idnits 2.17.1 draft-kent-opportunistic-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([STRINT], [I-D.farrell-perpass-attack]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... MUST still be able to explicitl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 1, 2014) is 3676 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBS' is mentioned on line 540, but not defined ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kent 3 Internet-Draft BBN Technologies 4 Intended status: Informational April 1, 2014 5 Expires: October 3, 2014 7 Opportunistic Security as a Countermeasure to Pervasive Monitoring 8 draft-kent-opportunistic-security-00 10 Abstract 12 This document was prepared as part of the IETF response to concerns 13 about "pervasive monitoring" (PM) as articulated in 14 [I-D.farrell-perpass-attack]. It begins by describing the current 15 criteria (discussed at the STRINT workshop [STRINT]) for addressing 16 concerns about PM. It then examines terminology that has been used 17 in IETF standards (and in academic publications) to describe 18 encryption and key management techniques, with a focus on 19 authentication vs. anonymity. Based on this analysis, it propose a 20 new term, "opportunistic security" to describe a goal for IETF 21 security protocols, one countermeasure to pervasive monitoring. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 3, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Removing Impediments to Using Encryption in the Internet . . 2 58 2. Why not "Opportunistic Encryption"? . . . . . . . . . . . . . 4 59 3. Authentication, Key Management and Existing IETF Protocols . 6 60 4. Anonymous, Pseudonymous, and Unauthenticated . . . . . . . . 7 61 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 67 1. Removing Impediments to Using Encryption in the Internet 69 Recent discussions in the IETF about countering pervasive monitoring 70 (PM) have focused on increasing the use of encryption. In many 71 contexts, it is perceived that requiring authentication as part of 72 establishing an encrypted session is the major impediment to more 73 widespread use of encryption. Many IETF security protocols commonly 74 call for such authentication as part of establishing an encrypted 75 session. Thus much of the current flurry of activity focuses on 76 removing this impediment. 78 The term "opportunistic encryption" has been used frequently to refer 79 to newly proposed techniques for encouraging more widespread use of 80 encryption. However, this term has not always been used 81 consistently, and the term already has a precise meaning in the IETF 82 [RFC4322]. The next section of this document examines terminology 83 relevant to the topic, and suggests use of a new term: "opportunistic 84 security", a compromise based on the many terms that have been 85 offered. It also proposes a definition for this term, based on 86 principles adopted during the STRINT Workshop. 88 Opportunistic Security (for realtime communication) is defined as a 89 set of mechanisms for a security protocol that exhibit the following 90 characteristics: 92 1. It is invisible to users, and, more broadly, to applications that 93 initiate sessions. (Lack of visibility is considered critical, 94 so that users do not become confused by the variability in the 95 set of security services they are being afforded. Similarly, an 96 application that has not mandated explicit use of security 97 protocol benefits from opportunistic security, but OUGHT NOT make 98 decisions on how to behave based on the success or failure of OS 99 mechanisms). 101 2. Opportunistic security is not intended to be a substitute for 102 authenticated, integrity-protected encryption when that set of 103 security services can be provided to a user. For example, if a 104 user can establish a server-authenticated (see definition later) 105 TLS session with a financial institution today, the user should 106 continue to do so. This suggests that users (applications?) 107 MUST still be able to explicitly invoke security protocols. 109 3. Opportunistic security will make use of perfect forward secrecy 110 (PFS) for key agreement. (PFS is desired because it affords 111 protection against a range of attacks that go beyond simple, 112 passive wiretapping. IKE [RFC2246] has offered this capability, 113 though it does not appear to be commonly used.) 115 4. Crypto-based authentication is a desired, though not mandatory, 116 feature. (Authentication comes in many flavors, as discussed in 117 Section 2. Authentication is desirable because it offers 118 protection against a range of active attacks, including MiTM, 119 that could cause a user to communicate with a party impersonating 120 the intended communication target. Some security protocols 121 mandate two-way crypto-based authentication, by default, e.g., 122 IKE. TLS [RFC5246] and SSH [RFC4253] typically make use of 1-way 123 (server-based) crypto-based authentication, although they also 124 support client-based crypto-based authentication. Because the 125 success or failure of opportunistic security is not to be 126 signaled to the initiator of a session, the user will not know 127 whether the target of the session has been authenticated. 129 5. Detection of a man-in-the-middle (MiTM) attacks is a desired, 130 thought not mandatory, feature. If crypto-based authentication 131 cannot be achieved, it may still be possible to detect a MiTM. 132 MiTM detection is considered a lower priority than (crypt-based) 133 authentication, and is to be pursued only if the former security 134 is not available (or fails). 136 6. Use of opportunistic security must not introduce human 137 perceptible delays in session/connection establishment, as that 138 will discourage its use. As a result, authentication and MiTM 139 detection should take place after an encrypted session is 140 established. This ordering implies that some data may be 141 transmitted prior to authentication or detection of a MiTM. 143 7. Because opportunistic security entails a new key management 144 paradigm, it requires new capabilities by peers. Thus, until OK 145 is universally adopted, an attempt to execute opportunistic 146 security may fail, and the session will fallback to plaintext 147 communication. >Since an attempt to use opportunistic security is 148 not communicated to users or applications, falling back to the 149 status quo, i.e., plaintext communication, is a reasonable 150 strategy. 152 2. Why not "Opportunistic Encryption"? 154 The term "opportunistic encryption" has become very widely used to 155 describe a range of key management (for encryption) techniques in the 156 IETF since the second half of 2013. However, it is not a new term. 157 The term was coined by H. Spencer and D. Redelmeier in 2001 158 [FreeSwanOE], and entered into the IETF vocabulary by Michael 159 Richardson in "Opportunistic Encryption using the Internet Key 160 Exchange (IKE)" an Informational RFC [RFC4322]. In this RFC the term 161 is defined as: 163 ... the process of encrypting a session with authenticated 164 knowledge of who the other party is without prearrangement. 166 This definition above is a bit opaque. The introduction to [RFC4322] 167 provides a clearer description of the term, by stating the following 168 goal: 170 The objective of opportunistic encryption is to allow encryption 171 without any pre-arrangement specific to the pair of systems 172 involved. 174 Later the RFC notes: 176 Opportunistic encryption creates tunnels between nodes that are 177 essentially strangers. This is done without any prior bilateral 178 arrangement. 180 The reference to "prior bilateral arrangement" is relevant to IPsec 181 but not to most other IETF security protocols. If every pair of 182 communicating entities were required to make prior bilateral 183 arrangements to enable encryption between them, a substantial 184 impediment would exist to widespread use of encryption. However, 185 other IETF security protocols define ways to enable encryption that 186 do not require prior bilateral arrangements. Some of these protocols 187 require that the target of a communication make available a public 188 key, for use by any initiator of a communication; an example of a 189 prior unilateral arrangement. The essential difference between IPsec 190 and most other IETF security protocols is that IPsec intrinsically 191 incorporates access control; other IETF security protocols do not. 193 The definition provided in [RFC4322] is specific to the IPsec 194 [RFC4301] context and ought not be used to describe the goals noted 195 in Section 1 above, as a countermeasure to PM. Because IPsec 196 implements access controls, it requires explicit specification (by 197 each peer) of how to process all traffic that crosses an "IPsec 198 boundary" (inbound and outbound). Traffic is either discarded, 199 permitted to pass w/o IPsec protection, or protected using IPsec. 200 The goal of opportunistic encryption (as per [RFC4322]) is to enable 201 IPsec protected communication without a priori configuration of 202 access control database entries at each peer (hence, bilateral). 203 Opportunistic encryption still calls for each party to identify the 204 other, using IKE [RFC2409] (equivalently, IKE v2 [RFC5996]) 205 authentication mechanisms, so it is not an unauthenticated key 206 management approach. Also note that [RFC4322] describes 207 opportunistic encryption relative to IKE, as it should; IPsec 208 implements encryption using ESP [RFC4303]. ESP usually provides data 209 integrity and authentication, as well as confidentiality, thus the 210 phrase opportunistic encryption is unduly narrow relative to the 211 anti-PM goal. 213 [RFC4322] also defines anonymous encryption: 215 Anonymous encryption: the process of encrypting a session without 216 any knowledge of who the other parties are. No authentication of 217 identities is done. 219 Thus, in [RFC4322], the term anonymous encryption refers to encrypted 220 communication where neither party is authenticated to the other. 221 Also note that the definition above refers to "the process of 222 encrypting a session ..." In fact, it the key management process that 223 causes an encrypted session to be authenticated, or not, based on 224 credentials such as public keys, public key certificates, etc. 226 An examination of about 70 papers published in ACM, IEEE, and other 227 security conference proceedings identified numerous uses of the terms 228 opportunistic and anonymous encryption. Most, though not all, of the 229 papers used the terms opportunistic encryption and anonymous 230 encryption as defined in [RFC4322], but in some papers the 231 terminology was unclear or inconsistent with the [RFC4322] 232 definition. 234 Wikipedia [wikipedia] uses a somewhat different definition for 235 opportunistic encryption. Wikipedia [wikipedia] provides the 236 following definition: 238 Opportunistic encryption refers to any system that, when 239 connecting to another system, attempts to encrypt the 240 communications channel otherwise falling back to unencrypted 241 communications. This method requires no pre-arrangement between 242 the two systems. 244 This definition shares some aspects of the [RFC4322] definition, but 245 it is not equivalent; it makes no mention of authentication or access 246 control, two essential aspects of opportunistic encryption as per 247 [RFC4322]. The definition is similar to some of the goals listed in 248 Section 1, but not to all of them. The article goes on to cite 249 examples of what it considers to be opportunistic encryption (citing 250 use of self-signed certificates in TLS), and in so doing contradicts 251 the concise definition above. Given the questionable scholarship of 252 the article, and its inconsistent use of the term with a range of 253 examples, it does not merit consideration when choosing a term to 254 describe the anti-PM mechanisms the IETF is developing. 256 Thus, the recent penchant for using the term opportunistic encryption 257 to refer to mechanisms that yield unauthenticated sessions is 258 inaccurate, even if popular. Although opportunistic encryption, as 259 described in [RFC4322], did not see widespread use, the effort has 260 resumed (as briefed in late 2013 [OErevisited]) and thus it makes 261 sense to reserve the term for that well-defined context. 263 The adjective "opportunistic" has caught the imagination of many (at 264 least in the IETF), so it seems desirable to retain that word when 265 selecting a new phrase to describe the goals cited in Section 1. It 266 was observed that these goals encompass more than just encryption. 267 PFS is a key management feature, and the optional (crypt-based) 268 authentication and MiTM detection features are security services 269 [ISO.7498-2.1988]. Thus the term "opportunistic security" is 270 proposed here as the (more accurate) term to replace opportunistic 271 encryption. 273 3. Authentication, Key Management and Existing IETF Protocols 275 As noted above, many IETF security protocols incorporate (crypto- 276 based) authentication as an intrinsic part of key management. IKE 277 normally requires two-way (mutual) authentication of the peers that 278 establish security associations. TLS normally affords server 279 authentication (based on X.509 certificates and the so-called Web 280 PKI), and offers optional support for client authentication based on 281 a leap of faith (LoF) or trust on first use (TOFU) approach. Because 282 SSH is most often employed in an enterprise context, reliance on 283 these initial authentication mechanisms represents a reasonable risk- 284 based design tradeoff. 286 Although, as noted above, many IETF security protocols incorporate 287 1-way or 2-way crypto-based authentication as part of key management, 288 most also offer options to enable creation of an encrypted session 289 based on 1-way or 2-way unauthenticated key management. For example, 290 TLS typically is used in a fashion that provides server, but not 291 client, authenticated communication. TLS also supports 292 "establishment of sessions" in which neither party (client or server) 293 asserts an identity during the handshake protocol (based on Diffie- 294 Hellman or ECDH key agreement). Thus TLS offers 2-way 295 unauthenticated communication in addition to the common, server- 296 authenticated communication. (The same analysis applies to DTLS 297 [RFC6347].) 299 In the store-and-forward environment, encrypted S/MIME messages are 300 usually signed. Moreover, the recipient of an S/MIME message is 301 typically identified by a certificate, so the originator knows to 302 whom the message is directed. Thus, in common use, S/MIME provides 303 2-way authentication of traffic. However, S/MIME allows transmission 304 of originator-anonymous encrypted messages. First, note that signing 305 of a message by the originator is optional (see Section 3.3 of 306 [RFC5751]). Also, an originator may employ a key agreement algorithm 307 (e.g., Diffie-Hellman), to preserve originator anonymity. 308 (Section 6.2.2 of [RFC5652] notes: "The originatorKey alternative 309 inclues the algorithm identifier and sender's key agreement public 310 key. This alternative permits originator anonymity since the public 311 key is not certified.") 313 The originator of an S/MIME message directs an encrypted message to a 314 specific recipient (or set of recipients), and typically makes use of 315 a public key associated with the intended recipient to encrypt the 316 content encryption key for the message. If the recipient is 317 identified by a certificate, as is commonly the case, one would view 318 the communication as recipient-authenticated. However, if the public 319 key associated with a recipient is not conveyed via a validated 320 certificate, then the recipient would not be (crypto) authenticated 321 in the traditional sense. S/MIME calls for implementations to cache 322 capabilities information about senders (section 2.7.2 of [RFC5751]), 323 to facilitate this form of inband cryptographic data transfer. This 324 represents and alternative way for a prospective recipient to convey 325 public key info. (Note, this procedure is at odds with the 326 definition of opportunistic encryption, as it calls for a priori, 327 per-peer configuration of data to enable later encrypted 328 communication!) 330 4. Anonymous, Pseudonymous, and Unauthenticated 332 The discussion above used the terms "authenticated" and 333 "unauthenticated" when describing various modes of key management. 334 These different modes achieve different results with respect to 335 identification of participants in a communication. We avoided the 336 term "anonymous" in part because unauthenticated communication, in 337 many contexts does not confer anonymity, per se. If a user does not 338 employ a key management technique that authenticate his/her identity, 339 the user may be required to employ some other form of authentication 340 later in the communication. In such cases the user clearly is not 341 anonymous. Also, the IP address and other characteristics of the 342 user may be gleaned from a communication, independent of the use of 343 explicit authentication mechanisms, including those associated with 344 key management. Finally, we avoid using the term "unauthenticated 345 encryption" because "authenticated encryption" is a well-defined term 346 in the crypto community. Instead we use the term "authenticated 347 encrypted communication". 349 Another reason to avoid the term "anonymous" her is because it is 350 often confused with mechanisms that offer pseudonymous 351 communication.Pseudonymity [merriam-webster] implies use of an 352 identifier, but one that represents a "false name" for an entity. 353 Use of pseudonyms is common in some Internet communication contexts. 354 Many Gmail, Yahoo, and Hotmail mail addresses likely represent 355 pseudonyms. A pseudonym is an attractive way to provide 356 unauthenticated communication. A pseudonym typically makes use of 357 the same syntax as a verified identity in authenticated 358 communication, and thus protocols designed to make use of 359 authenticated identities are compatible with use of pseudonyms, to 360 first order. 362 "Traceable Anonymous Certificate", is an Experimental RFC [RFC5636] 363 that describes a specific mechanism for a Certification Authority 364 (CA) [RFC5280] to issue an X.509 certificate with a pseudonym. The 365 goal of the mechanisms described in that RFC is to conceal a user's 366 identity in PKI-based application contexts (for privacy), but to 367 permit authorities to reveal the true identity (under controlled 368 circumstances). This appears to be the only RFC that explicitly 369 addresses pseudonymous key management; although it uses the term 370 "pseudonym" extensively, it also uses the term "anonymous" more 371 often, treating the two as synonyms. 373 Self-signed certificates [RFC6818] are often used with TLS in both 374 browser and non-browser contexts. In the HTTPS (browser) context, a 375 self-signed certificate typically is accepted after a warning has 376 been displayed to a user; the HTTPS [RFC2818] requirement to match a 377 server DNS name against a certificate Subject name does not apply 378 when TLS is employed in non-browser contexts. The Subject name in a 379 self-signed certificate is completely under the control of the entity 380 that issued it, thus this is a trivial way to generate a pseudonymous 381 certificate, without using the mechanisms specified in [RFC5636]. 382 Thus support for pseudonymous encrypted communication is supported in 383 web browsing, as a side effect of this deviation from [RFC2818]. 384 (Some speculate that most self-signed certificates contain accurate 385 user or device IDs; the certificates are used to avoid the costs 386 associated with issuance of certificates by Web PKI CAs.) 388 Pseudonymous encrypted communication is the result of applying 389 techniques to distribute keys when an authentication exchange is 390 based on a pseudonym, e.g., a self-signed certificate containing a 391 pseudonym. As with unauthenticated encrypted communication, 392 pseudonymous encrypted communication may apply to one or both parties 393 in an encrypted communication. One also can imagine mixed mode 394 communications, e.g., in which unauthenticated encrypted 395 communication is employed by one party and pseudonymous encrypted 396 communication is employed by the other. 398 As noted earlier, the model for opportunistic security (for realtime 399 communications) is to first establish an encrypted session, using key 400 management that affords PFS, and then attempt to "upgrade" it to an 401 authenticated communication. This is analogous to what IKE [RFC4306] 402 does. As experience with IKE has shown, this creates a DoS 403 vulnerability, i.e., an attacker can cause the target of a session/ 404 connection to expend resources performing key agreement operations 405 prior to authenticating the initiator of the communication. 406 Implementations of opportunistic security will have to address this 407 concern. Opportunistic security designs also will have to address 408 various flavors of downgrade attacks, since opportunistic security 409 will allow unauthenticated or plaintext communication. Even though 410 opportunistic security assumes that a user is not alerted to its use, 411 it may be appropriate to alert a user to such attacks, or provide a 412 means by which a system administrator can become aware of them. The 413 details of how these concerns are addressed probably will be specific 414 to the protocol context in which opportunistic security is 415 implemented. 417 5. Terminology 419 The following definitions are derived from the Internet Security 420 Glossary [RFC4949], where applicable. 422 Authenticated Encrypted Communication An encrypted communication 423 session based on using a key management technique that provides 424 crypto-based authentication, of one or both parties to the 425 communication. The communication may be 1-way or 2-way 426 authenticated. 428 Authentication The process of verifying a claim that a system or 429 entity has a certain attribute value. In the IETF context, 430 authentication typically refers to verification of an identity 431 claim, relative to some identifier's space. Typical identifier 432 spaces in the Internet include DNS names and [RFC0822] names. 434 (Data) Confidentiality The security service that prevents 435 information becoming available to unauthorized entities. 436 Encryption is the security mechanism typically used to implement 437 confidentiality. 439 (Data) Integrity The security service that enables a recipient of a 440 message or a packet to determine if the data has been modified or 441 destroyed in an unauthorized manner. 443 Key agreement algorithm A key establishment method based on 444 asymmetric cryptography, in which a pair of entities engage in a 445 public exchange of data (public keys and associated data), to 446 generate the same shared secret value. (Thus both entities 447 contribute secret values to the resulting key.) This value is 448 later used to create symmetric keys used for encryption and/or 449 integrity checking. Diffie-Hellman and Elliptic Curve Diffie- 450 Hellman (ECDH) are the most common algorithms used for key 451 agreement as specified in RFCs. 453 Key transport A key establishment method by which a secret 454 (symmetric) key is generated by one entity and securely sent to 455 another entity. (Thus only one entity contributes secret values 456 to the resulting key.) Key transport may make use of either 457 symmetric or asymmetric cryptographic algorithms. The RSA 458 algorithm is most commonly cited in RFCs as a basis for a public 459 key, key transport mechanism. 461 Leap of Faith (LoF) In a protocol, a leap of faith typically 462 consists of accepting an asserted identity, without authenticating 463 that assertion, and caching a key or credential associated with 464 the identity. Subsequent communication using the cached key/ 465 credential is secure against a MiTM attack, if such an attack did 466 not succeed during the (vulnerable) initial communication or if 467 the MiTM is not present for all subsequent communications. The 468 SSH protocol ([RFC4251], [RFC4252], [RFC4253]) makes use of LoF. 469 The phrase trust on first use (TOFU) is often considered a 470 synonym. 472 Man-in-the-Middle attack (MiTM) A form of active wiretapping attack 473 in which an attacker intercepts and may selectively modify 474 communicated data to masquerade as one of the entities involved in 475 a communication. Masquerading enables the MiTM to violate the 476 confidentiality and/or the integrity of communicated data passing 477 through it. 479 Opportunistic Encryption A key management technique that enables 480 authenticated, communication between parties, and that does not 481 require a priori, bilateral arrangements. This term is defined 482 only for IPsec. 484 Opportunistic Security The result of employing a key management 485 technique that attempts to establish an encrypted communication 486 automatically and invisibly to a user. Opportunistic security may 487 attempt to upgrade an encrypted communication to provide 488 authentication (one or two way), and/or to detect MiTM attacks. 489 If opportunistic security is unable to create an encrypted 490 communication, e.g., because the other communicant does not 491 support opportunistic security, unencrypted (plaintext) 492 communication results. 494 Perfect Forward Secrecy (PFS) For a key management protocol, the 495 property that compromise of long-term keys does not compromise 496 session/traffic/content keys that are derived from or distributed 497 using the long-term keys. 499 Private key The secret component of a pair of cryptographic keys 500 used for asymmetric cryptography. 502 Public key The publicly disclosed component of a pair of 503 cryptographic keys used for asymmetric cryptography. The phrase 504 "public key data" includes a public key and any additional 505 parameters required to perform computation using the public key. 507 Pseudonymous Communication A key management technique that enables 508 pseudonymous communication between parties, e.g., based on use of 509 a self-signed certificate. Pseudonymous communication may be one- 510 way or two-way, depending on details of the key management 511 mechanism employed. 513 Session A realtime communication between entities. 515 Shared secret A value derived from a key agreement algorithm and 516 used as an input to generate a CEK or traffic encryption key. 518 Symmetric cryptography A type of cryptography in which the 519 algorithms employ the same key for encryption and decryption, and 520 the key is not publicly disclosed. 522 Traffic (encryption) key (TEK) A symmetric key used to encrypt/ 523 decrypt traffic carried via an association. 525 Trust on First Use (TOFU) See Leap of Faith, above. 527 Unauthenticated Encrypted Communication An encrypted communication 528 session based on using a key management technique that enables 529 unauthenticated communication between parties. The communication 530 may be 1-way or 2-way unauthenticated. If 1-way, the initiator 531 (client) or the target (server) may be anonymous. 533 6. Acknowledgements 535 I want to thank David Mandelberg for his help in generating this 536 document. 538 7. Security Considerations 540 [TBS] 542 8. References 544 [FreeSwanOE] 545 Spencer, H. and D. Redelmeier, "Opportunistic Encryption", 546 May 2001. 548 [I-D.farrell-perpass-attack] 549 Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an 550 Attack", draft-farrell-perpass-attack-06 (work in 551 progress), February 2014. 553 [ISO.7498-2.1988] 554 International Organization for Standardization, 555 "Information Processing Systems - Open Systems 556 Interconnection Reference Model - Security Architecture", 557 ISO Standard 7498-2, 1988. 559 [OErevisited] 560 Wouters, P., "Opportunistic Encryption revisited", 561 November 2013, . 564 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 565 text messages", STD 11, RFC 822, August 1982. 567 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 568 RFC 2246, January 1999. 570 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 571 (IKE)", RFC 2409, November 1998. 573 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 575 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 576 Protocol Architecture", RFC 4251, January 2006. 578 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 579 Authentication Protocol", RFC 4252, January 2006. 581 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 582 Transport Layer Protocol", RFC 4253, January 2006. 584 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 585 Internet Protocol", RFC 4301, December 2005. 587 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 588 4303, December 2005. 590 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 591 4306, December 2005. 593 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 594 Encryption using the Internet Key Exchange (IKE)", RFC 595 4322, December 2005. 597 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 598 4949, August 2007. 600 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 601 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 603 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 604 Housley, R., and W. Polk, "Internet X.509 Public Key 605 Infrastructure Certificate and Certificate Revocation List 606 (CRL) Profile", RFC 5280, May 2008. 608 [RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent, 609 "Traceable Anonymous Certificate", RFC 5636, August 2009. 611 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 612 RFC 5652, September 2009. 614 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 615 Mail Extensions (S/MIME) Version 3.2 Message 616 Specification", RFC 5751, January 2010. 618 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 619 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 620 5996, September 2010. 622 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 623 Security Version 1.2", RFC 6347, January 2012. 625 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 626 Infrastructure Certificate and Certificate Revocation List 627 (CRL) Profile", RFC 6818, January 2013. 629 [STRINT] "A W3C/IAB workshop on Strengthening the Internet Against 630 Pervasive Monitoring (STRINT)", March 2014, . 633 [merriam-webster] 634 "pseudonymity", March 2014, 635 . 637 [wikipedia] 638 "Opportunistic encryption", November 2013, 639 . 642 Author's Address 644 Stephen Kent 645 BBN Technologies 646 10 Moulton St. 647 Camridge, MA 02138 648 US 650 Email: kent@bbn.com