7 Network Working Group J. Myers
8 Internet Draft April 2002
9 Document: draft-myers-saslrev-02.txt
12 Simple Authentication and Security Layer (SASL)
16 This document is an Internet Draft and is in full conformance with
17 all provisions of Section 10 of RFC 2026.
19 Internet Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its Areas, and its Working Groups. Note that
21 other groups may also distribute working documents as Internet
22 Drafts. Internet Drafts are draft documents valid for a maximum of
23 six months. Internet Drafts may be updated, replaced, or obsoleted
24 by other documents at any time. It is not appropriate to use
25 Internet Drafts as reference material or to cite them other than as
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/1id-abstracts.html
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html
36 A revised version of this draft document will be submitted to the RFC
37 editor as a Draft Standard for the Internet Community. Discussion
38 and suggestions for improvement are requested. Distribution of this
63 Internet DRAFT SASL April 6, 2002
73 Status of this Memo ............................................... i
74 1. Abstract .................................................... 2
75 2. Organization of this document ............................... 2
76 2.1. How to read this document ................................... 2
77 2.2. Conventions used in this document ........................... 2
78 3. Overview .................................................... 2
79 4. Authentication mechanisms ................................... 3
80 4.1. Authentication protocol exchange ............................ 4
81 4.2. Authorization identities and proxy authentication ........... 4
82 4.3. Security layers ............................................. 5
83 4.4. Character string issues ..................................... 5
84 5. Protocol profile requirements ............................... 6
85 6. Specific issues ............................................. 7
86 6.1. Client sends data first ..................................... 7
87 6.2. Server returns success with additional data ................. 7
88 6.3. Multiple authentications .................................... 8
89 6.4. Token length limits ......................................... 8
90 7. Registration procedures ..................................... 8
91 7.1. Comments on SASL mechanism registrations .................... 9
92 7.2. Location of registered SASL mechanism list .................. 9
93 7.3. Change control .............................................. 9
94 7.4. Registration template ....................................... 10
95 8. The external mechanism ...................................... 10
96 8.1 Formal syntax ............................................... 11
97 8.2 Example ..................................................... 11
98 9. References .................................................. 12
99 10. Security considerations ..................................... 12
100 11. Author's address ............................................ 13
101 Appendix A. Relation of SASL to transport security ................ 14
102 Appendix B. IANA considerations ................................... 15
103 Appendix C. Changes since RFC 2222 ................................ 15
119 Internet DRAFT SASL April 6, 2002
124 SASL provides a method for adding authentication support with an
125 optional security layer to connection-based protocols. It also
126 describes a structure for authentication mechanisms. The result is
127 an abstraction layer between protocols and authentication mechanisms
128 such that any SASL-compatible authentication mechanism can be used
129 with any SASL-compatible protocol.
131 This document describes how a SASL authentication mechanism is
132 structured, how a protocol adds support for SASL, defines the
133 protocol for carrying a security layer over a connection, and defines
134 the EXTERNAL SASL authentication mechanism.
136 2. Organization of this document
138 2.1. How to read this document
140 This document is written to serve two different audiences, protocol
141 designers using this specification to support authentication in their
142 protocol, and implementors of clients or servers for those protocols
143 using this specification.
145 The sections "Overview", "Authentication mechanisms", "Protocol
146 profile requirements", "Specific issues", and "Security
147 considerations" cover issues that protocol designers need to
148 understand and address in profiling this specification for use in a
151 Implementors of a protocol using this specification need the
152 protocol-specific profiling information in addition to the
153 information in this document.
155 2.2. Conventions used in this document
157 In examples, "C:" and "S:" indicate lines sent by the client and
160 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
161 in this document are to be interpreted as defined in "Key words for
162 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
166 The Simple Authentication and Security Layer (SASL) is a method for
167 adding authentication support to connection-based protocols.
169 The SASL specification has three layers, as indicated in the diagram
175 Internet DRAFT SASL April 6, 2002
178 below. At the top, a protocol definition using SASL specifies a
179 profile, including a command for identifying and authenticating a
180 user to a server and for optionally negotiating a security layer for
181 subsequent protocol interactions. At the bottom, a SASL mechanism
182 definition specifies an authentication mechanism. The SASL
183 framework, specified by this document, constrains the behavior of
184 protocol profiles and mechanisms, separating protocol from mechanism
185 and defining how they interact.
187 SMTP Protocol LDAP Protocol Etc
188 Profile Profile . . .
194 EXTERNAL DIGEST-MD5 Etc
195 SASL mechanism SASL mechanism . . .
197 This separation between the definition of protocols and the
198 definition of authentication mechanisms is crucial. It permits an
199 authentication mechanism to be defined once, making it usable by any
200 SASL protocol profiles. In many implementations, the same SASL
201 mechanism code is used for multiple protocols.
203 4. Authentication mechanisms
205 SASL mechanisms are named by strings, from 1 to 20 characters in
206 length, consisting of upper-case letters, digits, hyphens, and/or
207 underscores. SASL mechanism names must be registered with the IANA.
208 IETF Standards Track documents may override this registration
209 requirement by reserving a portion of the SASL mechanism namespace
210 for their own use; the GSSAPI mechanism specification [SASL-GSSAPI]
211 does this. Procedures for registering new SASL mechanisms are given
212 in the section "Registration procedures".
214 The "sasl-mech" rule below defines the syntax of a SASL mechanism
215 name. This uses the augmented Backus-Naur Form (BNF) notation as
216 specified in [ABNF] and the ABNF core rules as specified in Appendix
217 A of the ABNF specification [ABNF].
219 sasl-mech = 1*20mech-char
220 mech-char = %x41-5A / DIGIT / "-" / "_"
221 ; mech names restricted to uppercase letters,
222 ; digits, "-" and "_"
231 Internet DRAFT SASL April 6, 2002
234 4.1. Authentication protocol exchange
236 A SASL mechanism is responsible for conducting an authentication
237 protocol exchange. This consists of a series of server challenges
238 and client responses, the contents of which are specific to and
239 defined by the mechanism. To the protocol, the challenges and
240 responses are opaque binary tokens of arbitrary length. The
241 protocol's profile then specifies how these binary tokens are then
242 encoded for transfer over the connection.
244 After receiving an authentication command or any client response, a
245 server mechanism may issue a challenge, indicate failure, or indicate
246 completion. The server mechanism MAY return additional data with a
247 completion indication. The protocol's profile specifies how each of
248 these is then represented over the connection.
250 After receiving a challenge, a client mechanism may issue a response
251 or abort the exchange. The protocol's profile specifies how each of
252 these is then represented over the connection.
254 During the authentication protocol exchange, the mechanism performs
255 authentication, transmits an authorization identity (frequently known
256 as a userid) from the client to server, and negotiates the use of a
257 mechanism-specific security layer. If the use of a security layer is
258 agreed upon, then the mechanism must also define or negotiate the
259 maximum security layer buffer size that each side is able to receive.
261 4.2. Authorization identities and proxy authentication
263 An authorization identity is a string of zero or more ISO 10646
264 [ISO-10646] coded characters. The NULL (U+0000) character is not
265 permitted in authorization identities. The authorization identity is
266 used by the server as the primary identity for making access policy
269 The character encoding scheme used for transmitting an authorization
270 identity over protocol is specified in each authentication mechanism
271 (with the authentication mechanism's blob being further encoded by
272 the protocol profile). Per IETF character set policy [CHARSET-
273 POLICY], authentication mechanisms SHOULD encode these and other
274 strings in UTF-8 [UTF-8]. While some legacy mechanisms are incapable
275 of transmitting an authoriation identity other than the empty string,
276 newly defined mechanisms are expected to be capable of carrying the
277 entire repertoire produced by the string normalization rules defined
278 in the section "Character string issues".
280 The identity derived from the client's authentication credentials is
281 known as the "authentication identity". With any mechanism,
287 Internet DRAFT SASL April 6, 2002
290 transmitting an authorization identity of the empty string directs
291 the server to derive an authorization identity from the client's
292 authentication identity.
294 If the authorization identity transmitted during the authentication
295 protocol exchange is not the empty string, this is typically referred
296 to as "proxy authentication". This feature permits agents such as
297 proxy servers to authenticate using their own credentials, yet
298 request the access privileges of the identity for which they are
301 The server makes an implementation defined policy decision as to
302 whether the authentication identity is permitted to have the access
303 privileges of the authorization identity and whether the
304 authorization identity is permitted to receive service. If it is
305 not, the server indicates failure of the authentication protocol
308 As a client might not have the same information as the server,
309 clients SHOULD NOT themselves try to derive authorization identities
310 from authentication identities when clients could instead transmit an
311 authorization identity of the empty string.
315 If use of a security layer is negotiated by the authentication
316 protocol exchange, the security layer is applied to all subsequent
317 data sent over the connection. The security layer takes effect
318 immediately following the last response of the authentication
319 exchange for data sent by the client and the completion indication
320 for data sent by the server.
322 Once the security layer is in effect, the protocol stream is
323 processed by the security layer into buffers of security encoded
324 data. Each buffer of security encoded data is transferred over the
325 connection as a stream of octets prepended with a four octet field in
326 network byte order that represents the length of the following
327 buffer. The length of the security encoded data buffer must be no
328 larger than the maximum size that was either defined in the mechanism
329 specification or negotiated by the other side during the
330 authentication protocol exchange.
331 4.4. Character string issues
333 Per IETF character set policy [CHARSET-POLICY], authentication
334 mechanisms SHOULD encode character strings in UTF-8 [UTF-8].
336 In order to avoid noninteroperability due to differing
337 normalizations, when a mechanism specifies that a string password be
343 Internet DRAFT SASL April 6, 2002
346 used as input to a cryptographic function it SHOULD specify that the
347 string first be normalized by the following profile of stringprep
350 [TODO Insert stringprep profile here. NOT specifying case folding.
351 Disallowing control characters.]
353 5. Protocol profile requirements
355 In order to use this specification, a protocol definition MUST supply
356 the following information:
359 1. A service name, to be selected from the IANA registry of "service"
360 elements for the GSSAPI host-based service name form. [GSSAPI]
361 This service name is made available to the authentication
364 The registry is available at the URL
365 "http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names"
367 2. A definition of the command to initiate the authentication
368 protocol exchange. This command must have as a parameter the name
369 of the mechanism being selected by the client.
371 The command SHOULD have an optional parameter giving an initial
372 response. This optional parameter allows the client to avoid a
373 round trip when using a mechanism which is defined to have the
374 client send data first. When this initial response is sent by the
375 client and the selected mechanism is defined to have the server
376 start with an initial challenge, the command fails. See section
377 6.1 of this document for further information.
379 3. A definition of the method by which the authentication protocol
380 exchange is carried out, including how the challenges and
381 responses are encoded, how the server indicates completion or
382 failure of the exchange, how the client aborts an exchange., and
383 how the exchange method interacts with any line length limits in
386 The method defined MUST be capable of transmitting challenge and
387 response tokens of up to 16384 octets and MUST pass this
388 requirement onto implementations. This length requirement applies
389 to the size of a token before any protocol profile specific
390 encoding. For example, if the protocol profile transmits tokens
391 encoded in the base64 encoding then the protocol profile needs to
392 require implementations to be capable of handling base64 token
393 sequences of up to 21848 characters.
399 Internet DRAFT SASL April 6, 2002
402 The command SHOULD have a method for the server to include an
403 optional challenge with a success notification. This allows the
404 server to avoid a round trip when using a mechanism which is
405 defined to have the server send additional data along with the
406 indication of successful completion. See section 6.2 of this
407 document for further information.
409 4. Identification of the octet where any negotiated security layer
410 starts to take effect, in both directions.
412 In addition, a protocol profile SHOULD specify a mechanism through
413 which a client may obtain the names of the SASL mechanisms
414 available to it. This is typically done through the protocol's
415 extensions or capabilities mechanism.
417 A protocol profile MAY further refine the definition of an
418 authorization identity by adding additional syntactic restrictions
419 and protocol-specific semantics.
421 A protocol profile SHOULD NOT attempt to amend the definition of
422 mechanisms or make mechanism-specific encodings. This breaks the
423 separation between protocol and mechanism that is fundamental to
427 6.1. Client sends data first
429 Some mechanisms specify that the first data sent in the
430 authentication protocol exchange is from the client to the server.
432 If a protocol's profile permits the command which initiates an
433 authentication protocol exchange to contain an initial client
434 response, this parameter SHOULD be used with such mechanisms.
436 If the initial client response parameter is not given, or if a
437 protocol's profile does not permit the command which initiates an
438 authentication protocol exchange to contain an initial client
439 response, then the server issues a challenge with no data. The
440 client's response to this challenge is then used as the initial
441 client response. (The server then proceeds to send the next
442 challenge, indicates completion, or indicates failure.)
444 6.2. Server returns success with additional data
446 Some mechanisms may specify that additional data be sent to the
447 client along with an indication of successful completion of the
448 exchange. This data would, for example, authenticate the server to
455 Internet DRAFT SASL April 6, 2002
458 If a protocol's profile does not permit this additional data to be
459 returned with a success indication, then the server issues the data
460 as a server challenge, without an indication of successful
461 completion. The client then responds with no data. After receiving
462 this empty response, the server then indicates successful completion
463 (with no additional data).
465 6.3. Multiple authentications
467 Unless otherwise stated by the protocol's profile, only one
468 successful SASL negotiation may occur in a protocol session. In this
469 case, once an authentication protocol exchange has successfully
470 completed, further attempts to initiate an authentication protocol
473 In the case that a profile explicitly permits multiple successful
474 SASL negotiations to occur, then in no case may multiple security
475 layers be simultaneously in effect. If a security layer is in effect
476 and a subsequent SASL negotiation selects no security layer, the
477 original security layer remains in effect. If a security layer is in
478 effect and a subsequent SASL negotiation selects a second security
479 layer, then the second security layer replaces the first.
481 6.4. Token length limits
483 The section "Protocol profile requirements" specifies a requirement
484 that profiles and implementations be capable of handling
485 authentication tokens of up to a certain size. Protocol profiles and
486 implementations MAY permit tokens of a larger size, but mechanisms
487 cannot depend on implementations permitting larger sizes.
489 Protocol profiles MAY specify a smaller length limit in their
490 optional initial response parameter and/or successful completion
491 challenge field. If the mechanism supplies a larger token than the
492 protocol profile permits in these fields, then the token is sent
493 using the fallback procedures specified in the "Client sends data
494 first" or "Server returns success with additional data" sections.
496 If an implementation knows that all of its supported mechansims
497 conform to a smaller token size limit, it may use the "behave as if"
498 rule to implement that smaller token size limit.
500 7. Registration procedures
502 Registration of a SASL mechanism is done by filling in the template
503 in section 7.4 and sending it in to iana@iana.org. IANA has the
504 right to reject obviously bogus registrations, but will perform no
505 review of claims made in the registration form.
511 Internet DRAFT SASL April 6, 2002
514 There is no naming convention for SASL mechanisms; any name that
515 conforms to the syntax of a SASL mechanism name can be registered.
516 An IETF Standards Track document may reserve a portion of the SASL
517 mechanism namespace for its own use, amending the registration rules
518 for that portion of the namespace.
520 While the registration procedures do not require it, authors of SASL
521 mechanisms are encouraged to seek community review and comment
522 whenever that is feasible. Authors may seek community review by
523 posting a specification of their proposed mechanism as an internet-
524 draft. SASL mechanisms intended for widespread use should be
525 standardized through the normal IETF process, when appropriate.
527 7.1. Comments on SASL mechanism registrations
529 Comments on registered SASL mechanisms should first be sent to the
530 "owner" of the mechanism. Submitters of comments may, after a
531 reasonable attempt to contact the owner, request IANA to attach their
532 comment to the SASL mechanism registration itself. If IANA approves
533 of this the comment will be made accessible in conjunction with the
534 SASL mechanism registration itself.
536 7.2. Location of registered SASL mechanism list
538 SASL mechanism registrations are available at the URL
539 "http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms" The
540 SASL mechanism description and other supporting material may also be
541 published as an Informational RFC by sending it to
542 "rfc-editor@rfc-editor.org" (please follow the instructions to RFC
543 authors [RFC-INSTRUCTIONS]).
547 Once a SASL mechanism registration has been published by IANA, the
548 author may request a change to its definition. The change request
549 follows the same procedure as the registration request.
551 The owner of a SASL mechanism may pass responsibility for the SASL
552 mechanism to another person or agency by informing IANA; this can be
553 done without discussion or review.
555 The IESG may reassign responsibility for a SASL mechanism. The most
556 common case of this will be to enable changes to be made to
557 mechanisms where the author of the registration has died, moved out
558 of contact or is otherwise unable to make changes that are important
561 SASL mechanism registrations may not be deleted; mechanisms which are
567 Internet DRAFT SASL April 6, 2002
570 no longer believed appropriate for use can be declared OBSOLETE by a
571 change to their "intended use" field; such SASL mechanisms will be
572 clearly marked in the lists published by IANA.
574 The IESG is considered to be the owner of all SASL mechanisms which
575 are on the IETF standards track.
577 7.4. Registration template
581 Subject: Registration of SASL mechanism X
585 Security considerations:
587 Published specification (optional, recommended):
589 Person & email address to contact for further information:
593 (One of COMMON, LIMITED USE or OBSOLETE)
595 Owner/Change controller:
597 (Any other information that the author deems interesting may be
598 added below this line.)
600 8. The external mechanism
602 The mechanism name associated with external authentication is
605 The client sends an initial response with the UTF-8 encoding of the
606 authorization identity.
608 The server uses information, external to SASL, to determine whether
609 the client is authorized to authenticate as the authorization
610 identity. If the client is so authorized, the server indicates
611 successful completion of the authentication exchange; otherwise the
612 server indicates failure.
614 The system providing this external information may be, for example,
617 If the client sends the empty string as the authorization identity
623 Internet DRAFT SASL April 6, 2002
626 (thus requesting the authorization identity be derived from the
627 client's authentication credentials), the authorization identity is
628 to be derived from authentication credentials which exist in the
629 system which is providing the external authentication.
633 The following syntax specification uses the augmented Backus-Naur
634 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
635 rules as specified in Appendix A of the ABNF specification [ABNF].
637 The "initial-response" rule below defines the initial response sent
638 from client to server.
640 initial-response = *UTF8
641 UTF8 = %x01-7F / UTF8-2 / UTF8-3 / UTF8-4
642 UTF8-loworder = %x80-BF
643 UTF8-2 = %xC1-DF UTF8-loworder
644 ; Disallow overlong sequences beginning with 0xC0.
645 UTF8-3 = (%xE0 %xA0-BF UTF8-loworder) /
646 (%xE1-EC 2UTF8-loworder) /
647 (%xED %x80-9F UTF8-loworder) /
648 (%xEE 2UTF8-loworder) /
649 (%xEF %x80-BE UTF8-loworder) /
651 ; Disallow overlong sequences beginning with 0xE0,
652 ; disallow encoded surrogate characters, and
653 ; disallow U+FFFE, U+FFFF.
654 UTF8-4 = (%xF0 %x90-BF 2UTF8-loworder) /
655 (%xF1-F7 3UTF8-loworder)
656 ; Disallow overlong sequences beginning with 0xF0.
660 The following is an example of an EXTERNAL authentication in the SMTP
661 protocol [SMTP-AUTH]. In this example, the client is proxy
662 authenticating, sending the authorization id "fred". The server has
663 determined the client's identity through IPsec and has a security
664 policy that permits that identity to proxy authenticate as any other
667 To the protocol profile, the four octet sequence "fred" is an opaque
668 binary blob. The SASL protocol profile for SMTP specifies that
669 server challenges and client responses are encoded in BASE64; the
670 BASE64 encoding of "fred" is "ZnJlZA==".
672 S: 220 smtp.example.com ESMTP server ready
673 C: EHLO jgm.example.com
679 Internet DRAFT SASL April 6, 2002
682 S: 250-smtp.example.com
683 S: 250 AUTH DIGEST-MD5 EXTERNAL
684 C: AUTH EXTERNAL ZnJlZA==
685 S: 235 Authentication successful.
689 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
690 ABNF", RFC 2234, November 1997
692 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and
693 Languages", RFC 2277, January 1998
695 [GSSAPI] Linn, "Generic Security Service Application Program
696 Interface, Version 2, Update 1", RFC 2743, January 2000
698 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
699 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
701 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
702 Requirement Levels", RFC 2119, March 1997
704 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors",
705 RFC 2223, October 1997
707 [SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms", draft-ietf-cat-sasl-
708 gssapi-XX.txt, September 2000
710 [SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC 2444,
713 [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC
718 [UNICODE-NORMALIZATION] Davis, Durst, "Unicode Standard Annex #15:
719 Unicode Normalization Forms", March 2001,
720 http://www.unicode.org/unicode/reports/tr15/ [TODO -- remove?]
722 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
725 10. Security considerations
727 Security issues are discussed throughout this memo.
729 The mechanisms that support integrity protection are designed such
735 Internet DRAFT SASL April 6, 2002
738 that the negotiation of the security layer and authorization identity
739 is integrity protected. When the client selects a security layer
740 with at least integrity protection, this protects against an active
741 attacker hijacking the connection and modifying the authentication
742 exchange to negotiate a plaintext connection.
744 When a server or client supports multiple authentication mechanisms,
745 each of which has a different security strength, it is possible for
746 an active attacker to cause a party to use the least secure mechanism
747 supported. To protect against this sort of attack, a client or
748 server which supports mechanisms of different strengths should have a
749 configurable minimum strength that it will use. It is not sufficient
750 for this minimum strength check to only be on the server, since an
751 active attacker can change which mechanisms the client sees as being
752 supported, causing the client to send authentication credentials for
753 its weakest supported mechanism.
755 The client's selection of a SASL mechanism is done in the clear and
756 may be modified by an active attacker. It is important for any new
757 SASL mechanisms to be designed such that an active attacker cannot
758 obtain an authentication with weaker security properties by modifying
759 the SASL mechanism name and/or the challenges and responses.
761 Any protocol interactions prior to authentication are performed in
762 the clear and may be modified by an active attacker. In the case
763 where a client selects integrity protection, it is important that any
764 security-sensitive protocol negotiations be performed after
765 authentication is complete. Protocols should be designed such that
766 negotiations performed prior to authentication should be either
767 ignored or revalidated once authentication is complete.
769 The EXTERNAL mechanism provides no security protection; it is
770 vulnerable to spoofing by either client or server, active attack, and
771 eavesdropping. It should only be used when external security
772 mechanisms are present and have sufficient strength.
777 Netscape Communications
778 501 E. Middlefield Road
780 Mountain View, CA 94043-4042
782 Email: jgmyers@netscape.com
791 Internet DRAFT SASL April 6, 2002
794 Appendix A. Relation of SASL to transport security
796 Questions have been raised about the relationship between SASL and
797 various services (such as IPsec and TLS) which provide a secured
800 Two of the key features of SASL are:
803 1. The separation of the authorization identity from the identity in
804 the client's credentials. This permits agents such as proxy
805 servers to authenticate using their own credentials, yet request
806 the access privileges of the identity for which they are proxying.
808 2. Upon successful completion of an authentication exchange, the
809 server knows the authorization identity the client wishes to use.
810 This allows servers to move to a "user is authenticated" state in
813 These features are extremely important to some application protocols,
814 yet Transport Security services do not always provide them. To
815 define SASL mechanisms based on these services would be a very messy
816 task, as the framing of these services would be redundant with the
817 framing of SASL and some method of providing these important SASL
818 features would have to be devised.
820 Sometimes it is desired to enable within an existing connection the
821 use of a security service which does not fit the SASL model. (TLS is
822 an example of such a service.) This can be done by adding a command,
823 for example "STARTTLS", to the protocol. Such a command is outside
824 the scope of SASL, and should be different from the command which
825 starts a SASL authentication protocol exchange.
827 In certain situations, it is reasonable to use SASL underneath one of
828 these Transport Security services. The transport service would
829 secure the connection, either service would authenticate the client,
830 and SASL would negotiate the authorization identity. The SASL
831 negotiation would be what moves the protocol from "unauthenticated"
832 to "authenticated" state. The "EXTERNAL" SASL mechanism is
833 explicitly intended to handle the case where the transport service
834 secures the connection and authenticates the client and SASL
835 negotiates the authorization identity.
837 When using SASL underneath a sufficiently strong Transport Security
838 service, a SASL security layer would most likely be redundant. The
839 client and server would thus probably want to negotiate off the use
840 of a SASL security layer.
847 Internet DRAFT SASL April 6, 2002
850 Appendix B. IANA considerations
852 The IANA is directed to modify the SASL mechanisms registry as
856 1. Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
857 registrations to OBSOLETE.
859 2. Change the "Published specification" of the EXTERNAL mechanism to
862 Appendix C. Changes since RFC 2222
864 The GSSAPI mechanism was removed. It is now specified in a separate
865 document [SASL-GSSAPI].
867 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
870 The "SKEY" mechanism described in RFC 2222 is obsolete and has been
871 removed. It has been replaced by the OTP mechanism [SASL-OTP].
873 The overview has been substantially reorganized and clarified.
875 Clarified the definition and semantics of the authorization identity.
877 Prohibited the NULL character in authorization identities.
879 Added a section on character string issues and normalization.
881 The word "must" in the first paragraph of the "Protocol profile
882 requirements" section was changed to "MUST".
884 Added a requirement that protocol profiles and implementations be
885 able to handle tokens of up to 16384 octets.
887 Specified that protocol profiles SHOULD provide a way for clients to
888 discover available SASL mechanisms.
890 Made the requirement that protocol profiles specify the semantics of
891 the authorization identity optional to the protocol profile.
892 Clarified that such a specification is a refinement of the definition
893 in the base SASL spec.
895 Added a requirement discouraging protocol profiles from breaking the
896 separation between protocol and mechanism.
903 Internet DRAFT SASL April 6, 2002
906 Mentioned that standards track documents may carve out their own
907 portions of the SASL mechanism namespace.
909 Specified that the authorization identity in the EXTERNAL mechanism
912 Added a statement that a protocol profile SHOULD allow challenge data
913 to be sent with a success indication.
915 Added a security consideration for the EXTERNAL mechansim.
917 Clarified sections concerning success with addtional data.