idnits 2.17.1 draft-ietf-sasl-gssapi-02.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.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (March 29, 2005) is 6968 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 297, 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: 11 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: September 27, 2005 March 29, 2005 5 SASL GSSAPI mechanisms 6 draft-ietf-sasl-gssapi-02 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 27, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 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 Table of Contents 52 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 53 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 54 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Specification common to all GSSAPI mechanisms . . . . . . . . 6 57 4.1 Client side of authentication protocol exchange . . . . . 6 58 4.2 Server side of authentication protocol exchange . . . . . 7 59 4.3 Security layer . . . . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 65 8.2 Informative References . . . . . . . . . . . . . . . . . . . 12 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . 14 69 1. Conventions Used in this Document 71 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 72 in this document are to be interpreted as defined in "Key words for 73 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 75 2. Introduction and Overview 77 Each and every GSSAPI mechanism used within SASL is implicitly 78 registered by this specification. 80 For backwards compatibility with existing implementations of Kerberos 81 V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5 82 GSSAPI mechanism [KRB5GSS] is "GSSAPI" and the SASL mechanism for the 83 SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL mechanism 84 name for any other GSSAPI mechanism is the concatenation of "GSS-" 85 and the Base32 [BASE-ENCODING] encoding of the first ten bytes of the 86 MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI 87 mechanism's OID. The Base32 rules on padding characters and 88 characters outside of the base32 alphabet are not relevant to this 89 use of Base32. 91 SASL mechanism names starting with "GSS-" are reserved for SASL 92 mechanisms which conform to this document. 94 The specification of all SASL mechanisms conforming to this document 95 is in the "Specification common to all GSSAPI mechanisms" section of 96 this document. 98 The IESG is considered to be the owner of all SASL mechanisms which 99 conform to this document. This does NOT necessarily imply that the 100 IESG is considered to be the owner of the underlying GSSAPI 101 mechanism. 103 2.1 Example 105 The OID for the SPKM-1 mechanism [SPKM1] is 1.3.6.1.5.5.1. The ASN.1 106 DER encoding of this OID is 06 06 2b 06 01 05 05 01. The MD5 hash of 107 the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46 108 8a 30. The Base32 encoding of the first ten bytes of this is 109 "K7XIDASOVRG3BZSQ". Thus the SASL mechanism name for the SPKM-1 110 GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ". 112 3. SPNEGO 114 Use of the Simple and Protected GSS-API Negotiation Mechanism 115 [SPNEGO] underneath SASL introduces subtle interoperability problems 116 and security considerations. To address these, this section places 117 additional requirements on implementations which support SPNEGO 118 underneath SASL. 120 A client which supports, for example, the Kerberos V5 GSSAPI 121 mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL 122 mechanism will not interoperate with a server which supports the 123 Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL 124 mechanism. 126 Since SASL is capable of negotiating amongst GSSAPI mechanisms, the 127 only reason for a server or client to support the "GSS-SPNEGO" 128 mechanism is to allow a policy of only using mechanisms below a 129 certain strength if those mechanism's negotiation is protected. In 130 such a case, a client or server would only want to negotiate those 131 weaker mechanisms through SPNEGO. In any case, there is no down- 132 negotiation security consideration with using the strongest mechanism 133 and set of options the implementation supports, so for 134 interoperability that mechanism and set of options MUST be negotiable 135 without using the "GSS-SPNEGO" mechanism. 137 If a client's policy is to first prefer GSSAPI mechanism X, then 138 non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server 139 supports mechanisms Y and Z but not X, then if the client attempts to 140 negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it 141 may end up using mechanism Z when it should have used mechanism Y. 142 For this reason, implementations MUST exclude from SPNEGO those 143 GSSAPI mechanisms which are weaker than the strongest non-GSSAPI SASL 144 mechanism advertised by the server. 146 4. Specification common to all GSSAPI mechanisms 148 Each SASL mechanism which uses a GSSAPI mechanism uses the following 149 specification. 151 The implementation MAY set any GSSAPI flags or arguments not 152 mentioned in this specification as is necessary for the 153 implementation to enforce its security policy. 155 4.1 Client side of authentication protocol exchange 157 The client calls GSS_Init_sec_context, passing in 158 input_context_handle of 0 (initially), mech_type of the GSSAPI 159 mechanism for which this SASL mechanism is registered, chan_binding 160 of NULL, and targ_name equal to output_name from GSS_Import_Name 161 called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and 162 input_name_string of "service@hostname" where "service" is the 163 service name specified in the protocol's profile, and "hostname" is 164 the fully qualified host name of the server. If the client will be 165 requesting a security layer, it MUST also supply to the 166 GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag 167 of TRUE, and an integ_req_flag of TRUE. If the client will be 168 requesting a security layer providing confidentiality protection, it 169 MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. 170 The client then responds with the resulting output_token. If 171 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 172 should expect the server to issue a token in a subsequent challenge. 173 The client must pass the token to another call to 174 GSS_Init_sec_context, repeating the actions in this paragraph. 176 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 177 the context to ensure that it provides a level of protection 178 permitted by the client's security policy. If the context is 179 acceptable, the client takes the following actions: If the last call 180 to GSS_Init_sec_context returned an output_token, then the client 181 responds with the output_token, otherwise the client responds with no 182 data. The client should then expect the server to issue a token in a 183 subsequent challenge. The client passes this token to GSS_Unwrap and 184 interprets the first octet of resulting cleartext as a bit-mask 185 specifying the security layers supported by the server and the second 186 through fourth octets as the network byte order maximum size 187 output_message to send to the server (if the resulting cleartext is 188 not 4 octets long, the client fails the negotiation). The client 189 verifies that the server maximum buffer is 0 if the server doesn't 190 advertise support for any security layer. The client then constructs 191 data, with the first octet containing the bit-mask specifying the 192 selected security layer, the second through fourth octets containing 193 in network byte order the maximum size output_message the client is 194 able to receive, and the remaining octets containing the UTF-8 [UTF8] 195 encoded authorization identity. (Implementation note: the 196 authorization identity is not terminated with the NUL (%x00) 197 character). The client passes the data to GSS_Wrap with conf_flag 198 set to FALSE, and responds with the generated output_message. The 199 client can then consider the server authenticated. 201 4.2 Server side of authentication protocol exchange 203 The server passes the initial client response to 204 GSS_Accept_sec_context as input_token, setting input_context_handle 205 to 0 (initially), mech_type of the GSSAPI mechanism for which this 206 SASL mechanism is registered, chan_binding of NULL, and 207 acceptor_cred_handle equal to output_cred_handle from 208 GSS_Acquire_cred called with desired_name equal to output_name from 209 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE 210 and input_name_string of "service@hostname" where "service" is the 211 service name specified in the protocol's profile, and "hostname" is 212 the fully qualified host name of the server. If 213 GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server 214 returns the generated output_token to the client in challenge and 215 passes the resulting response to another call to 216 GSS_Accept_sec_context, repeating the actions in this paragraph. 218 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 219 examines the context to ensure that it provides a level of protection 220 permitted by the server's security policy. If the context is 221 acceptable, the server takes the following actions: If the last call 222 to GSS_Accept_sec_context returned an output_token, the server 223 returns it to the client in a challenge and expects a reply from the 224 client with no data. Whether or not an output_token was returned 225 (and after receipt of any response from the client to such an 226 output_token), the server then constructs 4 octets of data, with the 227 first octet containing a bit-mask specifying the security layers 228 supported by the server and the second through fourth octets 229 containing in network byte order the maximum size output_token the 230 server is able to receive (which MUST be 0 if the server doesn't 231 support any security layer). The server must then pass the plaintext 232 to GSS_Wrap with conf_flag set to FALSE and issue the generated 233 output_message to the client in a challenge. The server must then 234 pass the resulting response to GSS_Unwrap and interpret the first 235 octet of resulting cleartext as the bit-mask for the selected 236 security layer, the second through fourth octets as the network byte 237 order maximum size output_message to send to the client, and the 238 remaining octets as the authorization identity. The server verifies 239 that the client has selected a security layer that was offered, and 240 that the client maximum buffer is 0 if no security layer was chosen. 241 The server must verify that the src_name is authorized to 242 authenticate as the authorization identity. After these 243 verifications, the authentication process is complete. 245 4.3 Security layer 247 The security layers and their corresponding bit-masks are as follows: 249 1 No security layer 250 2 Integrity protection. 251 Sender calls GSS_Wrap with conf_flag set to FALSE 252 4 Confidentiality protection. 253 Sender calls GSS_Wrap with conf_flag set to TRUE 255 Other bit-masks may be defined in the future; bits which are not 256 understood must be negotiated off. 258 Note that SASL negotiates the maximum size of the output_message to 259 send. Implementations can use the GSS_Wrap_size_limit call to 260 determine the corresponding maximum size input_message. 262 5. IANA Considerations 264 The IANA is advised that SASL mechanism names starting with "GSS-" 265 are reserved for SASL mechanisms which conform to this document. The 266 IANA is directed to place a statement to that effect in the 267 sasl-mechanisms registry. 268 Family of SASL mechanisms: YES 269 Prefix: GSS- 270 Security considerations: RFC [THIS-DOC] 271 Published Specification: RFC [THIS-DOC] 272 Person & email address to contact for further information: Alexey 273 Melnikov 274 Intended usage: COMMON 275 Owner/Change controller: iesg@ietf.org 277 The IANA is directed to modify the existing registration for "GSSAPI" 278 as follows: 279 Family of SASL mechanisms: NO 280 SASL mechanism name: GSSAPI 281 Security considerations: ? 282 Published Specification: RFC [THIS-DOC] 283 Person & email address to contact for further information: Alexey 284 Melnikov 285 Intended usage: COMMON 286 Owner/Change controller: iesg@ietf.org 287 Additional Information: This mechanism is for the Kerberos V5 288 mechanism of GSSAPI. Other GSSAPI mechanisms use other SASL 289 mechanism names, as described in this mechanism's published 290 specification. 292 The IANA is directed to modify the existing registration for 293 "GSS-SPNEGO" as follows: 294 Family of SASL mechanisms: NO 295 SASL mechanism name: GSS-SPNEGO 296 Security considerations: See the "SPNEGO" section of RFC [THIS-DOC]. 297 Published Specification: RFC [THIS-DOC] 298 Person & email address to contact for further information: Alexey 299 Melnikov 300 Intended usage: LIMITED USE 301 Owner/Change controller: iesg@ietf.org 303 6. Security Considerations 305 Security issues are discussed throughout this memo. 307 When a server or client supports multiple authentication mechanisms, 308 each of which has a different security strength, it is possible for 309 an active attacker to cause a party to use the least secure mechanism 310 supported. To protect against this sort of attack, a client or 311 server which supports mechanisms of different strengths should have a 312 configurable minimum strength that it will use. It is not sufficient 313 for this minimum strength check to only be on the server, since an 314 active attacker can change which mechanisms the client sees as being 315 supported, causing the client to send authentication credentials for 316 its weakest supported mechanism. 318 The client's selection of a SASL mechanism is done in the clear and 319 may be modified by an active attacker. It is important for any new 320 SASL mechanisms to be designed such that an active attacker cannot 321 obtain an authentication with weaker security properties by modifying 322 the SASL mechanism name and/or the challenges and responses. 324 [SPNEGO] has protection against many of these down-negotiation 325 attacks, SASL does not itself have such protection. The section 326 titled "SPNEGO" mentions considerations of choosing negotiation 327 through SASL versus SPNEGO. 329 The integrity protection provided by the security layer is useless to 330 the client unless the client also requests mutual authentication. 331 Therefore, a client wishing to benefit from the integrity protection 332 of a security layer MUST pass to the GSS_Init_sec_context call a 333 mutual_req_flag of TRUE. 335 When constructing the input_name_string, the client should not 336 canonicalize the server's fully qualified domain name using an 337 insecure or untrusted directory service. 339 Additional security considerations are in the [SASL] and [GSSAPI] 340 specifications. Additional security considerations for the GSSAPI 341 mechanism can be found in [KRB5GSS]. 343 7. Acknowledgements 345 This document is a revision of RFC 2222 written by John G. Myers. 346 He also contributed significantly to this revision. 348 Thank you to Lawrence Greenfield for converting text of this draft to 349 XML format. 351 Contributions of many members of the SASL mailing list are gratefully 352 acknowledged. 354 8. References 356 8.1 Normative References 358 [ASN1] International Organization for Standardization, 359 "Information Processing Systems - Open Systems 360 Interconnection - Specification of Abstract Syntax 361 Notation One (ASN.1)", ISO Standard 8824, December 1990. 363 [BASE-ENCODING] 364 Josefsson, S., "The Base16, Base32, and Base64 Data 365 Encodings", RFC 3548, July 2003. 367 [GSSAPI] Linn, J., "Generic Security Service Application Program 368 Interface Version 2, Update 1", RFC 2743, January 2000. 370 [KEYWORDS] 371 Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 375 1964, June 1996. 377 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 378 April 1992. 380 [SASL] Myers, J., "Simple Authentication and Security Layer 381 (SASL)", RFC 2222, October 1997. 383 [SASL[2]] Melnikov, A., "Simple Authentication and Security Layer 384 (SASL)", draft-ietf-sasl-rfc2222bis (work in progress), 385 June 2004. 387 [SPNEGO] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 388 Negotiation Mechanism", RFC 2478, December 1998. 390 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 391 10646", RFC 2279, January 1998. 393 8.2 Informative References 395 [SPKM1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 396 RFC 2025, October 1996. 398 Author's Address 400 Alexey Melnikov (Ed.) 401 Isode Limited 402 5 Castle Business Village 403 36 Station Road 404 Hampton, Middlesex TW12 2BX 405 UK 407 EMail: Alexey.Melnikov@isode.com 408 URI: http://www.melnikov.ca/ 410 Intellectual Property Statement 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org. 434 Disclaimer of Validity 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 439 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 440 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 441 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 Copyright Statement 446 Copyright (C) The Internet Society (2005). This document is subject 447 to the rights, licenses and restrictions contained in BCP 78, and 448 except as set forth therein, the authors retain all their rights. 450 Acknowledgment 452 Funding for the RFC Editor function is currently provided by the 453 Internet Society.