idnits 2.17.00 (12 Aug 2021) /tmp/idnits25522/draft-ietf-cat-sasl-gssapi-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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 5 characters in excess of 72. ** The abstract seems to contain references ([GSSAPI], [SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 2000) is 8040 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 433 -- Looks like a reference, but probably isn't: '1' on line 437 -- Looks like a reference, but probably isn't: '2' on line 410 -- Looks like a reference, but probably isn't: '3' on line 412 -- Looks like a reference, but probably isn't: '4' on line 413 -- Looks like a reference, but probably isn't: '1024' on line 425 -- Looks like a reference, but probably isn't: '16' on line 430 -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2478 (ref. 'SPNEGO') (Obsoleted by RFC 4178) ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Myers 2 Internet Draft Netscape Communications 3 Document: draft-ietf-cat-sasl-gssapi-01.txt May 2000 5 SASL GSSAPI mechanisms 7 Status of this Memo 9 Internet-Drafts are working documents of the Internet Engineering 10 Task Force (IETF), its areas, and its working groups. Note that 11 other groups may also distribute working documents as Internet- 12 Drafts. 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 A revised version of this draft document will be submitted to the RFC 29 editor as a Proposed Standard for the Internet Community. Discussion 30 and suggestions for improvement are requested. 32 Internet DRAFT SASL May 23, 2000 34 1. Abstract 36 The Simple Authentication and Security Layer [SASL] is a method for 37 adding authentication support to connection-based protocols. This 38 document describes the method for using the Generic Security Service 39 Application Program Interface [GSSAPI] in the Simple Authentication 40 and Security Layer [SASL]. 42 This document amends section 7.2 of RFC 2222 [SASL], the definition 43 of the "GSSAPI" SASL mechanism. 45 2. Organization of this Document 47 2.1. How to Read This Document 49 [TODO: is this section needed?] 51 2.2. Conventions Used in this Document 53 In examples, "C:" and "S:" indicate lines sent by the client and 54 server respectively. 56 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 57 in this document are to be interpreted as defined in "Key words for 58 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 60 2.3. Examples 62 [TODO: No examples included. Needed?] 64 Examples in this document are for the IMAP profile [IMAP4] of this 65 specification. The base64 encoding of challenges and responses, as 66 well as the "+ " preceding the responses are part of the IMAP4 67 profile, not part of the SASL specification itself. 69 3. Introduction and Overview 71 Each and every GSSAPI mechanism used within SASL is implicitly 72 registered by this specification. 74 For backwards compatibility with existing implementations of Kerberos 75 V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5 76 GSSAPI mechanism [GSSAPI-KERBEROS] is "GSSAPI" and the SASL mechanism 77 for the SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL 78 mechanism name for any other GSSAPI mechanism is the concatenation of 79 "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash 80 [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI mechanism's OID. 81 Base32 encoding is described later in this document 83 Internet DRAFT SASL May 23, 2000 85 SASL mechanism names starting with "GSS-" are reserved for SASL 86 mechanisms which conform to this document. 88 The specification of all SASL mechanisms conforming to this document 89 is in the "Specification common to all GSSAPI mechanisms" section of 90 this document. 92 The IESG is considered to be the owner of all SASL mechanisms which 93 conform to this document. This does NOT imply that the IESG is 94 considered to be the owner of the underlying GSSAPI mechanism. 96 4. SPNEGO 98 Implementations SHOULD NOT use the Simple and Protected GSS-API 99 Negotiation Mechanism [SPNEGO] underneath SASL. 101 A client which supports, for example, the Kerberos V5 GSSAPI 102 mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL 103 mechanism will not interoperate with a server which supports the 104 Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL 105 mechanism. 107 If a client's policy is to first prefer GSSAPI mechanism X, then 108 non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server 109 supports mechanisms Y and Z but not X, then if the client attempts to 110 negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it 111 may end up using mechanism Z when it should have used mechanism Y. 113 One reason a server or client might want to violate the above SHOULD 114 directive is if it has a policy of only using mechanisms below a 115 certain strength if their negotiation is protected. In such a case, 116 it would only want to negotiate those weaker mechnisms through 117 SPNEGO. In any case, there is no down-negotiation security 118 consideration with using the strongest mechanism and set of options 119 the implementation supports, so for interoperability that mechanism 120 and set of options MUST be negotiable without using the "GSS-SPNEGO" 121 mechanism. 123 5. Base32 encoding 125 The Base32 encoding is designed to represent arbitrary sequences of 126 octets in a form that needs to be case insensitive but need not be 127 humanly readable. 129 A 33-character subset of US-ASCII is used, enabling 5 bits to be 130 represented per printable character. (The extra 33rd character, "=", 131 is used to signify a special processing function.) 133 Internet DRAFT SASL May 23, 2000 135 The encoding process represents 40-bit groups of input bits as output 136 strings of 8 encoded characters. Proceeding from left to right, a 137 40-bit input group is formed by concatenating 5 8bit input groups. 138 These 40 bits are then treated as 8 concatenated 5-bit groups, each 139 of which is translated into a single digit in the base32 alphabet. 140 When encoding a bit stream via the base32 encoding, the bit stream 141 must be presumed to be ordered with the most-significant-bit first. 142 That is, the first bit in the stream will be the high-order bit in 143 the first 8bit byte, and the eighth bit will be the low-order bit in 144 the first 8bit byte, and so on. 146 Each 5-bit group is used as an index into an array of 32 printable 147 characters. The character referenced by the index is placed in the 148 output string. These characters, identified in Table 1, below, are 149 selected from US-ASCII digits and uppercase letters. 151 Table 1: The Base32 Alphabet 153 Value Encoding Value Encoding Value Encoding Value Encoding 154 0 A 9 J 18 S 27 3 155 1 B 10 K 19 T 28 4 156 2 C 11 L 20 U 29 5 157 3 D 12 M 21 V 30 6 158 4 E 13 N 22 W 31 7 159 5 F 14 O 23 X 160 6 G 15 P 24 Y (pad) = 161 7 H 16 Q 25 Z 162 8 I 17 R 26 2 164 Special processing is performed if fewer than 40 bits are available 165 at the end of the data being encoded. A full encoding quantum is 166 always completed at the end of a body. When fewer than 40 input bits 167 are available in an input group, zero bits are added (on the right) 168 to form an integral number of 5-bit groups. Padding at the end of 169 the data is performed using the "=" character. Since all base32 170 input is an integral number of octets, only the following cases can 171 arise: (1) the final quantum of encoding input is an integral 172 multiple of 40 bits; here, the final unit of encoded output will be 173 an integral multiple of 4 characters with no "=" padding, (2) the 174 final quantum of encoding input is exactly 8 bits; here, the final 175 unit of encoded output will be two characters followed by six "=" 176 padding characters, (3) the final quantum of encoding input is 177 exactly 16 bits; here, the final unit of encoded output will be four 178 characters followed by four "=" padding characters, (4) the final 179 quantum of encoding input is exactly 24 bits; here, the final unit of 180 encoded output will be five characters followed by five"=" padding 181 characters, or (5) the final quantum of encoding input is exactly 32 182 bits; here, the final unit of encoded output will be seven characters 184 Internet DRAFT SASL May 23, 2000 186 followed by one "=" padding character. 188 Because it is used only for padding at the end of the data, the 189 occurrence of any "=" characters may be taken as evidence that the 190 end of the data has been reached (without truncation in transit). No 191 such assurance is possible, however, when the number of octets 192 transmitted was a multiple of three and no "=" characters are 193 present. 195 Any characters outside of the base32 alphabet are to be ignored in 196 base32-encoded data. 198 6. Specification common to all GSSAPI mechanisms 200 Each SASL mechanism which uses a GSSAPI mechanism uses the following 201 specification. 203 6.1. Client side of authentication protocol exchange 205 The client calls GSS_Init_sec_context, passing in 206 input_context_handle of 0 (initially), mech_type of the GSSAPI 207 mechanism for which this SASL mechanism is registered, and targ_name 208 equal to output_name from GSS_Import_Name called with input_name_type 209 of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 210 "service@hostname" where "service" is the service name specified in 211 the protocol's profile, and "hostname" is the fully qualified host 212 name of the server. The client then responds with the resulting 213 output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, 214 then the client should expect the server to issue a token in a 215 subsequent challenge. The client must pass the token to another call 216 to GSS_Init_sec_context, repeating the actions in this paragraph. 218 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes 219 the following actions: If the last call to GSS_Init_sec_context 220 returned an output_token, then the client responds with the 221 output_token, otherwise the client responds with no data. The client 222 should then expect the server to issue a token in a subsequent 223 challenge. The client passes this token to GSS_Unwrap and interprets 224 the first octet of resulting cleartext as a bit-mask specifying the 225 security layers supported by the server and the second through fourth 226 octets as the maximum size output_message to send to the server. The 227 client then constructs data, with the first octet containing the 228 bit-mask specifying the selected security layer, the second through 229 fourth octets containing in network byte order the maximum size 230 output_message the client is able to receive, and the remaining 231 octets containing the UTF-8 encoded [UTF8] authorization identity. 232 The client passes the data to GSS_Wrap with conf_flag set to FALSE, 233 and responds with the generated output_message. The client can then 235 Internet DRAFT SASL May 23, 2000 237 consider the server authenticated. 239 6.2. Server side of authentication protocol exchange 241 The server passes the initial client response to 242 GSS_Accept_sec_context as input_token, setting input_context_handle 243 to 0 (initially). If GSS_Accept_sec_context returns 244 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 245 to the client in challenge and passes the resulting response to 246 another call to GSS_Accept_sec_context, repeating the actions in this 247 paragraph. 249 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server takes 250 the following actions: If the last call to GSS_Accept_sec_context 251 returned an output_token, the server returns it to the client in a 252 challenge and expects a reply from the client with no data. Whether 253 or not an output_token was returned (and after receipt of any 254 response from the client to such an output_token), the server then 255 constructs 4 octets of data, with the first octet containing a bit- 256 mask specifying the security layers supported by the server and the 257 second through fourth octets containing in network byte order the 258 maximum size output_token the server is able to receive. The server 259 must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE 260 and issue the generated output_message to the client in a challenge. 261 The server must then pass the resulting response to GSS_Unwrap and 262 interpret the first octet of resulting cleartext as the bit-mask for 263 the selected security layer, the second through fourth octets as the 264 maximum size output_message to send to the client, and the remaining 265 octets as the authorization identity. The server must verify that 266 the src_name is authorized to authenticate as the authorization 267 identity. After these verifications, the authentication process is 268 complete. 270 6.3. Security layer 272 The security layers and their corresponding bit-masks are as follows: 274 1 No security layer 275 2 Integrity protection. 276 Sender calls GSS_Wrap with conf_flag set to FALSE 277 4 Privacy protection. 278 Sender calls GSS_Wrap with conf_flag set to TRUE 279 Other bit-masks may be defined in the future; bits which are not 280 understood must be negotiated off. 282 Internet DRAFT SASL May 23, 2000 284 7. IANA Considerations 286 The IANA is directed to modify the existing registration for "GSSAPI" 287 in the "sasl-mechanisms" so that this document is listed as the 288 published specification. Add the descriptive text "This mechanism is 289 for the Kerberos V5 mechanism of GSSAPI. Other GSSAPI mechanisms use 290 other SASL mechanism names, as described in this mechanism's 291 published specification." 293 The IANA is advised that SASL mechanism names starting with "GSS-" 294 are reserved for SASL mechanisms which conform to this document. 296 Internet DRAFT SASL May 23, 2000 298 8. References 300 [ASN1] ISO/IEC 8824, "Specification of Abstract Syntax Notation One 301 (ASN.1)" 303 [GSSAPI] Linn, J., "Generic Security Service Application Program 304 Interface Version 2, Update 1", RFC 2743, January 2000 306 [GSSAPI-KERBEROS] Linn, J., "The Kerberos Version 5 GSS-API 307 Mechanism", RFC 1964, June 1996 309 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 310 RFC 1730, University of Washington, December 1994. 312 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 313 Requirement Levels", RFC 2119, March 1997 315 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 316 1992 318 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 319 RFC 2222, October 1997 321 [SPNEGO] Baize, E., Pinkas., D., "The Simple and Protected GSS-API 322 Negotiation Mechanism", RFC 2478, December 1998 324 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 325 RFC 2279, January 1998 327 9. Security Considerations 329 Security issues are discussed throughout this memo. 331 When a server or client supports multiple authentication mechanisms, 332 each of which has a different security strength, it is possible for 333 an active attacker to cause a party to use the least secure mechanism 334 supported. To protect against this sort of attack, a client or 335 server which supports mechanisms of different strengths should have a 336 configurable minimum strength that it will use. It is not sufficient 337 for this minimum strength check to only be on the server, since an 338 active attacker can change which mechanisms the client sees as being 339 supported, causing the client to send authentication credentials for 340 its weakest supported mechanism. 342 The client's selection of a SASL mechanism is done in the clear and 343 may be modified by an active attacker. It is important for any new 344 SASL mechanisms to be designed such that an active attacker cannot 345 obtain an authentication with weaker security properties by modifying 347 Internet DRAFT SASL May 23, 2000 349 the SASL mechanism name and/or the challenges and responses. 351 SPNEGO [SPNEGO] has protection against many of these down-negotiation 352 attacks, SASL does not itself have such protection. The section 353 titled "SPNEGO" mentions considerations of choosing negotiation 354 through SASL versus SPNEGO. 356 Additional security considerations are in the SASL [SASL] and GSSAPI 357 [GSSAPI] specifications. 359 10. Author's Address 361 John G. Myers 362 Netscape Communications 363 501 E. Middlefield Road 364 Mail Stop SCA 15:201 365 Mountain View, CA 94043-4042 367 Email: jgmyers@netscape.com 369 Internet DRAFT SASL May 23, 2000 371 Appendix A. Sample code 373 The following is an example program which converts mechanism OIDs (of 374 the form "1.3.6.1.5.5.1") to SASL mechanism names. This sample 375 program uses the reference MD5 implementation in [MD5]. 377 #include 378 #include "md5.h" 380 unsigned long parsenum(char **ptr) 381 { 382 unsigned long rval = 0; 383 while (**ptr >= '0' && **ptr <= '9') { 384 rval = rval * 10 + *(*ptr)++ - '0'; 385 } 386 return rval; 387 } 389 void encode(unsigned long val, unsigned char **buf) 390 { 391 unsigned long tmpval; 392 int noctets = 1; 393 for (tmpval = val; tmpval >= 128; tmpval >>= 7) noctets++; 394 while (--noctets) { 395 *(*buf)++ = ((val >> (7 * noctets)) & 0x7f) | 0x80; 396 } 397 *(*buf)++ = val & 0x7f; 398 } 400 static char basis_32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; 402 void base32encode10(unsigned char *buf) 403 { 404 int len = 10; 405 while (len) { 406 putc(basis_32[buf[0] >> 3], stdout); 407 putc(basis_32[((buf[0] & 7) << 2) | (buf[1] >> 6)], stdout); 408 putc(basis_32[(buf[1] & 0x3f) >> 1], stdout); 409 putc(basis_32[((buf[1] & 1) << 4) | (buf[2] >> 4)], stdout); 410 putc(basis_32[((buf[2] & 0xf) << 1) | (buf[3] >> 7)], stdout); 411 putc(basis_32[(buf[3] & 0x7f) >> 2], stdout); 412 putc(basis_32[((buf[3] & 3) << 3) | (buf[4] >> 5)], stdout); 413 putc(basis_32[(buf[4] & 0x1f)], stdout); 414 len -= 5; 415 } 416 } 418 main(int argc, char **argv) 420 Internet DRAFT SASL May 23, 2000 422 { 423 char *oidstr; 424 unsigned long val1, val2; 425 unsigned char asn1buf[1024]; /* Had better be big enough */ 426 unsigned char *asn1next = asn1buf; 427 unsigned char *asn1lennext; 428 unsigned char *p; 429 MD5_CTX md5ctx; 430 unsigned char md5buf[16]; 432 if (argc != 2) { 433 fprintf(stderr, "usage: %s oid\n", argv[0]); 434 exit(1); 435 } 437 oidstr = argv[1]; 438 val1 = parsenum(&oidstr); 439 if (*oidstr++ != '.') goto badoid; 440 val2 = parsenum(&oidstr); 441 if (*oidstr && *oidstr++ != '.') goto badoid; 442 *asn1next++ = val1 * 40 + val2; 444 while (*oidstr) { 445 val1 = parsenum(&oidstr); 446 if (*oidstr && *oidstr++ != '.') goto badoid; 448 encode(val1, &asn1next); 449 } 451 /* Now that we know the length of the OID, generate the tag 452 * and length 453 */ 454 asn1lennext = asn1next; 455 *asn1lennext++ = 6; 456 encode(asn1next - asn1buf, &asn1lennext); 458 printf("ASN.1 DER encoding: "); 459 for (p = asn1next; p < asn1lennext; p++) { 460 printf("%02x ", *p); 461 } 462 for (p = asn1buf; p < asn1next; p++) { 463 printf("%02x ", *p); 464 } 465 printf("\n"); 467 MD5Init(&md5ctx); 468 MD5Update(&md5ctx, (unsigned char *)asn1next, asn1lennext - asn1next); 469 MD5Update(&md5ctx, (unsigned char *)asn1buf, asn1next - asn1buf); 471 Internet DRAFT SASL May 23, 2000 473 MD5Final(md5buf, &md5ctx); 475 printf("MD5 hash: "); 476 for (p = md5buf; p < md5buf + 16; p++) { 477 printf("%02x ", *p); 478 } 479 printf("\n"); 481 printf("SASL mechanism name: GSS-"); 482 base32encode10(md5buf); 483 printf("\n"); 485 exit(0); 486 badoid: 487 fprintf(stderr, "incorrect oid syntax\n"); 488 exit(1); 489 } 491 Internet DRAFT SASL May 23, 2000 493 Table of Contents 495 Status of this Memo ............................................... i 496 1. Abstract .................................................... 2 497 2. Organization of this Document ............................... 2 498 2.1. How to Read This Document ................................... 2 499 2.2. Conventions Used in this Document ........................... 2 500 2.3. Examples .................................................... 2 501 3. Introduction and Overview ................................... 2 502 4. SPNEGO ...................................................... 3 503 5. Base32 encoding ............................................. 3 504 6. Specification common to all GSSAPI mechanisms ............... 5 505 6.1. Client side of authentication protocol exchange ............. 5 506 6.2. Server side of authentication protocol exchange ............. 6 507 6.3. Security layer .............................................. 6 508 7. IANA Considerations ......................................... 7 509 8. References .................................................. 8 510 9. Security Considerations ..................................... 8 511 10. Author's Address ............................................ 9 512 Appendix A. Sample code ........................................... 10