3 Network Working Group A. Melnikov
5 Document: draft-ietf-sasl-rfc2222bis-10.txt February 2005
6 Obsoletes: RFC 2222 Expires in six months
9 Simple Authentication and Security Layer (SASL)
13 By submitting this Internet-Draft, I certify that any applicable
14 patent or other IPR claims of which I am aware have been disclosed,
15 and any of which I become aware will be disclosed, in accordance with
18 Internet Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its Areas, and its Working Groups. Note that
20 other groups may also distribute working documents as Internet
21 Drafts. Internet Drafts are draft documents valid for a maximum of
22 six months. Internet Drafts may be updated, replaced, or obsoleted
23 by other documents at any time. It is not appropriate to use
24 Internet Drafts as reference material or to cite them other than as
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 A revised version of this draft document will be submitted to the RFC
34 editor as a Standards Track RFC for the Internet Community.
35 Discussion and suggestions for improvement are requested.
36 Distribution of this draft is unlimited.
38 When published as an RFC this document will obsolete RFC 2222.
54 A. Melnikov FORMFEED[Page i]
60 Internet DRAFT SASL 16 February 2005
65 The Simple Authentication and Security Layer (SASL) is a framework
66 for providing authentication and data security services in
67 connection-oriented protocols via replaceable mechanisms. It provides
68 a structured interface between protocols and mechanisms. The
69 resulting framework allows new protocols to reuse existing mechanisms
70 and allows old protocols to make use of new mechanisms. The
71 framework also provides a protocol for securing subsequent protocol
72 exchanges within a data security layer.
74 This document describes how a SASL mechanism is structured, describes
75 how protocols add support for SASL, and defines the protocol for
76 carrying a data security layer over a connection. Additionally, this
77 document defines one SASL mechanism, the EXTERNAL mechanism.
80 1. Conventions used in this document
82 In examples, "C:" and "S:" indicate lines sent by the client and
85 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
86 in this document are to be interpreted as defined in "Key words for
87 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
89 Character names in this document use the notation for code points and
90 names from the Unicode Standard [Unicode]. For example, the letter
91 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
93 This document uses terms "integrity protection" and "confidentiality
94 protection". The former refers to a security layer (see Section
95 "Introduction" below for the definition) designed to provide "data
96 integrity service" as defined in [Sec-Glossary]. Confidentiality
97 protection is a security layer that provides "data confidentiality
98 service" as defined in [Sec-Glossary]. The term "confidentiality
99 protection" implies "integrity protection". Security layers may offer
100 other kinds of security services, for example re-keying, truncation
101 detection, as well as other services, e.g. compression.
106 The Simple Authentication and Security Layer (SASL) is a framework
107 for providing authentication and data security services in
108 connection-oriented protocols via replaceable mechanisms. SASL
109 provides a structured interface between protocols and mechanisms.
110 SASL also provides a protocol for securing subsequent protocol
114 A. Melnikov FORMFEED[Page 2]
120 Internet DRAFT SASL 16 February 2005
123 exchanges within a data security layer.
125 SASL's design is intended to allow new protocols to reuse existing
126 mechanisms without requiring redesign of the mechanisms and allows
127 existing protocols to make use of new mechanisms without redesign of
130 The SASL is conceptually a framework which provides a layer between
131 protocols and mechanisms, as illustrated in the following diagram.
133 SMTP Protocol LDAP Protocol Other Protocols
134 Profile Profile . . .
140 DIGEST-MD5 EXTERNAL Other Mechanisms
141 SASL mechanism SASL mechanism . . .
144 It is through the interfaces of this layer that the framework allows
145 any protocol to be utilized with any mechanism. While the layer does
146 generally hide the particulars of protocols from mechanisms and the
147 particulars of mechanisms from protocols, the layer does not
148 generally hide the particulars of mechanisms from protocol
149 implementations. For example, different mechanisms require different
150 information to operate, some of them use password based
151 authentication, some of then require realm information, others make
152 use of Kerberos tickets, certificates, etc. Also, in order to
153 perform authorization, server implementations have to implement a
154 mapping from a mechanism-specific authentication identity format to a
155 protocol-specific format.
157 It is possible to design and implement this framework in ways which
158 do abstract away particulars of similar mechanisms. Such
159 implementation could also be designed to be shared by multiple
160 implementations of various protocols.
162 As illustrated above, the SASL framework interfaces with both
163 protocols and mechanisms.
165 To use SASL, a protocol includes a command for identifying and
166 authenticating a user to a server and for optionally negotiating a
167 security layer for subsequent protocol interactions. If the use of a
168 security layer is negotiated, that security layer is inserted between
169 the protocol and the connection. Section 4 ("Protocol profile
170 requirements") profiles the requirements that a protocol
174 A. Melnikov FORMFEED[Page 3]
180 Internet DRAFT SASL 16 February 2005
183 specification must fulfill to make use of SASL. A SASL protocol
184 profile is a part of the protocol specification that satisfies the
185 requirements of Section 4.
187 A SASL mechanism is a series of server challenges and client
188 responses specific to the mechanism. Each SASL mechanism is
189 identified by a registered name. Section 5 ("Mechanism profile
190 guidelines") profiles the requirements that a mechanism specification
191 must fulfill to define a SASL mechanism.
193 This document is written to serve several different audiences:
195 - protocol designers using this specification to support
196 authentication in their protocol,
198 - mechanism designers that define new SASL mechanisms, and
200 - implementors of clients or servers for those protocols using this
203 The sections "Authentication mechanisms", "Protocol profile
204 requirements", "Specific issues", and "Security considerations" cover
205 issues that protocol designers need to understand and address in
206 profiling this specification for use in a specific protocol.
208 The sections "Authentication mechanisms", "Mechanism profile
209 guidelines", "Security considerations" and "Registration procedure"
210 cover issues that mechanism designers need to understand and address
211 in designing new SASL mechanisms.
213 The sections "Authentication mechanisms", "Protocol profile
214 requirements", "Specific issues" and "Security considerations" cover
215 issues that implementors of a protocol that uses SASL framework need
216 to understand. The implementors will also need to understand a
217 specification of a SASL profile specific to the protocol, as well as
218 aspects of mechanism specifications they intend to use (regardless of
219 whether they are implementing the mechanisms themselves or using an
220 existing implementation) to understand, for instance, the mechanism-
221 specific authentication identity forms, the offered services, and
222 security and other considerations.
224 2.1. Relationship to other documents
226 This document obsoletes RFC 2222. It replaces all portions of RFC
227 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2
228 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4
229 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete.
230 The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
234 A. Melnikov FORMFEED[Page 4]
240 Internet DRAFT SASL 16 February 2005
243 3. Authentication mechanisms
245 SASL mechanisms are named by strings, from 1 to 20 characters in
246 length, consisting of ASCII [ASCII] upper-case letters, digits,
247 hyphens, and/or underscores. Names of SASL mechanisms or families of
248 mechanisms must be registered with the Internet Assigned Numbers
249 Authority (IANA) as described in section 8.2.
251 The "sasl-mech" ABNF production below defines the syntax of a SASL
252 mechanism name. This uses the Augmented Backus-Naur Form (ABNF)
253 notation as specified in [ABNF].
255 sasl-mech = 1*20mech-char
256 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
257 ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
258 ; and "_" from ASCII character set.
260 UPPER-ALPHA = %x41-5A
273 3.1. Authentication Exchange
275 A SASL mechanism is responsible for conducting an authentication
276 exchange. This consists of a series of server challenges and client
277 responses, the contents of which are specific to and defined by the
278 mechanism. To the application protocol, the challenges and responses
279 are opaque binary tokens of arbitrary length (including 0-length).
280 The protocol's profile then specifies how these binary tokens are
281 encoded for transfer over the connection.
283 After receiving an authentication command or any client response, a
284 server mechanism may issue a challenge, indicate failure, or indicate
285 completion. The server mechanism may return additional data with a
286 completion indication. The protocol's profile specifies how each of
287 these is then represented over the connection.
289 After receiving a challenge, a client mechanism may issue a response
290 or abort the exchange. The protocol's profile specifies how each of
294 A. Melnikov FORMFEED[Page 5]
300 Internet DRAFT SASL 16 February 2005
303 these are then represented over the connection.
305 During the authentication exchange, the mechanism performs
306 authentication, transmits an authorization identity (sometimes known
307 as a username) from the client to server, and may negotiate the use
308 of a mechanism-specific security layer. If the use of a security
309 layer is agreed upon, then the mechanism must also define or
310 negotiate the maximum security layer buffer size that each side is
313 3.2. Identity Concepts
316 Conceptually, SASL framework involves two identities:
317 1) an identity associated with the authentication
318 credentials (termed the authentication identity), and
319 2) an identity to act as (termed the authorization
322 The client provides its credentials and, optionally, a string
323 representing the requested authorization identity as part of the SASL
324 exchange. When this string is omitted or empty, the client is
325 requesting to act as the identity associated with the credentials
326 (e.g., the user is requesting to act as the authentication identity).
328 The server is responsible for verifying the client's credentials and
329 verifying that the client is allowed to act as the authorization
330 identity. A SASL exchange fails if either (or both) of these
333 SASL mechanism specifications describe the form of credentials used
334 to authenticate clients, and SASL application profiles describe the
335 form of authorization identities transferred as part of
336 authentication exchange. However, the precise form(s) of the
337 authentication identities (used within the server in its
338 verifications, or otherwise) and the precise form(s) of the
339 authorization identities (used in making authorization decisions, or
340 otherwise) is beyond the scope of the SASL and this specification.
341 In some circumstances, the precise identity forms used outside of the
342 SASL exchange may be dictated by other specifications. For instance,
343 the authorization policy specification for an application protocol
344 may dictate the precise form that an authorization identity is to be
345 represented in the authorization policy.
347 <<Need to address few issues in the two remaining paragraphs>> Any
348 normalization of the authentication identity (for the purposes of
349 conducting authentication exchange) is defined by a particular SASL
350 mechanism, the protocol profile doesn't influence it. Note, that the
354 A. Melnikov FORMFEED[Page 6]
360 Internet DRAFT SASL 16 February 2005
363 mechanism specification doesn't control how authentication identity
364 information is represented elsewhere <<need to add few examples>>.
366 The mechanism MUST preserve Unicode codepoints when transferring
367 authorization identity (e.g. the mechanism can't apply any form of
371 3.2.1. Authorization identities and proxy authentication
374 A mechanism which is incapable of transmitting an authorization
375 identity must be treated as if it always transmits an authorization
376 identity of an empty string.
378 If the authorization identity transmitted during the authentication
379 exchange is not the empty string, this is typically referred to as
380 "proxy authentication". This feature permits agents such as proxy
381 servers to authenticate using their own credentials, yet request the
382 access privileges of the identity for which they are proxying.
384 The server makes an implementation-defined policy decision as to
385 whether the authentication identity is permitted to have the access
386 privileges of the authorization identity and whether the
387 authorization identity is permitted to receive service. If it is
388 not, the server indicates failure of the authentication exchange.
390 As a client might not have the same information as the server,
391 clients SHOULD NOT derive authorization identities from
392 authentication identities. Instead, clients SHOULD provide no (or
393 empty) authorization identity when the user has not provided an
394 authorization identity.
396 The server SHOULD verify that a received authorization identity is in
397 the correct form. Protocol profiles whose authorization identities
398 are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
399 profile [SASLprep] of the "stringprep" algorithm [StringPrep] to
400 prepare these names for matching. The profiles MAY use a stringprep
401 profile that is more strict than "SASLprep". If the preparation of
402 the authorization identity fails or results in an empty string, the
403 server MUST fail the authentication exchange. The only exception to
404 this rule is when the received authorization identity is already the
407 3.2.2. Authorization Identity Format
409 An authorization identity is a string of zero or more Unicode
410 [Unicode] coded characters. The NUL <U+0000> character is prohibited
414 A. Melnikov FORMFEED[Page 7]
420 Internet DRAFT SASL 16 February 2005
423 in authorization identities.
425 The character encoding scheme used for transmitting an authorization
426 identity over the protocol is specified in each authentication
427 mechanism. All IETF-defined mechanisms MUST, and all other
428 mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF
429 policy regarding character sets and encoding schemes.)
431 Mechanisms are expected to be capable of carrying the entire Unicode
432 repertoire (with the exception of the NUL character). An
433 authorization identity of the empty string and an absent
434 authorization identity MUST be treated as equivalent. A mechanism
435 which provides an optional field for an authorization identity,
436 SHOULD NOT allow that field, when present, to be empty. The meaning
437 of the empty string as an authorization identity is described in
443 SASL mechanisms may offer a wide range of services in "security
444 layers". Typical examples of such services are data integrity, data
445 confidentiality, re-keying, truncation detection and compression.
447 If use of a security layer is negotiated by the authentication
448 protocol exchange, the security layer is applied to all subsequent
449 data sent over the connection (until another security layer is
450 negotiated ( see also section 6.3) or underlying connection is
451 closed). The security layer takes effect immediately following the
452 last response of the authentication exchange for data sent by the
453 client and the completion indication for data sent by the server. The
454 exact position MUST be defined by the protocol profile (see section 4
457 Once the security layer is in effect the protocol stream is processed
458 by the security layer into buffers of protected data. If the
459 security layer is not able to produce a buffer, the connection MUST
460 be closed. If the security layer is not able to decode a received
461 buffer, the connection MUST be closed. In both cases the underlying
462 connection SHOULD be closed gracefully.
464 Each buffer of protected data is transferred over the connection as a
465 stream of octets prepended with a four octet field in network byte
466 order that represents the length of the buffer. The length of the
467 protected data buffer MUST be no larger than the maximum size that
468 was either defined in the mechanism specification or negotiated by
469 the other side during the authentication exchange. Upon the receipt
470 of a data buffer which is larger than the defined/negotiated maximal
474 A. Melnikov FORMFEED[Page 8]
480 Internet DRAFT SASL 16 February 2005
483 buffer size the receiver SHOULD close the connection, as this might
484 be a sign of an attack.
486 SASL mechanisms which are unable to negotiate a security layer are
487 treated as selecting no security layer.
489 4. Protocol profile requirements
491 In order to use this specification, a protocol definition MUST supply
492 the following information:
494 1) A service name, to be selected from the IANA registry of
495 "service" elements for the GSSAPI host-based service name form
496 [GSSAPI]. This service name is made available to the authentication
499 The registry is available at the URL
500 <http://www.iana.org/assignments/gssapi-service-names>.
502 2) A definition of the command to initiate the authentication
503 protocol exchange. This command must have as a parameter the name
504 of the mechanism being selected by the client.
506 The command SHOULD have an optional parameter giving an initial
507 response. If the protocol allows for the initial response, the
508 protocol profile MUST also describe how an empty initial response
509 is encoded. This optional parameter allows the client to avoid a
510 round trip when using a mechanism which is defined to have the
511 client send data first. When this initial response is sent by the
512 client and the selected mechanism is defined to have the server
513 start with an initial challenge, the command fails. See section
514 6.1 of this document for further information.
516 3) A definition of the method by which the authentication protocol
517 exchange is carried out, including how the challenges and responses
518 are encoded, how the server indicates completion or failure of the
519 exchange, how the client aborts an exchange, and how the exchange
520 method interacts with any line length limits in the protocol.
522 The exchange method SHOULD allow the server to include an optional
523 data ("optional challenge") with a success notification. This
524 allows the server to avoid a round trip when using a mechanism
525 which is defined to have the server send additional data along with
526 the indication of successful completion. Note that if additional
527 data is sent with success, it can not be empty. See section 6.2 of
528 this document for further information.
530 4) A protocol profile SHOULD specify a mechanism through which a
534 A. Melnikov FORMFEED[Page 9]
540 Internet DRAFT SASL 16 February 2005
543 client may obtain the names of the SASL mechanisms available to it.
544 This is typically done through the protocol's extensions or
545 capabilities mechanism.
547 5) Identification of the octet where any negotiated security layer
548 starts to take effect, in both directions.
550 6) Specify if the protocol profile supports "multiple
551 authentications" (see section 6.3).
553 7) If both a Transport Layer Security [TLS] and a SASL security
554 layer are allowed to be negotiated by the protocol, the protocol
555 profile MUST define in which order they are applied to a cleartext
556 data sent over the connection.
558 8) A protocol profile MAY further refine the definition of an
559 authorization identity by adding additional syntactic restrictions
560 and protocol-specific semantics. A protocol profile MUST specify
561 the form of the authorization identity (since it is protocol-
562 specific, as opposed to the authentication identity, which is
563 mechanism-specific) and how authorization identities are to be
564 compared. Profiles whose authorization identities are simple user
565 names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile
566 [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare
567 these names for matching. The profiles MAY use a stringprep profile
568 that is more strict than SASLprep.
570 9) Where the application-layer protocol does not precisely state
571 how identities established through SASL relate to identities used
572 elsewhere (e.g., access controls) in the application-layer
573 protocol, it may be useful for the application-layer protocol to
574 provide a facility which the client may use to discover the
578 A protocol profile SHOULD NOT attempt to amend the definition of
579 mechanisms or create mechanism-specific encodings. This breaks the
580 separation between protocol and mechanism that is fundamental to the
581 design of SASL. (Likewise, SASL mechanisms are intended to be profile
584 5. Mechanism profile guidelines
587 Designers of new SASL mechanism should be aware of the following
590 1) Authorization identity
594 A. Melnikov FORMFEED[Page 10]
600 Internet DRAFT SASL 16 February 2005
603 While some legacy mechanisms are incapable of transmitting an
604 authorization identity (which means that for these mechanisms the
605 authorization identity is always the empty string), newly defined
606 mechanisms SHOULD be capable of transmitting a non-empty
607 authorization identity. See also section 3.2.
609 2) Character string issues
611 Authentication mechanisms SHOULD encode character strings in UTF-8
612 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character
613 sets in IETF protocols). In order to avoid interoperability problems
614 due to differing normalizations, when a mechanism specifies that
615 character data is to be used as input to a cryptographic and/or
616 comparison function, the mechanism specification MUST detail how the
617 data is to be represented, including any normalizations or other
618 preparations, to ensure proper function. Designers of mechanisms
619 SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep"
620 algorithm [StringPrep] where applicable. This recommendation does
621 not apply to authorization identities as their handling is protocol-
624 The preparation can be potentially performed on the client side (upon
625 getting user input or retrieving a value from configuration) or on
626 the server side (upon receiving the value from the client, retrieving
627 a value from its authentication database or generating a new value in
628 order to store in in the authentication database). SASL mechanisms
629 MUST define which entity (or entities) must perform the preparation.
630 If preparation fails or turns a non-empty string into the empty
631 string, the entity doing the preparation MUST fail the authentication
634 Implementation note: A server side can be represented by multiple
635 processes. For example, the server side may consist of the server
636 process itself that communicated with a client and a utility (a
637 server agent) that is able to store passwords/hashes (or derivitives)
638 in a database that can be later used by the server. For the server
639 agent the requirement to "fail the authentication exchange" should be
640 interpreted as a requirement to refuse to store the data in the
643 3) The mechanism specification MUST detail whether or not it offers a
644 security layer. If it does, it MUST detail the security and other
645 services offered in the layer as well as how these services are to be
648 4) If the underlying cryptographic technology used by a mechanism
649 supports data integrity, then the mechanism specification MUST
650 integrity protect the transmission of an authorization identity and
654 A. Melnikov FORMFEED[Page 11]
660 Internet DRAFT SASL 16 February 2005
663 the negotiation of the security layer.
665 5) The mechanism SHOULD NOT use the authorization identity in
666 generation of any long-term cryptographic keys/hashes. The reason is
667 that different protocols (and sometimes even different
668 implementations of the same protocol) may use multiple forms of an
669 authorization identity that are semantically equivalent and some
670 clients may use one form while other clients use a different form.
672 6) SASL mechanisms should be designed to minimize the number of round
673 trips required, because SASL can be used with protocols where
674 connections are short-lived.
676 7) SASL mechanisms SHOULD be profile neutral.
680 6.1. Client sends data first
682 Some mechanisms specify that the first data sent in the
683 authentication exchange is from the client to the server.
685 If a protocol's profile permits the command which initiates an
686 authentication exchange to contain an initial client response, this
687 parameter SHOULD be used with such mechanisms.
689 If the initial client response parameter is not given, or if a
690 protocol's profile does not permit the command which initiates an
691 authentication exchange to contain an initial client response, then
692 the server issues a challenge with no data. The client's response to
693 this challenge is then used as the initial client response. (The
694 server then proceeds to send the next challenge, indicates
695 completion, or indicates failure.)
697 6.1.1. Client sends data first examples
700 The following are two examples of the SECURID authentication [SASL-
701 SECURID] in the SMTP protocol [SMTP]. In the first example below,
702 the client is trying fast reauthentication by sending the initial
705 S: 220-smtp.example.com ESMTP Server
706 C: EHLO client.example.com
707 S: 250-smtp.example.com Welcome client.example.com
708 S: 250-AUTH GSSAPI SECURID
710 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA=
714 A. Melnikov FORMFEED[Page 12]
720 Internet DRAFT SASL 16 February 2005
723 S: 235 Authentication successful
725 The example below is almost identical to the previous, but here the
726 client chooses not to use the initial response parameter.
728 S: 220-smtp.example.com ESMTP Server
729 C: EHLO client.example.com
730 S: 250-smtp.example.com Welcome client.example.com
731 S: 250-AUTH GSSAPI SECURID
735 C: AG1hZ251cwAxMjM0NTY3OAA=
736 S: 235 Authentication successful
738 Additonal examples that show usage of initial response can be found
742 6.2. Server returns success with additional data
744 Some mechanisms may specify that additional data be sent to the
745 client along with an indication of successful completion of the
746 exchange. This data would, for example, authenticate the server to
749 If a protocol's profile does not permit this additional data to be
750 returned with a success indication, then the server issues the data
751 as a server challenge, without an indication of successful
752 completion. The client then responds with no data. After receiving
753 this empty response, the server then indicates successful completion
754 (with no additional data).
756 Client implementors should be aware of an additional failure case
757 that might occur when the profile supports sending the additional
758 data with success. Imagine that an active attacker is trying to
759 impersonate the server and sends faked data, which should be used to
760 authenticate the server to the client, with success. (A similar
761 situation can happen when either the server and/or the client has a
762 bug and they calculate different responses.) After checking the data,
763 the client will think that the authentication exchange has failed,
764 however the server will think that the authentication exchange has
765 completed successfully. At this point the client can not abort the
766 authentication exchange; it SHOULD close the connection instead.
767 However, if the profile did not support sending of additional data
768 with success, the client could have aborted the exchange at the very
769 last step of the authentication exchange.
774 A. Melnikov FORMFEED[Page 13]
780 Internet DRAFT SASL 16 February 2005
783 6.2.1. Server returns success with additional data examples
786 The following are two examples of a DIGEST-MD5 authentication [SASL-
787 DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In
788 the first example below, the server is sending mutual authentication
792 xmlns='jabber:client'
793 xmlns:stream='http://etherx.jabber.org/streams'
797 xmlns='jabber:client'
798 xmlns:stream='http://etherx.jabber.org/streams'
803 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
804 <mechanism>DIGEST-MD5</mechanism>
805 <mechanism>CRAM-MD5</mechanism>
808 C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
809 mechanism='DIGEST-MD5'/>
810 S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
811 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
812 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
814 C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
815 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
816 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
817 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
818 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
821 S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
822 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
825 The example below is almost identical to the previous, but here
826 the server chooses not to use the additional data with success.
829 xmlns='jabber:client'
830 xmlns:stream='http://etherx.jabber.org/streams'
834 A. Melnikov FORMFEED[Page 14]
840 Internet DRAFT SASL 16 February 2005
846 xmlns='jabber:client'
847 xmlns:stream='http://etherx.jabber.org/streams'
852 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
853 <mechanism>DIGEST-MD5</mechanism>
854 <mechanism>CRAM-MD5</mechanism>
857 C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
858 mechanism='DIGEST-MD5'/>
859 S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
860 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
861 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
863 C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
864 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
865 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
866 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
867 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
870 S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
871 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
873 C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
874 S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
876 6.3. Multiple authentications
878 Unless otherwise stated by the protocol's profile, only one
879 successful SASL negotiation may occur in a protocol session. In this
880 case, once an authentication exchange has successfully completed,
881 further attempts to initiate an authentication exchange fail.
883 If a profile explicitly permits multiple successful SASL negotiations
884 to occur, then in no case may multiple security layers be
885 simultaneously in effect. If a security layer is in effect and a
886 subsequent SASL negotiation selects a second security layer, then the
887 second security layer replaces the first. If a security layer is in
888 effect and a subsequent SASL negotiation selects no security layer,
889 the original security layer remains in effect.
894 A. Melnikov FORMFEED[Page 15]
900 Internet DRAFT SASL 16 February 2005
903 Where a protocol profile permits multiple successful SASL
904 negotiations, the profile MUST detail the effect of a failed SASL
905 negotiation upon the previously established authentication state.
906 In particular, it MUST state whether the previously established
907 authenticated state remains in force or whether the connection is to
908 revert to an non-authenticated state. Regardless of the specified
909 effect upon authentication state, the previously negotiated security
910 layer remains in effect.
912 7. The EXTERNAL mechanism
914 The mechanism name associated with external authentication is
917 The client sends a single message containing the UTF-8 encoding of
918 the requested authorization identity. The message may be empty. The
919 form of the authorization identity may be restricted by the
920 application protocol's SASL profile.
922 Some system external to SASL must authenticate the client. If that
923 succeeds, the server determines the authentication identity from
924 information from this system. If the requested authorization
925 identity is empty, the authorization identity is derived from the
926 authentication identity. The server determines if the authentication
927 identity is allowed to act as the authorization identity. If all
928 that succeeds, the server indicates successful completion of the
929 authentication exchange; otherwise it indicates failure.
931 The system providing this external information may be, for example,
932 IPSec [IPSec] or TLS [TLS]. However, the client can make no
933 assumptions as to what information the server can use in determining
934 client authorization. For example, just because TLS was established,
935 doesn't mean that the server will use the information provided by
940 The following syntax specification uses the augmented Backus-Naur
941 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced
942 but not defined below are as defined by [UTF-8].
944 The "extern-resp" rule below defines the message sent from client to
947 extern-resp = *( UTF8-char-no-nul )
949 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
954 A. Melnikov FORMFEED[Page 16]
960 Internet DRAFT SASL 16 February 2005
963 UTF8-1-no-nul = %x01-7F
966 7.2. Examples of SASL EXTERNAL
968 The following is an example of an EXTERNAL authentication in the SMTP
969 protocol [SMTP]. In this example, the client is proxy authenticating,
970 sending the authorization identity "fred@example.com" in the
971 (optional) initial response. The server has obtained the client's
972 (authentication) identity from an external service, such as IPsec,
973 and has a security policy that permits that identity to assume the
974 identity of the asserted authorization identity.
976 To the protocol profile, the sequence "fred@example.com" is an opaque
977 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies
978 that server challenges and client responses are encoded in BASE64
979 [BASE64, section 3]; the BASE64 encoding of "fred@example.com" is
980 "ZnJlZEBleGFtcGxlLmNvbQ==".
982 S: 220 smtp.example.com ESMTP server ready
983 C: EHLO jgm.example.com
984 S: 250-smtp.example.com
985 S: 250 AUTH DIGEST-MD5 EXTERNAL
986 C: AUTH EXTERNAL ZnJlZEBleGFtcGxlLmNvbQ==
987 S: 235 Authentication successful.
989 The following example is almost identical to the one above, but the
990 client doesn't request proxy authentication.
992 S: 220 smtp.example.com ESMTP server ready
993 C: EHLO jgm.example.com
994 S: 250-smtp.example.com
995 S: 250 AUTH DIGEST-MD5 EXTERNAL
997 S: 235 Authentication successful.
999 The following is an example of an EXTERNAL authentication in the
1000 IMAP4 protocol [IMAP]. IMAP4 doesn't support the initial response
1001 feature of SASL. As in the previous example, the client doesn't
1002 request proxy authentication.
1004 S: * OK IMAP4rev1 Server
1006 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=EXTERNAL
1008 C: A01 AUTHENTICATE EXTERNAL
1009 (note that there is a space following the "+" in the following line)
1014 A. Melnikov FORMFEED[Page 17]
1020 Internet DRAFT SASL 16 February 2005
1027 8. IANA Considerations
1030 8.1. Guidelines for IANA
1033 It is requested that IANA updates the SASL mechanisms registry as
1037 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
1038 registrations to OBSOLETE. Change the "Published specification"
1039 of the EXTERNAL mechanism to this document. Updated registration
1040 information is provided in Section 8.6.
1042 8.2. Registration procedure
1045 Registration of a SASL mechanism is done by filling in the template
1046 in section 8.5 and sending it via electronic mail to <iana@iana.org>.
1047 IANA has the right to reject obviously bogus registrations, but will
1048 perform no review of claims made in the registration form. SASL
1049 mechanism registrations are currently available at the URL
1050 <http://www.iana.org/assignments/sasl-mechanisms>.
1052 There is no naming convention for SASL mechanisms; any name that
1053 conforms to the syntax of a SASL mechanism name can be registered.
1054 However an IETF Standards Track document may reserve a portion of the
1055 SASL mechanism namespace ("family of SASL mechanisms") for its own
1056 use, amending the registration rules for that portion of the
1057 namespace. Each family of SASL mechanisms MUST be identified by a
1060 While the registration procedures do not require expert review,
1061 authors of SASL mechanisms are encouraged to seek community review
1062 and comment whenever that is feasible. Authors may seek community
1063 review by posting a specification of their proposed mechanism as an
1064 Internet-Draft. SASL mechanisms intended for widespread use should
1065 be standardized through the normal IETF process, when appropriate.
1067 8.3. Comments on SASL mechanism registrations
1069 Comments on registered SASL mechanisms should first be sent to the
1070 "owner" of the mechanism and/or to the SASL WG mailing list.
1074 A. Melnikov FORMFEED[Page 18]
1080 Internet DRAFT SASL 16 February 2005
1083 Submitters of comments may, after a reasonable attempt to contact the
1084 owner, request IANA to attach their comment to the SASL mechanism
1085 registration itself. If IANA approves of this, the comment will be
1086 made accessible in conjunction with the SASL mechanism registration
1091 Once a SASL mechanism registration has been published by IANA, the
1092 author may request a change to its definition. The change request
1093 follows the same procedure as the registration request.
1095 The owner of a SASL mechanism may pass responsibility for the SASL
1096 mechanism to another person or agency by informing IANA; this can be
1097 done without discussion or review.
1099 The IESG may reassign responsibility for a SASL mechanism. The most
1100 common case of this will be to enable changes to be made to
1101 mechanisms where the author of the registration has died, moved out
1102 of contact or is otherwise unable to make changes that are important
1105 SASL mechanism registrations may not be deleted; mechanisms which are
1106 no longer believed appropriate for use can be declared OBSOLETE by a
1107 change to their "intended usage" field; such SASL mechanisms will be
1108 clearly marked in the lists published by IANA.
1110 The IESG is considered to be the owner of all SASL mechanisms which
1111 are on the IETF standards track.
1113 8.5. Registration template
1116 Subject: Registration of SASL mechanism X
1118 Family of SASL mechanisms: (YES or NO)
1120 SASL mechanism name (or prefix for the family):
1122 Security considerations:
1124 Published specification (optional, recommended):
1126 Person & email address to contact for further information:
1130 (One of COMMON, LIMITED USE or OBSOLETE)
1134 A. Melnikov FORMFEED[Page 19]
1140 Internet DRAFT SASL 16 February 2005
1143 Owner/Change controller:
1145 (Any other information that the author deems interesting may be
1146 added below this line.)
1149 8.6. The EXTERNAL mechanism registration
1151 It is requested that the SASL Mechanism registry [IANA-SASL] entry
1152 for the EXTERNAL mechanism be updated to reflect that this document
1153 now provides its technical specification.
1156 Subject: Updated Registration of SASL mechanism EXTERNAL
1158 Family of SASL mechanisms: NO
1160 SASL mechanism name: EXTERNAL
1162 Security considerations: See RFC XXXX, section 9.
1164 Published specification (optional, recommended): RFC XXXX
1166 Person & email address to contact for further information:
1167 Alexey Melnikov <Alexey.Melnikov@isode.com>
1169 Intended usage: COMMON
1171 Owner/Change controller: IESG <iesg@ietf.org>
1173 Note: Updates existing entry for EXTERNAL
1175 9. Security considerations
1177 Security issues are discussed throughout this memo.
1179 When the client selects a security layer with at least integrity
1180 protection, this protects against an active attacker hijacking the
1181 connection and modifying the authentication exchange to negotiate a
1182 plaintext connection.
1184 When a server or client supports multiple authentication mechanisms,
1185 each of which has a different security strength, it is possible for
1186 an active attacker to cause a party to use the least secure mechanism
1187 supported. To protect against this sort of attack, a client or
1188 server which supports mechanisms of different strengths should have a
1189 configurable minimum strength that it will use. It is not sufficient
1190 for this minimum strength check to only be on the server, since an
1194 A. Melnikov FORMFEED[Page 20]
1200 Internet DRAFT SASL 16 February 2005
1203 active attacker can change which mechanisms the client sees as being
1204 supported, causing the client to send authentication credentials for
1205 its weakest supported mechanism.
1207 The client's selection of a SASL mechanism is done in the clear and
1208 may be modified by an active attacker. It is important for any new
1209 SASL mechanisms to be designed such that an active attacker cannot
1210 obtain an authentication with weaker security properties by modifying
1211 the SASL mechanism name and/or the challenges and responses.
1213 In order to detect Man-in-the-middle (MITM) attacks the client MAY
1214 list available SASL mechanisms both before and after the SASL
1215 security layer is negotiated. This allows the client to detect
1216 active attacks that remove mechanisms from the server's list of
1217 supported mechanisms, and allows the client to ensure that it is
1218 using the best mechanism supported by both client and server. New
1219 protocol profiles SHOULD require servers to make the list of SASL
1220 mechanisms available for the initial authentication available to the
1221 client after security layers are established. Some older protocols
1222 do not require this (or don't support listing of SASL mechanisms once
1223 authentication is complete); for these protocols clients MUST NOT
1224 treat an empty list of SASL mechanisms after authentication as a MITM
1227 Any protocol interactions prior to authentication are performed in
1228 the clear and may be modified by an active attacker. In the case
1229 where a client selects integrity protection, it is important that any
1230 security-sensitive protocol negotiations be performed after
1231 authentication is complete. Protocols should be designed such that
1232 negotiations performed prior to authentication should be either
1233 ignored or revalidated once authentication is complete.
1235 Clients should be admonished to validate TLS server IDs to prevent
1236 MITM attacks when using SASL-over-TLS. The same recommendation
1237 applies to other protocols providing security services.
1239 When use of a security layer is negotiated by the authentication
1240 protocol exchange, the receiver should handle gracefully any
1241 protected data buffer larger than the defined/negotiated maximal
1242 size. In particular, it must not blindly allocate the amount of
1243 memory specified in the buffer size field, as this might cause the
1244 "out of memory" condition. If the receiver detects a large block, it
1245 SHOULD close the connection.
1247 Most of the currently available mechanisms that provide security
1248 layers only provide basic data security services, such as data
1249 integrity and data privacy services. It is hoped that future
1250 mechanisms will provide more advance data security services like re-
1254 A. Melnikov FORMFEED[Page 21]
1260 Internet DRAFT SASL 16 February 2005
1263 keying and truncation attack detection.
1265 Distributed server implementations need to be careful in how they
1266 trust other parties. In particular, authentication secrets should
1267 only be disclosed to other parties that are trusted to manage and use
1268 those secrets in manner acceptable to disclosing party. Applications
1269 using SASL assume that SASL security layers providing data
1270 confidentiality are secure even when an attacker chooses the text to
1271 be protected by the security layer. Similarly applications assume
1272 that the SASL security layer is secure even if the attacker can
1273 manipulate the ciphertext output of the security layer. New SASL
1274 mechanisms MUST meet these assumptions.
1276 "stringprep" and Unicode security considerations apply to
1277 authentication identities, authorization identities and passwords.
1279 The EXTERNAL mechanism provides no security protection; it is
1280 vulnerable to spoofing by either client or server, active attack, and
1281 eavesdropping. It should only be used when external security
1282 mechanisms are present and have sufficient strength.
1288 The secure or administratively permitted lifetimes of SASL
1289 mechanisms' security layers are finite. Cryptographic keys weaken as
1290 they are used and as time passes; the more time and/or ciphertext
1291 that a cryptanalyst has after the first use of the a key, the easier
1292 it is for the cryptanalyst to mount attacks on the key.
1294 Administrative limits on security layers lifetime may take the form
1295 of time limits expressed in x.509 certificates, Kerberos V tickets,
1296 or in directories, and are often desired. In practice one likely
1297 effect of administrative security layers lifetime limits is that
1298 applications may find that security layers stop working in the middle
1299 of application protocol operation, such as, perhaps, during large
1300 data transfers. As the result of this the connection will be closed
1301 (see section 3.3), which will result in unpleasant user experience.
1303 Re-keying (key renegotiation process) is a way of addressing the
1304 weakening of cryptographic keys. SASL framework does not itself
1305 provide for re-keying. SASL mechanisms may. Designers of future SASL
1306 mechanisms should consider providing re-keying services.
1308 Applications that wish to re-key SASL security layers where the
1309 mechanism does not provide for re-keying should reauthenticate the
1310 same IDs and replace the expired or soon-to-expire security layers.
1314 A. Melnikov FORMFEED[Page 22]
1320 Internet DRAFT SASL 16 February 2005
1323 This approach requires support for reauthentication in the
1324 application protocols. See section 6.3.
1329 10.1. Normative References
1331 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax
1332 Specifications: ABNF", RFC 2234, November 1997
1334 [ASCII] American National Standards Institute, "Code Extension
1335 Techniques for Use with the 7-bit Coded Character Set of American
1336 National Standard Code (ASCII) for Information Interchange", FIPS PUB
1339 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and
1340 Languages", RFC 2277, BCP 18, January 1998
1342 [GSSAPI] Linn, J., "Generic Security Service Application Program
1343 Interface, Version 2, Update 1", RFC 2743, January 2000
1345 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1346 Requirement Levels", RFC 2119, BCP 19, March 1997
1348 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1349 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading,
1350 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the
1351 "Unicode Standard Annex #27: Unicode 3.1"
1352 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
1353 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
1355 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of
1356 Internationalized Strings ("stringprep")", RFC 3454, December 2002.
1358 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1359 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
1361 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1362 RFC 3629, STD 63, November 2003.
1364 10.2. Informative References
1367 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in
1368 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003
1370 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
1374 A. Melnikov FORMFEED[Page 23]
1380 Internet DRAFT SASL 16 February 2005
1383 Authentication as a SASL Mechanism", work in progress, draft-ietf-
1384 sasl-rfc2831bis-XX.txt, replaces RFC 2831
1386 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
1389 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC
1392 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
1395 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
1396 RFC 2554, March 1999.
1398 Being revised by Siemborski, R., "SMTP Service Extension for
1399 Authentication", work in progress, draft-siemborski-rfc2554bis-
1402 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol
1403 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt.
1405 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
1406 Encodings", RFC 3548, July 2003.
1408 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC
1409 Authors", RFC 2223, October 1997.
1411 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
1412 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.
1414 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1417 [IPSec] Kent, S., and R. Atkinson, "Security Architecture for the
1418 Internet Protocol", RFC 2401, November 1998.
1420 [Sec-Glossary] Shirey, R., "Internet Security Glossary", RFC 2828,
1424 11. Editor's Address
1428 5 Castle Business Village
1434 A. Melnikov FORMFEED[Page 24]
1440 Internet DRAFT SASL 16 February 2005
1443 TW12 2BX, United Kingdom
1445 Email: Alexey.Melnikov@isode.com
1446 URI: http://www.melnikov.ca/
1450 This document is a revision of RFC 2222 written by John G. Myers. He
1451 also contributed significantly to this revision.
1453 Contributions of many members of the SASL mailing list are gratefully
1454 acknowledged, in particular that of Kurt Zeilenga, Peter Saint-Andre,
1455 Rob Siemborski, Magnus Nystrom, Jeffrey Hutzelman, Hallvard B
1456 Furuseth, Tony Hansen, Simon Josefsson, Abhijit Menon-Sen, RL 'Bob'
1457 Morgan, Sam Hartman, Nicolas Williams, Tim Alsop and Luke Howard.
1459 Appendix A. Relation of SASL to transport security
1461 Questions have been raised about the relationship between SASL and
1462 various services (such as IPsec and TLS) which provide a secured
1465 Two of the key features of SASL are:
1467 The separation of the authorization identity from the identity in
1468 the client's credentials. This permits agents such as proxy
1469 servers to authenticate using their own credentials, yet request
1470 the access privileges of the identity for which they are proxying.
1472 Upon successful completion of an authentication exchange, the
1473 server knows the authorization identity the client wishes to use.
1474 This allows servers to move to a "user is authenticated" state in
1477 These features are extremely important to some application protocols,
1478 yet Transport Security services do not always provide them. To
1479 define SASL mechanisms based on these services would be a very messy
1480 task, as the framing of these services would be redundant with the
1481 framing of SASL and some method of providing these important SASL
1482 features would have to be devised.
1484 Sometimes it is desired to enable within an existing connection the
1485 use of a security service which does not fit the SASL model. (TLS is
1486 an example of such a service.) This can be done by adding a command,
1487 for example "STARTTLS", to the protocol. Such a command is outside
1488 the scope of SASL, and should be different from the command which
1489 starts a SASL authentication protocol exchange.
1494 A. Melnikov FORMFEED[Page 25]
1500 Internet DRAFT SASL 16 February 2005
1503 In certain situations, it is reasonable to use SASL underneath one of
1504 these Transport Security services. The transport service would
1505 secure the connection, either service would authenticate the client,
1506 and SASL would negotiate the authorization identity. The SASL
1507 negotiation would be what moves the protocol from "unauthenticated"
1508 to "authenticated" state. The "EXTERNAL" SASL mechanism is
1509 explicitly intended to handle the case where the transport service
1510 secures the connection and authenticates the client and SASL
1511 negotiates the authorization identity.
1513 Appendix B. Changes since RFC 2222
1515 The GSSAPI mechanism was removed. It is now specified in a separate
1516 document [SASL-GSSAPI].
1518 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
1521 The "SKEY" mechanism described in RFC 2222 is obsolete and has been
1522 removed. It has been replaced by the OTP mechanism [SASL-OTP].
1524 The introduction has been substantially reorganized and clarified.
1526 Clarified the definition and semantics of the authorization identity.
1528 Prohibited the NUL character in authorization identities.
1530 Added a section on character string issues.
1532 The word "must" in the first paragraph of the "Protocol profile
1533 requirements" section was changed to "MUST".
1535 Specified that protocol profiles SHOULD provide a way for clients to
1536 discover available SASL mechanisms.
1538 Made the requirement that protocol profiles specify the semantics of
1539 the authorization identity optional to the protocol profile.
1540 Clarified that such a specification is a refinement of the definition
1541 in the base SASL spec.
1543 Added a requirement discouraging protocol profiles from breaking the
1544 separation between protocol and mechanism.
1546 Mentioned that standards track documents may carve out their own
1547 portions of the SASL mechanism namespace and may amend registration
1548 rules for the portion. However registration of individual SASL
1549 mechanisms is still required.
1554 A. Melnikov FORMFEED[Page 26]
1560 Internet DRAFT SASL 16 February 2005
1563 Clarified that authorization identity should be encoded in UTF-8.
1565 Specified that the authorization identity in the EXTERNAL mechanism
1566 is encoded in UTF-8.
1568 Added a statement that a protocol profile SHOULD allow challenge data
1569 to be sent with a success indication.
1571 Added a security consideration for the EXTERNAL mechanism.
1573 Clarified sections concerning success with additional data.
1575 Cleaned up IANA considerations/registrations and assembled them in
1578 Updated references and split them into Informative and Normative.
1580 Added text to the Security considerations section regarding handling
1581 of extremely large SASL blocks.
1583 Added text about SASLprep for authentication identities and
1584 passwords. Described where SASLprep preparation should take place.
1586 Added paragraph about verifying authorization identities.
1588 Added a protocol profile requirement to specify interaction between
1589 SASL and TLS security layers.
1591 Added a protocol profile requirement to specify if it supports
1594 Removed the text that seemed to suggest that SASL security layer must
1595 not be used when TLS is available.
1597 Created two subsections in 3.2 to talk separately about proxy
1598 authorization and format of the authorization identities.
1600 Made requirement to verify that an authorization identity is correct
1601 by performing SASLprep.
1603 Clarified that each SASL mechanism must decide where SASLprep is
1606 Added 4 new examples for initial response and additional data with
1609 Added text on checking the list of available SASL mechanisms after
1610 negotiating a security layer.
1614 A. Melnikov FORMFEED[Page 27]
1620 Internet DRAFT SASL 16 February 2005
1623 Added definition of "integrity protection" and "confidentiality
1626 Added warning about negotiating no layer once a security layer is
1629 Added new section with guidelines to a SASL mechanism designer.
1631 Added a requirement to specify how an empty initial challenge is
1632 encoded if initial response is supported by a protocol.
1634 Clarified that empty "additional data with success" is not allowed.
1636 Replaced "buffers of cipher-text" with "buffers of protected data"
1639 Clarified that SASL EXTERNAL can be used even with SASL profiles that
1640 don't support initial client response.
1642 Changed "authentication protocol exchange" to "authentication
1643 exchange" everywhere.
1645 Added some text about re-keying and other services that can be
1646 provided by a security layer.
1649 Appendix C. Full Copyright Statement and Intellectual Property Statement
1651 Full Copyright Statement
1654 Copyright (C) The Internet Society (2004). This document is subject
1655 to the rights, licenses and restrictions contained in BCP 78, and
1656 except as set forth therein, the authors retain all their rights.
1658 This document and translations of it may be copied and furnished to
1659 others, and derivative works that comment on or otherwise explain it
1660 or assist in its implementation may be prepared, copied, published
1661 and distributed, in whole or in part, without restriction of any
1662 kind, provided that the above copyright notice and this paragraph are
1663 included on all such copies and derivative works. However, this
1664 document itself may not be modified in any way, such as by removing
1665 the copyright notice or references to the Internet Society or other
1666 Internet organizations, except as needed for the purpose of
1667 developing Internet standards in which case the procedures for
1668 copyrights defined in the Internet Standards process must be
1669 followed, or as required to translate it into languages other than
1674 A. Melnikov FORMFEED[Page 28]
1680 Internet DRAFT SASL 16 February 2005
1683 The limited permissions granted above are perpetual and will not be
1684 revoked by the Internet Society or its successors or assigns.
1686 This document and the information contained herein are provided on an
1687 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1688 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1689 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1690 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1691 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1692 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1696 Funding for the RFC Editor function is currently provided by the
1699 Intellectual Property
1701 The IETF takes no position regarding the validity or scope of any
1702 Intellectual Property Rights or other rights that might be claimed to
1703 pertain to the implementation or use of the technology described in
1704 this document or the extent to which any license under such rights
1705 might or might not be available; nor does it represent that it has
1706 made any independent effort to identify any such rights. Information
1707 on the procedures with respect to rights in RFC documents can be
1708 found in BCP 78 and BCP 79.
1710 Copies of IPR disclosures made to the IETF Secretariat and any
1711 assurances of licenses to be made available, or the result of an
1712 attempt made to obtain a general license or permission for the use of
1713 such proprietary rights by implementers or users of this
1714 specification can be obtained from the IETF on-line IPR repository at
1715 http://www.ietf.org/ipr.
1717 The IETF invites any interested party to bring to its attention any
1718 copyrights, patents or patent applications, or other proprietary
1719 rights that may cover technology that may be required to implement
1720 this standard. Please address the information to the IETF at ietf-
1734 A. Melnikov FORMFEED[Page 29]
1740 Internet DRAFT SASL 16 February 2005
1743 Status of this Memo .......................................... i
1744 Abstract ..................................................... 2
1745 1. Conventions used in this document ........................ 2
1746 2. Introduction ........................................... 2
1747 2.1. Relationship to other documents ........................ 4
1748 3. Authentication mechanisms .............................. 5
1749 3.1. Authentication Exchange ................................ 5
1750 3.2. Identity Concepts ...................................... 6
1751 3.2.1. Authorization identities and proxy authentication .... 7
1752 3.2.2. Authorization Identity Format ........................ 7
1753 3.3. Security layers ........................................ 8
1754 4. Protocol profile requirements .......................... 9
1755 5. Mechanism profile guidelines .......................... 10
1756 6. Specific issues ....................................... 12
1757 6.1. Client sends data first ............................... 12
1758 6.1.1. Client sends data first examples .................... 12
1759 6.2. Server returns success with additional data ........... 13
1760 6.2.1. Server returns success with additional data examples. 14
1761 6.3. Multiple authentications .............................. 15
1762 7. The EXTERNAL mechanism ................................ 16
1763 7.1. Formal syntax ......................................... 16
1764 7.2. Examples of SASL EXTERNAL ............................. 17
1765 8. IANA Considerations ................................... 18
1766 8.1. Guidelines for IANA ................................... 18
1767 8.2. Registration procedure ................................ 18
1768 8.3. Comments on SASL mechanism registrations .............. 18
1769 8.4. Change control ........................................ 19
1770 8.5. Registration template ................................. 19
1771 8.6. The EXTERNAL mechanism registration ................... 20
1772 9. Security considerations ................................ 20
1773 9.1. Re-keying ............................................. 22
1774 10. References ........................................... 23
1775 10.1. Normative References ................................. 23
1776 10.2. Informative References ............................... 23
1777 11. Editor's Address ...................................... 24
1778 12. Acknowledgments ....................................... 25
1779 Appendix A. Relation of SASL to transport security .......... 25
1780 Appendix B. Changes since RFC 2222 .......................... 26
1781 Appendix C. Full Copyright Statement and Intellectual
1782 Property Statement .............................. 28
1783 Full Copyright Statement .................................... 28
1784 Intellectual Property ....................................... 29
1794 A. Melnikov FORMFEED[Page ii]