idnits 2.17.1 draft-kent-opportunistic-security-01.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 106: '...uggests that users (applications) MUST...' RFC 2119 keyword, line 138: '...d MiTM detection SHOULD take place aft...' RFC 2119 keyword, line 142: '...sidered onerous, authentication MAY be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2014) is 3665 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBS' is mentioned on line 550, but not defined ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** 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: 12 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 8, 2014 5 Expires: October 10, 2014 7 Opportunistic Security as a Countermeasure to Pervasive Monitoring 8 draft-kent-opportunistic-security-01 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 10, 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 . . . . . . . . 8 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 98 [RFC6919] make decisions on how to behave based on the success or 99 failure of OS 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) MUST 107 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 [RFC5996] 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 (crypto-based) 133 authentication, and is to be pursued only if the former security 134 service is not available (or fails). 136 6. In some contexts, human-perceptible delays in session/connection 137 establishment might discourage use of OS. In such contexts, 138 authentication and MiTM detection SHOULD take place after an 139 encrypted session is established. This ordering implies that 140 some data may be transmitted prior to authentication or detection 141 of a MiTM. In a context where delays imposed by performing 142 authentication are not considered onerous, authentication MAY be 143 attempted prior to enabling transmission. In such contexts all 144 application traffic will be afforded authentication (and, 145 typically, integrity) if available. 147 7. Because opportunistic security entails a new key management 148 paradigm, it requires new capabilities by peers. Thus, until OS 149 is universally adopted, an attempt to execute opportunistic 150 security may fail, and the session will fallback to plaintext 151 communication. Since an attempt to use opportunistic security is 152 not communicated to users or applications, falling back to the 153 status quo, i.e., plaintext communication, is a reasonable 154 strategy. 156 2. Why not "Opportunistic Encryption"? 158 The term "opportunistic encryption" has become very widely used to 159 describe a range of key management (for encryption) techniques in the 160 IETF since the second half of 2013. However, it is not a new term. 161 The term was coined by H. Spencer and D. Redelmeier in 2001 162 [FreeSwanOE], and entered into the IETF vocabulary by Michael 163 Richardson in "Opportunistic Encryption using the Internet Key 164 Exchange (IKE)" an Informational RFC [RFC4322]. In this RFC the term 165 is defined as: 167 ... the process of encrypting a session with authenticated 168 knowledge of who the other party is without prearrangement. 170 This definition above is a bit opaque. The introduction to [RFC4322] 171 provides a clearer description of the term, by stating the following 172 goal: 174 The objective of opportunistic encryption is to allow encryption 175 without any pre-arrangement specific to the pair of systems 176 involved. 178 Later the RFC notes: 180 Opportunistic encryption creates tunnels between nodes that are 181 essentially strangers. This is done without any prior bilateral 182 arrangement. 184 The reference to "prior bilateral arrangement" is relevant to IPsec 185 but not to most other IETF security protocols. If every pair of 186 communicating entities were required to make prior bilateral 187 arrangements to enable encryption between them, a substantial 188 impediment would exist to widespread use of encryption. However, 189 other IETF security protocols define ways to enable encryption that 190 do not require prior bilateral arrangements. Some of these protocols 191 require that the target of a communication make available a public 192 key, for use by any initiator of a communication; an example of a 193 prior unilateral arrangement. The essential difference between IPsec 194 and most other IETF security protocols is that IPsec intrinsically 195 incorporates access control; other IETF security protocols do not. 197 The definition provided in [RFC4322] is specific to the IPsec 198 [RFC4301] context and ought not be used to describe the goals noted 199 in Section 1 above, as a countermeasure to PM. Because IPsec 200 implements access controls, it requires explicit specification (by 201 each peer) of how to process all traffic that crosses an "IPsec 202 boundary" (inbound and outbound). Traffic is either discarded, 203 permitted to pass w/o IPsec protection, or protected using IPsec. 204 The goal of opportunistic encryption (as per [RFC4322]) is to enable 205 IPsec protected communication without a priori configuration of 206 access control database entries at each peer (hence, bilateral). 207 Opportunistic encryption still calls for each party to identify the 208 other, using IKE v2 [RFC5996] (equivalently, IKE v1 [RFC2409]) 209 authentication mechanisms, so it is not an unauthenticated key 210 management approach. Also note that [RFC4322] describes 211 opportunistic encryption relative to IKE, as it should; IPsec 212 implements encryption using ESP [RFC4303]. ESP usually provides data 213 integrity and authentication, as well as confidentiality, thus the 214 phrase opportunistic encryption is unduly narrow relative to the 215 anti-PM goal. 217 [RFC4322] also defines anonymous encryption: 219 Anonymous encryption: the process of encrypting a session without 220 any knowledge of who the other parties are. No authentication of 221 identities is done. 223 Thus, in [RFC4322], the term anonymous encryption refers to encrypted 224 communication where neither party is authenticated to the other. 225 Also note that the definition above refers to "the process of 226 encrypting a session ..." In fact, it is the key management process 227 that causes an encrypted session to be authenticated, or not, based 228 on credentials such as public keys, public key certificates, etc. 230 An examination of about 70 papers published in ACM, IEEE, and other 231 security conference proceedings identified numerous uses of the terms 232 opportunistic and anonymous encryption. Most, though not all, of the 233 papers used the terms opportunistic encryption and anonymous 234 encryption as defined in [RFC4322], but in some papers the 235 terminology was unclear or inconsistent with the [RFC4322] 236 definition. 238 Wikipedia [wikipedia] uses a somewhat different definition for 239 opportunistic encryption. Wikipedia [wikipedia] provides the 240 following definition: 242 Opportunistic encryption refers to any system that, when 243 connecting to another system, attempts to encrypt the 244 communications channel otherwise falling back to unencrypted 245 communications. This method requires no pre-arrangement between 246 the two systems. 248 This definition shares some aspects of the [RFC4322] definition, but 249 it is not equivalent; it makes no mention of authentication or access 250 control, two essential aspects of opportunistic encryption as per 251 [RFC4322]. The definition is similar to some of the goals listed in 252 Section 1, but not to all of them. The article goes on to cite 253 examples of what it considers to be opportunistic encryption (citing 254 use of self-signed certificates in TLS), and in so doing contradicts 255 the concise definition above. Given the questionable scholarship of 256 the article, and its inconsistent use of the term with a range of 257 examples, it does not merit consideration when choosing a term to 258 describe the anti-PM mechanisms the IETF is developing. 260 Thus, the recent penchant for using the term opportunistic encryption 261 to refer to mechanisms that yield unauthenticated sessions is 262 inaccurate, even if popular. Although opportunistic encryption, as 263 described in [RFC4322], did not see widespread use, the effort has 264 resumed (as briefed in late 2013 [OErevisited]) and thus it makes 265 sense to reserve the term for that well-defined context. 267 The adjective "opportunistic" has caught the imagination of many (at 268 least in the IETF), so it seems desirable to retain that word when 269 selecting a new phrase to describe the goals cited in Section 1. It 270 was observed that these goals encompass more than just encryption. 271 PFS is a key management feature, and the optional (crypto-based) 272 authentication and MiTM detection features are security services 273 [ISO.7498-2.1988]. Thus the term "opportunistic security" is 274 proposed here as the (more accurate) term to replace opportunistic 275 encryption. 277 3. Authentication, Key Management and Existing IETF Protocols 279 As noted above, many IETF security protocols incorporate (crypto- 280 based) authentication as an intrinsic part of key management. IKE 281 normally requires two-way (mutual) authentication of the peers that 282 establish security associations. TLS normally affords server 283 authentication (based on X.509 certificates and the so-called Web 284 PKI), and offers optional support for client authentication based on 285 use of certificates. SSH ([RFC4251], [RFC4252], [RFC4253]) makes use 286 of a trust on first use (TOFU) approach (aka a leap of faith, see 287 below) for server authentication. Because SSH is most often employed 288 in an enterprise context, reliance on this initial authentication 289 mechanism (for severs) represents a reasonable risk-based design 290 tradeoff. (User authentication in SSH is supported via a wide range 291 of techniques, some of which are cryptographic-based.) 293 Although, as noted above, many IETF security protocols incorporate 294 1-way or 2-way crypto-based authentication as part of key management, 295 most also offer options to enable creation of an encrypted session 296 based on 1-way or 2-way unauthenticated key management. For example, 297 TLS typically is used in a fashion that provides server, but not 298 client, authenticated communication. TLS also supports 299 "establishment of sessions" in which neither party (client or server) 300 asserts an identity during the handshake protocol (based on Diffie- 301 Hellman or ECDH key agreement). Thus TLS offers 2-way 302 unauthenticated communication in addition to the common, server- 303 authenticated communication. (The same analysis applies to DTLS 304 [RFC6347].) 306 In the store-and-forward environment, encrypted S/MIME messages are 307 usually signed. Moreover, the recipient of an S/MIME message is 308 typically identified by a certificate, so the originator specifies to 309 whom the message is directed. Thus, in common use, S/MIME provides 310 2-way authentication of traffic. However, S/MIME allows transmission 311 of originator-anonymous encrypted messages. First, note that signing 312 of a message by the originator is optional (see Section 3.3 of 313 [RFC5751]). Also, an originator may employ a key agreement algorithm 314 (e.g., Diffie-Hellman), to preserve originator anonymity. 315 (Section 6.2.2 of [RFC5652] notes: "The originatorKey alternative 316 inclues the algorithm identifier and sender's key agreement public 317 key. This alternative permits originator anonymity since the public 318 key is not certified.") 320 The originator of an S/MIME message directs an encrypted message to a 321 specific recipient (or set of recipients), and typically makes use of 322 a public key associated with the intended recipient to encrypt the 323 content encryption key for the message. If the recipient is 324 identified by a certificate, as is commonly the case, one would view 325 the communication as recipient-authenticated. However, if the public 326 key associated with a recipient is not conveyed via a validated 327 certificate, then the recipient would not be (crypto) authenticated 328 in the traditional sense. S/MIME calls for implementations to cache 329 capabilities information about senders (section 2.7.2 of [RFC5751]), 330 to facilitate this form of inband cryptographic data transfer. This 331 represents an alternative way for a prospective recipient to convey 332 public key info. (Note, this procedure is at odds with the 333 definition of opportunistic encryption, as it calls for a priori, 334 per-peer configuration of data to enable later encrypted 335 communication!) 337 4. Anonymous, Pseudonymous, and Unauthenticated 339 The discussion above used the terms "authenticated" and 340 "unauthenticated" when describing various modes of key management. 341 These different modes achieve different results with respect to 342 identification of participants in a communication. We avoided the 343 term "anonymous" in part because unauthenticated communication, in 344 many contexts does not confer anonymity, per se. If a user does not 345 employ a key management technique that authenticate his/her identity, 346 the user may be required to employ some other form of authentication 347 later in the communication. In such cases the user clearly is not 348 anonymous. Also, the IP address and other characteristics of the 349 user may be gleaned from a communication, independent of the use of 350 explicit authentication mechanisms, including those associated with 351 key management. Finally, we avoid using the term "unauthenticated 352 encryption" because "authenticated encryption" is a well-defined term 353 in the crypto community. Instead we use the terms "unauthenticated 354 encrypted communication" and "authenticated encrypted communication" 355 as appropriate. 357 Another reason to avoid the term "anonymous" here is because it is 358 often confused with mechanisms that offer pseudonymous communication. 359 Pseudonymity [merriam-webster] implies use of an identifier, but one 360 that represents a "false name" for an entity. Use of pseudonyms is 361 common in some Internet communication contexts. Many Gmail, Yahoo, 362 and Hotmail mail addresses likely represent pseudonyms. A pseudonym 363 is an attractive way to provide unauthenticated communication. A 364 pseudonym typically makes use of the same syntax as a verified 365 identity in authenticated communication, and thus protocols designed 366 to make use of authenticated identities are compatible with use of 367 pseudonyms, to first order. 369 "Traceable Anonymous Certificate", is an Experimental RFC [RFC5636] 370 that describes a specific mechanism for a Certification Authority 371 (CA) [RFC5280] to issue an X.509 certificate with a pseudonym. The 372 goal of the mechanisms described in that RFC is to conceal a user's 373 identity in PKI-based application contexts (for privacy), but to 374 permit authorities to reveal the true identity (under controlled 375 circumstances). This appears to be the only RFC that explicitly 376 addresses pseudonymous key management; although it uses the term 377 "pseudonym" extensively, it also uses the term "anonymous" more 378 often, treating the two as synonyms. 380 Self-signed certificates [RFC6818] are often used with TLS in both 381 browser and non-browser contexts. In the HTTPS (browser) context, a 382 self-signed certificate typically is accepted after a warning has 383 been displayed to a user; the HTTPS ([RFC2818], [RFC6797]) 384 requirement to match a server DNS name against a certificate Subject 385 name does not apply when TLS is employed in non-browser contexts. 386 The Subject name in a self-signed certificate is completely under the 387 control of the entity that issued it, thus this is a trivial way to 388 generate a pseudonymous certificate, without using the mechanisms 389 specified in [RFC5636]. Thus support for pseudonymous encrypted 390 communication is supported in web browsing, as a side effect of this 391 deviation from [RFC2818]. (Some speculate that most self-signed 392 certificates contain accurate user or device IDs; the certificates 393 are used to avoid the costs associated with issuance of certificates 394 by Web PKI CAs.) 396 Pseudonymous encrypted communication is the result of applying 397 techniques to distribute keys when an authentication exchange is 398 based on a pseudonym, e.g., a self-signed certificate containing a 399 pseudonym. As with unauthenticated encrypted communication, 400 pseudonymous encrypted communication may apply to one or both parties 401 in an encrypted communication. One also can imagine mixed mode 402 communications, e.g., in which unauthenticated encrypted 403 communication is employed by one party and pseudonymous encrypted 404 communication is employed by the other. 406 As noted earlier, the model for opportunistic security (for realtime 407 communications) is to first establish an encrypted session, using key 408 management that affords PFS, and then attempt to "upgrade" it to an 409 authenticated communication. This is analogous to what IKE v2 410 [RFC5996] does. As experience with IKE has shown, this creates a DoS 411 vulnerability, i.e., an attacker can cause the target of a session/ 412 connection to expend resources performing key agreement operations 413 prior to authenticating the initiator of the communication. 414 Implementations of opportunistic security will have to address this 415 concern. Opportunistic security designs also will have to address 416 various flavors of downgrade attacks, since opportunistic security 417 will allow unauthenticated or plaintext communication. Even though 418 opportunistic security assumes that a user is not alerted to its use, 419 it may be appropriate to alert a user to such attacks, or provide a 420 means by which a system administrator can become aware of them. The 421 details of how these concerns are addressed probably will be specific 422 to the protocol context in which opportunistic security is 423 implemented. 425 5. Terminology 427 The following definitions are derived from the Internet Security 428 Glossary [RFC4949], where applicable. 430 Authenticated Encrypted Communication An encrypted communication 431 session based on using a key management technique that provides 432 crypto-based authentication, of one or both parties to the 433 communication. The communication may be 1-way or 2-way 434 authenticated. 436 Authentication The process of verifying a claim that a system or 437 entity has a certain attribute value. In the IETF context, 438 authentication typically refers to verification of an identity 439 claim, relative to some identifier's space. Typical identifier 440 spaces in the Internet include DNS names and [RFC0822] names. 442 (Data) Confidentiality The security service that prevents 443 information becoming available to unauthorized entities. 444 Encryption is the security mechanism typically used to implement 445 confidentiality. 447 Content encryption key (CEK) A symmetric cryptographic key used to 448 encrypt/decrypt the content of an S/MIME message. (Sometimes 449 referred to as a message encryption key.) 451 (Data) Integrity The security service that enables a recipient of a 452 message or a packet to determine if the data has been modified or 453 destroyed in an unauthorized manner. 455 Key agreement algorithm A key establishment method based on 456 asymmetric cryptography, in which a pair of entities engage in a 457 public exchange of data (public keys and associated data), to 458 generate the same shared secret value. (Thus both entities 459 contribute secret values to the resulting key.) This value is 460 later used to create symmetric keys used for encryption and/or 461 integrity checking. Diffie-Hellman and Elliptic Curve Diffie- 462 Hellman (ECDH) are the most common algorithms used for key 463 agreement as specified in RFCs. 465 Key transport A key establishment method by which a secret 466 (symmetric) key is generated by one entity and securely sent to 467 another entity. (Thus only one entity contributes secret values 468 to the resulting key.) Key transport may make use of either 469 symmetric or asymmetric cryptographic algorithms. The RSA 470 algorithm is most commonly cited in RFCs as a basis for a public 471 key, key transport mechanism. 473 Man-in-the-Middle attack (MiTM) A form of active wiretapping attack 474 in which an attacker intercepts and may selectively modify 475 communicated data to masquerade as one of the entities involved in 476 a communication. Masquerading enables the MiTM to violate the 477 confidentiality and/or the integrity of communicated data passing 478 through it. 480 Opportunistic Encryption A key management technique that enables 481 authenticated communication between parties, and that does not 482 require a priori, bilateral arrangements. This term is defined 483 only for IPsec. 485 Opportunistic Security The result of employing a key management 486 technique that attempts to establish an encrypted communication 487 automatically and invisibly to a user. Opportunistic security may 488 attempt to upgrade an encrypted communication to provide 489 authentication (one or two way), and/or to detect MiTM attacks. 490 If opportunistic security is unable to create an encrypted 491 communication, e.g., because the other communicant does not 492 support opportunistic security, unencrypted (plaintext) 493 communication results. 495 Perfect Forward Secrecy (PFS) For a key management protocol, the 496 property that compromise of long-term keys does not compromise 497 session/traffic/content keys that are derived from or distributed 498 using the long-term keys. 500 Private key The secret component of a pair of cryptographic keys 501 used for asymmetric cryptography. 503 Public key The publicly disclosed component of a pair of 504 cryptographic keys used for asymmetric cryptography. The phrase 505 "public key data" includes a public key and any additional 506 parameters required to perform computation using the public key. 508 Pseudonymous Communication A key management technique that enables 509 pseudonymous communication between parties, e.g., based on use of 510 a self-signed certificate. Pseudonymous communication may be one- 511 way or two-way, depending on details of the key management 512 mechanism employed. 514 Session A realtime communication between entities. 516 Shared secret A value derived from a key agreement algorithm and 517 used as an input to generate a content encryption key or traffic 518 encryption key. 520 Symmetric cryptography A type of cryptography in which the 521 algorithms employ the same key for encryption and decryption, and 522 the key is not publicly disclosed. 524 Traffic (encryption) key (TEK) A symmetric key used to encrypt/ 525 decrypt traffic carried via an association. 527 Trust on First Use (TOFU) In a protocol, TOFU typically consists of 528 accepting an asserted identity, without authenticating that 529 assertion, and caching a key or credential associated with the 530 identity. Subsequent communication using the cached key/ 531 credential is secure against a MiTM attack, if such an attack did 532 not succeed during the (vulnerable) initial communication or if 533 the MiTM is not present for all subsequent communications. The 534 SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF) 535 is sometimes used as a synonym. 537 Unauthenticated Encrypted Communication An encrypted communication 538 session based on using a key management technique that enables 539 unauthenticated communication between parties. The communication 540 may be 1-way or 2-way unauthenticated. If 1-way, the initiator 541 (client) or the target (server) may be anonymous. 543 6. Acknowledgements 545 I want to thank David Mandelberg and Edric Barnes for their help in 546 generating this document. 548 7. Security Considerations 550 [TBS] 552 8. References 554 [FreeSwanOE] 555 Spencer, H. and D. Redelmeier, "Opportunistic Encryption", 556 May 2001. 558 [I-D.farrell-perpass-attack] 559 Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an 560 Attack", draft-farrell-perpass-attack-06 (work in 561 progress), February 2014. 563 [ISO.7498-2.1988] 564 International Organization for Standardization, 565 "Information Processing Systems - Open Systems 566 Interconnection Reference Model - Security Architecture", 567 ISO Standard 7498-2, 1988. 569 [OErevisited] 570 Wouters, P., "Opportunistic Encryption revisited", 571 November 2013, . 574 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 575 text messages", STD 11, RFC 822, August 1982. 577 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 578 (IKE)", RFC 2409, November 1998. 580 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 582 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 583 Protocol Architecture", RFC 4251, January 2006. 585 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 586 Authentication Protocol", RFC 4252, January 2006. 588 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 589 Transport Layer Protocol", RFC 4253, January 2006. 591 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 592 Internet Protocol", RFC 4301, December 2005. 594 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 595 4303, December 2005. 597 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 598 Encryption using the Internet Key Exchange (IKE)", RFC 599 4322, December 2005. 601 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 602 4949, August 2007. 604 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 605 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 607 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 608 Housley, R., and W. Polk, "Internet X.509 Public Key 609 Infrastructure Certificate and Certificate Revocation List 610 (CRL) Profile", RFC 5280, May 2008. 612 [RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent, 613 "Traceable Anonymous Certificate", RFC 5636, August 2009. 615 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 616 RFC 5652, September 2009. 618 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 619 Mail Extensions (S/MIME) Version 3.2 Message 620 Specification", RFC 5751, January 2010. 622 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 623 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 624 5996, September 2010. 626 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 627 Security Version 1.2", RFC 6347, January 2012. 629 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 630 Transport Security (HSTS)", RFC 6797, November 2012. 632 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 633 Infrastructure Certificate and Certificate Revocation List 634 (CRL) Profile", RFC 6818, January 2013. 636 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 637 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 638 April 1 2013. 640 [STRINT] "A W3C/IAB workshop on Strengthening the Internet Against 641 Pervasive Monitoring (STRINT)", March 2014, . 644 [merriam-webster] 645 "pseudonymity", March 2014, 646 . 648 [wikipedia] 649 "Opportunistic encryption", November 2013, 650 . 653 Author's Address 655 Stephen Kent 656 BBN Technologies 657 10 Moulton St. 658 Camridge, MA 02138 659 US 661 Email: kent@bbn.com