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