idnits 2.17.1 draft-myers-auth-sasl-04.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-26) 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 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 220 instances 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 10147 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: 13 errors (**), 0 flaws (~~), 3 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 Carnegie Mellon 4 Document: draft-myers-auth-sasl-04.txt July 1996 6 Simple Authentication and Security 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 July 22, 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 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 2.3. Examples 71 Examples in this document are for the IMAP profile [IMAP4] of this 72 specification. The base64 encoding of challenges and responses, as 73 well as the "+ " preceeding the responses are part of the IMAP4 74 profile, not part of the SASL specification itself. 76 3. Introduction and Overview 78 The Simple Authentication and Security 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 July 22, 1996 85 security layer 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 initiates 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 security layer. If the use of a security 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 security layer is negotiated, it is applied to all 119 subsequent data sent over the connection. The security 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 security layer is in effect, 123 the protocol stream is processed by the security layer into buffers 124 of 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 July 22, 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 security 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 feasible. 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 July 22, 1996 180 5.2. Location of Registered SASL Mechanism List 182 SASL mechanism 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 July 22, 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 security layers supported by the server, and the sixth 262 through eighth octets containing, in network byte order, the maximum 263 cipher-text buffer size the server is able to receive. The server 264 must encrypt using DES ECB mode the 8 octets of data in the session 265 key and issue that encrypted data in a second challenge. The client 266 considers the server authenticated if the first four octets of the 267 un-encrypted data is equal to one plus the checksum it previously 268 sent. 270 The client must construct data with the first four octets containing 271 the original server-issued checksum in network byte order, the fifth 272 octet containing the bit-mask specifying the selected security layer, 273 the sixth through eighth octets containing in network byte order the 274 maximum cipher-text buffer size the client is able to receive, and 275 the following octets containing the authorization identity. The 276 client must then append from one to eight zero-valued octets so that 278 Internet DRAFT SASL July 22, 1996 280 the length of the data is a multiple of eight octets. The client must 281 then encrypt using DES PCBC mode the data with the session key and 282 respond with the encrypted data. The server decrypts the data and 283 verifies the contained checksum. The server must verify that the 284 principal identified in the Kerberos ticket is authorized to connect 285 as that authorization identity. After this verification, the 286 authentication process is complete. 288 The security layers and their corresponding bit-masks are as follows: 290 1 No security layer 291 2 Integrity (krb_mk_safe) protection 292 4 Privacy (krb_mk_priv) protection 293 Other bit-masks may be defined in the future; bits which are not 294 understood must be negotiated off. 296 EXAMPLE: The following are two Kerberos version 4 login scenarios to 297 the IMAP4 protocol (note that the line breaks in the sample 298 authenticators are for editorial clarity and are not in real 299 authenticators) 301 S: * OK IMAP4 Server 302 C: A001 AUTHENTICATE KERBEROS_V4 303 S: + AmFYig== 304 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 305 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 306 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 307 S: + or//EoAADZI= 308 C: DiAF5A4gA+oOIALuBkAAmw== 309 S: A001 OK Kerberos V4 authentication successful 311 S: * OK IMAP4 Server 312 C: A001 AUTHENTICATE KERBEROS_V4 313 S: + gcfgCA== 314 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 315 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 316 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 317 S: A001 NO Kerberos V4 authentication failed 319 Internet DRAFT SASL July 22, 1996 321 6.2. GSSAPI mechanism 323 The mechanism name associated with all mechanisms employing the 324 GSSAPI [GSSAPI] is "GSSAPI". 326 6.2.1 Client side of authentication protocol exchange 328 The first challenge issued by the server contains no data. 330 The client calls GSS_Init_sec_context, passing in 0 for 331 input_context_handle (initially) and a targ_name equal to output_name 332 from GSS_Import_Name called with input_name_type of 333 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 334 "service@hostname" where "service" is the service name specified in 335 the protocol's profile, and "hostname" is the fully qualified host 336 name of the server. The client then responds with the resulting 337 output_token. If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, 338 then the client should expect the server to issue a token in a 339 subsequent challenge. The client must pass the token to another call 340 to GSS_Init_sec_context, repeating the actions in this paragraph. 342 When GSS_Init_sec_context returns GSS_COMPLETE, the client takes the 343 following actions: If the last call to GSS_Init_sec_context returned 344 an output_token, then the client responds with the output_token, 345 otherwise the client responds with no data. The client should then 346 expect the server to issue a token in a subsequent challenge. The 347 client passes this token to GSS_Unseal and interprets the first octet 348 of resulting cleartext as a bit-mask specifying the protection 349 mechanisms supported by the server and the second through fourth 350 octets as the maximum size output_message to send to the server. The 351 client then constructs data, with the first octet containing the 352 bit-mask specifying the selected protection mechanism, the second 353 through fourth octets containing in network byte order the maximum 354 size output_message the client is able to receive, and the remaining 355 octets containing the authorization identity. The client passes the 356 data to GSS_Seal with conf_flag set to FALSE, and responds with the 357 generated output_message. The client can then consider the server 358 authenticated. 360 6.2.2 Server side of authentication protocol exchange 362 The server starts by issuing a challenge with no data. It passes the 363 resulting client response to GSS_Accept_sec_context as input_token, 364 setting acceptor_cred_handle to NULL (for "use default credentials"), 365 and 0 for input_context_handle (initially). If 366 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server 367 returns the generated output_token to the client in challenge and 368 passes the resulting response to another call to 370 Internet DRAFT SASL July 22, 1996 372 GSS_Accept_sec_context, repeating the actions in this paragraph. 374 When GSS_Accept_sec_context returns GSS_COMPLETE, the client takes 375 the following actions: If the last call to GSS_Accept_sec_context 376 returned an output_token, the server returns it to the client in a 377 challenge and expects a reply from the client with no data. Whether 378 or not an output_token was returned (and after receipt of any respons 379 from the client to such an output_token), the server then constructs 380 4 octets of data, with the first octet containing a bit-mask 381 specifying the protection mechanisms supported by the server and the 382 second through fourth octets containing in network byte order the 383 maximum size output_token the server is able to receive. The server 384 must then pass the plaintext to GSS_Seal with conf_flag set to FALSE 385 and issue the generated output_message to the client in a challenge. 386 The server must then pass the resulting response to GSS_Unseal and 387 interpret the first octet of resulting cleartext as the bit-mask for 388 the selected protection mechanism, the second through fourth octets 389 as the maximum size output_message to send to the client, and the 390 remaining octets as the authorization identity. The server must 391 verify that the src_name is authorized to authenticate as the 392 authorization identity. After these verifications, the 393 authentication process is complete. 395 6.2.3 Security layer 397 The security layers and their corresponding bit-masks are as follows: 399 1 No security layer 400 2 Integrity protection. 401 Sender calls GSS_Seal with conf_flag set to FALSE 402 4 Privacy protection. 403 Sender calls GSS_Seal with conf_flag set to TRUE 404 Other bit-masks may be defined in the future; bits which are not 405 understood must be negotiated off. 407 Internet DRAFT SASL July 22, 1996 409 6.3. S/Key mechanism 411 The mechanism name associated with S/Key [SKEY] is "SKEY". 413 The challenge issued by the server contains no data. The client 414 responds with the authorization identity. 416 The data encoded in the second ready response contains the decimal 417 sequence number followed by a single space and the seed string for 418 the indicated authorization identity. The client responds with the 419 one-time-password, as either a 64-bit value in network byte order or 420 encoded in the "six English words" format. 422 The server musth verify the one-time-password. After this 423 verification, the authentication process is complete. 425 S/Key authentication does not provide for any security layers. 427 EXAMPLE: The following are two S/Key login scenarios in the IMAP4 428 protocol. 430 S: * OK IMAP4 Server 431 C: A001 AUTHENTICATE SKEY 432 S: + 433 C: bW9yZ2Fu 434 S: + OTUgUWE1ODMwOA== 435 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 436 S: A001 OK S/Key authentication successful 438 S: * OK IMAP4 Server 439 C: A001 AUTHENTICATE SKEY 440 S: + 441 C: c21pdGg= 442 S: + OTUgUWE1ODMwOA== 443 C: BsAY3g4gBNo= 444 S: A001 NO S/Key authentication failed 446 Internet DRAFT SASL July 22, 1996 448 7. References 450 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 451 RFC 1730, University of Washington, December 1994. 453 [GSSAPI] Linn, J., "Generic Security Service Application Program 454 Interface, Version 2", draft-ietf-cat-gssv2-XX, OpenVision 455 Technologies, May 1996 457 [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 458 October 1993 460 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC 461 1760, Bellcore, February 1995 463 8. Security Considerations 465 Security issues are discussed throughout this memo. 467 The mechanisms that support integrity protection are designed such 468 that the negotiation of the security layer and authorization identity 469 is integrity protected. When the client selects a security layer 470 with at least integrity protection, this protects against an active 471 attacker hijacking the connection and modifying the authentication 472 exchange to negotiate a plaintext connection. 474 The client's selection of an SASL mechanism is done in the clear and 475 may be modified by an active attacker. It is important for any new 476 SASL mechanisms to be designed such that an active attacker cannot 477 obtain an authentication with weaker security properties by modifying 478 the SASL mechanism name and/or the challenges and responses. 480 Any protocol interactions prior to authentication are performed in 481 the clear and may be modified by an active attacker. In the case 482 where a client selects integrity protection, it is important that any 483 security-sensitive protocol negotiations be performed after 484 authentication is complete. Protocols should be designed such that 485 negotiations performed prior to authentication should be either 486 ignored or revalidated once authentication is complete. 488 9. Author's Address 490 John G. Myers 491 Carnegie-Mellon University 492 5000 Forbes Ave. 493 Pittsburgh PA, 15213-3890 495 EMail: jgm+@cmu.edu 497 Internet DRAFT SASL July 22, 1996 499 Internet DRAFT SASL July 22, 1996 501 Table of Contents 503 Status of this Memo ............................................... i 504 1. Abstract ..................................................... 2 505 2. Organization of this Document ................................ 2 506 2.1. How to Read This Document .................................... 2 507 2.2. Conventions Used in this Document ............................ 2 508 2.3. Examples ..................................................... 2 509 3. Introduction and Overview .................................... 2 510 4. Profiling requirements ....................................... 4 511 5. Registration procedures ...................................... 4 512 5.1. Comments on SASL mechanism registrations ..................... 4 513 5.2. Location of Registered SASL Mechanism List .................. 5 514 5.2. Change Control .............................................. 5 515 5.3. Registration Template ....................................... 5 516 6. Mechanism definitions ........................................ 6 517 6.1. Kerberos version 4 mechanism ................................. 6 518 6.2. GSSAPI mechanism ............................................. 8 519 6.2.1 Client side of authentication protocol exchange ............. 8 520 6.2.2 Server side of authentication protocol exchange ............. 8 521 6.2.3 Security layer .............................................. 9 522 6.3. S/Key mechanism .............................................. 10 523 7. References ................................................... 11 524 8. Security Considerations ...................................... 11 525 9. Author's Address ............................................. 11