idnits 2.17.00 (12 Aug 2021) /tmp/idnits36901/draft-hudson-impp-security-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 378 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** There are 99 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2778]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 2778' on line 364 looks like a reference -- Missing reference section? 'RFC 2782' on line 55 looks like a reference -- Missing reference section? 'RFC 2779' on line 368 looks like a reference -- Missing reference section? 'RFC 2222' on line 344 looks like a reference -- Missing reference section? 'RFC 2478' on line 352 looks like a reference -- Missing reference section? 'RFC 2065' on line 340 looks like a reference -- Missing reference section? 'RFC 2631' on line 356 looks like a reference -- Missing reference section? 'RFC 2246' on line 348 looks like a reference -- Missing reference section? 'RFC 2015' on line 336 looks like a reference -- Missing reference section? 'RFC 2633' on line 360 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Greg Hudson 2 Expires: November 21, 2000 ghudson@mit.edu 3 MIT 5 Security in the Instant Message and Presence Protocols 6 draft-hudson-impp-security-00.txt 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 2. Abstract 30 This document describes the security issues and options associated 31 with instant messaging and transmission of presence as they are being 32 considered in the IMPP working group. 34 This document uses many terms described in [RFC 2778], which describes 35 a model for instant messaging. 37 3. IMPP architecture and payload characterization 39 The architecture favored by the IMPP working group involves two 40 different kinds of network elements, clients and servers. Clients 41 represent IMPP entities (senders, instant inboxes, presentities, or 42 watcher), and only speak to the server of their home domain. Servers 43 communicate with each other in order to carry out presence operations. 45 A server may choose to communicate with entities other than IMPP 46 clients; in this case, the server is called a gateway. For instance, 47 MIT might set up a server which appears to be an IMPP server to other 48 servers, but which communicates with Zephyr clients instead of 49 standard IMPP clients. 51 A server may choose to communicate with "clients" only on the local 52 host, without using the standard protocol, or with only one "client" 53 built into the server program. 55 Servers for a domain are located using a SRV [RFC 2782] lookup in the 56 DNS, similar to how email servers for a domain are located using an MX 57 lookup. Also as with email, there is a fallback to an A record lookup 58 if no SRV record exists. 60 Compared to email, IMPP traffic is expected to be characterized by 61 larger numbers of smaller messages. Currently, a heavy email user 62 subscribed to many email lists might receive a few hundred messages in 63 a day, while a user of many instant messaging "chat rooms" or IRC 64 channels might receive a few hundred messages in an hour or less. 66 The forms of the IMPP transfer protocols are not finalized. This 67 document will be written assuming that the transfer protocols between 68 clients and servers and between servers and servers use long-lived TCP 69 connections. 71 4. Goals 73 The security goals of the IMPP system are presented in [RFC 2779]. 74 They can be summarized as follows: 76 * Secrecy: Eavesdroppers should not be able to read message 77 content. Ideally, they should not be able to do traffic 78 analysis either, beyond watching where the actual IP packets 79 go. 81 * Authentication and integrity: It should be difficult to 82 forge IMPP operations or modify them in transit. 84 5. General methods 86 Security goals can be achieved in one of two general ways: 88 1. Data can be authenticated or encrypted at the level of the 89 transfer protocol or, equivalently, at the level of the 90 underlying transport protocol (e.g. using TLS or IPsec). 91 This method requires the communicating parties to trust the 92 intermediary servers to do their job properly. 94 2. Data can be authenticated and/or encrypted from the sender 95 to the receiver, even though they do not enjoy a direct 96 connection. This method does not require the communicating 97 parties to trust any intermediaries, but does require them 98 to agree on a security mechanism and key management 99 structure. 101 Of course, these two methods can be layered together for added 102 protection. And it is possible to mix the two methods; for instance, 103 presence information might be authenticated from a presence service to 104 a watcher, which would require the presentity's server to be trusted 105 but not the watcher's. 107 6. Secrecy 109 Preventing passive eavesdroppers from reading traffic, including 110 headers, is relatively easy. At the beginning of each transfer 111 connection, the two parties can conduct an anonymous Diffie-Hellman 112 key exchange and encrypt the transfer stream using a symmetric 113 algorithm. This scheme requires no infrastructure and would prevent 114 passive eavesdroppers from reading traffic, but a man-in-the-middle 115 attacker can defeat this scheme while remaining invisible to the two 116 parties. Also, there is currently no standardized protocol method 117 that I know of for doing anonymous Diffie-Hellman key exchange, 118 selecting symmetric encryption algorithms, and deriving keys. 120 Secrecy of IM and presence payloads can also be achieved in an 121 end-to-end manner if the sender can obtain the a public key for the 122 receiver or can somehow negotiate a shared secret with the receiver. 123 This category of method requires infrastructure, of course, and does 124 not prevent attackers from doing traffic analysis. 126 7. Authentication 128 Authentication is a fundamentally more difficult problem than secrecy. 129 Authentication between two unfamiliar parties cannot be achieved 130 without some kind of infrastructure, and authentication 131 infrastructures are inherently limited in strength. In considering 132 the options below, note that each option proves something slightly 133 different about the sender. 135 7.1. Transfer-level or transport-level authentication 137 Authentication at the transfer protocol or transport protocol level 138 has some attractive properties: 140 * Assuming the transfer protocol uses long-lived TCP 141 connections, security associations can be set up at the 142 beginning of a connection and efficient symmetric protocols 143 can be used to encrypt and integrity-protect traffic. 145 * Proper authentication at the transfer level can allow 146 improved secrecy, preventing even man-in-the-middle 147 attackers from eavesdropping or performing traffic analysis. 149 * Domains can reuse their existing security infrastructure to 150 authenticate clients. 152 Between a client and its home server, authentication is essentially a 153 solved problem. Either SASL [RFC 2222] or SPNEG0 [RFC 2478] allow 154 clients to use a variety of methods of varying strengths to 155 authenticate to a server and to protect traffic. Server operators can 156 decide what sorts of authentication they will allow from clients. 158 Between servers for two domains, however, the problem is harder. 159 Although SASL or SPNEG0 can be used between domains, most of the 160 existing mechanisms within those frameworks are not as useful between 161 domains, and the problem of configuring a minimum security level 162 between domains is essentially unsolvable without help from the 163 protocol specification. 165 Following are descriptions of two possible options for transfer-level 166 authentication between domains. Neither is particularly optimal. 168 7.1.1. Using DNS KEY records for inter-domain authentication 170 If we wish to authenticate that a server is properly representing the 171 DNS domain it claims to be representing, then it would make some 172 amount of sense to use the DNS as the authority for keys. The secure 173 DNS specification [RFC 2065] envisions that DNS might be used to store 174 public keys for application protocols. Ideally these keys would be 175 signed to protect against DNS spoofing attacks. Public keys in the 176 DNS could be used in a variety of ways for authenticating domains; one 177 option would be authenticated Diffie-Hellman key agreement as 178 described in [RFC 2631]. 180 This scheme has some nice properties: 182 * Because servers look up each others' key records in the DNS, 183 and because DNS records usually expire after a relatively 184 short time period, there is no certificate revocation 185 problem, and key roll-over is possible by including multiple 186 keys in the RRset. 188 * Because servers look up each others' key records in the DNS, 189 this mechanism can be made optional without allowing an 190 attacker to spoof a domain by claiming that the domain does 191 not support security. If a domain has a public key for IMPP 192 in the DNS, then it would not be allowed to authenticate to 193 another secure domain without the private key. 195 * Even in the absence of signed key records, an attacker would 196 have to perform a DNS spoofing attack to forge a request. 197 This would be considerably better than email, where forging 198 email is as trivial as lying about the from address. 200 * Because the same authority is used for keys as for server 201 lookup, there is no concern that a certification authority 202 separate from the relevant DNS authorities might be issuing 203 certificates to parties other than the authorized domain 204 administrators. 206 However, there are some important disadvantages to this scheme: 208 * Secure DNS is essentially vapor at the current time. Some 209 implementations exist, but we have essentially no 210 operational experience with it. 212 * Upon receiving a connection and an authentication request, a 213 server would have to go out and perform a DNS query to get 214 the public key for the domain the connection initiator 215 claims to be. This may not be a real problem, since server 216 implementations already have to perform DNS queries to 217 initiate connections to other domains. 219 * There is no standard mechanism for authenticating domains 220 using public keys stored in the DNS; a new one would have to 221 be invented. 223 7.1.2. Using TLS and X.509 certificates for inter-domain authentication 225 TLS [RFC 2246] describes a transport-layer security protocol using 226 X.509 certificates. This approach is currently in wide use for 227 securely authenticating World Wide Web sites to web users and for 228 protecting traffic (especially for passwords and/or credit card 229 information used in web commerce). TLS could be used for mutual 230 authentication between domains, since it allows for certificates to be 231 passed in both directions. 233 The advantages of this scheme are obvious: it is an existing standard 234 with significant deployment experience (although most of it with 235 certificates only going in one direction) with existing publicly 236 available implementations. However, it poses the following problems: 238 * Certificates typically expire after a long period of time, 239 much longer than a typical DNS expiry time. If a private 240 key is compromised, TLS provides no mechanism for revoking 241 the corresponding certificate. 243 * Domains would provide each other with the entire certificate 244 chain leading up to the CA as part of the transfer 245 connection; servers do not and cannot look up certificates 246 in any outside directory. This is potentially convenient 247 for the server implementors, but means there is no way to 248 look up whether a domain supports security or not. So if 249 the TLS mechanism is optional, a domain has no way of 250 knowing whether to trust another party's assertion that they 251 represent a domain which does not employ the mechanism. 253 * Although TLS allows the receiving party to specify to the 254 initiating party which certification authorities it 255 respects, it does not allow the initiating party to 256 specify that information to the receiving party. So a 257 server with certificate chains leading to two different CAs 258 does not know which certificate chain to present upon 259 receiving a connection from another server. 261 * A certificate chain leads to a certification authority which 262 may not be the same as the authority which controls the root 263 DNS zone. The risk exists that a certification authority 264 might hand out certificates to parties other than authorized 265 domain owners. 267 7.2. End to end authentication 269 End to end authentication has some nice properties relative to 270 transfer-level or transport-level authentication: 272 * The parties involved do not have to trust the servers 273 between them. 275 * You can use end to end authentication to authenticate facts 276 other than authorized use of a particular IMPP identifier. 277 Two familiar parties can use manually exchanged keys to 278 authenticate their actual identities. Similarly, two 279 previous unfamiliar parties can exchange keys and use 280 them to authenticate the fact that they are the same two 281 parties conversing over a long period of time, even if 282 neither of them is certain of who the other one is. 284 * Servers don't have to do any work to support end to end 285 authentication between users; the computational work is 286 pushed out to the edges. This is good for traditional 287 Internet deployments involving powerful client machines, 288 although it poses problems for battery-operated wireless 289 clients. 291 Unlike transfer-level or transport-level authentication, end to end 292 authentication cannot be leveraged to protect against traffic analysis 293 (although it can be leveraged to protect against eavesdropping of IM 294 and presence payloads), and it does not allow administrative domains 295 to reuse their existing key security infrastructure if it does not 296 happen to gel with the end to end security mechanism in use. Finally, 297 end-to-end authentication does not apply (or at least applies 298 differently) to requests between users and servers, such as for a 299 presentity's request to change its presence information. 301 7.2.1. End to end authentication using existing MIME-based mechanisms 303 PGP/MIME [RFC 2015] and S/MIME [RFC 2633] are existing methods for 304 authenticating MIME payloads. They are designed for mail, a 305 non-interactive medium characterized by larger, less frequent 306 payloads, and may not perform adequately for large, smaller payloads. 307 The bandwidth overhead imposed by PGP or S/MIME signatures may be 308 unacceptable for one-line messages, and the computation overhead of 309 doing a public key operation for each instant message may be 310 unacceptable for battery-powered devices. However, they are existing 311 standards with available implementations. 313 7.2.2. End to end authentication using new mechanisms 315 A new, more interactive MIME-based mechanism could be designed in 316 order to reduce the bandwidth and computation overheads of PGP/MIME 317 and S/MIME. For instance, two parties communicating secretly over 318 many messages could establish a shared secret in the first message, 319 and then use efficient symmetric algorithms to protect the remaining 320 messages. 322 A mechanism along these lines could help enormously for users 323 participating in IM redistribution lists or "chat rooms," but only if 324 the redistribution list is considered an "end" and is trusted to 325 properly represent the identities of users who send through it. In 326 the absence of such trust, it is difficult to do better than one 327 public key operation per message for a redistribution list scenario. 329 8. Conclusions 331 Security in the IMPP area is a difficult problem, and none of the 332 solutions presented above is very satisfactory, at least by itself. 334 10. References 336 [RFC 2015] 337 M. Elkins. "MIME Security with Pretty Good Privacy (PGP)". RFC 2015, 338 October 1996. 340 [RFC 2065] 341 D. Eastlake, 3rd, C. Kaufman. "Domain Name System Security 342 Extensions." RFC 2065, January 1997. 344 [RFC 2222] 345 J. Myers. "Simple Authentication and Security Layer (SASL)." RFC 346 2222, October 1997. 348 [RFC 2246] 349 T. Dierks, C. Allen. "The TLS Protocol Version 1.0." RFC 2246, 350 January 1999. 352 [RFC 2478] 353 E. Baize, D. Pinkas. "The Simple and Protected GSS-API Negotiation 354 Mechanism." RFC 2478, December 1998. 356 [RFC 2631] 357 E. Rescorla. "Diffie-Hellman Key Agreement Method. E. Rescorla." RFC 358 2631, June 1999. 360 [RFC 2633] 361 B. Ramsdell, Ed.. "S/MIME Version 3 Message Specification." RFC 362 2633, June 1999. 364 [RFC 2778] 365 M. Day, J. Rosenberg, H.Sugano. "A model for Presence and Instant 366 Messaging." RFC 2778, February 2000. 368 [RFC 2779] 369 M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Messaging / 370 Presence Protocol Requirements." 372 11. Author's address 374 Greg Hudson 375 Massachusetts Institute of Technology 376 Cambridge, MA 02139 377 ghudson@mit.edu