Initial release, version 0.0.0.
[gsasl.git] / doc / specification / draft-myers-saslrev-02.txt
blobab833ee248177bc43c7bb374f9ed588ceb36c299
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)
14 Status of this Memo
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
26    ``work in progress''.
28   
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
39    draft is unlimited.
61 J. Myers                                                        [Page i]
63 Internet DRAFT                    SASL                     April 6, 2002
69                            Table of Contents
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
117 J. Myers                                                       [Page ii]
119 Internet DRAFT                    SASL                     April 6, 2002
122 1.    Abstract
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
149    specific protocol.
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
158    server respectively.
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].
164 3.    Overview
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
173 J. Myers                                                        [Page 2]
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            . . .
189                           \-----        |       -----/
190                                 \       |      /
191                                  SASL framework
192                                 /       |      \
193                           /-----        |       -----\
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 "_"
229 J. Myers                                                        [Page 3]
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
267    decisions.
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,
285 J. Myers                                                        [Page 4]
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
299    proxying.
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
306    exchange.
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.
313 4.3.  Security layers
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
341 J. Myers                                                        [Page 5]
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
348    [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
362       mechanism.
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
384       the protocol.
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.
397 J. Myers                                                        [Page 6]
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
424       the design of SASL.
425 6.    Specific issues
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
449    the client.
453 J. Myers                                                        [Page 7]
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
471    exchange fail.
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.
509 J. Myers                                                        [Page 8]
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]).
545 7.3.  Change control
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
559    to the community.
561    SASL mechanism registrations may not be deleted; mechanisms which are
565 J. Myers                                                        [Page 9]
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
580      To: iana@isi.edu
581      Subject: Registration of SASL mechanism X
583      SASL mechanism name:
585      Security considerations:
587      Published specification (optional, recommended):
589      Person & email address to contact for further information:
591      Intended usage:
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
603    "EXTERNAL".
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,
615    IPsec or TLS.
617    If the client sends the empty string as the authorization identity
621 J. Myers                                                       [Page 10]
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.
631 8.1   Formal syntax
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) /
650                     (%xEF %xBF %x80-BD)
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.
658 8.2   Example
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
665    identity.
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
677 J. Myers                                                       [Page 11]
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.
687 9.    References
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,
711    October 1998
713    [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC
714    2554, March 1999
716    [STRINGPREP] [TODO]
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
723    2279, Janyary 1998
725 10.   Security considerations
727    Security issues are discussed throughout this memo.
729    The mechanisms that support integrity protection are designed such
733 J. Myers                                                       [Page 12]
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.
774 11.   Author's address
776    John G. Myers
777    Netscape Communications
778    501 E. Middlefield Road
779    Mail Stop SCA 15:201
780    Mountain View, CA 94043-4042
782    Email: jgmyers@netscape.com
789 J. Myers                                                       [Page 13]
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
798    connection.
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
811       the protocol.
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.
845 J. Myers                                                       [Page 14]
847 Internet DRAFT                    SASL                     April 6, 2002
850 Appendix B. IANA considerations
852    The IANA is directed to modify the SASL mechanisms registry as
853    follows:
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
860       this document.
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
868    been removed.
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.
901 J. Myers                                                       [Page 15]
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
910    is encoded in UTF-8.
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.
957 J. Myers                                                       [Page 16]