idnits 2.17.00 (12 Aug 2021) /tmp/idnits3063/draft-saintandre-tls-server-id-check-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 31, 2009) is 4645 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-avt-dtls-srtp has been published as RFC 5764 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2830 (ref. 'LDAP-TLS') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 4741 (ref. 'NETCONF') (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4742 (ref. 'NETCONF-SSH') (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 5539 (ref. 'NETCONF-TLS') (Obsoleted by RFC 7589) == Outdated reference: draft-ietf-sip-domain-certs has been published as RFC 5922 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) == Outdated reference: draft-ietf-xmpp-3920bis has been published as RFC 6120 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: Standards Track K. Zeilenga 5 Expires: March 4, 2010 Isode Limited 6 J. Hodges 7 PayPal 8 R. Morgan 9 Internet2 10 August 31, 2009 12 Server Identity Verification in Application Protocols 13 draft-saintandre-tls-server-id-check-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 4, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Technologies such as Transport Layer Security (TLS) and IPsec enable 52 a secure connection between two entities (a "client" and a "server") 53 using X.509 certificates. This document specifies recommended 54 procedures for checking the identity of the server in such an 55 interaction. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Comparison Rules . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.1. Domain Names . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.2. IP Addresses . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.3. Email Addresses . . . . . . . . . . . . . . . . . . . 7 67 3.2.4. SIP Addresses . . . . . . . . . . . . . . . . . . . . 8 68 3.2.5. JabberIDs . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 Technologies such as Transport Layer Security [TLS] and [IPSEC] 80 enable a secure connection between two entities using the Internet 81 X.509 Public Key Infrastructure (PKI) as described in [X509]. In 82 such interactions, the entity that initiates the connection is called 83 a "client" and the entity that receives the connection is called a 84 "server". 86 Note: The terms "client" and "server" as used here refer to 87 security roles, not application roles; a server in the context of 88 TLS or IPSec might be a "client" (i.e., a user agent) in the 89 context of an application protocol as deployed on the Internet. 91 If a client wishes to connect to a server securely, it needs to check 92 the identity of the server so that it can determine if the server is 93 what it claims to be, verify that there is no attacker in the middle, 94 etc. Typically this is done by correlating the information presented 95 in the server's certificate with information available about the 96 server contained in the Domain Name System (DNS). 98 Different application protocols that make use of the client-server 99 pattern for security purposes have traditionally specified their own 100 procedures for checking server identities. Examples include but are 101 not limited to: 103 o The Hypertext Transfer Protocol [HTTP], for which see also 104 [HTTP-TLS] 105 o The Internet Message Access Protocol [IMAP] and the Post Office 106 Protocol [POP3], for which see also [USINGTLS] 107 o The Lightweight Directory Access Protocol [LDAP], for which see 108 also [LDAP-AUTH] and its predecesor [LDAP-TLS] 109 o The NETCONF Configuration Protocol [NETCONF], for which see also 110 [NETCONF-SSH] and [NETCONF-TLS] 111 o The Network News Transfer Protocol [NNTP], for which see also 112 [NNTP-TLS] 113 o The Session Initiation Protocol [SIP], for which see also 114 [SIP-CERTS] 115 o The Simple Mail Transfer Protocol [SMTP], for which see also 116 [SMTP-AUTH] and [SMTP-TLS] 117 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] 118 o The Extensible Messaging and Presence Protocol [XMPP], for which 119 see also [XMPPBIS] 121 Unfortunately, this divergence of approaches has caused some 122 confusion among developers and protocol designers. Therefore this 123 document specifies recommended identity checking procedures for 124 application protocols produced within the Internet Standards Process, 125 for the purpose of codifying secure authentication practices. 127 Note: This document is currently limited in scope to the presentation 128 of identities in X.509 certificates as issued in the context of the 129 Public Key Infrastructure (PKI) and as applied to Transport Layer 130 Security [TLS]; a future version of this document might address X.509 131 certificates as issued outside the context of the PKI, non-X.509 132 public keys such as OpenPGP keys, presentation of identities in ways 133 other than in the certificate itself (e.g., certificate fingerprints 134 for Secure Shell as described in [SSH] or for Datagram Transport 135 Layer Security DTLS and Secure Real-time Transport Protocol as 136 described in [DTLS-SRTP]), and applications other than TLS. 138 2. Conventions 140 The following capitalized keywords are to be interpreted as described 141 in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 142 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 143 "OPTIONAL". 145 Most security-related terms are to be understood in the sense defined 146 in [SECTERMS]; such terms include, but are not limited to, 147 "assurance", "attack", "authentication", "authorization", 148 "certificate", "certification authority", "confidentiality", 149 "credential", "downgrade", "encryption", "fingerprint", "hash value", 150 "identity", "integrity", "signature", "security perimeter", "self- 151 signed certificate", "sign", "spoof", "tamper", "trust", "trust 152 anchor", "trust chain", "validate", "verify". 154 In addition, we define the following terms to assist in understanding 155 the process of verifying identity: 157 identity set: The set of identities that are presented by the server 158 to the client (in the form of the server's X.509 certificate) when 159 the client is attempts to establish a secure connection to the 160 server. 161 identity type: The "natural kind" of identity to which a presented 162 identity or reference identity belongs. For example, the 163 reference identity might be a domain name, an IPv4 or IPv6 164 address, an email address, a SIP address, a JabberID, or some 165 other type (this specification does not yet provide a complete 166 taxonomy of identity types). In the case of domain names, the 167 reference identity MUST NOT contain the wildcard character '*' 168 (ASCII 42) in the left-most (least significant) domain name 169 component or component fragment. 171 presented identity: A single member of the identity set. 172 reference identity: The client's conception of the server's identity 173 before it attempts to establish a secure connection to the server; 174 this is the identity that the client expects the server to present 175 and to which the client makes reference when attempting to verify 176 the server's identity. 178 3. Verification Process 180 When a client connects to a server, it MUST verify the server's 181 identity (in order to prevent passive and active attacks against the 182 connection). By "verify identity" we mean that the client needs to 183 establish that at least one of the identities in the identity set 184 matches the reference identity. 186 3.1. Overview 188 At a high level, the client verifies the server identity in 189 accordance with the following rules: 191 1. Before connecting to the server, the client determines the 192 identity type of the reference identity. 193 2. During the process of attempting to establish a secure 194 connection, the server MUST present its identity set to the 195 client in the form of an X.509 certificate [X509]. 196 3. Upon being presented with the server's identity set, the client 197 MUST check the reference identity against the presented 198 identities for the purpose of finding a match. To do so, the 199 client iterates through all of the subjectAltName extensions it 200 recognizes in the server's certificate (potentially in an 201 application-specific preference order) and compares the value of 202 each extension against the reference identity until it has either 203 produced a match or exhausted the identities in the identity set 204 (comparison rules for matching particular identity types are 205 provided under Section 3.2, including fallbacks to several 206 subjectName fields). 207 4. Before attempting to find a match in relation to a particular 208 presented identity, the client MAY map the reference identity to 209 a different identity type. Such a mapping MAY be performed for 210 any available subjectAltName type to which the reference identity 211 can be mapped; however, the reference identity SHOULD be mapped 212 only to types for which the mapping is either inherently secure 213 (e.g., extracting the DNS name from a URI to compare with a 214 subjectAltName of type dNSName) or for which the mapping is 215 performed in a secure manner (e.g., using DNSSEC, or using user- 216 configured or admin-configured host-to-address/address-to-host 217 lookup tables). 219 5. If the identity set has more than one member, a match with any of 220 the presented identities is acceptable. 222 Note: Beyond the server identity check described in this section, 223 clients might complete further checking to ensure that the server 224 is authorized to provide the service it is requested to provide. 225 The client might need to make use of local policy information in 226 making this determination. 228 3.2. Comparison Rules 230 3.2.1. Domain Names 232 If the reference identity is a domain name as defined by [RFC1034] 233 and [RFC1035] for "traditional" domain names or by [IDNA] for 234 internationalized domain names, then the client can match the 235 reference identity against subjectAltName extensions of type dNSName 236 and SRVName [SRVNAME] according to the following rules. 238 If the reference identity is a "traditional" domain name, then 239 matching of reference identity against the presented identity is 240 performed by comparing the set of domain components using a case- 241 insensitive ASCII comparison. 243 If the reference identity is an internationalized domain name, then 244 an implementation MUST convert the reference identity to the ASCII 245 Compatible Encoding (ACE) format as specified in Section 4 of [IDNA] 246 before comparison with subjectAltName values of type dNSName; 247 specifically, the conversion operation specified in Section 4 of 248 [IDNA] MUST be performed as follows: 250 o in step 1, the domain name SHALL be considered a "stored string" 251 o in step 3, set the flag called "UseSTD3ASCIIRules" 252 o in step 4, process each label with the "ToASCII" operation 253 o in step 5, change all label separators to U+002E (full stop) 255 After performing the "to-ASCII" conversion, the DNS labels and names 256 MUST be compared for equality according to the rules specified in 257 Section 3 of [IDNA]. 259 A dNSName MAY contain the wildcard character '*' (ASCII 42). The 260 wildcard character applies only to the left-most (least significant) 261 domain name component or component fragment and matches any single 262 component or component fragment. For instance, a dNSName of 263 *.example.com matches foo.example.com but not bar.foo.example.com or 264 example.com itself; similarly, a dNSName of baz*.example.net matches 265 baz1.example.net and baz2.example.net but not qux.example.net or 266 example.net itself. 268 In addition to checking the subjectAltName extensions of type dNSName 269 and SRVNAME, the client MAY as a fallback check the value of the 270 Common Name (CN) (see [LDAP-SCHEMA]) as presented in the subjectName 271 component of the server's X.509 certificate. In existing 272 certificates, the CN is often used for encapsulating a domain name; 273 for example, consider the following subjectName: 275 cn=www.example.com, ou=Web Services, c=GB 277 Here the Common Name is "www.example.com" and the client could choose 278 to compare the reference identity against that CN. 280 When comparing the referenced identity against the Common Name, the 281 client MUST follow the comparison rules described above for 282 subjectAltName extensions of type dNSName and SRVName, with the 283 exception that no wildcard matching is allowed. 285 In order to match domain names, a client MUST NOT check Relative 286 Distinguished Names (RDNs) other than the Common Name; in particular, 287 this means that a series of Domain Component (DC) attributes MUST NOT 288 be checked (because the order of Domain Components is not guaranteed, 289 certain attacks are possible if DC attributes are checked). 291 3.2.2. IP Addresses 293 If the reference identity is an IP address as defined by [IP] or 294 [IPv6], then the client can match the reference identity against 295 subjectAltName extensions of type iPaddress according to the 296 following rules. 298 The reference identity MUST be converted to the "network byte order" 299 octet string representation; for IP Version 4 the octet string will 300 contain exactly four octets, and for IP Version 6 the octet string 301 will contain exactly sixteen octets. The client then compares this 302 octet string, where a match occurs if the reference identity and 303 presented identity octet strings are identical. 305 3.2.3. Email Addresses 307 If the reference identity is an email address as defined by [EMAIL], 308 then the client SHOULD compare the reference identity against the 309 value of the "rfc822Name" subjectAltName extension described in 310 [X509]. 312 The client MAY also compare the reference identity against the value 313 of the "E" attribute of the subjectName as described in [CRMF]. 315 3.2.4. SIP Addresses 317 If the reference identity is a SIP address as defined by [SIP], then 318 the client SHOULD compare map the reference identity to a domain name 319 or email address and proceed as described for those identity types, 320 or proceed as described in [SIP-CERTS]. 322 3.2.5. JabberIDs 324 If the reference identity is a JabberID as defined by [XMPP], then 325 the client SHOULD compare the reference identity against the value of 326 the "id-on-xmppAddr" subjectAltName extension of type otherName 327 described in [XMPP], or proceed as described in [XMPPBIS]. 329 3.3. Outcome 331 The outcome of the checking procedure is one of the following: 333 Case #1: The client finds at least one presented identity that 334 matches the reference identity; the entity MUST use this as the 335 validated identity of the server. 336 Case #2: The client finds no subjectAltName that matches the 337 reference identity but a human user has permanently accepted the 338 certificate during a previous connection attempt; the client MUST 339 verify that the cached certificate was presented and MUST notify 340 the user if the certificate has changed since the last time that a 341 secure connection was successfully negotiated. 342 Case #3: The client finds no subjectAltName that matches the 343 reference identity and a human user has not permanently accepted 344 the certificate during a previous connection attempt; the client 345 MUST NOT use the presented identity (if any) as the validated 346 identity of the server and instead MUST proceed as described in 347 the next section. Instead, if the client is a user-oriented 348 application, then it MUST either (1) automatically terminate the 349 connection with a bad certificate error or (2) show the 350 certificate (including the entire certificate chain) to the user 351 and give the user the choice of terminating the connecting or 352 accepting the certificate temporarily (i.e., for this connection 353 attempt only) or permanently (i.e., for all future connection 354 attempts) and then continuing with the connection; if a user 355 permanently accepts a certificate in this way, the client MUST 356 cache the certificate (or some non-forgeable representation such 357 as a hash value) and in future connection attempts behave as in 358 Case #2. (It is the resposibility of the human user to verify the 359 hash value or fingerprint of the certificate with the peer over a 360 trusted communication layer.) If the client is an automated 361 application, then it SHOULD terminate the connection with a bad 362 certificate error and log the error to an appropriate audit log; 363 an automated application MAY provide a configuration setting that 364 disables this check, but MUST provide a setting that enables the 365 check. 367 4. Security Considerations 369 To follow. 371 5. IANA Considerations 373 This document has no actions for the IANA. 375 6. References 377 6.1. Normative References 379 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 380 "Internationalizing Domain Names in Applications (IDNA)", 381 RFC 3490, March 2003. 383 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 384 September 1981. 386 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 387 (IPv6) Specification", RFC 2460, December 1998. 389 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 393 Housley, R., and W. Polk, "Internet X.509 Public Key 394 Infrastructure Certificate and Certificate Revocation List 395 (CRL) Profile", RFC 5280, May 2008. 397 6.2. Informative References 399 [CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure 400 Certificate Request Message Format (CRMF)", RFC 4211, 401 September 2005. 403 [DTLS-SRTP] 404 McGrew, D. and E. Rescorla, "Datagram Transport Layer 405 Security (DTLS) Extension to Establish Keys for Secure 406 Real-time Transport Protocol (SRTP)", 407 draft-ietf-avt-dtls-srtp-07 (work in progress), 408 February 2009. 410 [EMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 411 October 2008. 413 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 414 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 415 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 417 [HTTP-TLS] 418 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 420 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 421 4rev1", RFC 3501, March 2003. 423 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 424 Internet Protocol", RFC 4301, December 2005. 426 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 427 (LDAP): The Protocol", RFC 4511, June 2006. 429 [LDAP-AUTH] 430 Harrison, R., "Lightweight Directory Access Protocol 431 (LDAP): Authentication Methods and Security Mechanisms", 432 RFC 4513, June 2006. 434 [LDAP-SCHEMA] 435 Sciberras, A., "Lightweight Directory Access Protocol 436 (LDAP): Schema for User Applications", RFC 4519, 437 June 2006. 439 [LDAP-TLS] 440 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 441 Directory Access Protocol (v3): Extension for Transport 442 Layer Security", RFC 2830, May 2000. 444 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 445 December 2006. 447 [NETCONF-SSH] 448 Wasserman, M. and T. Goddard, "Using the NETCONF 449 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 450 December 2006. 452 [NETCONF-TLS] 453 Badra, M., "NETCONF over Transport Layer Security (TLS)", 454 RFC 5539, May 2009. 456 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 457 RFC 3977, October 2006. 459 [NNTP-TLS] 460 Murchison, K., Vinocur, J., and C. Newman, "Using 461 Transport Layer Security (TLS) with Network News Transfer 462 Protocol (NNTP)", RFC 4642, October 2006. 464 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 465 STD 53, RFC 1939, May 1996. 467 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 468 STD 13, RFC 1034, November 1987. 470 [RFC1035] Mockapetris, P., "Domain names - implementation and 471 specification", STD 13, RFC 1035, November 1987. 473 [SECTERMS] 474 Shirey, R., "Internet Security Glossary, Version 2", 475 RFC 4949, August 2007. 477 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 478 A., Peterson, J., Sparks, R., Handley, M., and E. 479 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 480 June 2002. 482 [SIP-CERTS] 483 Gurbani, V., Lawrence, S., and B. Laboratories, "Domain 484 Certificates in the Session Initiation Protocol (SIP)", 485 draft-ietf-sip-domain-certs-04 (work in progress), 486 May 2009. 488 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 489 October 2008. 491 [SMTP-AUTH] 492 Siemborski, R. and A. Melnikov, "SMTP Service Extension 493 for Authentication", RFC 4954, July 2007. 495 [SMTP-TLS] 496 Hoffman, P., "SMTP Service Extension for Secure SMTP over 497 Transport Layer Security", RFC 3207, February 2002. 499 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 500 Subject Alternative Name for Expression of Service Name", 501 RFC 4985, August 2007. 503 [SSH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 504 Protocol Architecture", RFC 4251, January 2006. 506 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 508 [SYSLOG-TLS] 509 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 510 Security (TLS) Transport Mapping for Syslog", RFC 5425, 511 March 2009. 513 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 514 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 516 [USINGTLS] 517 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 518 RFC 2595, June 1999. 520 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 521 Protocol (XMPP): Core", RFC 3920, October 2004. 523 [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence 524 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-01 (work 525 in progress), August 2009. 527 Authors' Addresses 529 Peter Saint-Andre 530 Cisco 532 Email: psaintan@cisco.com 534 Kurt D. Zeilenga 535 Isode Limited 537 Email: Kurt.Zeilenga@Isode.COM 539 Jeff Hodges 540 PayPal 542 Email: Jeff.Hodges@KingsMountain.com 543 RL 'Bob' Morgan 544 UWashington/Internet2 546 Email: rlmorgan@washington.edu