idnits 2.17.1 draft-meyer-xmpp-sasl-cert-management-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 : ---------------------------------------------------------------------------- ** 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.) 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 (March 8, 2009) is 5528 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 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' == Outdated reference: A later version (-02) exists of draft-meyer-xmpp-e2e-encryption-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Meyer 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track P. Saint-Andre 5 Expires: September 9, 2009 Cisco 6 March 8, 2009 8 Management and Use of Client Certificates for the Extensible Messaging 9 and Presence Protocol (XMPP) 10 draft-meyer-xmpp-sasl-cert-management-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 9, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines methods for managing and using client 49 certificates in the Extensible Messaging and Presence Protocol 50 (XMPP). These methods, which make use of the EXTERNAL mechanism of 51 the Simple Authentication and Security Layer (SASL) protocol, enable 52 an XMPP client to log in to an XMPP server without providing a 53 password. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. First Login . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Certificate Generation . . . . . . . . . . . . . . . . . . . . 4 60 4. Uploading a Certificate . . . . . . . . . . . . . . . . . . . 4 61 5. Subsequent Login via SASL EXTERNAL . . . . . . . . . . . . . . 6 62 6. Requesting the List of Certificates . . . . . . . . . . . . . 10 63 7. Removing a Certificate . . . . . . . . . . . . . . . . . . . . 10 64 8. Revoking a Certificate . . . . . . . . . . . . . . . . . . . . 11 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 9.1. Certificate Policies . . . . . . . . . . . . . . . . . . . 11 67 9.2. Stream Characteristics . . . . . . . . . . . . . . . . . . 12 68 9.3. Check subjectAltName . . . . . . . . . . . . . . . . . . . 12 69 9.4. Changing the Password . . . . . . . . . . . . . . . . . . 12 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 13 74 Appendix B. Copying Conditions . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 An XMPP client typically needs a user name and a password to log in 80 to an XMPP server. Many clients provide a mechanism to store these 81 credentials so that a human user can automatically log in without 82 being prompted for the password. While this practice is very user 83 friendly, it can be a security risk, especially for some devices. 84 Mobile devices like a mobile phone or a laptop might get stolen, 85 providing the thief with the required password. Mobile phones are 86 particularly insecure: providing the password on the keypad for each 87 login is too complicated and the risk of losing the phone is high. 89 A solution to this problem is to allow a client to log in without 90 knowing the password. XMPP as specified in [rfc3920bis] allows the 91 use of any Simple Authentication and Security Layer [SASL] mechanism 92 in the authentication of XMPP entities, including the SASL EXTERNAL 93 mechanism. Therefore this document defines two methods that will 94 enable password-free login for XMPP clients: 96 o How a client generates an X.509 certificate [X509], manages the 97 list of client certificates, and informs the server of its 98 authorized certificates. 99 o How a client presents a certificate during the Transport Layer 100 Security [TLS] handshake and refers to it during SASL negotiation 101 using the EXTERNAL mechanism. 103 The overall process is as follows: 105 1. Client logs in to server using standard password-based 106 authentication methods (or a previously authorized certificate). 107 2. Client generates or obtains a certificate. 108 3. Client informs server of the certificate. 109 4. On subsequent login attempts, client can use the authorized 110 certificate. 112 The client can also retrieve the list of authorized certificates, 113 remove a certificate, or revoke a certificate. 115 These use cases are explained in the following sections. 117 Note: The following capitalized keywords are to be interpreted as 118 described in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL 119 NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; 120 "MAY", "OPTIONAL". 122 2. First Login 124 On first login, the client has not yet authorized a certificate and 125 therefore cannot use SASL EXTERNAL to authenticate. (There is a 126 possible exception if the client already has a valid certificate 127 issued by a certificate authority ("CA") that is recognized by the 128 server, but we ignore that case here because it is relatively rare.) 129 Therefore the client would authenticate using standard XMPP methods 130 as described in [rfc3920bis]. If the client will attempt to upload 131 and authorize a certificate for subsequent login attempts, it MUST 132 protect the client-to-server stream using channel encryption via 133 Transport Layer Security [TLS] as described in [rfc3920bis]. 135 3. Certificate Generation 137 In order to upload and authorize a certificate, the client needs to 138 generate or obtain a certificate. Here we assume that the client 139 generates a self-signed certificate since this is also a requirement 140 of [XTLS]; however, it is also possible for the client to obtain a 141 CA-issued certificate. The client certificate MUST include a JID as 142 described in section 15.2.1.2 of [rfc3920bis], where the JID will be 143 represented as an XmppAddr. The JID can be either a bare JID of the 144 form "user@domain.tld" or a full JID of the form 145 "user@domain.tld/resource". 147 subjectAltName=otherName:id-on-xmppAddr;UTF8:hamlet@example.com 149 4. Uploading a Certificate 151 After the client has logged in and generated a certificate, it shall 152 upload the certificate to its XMPP server. This is done by sending 153 an XMPP IQ stanza of type "set" containing an element 154 qualified by the 'urn:xmpp:saslcert:0' namespace; this element in 155 turn MUST contain at least one element, which in turn MUST 156 contain a child element and SHOULD contain a 157 child element. The XML character of the element is 158 the X.509 certificate in DER encoding, Base64-encoded as specified in 159 Section 4 of [RFC4648] for sending over the XML stream. The XML 160 character data of the element is a human-readable name for 161 the certificate (thus making it easier for a human user to manage the 162 different certificates); the name does not have to be unique, since 163 the certificate's fingerprint provides a truly unique identifier. A 164 client can upload multiple certificates with each certificate defined 165 in one individual element. 167 170 171 172 Mobile Client 173 174 MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV 175 BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV 176 BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p 177 RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t 178 qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D 179 hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx 180 YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk 181 EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG 182 SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp 183 ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK 184 QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8 185 186 187 188 190 If the server can process the certificate, it returns an empty IQ 191 result. 193 197 (Error cases will be described in a future version of this 198 specification, although the normal XMPP stanza errors apply.) 200 Once the server has accepted the certificate, a client can use that 201 certificate to authenticate the user using SASL EXTERNAL on 202 subsequent logins. Therefore the client MUST NOT store the password 203 for subsequent login attempts. 205 The client that uploads the certificate does not need to be the 206 client that subsequently uses the certificate. For example, a user 207 might use a full-featured client to upload a certificate for 208 subsequent use by a "bot" (e.g., an automated service or a device 209 such as a set-top box). The bot creates its certificate and private 210 key, and the user uploads the certificate to the server with a 211 different client. After that procedure the bot can log in to the 212 server and even participate in secure end-to-end communication 213 without ever knowing the user's password. 215 An optional element inside the element 216 indicates that a client logged in with that certificate is not 217 allowed to add or remove certificates from the list. A server MAY 218 allow such a client to query the list of certificates. 220 223 224 225 Simple Bot 226 227 228 Certificate-in-DER-format-Base64-encoded 229 230 231 232 234 5. Subsequent Login via SASL EXTERNAL 236 The RECOMMENDED protocol flow for client-to-server use of SASL 237 EXTERNAL with end-user certificates is as follows: 239 1. Client initiates stream to the server. 241 247 2. Server replies with stream header. 249 256 3. Server advertises TLS stream feature. 258 259 260 261 263 265 4. Client sends STARTTLS command to the server. 267 269 5. Server tells the client to proceed. 271 273 6. During TLS handshake, the server requests a certificate and the 274 client presents its certificate. 275 7. TLS negotiation completes successfully. 276 8. Client initiates a new stream header to the server. 278 284 9. Server replies with stream header. 286 293 10. Server advertises SASL mechanisms. If the server expects that 294 the client will be able to authenticate and authorize as the 295 identity provided in the presented certificate, then the server 296 SHOULD advertise the SASL EXTERNAL mechanism; otherwise, if 297 presented certificate is unacceptable (e.g., because the 298 certificate is expired, not yet valid, or revoked), the server 299 MUST NOT offer the EXTERNAL mechanism. 301 302 303 EXTERNAL 304 DIGEST-MD5 305 ANONYMOUS 306 307 308 310 11. Because the client presented a certificate, it SHOULD consider 311 EXTERNAL to be its preferred SASL mechanism. If the client 312 certificate includes only one XMPP address and the user wishes 313 to authorize as the identity that has been authenticated by the 314 TLS layer (i.e., the XMPP address that is contained in the 315 client certificate), then the client SHOULD NOT include an 316 authorization identity (i.e., the XML character data for the 317 element SHOULD be "=", indicating an empty response); if 318 the client certificate contains more than one XMPP address or if 319 the user wishes to authorize as another identity, then the 320 client MUST include an authorization identity; if the client 321 certificate contain no XMPP address, then the client SHOULD 322 include an authorization identity (but MAY omit the 323 authorization identity if it does not know its identity, instead 324 having it assigned by the server). 326 = 329 12. Server determines whether to allow authentication and 330 authorization of user. 331 1. If (1) the certificate presented by the client contains only 332 one valid XMPP address that corresponds to a registered 333 account on the server and (2) the client did not pass an 334 authorization identity in the SASL exchange, then the server 335 SHOULD allow authentication and authorization of that JID. 336 For the purpose of client authentication and authorization 337 with a server, a valid XMPP address is a JID encapsulated as 338 a subjectAltName entity of type otherName with an ASN.1 339 Object Identifier of "id-on-xmppAddr" as specified in 340 Section 15.2.1.3 of [rfc3920bis]. 342 344 2. If the certificate contains more than one valid XMPP address 345 that corresponds to a registered account on the server 346 (e.g., because the server offers virtual hosting), then the 347 server SHOULD allow authentication and authorization of the 348 JID specified as the authorization identity. 350 352 3. If no authorization identity is included, then the server 353 MUST return a SASL failure case of and 354 close the stream. 356 357 358 359 361 4. If the certificate does not contain an XMPP address, then 362 the server MAY attempt to determine if there is a registered 363 account associated with the user, for example by performing 364 an LDAP lookup based on the Common Name in the certificate; 365 if such a JID mapping is successful and the mapped JID 366 matches the authorization identity provided, then the server 367 SHOULD allow authentication and authorization of that mapped 368 JID. 370 372 5. If JID mapping is unsuccessful, then the server MUST return 373 a SASL failure case of and close the 374 stream. 376 377 378 379 381 6. If JID mapping is successful but the mapped JID does not 382 match the authorization identity provided (if any), then the 383 server MUST return a SASL failure case of 384 and close the stream. 386 387 388 389 391 13. If SASL authentication succeeded, the client opens a new stream, 392 then the client and server proceed with resource binding as 393 described in [rfc3920bis]. If the XmppAddr in the certificate 394 is a full JID then the server MUST force the client to use the 395 defined resource during resource binding. The client is only 396 allowed to use the provided resource name. If a client with the 397 same resource name is currently logged in and that client is not 398 forced to use the specified resource name, it SHOULD be logged 399 out by the server. 401 6. Requesting the List of Certificates 403 A client can request the list of all certificates that are authorized 404 to authenticate for its bare JID using SASL EXTERNAL. This is done 405 by sending an XMPP IQ stanza of type "get" containing a 406 element qualified by the 'urn:xmpp:saslcert:0' namespace. 408 411 412 414 The server then returns the list of all known certificates, including 415 the provided name. Each certificate is contained in a separate 416 element and uniquely identified by the value of the 'id' 417 attribute. In the following example the 'id' is the SHA1 value in 418 hex of the certificate. The 'id' is used for the client to remove or 419 revoke a certificate. 421 424 425 426 Mobile Client 427 428 Certificate-in-DER-format-Base64-encoded 429 430 431 432 Simple Bot 433 434 435 Certificate-in-DER-format-Base64-encoded 436 437 438 439 441 7. Removing a Certificate 443 A client needs to create a new certificate before its current one 444 expires. After the new certificate is uploaded to the server, it 445 might want to remove the old certificate to keep the list of 446 certificates short (otherwise the list will grow indefinitely, making 447 certificate handling more difficult for the user). The client 448 removes a certificate by sending an XMPP IQ stanza of type "set" 449 containing a element that in turn contains an empty 450 whose 'id' attribute uniquely identifies the certificate as retrieved 451 from the server with the IQ stanza. Similar to the upload 452 procedure a client can remove multiple certificates by adding more 453 than one element. 455 458 459 460 461 463 Once a certificate has been removed it can no longer be used for SASL 464 EXTERNAL. A server MAY automatically remove expired certificates 465 from the list. 467 8. Revoking a Certificate 469 The user can revoke a certificate for a stolen or compromised device. 470 The mechanism is similar to removing a certificate. The difference 471 is that if a client is logged in with the compromised certificate 472 using SASL EXTERNAL, the server SHOULD close the stream to that 473 client thus forcing that client to log out. The client revokes a 474 certificate by sending an XMPP IQ stanza of type "set" containing a 475 element that in turn contains an empty whose 'id' 476 attribute uniquely identified the certificate. 478 481 482 483 484 486 9. Security Considerations 488 9.1. Certificate Policies 490 This specification defines a method whereby a user can authorize 491 self-signed certificates for login. In accordance with local 492 security policies, a given XMPP deployment can refuse to support this 493 feature, can allow only clients that have authenticated with CA- 494 issued certificates to upload self-signed certificates, can accept 495 self-signed certificates only for full JIDs, etc. 497 9.2. Stream Characteristics 499 This specification allows the user to manipulate an alternative way 500 to log into the server. The certificates are not required to be 501 signed and any certificate can be used. Therefore the server MUST 502 reject any communication described in this document if the link 503 between client and server is not secured with both STARTTLS and SASL. 505 9.3. Check subjectAltName 507 The server MUST check if the JID in the subjectAltName of the 508 certificate matches the bare JID of the user. A user MUST NOT be 509 allowed to upload certificates for a different user. 511 9.4. Changing the Password 513 [XEP-0077] defines a mechanism to change the password without knowing 514 the current one. If the server supports password change it MUST 515 return not-authorized for clients logged in using SASL EXTERNAL and 516 MAY include a password change form requiring the old password. If 517 the client has logged in with the current password, the server MAY 518 change the password without a form as specified in XEP-0077. 520 If a client is allowed to change the password without knowing the 521 current password, the additional security provided by this document 522 is compromised. 524 10. References 526 10.1. Normative References 528 [rfc3920bis] 529 Saint-Andre, P., "Extensible Messaging and Presence 530 Protocol (XMPP): Core", draft-saintandre-rfc3920bis-09 531 (work in progress), March 2009. 533 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 534 Encodings", RFC 4648, October 2006. 536 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 537 Security Layer (SASL)", RFC 4422, June 2006. 539 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 543 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 545 [X509] "ITU-T Recommendation X.509 (1997 E): Information 546 Technology - Open Systems Interconnection - The Directory: 547 Authentication Framework", June 1997. 549 10.2. Informative References 551 [XEP-0077] 552 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 553 January 2006. 555 [XTLS] Meyer, D. and P. Saint-Andre, "Extensible Messaging and 556 Presence Protocol (XMPP) End-to-End Encryption Using 557 Transport Layer Security ("XTLS")", 558 draft-meyer-xmpp-e2e-encryption-01 (work in progress), 559 March 2009. 561 Appendix A. XML Schema 563 The following schema is not normative. 565 567 573 574 575 576 580 581 582 584 585 586 587 591 592 593 595 596 597 598 602 603 604 606 607 608 609 613 614 615 617 618 619 623 627 631 632 633 635 636 637 638 639 641 643 Appendix B. Copying Conditions 645 Regarding this entire document or any portion of it, the authors make 646 no guarantees and are not responsible for any damage resulting from 647 its use. The authors grant irrevocable permission to anyone to use, 648 modify, and distribute it in any way that does not diminish the 649 rights of anyone else to use, modify, and distribute it, provided 650 that redistributed derivative works do not contain misleading author 651 or version information. Derivative works need not be licensed under 652 similar terms. 654 Authors' Addresses 656 Dirk Meyer 657 Universitaet Bremen TZI 659 Email: dmeyer@tzi.de 661 Peter Saint-Andre 662 Cisco 664 Email: psaintan@cisco.com