idnits 2.17.1 draft-myers-auth-sasl-02.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-04-16) 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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 61 lines 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 is 1 instance 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. 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 (July 1996) is 10137 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: 14 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Myers 2 Internet Draft Carnegie Mellon 3 Document: draft-myers-auth-sasl-02.txt July 1996 5 Simple Authentication and Session Layer 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 ``working draft'' or ``work in progress``. 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 23 munnari.oz.au. 25 A revised version of this draft document will be submitted to the RFC 26 editor as a Proposed Standard for the Internet Community. Discussion 27 and suggestions for improvement are requested. This document will 28 expire before December 1996. Distribution of this draft is 29 unlimited. 31 Internet DRAFT SASL July 2, 1996 33 1. Abstract 35 This document describes a method for adding authentication support to 36 connection-based protocols. To use this specification, a protocol 37 includes a command for identifying and authenticating a user to a 38 server and for optionally negotiating protection of subsequent 39 protocol interactions. If its use is negotiated, a "session layer" 40 is inserted between the protocol and the connection. This document 41 describes how a protocol specifies such a command, defines several 42 mechanisms for use by the command, and defines the protocol used for 43 carrying a negotiated session layer over the connection. 45 2. Organization of this Document 47 2.1. How to Read This Document 49 This document is written to serve two different audiences, protocol 50 designers using this specification to support authentication in their 51 protocol, and implementors of clients or servers for those protocols 52 using this specification. 54 The sections "Introduction and Overview", "Profiling requirements", 55 and "Security Considerations" cover issues that protocol designers 56 need to understand and address in profiling this specification for 57 use in a specific protocol. 59 Implementors of a protocol using this specification need the 60 protocol-specific profiling information in addition to the 61 information in this document. 63 2.2. Conventions Used in this Document 65 In examples, "C:" and "S:" indicate lines sent by the client and 66 server respectively. 68 2.3. Examples 70 Examples in this document are for the IMAP profile [IMAP4] of this 71 specification. The base64 encoding of challenges and responses, as 72 well as the "+ " preceeding the responses are part of the IMAP4 73 profile, not part of the SASL specification itself. 75 3. Introduction and Overview 77 The Simple Authentication and Session Layer (SASL) is a method for 78 adding authentication support to connection-based protocols. To use 79 this specification, a protocol includes a command for identifying and 80 authenticating a user to a server and for optionally negotiating a 81 Internet DRAFT SASL July 2, 1996 83 session layer for subsequent protocol interactions. 85 The command has a single argument, identifying a SASL mechanism. 86 SASL mechanisms are named by strings, from 1 to 20 characters in 87 length, consisting of upper-case letters, digits, hyphens, and/or 88 underscores. SASL mechanism names must be registered with the IANA. 89 Procedures for registering new SASL mechanisms are given in the 90 section "Registration procedures" 92 If a server supports the requested mechanism, it performs an 93 authentication protocol exchange. This consists of a series of 94 server challenges and client responses that are specific to the 95 requested mechanism. The challenges and responses are defined by the 96 mechanisms as binary tokens of arbitrary length. The protocol's 97 profile then specifies how these binary tokens are then encoded for 98 transfer over the connection. 100 After receiving the authentication command or any client response, a 101 server may issue a challenge, indicate failure, or indicate 102 completion. The protocol's profile specifies how the server 103 indicates which of the above it is doing. 105 After receiving a challenge, a client may issue a response or abort 106 the exchange. The protocol's profile specifies how the client 107 indicates which of the above it is doing. 109 During the authentication protocol exchange, the mechanism performs 110 authentication, transmits an authorization identity (frequently known 111 as a userid) from the client to server, and negotiates the use of a 112 mechanism-specific session layer. If the use of a session layer is 113 agreed upon, then the mechanism must also define or negotiate the 114 maximum cipher-text buffer size that each side is able to receive. 116 If use of a session layer is negotiated, it is applied to all 117 subsequent data sent over the connection. The session layer takes 118 effect immediately following the last response of the authentication 119 exchange for data sent by the client and the completion indication 120 for data sent by the server. Once the session layer is in effect, 121 the protocol stream is processed by the session layer into buffers of 122 cipher-text. Each buffer is transferred over the connection as a 123 stream of octets prepended with a four octet field in network byte 124 order that represents the length of the following buffer. The length 125 of the cipher-text buffer must be no larger than the maximum size 126 that was defined or negotiated by the other side. 128 Internet DRAFT SASL July 2, 1996 130 4. Profiling requirements 132 In order to use this specification, a protocol definition must supply 133 the following information: 135 1. A service name, to be selected from the IANA registry of "service" 136 elements for the GSSAPI host-based service name form. [GSSAPI] 138 2. A definition of the command to initiate the authentication 139 protocol exchange. This command must have as a parameter the 140 mechanism name being selected by the client. 142 3. A definition of the method by which the authentication protocol 143 exchange is carried out, including how the challenges and 144 responses are encoded, how the server indicates completion or 145 failure of the exchange, how the client aborts an exchange, and 146 how the exchange method interacts with any line length limits in 147 the protocol. 149 4. Identification of the octet where any negotiated session layer 150 starts to take effect, in both directions. 152 5. A specification of how the authorization identity passed from the 153 client to the server is to be interpreted. 155 5. Registration procedures 157 The following documents the procedure for registering new SASL 158 mechanism types. 160 While the registration procedures do not require it, authors of SASL 161 mechanisms are encouraged to seek community review and comment 162 whenever that is feasable. Authors may seek community review by 163 posting a specification of their proposed mechanism as an internet- 164 draft. 166 5.1. Comments on SASL mechanism registrations 168 Comments on registered SASL mechanisms may be submitted by members of 169 the community to IANA. These comments will be passed on to the 170 "owner" of the mechanism if possible. Submitters of comments may 171 request that their comment be attached to the SASL mechanism 172 registration itself, and if IANA approves of this the comment will be 173 made accessible in conjunction with the SASL mechanism registration 174 itself. 176 Internet DRAFT SASL July 2, 1996 178 5.2. Location of Registered SASL Mechanism List 180 Media type registrations will be posted in the anonymous FTP 181 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- 182 mechanisms/" and all registered SASL mechanisms will be listed in the 183 periodically issued "Assigned Numbers" RFC [currently RFC- 1700]. 184 The SASL mechanism description and other supporting material may also 185 be published as an Informational RFC by sending it to "rfc- 186 editor@isi.edu" (please follow the instructions to RFC authors [RFC- 187 1543]). 189 5.2. Change Control 191 Once a SASL mechanism registration has been published by IANA, the 192 author may request a change to its definition. The change request 193 follows the same procedure as the registration request. 195 The owner of a content type may pass responsibility for the content 196 type to another person or agency by informing IANA; this can be done 197 without discussion or review. 199 The IESG may reassign responsibility for a SASL mechanism. The most 200 common case of this will be to enable changes to be made to types 201 where the author of the registration has died, moved out of contact 202 or is otherwise unable to make changes that are important to the 203 community. 205 SASL mechanism registrations may not be deleted; mechanisms which are 206 no longer believed appropriate for use can be declared OBSOLETE by a 207 change to their "intended use" field; such SASL mechanisms will be 208 clearly marked in the lists published by IANA. 210 5.3. Registration Template 212 To: iana@isi.edu 213 Subject: Registration of SASL mechanism XXX 215 SASL mechanism name: 217 Security considerations: 219 Published specification (optional, recommended): 221 Person & email address to contact for further information: 223 Intended usage: 225 Internet DRAFT SASL July 2, 1996 227 (One of COMMON, LIMITED USE or OBSOLETE) 229 Author/Change controller: 231 (Any other information that the author deems interesting may be 232 added below this line.) 234 6. Mechanism definitions 236 The following mechanisms are hereby defined. 238 6.1. Kerberos version 4 mechanism 240 The mechanism name associated with Kerberos version 4 is 241 "KERBEROS_V4". 243 The first challenge consists of a random 32-bit number in network 244 byte order. The client responds with a Kerberos ticket and an 245 authenticator for the principal "service.hostname@realm", where 246 "service" is the service name specified in the protocol's profile, 247 "hostname" is the first component of the host name of the server with 248 all letters in lower case, and where "realm" is the Kerberos realm of 249 the server. The encrypted checksum field included within the 250 Kerberos authenticator contains the server provided challenge in 251 network byte order. 253 Upon decrypting and verifying the ticket and authenticator, the 254 server verifies that the contained checksum field equals the original 255 server provided random 32-bit number. Should the verification be 256 successful, the server must add one to the checksum and construct 8 257 octets of data, with the first four octets containing the incremented 258 checksum in network byte order, the fifth octet containing a bit-mask 259 specifying the sesison layers supported by the server, and the sixth 260 through eighth octets containing, in network byte order, the maximum 261 cipher-text buffer size the server is able to receive. The server 262 must encrypt using DES ECB mode the 8 octets of data in the session 263 key and issue that encrypted data in a second challenge. The client 264 considers the server authenticated if the first four octets the un- 265 encrypted data is equal to one plus the checksum it previously sent. 267 The client must construct data with the first four octets containing 268 the original server-issued checksum in network byte order, the fifth 269 octet containing the bit-mask specifying the selected session layer, 270 the sixth through eighth octets containing in network byte order the 271 maximum cipher-text buffer size the client is able to receive, and 272 the following octets containing the authorization identity. The 273 client must then append from one to eight zero-valued octets so that 274 the length of the data is a multiple of eight octets. The client must 275 Internet DRAFT SASL July 2, 1996 277 then encrypt using DES PCBC mode the data with the session key and 278 respond with the encrypted data. The server decrypts the data and 279 verifies the contained checksum. The server must verify that the 280 principal identified in the Kerberos ticket is authorized to connect 281 as that authorization identiy. After these verifications, the 282 authentication process is complete. 284 The session layers and their corresponding bit-masks are as follows: 286 1 No session layer 287 2 Integrity (krb_mk_safe) protection 288 4 Privacy (krb_mk_priv) protection 289 Other bit-masks may be defined in the future; bits which are not 290 understood must be negotiated off. 292 EXAMPLE: The following are two Kerberos version 4 login scenarios to 293 the IMAP4 protocol (note that the line breaks in the sample 294 authenticators are for editorial clarity and are not in real 295 authenticators) 297 S: * OK IMAP4 Server 298 C: A001 AUTHENTICATE KERBEROS_V4 299 S: + AmFYig== 300 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 301 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 302 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 303 S: + or//EoAADZI= 304 C: DiAF5A4gA+oOIALuBkAAmw== 305 S: A001 OK Kerberos V4 authentication successful 307 S: * OK IMAP4 Server 308 C: A001 AUTHENTICATE KERBEROS_V4 309 S: + gcfgCA== 310 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 311 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 312 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 313 S: A001 NO Kerberos V4 authentication failed 314 Internet DRAFT SASL July 2, 1996 316 6.2. GSSAPI mechanism 318 The mechanism name associated with all mechanisms employing the 319 GSSAPI [GSSAPI] is "GSSAPI". 321 6.2.1 Client side of authentication protocol exchange 323 The first challenge issued by the server contains no data. 325 The client calls GSS_Init_sec_context, passing in 0 for 326 input_context_handle (initially) and a targ_name equal to output_name 327 from GSS_Import_Name called with input_name_type of 328 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 329 "service@hostname" where "service" is the service name specified in 330 the protocol's profile, and "hostname" is the fully qualified host 331 name of the server. The client then responds with the resulting 332 output_token. If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, 333 then the client should expect the server to issue a token in a 334 subsequent challenge. The client must pass the token to another call 335 to GSS_Init_sec_context, repeating the actions in this paragraph. 337 When GSS_Init_sec_context returns GSS_COMPLETE, the client takes the 338 following actions: If the last call to GSS_Init_sec_context returned 339 an output_token, then the client responds with the output_token, 340 otherwise the client responds with no data. The client should then 341 expect the server to issue a token in a subsequent challenge. The 342 client passes this token to GSS_Unseal and interprets the first octet 343 of resulting cleartext as a bit-mask specifying the protection 344 mechanisms supported by the server and the second through fourth 345 octets as the maximum size output_message to send to the server. The 346 client then constructs data, with the first octet containing the 347 bit-mask specifying the selected protection mechanism, the second 348 through fourth octets containing in network byte order the maximum 349 size output_message the client is able to receive, and the remaining 350 octets containing the authorization identity. The client passs the 351 data to GSS_Seal with conf_flag set to FALSE, and responds with the 352 generated output_message. The client can then consider the server 353 authenticated. 355 6.2.2 Server side of authentication protocol exchange 357 The server starts by issuing a challenge with no data. It passes the 358 resulting client response to GSS_Accept_sec_context as input_token, 359 setting acceptor_cred_handle to NULL (for "use default credentials"), 360 and 0 for input_context_handle (initially). If 361 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server 362 returns the generated output_token to the client in challenge and 363 passes the resulting response to another call to 364 Internet DRAFT SASL July 2, 1996 366 GSS_Accept_sec_context, repeating the actions in this paragraph. 368 When GSS_Accept_sec_context returns GSS_COMPLETE, the client takes 369 the followig actions: If the last call to GSS_Accept_sec_context 370 returned an output_token, the server returns it to the client in a 371 challenge and expects a reply from the client with no data. Whether 372 or not an output_token was returned, the server then constructs 4 373 octets of data, with the first octet containing a bit-mask specifying 374 the protection mechanisms supported by the server and the second 375 through fourth octets containing in network byte order the maximum 376 size output_token the server is able to receive. The server must 377 then pass the plaintext to GSS_Seal with conf_flag set to FALSE and 378 issue the generated output_message to the client in a challenge. The 379 server must then pass the resulting response to GSS_Unseal and 380 interpret the first octet of resulting cleartext as the bit-mask for 381 the selected protection mechanism, the second through fourth octets 382 as the maximum size output_message to send to the client, and the 383 remaining octets as the authroization identity. Upon verifying the 384 src_name is authorized to authenticate as the authorization identity, 385 The server should then consider the client authenticated. 387 6.2.3 Session layer 389 The session layers and their corresponding bit-masks are as follows: 391 1 No session layer 392 2 Integrity protection. 393 Sender calls GSS_Seal with conf_flag set to FALSE 394 4 Privacy protection. 395 Sender calls GSS_Seal with conf_flag set to TRUE 396 Other bit-masks may be defined in the future; bits which are not 397 understood must be negotiated off. 399 Internet DRAFT SASL July 2, 1996 401 6.3. S/Key mechanism 403 The mechanism name associated with S/Key [SKEY] is "SKEY". 405 The challenge issued by the server contains no data. The client 406 responds with the authorization identity. 408 The data encoded in the second ready response contains the decimal 409 sequence number followed by a single space and the seed string for 410 the indicated authorization identity. The client responds with the 411 one-time-password, as either a 64-bit value in network byte order or 412 encoded in the "six English words" format. 414 Upon successful verification of the one-time-password, the server 415 should consider the client authenticated. 417 S/Key authentication does not provide for any session layers. 419 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 420 protocol. 422 S: * OK IMAP4 Server 423 C: A001 AUTHENTICATE SKEY 424 S: + 425 C: bW9yZ2Fu 426 S: + OTUgUWE1ODMwOA== 427 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 428 S: A001 OK S/Key authentication successful 430 S: * OK IMAP4 Server 431 C: A001 AUTHENTICATE SKEY 432 S: + 433 C: c21pdGg= 434 S: + OTUgUWE1ODMwOA== 435 C: BsAY3g4gBNo= 436 S: A001 NO S/Key authentication failed 437 Internet DRAFT SASL July 2, 1996 439 7. References 441 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 442 RFC 1730, University of Washington, December 1994. 444 [GSSAPI] Linn, J., "Generic Security Service Application Program 445 Interface, Version 2", draft-ietf-cat-gssv2-XX, Geer Zolot 446 Associates, May 1996 448 [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 449 October 1993 451 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 452 1760, Bellcore, February 1995 454 8. Security Considerations 456 Security issues are discussed throughout this memo. 458 The mechanisms that support integrity protection are designed such 459 that the negotiation of the session layer and authorization identity 460 is integrity protected. When the client selects a session layer with 461 at least integrity protection, this protects against an active 462 attacker hijacking the connection and modifying the authentication 463 exchange to negotiate a plaintext connection. 465 The client's selection of an SASL mechanism is done in the clear and 466 may be modified by an active attacker. It is important for any new 467 SASL mechanisms to be designed such that an active attacker cannot 468 obtain an authentication with weaker security properties by modifying 469 the SASL mechanism name and/or the challenges and responses. 471 Any protocol interactions prior to authentication are performed in 472 the clear and may be modified by an active attacker. In the case 473 where a client selects integrity protection, it is important that any 474 security-sensitive protocol negotiations be performed after 475 authenticaiton is complete. Protocols should be designed such that 476 negotiations performed prior to authentication should be ignored once 477 authentication is complete. 479 9. Author's Address 481 John G. Myers 482 Carnegie-Mellon University 483 5000 Forbes Ave. 484 Pittsburgh PA, 15213-3890 486 EMail: jgm+@cmu.edu 487 Internet DRAFT SASL July 2, 1996 488 Internet DRAFT SASL July 2, 1996 490 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 492 Status of this Memo 493 1. Abstract 494 2. Organization of this Document 495 2.1. How to Read This Document 496 2.2. Conventions Used in this Document 497 2.3. Examples 498 3. Introduction and Overview 499 4. Profiling requirements 500 5. Registration procedures 501 5.1. Comments on SASL mechanism registrations 502 5.2. Location of Registered SASL Mechanism List 503 5.2. Change Control 504 5.3. Registration Template 505 6. Mechanism definitions 506 6.1. Kerberos version 4 mechanism 507 6.2. GSSAPI mechanism 508 6.2.1 Client side of authentication protocol exchange 509 6.2.2 Server side of authentication protocol exchange 510 6.2.3 Session layer 511 6.3. S/Key mechanism 512 7. References 513 8. Security Considerations 514 9. Author's Address