idnits 2.17.1 draft-ietf-sasl-gssapi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 452. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 427), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (June 25, 2004) is 7244 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) == Missing Reference: 'THIS-DOC' is mentioned on line 308, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3548 (ref. 'BASE-ENCODING') (Obsoleted by RFC 4648) ** 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: 15 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SASL Working Group A. Melnikov 2 Internet-Draft Isode 3 Expires: December 24, 2004 June 25, 2004 5 SASL GSSAPI mechanisms 6 draft-ietf-sasl-gssapi-01 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on December 24, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The Simple Authentication and Security Layer [SASL] is a method for 38 adding authentication support to connection-based protocols. This 39 document describes the method for using the Generic Security Service 40 Application Program Interface [GSSAPI] in the Simple Authentication 41 and Security Layer [SASL]. 43 This document replaces section 7.2 of RFC 2222 [SASL], the definition 44 of the "GSSAPI" SASL mechanism. 46 Table of Contents 48 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 49 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 50 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Specification common to all GSSAPI mechanisms . . . . . . . . 6 53 4.1 Client side of authentication protocol exchange . . . . . . . 6 54 4.2 Server side of authentication protocol exchange . . . . . . . 7 55 4.3 Security layer . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 59 Normative References . . . . . . . . . . . . . . . . . . . . . 13 60 Informative References . . . . . . . . . . . . . . . . . . . . 14 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 62 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 64 1. Conventions Used in this Document 66 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 67 in this document are to be interpreted as defined in "Key words for 68 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 70 2. Introduction and Overview 72 Each and every GSSAPI mechanism used within SASL is implicitly 73 registered by this specification. 75 For backwards compatibility with existing implementations of Kerberos 76 V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5 77 GSSAPI mechanism [KRB5GSS] is "GSSAPI" and the SASL mechanism for the 78 SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL mechanism 79 name for any other GSSAPI mechanism is the concatenation of "GSS-" 80 and the Base32 [BASE-ENCODING] encoding of the first ten bytes of the 81 MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI 82 mechanism's OID. The Base32 rules on padding characters and 83 characters outside of the base32 alphabet are not relevant to this 84 use of Base32. 86 SASL mechanism names starting with "GSS-" are reserved for SASL 87 mechanisms which conform to this document. 89 The specification of all SASL mechanisms conforming to this document 90 is in the "Specification common to all GSSAPI mechanisms" section of 91 this document. 93 The IESG is considered to be the owner of all SASL mechanisms which 94 conform to this document. This does NOT necessarily imply that the 95 IESG is considered to be the owner of the underlying GSSAPI 96 mechanism. 98 2.1 Example 100 The OID for the SPKM-1 mechanism [SPKM1] is 1.3.6.1.5.5.1. The ASN.1 101 DER encoding of this OID is 06 06 2b 06 01 05 05 01. The MD5 hash of 102 the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46 103 8a 30. The Base32 encoding of the first ten bytes of this is 104 "K7XIDASOVRG3BZSQ". Thus the SASL mechanism name for the SPKM-1 105 GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ". 107 3. SPNEGO 109 Use of the Simple and Protected GSS-API Negotiation Mechanism 110 [SPNEGO] underneath SASL introduces subtle interoperability problems 111 and security considerations. To address these, this section places 112 additional requirements on implementations which support SPNEGO 113 underneath SASL. 115 A client which supports, for example, the Kerberos V5 GSSAPI 116 mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL 117 mechanism will not interoperate with a server which supports the 118 Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL 119 mechanism. 121 Since SASL is capable of negotiating amongst GSSAPI mechanisms, the 122 only reason for a server or client to support the "GSS-SPNEGO" 123 mechanism is to allow a policy of only using mechanisms below a 124 certain strength if those mechanism's negotiation is protected. In 125 such a case, a client or server would only want to negotiate those 126 weaker mechanisms through SPNEGO. In any case, there is no down- 127 negotiation security consideration with using the strongest mechanism 128 and set of options the implementation supports, so for 129 interoperability that mechanism and set of options MUST be negotiable 130 without using the "GSS-SPNEGO" mechanism. 132 If a client's policy is to first prefer GSSAPI mechanism X, then non- 133 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports 134 mechanisms Y and Z but not X, then if the client attempts to 135 negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it 136 may end up using mechanism Z when it should have used mechanism Y. 137 For this reason, implementations MUST exclude from SPNEGO those 138 GSSAPI mechanisms which are weaker than the strongest non-GSSAPI SASL 139 mechanism advertised by the server. 141 4. Specification common to all GSSAPI mechanisms 143 Each SASL mechanism which uses a GSSAPI mechanism uses the following 144 specification. 146 The implementation MAY set any GSSAPI flags or arguments not 147 mentioned in this specification as is necessary for the 148 implementation to enforce its security policy. 150 4.1 Client side of authentication protocol exchange 152 The client calls GSS_Init_sec_context, passing in 153 input_context_handle of 0 (initially), mech_type of the GSSAPI 154 mechanism for which this SASL mechanism is registered, chan_binding 155 of NULL, and targ_name equal to output_name from GSS_Import_Name 156 called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and 157 input_name_string of "service@hostname" where "service" is the 158 service name specified in the protocol's profile, and "hostname" is 159 the fully qualified host name of the server. If the client will be 160 requesting a security layer, it MUST also supply to the 161 GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag 162 of TRUE, and an integ_req_flag of TRUE. If the client will be 163 requesting a security layer providing confidentiality protection, it 164 MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. 165 The client then responds with the resulting output_token. If 166 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 167 should expect the server to issue a token in a subsequent challenge. 168 The client must pass the token to another call to 169 GSS_Init_sec_context, repeating the actions in this paragraph. 171 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 172 the context to ensure that it provides a level of protection 173 permitted by the client's security policy. If the context is 174 acceptable, the client takes the following actions: If the last call 175 to GSS_Init_sec_context returned an output_token, then the client 176 responds with the output_token, otherwise the client responds with no 177 data. The client should then expect the server to issue a token in a 178 subsequent challenge. The client passes this token to GSS_Unwrap and 179 interprets the first octet of resulting cleartext as a bit-mask 180 specifying the security layers supported by the server and the second 181 through fourth octets as the network byte order maximum size 182 output_message to send to the server (if the resulting cleartext is 183 not 4 octets long, the client fails the negotiation). The client 184 then constructs data, with the first octet containing the bit-mask 185 specifying the selected security layer, the second through fourth 186 octets containing in network byte order the maximum size 187 output_message the client is able to receive, and the remaining 188 octets containing the UTF-8 [UTF8] encoded authorization identity. 190 (Implementation note: the authorization identity is not terminated 191 with the NUL (%x00) character). The client passes the data to 192 GSS_Wrap with conf_flag set to FALSE, and responds with the generated 193 output_message. The client can then consider the server 194 authenticated. 196 4.2 Server side of authentication protocol exchange 198 The server passes the initial client response to 199 GSS_Accept_sec_context as input_token, setting input_context_handle 200 to 0 (initially), mech_type of the GSSAPI mechanism for which this 201 SASL mechanism is registered, chan_binding of NULL, and 202 acceptor_cred_handle equal to output_cred_handle from 203 GSS_Acquire_cred called with desired_name equal to output_name from 204 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE 205 and input_name_string of "service@hostname" where "service" is the 206 service name specified in the protocol's profile, and "hostname" is 207 the fully qualified host name of the server. If 208 GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server 209 returns the generated output_token to the client in challenge and 210 passes the resulting response to another call to 211 GSS_Accept_sec_context, repeating the actions in this paragraph. 213 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 214 examines the context to ensure that it provides a level of protection 215 permitted by the server's security policy. If the context is 216 acceptable, the server takes the following actions: If the last call 217 to GSS_Accept_sec_context returned an output_token, the server 218 returns it to the client in a challenge and expects a reply from the 219 client with no data. Whether or not an output_token was returned 220 (and after receipt of any response from the client to such an 221 output_token), the server then constructs 4 octets of data, with the 222 first octet containing a bit-mask specifying the security layers 223 supported by the server and the second through fourth octets 224 containing in network byte order the maximum size output_token the 225 server is able to receive. The server must then pass the plaintext 226 to GSS_Wrap with conf_flag set to FALSE and issue the generated 227 output_message to the client in a challenge. The server must then 228 pass the resulting response to GSS_Unwrap and interpret the first 229 octet of resulting cleartext as the bit-mask for the selected 230 security layer, the second through fourth octets as the network byte 231 order maximum size output_message to send to the client, and the 232 remaining octets as the authorization identity. The server must 233 verify that the src_name is authorized to authenticate as the 234 authorization identity. After these verifications, the 235 authentication process is complete. 237 4.3 Security layer 239 The security layers and their corresponding bit-masks are as follows: 241 1 No security layer 242 2 Integrity protection. 243 Sender calls GSS_Wrap with conf_flag set to FALSE 244 4 Confidentiality protection. 245 Sender calls GSS_Wrap with conf_flag set to TRUE 247 Other bit-masks may be defined in the future; bits which are not 248 understood must be negotiated off. 250 Note that SASL negotiates the maximum size of the output_message to 251 send. Implementations can use the GSS_Wrap_size_limit call to 252 determine the corresponding maximum size input_message. 254 5. IANA Considerations 256 The IANA is advised that SASL mechanism names starting with "GSS-" 257 are reserved for SASL mechanisms which conform to this document. The 258 IANA is directed to place a statement to that effect in the sasl- 259 mechanisms registry. 261 Family of SASL mechanisms: YES 263 Prefix: GSS- 265 Security considerations: RFC [THIS-DOC] 267 Published Specification: RFC [THIS-DOC] 269 Person & email address to contact for further information: Alexey 270 Melnikov 272 Intended usage: COMMON 274 Owner/Change controller: iesg@ietf.org 276 The IANA is directed to modify the existing registration for "GSSAPI" 277 as follows: 279 Family of SASL mechanisms: NO 281 SASL mechanism name: GSSAPI 283 Security considerations: ? 285 Published Specification: RFC [THIS-DOC] 287 Person & email address to contact for further information: Alexey 288 Melnikov 290 Intended usage: COMMON 292 Owner/Change controller: iesg@ietf.org 294 Additional Information: This mechanism is for the Kerberos V5 295 mechanism of GSSAPI. Other GSSAPI mechanisms use other SASL 296 mechanism names, as described in this mechanism's published 297 specification. 299 The IANA is directed to modify the existing registration for "GSS- 300 SPNEGO" as follows: 302 Family of SASL mechanisms: NO 304 SASL mechanism name: GSS-SPNEGO 306 Security considerations: See the "SPNEGO" section of RFC [THIS-DOC]. 308 Published Specification: RFC [THIS-DOC] 310 Person & email address to contact for further information: Alexey 311 Melnikov 313 Intended usage: LIMITED USE 315 Owner/Change controller: iesg@ietf.org 317 6. Security Considerations 319 Security issues are discussed throughout this memo. 321 When a server or client supports multiple authentication mechanisms, 322 each of which has a different security strength, it is possible for 323 an active attacker to cause a party to use the least secure mechanism 324 supported. To protect against this sort of attack, a client or 325 server which supports mechanisms of different strengths should have a 326 configurable minimum strength that it will use. It is not sufficient 327 for this minimum strength check to only be on the server, since an 328 active attacker can change which mechanisms the client sees as being 329 supported, causing the client to send authentication credentials for 330 its weakest supported mechanism. 332 The client's selection of a SASL mechanism is done in the clear and 333 may be modified by an active attacker. It is important for any new 334 SASL mechanisms to be designed such that an active attacker cannot 335 obtain an authentication with weaker security properties by modifying 336 the SASL mechanism name and/or the challenges and responses. 338 [SPNEGO] has protection against many of these down-negotiation 339 attacks, SASL does not itself have such protection. The section 340 titled "SPNEGO" mentions considerations of choosing negotiation 341 through SASL versus SPNEGO. 343 The integrity protection provided by the security layer is useless to 344 the client unless the client also requests mutual authentication. 345 Therefore, a client wishing to benefit from the integrity protection 346 of a security layer MUST pass to the GSS_Init_sec_context call a 347 mutual_req_flag of TRUE. 349 When constructing the input_name_string, the client should not 350 canonicalize the server's fully qualified domain name using an 351 insecure or untrusted directory service. 353 Additional security considerations are in the [SASL] and [GSSAPI] 354 specifications. Additional security considerations for the GSSAPI 355 mechanism can be found in [KRB5GSS]. 357 7. Acknowledgements 359 This document is a revision of RFC 2222 written by John G. Myers. 360 He also contributed significantly to this revision. 362 Thank you to Lawrence Greenfield for converting text of this draft to 363 XML format. 365 Contributions of many members of the SASL mailing list are gratefully 366 acknowledged. 368 Normative References 370 [ASN1] International Organization for Standardization, 371 "Information Processing Systems - Open Systems 372 Interconnection - Specification of Abstract Syntax 373 Notation One (ASN.1)", ISO Standard 8824, December 374 1990. 376 [BASE-ENCODING] Josefsson, S., "The Base16, Base32, and Base64 Data 377 Encodings", RFC 3548, July 2003. 379 [GSSAPI] Linn, J., "Generic Security Service Application 380 Program Interface Version 2, Update 1", RFC 2743, 381 January 2000. 383 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API 387 Mechanism", RFC 1964, June 1996. 389 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 390 1321, April 1992. 392 [SASL] Myers, J., "Simple Authentication and Security Layer 393 (SASL)", RFC 2222, October 1997. 395 [SASL[2]] Melnikov, A., "Simple Authentication and Security 396 Layer (SASL)", draft-ietf-sasl-rfc2222bis (work in 397 progress), June 2004. 399 [SPNEGO] Baize, E. and D. Pinkas, "The Simple and Protected 400 GSS-API Negotiation Mechanism", RFC 2478, December 401 1998. 403 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 404 10646", RFC 2279, January 1998. 406 Informative References 408 [SPKM1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 409 RFC 2025, October 1996. 411 Author's Address 413 Alexey Melnikov (Ed.) 414 Isode Limited 415 5 Castle Business Village 416 36 Station Road 417 Hampton, Middlesex TW12 2BX 418 UK 420 EMail: Alexey.Melnikov@isode.com 421 URI: http://www.melnikov.ca/ 423 Full Copyright Statement 425 Copyright (C) The Internet Society (2004). This document is subject 426 to the rights, licenses and restrictions contained in BCP 78, and 427 except as set forth therein, the authors retain all their rights. 429 This document and translations of it may be copied and furnished to 430 others, and derivative works that comment on or otherwise explain it 431 or assist in its implementation may be prepared, copied, published 432 and distributed, in whole or in part, without restriction of any 433 kind, provided that the above copyright notice and this paragraph are 434 included on all such copies and derivative works. However, this 435 document itself may not be modified in any way, such as by removing 436 the copyright notice or references to the Internet Society or other 437 Internet organizations, except as needed for the purpose of 438 developing Internet standards in which case the procedures for 439 copyrights defined in the Internet Standards process must be 440 followed, or as required to translate it into languages other than 441 English. 443 The limited permissions granted above are perpetual and will not be 444 revoked by the Internet Society or its successors or assigns. 446 This document and the information contained herein are provided on an 447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 449 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 450 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 451 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 454 Acknowledgement 456 Funding for the RFC Editor function is currently provided by the 457 Internet Society.