idnits 2.17.1 draft-myers-auth-sasl-09.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 62 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 72: '... 1) MUST, or the adjective REQUIRED,...' RFC 2119 keyword, line 75: '... 2) MUST NOT that the definition is ...' RFC 2119 keyword, line 78: '... 3) SHOULD means that there may exis...' RFC 2119 keyword, line 80: '... MUST be understood and carefully we...' RFC 2119 keyword, line 85: '... 4) SHOULD NOT means that there may ...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9844 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 2078 (ref. 'GSSAPI') (Obsoleted by RFC 2743) ** Obsolete normative reference: RFC 1543 (Obsoleted by RFC 2223) ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'SKEY') Summary: 16 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft April 1997 4 Document: draft-myers-auth-sasl-09.txt 6 Simple Authentication and Security Layer (SASL) 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before December 1996. Distribution of this draft is 30 unlimited. 32 Internet DRAFT SASL April 16, 1997 34 1. Abstract 36 This document describes a method for adding authentication support to 37 connection-based protocols. To use this specification, a protocol 38 includes a command for identifying and authenticating a user to a 39 server and for optionally negotiating protection of subsequent 40 protocol interactions. If its use is negotiated, a security layer is 41 inserted between the protocol and the connection. This document 42 describes how a protocol specifies such a command, defines several 43 mechanisms for use by the command, and defines the protocol used for 44 carrying a negotiated security layer over the connection. 46 2. Organization of this Document 48 2.1. How to Read This Document 50 This document is written to serve two different audiences, protocol 51 designers using this specification to support authentication in their 52 protocol, and implementors of clients or servers for those protocols 53 using this specification. 55 The sections "Introduction and Overview", "Profiling requirements", 56 and "Security Considerations" cover issues that protocol designers 57 need to understand and address in profiling this specification for 58 use in a specific protocol. 60 Implementors of a protocol using this specification need the 61 protocol-specific profiling information in addition to the 62 information in this document. 64 2.2. Conventions Used in this Document 66 In examples, "C:" and "S:" indicate lines sent by the client and 67 server respectively. 69 The following terms are used in this document to signify the 70 requirements of this specification. 72 1) MUST, or the adjective REQUIRED, means that the definition is an 73 absolute requirement of the specification. 75 2) MUST NOT that the definition is an absolute prohibition of the 76 specification. 78 3) SHOULD means that there may exist valid reasons in particular 79 circumstances to ignore a particular item, but the full implications 80 MUST be understood and carefully weighed before choosing a different 81 course. 83 Internet DRAFT SASL April 16, 1997 85 4) SHOULD NOT means that there may exist valid reasons in particular 86 circumstances when the particular behavior is acceptable or even 87 useful, but the full implications SHOULD be understood and the case 88 carefully weighed before implementing any behavior described with 89 this label. 91 5) MAY, or the adjective OPTIONAL, means that an item is truly 92 optional. One vendor may choose to include the item because a 93 particular marketplace requires it or because the vendor feels that 94 it enhances the product while another vendor may omit the same item. 95 An implementation which does not include a particular option MUST be 96 prepared to interoperate with another implementation which does 97 include the option. 99 "Can" is used instead of "may" when referring to a possible 100 circumstance or situation, as opposed to an optional facility of the 101 protocol. 103 2.3. Examples 105 Examples in this document are for the IMAP profile [IMAP4] of this 106 specification. The base64 encoding of challenges and responses, as 107 well as the "+ " preceding the responses are part of the IMAP4 108 profile, not part of the SASL specification itself. 110 3. Introduction and Overview 112 The Simple Authentication and Security Layer (SASL) is a method for 113 adding authentication support to connection-based protocols. To use 114 this specification, a protocol includes a command for identifying and 115 authenticating a user to a server and for optionally negotiating a 116 security layer for subsequent protocol interactions. 118 The command has a single argument, identifying a SASL mechanism. 119 SASL mechanisms are named by strings, from 1 to 20 characters in 120 length, consisting of upper-case letters, digits, hyphens, and/or 121 underscores. SASL mechanism names must be registered with the IANA. 122 Procedures for registering new SASL mechanisms are given in the 123 section "Registration procedures" 125 If a server supports the requested mechanism, it initiates an 126 authentication protocol exchange. This consists of a series of 127 server challenges and client responses that are specific to the 128 requested mechanism. The challenges and responses are defined by the 129 mechanisms as binary tokens of arbitrary length. The protocol's 130 profile then specifies how these binary tokens are then encoded for 131 transfer over the connection. 133 Internet DRAFT SASL April 16, 1997 135 After receiving the authentication command or any client response, a 136 server may issue a challenge, indicate failure, or indicate 137 completion. The protocol's profile specifies how the server 138 indicates which of the above it is doing. 140 After receiving a challenge, a client may issue a response or abort 141 the exchange. The protocol's profile specifies how the client 142 indicates which of the above it is doing. 144 During the authentication protocol exchange, the mechanism performs 145 authentication, transmits an authorization identity (frequently known 146 as a userid) from the client to server, and negotiates the use of a 147 mechanism-specific security layer. If the use of a security layer is 148 agreed upon, then the mechanism must also define or negotiate the 149 maximum cipher-text buffer size that each side is able to receive. 151 The transmitted authorization identity may be different than the 152 identity in the client's authentication credentials. This permits 153 agents such as proxy servers to authenticate using their own 154 credentials, yet request the access privileges of the identity for 155 which they are proxying. With any mechanism, transmitting an 156 authorization identity of the null string directs the server to 157 derive an authorization identity from the client's authentication 158 credentials. 160 If use of a security layer is negotiated, it is applied to all 161 subsequent data sent over the connection. The security layer takes 162 effect immediately following the last response of the authentication 163 exchange for data sent by the client and the completion indication 164 for data sent by the server. Once the security layer is in effect, 165 the protocol stream is processed by the security layer into buffers 166 of cipher-text. Each buffer is transferred over the connection as a 167 stream of octets prepended with a four octet field in network byte 168 order that represents the length of the following buffer. The length 169 of the cipher-text buffer must be no larger than the maximum size 170 that was defined or negotiated by the other side. 172 4. Profiling requirements 174 In order to use this specification, a protocol definition must supply 175 the following information: 177 1. A service name, to be selected from the IANA registry of "service" 178 elements for the GSSAPI host-based service name form. [GSSAPI] 180 2. A definition of the command to initiate the authentication 181 protocol exchange. This command must have as a parameter the 183 Internet DRAFT SASL April 16, 1997 185 mechanism name being selected by the client. 187 The command SHOULD have an optional parameter giving an initial 188 response. This optional parameter allows the client to avoid a 189 round trip when using a mechanism which is defined to have the 190 client send data first. When this initial response is sent by the 191 client and the selected mechanism is defined to have the server 192 start with an initial challenge, the command fails. See section 193 5.1 of this document for further information. 195 3. A definition of the method by which the authentication protocol 196 exchange is carried out, including how the challenges and 197 responses are encoded, how the server indicates completion or 198 failure of the exchange, how the client aborts an exchange, and 199 how the exchange method interacts with any line length limits in 200 the protocol. 202 4. Identification of the octet where any negotiated security layer 203 starts to take effect, in both directions. 205 5. A specification of how the authorization identity passed from the 206 client to the server is to be interpreted. 208 5. Specific issues 210 5.1. Client sends data first 212 Some mechanisms specify that the first data sent in the 213 authentication protocol exchange is from the client to the server. 215 If a protocol's profile permits the command which initiates an 216 authentication protocol exchange to contain an initial client 217 response, this parameter SHOULD be used with such mechanisms. 219 If the initial client response parameter is not given, or if a 220 protocol's profile does not permit the command which initiates an 221 authentication protocol exchange to contain an initial client 222 response, then the server issues a challenge with no data. The 223 client's response to this challenge is then used as the initial 224 client response. (The server then proceeds to send the next 225 challenge, indicates completion, or indicates failure.) 227 5.2. Server returns success with additional data 229 Some mechanisms may specify that server challenge data be sent to the 230 client along with an indication of successful completion of the 231 exchange. This data would, for example, authenticate the server to 232 the client. 234 Internet DRAFT SASL April 16, 1997 236 If a protocol's profile does not permit this server challenge to be 237 returned with a success indication, then the server issues the server 238 challenge without an indication of successful completion. The client 239 then responds with no data. After receiving this empty response, the 240 server then indicates successful completion. 242 5.3. Multiple authentications 244 Unless otherwise stated by the protocol's profile, only one 245 successful SASL negotiation may occur in a protocol session. In this 246 case, once an authentication protocol exchange has successfully 247 completed, further attempts to initiate an authentication protocol 248 exchange fail. 250 In the case that a profile explicitly permits multiple successful 251 SASL negotiations to occur, then in no case may multiple security 252 layers be simultaneously in effect. If a security layer is in effect 253 and a subsequent SASL negotiation selects no security layer, the 254 original security layer remains in effect. If a security layer is in 255 effect and a subsequent SASL negotiation selects a second security 256 layer, then the second security layer replaces the first. 258 6. Registration procedures 260 The following documents the procedure for registering new SASL 261 mechanism types. 263 While the registration procedures do not require it, authors of SASL 264 mechanisms are encouraged to seek community review and comment 265 whenever that is feasible. Authors may seek community review by 266 posting a specification of their proposed mechanism as an internet- 267 draft. SASL mechanisms intended for widespread use should be 268 standardized through the normal IETF process, when appropriate. 270 6.1. Comments on SASL mechanism registrations 272 Comments on registered SASL mechanisms should first be sent to the 273 "owner" of the mechanism. Submitters of comments may, after a 274 reasonable attempt to contact the owner, request IANA to attach their 275 comment to the SASL mechanism registration itself. If IANA approves 276 of this the comment will be made accessible in conjunction with the 277 SASL mechanism registration itself. 279 6.2. Location of Registered SASL Mechanism List 281 SASL mechanism registrations will be posted in the anonymous FTP 282 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- 283 mechanisms/" and all registered SASL mechanisms will be listed in the 285 Internet DRAFT SASL April 16, 1997 287 periodically issued "Assigned Numbers" RFC [currently RFC- 1700]. 288 The SASL mechanism description and other supporting material may also 289 be published as an Informational RFC by sending it to "rfc- 290 editor@isi.edu" (please follow the instructions to RFC authors [RFC- 291 1543]). 293 6.3. Change Control 295 Once a SASL mechanism registration has been published by IANA, the 296 author may request a change to its definition. The change request 297 follows the same procedure as the registration request. 299 The owner of a SASL mechanism may pass responsibility for the SASL 300 mechanism to another person or agency by informing IANA; this can be 301 done without discussion or review. 303 The IESG may reassign responsibility for a SASL mechanism. The most 304 common case of this will be to enable changes to be made to 305 mechanisms where the author of the registration has died, moved out 306 of contact or is otherwise unable to make changes that are important 307 to the community. 309 SASL mechanism registrations may not be deleted; mechanisms which are 310 no longer believed appropriate for use can be declared OBSOLETE by a 311 change to their "intended use" field; such SASL mechanisms will be 312 clearly marked in the lists published by IANA. 314 The IESG is considered to be the owner of all SASL mechanisms which 315 are on the IETF standards track. 317 6.4. Registration Template 319 To: iana@isi.edu 320 Subject: Registration of SASL mechanism X 322 SASL mechanism name: 324 Security considerations: 326 Published specification (optional, recommended): 328 Person & email address to contact for further information: 330 Intended usage: 332 (One of COMMON, LIMITED USE or OBSOLETE) 334 Internet DRAFT SASL April 16, 1997 336 Author/Change controller: 338 (Any other information that the author deems interesting may be 339 added below this line.) 341 7. Mechanism definitions 343 The following mechanisms are hereby defined. 345 7.1. Kerberos version 4 mechanism 347 The mechanism name associated with Kerberos version 4 is 348 "KERBEROS_V4". 350 The first challenge consists of a random 32-bit number in network 351 byte order. The client responds with a Kerberos ticket and an 352 authenticator for the principal "service.hostname@realm", where 353 "service" is the service name specified in the protocol's profile, 354 "hostname" is the first component of the host name of the server with 355 all letters in lower case, and where "realm" is the Kerberos realm of 356 the server. The encrypted checksum field included within the 357 Kerberos authenticator contains the server provided challenge in 358 network byte order. 360 Upon decrypting and verifying the ticket and authenticator, the 361 server verifies that the contained checksum field equals the original 362 server provided random 32-bit number. Should the verification be 363 successful, the server must add one to the checksum and construct 8 364 octets of data, with the first four octets containing the incremented 365 checksum in network byte order, the fifth octet containing a bit-mask 366 specifying the security layers supported by the server, and the sixth 367 through eighth octets containing, in network byte order, the maximum 368 cipher-text buffer size the server is able to receive. The server 369 must encrypt using DES ECB mode the 8 octets of data in the session 370 key and issue that encrypted data in a second challenge. The client 371 considers the server authenticated if the first four octets of the 372 un-encrypted data is equal to one plus the checksum it previously 373 sent. 375 The client must construct data with the first four octets containing 376 the original server-issued checksum in network byte order, the fifth 377 octet containing the bit-mask specifying the selected security layer, 378 the sixth through eighth octets containing in network byte order the 379 maximum cipher-text buffer size the client is able to receive, and 380 the following octets containing the authorization identity. The 381 client must then append from one to eight zero-valued octets so that 382 the length of the data is a multiple of eight octets. The client must 383 then encrypt using DES PCBC mode the data with the session key and 385 Internet DRAFT SASL April 16, 1997 387 respond with the encrypted data. The server decrypts the data and 388 verifies the contained checksum. The server must verify that the 389 principal identified in the Kerberos ticket is authorized to connect 390 as that authorization identity. After this verification, the 391 authentication process is complete. 393 The security layers and their corresponding bit-masks are as follows: 395 1 No security layer 396 2 Integrity (krb_mk_safe) protection 397 4 Privacy (krb_mk_priv) protection 398 Other bit-masks may be defined in the future; bits which are not 399 understood must be negotiated off. 401 EXAMPLE: The following are two Kerberos version 4 login scenarios to 402 the IMAP4 protocol (note that the line breaks in the sample 403 authenticators are for editorial clarity and are not in real 404 authenticators) 406 S: * OK IMAP4 Server 407 C: A001 AUTHENTICATE KERBEROS_V4 408 S: + AmFYig== 409 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 410 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 411 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 412 S: + or//EoAADZI= 413 C: DiAF5A4gA+oOIALuBkAAmw== 414 S: A001 OK Kerberos V4 authentication successful 416 S: * OK IMAP4 Server 417 C: A001 AUTHENTICATE KERBEROS_V4 418 S: + gcfgCA== 419 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 420 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 421 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 422 S: A001 NO Kerberos V4 authentication failed 424 Internet DRAFT SASL April 16, 1997 426 7.2. GSSAPI mechanism 428 The mechanism name associated with all mechanisms employing the 429 GSSAPI [GSSAPI] is "GSSAPI". 431 7.2.1 Client side of authentication protocol exchange 433 The client calls GSS_Init_sec_context, passing in 0 for 434 input_context_handle (initially) and a targ_name equal to output_name 435 from GSS_Import_Name called with input_name_type of 436 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 437 "service@hostname" where "service" is the service name specified in 438 the protocol's profile, and "hostname" is the fully qualified host 439 name of the server. The client then responds with the resulting 440 output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, 441 then the client should expect the server to issue a token in a 442 subsequent challenge. The client must pass the token to another call 443 to GSS_Init_sec_context, repeating the actions in this paragraph. 445 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes 446 the following actions: If the last call to GSS_Init_sec_context 447 returned an output_token, then the client responds with the 448 output_token, otherwise the client responds with no data. The client 449 should then expect the server to issue a token in a subsequent 450 challenge. The client passes this token to GSS_Unwrap and interprets 451 the first octet of resulting cleartext as a bit-mask specifying the 452 security layers supported by the server and the second through fourth 453 octets as the maximum size output_message to send to the server. The 454 client then constructs data, with the first octet containing the 455 bit-mask specifying the selected security layer, the second through 456 fourth octets containing in network byte order the maximum size 457 output_message the client is able to receive, and the remaining 458 octets containing the authorization identity. The client passes the 459 data to GSS_Wrap with conf_flag set to FALSE, and responds with the 460 generated output_message. The client can then consider the server 461 authenticated. 463 7.2.2 Server side of authentication protocol exchange 465 The server passes the initial client response to 466 GSS_Accept_sec_context as input_token, setting input_context_handle 467 to 0 (initially). If GSS_Accept_sec_context returns 468 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 469 to the client in challenge and passes the resulting response to 470 another call to GSS_Accept_sec_context, repeating the actions in this 471 paragraph. 473 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes 475 Internet DRAFT SASL April 16, 1997 477 the following actions: If the last call to GSS_Accept_sec_context 478 returned an output_token, the server returns it to the client in a 479 challenge and expects a reply from the client with no data. Whether 480 or not an output_token was returned (and after receipt of any 481 response from the client to such an output_token), the server then 482 constructs 4 octets of data, with the first octet containing a bit- 483 mask specifying the security layers supported by the server and the 484 second through fourth octets containing in network byte order the 485 maximum size output_token the server is able to receive. The server 486 must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE 487 and issue the generated output_message to the client in a challenge. 488 The server must then pass the resulting response to GSS_Unwrap and 489 interpret the first octet of resulting cleartext as the bit-mask for 490 the selected security layer, the second through fourth octets as the 491 maximum size output_message to send to the client, and the remaining 492 octets as the authorization identity. The server must verify that 493 the src_name is authorized to authenticate as the authorization 494 identity. After these verifications, the authentication process is 495 complete. 497 7.2.3 Security layer 499 The security layers and their corresponding bit-masks are as follows: 501 1 No security layer 502 2 Integrity protection. 503 Sender calls GSS_Wrap with conf_flag set to FALSE 504 4 Privacy protection. 505 Sender calls GSS_Wrap with conf_flag set to TRUE 506 Other bit-masks may be defined in the future; bits which are not 507 understood must be negotiated off. 509 Internet DRAFT SASL April 16, 1997 511 7.3. S/Key mechanism 513 The mechanism name associated with S/Key [SKEY] using the MD4 digest 514 algorithm is "SKEY". 516 The client sends an initial response with the authorization identity. 518 The server then issues a challenge which contains the decimal 519 sequence number followed by a single space and the seed string for 520 the indicated authorization identity. The client responds with the 521 one-time-password, as either a 64-bit value in network byte order or 522 encoded in the "six English words" format. 524 The server must verify the one-time-password. After this 525 verification, the authentication process is complete. 527 S/Key authentication does not provide for any security layers. 529 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 530 protocol. 532 S: * OK IMAP4 Server 533 C: A001 AUTHENTICATE SKEY 534 S: + 535 C: bW9yZ2Fu 536 S: + OTUgUWE1ODMwOA== 537 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 538 S: A001 OK S/Key authentication successful 540 S: * OK IMAP4 Server 541 C: A001 AUTHENTICATE SKEY 542 S: + 543 C: c21pdGg= 544 S: + OTUgUWE1ODMwOA== 545 C: BsAY3g4gBNo= 546 S: A001 NO S/Key authentication failed 548 The following is an S/Key login scenario in an IMAP4-like protocol 549 which has an optional "initial response" argument to the AUTHENTICATE 550 command. 552 S: * OK IMAP4-Like Server 553 C: A001 AUTHENTICATE SKEY bW9yZ2Fu 554 S: + OTUgUWE1ODMwOA== 555 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 556 S: A001 OK S/Key authentication successful 558 Internet DRAFT SASL April 16, 1997 560 8. References 562 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 563 RFC 1730, University of Washington, December 1994. 565 [GSSAPI] Linn, J., "Generic Security Service Application Program 566 Interface, Version 2", RFC 2078, January 1997 568 [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 569 October 1993 571 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 572 1760, Bellcore, February 1995 574 8. Security Considerations 576 Security issues are discussed throughout this memo. 578 The mechanisms that support integrity protection are designed such 579 that the negotiation of the security layer and authorization identity 580 is integrity protected. When the client selects a security layer 581 with at least integrity protection, this protects against an active 582 attacker hijacking the connection and modifying the authentication 583 exchange to negotiate a plaintext connection. 585 When a server or client supports multiple authentication mechanisms, 586 each of which has a different security strength, it is possible for 587 an active attacker to cause a party to use the least secure mechanism 588 supported. To protect against this sort of attack, a client or 589 server which supports mechanisms of different strengths should have a 590 configurable minimum strength that it will use. It is not sufficient 591 for this minimum strength check to only be on the server, since an 592 active attacker can change which mechanisms the client sees as being 593 supported, causing the client to send authentication credentials for 594 its weakest supported mechanism. 596 The client's selection of an SASL mechanism is done in the clear and 597 may be modified by an active attacker. It is important for any new 598 SASL mechanisms to be designed such that an active attacker cannot 599 obtain an authentication with weaker security properties by modifying 600 the SASL mechanism name and/or the challenges and responses. 602 Any protocol interactions prior to authentication are performed in 603 the clear and may be modified by an active attacker. In the case 604 where a client selects integrity protection, it is important that any 605 security-sensitive protocol negotiations be performed after 606 authentication is complete. Protocols should be designed such that 607 negotiations performed prior to authentication should be either 609 Internet DRAFT SASL April 16, 1997 611 ignored or revalidated once authentication is complete. 613 9. Author's Address 615 John G. Myers 616 220 Palo Alto Ave, Apt 102 617 Palo Alto, CA 94301 619 Email: jgm@cmu.edu 621 Appendix A. Relation of SASL to Transport Security 623 Questions have been raised about the relationship between SASL and 624 various services (such as IPsec and SSL) which provide a secured 625 connection. 627 Two of the key features of SASL are: 629 1. The separation of the authorization identity from the identity in 630 the client's credentials. This permits agents such as proxy 631 servers to authenticate using their own credentials, yet request 632 the access privileges of the identity for which they are proxying. 634 2. Upon successful completion of an authentication exchange, the 635 server knows the authorization identity the client wishes to use. 636 This allows servers to move to a "user is authenticated" state in 637 the protocol. 639 These features are extremely important to some application protocols, 640 yet Transport Security services do not always provide them. 642 In certain situations, it is reasonable to use SASL underneath one of 643 these Transport Security services. The transport service would 644 secure the connection, either service would authenticate the client, 645 and SASL would negotiate the authorization identity. The SASL 646 negotiation would be what moves the protocol from "unauthenticated" 647 to "authenticated" state. 649 When using SASL underneath a sufficiently strong Transport Security 650 service, a SASL security layer would most likely be redundant. The 651 client and server would thus probably want to negotiate off the use 652 of a SASL security layer. 654 Internet DRAFT SASL April 16, 1997 656 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 658 Status of this Memo ............................................... i 659 1. Abstract ...................................................... 2 660 2. Organization of this Document ................................ 2 661 2.1. How to Read This Document .................................... 2 662 2.2. Conventions Used in this Document ............................ 2 663 2.3. Examples ..................................................... 3 664 3. Introduction and Overview .................................... 3 665 4. Profiling requirements ....................................... 4 666 5. Specific issues .............................................. 5 667 5.1. Client sends data first ...................................... 5 668 5.2. Server returns success with additional data .................. 5 669 5.3. Multiple authentications ..................................... 6 670 6. Registration procedures ...................................... 6 671 6.1. Comments on SASL mechanism registrations ..................... 6 672 6.2. Location of Registered SASL Mechanism List .................. 6 673 6.3. Change Control ............................................... 7 674 6.4. Registration Template ....................................... 7 675 7. Mechanism definitions ........................................ 8 676 7.1. Kerberos version 4 mechanism ................................. 8 677 7.2. GSSAPI mechanism ............................................. 10 678 7.2.1 Client side of authentication protocol exchange ............. 10 679 7.2.2 Server side of authentication protocol exchange ............. 10 680 7.2.3 Security layer .............................................. 11 681 7.3. S/Key mechanism .............................................. 12 682 8. References ................................................... 13 683 8. Security Considerations ...................................... 13 684 9. Author's Address ............................................. 14 685 Appendix A. Relation of SASL to Transport Security ................ 14