idnits 2.17.1 draft-myers-auth-sasl-01.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-19) 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. 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 (June 1996) is 10170 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: 12 errors (**), 0 flaws (~~), 1 warning (==), 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 Carnegie Mellon 4 Document: draft-myers-auth-sasl-01.txt June 1996 6 Simple Authentication and Session Layer 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 June 3, 1996 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 a protection mechanism for 40 subsequent protocol interactions. If use of a protection mechanism 41 is negotiated, a "session layer" is inserted between the protocol and 42 the connection. This document describes how a protocol specifies 43 such a command, defines several mechanisms for use by the command, 44 and defines the protocol used for carrying a negotiated session layer 45 over the connection. 47 2. Organization of this Document 49 2.1. How to Read This Document 51 This document is written to serve two different audiences, protocol 52 designers using this specification to support authentication in their 53 protocol, and implementors of clients or servers for those protocols 54 using this specification. 56 The sections "Introduction and Overview", "Profiling requirements", 57 and "Security Considerations" cover issues that protocol designers 58 need to understand and address in profiling this specification for 59 use in a specific protocol. 61 Implementors of a protocol using this specification need the 62 protocol-specific profiling information in addition to the 63 information in this document. 65 2.2. Conventions Used in this Document 67 In examples, "C:" and "S:" indicate lines sent by the client and 68 server respectively. 70 2.3. Examples 72 Examples in this document are for the IMAP profile [IMAP4] of this 73 specification. The base64 encoding of challenges and responses is 74 part of the IMAP4 profile, not part of the SASL specification itself. 76 3. Introduction and Overview 78 The Simple Authentication and Session Layer (SASL) is a method for 79 adding authentication support to connection-based protocols. To use 80 this specification, a protocol includes a command for identifying and 81 authenticating a user to a server and for optionally negotiating a 83 Internet DRAFT SASL June 3, 1996 85 protection mechanism for subsequent protocol interactions. 87 The command has a single argument, identifying a SASL mechanism. 88 SASL mechanisms are named by strings, from 1 to 20 characters in 89 length, consisting of upper-case letters, digits, hyphens, and/or 90 underscores. SASL mechanism names must be registered with the IANA. 91 Procedures for registering new SASL mechanisms are given in the 92 section "Registration procedures" 94 If a server supports the requested mechanism, it performs an 95 authentication protocol exchange. This consists of a series of 96 server challenges and client responses that are specific to the 97 requested mechanism. The challenges and responses are defined by the 98 mechanisms as binary tokens of arbitrary length. The protocol's 99 profile then specifies how these binary tokens are then encoded for 100 transfer over the connection. 102 After receiving the authentication command or any client response, a 103 server may issue a challenge, indicate failure, or indicate 104 completion. The protocol's profile specifies how the server 105 indicates which of the above it is doing. 107 After receiving a challenge, a client may issue a response or abort 108 the exchange. The protocol's profile specifies how the client 109 indicates which of the above it is doing. 111 During the authentication protocol exchange, the mechanism performs 112 authentication, transmits an authorization identity (frequently known 113 as a userid) from the client to server, and negotiates the use of a 114 mechanism-specific session layer. If the use of a session layer is 115 agreed upon, then the mechanism must also define or negotiate the 116 maximum cipher-text buffer size that each side is able to receive. 118 If use of a session layer is negotiated, it is applied to all 119 subsequent data sent over the connection. The session layer takes 120 effect immediately following the last response of the authentication 121 exchange for data sent by the client and the completion indication 122 for data sent by the server. Once the session layer is in effect, 123 the protocol stream is processed by the session layer into buffers of 124 cipher-text. Each buffer is transferred over the connection as a 125 stream of octets prepended with a four octet field in network byte 126 order that represents the length of the following buffer. The length 127 of the cipher-text buffer must be no larger than the maximum size 128 that was defined or negotiated by the other side. 130 Internet DRAFT SASL June 3, 1996 132 4. Profiling requirements 134 In order to use this specification, a protocol definition must supply 135 the following information: 137 1. A service name, to be selected from the IANA registry of "service" 138 elements for the GSSAPI host-based service name form. [GSSAPI] 140 2. A definition of the command to initiate the authentication 141 protocol exchange. This command must have as a parameter the 142 mechanism name being selected by the client. 144 3. A definition of the method by which the authentication protocol 145 exchange is carried out, including how the challenges and 146 responses are encoded, how the server indicates completion or 147 failure of the exchange, how the client aborts an exchange, and 148 how the exchange method interacts with any line length limits in 149 the protocol. 151 4. Identification of the octet where any negotiated session layer 152 starts to take effect, in both directions. 154 5. A specification of how the authorization identity passed from the 155 client to the server is to be interpreted. 157 5. Registration procedures 159 The following documents the procedure for registering new SASL 160 mechanism types. 162 While the registration procedures do not require it, authors of SASL 163 mechanisms are encouraged to seek community review and comment 164 whenever that is feasable. Authors may seek community review by 165 posting a specification of their proposed mechanism as an internet- 166 draft. 168 5.1. Comments on SASL mechanism registrations 170 Comments on registered SASL mechanisms may be submitted by members of 171 the community to IANA. These comments will be passed on to the 172 "owner" of the mechanism if possible. Submitters of comments may 173 request that their comment be attached to the SASL mechanism 174 registration itself, and if IANA approves of this the comment will be 175 made accessible in conjunction with the SASL mechanism registration 176 itself. 178 Internet DRAFT SASL June 3, 1996 180 5.2. Location of Registered SASL Mechanism List 182 Media type registrations will be posted in the anonymous FTP 183 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- 184 mechanisms/" and all registered SASL mechanisms will be listed in the 185 periodically issued "Assigned Numbers" RFC [currently RFC- 1700]. 186 The SASL mechanism description and other supporting material may also 187 be published as an Informational RFC by sending it to "rfc- 188 editor@isi.edu" (please follow the instructions to RFC authors [RFC- 189 1543]). 191 5.2. Change Control 193 Once a SASL mechanism registration has been published by IANA, the 194 author may request a change to its definition. The change request 195 follows the same procedure as the registration request. 197 The owner of a content type may pass responsibility for the content 198 type to another person or agency by informing IANA; this can be done 199 without discussion or review. 201 The IESG may reassign responsibility for a SASL mechanism. The most 202 common case of this will be to enable changes to be made to types 203 where the author of the registration has died, moved out of contact 204 or is otherwise unable to make changes that are important to the 205 community. 207 SASL mechanism registrations may not be deleted; mechanisms which are 208 no longer believed appropriate for use can be declared OBSOLETE by a 209 change to their "intended use" field; such SASL mechanisms will be 210 clearly marked in the lists published by IANA. 212 5.3. Registration Template 214 To: iana@isi.edu 215 Subject: Registration of SASL mechanism XXX 217 SASL mechanism name: 219 Security considerations: 221 Published specification (optional, recommended): 223 Person & email address to contact for further information: 225 Intended usage: 227 Internet DRAFT SASL June 3, 1996 229 (One of COMMON, LIMITED USE or OBSOLETE) 231 Author/Change controller: 233 (Any other information that the author deems interesting may be 234 added below this line.) 236 6. Mechanism definitions 238 The following mechanisms are hereby defined. 240 6.1. Kerberos version 4 mechanism 242 The mechanism name associated with Kerberos version 4 is 243 "KERBEROS_V4". 245 The first challenge consists of a random 32-bit number in network 246 byte order. The client responds with a Kerberos ticket and an 247 authenticator for the principal "service.hostname@realm", where 248 "service" is the service name specified in the protocol's profile, 249 "hostname" is the first component of the host name of the server with 250 all letters in lower case, and where "realm" is the Kerberos realm of 251 the server. The encrypted checksum field included within the 252 Kerberos authenticator contains the server provided challenge in 253 network byte order. 255 Upon decrypting and verifying the ticket and authenticator, the 256 server verifies that the contained checksum field equals the original 257 server provided random 32-bit number. Should the verification be 258 successful, the server must add one to the checksum and construct 8 259 octets of data, with the first four octets containing the incremented 260 checksum in network byte order, the fifth octet containing a bit-mask 261 specifying the protection mechanisms supported by the server, and the 262 sixth through eighth octets containing, in network byte order, the 263 maximum cipher-text buffer size the server is able to receive. The 264 server must encrypt the 8 octets of data in the session key and issue 265 that encrypted data in a second challenge. The client considers the 266 server authenticated if the first four octets the un-encrypted data 267 is equal to one plus the checksum it previously sent. 269 The client must construct data with the first four octets containing 270 the original server-issued checksum in network byte order, the fifth 271 octet containing the bit-mask specifying the selected protection 272 mechanism, the sixth through eighth octets containing in network byte 273 order the maximum cipher-text buffer size the client is able to 274 receive, and the following octets containing the authorization 275 identity. The client must then append from one to eight zero-valued 276 octets so that the length of the data is a multiple of eight octets. 278 Internet DRAFT SASL June 3, 1996 280 The client must then PCBC encrypt the data with the session key and 281 respond with the encrypted data. The server decrypts the data and 282 verifies the contained checksum. The server must verify that the 283 principal identified in the Kerberos ticket is authorized to connect 284 as that authorization identiy. After these verifications, the 285 authentication process is complete. 287 The protection mechanisms and their corresponding bit-masks are as 288 follows: 290 1 No protection mechanism 291 2 Integrity (krb_mk_safe) protection 292 4 Privacy (krb_mk_priv) protection 294 EXAMPLE: The following are two Kerberos version 4 login scenarios to 295 the IMAP4 protocol (note that the line breaks in the sample 296 authenticators are for editorial clarity and are not in real 297 authenticators) 299 S: * OK IMAP4 Server 300 C: A001 AUTHENTICATE KERBEROS_V4 301 S: + AmFYig== 302 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 303 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 304 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 305 S: + or//EoAADZI= 306 C: DiAF5A4gA+oOIALuBkAAmw== 307 S: A001 OK Kerberos V4 authentication successful 309 S: * OK IMAP4 Server 310 C: A001 AUTHENTICATE KERBEROS_V4 311 S: + gcfgCA== 312 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 313 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 314 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 315 S: A001 NO Kerberos V4 authentication failed 317 Internet DRAFT SASL June 3, 1996 319 6.2. GSSAPI mechanism 321 The mechanism name associated with all mechanisms employing the 322 GSSAPI [GSSAPI] is "GSSAPI". 324 The first challenge issued by the server contains no data. The 325 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. 337 If GSS_Init_sec_context returns GSS_COMPLETE, then the client 338 responds with any resulting output_token. If there is no 339 output_token, the client responds with no data. The client should 340 then expect the server to issue a token in a subsequent challenge. 341 The client passes this token to GSS_Unseal and interprets the first 342 octet of resulting cleartext as a bit-mask specifying the protection 343 mechanisms supported by the server and the second through fourth 344 octets as the maximum size output_message to send to the server. The 345 client then constructs data, with the first octet containing the 346 bit-mask specifying the selected protection mechanism, the second 347 through fourth octets containing in network byte order the maximum 348 size output_message the client is able to receive, and the remaining 349 octets containing the authorization identity. The client passs the 350 data to GSS_Seal with conf_flag set to FALSE, and responds with the 351 generated output_message. The client can then consider the server 352 authenticated. 354 The server starts by issuing a challenge with no data. It passes the 355 resulting client response to GSS_Accept_sec_context as input_token, 356 setting acceptor_cred_handle to NULL (for "use default credentials"), 357 and 0 for input_context_handle (initially). If 358 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server 359 returns the generated output_token to the client in challenge and 360 passes the resulting response to another call to 361 GSS_Accept_sec_context. 363 If GSS_Accept_sec_context returns GSS_COMPLETE, then if an 364 output_token is returned, the server returns it to the client in a 365 challenge and expects a reply from the client with no data. Whether 366 or not an output_token was returned, the server then constructs 4 368 Internet DRAFT SASL June 3, 1996 370 octets of data, with the first octet containing a bit-mask specifying 371 the protection mechanisms supported by the server and the second 372 through fourth octets containing in network byte order the maximum 373 size output_token the server is able to receive. The server must 374 then pass the plaintext to GSS_Seal with conf_flag set to FALSE and 375 issue the generated output_message to the client in a challenge. The 376 server must then pass the resulting response to GSS_Unseal and 377 interpret the first octet of resulting cleartext as the bit-mask for 378 the selected protection mechanism, the second through fourth octets 379 as the maximum size output_message to send to the client, and the 380 remaining octets as the authroization identity. Upon verifying the 381 src_name is authorized to authenticate as the authorization identity, 382 The server should then consider the client authenticated. 384 The protection mechanisms and their corresponding bit-masks are as 385 follows: 387 1 No protection mechanism 388 2 Integrity protection. 389 Sender calls GSS_Seal with conf_flag set to FALSE 390 4 Privacy protection. 391 Sender calls GSS_Seal with conf_flag set to TRUE 393 Internet DRAFT SASL June 3, 1996 395 6.4. S/Key mechanism 397 The mechanism name associated with S/Key [SKEY] is "SKEY". 399 The challenge issued by the server contains no data. The client 400 responds with the authorization identity. 402 The data encoded in the second ready response contains the decimal 403 sequence number followed by a single space and the seed string for 404 the indicated authorization identity. The client responds with the 405 one-time-password, as either a 64-bit value in network byte order or 406 encoded in the "six English words" format. 408 Upon successful verification of the one-time-password, the server 409 should consider the client authenticated. 411 S/Key authentication does not provide for any protection mechanisms. 413 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 414 protocol. 416 S: * OK IMAP4 Server 417 C: A001 AUTHENTICATE SKEY 418 S: + 419 C: bW9yZ2Fu 420 S: + OTUgUWE1ODMwOA== 421 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 422 S: A001 OK S/Key authentication successful 424 S: * OK IMAP4 Server 425 C: A001 AUTHENTICATE SKEY 426 S: + 427 C: c21pdGg= 428 S: + OTUgUWE1ODMwOA== 429 C: BsAY3g4gBNo= 430 S: A001 NO S/Key authentication failed 432 Internet DRAFT SASL June 3, 1996 434 7. References 436 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 437 RFC 1730, University of Washington, December 1994. 439 [GSSAPI] Linn, J., "Generic Security Service Application Program 440 Interface, Version 2", draft-ietf-cat-gssv2-XX, Geer Zolot 441 Associates, May 1996 443 [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 444 October 1993 446 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 447 1760, Bellcore, February 1995 449 8. Security Considerations 451 Security issues are discussed throughout this memo. 453 The mechanisms that support integrity protection are designed such 454 that the negotiation of the session layer and authorization identity 455 is integrity protected. When the client selects a session layer with 456 at least integrity protection, this protects against an active 457 attacker hijacking the connection and modifying the authentication 458 exchange to negotiate a plaintext connection. 460 The client's selection of an mechanism is done in the clear and may 461 be modified by an active attacker. It is important for any new 462 authentiction mechanisms to be designed such that credentials for 463 existing mechanisms are not usable. 465 Any protocol interactions prior to authentication are performed in 466 the clear and may be modified by an active attacker. In the case 467 where a client selects integrity protection, it is important that any 468 security-sensitive protocol negotiations be performed after 469 authenticaiton is complete. Protocols should be designed such that 470 negotiations performed prior to authentication should be ignored once 471 authentication is complete. 473 9. Author's Address 475 John G. Myers 476 Carnegie-Mellon University 477 5000 Forbes Ave. 478 Pittsburgh PA, 15213-3890 480 EMail: jgm+@cmu.edu 482 Internet DRAFT SASL June 3, 1996 484 Table of Contents 486 Status of this Memo ............................................... i 487 1. Abstract ..................................................... 2 488 2. Organization of this Document ................................ 2 489 2.1. How to Read This Document .................................... 2 490 2.2. Conventions Used in this Document ............................ 2 491 2.3. Examples ..................................................... 2 492 3. Introduction and Overview .................................... 2 493 4. Profiling requirements ....................................... 4 494 5. Registration procedures ...................................... 4 495 5.1. Comments on SASL mechanism registrations ..................... 4 496 5.2. Location of Registered SASL Mechanism List .................. 5 497 5.2. Change Control .............................................. 5 498 5.3. Registration Template ....................................... 5 499 6. Mechanism definitions ........................................ 6 500 6.1. Kerberos version 4 mechanism ................................. 6 501 6.2. GSSAPI mechanism ............................................. 8 502 6.4. S/Key mechanism .............................................. 10 503 7. References ................................................... 11 504 8. Security Considerations ...................................... 11 505 9. Author's Address ............................................. 11