]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2222.txt
Add SASL RFC
[openldap] / doc / rfc / rfc2222.txt
1
2
3
4
5
6
7 Network Working Group                                           J. Myers
8 Request for Comments: 2222                       Netscape Communications
9 Category: Standards Track                                   October 1997
10
11
12             Simple Authentication and Security Layer (SASL)
13
14 Status of this Memo
15
16    This document specifies an Internet standards track protocol for the
17    Internet community, and requests discussion and suggestions for
18    improvements.  Please refer to the current edition of the "Internet
19    Official Protocol Standards" (STD 1) for the standardization state
20    and status of this protocol.  Distribution of this memo is unlimited.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (1997).  All Rights Reserved.
25
26 Table of Contents
27
28    1.    Abstract ..............................................    2
29    2.    Organization of this Document .........................    2
30    2.1.  How to Read This Document .............................    2
31    2.2.  Conventions Used in this Document .....................    2
32    2.3.  Examples ..............................................    3
33    3.    Introduction and Overview .............................    3
34    4.    Profiling requirements ................................    4
35    5.    Specific issues .......................................    5
36    5.1.  Client sends data first ...............................    5
37    5.2.  Server returns success with additional data ...........    5
38    5.3.  Multiple authentications ..............................    5
39    6.    Registration procedures ...............................    6
40    6.1.  Comments on SASL mechanism registrations ..............    6
41    6.2.  Location of Registered SASL Mechanism List ............    6
42    6.3.  Change Control ........................................    7
43    6.4.  Registration Template .................................    7
44    7.    Mechanism definitions .................................    8
45    7.1.  Kerberos version 4 mechanism ..........................    8
46    7.2.  GSSAPI mechanism ......................................    9
47    7.2.1 Client side of authentication protocol exchange .......    9
48    7.2.2 Server side of authentication protocol exchange .......   10
49    7.2.3 Security layer ........................................   11
50    7.3.  S/Key mechanism .......................................   11
51    7.4.  External mechanism ....................................   12
52    8.    References ............................................   13
53    9.    Security Considerations ...............................   13
54    10.   Author's Address ......................................   14
55
56
57
58 Myers                       Standards Track                     [Page 1]
59 \f
60 RFC 2222                          SASL                      October 1997
61
62
63    Appendix A. Relation of SASL to Transport Security ..........   15
64    Full Copyright Statement ....................................   16
65
66 1.    Abstract
67
68    This document describes a method for adding authentication support to
69    connection-based protocols.  To use this specification, a protocol
70    includes a command for identifying and authenticating a user to a
71    server and for optionally negotiating protection of subsequent
72    protocol interactions.  If its use is negotiated, a security layer is
73    inserted between the protocol and the connection.  This document
74    describes how a protocol specifies such a command, defines several
75    mechanisms for use by the command, and defines the protocol used for
76    carrying a negotiated security layer over the connection.
77
78 2.    Organization of this Document
79
80 2.1.  How to Read This Document
81
82    This document is written to serve two different audiences, protocol
83    designers using this specification to support authentication in their
84    protocol, and implementors of clients or servers for those protocols
85    using this specification.
86
87    The sections "Introduction and Overview", "Profiling requirements",
88    and "Security Considerations" cover issues that protocol designers
89    need to understand and address in profiling this specification for
90    use in a specific protocol.
91
92    Implementors of a protocol using this specification need the
93    protocol-specific profiling information in addition to the
94    information in this document.
95
96 2.2.  Conventions Used in this Document
97
98    In examples, "C:" and "S:" indicate lines sent by the client and
99    server respectively.
100
101    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
102    in this document are to be interpreted as defined in "Key words for
103    use in RFCs to Indicate Requirement Levels" [RFC 2119].
104
105
106
107
108
109
110
111
112
113
114 Myers                       Standards Track                     [Page 2]
115 \f
116 RFC 2222                          SASL                      October 1997
117
118
119 2.3.  Examples
120
121    Examples in this document are for the IMAP profile [RFC 2060] of this
122    specification.  The base64 encoding of challenges and responses, as
123    well as the "+ " preceding the responses are part of the IMAP4
124    profile, not part of the SASL specification itself.
125
126 3.    Introduction and Overview
127
128    The Simple Authentication and Security Layer (SASL) is a method for
129    adding authentication support to connection-based protocols.  To use
130    this specification, a protocol includes a command for identifying and
131    authenticating a user to a server and for optionally negotiating a
132    security layer for subsequent protocol interactions.
133
134    The command has a required argument identifying a SASL mechanism.
135    SASL mechanisms are named by strings, from 1 to 20 characters in
136    length, consisting of upper-case letters, digits, hyphens, and/or
137    underscores.  SASL mechanism names must be registered with the IANA.
138    Procedures for registering new SASL mechanisms are given in the
139    section "Registration procedures"
140
141    If a server supports the requested mechanism, it initiates an
142    authentication protocol exchange.  This consists of a series of
143    server challenges and client responses that are specific to the
144    requested mechanism.  The challenges and responses are defined by the
145    mechanisms as binary tokens of arbitrary length.  The protocol's
146    profile then specifies how these binary tokens are then encoded for
147    transfer over the connection.
148
149    After receiving the authentication command or any client response, a
150    server may issue a challenge, indicate failure, or indicate
151    completion.  The protocol's profile specifies how the server
152    indicates which of the above it is doing.
153
154    After receiving a challenge, a client may issue a response or abort
155    the exchange.  The protocol's profile specifies how the client
156    indicates which of the above it is doing.
157
158    During the authentication protocol exchange, the mechanism performs
159    authentication, transmits an authorization identity (frequently known
160    as a userid) from the client to server, and negotiates the use of a
161    mechanism-specific security layer.  If the use of a security layer is
162    agreed upon, then the mechanism must also define or negotiate the
163    maximum cipher-text buffer size that each side is able to receive.
164
165
166
167
168
169
170 Myers                       Standards Track                     [Page 3]
171 \f
172 RFC 2222                          SASL                      October 1997
173
174
175    The transmitted authorization identity may be different than the
176    identity in the client's authentication credentials.  This permits
177    agents such as proxy servers to authenticate using their own
178    credentials, yet request the access privileges of the identity for
179    which they are proxying.  With any mechanism, transmitting an
180    authorization identity of the empty string directs the server to
181    derive an authorization identity from the client's authentication
182    credentials.
183
184    If use of a security layer is negotiated, it is applied to all
185    subsequent data sent over the connection.  The security layer takes
186    effect immediately following the last response of the authentication
187    exchange for data sent by the client and the completion indication
188    for data sent by the server.  Once the security layer is in effect,
189    the protocol stream is processed by the security layer into buffers
190    of cipher-text.  Each buffer is transferred over the connection as a
191    stream of octets prepended with a four octet field in network byte
192    order that represents the length of the following buffer.  The length
193    of the cipher-text buffer must be no larger than the maximum size
194    that was defined or negotiated by the other side.
195
196 4.    Profiling requirements
197
198    In order to use this specification, a protocol definition must supply
199    the following information:
200
201    1. A service name, to be selected from the IANA registry of "service"
202       elements for the GSSAPI host-based service name form [RFC 2078].
203
204    2. A definition of the command to initiate the authentication
205       protocol exchange.  This command must have as a parameter the
206       mechanism name being selected by the client.
207
208       The command SHOULD have an optional parameter giving an initial
209       response.  This optional parameter allows the client to avoid a
210       round trip when using a mechanism which is defined to have the
211       client send data first.  When this initial response is sent by the
212       client and the selected mechanism is defined to have the server
213       start with an initial challenge, the command fails.  See section
214       5.1 of this document for further information.
215
216    3. A definition of the method by which the authentication protocol
217       exchange is carried out, including how the challenges and
218       responses are encoded, how the server indicates completion or
219       failure of the exchange, how the client aborts an exchange, and
220       how the exchange method interacts with any line length limits in
221       the protocol.
222
223
224
225
226 Myers                       Standards Track                     [Page 4]
227 \f
228 RFC 2222                          SASL                      October 1997
229
230
231    4. Identification of the octet where any negotiated security layer
232       starts to take effect, in both directions.
233
234    5. A specification of how the authorization identity passed from the
235       client to the server is to be interpreted.
236
237 5.    Specific issues
238
239 5.1.  Client sends data first
240
241    Some mechanisms specify that the first data sent in the
242    authentication protocol exchange is from the client to the server.
243
244    If a protocol's profile permits the command which initiates an
245    authentication protocol exchange to contain an initial client
246    response, this parameter SHOULD be used with such mechanisms.
247
248    If the initial client response parameter is not given, or if a
249    protocol's profile does not permit the command which initiates an
250    authentication protocol exchange to contain an initial client
251    response, then the server issues a challenge with no data.  The
252    client's response to this challenge is then used as the initial
253    client response.  (The server then proceeds to send the next
254    challenge, indicates completion, or indicates failure.)
255
256 5.2.  Server returns success with additional data
257
258    Some mechanisms may specify that server challenge data be sent to the
259    client along with an indication of successful completion of the
260    exchange.  This data would, for example, authenticate the server to
261    the client.
262
263    If a protocol's profile does not permit this server challenge to be
264    returned with a success indication, then the server issues the server
265    challenge without an indication of successful completion.  The client
266    then responds with no data.  After receiving this empty response, the
267    server then indicates successful completion.
268
269 5.3.  Multiple authentications
270
271    Unless otherwise stated by the protocol's profile, only one
272    successful SASL negotiation may occur in a protocol session.  In this
273    case, once an authentication protocol exchange has successfully
274    completed, further attempts to initiate an authentication protocol
275    exchange fail.
276
277
278
279
280
281
282 Myers                       Standards Track                     [Page 5]
283 \f
284 RFC 2222                          SASL                      October 1997
285
286
287    In the case that a profile explicitly permits multiple successful
288    SASL negotiations to occur, then in no case may multiple security
289    layers be simultaneously in effect.  If a security layer is in effect
290    and a subsequent SASL negotiation selects no security layer, the
291    original security layer remains in effect.  If a security layer is in
292    effect and a subsequent SASL negotiation selects a second security
293    layer, then the second security layer replaces the first.
294
295 6.    Registration procedures
296
297    Registration of a SASL mechanism is done by filling in the template
298    in section 6.4 and sending it in to iana@isi.edu.  IANA has the right
299    to reject obviously bogus registrations, but will perform no review
300    of clams made in the registration form.
301
302    There is no naming convention for SASL mechanisms; any name that
303    conforms to the syntax of a SASL mechanism name can be registered.
304
305    While the registration procedures do not require it, authors of SASL
306    mechanisms are encouraged to seek community review and comment
307    whenever that is feasible.  Authors may seek community review by
308    posting a specification of their proposed mechanism as an internet-
309    draft.  SASL mechanisms intended for widespread use should be
310    standardized through the normal IETF process, when appropriate.
311
312 6.1.  Comments on SASL mechanism registrations
313
314    Comments on registered SASL mechanisms should first be sent to the
315    "owner" of the mechanism.  Submitters of comments may, after a
316    reasonable attempt to contact the owner, request IANA to attach their
317    comment to the SASL mechanism registration itself.  If IANA approves
318    of this the comment will be made accessible in conjunction with the
319    SASL mechanism registration itself.
320
321 6.2.  Location of Registered SASL Mechanism List
322
323    SASL mechanism registrations will be posted in the anonymous FTP
324    directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
325    mechanisms/" and all registered SASL mechanisms will be listed in the
326    periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
327    1700].  The SASL mechanism description and other supporting material
328    may also be published as an Informational RFC by sending it to "rfc-
329    editor@isi.edu" (please follow the instructions to RFC authors [RFC
330    2223]).
331
332
333
334
335
336
337
338 Myers                       Standards Track                     [Page 6]
339 \f
340 RFC 2222                          SASL                      October 1997
341
342
343 6.3.  Change Control
344
345    Once a SASL mechanism registration has been published by IANA, the
346    author may request a change to its definition.  The change request
347    follows the same procedure as the registration request.
348
349    The owner of a SASL mechanism may pass responsibility for the SASL
350    mechanism to another person or agency by informing IANA; this can be
351    done without discussion or review.
352
353    The IESG may reassign responsibility for a SASL mechanism. The most
354    common case of this will be to enable changes to be made to
355    mechanisms where the author of the registration has died, moved out
356    of contact or is otherwise unable to make changes that are important
357    to the community.
358
359    SASL mechanism registrations may not be deleted; mechanisms which are
360    no longer believed appropriate for use can be declared OBSOLETE by a
361    change to their "intended use" field; such SASL mechanisms will be
362    clearly marked in the lists published by IANA.
363
364    The IESG is considered to be the owner of all SASL mechanisms which
365    are on the IETF standards track.
366
367 6.4.  Registration Template
368
369    To: iana@iana.org
370    Subject: Registration of SASL mechanism X
371
372    SASL mechanism name:
373
374    Security considerations:
375
376    Published specification (optional, recommended):
377
378    Person & email address to contact for further information:
379
380    Intended usage:
381
382    (One of COMMON, LIMITED USE or OBSOLETE)
383
384    Author/Change controller:
385
386    (Any other information that the author deems interesting may be
387    added below this line.)
388
389
390
391
392
393
394 Myers                       Standards Track                     [Page 7]
395 \f
396 RFC 2222                          SASL                      October 1997
397
398
399 7.    Mechanism definitions
400
401    The following mechanisms are hereby defined.
402
403 7.1.  Kerberos version 4 mechanism
404
405    The mechanism name associated with Kerberos version 4 is
406    "KERBEROS_V4".
407
408    The first challenge consists of a random 32-bit number in network
409    byte order.  The client responds with a Kerberos ticket and an
410    authenticator for the principal "service.hostname@realm", where
411    "service" is the service name specified in the protocol's profile,
412    "hostname" is the first component of the host name of the server with
413    all letters in lower case, and where "realm" is the Kerberos realm of
414    the server.  The encrypted checksum field included within the
415    Kerberos authenticator contains the server provided challenge in
416    network byte order.
417
418    Upon decrypting and verifying the ticket and authenticator, the
419    server verifies that the contained checksum field equals the original
420    server provided random 32-bit number.  Should the verification be
421    successful, the server must add one to the checksum and construct 8
422    octets of data, with the first four octets containing the incremented
423    checksum in network byte order, the fifth octet containing a bit-mask
424    specifying the security layers supported by the server, and the sixth
425    through eighth octets containing, in network byte order, the maximum
426    cipher-text buffer size the server is able to receive.  The server
427    must encrypt using DES ECB mode the 8 octets of data in the session
428    key and issue that encrypted data in a second challenge.  The client
429    considers the server authenticated if the first four octets of the
430    un-encrypted data is equal to one plus the checksum it previously
431    sent.
432
433    The client must construct data with the first four octets containing
434    the original server-issued checksum in network byte order, the fifth
435    octet containing the bit-mask specifying the selected security layer,
436    the sixth through eighth octets containing in network byte order the
437    maximum cipher-text buffer size the client is able to receive, and
438    the following octets containing the authorization identity.  The
439    client must then append from one to eight zero-valued octets so that
440    the length of the data is a multiple of eight octets. The client must
441    then encrypt using DES PCBC mode the data with the session key and
442    respond with the encrypted data.  The server decrypts the data and
443    verifies the contained checksum.  The server must verify that the
444    principal identified in the Kerberos ticket is authorized to connect
445    as that authorization identity.  After this verification, the
446    authentication process is complete.
447
448
449
450 Myers                       Standards Track                     [Page 8]
451 \f
452 RFC 2222                          SASL                      October 1997
453
454
455    The security layers and their corresponding bit-masks are as follows:
456
457       1 No security layer
458       2 Integrity (krb_mk_safe) protection
459       4 Privacy (krb_mk_priv) protection
460
461    Other bit-masks may be defined in the future; bits which are not
462    understood must be negotiated off.
463
464    EXAMPLE: The following are two Kerberos version 4 login scenarios to
465    the IMAP4 protocol (note that the line breaks in the sample
466    authenticators are for editorial clarity and are not in real
467    authenticators)
468
469      S: * OK IMAP4 Server
470      C: A001 AUTHENTICATE KERBEROS_V4
471      S: + AmFYig==
472      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
473         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
474         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
475      S: + or//EoAADZI=
476      C: DiAF5A4gA+oOIALuBkAAmw==
477      S: A001 OK Kerberos V4 authentication successful
478
479
480      S: * OK IMAP4 Server
481      C: A001 AUTHENTICATE KERBEROS_V4
482      S: + gcfgCA==
483      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
484         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
485         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
486      S: A001 NO Kerberos V4 authentication failed
487
488 7.2.  GSSAPI mechanism
489
490    The mechanism name associated with all mechanisms employing the
491    GSSAPI [RFC 2078] is "GSSAPI".
492
493 7.2.1 Client side of authentication protocol exchange
494
495    The client calls GSS_Init_sec_context, passing in 0 for
496    input_context_handle (initially) and a targ_name equal to output_name
497    from GSS_Import_Name called with input_name_type of
498    GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
499    "service@hostname" where "service" is the service name specified in
500    the protocol's profile, and "hostname" is the fully qualified host
501    name of the server.  The client then responds with the resulting
502    output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
503
504
505
506 Myers                       Standards Track                     [Page 9]
507 \f
508 RFC 2222                          SASL                      October 1997
509
510
511    then the client should expect the server to issue a token in a
512    subsequent challenge.  The client must pass the token to another call
513    to GSS_Init_sec_context, repeating the actions in this paragraph.
514
515    When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
516    the following actions: If the last call to GSS_Init_sec_context
517    returned an output_token, then the client responds with the
518    output_token, otherwise the client responds with no data.  The client
519    should then expect the server to issue a token in a subsequent
520    challenge.  The client passes this token to GSS_Unwrap and interprets
521    the first octet of resulting cleartext as a bit-mask specifying the
522    security layers supported by the server and the second through fourth
523    octets as the maximum size output_message to send to the server.  The
524    client then constructs data, with the first octet containing the
525    bit-mask specifying the selected security layer, the second through
526    fourth octets containing in network byte order the maximum size
527    output_message the client is able to receive, and the remaining
528    octets containing the authorization identity.  The client passes the
529    data to GSS_Wrap with conf_flag set to FALSE, and responds with the
530    generated output_message.  The client can then consider the server
531    authenticated.
532
533 7.2.2 Server side of authentication protocol exchange
534
535    The server passes the initial client response to
536    GSS_Accept_sec_context as input_token, setting input_context_handle
537    to 0 (initially).  If GSS_Accept_sec_context returns
538    GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
539    to the client in challenge and passes the resulting response to
540    another call to GSS_Accept_sec_context, repeating the actions in this
541    paragraph.
542
543    When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
544    the following actions: If the last call to GSS_Accept_sec_context
545    returned an output_token, the server returns it to the client in a
546    challenge and expects a reply from the client with no data.  Whether
547    or not an output_token was returned (and after receipt of any
548    response from the client to such an output_token), the server then
549    constructs 4 octets of data, with the first octet containing a bit-
550    mask specifying the security layers supported by the server and the
551    second through fourth octets containing in network byte order the
552    maximum size output_token the server is able to receive.  The server
553    must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
554    and issue the generated output_message to the client in a challenge.
555    The server must then pass the resulting response to GSS_Unwrap and
556    interpret the first octet of resulting cleartext as the bit-mask for
557    the selected security layer, the second through fourth octets as the
558    maximum size output_message to send to the client, and the remaining
559
560
561
562 Myers                       Standards Track                    [Page 10]
563 \f
564 RFC 2222                          SASL                      October 1997
565
566
567    octets as the authorization identity.  The server must verify that
568    the src_name is authorized to authenticate as the authorization
569    identity.  After these verifications, the authentication process is
570    complete.
571
572 7.2.3 Security layer
573
574    The security layers and their corresponding bit-masks are as follows:
575
576      1 No security layer
577      2 Integrity protection.
578        Sender calls GSS_Wrap with conf_flag set to FALSE
579      4 Privacy protection.
580        Sender calls GSS_Wrap with conf_flag set to TRUE
581
582    Other bit-masks may be defined in the future; bits which are not
583    understood must be negotiated off.
584
585 7.3.  S/Key mechanism
586
587    The mechanism name associated with S/Key [RFC 1760] using the MD4
588    digest algorithm is "SKEY".
589
590    The client sends an initial response with the authorization identity.
591
592    The server then issues a challenge which contains the decimal
593    sequence number followed by a single space and the seed string for
594    the indicated authorization identity.  The client responds with the
595    one-time-password, as either a 64-bit value in network byte order or
596    encoded in the "six English words" format.
597
598    The server must verify the one-time-password.  After this
599    verification, the authentication process is complete.
600
601    S/Key authentication does not provide for any security layers.
602
603    EXAMPLE: The following are two S/Key login scenarios in the IMAP4
604    protocol.
605
606      S: * OK IMAP4 Server
607      C: A001 AUTHENTICATE SKEY
608      S: +
609      C: bW9yZ2Fu
610      S: + OTUgUWE1ODMwOA==
611      C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
612      S: A001 OK S/Key authentication successful
613
614
615
616
617
618 Myers                       Standards Track                    [Page 11]
619 \f
620 RFC 2222                          SASL                      October 1997
621
622
623      S: * OK IMAP4 Server
624      C: A001 AUTHENTICATE SKEY
625      S: +
626      C: c21pdGg=
627      S: + OTUgUWE1ODMwOA==
628      C: BsAY3g4gBNo=
629      S: A001 NO S/Key authentication failed
630
631    The following is an S/Key login scenario in an IMAP4-like protocol
632    which has an optional "initial response" argument to the AUTHENTICATE
633    command.
634
635      S: * OK IMAP4-Like Server
636      C: A001 AUTHENTICATE SKEY bW9yZ2Fu
637      S: + OTUgUWE1ODMwOA==
638      C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
639      S: A001 OK S/Key authentication successful
640
641 7.4.  External mechanism
642
643    The mechanism name associated with external authentication is
644    "EXTERNAL".
645
646    The client sends an initial response with the authorization identity.
647
648    The server uses information, external to SASL, to determine whether
649    the client is authorized to authenticate as the authorization
650    identity.  If the client is so authorized, the server indicates
651    successful completion of the authentication exchange; otherwise the
652    server indicates failure.
653
654    The system providing this external information may be, for example,
655    IPsec or TLS.
656
657    If the client sends the empty string as the authorization identity
658    (thus requesting the authorization identity be derived from the
659    client's authentication credentials), the authorization identity is
660    to be derived from authentication credentials which exist in the
661    system which is providing the external authentication.
662
663
664
665
666
667
668
669
670
671
672
673
674 Myers                       Standards Track                    [Page 12]
675 \f
676 RFC 2222                          SASL                      October 1997
677
678
679 8.    References
680
681    [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
682               4rev1", RFC 2060, December 1996.
683
684    [RFC 2078] Linn, J., "Generic Security Service Application Program
685               Interface, Version 2", RFC 2078, January 1997.
686
687    [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
688               Requirement Levels", RFC 2119, March 1997.
689
690    [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
691               Authors", RFC 2223, October 1997.
692
693    [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
694               1760, February 1995.
695
696    [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
697               RFC 1700, October 1994.
698
699 9.    Security Considerations
700
701    Security issues are discussed throughout this memo.
702
703    The mechanisms that support integrity protection are designed such
704    that the negotiation of the security layer and authorization identity
705    is integrity protected.  When the client selects a security layer
706    with at least integrity protection, this protects against an active
707    attacker hijacking the connection and modifying the authentication
708    exchange to negotiate a plaintext connection.
709
710    When a server or client supports multiple authentication mechanisms,
711    each of which has a different security strength, it is possible for
712    an active attacker to cause a party to use the least secure mechanism
713    supported.  To protect against this sort of attack, a client or
714    server which supports mechanisms of different strengths should have a
715    configurable minimum strength that it will use.  It is not sufficient
716    for this minimum strength check to only be on the server, since an
717    active attacker can change which mechanisms the client sees as being
718    supported, causing the client to send authentication credentials for
719    its weakest supported mechanism.
720
721
722
723
724
725
726
727
728
729
730 Myers                       Standards Track                    [Page 13]
731 \f
732 RFC 2222                          SASL                      October 1997
733
734
735    The client's selection of a SASL mechanism is done in the clear and
736    may be modified by an active attacker.  It is important for any new
737    SASL mechanisms to be designed such that an active attacker cannot
738    obtain an authentication with weaker security properties by modifying
739    the SASL mechanism name and/or the challenges and responses.
740
741    Any protocol interactions prior to authentication are performed in
742    the clear and may be modified by an active attacker.  In the case
743    where a client selects integrity protection, it is important that any
744    security-sensitive protocol negotiations be performed after
745    authentication is complete.  Protocols should be designed such that
746    negotiations performed prior to authentication should be either
747    ignored or revalidated once authentication is complete.
748
749 10.   Author's Address
750
751    John G. Myers
752    Netscape Communications
753    501 E. Middlefield Road
754    Mail Stop MV-029
755    Mountain View, CA 94043-4042
756
757    EMail: jgmyers@netscape.com
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786 Myers                       Standards Track                    [Page 14]
787 \f
788 RFC 2222                          SASL                      October 1997
789
790
791 Appendix A. Relation of SASL to Transport Security
792
793    Questions have been raised about the relationship between SASL and
794    various services (such as IPsec and TLS) which provide a secured
795    connection.
796
797    Two of the key features of SASL are:
798
799    1. The separation of the authorization identity from the identity in
800       the client's credentials.  This permits agents such as proxy
801       servers to authenticate using their own credentials, yet request
802       the access privileges of the identity for which they are proxying.
803
804    2. Upon successful completion of an authentication exchange, the
805       server knows the authorization identity the client wishes to use.
806       This allows servers to move to a "user is authenticated" state in
807       the protocol.
808
809    These features are extremely important to some application protocols,
810    yet Transport Security services do not always provide them.  To
811    define SASL mechanisms based on these services would be a very messy
812    task, as the framing of these services would be redundant with the
813    framing of SASL and some method of providing these important SASL
814    features would have to be devised.
815
816    Sometimes it is desired to enable within an existing connection the
817    use of a security service which does not fit the SASL model.  (TLS is
818    an example of such a service.)  This can be done by adding a command,
819    for example "STARTTLS", to the protocol.  Such a command is outside
820    the scope of SASL, and should be different from the command which
821    starts a SASL authentication protocol exchange.
822
823    In certain situations, it is reasonable to use SASL underneath one of
824    these Transport Security services.  The transport service would
825    secure the connection, either service would authenticate the client,
826    and SASL would negotiate the authorization identity.  The SASL
827    negotiation would be what moves the protocol from "unauthenticated"
828    to "authenticated" state.  The "EXTERNAL" SASL mechanism is
829    explicitly intended to handle the case where the transport service
830    secures the connection and authenticates the client and SASL
831    negotiates the authorization identity.
832
833    When using SASL underneath a sufficiently strong Transport Security
834    service, a SASL security layer would most likely be redundant.  The
835    client and server would thus probably want to negotiate off the use
836    of a SASL security layer.
837
838
839
840
841
842 Myers                       Standards Track                    [Page 15]
843 \f
844 RFC 2222                          SASL                      October 1997
845
846
847 Full Copyright Statement
848
849    Copyright (C) The Internet Society (1997).  All Rights Reserved.
850
851    This document and translations of it may be copied and furnished to
852    others, and derivative works that comment on or otherwise explain it
853    or assist in its implmentation may be prepared, copied, published
854    andand distributed, in whole or in part, without restriction of any
855    kind, provided that the above copyright notice and this paragraph are
856    included on all such copies and derivative works.  However, this
857    document itself may not be modified in any way, such as by removing
858    the copyright notice or references to the Internet Society or other
859    Internet organizations, except as needed for the purpose of
860    developing Internet standards in which case the procedures for
861    copyrights defined in the Internet Standards process must be
862    followed, or as required to translate it into languages other than
863    English.
864
865    The limited permissions granted above are perpetual and will not be
866    revoked by the Internet Society or its successors or assigns.
867
868    This document and the information contained herein is provided on an
869    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
870    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
871    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
872    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
873    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898 Myers                       Standards Track                    [Page 16]
899 \f