idnits 2.17.1 draft-myers-auth-sasl-08.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-29) 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. == Mismatching filename: the document gives the document name as 'draft-myers-auth-sasl-07', but the file name used is 'draft-myers-auth-sasl-08' == 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 ...' (4 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 (February 1997) is 9904 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) -- No information found for draft-ietf-cat-gssv2-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GSSAPI' ** Obsolete normative reference: RFC 1543 (Obsoleted by RFC 2223) ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'SKEY') Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft February 1997 4 Document: draft-myers-auth-sasl-07.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 February 26, 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 February 26, 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 February 26, 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. 157 If use of a security layer is negotiated, it is applied to all 158 subsequent data sent over the connection. The security layer takes 159 effect immediately following the last response of the authentication 160 exchange for data sent by the client and the completion indication 161 for data sent by the server. Once the security layer is in effect, 162 the protocol stream is processed by the security layer into buffers 163 of cipher-text. Each buffer is transferred over the connection as a 164 stream of octets prepended with a four octet field in network byte 165 order that represents the length of the following buffer. The length 166 of the cipher-text buffer must be no larger than the maximum size 167 that was defined or negotiated by the other side. 169 4. Profiling requirements 171 In order to use this specification, a protocol definition must supply 172 the following information: 174 1. A service name, to be selected from the IANA registry of "service" 175 elements for the GSSAPI host-based service name form. [GSSAPI] 177 2. A definition of the command to initiate the authentication 178 protocol exchange. This command must have as a parameter the 179 mechanism name being selected by the client. 181 The command SHOULD have an optional parameter giving an initial 183 Internet DRAFT SASL February 26, 1997 185 response. This optional parameter allows the client to avoid a 186 round trip when using a mechanism which is defined to send no data 187 in the initial challenge. When this initial response is sent by 188 the client and the mechanism is defined to send no data in the 189 initial challenge, the empty challenge is not sent to the client 190 and the server uses the data in the initial response parameter as 191 if it were sent in response to the empty challenge. (The server 192 then proceeds to send the second challenge, indicates completion, 193 or indicates failure.) When this initial response is sent by the 194 client and the mechanism is defined to send one or more octets of 195 data in the initial challenge, the command fails. 197 3. A definition of the method by which the authentication protocol 198 exchange is carried out, including how the challenges and 199 responses are encoded, how the server indicates completion or 200 failure of the exchange, how the client aborts an exchange, and 201 how the exchange method interacts with any line length limits in 202 the protocol. 204 4. Identification of the octet where any negotiated security layer 205 starts to take effect, in both directions. 207 5. A specification of how the authorization identity passed from the 208 client to the server is to be interpreted. 210 5. Registration procedures 212 The following documents the procedure for registering new SASL 213 mechanism types. 215 While the registration procedures do not require it, authors of SASL 216 mechanisms are encouraged to seek community review and comment 217 whenever that is feasible. Authors may seek community review by 218 posting a specification of their proposed mechanism as an internet- 219 draft. SASL mechanisms intended for widespread use should be 220 standardized through the normal IETF process, when appropriate. 222 5.1. Comments on SASL mechanism registrations 224 Comments on registered SASL mechanisms should first be sent to the 225 "owner" of the mechanism. Submitters of comments may, after a 226 reasonable attempt to contact the owner, request IANA to attach their 227 comment to the SASL mechanism registration itself. If IANA approves 228 of this the comment will be made accessible in conjunction with the 229 SASL mechanism registration itself. 231 Internet DRAFT SASL February 26, 1997 233 5.2. Location of Registered SASL Mechanism List 235 SASL mechanism registrations will be posted in the anonymous FTP 236 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- 237 mechanisms/" and all registered SASL mechanisms will be listed in the 238 periodically issued "Assigned Numbers" RFC [currently RFC- 1700]. 239 The SASL mechanism description and other supporting material may also 240 be published as an Informational RFC by sending it to "rfc- 241 editor@isi.edu" (please follow the instructions to RFC authors [RFC- 242 1543]). 244 5.2. Change Control 246 Once a SASL mechanism registration has been published by IANA, the 247 author may request a change to its definition. The change request 248 follows the same procedure as the registration request. 250 The owner of a SASL mechanism may pass responsibility for the SASL 251 mechanism to another person or agency by informing IANA; this can be 252 done without discussion or review. 254 The IESG may reassign responsibility for a SASL mechanism. The most 255 common case of this will be to enable changes to be made to 256 mechanisms where the author of the registration has died, moved out 257 of contact or is otherwise unable to make changes that are important 258 to the community. 260 SASL mechanism registrations may not be deleted; mechanisms which are 261 no longer believed appropriate for use can be declared OBSOLETE by a 262 change to their "intended use" field; such SASL mechanisms will be 263 clearly marked in the lists published by IANA. 265 The IESG is considered to be the owner of all SASL mechanisms which 266 are on the IETF standards track. 268 5.3. Registration Template 270 To: iana@isi..edu 271 Subject: Registration of SASL mechanism X 273 SASL mechanism name: 275 Security considerations: 277 Published specification (optional, recommended): 279 Person & email address to contact for further information: 281 Internet DRAFT SASL February 26, 1997 283 Intended usage: 285 (One of COMMON, LIMITED USE or OBSOLETE) 287 Author/Change controller: 289 (Any other information that the author deems interesting may be 290 added below this line.) 292 6. Mechanism definitions 294 The following mechanisms are hereby defined. 296 6.1. Kerberos version 4 mechanism 298 The mechanism name associated with Kerberos version 4 is 299 "KERBEROS_V4". 301 The first challenge consists of a random 32-bit number in network 302 byte order. The client responds with a Kerberos ticket and an 303 authenticator for the principal "service.hostname@realm", where 304 "service" is the service name specified in the protocol's profile, 305 "hostname" is the first component of the host name of the server with 306 all letters in lower case, and where "realm" is the Kerberos realm of 307 the server. The encrypted checksum field included within the 308 Kerberos authenticator contains the server provided challenge in 309 network byte order. 311 Upon decrypting and verifying the ticket and authenticator, the 312 server verifies that the contained checksum field equals the original 313 server provided random 32-bit number. Should the verification be 314 successful, the server must add one to the checksum and construct 8 315 octets of data, with the first four octets containing the incremented 316 checksum in network byte order, the fifth octet containing a bit-mask 317 specifying the security layers supported by the server, and the sixth 318 through eighth octets containing, in network byte order, the maximum 319 cipher-text buffer size the server is able to receive. The server 320 must encrypt using DES ECB mode the 8 octets of data in the session 321 key and issue that encrypted data in a second challenge. The client 322 considers the server authenticated if the first four octets of the 323 un-encrypted data is equal to one plus the checksum it previously 324 sent. 326 The client must construct data with the first four octets containing 327 the original server-issued checksum in network byte order, the fifth 328 octet containing the bit-mask specifying the selected security layer, 329 the sixth through eighth octets containing in network byte order the 330 maximum cipher-text buffer size the client is able to receive, and 332 Internet DRAFT SASL February 26, 1997 334 the following octets containing the authorization identity. The 335 client must then append from one to eight zero-valued octets so that 336 the length of the data is a multiple of eight octets. The client must 337 then encrypt using DES PCBC mode the data with the session key and 338 respond with the encrypted data. The server decrypts the data and 339 verifies the contained checksum. The server must verify that the 340 principal identified in the Kerberos ticket is authorized to connect 341 as that authorization identity. After this verification, the 342 authentication process is complete. 344 The security layers and their corresponding bit-masks are as follows: 346 1 No security layer 347 2 Integrity (krb_mk_safe) protection 348 4 Privacy (krb_mk_priv) protection 349 Other bit-masks may be defined in the future; bits which are not 350 understood must be negotiated off. 352 EXAMPLE: The following are two Kerberos version 4 login scenarios to 353 the IMAP4 protocol (note that the line breaks in the sample 354 authenticators are for editorial clarity and are not in real 355 authenticators) 357 S: * OK IMAP4 Server 358 C: A001 AUTHENTICATE KERBEROS_V4 359 S: + AmFYig== 360 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 361 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 362 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 363 S: + or//EoAADZI= 364 C: DiAF5A4gA+oOIALuBkAAmw== 365 S: A001 OK Kerberos V4 authentication successful 367 S: * OK IMAP4 Server 368 C: A001 AUTHENTICATE KERBEROS_V4 369 S: + gcfgCA== 370 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 371 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 372 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 373 S: A001 NO Kerberos V4 authentication failed 375 Internet DRAFT SASL February 26, 1997 377 6.2. GSSAPI mechanism 379 The mechanism name associated with all mechanisms employing the 380 GSSAPI [GSSAPI] is "GSSAPI". 382 6.2.1 Client side of authentication protocol exchange 384 The first challenge issued by the server contains no data. 386 The client calls GSS_Init_sec_context, passing in 0 for 387 input_context_handle (initially) and a targ_name equal to output_name 388 from GSS_Import_Name called with input_name_type of 389 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 390 "service@hostname" where "service" is the service name specified in 391 the protocol's profile, and "hostname" is the fully qualified host 392 name of the server. The client then responds with the resulting 393 output_token. If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, 394 then the client should expect the server to issue a token in a 395 subsequent challenge. The client must pass the token to another call 396 to GSS_Init_sec_context, repeating the actions in this paragraph. 398 When GSS_Init_sec_context returns GSS_COMPLETE, the client takes the 399 following actions: If the last call to GSS_Init_sec_context returned 400 an output_token, then the client responds with the output_token, 401 otherwise the client responds with no data. The client should then 402 expect the server to issue a token in a subsequent challenge. The 403 client passes this token to GSS_Unseal and interprets the first octet 404 of resulting cleartext as a bit-mask specifying the security layers 405 supported by the server and the second through fourth octets as the 406 maximum size output_message to send to the server. The client then 407 constructs data, with the first octet containing the bit-mask 408 specifying the selected security layer, the second through fourth 409 octets containing in network byte order the maximum size 410 output_message the client is able to receive, and the remaining 411 octets containing the authorization identity. The client passes the 412 data to GSS_Seal with conf_flag set to FALSE, and responds with the 413 generated output_message. The client can then consider the server 414 authenticated. 416 6.2.2 Server side of authentication protocol exchange 418 The server starts by issuing a challenge with no data. It passes the 419 resulting client response to GSS_Accept_sec_context as input_token, 420 setting acceptor_cred_handle to NULL (for "use default credentials"), 421 and 0 for input_context_handle (initially). If 422 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server 423 returns the generated output_token to the client in challenge and 424 passes the resulting response to another call to 426 Internet DRAFT SASL February 26, 1997 428 GSS_Accept_sec_context, repeating the actions in this paragraph. 430 When GSS_Accept_sec_context returns GSS_COMPLETE, the client takes 431 the following actions: If the last call to GSS_Accept_sec_context 432 returned an output_token, the server returns it to the client in a 433 challenge and expects a reply from the client with no data. Whether 434 or not an output_token was returned (and after receipt of any 435 response from the client to such an output_token), the server then 436 constructs 4 octets of data, with the first octet containing a bit- 437 mask specifying the security layers supported by the server and the 438 second through fourth octets containing in network byte order the 439 maximum size output_token the server is able to receive. The server 440 must then pass the plaintext to GSS_Seal with conf_flag set to FALSE 441 and issue the generated output_message to the client in a challenge. 442 The server must then pass the resulting response to GSS_Unseal and 443 interpret the first octet of resulting cleartext as the bit-mask for 444 the selected security layer, the second through fourth octets as the 445 maximum size output_message to send to the client, and the remaining 446 octets as the authorization identity. The server must verify that 447 the src_name is authorized to authenticate as the authorization 448 identity. After these verifications, the authentication process is 449 complete. 451 6.2.3 Security layer 453 The security layers and their corresponding bit-masks are as follows: 455 1 No security layer 456 2 Integrity protection. 457 Sender calls GSS_Seal with conf_flag set to FALSE 458 4 Privacy protection. 459 Sender calls GSS_Seal with conf_flag set to TRUE 460 Other bit-masks may be defined in the future; bits which are not 461 understood must be negotiated off. 463 Internet DRAFT SASL February 26, 1997 465 6.3. S/Key mechanism 467 The mechanism name associated with S/Key [SKEY] using the MD4 digest 468 algorithm is "SKEY". 470 The challenge issued by the server contains no data. The client 471 responds with the authorization identity. 473 The data encoded in the second ready response contains the decimal 474 sequence number followed by a single space and the seed string for 475 the indicated authorization identity. The client responds with the 476 one-time-password, as either a 64-bit value in network byte order or 477 encoded in the "six English words" format. 479 The server must verify the one-time-password. After this 480 verification, the authentication process is complete. 482 S/Key authentication does not provide for any security layers. 484 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 485 protocol. 487 S: * OK IMAP4 Server 488 C: A001 AUTHENTICATE SKEY 489 S: + 490 C: bW9yZ2Fu 491 S: + OTUgUWE1ODMwOA== 492 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 493 S: A001 OK S/Key authentication successful 495 S: * OK IMAP4 Server 496 C: A001 AUTHENTICATE SKEY 497 S: + 498 C: c21pdGg= 499 S: + OTUgUWE1ODMwOA== 500 C: BsAY3g4gBNo= 501 S: A001 NO S/Key authentication failed 503 The following is an S/Key login scenario in an IMAP4-like protocol 504 which has an optional "initial response" argument to the AUTHENTICATE 505 command. 507 S: * OK IMAP4-Like Server 508 C: A001 AUTHENTICATE SKEY bW9yZ2Fu 509 S: + OTUgUWE1ODMwOA== 510 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 512 Internet DRAFT SASL February 26, 1997 514 S: A001 OK S/Key authentication successful 516 Internet DRAFT SASL February 26, 1997 518 7. References 520 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 521 RFC 1730, University of Washington, December 1994. 523 [GSSAPI] Linn, J., "Generic Security Service Application Program 524 Interface, Version 2", draft-ietf-cat-gssv2-XX, OpenVision 525 Technologies, May 1996 527 [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 528 October 1993 530 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 531 1760, Bellcore, February 1995 533 8. Security Considerations 535 Security issues are discussed throughout this memo. 537 The mechanisms that support integrity protection are designed such 538 that the negotiation of the security layer and authorization identity 539 is integrity protected. When the client selects a security layer 540 with at least integrity protection, this protects against an active 541 attacker hijacking the connection and modifying the authentication 542 exchange to negotiate a plaintext connection. 544 When a server or client supports multiple authentication mechanisms, 545 each of which has a different security strength, it is possible for 546 an active attacker to cause a party to use the least secure mechanism 547 supported. To protect against this sort of attack, a client or 548 server which supports mechanisms of different strengths should have a 549 configurable minimum strength that it will use. It is not sufficient 550 for this minimum strength check to only be on the server, since an 551 active attacker can change which mechanisms the client sees as being 552 supported, causing the client to send authentication credentials for 553 its weakest supported mechanism. 555 The client's selection of an SASL mechanism is done in the clear and 556 may be modified by an active attacker. It is important for any new 557 SASL mechanisms to be designed such that an active attacker cannot 558 obtain an authentication with weaker security properties by modifying 559 the SASL mechanism name and/or the challenges and responses. 561 Any protocol interactions prior to authentication are performed in 562 the clear and may be modified by an active attacker. In the case 563 where a client selects integrity protection, it is important that any 564 security-sensitive protocol negotiations be performed after 565 authentication is complete. Protocols should be designed such that 567 Internet DRAFT SASL February 26, 1997 569 negotiations performed prior to authentication should be either 570 ignored or revalidated once authentication is complete. 572 9. Author's Address 574 John G. Myers 575 220 Palo Alto Ave, Apt 102 576 Palo Alto, CA 94301 578 Email: jgm@cmu.edu 580 Internet DRAFT SASL February 26, 1997 582 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 584 Status of this Memo ............................................... i 585 1. Abstract ..................................................... 2 586 2. Organization of this Document ................................ 2 587 2.1. How to Read This Document .................................... 2 588 2.2. Conventions Used in this Document ............................. 2 589 2.3. Examples ..................................................... 3 590 3. Introduction and Overview .................................... 3 591 4. Profiling requirements ....................................... 4 592 5. Registration procedures ...................................... 5 593 5.1. Comments on SASL mechanism registrations ..................... 5 594 5.2. Location of Registered SASL Mechanism List .................. 6 595 5.2. Change Control .............................................. 6 596 5.3. Registration Template ....................................... 6 597 6. Mechanism definitions ........................................ 7 598 6.1. Kerberos version 4 mechanism ................................. 7 599 6.2. GSSAPI mechanism ............................................. 9 600 6.2.1 Client side of authentication protocol exchange ............. 9 601 6.2.2 Server side of authentication protocol exchange ............. 9 602 6.2.3 Security layer ............................................... 10 603 6.3. S/Key mechanism .............................................. 11 604 7. References ................................................... 13 605 8. Security Considerations ...................................... 13 606 9. Author's Address ............................................. 14