idnits 2.17.1 draft-ietf-cat-sasl-gssapi-05.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 4 instances of too long lines in the document, the longest one being 6 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 2001) is 8381 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) == Missing Reference: 'THIS-DOC' is mentioned on line 343, but not defined -- Looks like a reference, but probably isn't: '15' on line 444 -- Looks like a reference, but probably isn't: '16' on line 542 -- Looks like a reference, but probably isn't: '0' on line 547 -- Looks like a reference, but probably isn't: '1' on line 551 -- Looks like a reference, but probably isn't: '2' on line 519 -- Looks like a reference, but probably isn't: '3' on line 521 -- Looks like a reference, but probably isn't: '4' on line 522 -- Looks like a reference, but probably isn't: '1024' on line 536 -- Looks like a reference, but probably isn't: '21' on line 543 == Unused Reference: 'IMAP4' is defined on line 362, but no explicit reference was found in the text -- 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 (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft Netscape Communications 4 Document: draft-ietf-cat-sasl-gssapi-05.txt May 2001 6 SASL GSSAPI mechanisms 8 Status of this Memo 10 Internet-Drafts are working documents of the Internet Engineering 11 Task Force (IETF), its areas, and its working groups. Note that 12 other groups may also distribute working documents as Internet- 13 Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. 29 A revised version of this draft document will be submitted to the RFC 30 editor as a Proposed Standard for the Internet Community. Discussion 31 and suggestions for improvement are requested. 33 NOTE TO RFC EDITOR: Prior to publication as an RFC, the RFC Editor is 34 directed to replace occurrences of "[THIS-DOC]" with the RFC number 35 assigned to this document. 37 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 39 1. Abstract 41 The Simple Authentication and Security Layer [SASL] is a method for 42 adding authentication support to connection-based protocols. This 43 document describes the method for using the Generic Security Service 44 Application Program Interface [GSSAPI] in the Simple Authentication 45 and Security Layer [SASL]. 47 This document replaces section 7.2 of RFC 2222 [SASL], the definition 48 of the "GSSAPI" SASL mechanism. 50 2. Conventions Used in this Document 52 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 53 in this document are to be interpreted as defined in "Key words for 54 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 56 3. Introduction and Overview 58 Each and every GSSAPI mechanism used within SASL is implicitly 59 registered by this specification. 61 For backwards compatibility with existing implementations of Kerberos 62 V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5 63 GSSAPI mechanism [GSSAPI-KERBEROS] is "GSSAPI" and the SASL mechanism 64 for the SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL 65 mechanism name for any other GSSAPI mechanism is the concatenation of 66 "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash 67 [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI mechanism's OID. 68 Base32 encoding is described later in this document. The Base32 69 rules on padding characters and characters outside of the base32 70 alphabet are not relevant to this use of Base32. 72 SASL mechanism names starting with "GSS-" are reserved for SASL 73 mechanisms which conform to this document. 75 The specification of all SASL mechanisms conforming to this document 76 is in the "Specification common to all GSSAPI mechanisms" section of 77 this document. 79 The IESG is considered to be the owner of all SASL mechanisms which 80 conform to this document. This does NOT necessarily imply that the 81 IESG is considered to be the owner of the underlying GSSAPI 82 mechanism. 84 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 86 3.1 Example 88 The OID for the SPKM-1 mechanism [SPKM] is 1.3.6.1.5.5.1. The ASN.1 89 DER encoding of this OID is 06 06 2b 06 01 05 05 01. The MD5 hash of 90 the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46 91 8a 30. The Base32 encoding of the first ten bytes of this is 92 "K7XIDASOVRG3BZSQ". Thus the SASL mechanism name for the SPKM-1 93 GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ". 95 4. SPNEGO 97 Use of the Simple and Protected GSS-API Negotiation Mechanism 98 [SPNEGO] underneath SASL introduces subtle interoperability problems 99 and security considerations. To address these, this section places 100 additional requirements on implementations which support SPNEGO 101 underneath SASL. 103 A client which supports, for example, the Kerberos V5 GSSAPI 104 mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL 105 mechanism will not interoperate with a server which supports the 106 Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL 107 mechanism. 109 Since SASL is capable of negotiating amongst GSSAPI mechanisms, the 110 only reason for a server or client to support the "GSS-SPNEGO" 111 mechanism is to allow a policy of only using mechanisms below a 112 certain strength if those mechanism's negotiation is protected. In 113 such a case, a client or server would only want to negotiate those 114 weaker mechanisms through SPNEGO. In any case, there is no down- 115 negotiation security consideration with using the strongest mechanism 116 and set of options the implementation supports, so for 117 interoperability that mechanism and set of options MUST be negotiable 118 without using the "GSS-SPNEGO" mechanism. 120 If a client's policy is to first prefer GSSAPI mechanism X, then 121 non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server 122 supports mechanisms Y and Z but not X, then if the client attempts to 123 negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it 124 may end up using mechanism Z when it should have used mechanism Y. 125 For this reason, implementations MUST exclude from SPNEGO those 126 GSSAPI mechanisms which are weaker than the strongest non-GSSAPI SASL 127 mechanism advertised by the server. 129 5. Base32 encoding 131 The Base32 encoding is designed to represent arbitrary sequences of 132 octets in a form that needs to be case insensitive but need not be 133 humanly readable. 135 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 137 A 33-character subset of US-ASCII is used, enabling 5 bits to be 138 represented per printable character. (The extra 33rd character, "=", 139 is used to signify a special processing function.) 141 The encoding process represents 40-bit groups of input bits as output 142 strings of 8 encoded characters. Proceeding from left to right, a 143 40-bit input group is formed by concatenating 5 8bit input groups. 144 These 40 bits are then treated as 8 concatenated 5-bit groups, each 145 of which is translated into a single digit in the base32 alphabet. 146 When encoding a bit stream via the base32 encoding, the bit stream 147 must be presumed to be ordered with the most-significant-bit first. 148 That is, the first bit in the stream will be the high-order bit in 149 the first 8bit byte, and the eighth bit will be the low-order bit in 150 the first 8bit byte, and so on. 152 Each 5-bit group is used as an index into an array of 32 printable 153 characters. The character referenced by the index is placed in the 154 output string. These characters, identified in Table 1, below, are 155 selected from US-ASCII digits and uppercase letters. 157 Table 1: The Base32 Alphabet 159 Value Encoding Value Encoding Value Encoding Value Encoding 160 0 A 9 J 18 S 27 3 161 1 B 10 K 19 T 28 4 162 2 C 11 L 20 U 29 5 163 3 D 12 M 21 V 30 6 164 4 E 13 N 22 W 31 7 165 5 F 14 O 23 X 166 6 G 15 P 24 Y (pad) = 167 7 H 16 Q 25 Z 168 8 I 17 R 26 2 170 Special processing is performed if fewer than 40 bits are available 171 at the end of the data being encoded. A full encoding quantum is 172 always completed at the end of a body. When fewer than 40 input bits 173 are available in an input group, zero bits are added (on the right) 174 to form an integral number of 5-bit groups. Padding at the end of 175 the data is performed using the "=" character. Since all base32 176 input is an integral number of octets, only the following cases can 177 arise: (1) the final quantum of encoding input is an integral 178 multiple of 40 bits; here, the final unit of encoded output will be 179 an integral multiple of 8 characters with no "=" padding, (2) the 180 final quantum of encoding input is exactly 8 bits; here, the final 181 unit of encoded output will be two characters followed by six "=" 182 padding characters, (3) the final quantum of encoding input is 183 exactly 16 bits; here, the final unit of encoded output will be four 184 characters followed by four "=" padding characters, (4) the final 186 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 188 quantum of encoding input is exactly 24 bits; here, the final unit of 189 encoded output will be five characters followed by three "=" padding 190 characters, or (5) the final quantum of encoding input is exactly 32 191 bits; here, the final unit of encoded output will be seven characters 192 followed by one "=" padding character. 194 Because it is used only for padding at the end of the data, the 195 occurrence of any "=" characters may be taken as evidence that the 196 end of the data has been reached (without truncation in transit). No 197 such assurance is possible, however, when the number of octets 198 transmitted was a multiple of 8 and no "=" characters are present. 200 Any characters outside of the base32 alphabet are to be ignored in 201 base32-encoded data. 203 6. Specification common to all GSSAPI mechanisms 205 Each SASL mechanism which uses a GSSAPI mechanism uses the following 206 specification. 208 The implementation MAY set any GSSAPI flags or arguments not 209 mentioned in this specification as is necessary for the 210 implementation to enforce its security policy. 212 6.1. Client side of authentication protocol exchange 214 The client calls GSS_Init_sec_context, passing in 215 input_context_handle of 0 (initially), mech_type of the GSSAPI 216 mechanism for which this SASL mechanism is registered, chan_binding 217 of NULL, and targ_name equal to output_name from GSS_Import_Name 218 called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and 219 input_name_string of "service@hostname" where "service" is the 220 service name specified in the protocol's profile, and "hostname" is 221 the fully qualified host name of the server. If the client will be 222 requesting a security layer, it MUST also supply to the 223 GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag 224 of TRUE, and an integ_req_flag of TRUE. If the client will be 225 requesting a security layer providing confidentiality protection, it 226 MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. 227 The client then responds with the resulting output_token. If 228 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 229 should expect the server to issue a token in a subsequent challenge. 230 The client must pass the token to another call to 231 GSS_Init_sec_context, repeating the actions in this paragraph. 233 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 234 the context to ensure that it provides a level of protection 235 permitted by the client's security policy. If the context is 237 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 239 acceptable, the client takes the following actions: If the last call 240 to GSS_Init_sec_context returned an output_token, then the client 241 responds with the output_token, otherwise the client responds with no 242 data. The client should then expect the server to issue a token in a 243 subsequent challenge. The client passes this token to GSS_Unwrap and 244 interprets the first octet of resulting cleartext as a bit-mask 245 specifying the security layers supported by the server and the second 246 through fourth octets as the network byte order maximum size 247 output_message to send to the server (if the resulting cleartext is 248 not 4 octets long, the client fails the negotiation). The client 249 then constructs data, with the first octet containing the bit-mask 250 specifying the selected security layer, the second through fourth 251 octets containing in network byte order the maximum size 252 output_message the client is able to receive, and the remaining 253 octets containing the UTF-8 encoded [UTF8] authorization identity. 254 The authorization identity is not NUL-terminated. The client passes 255 the data to GSS_Wrap with conf_flag set to FALSE, and responds with 256 the generated output_message. The client can then consider the 257 server authenticated. 259 6.2. Server side of authentication protocol exchange 261 The server passes the initial client response to 262 GSS_Accept_sec_context as input_token, setting input_context_handle 263 to 0 (initially), mech_type of the GSSAPI mechanism for which this 264 SASL mechanism is registered, chan_binding of NULL, and 265 acceptor_cred_handle equal to output_cred_handle from 266 GSS_Acquire_cred called with desired_name equal to output_name from 267 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE 268 and input_name_string of "service@hostname" where "service" is the 269 service name specified in the protocol's profile, and "hostname" is 270 the fully qualified host name of the server. If 271 GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server 272 returns the generated output_token to the client in challenge and 273 passes the resulting response to another call to 274 GSS_Accept_sec_context, repeating the actions in this paragraph. 276 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 277 examines the context to ensure that it provides a level of protection 278 permitted by the server's security policy. If the context is 279 acceptable, the server takes the following actions: If the last call 280 to GSS_Accept_sec_context returned an output_token, the server 281 returns it to the client in a challenge and expects a reply from the 282 client with no data. Whether or not an output_token was returned 283 (and after receipt of any response from the client to such an 284 output_token), the server then constructs 4 octets of data, with the 285 first octet containing a bit-mask specifying the security layers 286 supported by the server and the second through fourth octets 288 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 290 containing in network byte order the maximum size output_token the 291 server is able to receive. The server must then pass the plaintext 292 to GSS_Wrap with conf_flag set to FALSE and issue the generated 293 output_message to the client in a challenge. The server must then 294 pass the resulting response to GSS_Unwrap and interpret the first 295 octet of resulting cleartext as the bit-mask for the selected 296 security layer, the second through fourth octets as the network byte 297 order maximum size output_message to send to the client, and the 298 remaining octets as the authorization identity. The server must 299 verify that the src_name is authorized to authenticate as the 300 authorization identity. After these verifications, the 301 authentication process is complete. 303 6.3. Security layer 305 The security layers and their corresponding bit-masks are as follows: 307 1 No security layer 308 2 Integrity protection. 309 Sender calls GSS_Wrap with conf_flag set to FALSE 310 4 Confidentiality protection. 311 Sender calls GSS_Wrap with conf_flag set to TRUE 313 Other bit-masks may be defined in the future; bits which are not 314 understood must be negotiated off. 316 Note that SASL negotiates the maximum size of the output_message to 317 send. Implementations can use the GSS_Wrap_size_limit call to 318 determine the corresponding maximum size input_message. 320 7. IANA Considerations 322 The IANA is advised that SASL mechanism names starting with "GSS-" 323 are reserved for SASL mechanisms which conform to this document. The 324 IANA is directed to place a statement to that effect in the sasl- 325 mechanisms registry. 327 The IANA is directed to modify the existing registration for "GSSAPI" 328 in the "sasl-mechanisms" so that RFC [THIS-DOC] is listed as the 329 published specification. Add the descriptive text "This mechanism is 330 for the Kerberos V5 mechanism of GSSAPI. Other GSSAPI mechanisms use 331 other SASL mechanism names, as described in this mechanism's 332 published specification." 334 The IANA is directed to modify the existing registration for "GSS- 335 SPNEGO" as follows. 337 SASL mechanism name: GSS-SPNEGO 339 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 341 Security considerations: See the "SPNEGO" section of RFC [THIS-DOC]. 343 Published Specification: RFC [THIS-DOC] 345 Intended usage: LIMITED USE 347 Author/Change controller: iesg@ietf.org 349 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 351 8. References 353 [ASN1] ISO/IEC 8824, "Specification of Abstract Syntax Notation One 354 (ASN.1)" 356 [GSSAPI] Linn, J., "Generic Security Service Application Program 357 Interface Version 2, Update 1", RFC 2743, January 2000 359 [GSSAPI-KERBEROS] Linn, J., "The Kerberos Version 5 GSS-API 360 Mechanism", RFC 1964, June 1996 362 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 363 RFC 1730, University of Washington, December 1994. 365 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 366 Requirement Levels", RFC 2119, March 1997 368 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 369 1992 371 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 372 RFC 2222, October 1997 374 [SPKM] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 375 RFC 2025, October 1996 377 [SPNEGO] Baize, E., Pinkas., D., "The Simple and Protected GSS-API 378 Negotiation Mechanism", RFC 2478, December 1998 380 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 381 RFC 2279, January 1998 383 9. Security Considerations 385 Security issues are discussed throughout this memo. 387 When a server or client supports multiple authentication mechanisms, 388 each of which has a different security strength, it is possible for 389 an active attacker to cause a party to use the least secure mechanism 390 supported. To protect against this sort of attack, a client or 391 server which supports mechanisms of different strengths should have a 392 configurable minimum strength that it will use. It is not sufficient 393 for this minimum strength check to only be on the server, since an 394 active attacker can change which mechanisms the client sees as being 395 supported, causing the client to send authentication credentials for 396 its weakest supported mechanism. 398 The client's selection of a SASL mechanism is done in the clear and 400 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 402 may be modified by an active attacker. It is important for any new 403 SASL mechanisms to be designed such that an active attacker cannot 404 obtain an authentication with weaker security properties by modifying 405 the SASL mechanism name and/or the challenges and responses. 407 SPNEGO [SPNEGO] has protection against many of these down-negotiation 408 attacks, SASL does not itself have such protection. The section 409 titled "SPNEGO" mentions considerations of choosing negotiation 410 through SASL versus SPNEGO. 412 The integrity protection provided by the security layer is useless to 413 the client unless the client also requests mutual authentication. 414 Therefore, a client wishing to benefit from the integrity protection 415 of a security layer MUST pass to the GSS_Init_sec_context call a 416 mutual_req_flag of TRUE. 418 Additional security considerations are in the SASL [SASL] and GSSAPI 419 [GSSAPI] specifications. 421 10. Author's Address 423 John G. Myers 424 Netscape Communications 425 501 E. Middlefield Road 426 Mail Stop SCA 15:201 427 Mountain View, CA 94043-4042 429 Email: jgmyers@netscape.com 431 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 433 Appendix A. Sample code 435 The following is an example program which converts mechanism OIDs (of 436 the form "1.3.6.1.5.5.1") to SASL mechanism names. This sample 437 program uses the reference MD5 implementation in [MD5]. 439 #include 440 #include "md5.h" 442 static const 443 struct compat_map { 444 const unsigned char oid[15]; 445 const char *saslname; 446 } compat_map[] = { 447 { { 0x06, 0x05, 0x2b, 0x05, 0x01, 0x05, 0x02 }, "GSSAPI" }, 448 { { 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x12, 0x01, 0x02, 0x02 }, 449 "GSSAPI" }, /* old Kerberos V5 OID */ 450 { { 0x06, 0x06, 0x2b, 0x06, 0x01, 0x05, 0x05, 0x02 }, "GSS-SPNEGO" }, 451 }; 453 static unsigned long parsenum(char **ptr) 454 { 455 unsigned long rval = 0; 456 while (**ptr >= '0' && **ptr <= '9') { 457 rval = rval * 10 + *(*ptr)++ - '0'; 458 } 459 return rval; 460 } 462 static void asn1encode(unsigned long val, unsigned char **buf) 463 { 464 unsigned long tmpval; 465 int noctets = 1; 466 for (tmpval = val; tmpval >= 128; tmpval >>= 7) noctets++; 467 while (--noctets) { 468 *(*buf)++ = ((val >> (7 * noctets)) & 0x7f) | 0x80; 469 } 470 *(*buf)++ = val & 0x7f; 471 } 473 static char basis_32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; 475 /* 476 * Convert the GSSAPI mechanism 'oid' of length 'oidlen', placing 477 * the result into 'retbuf', which must be of size 21 478 */ 479 void oidToSaslMech(const unsigned char *oid, unsigned oidlen, char *retbuf) 480 { 482 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 484 int i; 485 MD5_CTX md5ctx; 486 unsigned char md5buf[16]; 487 char *out; 488 unsigned char *in; 489 unsigned char *p; 490 int len; 492 /* See if it has a backwards-compatibility SASL mechanism name */ 493 for (i = 0; i < (sizeof(compat_map) / sizeof(compat_map[0])); i++) { 494 if (memcmp(compat_map[i].oid, oid, oidlen) == 0) { 495 strcpy(retbuf, compat_map[i].saslname); 496 return; 497 } 498 } 500 MD5Init(&md5ctx); 501 MD5Update(&md5ctx, (unsigned char *)oid, oidlen); 502 MD5Final(md5buf, &md5ctx); 504 printf("MD5 hash: "); 505 for (p = md5buf; p < md5buf + 16; p++) { 506 printf("%02x ", *p); 507 } 508 printf("\n"); 510 in = md5buf; 511 strcpy(retbuf, "GSS-"); 512 out = retbuf + strlen(retbuf); 513 len = 10; 514 while (len) { 515 *out++ = basis_32[in[0] >> 3]; 516 *out++ = basis_32[((in[0] & 7) << 2) | (in[1] >> 6)]; 517 *out++ = basis_32[(in[1] & 0x3f) >> 1]; 518 *out++ = basis_32[((in[1] & 1) << 4) | (in[2] >> 4)]; 519 *out++ = basis_32[((in[2] & 0xf) << 1) | (in[3] >> 7)]; 520 *out++ = basis_32[(in[3] & 0x7f) >> 2]; 521 *out++ = basis_32[((in[3] & 3) << 3) | (in[4] >> 5)]; 522 *out++ = basis_32[(in[4] & 0x1f)]; 523 in += 5; 524 len -= 5; 525 } 526 *out++ = '\0'; 527 } 529 main(int argc, char **argv) 530 { 531 char *oidstr; 533 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 535 unsigned long val1, val2; 536 unsigned char asn1buf[1024]; 537 unsigned char *asn1start = asn1buf + 4; 538 unsigned char *asn1next = asn1start; 539 unsigned char *asn1lennext; 540 unsigned char *p; 541 MD5_CTX md5ctx; 542 unsigned char md5buf[16]; 543 char saslmechbuf[21]; 544 int i; 546 if (argc != 2) { 547 fprintf(stderr, "usage: %s oid\n", argv[0]); 548 exit(1); 549 } 551 oidstr = argv[1]; 552 val1 = parsenum(&oidstr); 553 if (*oidstr++ != '.') goto badoid; 554 val2 = parsenum(&oidstr); 555 if (*oidstr && *oidstr++ != '.') goto badoid; 556 *asn1next++ = val1 * 40 + val2; 558 while (*oidstr) { 559 val1 = parsenum(&oidstr); 560 if (*oidstr && *oidstr++ != '.') goto badoid; 562 asn1encode(val1, &asn1next); 563 } 565 /* Now that we know the length of the OID, generate the tag 566 * and length 567 */ 568 asn1lennext = asn1next; 569 *asn1lennext++ = 6; 570 asn1encode(asn1next - asn1start, &asn1lennext); 572 /* Copy tag and length to beginning */ 573 memcpy(asn1start - (asn1lennext - asn1next), asn1next, 574 asn1lennext - asn1next); 575 asn1start -= asn1lennext - asn1next; 577 printf("ASN.1 DER encoding: "); 578 for (p = asn1start; p < asn1next; p++) { 579 printf("%02x ", *p); 580 } 581 printf("\n"); 583 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 585 oidToSaslMech(asn1start, asn1next - asn1start, saslmechbuf); 586 printf("SASL mechanism name: %s\n", saslmechbuf); 588 exit(0); 590 badoid: 591 fprintf(stderr, "bad oid syntax\n"); 592 exit(1); 593 } 595 Internet DRAFT GSSAPI SASL mechanisms May 30, 2001 597 Table of Contents 599 Status of this Memo ............................................... i 600 1. Abstract .................................................... 2 601 2. Conventions Used in this Document ........................... 2 602 3. Introduction and Overview ................................... 2 603 3.1 Example ..................................................... 3 604 4. SPNEGO ...................................................... 3 605 5. Base32 encoding ............................................. 3 606 6. Specification common to all GSSAPI mechanisms ............... 5 607 6.1. Client side of authentication protocol exchange ............. 5 608 6.2. Server side of authentication protocol exchange ............. 6 609 6.3. Security layer .............................................. 7 610 7. IANA Considerations ......................................... 7 611 8. References .................................................. 9 612 9. Security Considerations ..................................... 9 613 10. Author's Address ............................................ 10 614 Appendix A. Sample code ........................................... 11