idnits 2.17.1 draft-ietf-sasl-gssapi-08.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 1, 2006) is 6446 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 300, but not defined -- Obsolete informational reference (is this intentional?): RFC 2078 (Obsoleted by RFC 2743) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SASL A. Melnikov, Ed. 3 Internet-Draft Isode 4 Intended status: Standards Track September 1, 2006 5 Expires: March 5, 2007 7 The Kerberos V5 ("GSSAPI") SASL mechanism 8 draft-ietf-sasl-gssapi-08 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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 March 5, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The Simple Authentication and Security Layer (SASL, RFC 4422) is a 42 framework for adding authentication support to connection-based 43 protocols. This document describes the method for using the Generic 44 Security Service Application Program Interface (GSS-API) Kerberos V5 45 in the SASL. 47 This document replaces section 7.2 of RFC 2222, the definition of the 48 "GSSAPI" SASL mechanism. 50 Table of Contents 52 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Relationship to Other Documents . . . . . . . . . . . . . 3 55 3. Kerberos V5 GSS-API mechanism . . . . . . . . . . . . . . . . 3 56 3.1. Client side of authentication protocol exchange . . . . . 4 57 3.2. Server side of authentication protocol exchange . . . . . 5 58 3.3. Security layer . . . . . . . . . . . . . . . . . . . . . . 7 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Changes since RFC 2222 . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 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 77 This specification documents currently deployed Simple Authentication 78 and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5 79 [KERBEROS] Generic Security Service Application Program Interface 80 ([GSS-API]) mechanism [RFC4121]. The authentication sequence is 81 described in Section 3. Note that the described authentication 82 sequence has known limitations in particular it lacks channel 83 bindings and the number of round trips required to complete 84 authentication exchange is not minimal. SASL WG is working on a 85 separate document that should address these limitations. 87 2.1. Relationship to Other Documents 89 This document, together with RFC 4422, obsoletes RFC 2222 in its 90 entirety. This document replaces Section 7.2 of RFC 2222. The 91 remainder is obsoleted as detailed in Section 1.2 of RFC 4422. 93 3. Kerberos V5 GSS-API mechanism 95 The SASL mechanism name for the Kerberos V5 GSS-API mechanism 96 [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism, 97 the mechanism is specifically tied to Kerberos V5 and GSS-API's 98 Kerberos V5 mechanism. 100 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism, 101 i.e. it starts with the client sending a "response" created as 102 described in the following section. 104 The implementation MAY set any GSS-API flags or arguments not 105 mentioned in this specification as is necessary for the 106 implementation to enforce its security policy. 108 Note that if during a SASL authentication exchange any GSS-API call 109 returns major_status other than GSS_S_COMPLETE (or 110 GSS_S_CONTINUE_NEEDED for GSS_Init_sec_context/ 111 GSS_Accept_sec_context) then the SASL authentication exchange MUST be 112 considered unsuccessful. 114 3.1. Client side of authentication protocol exchange 116 The client calls GSS_Init_sec_context, passing in 117 input_context_handle of 0 (initially), mech_type of the Kerberos V5 118 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name 119 equal to output_name from GSS_Import_Name called with input_name_type 120 of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of 121 "service@hostname" where "service" is the service name specified in 122 the protocol's profile, and "hostname" is the fully qualified host 123 name of the server. When calling the GSS_Init_sec_context the client 124 MUST pass the integ_req_flag of TRUE (**). If the client will be 125 requesting a security layer, it MUST also supply to the 126 GSS_Init_sec_context a mutual_req_flag of TRUE, and a 127 sequence_req_flag of TRUE. If the client will be requesting a 128 security layer providing confidentiality protection, it MUST also 129 supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The 130 client then responds with the resulting output_token. If 131 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 132 should expect the server to issue a token in a subsequent challenge. 133 The client must pass the token to another call to 134 GSS_Init_sec_context, repeating the actions in this paragraph. 136 (*) - Clients MAY use name types other than 137 GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but 138 only when they have a priori knowledge that the servers support 139 alternate name types. Otherwise clients MUST use 140 GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names. 142 (**) - Note that RFC 2222 [RFC2222] implementations will not work 143 with GSS-API implementations that require integ_req_flag to be true. 144 No implementations of RFC 1964 [KRB5GSS] or RFC 4121 [RFC4121] that 145 require integ_req_flag to be true are believed to exist and it is 146 expected that any future update to [RFC4121] will require that 147 integrity be available even in not explicitly requested by the 148 application. 150 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 151 the context to ensure that it provides a level of protection 152 permitted by the client's security policy. In particular, if the 153 integ_avail flag is not set in the context, then no security layer 154 can be offered or accepted. If the conf_avail flag is not set in the 155 context, then no security layer with confidentiality can be offered 156 or accepted. If the context is acceptable, the client takes the 157 following actions: If the last call to GSS_Init_sec_context returned 158 an output_token, then the client responds with the output_token, 159 otherwise the client responds with no data. The client should then 160 expect the server to issue a token in a subsequent challenge. The 161 client passes this token to GSS_Unwrap and interprets the first octet 162 of resulting cleartext as a bit-mask specifying the security layers 163 supported by the server and the second through fourth octets as the 164 maximum size output_message the server is able to receive (in network 165 byte order). If the resulting cleartext is not 4 octets long, the 166 client fails the negotiation. The client verifies that the server 167 maximum buffer is 0 if the server doesn't advertise support for any 168 security layer. The client then constructs data, with the first 169 octet containing the bit-mask specifying the selected security layer, 170 the second through fourth octets containing in network byte order the 171 maximum size output_message the client is able to receive (which MUST 172 be 0 if the client doesn't support any security layer), and the 173 remaining octets containing the UTF-8 [UTF8] encoded authorization 174 identity. (Implementation note: the authorization identity is not 175 terminated with the zero-valued (%x00) octet (e.g., the UTF-8 176 encoding of the NUL (U+0000) character)). The client passes the data 177 to GSS_Wrap with conf_flag set to FALSE, and responds with the 178 generated output_message. The client can then consider the server 179 authenticated. 181 3.2. Server side of authentication protocol exchange 183 A server MUST NOT advertise support for the "GSSAPI" SASL mechanism 184 described in this document unless it has acceptor credential for the 185 Kerberos V GSS-API Mechanism [KRB5GSS]. 187 The server passes the initial client response to 188 GSS_Accept_sec_context as input_token, setting input_context_handle 189 to 0 (initially), chan_binding of NULL, and a suitable 190 acceptor_cred_handle (see below). If GSS_Accept_sec_context returns 191 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 192 to the client in challenge and passes the resulting response to 193 another call to GSS_Accept_sec_context, repeating the actions in this 194 paragraph. 196 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred 197 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the 198 Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use 199 GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY 200 use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred 201 for the server's principal name(s) (**) and the Kerberos V5 GSS-API 202 mechanism [KRB5GSS]. 204 (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of 205 GSS-API mechanism as an input parameter. The OID set can be created 206 by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can 207 be freed by calling the GSS_Release_oid_set. 209 (**) - Use of server's principal names having 210 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, 211 where "service" is the service name specified in the protocol's 212 profile, is RECOMMENDED. 214 Upon successful establishment of the security context (i.e. 215 GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD 216 verify that the negotiated GSS-API mechanism is indeed Kerberos V5 217 [KRB5GSS]. This is done by examining the value of the mech_type 218 parameter returned from the GSS_Accept_sec_context call. If the 219 value differ SASL authentication MUST be aborted. 221 Upon successful establishment of the security context and if the 222 server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor 223 credential handle, the server SHOULD also check using the 224 GSS_Inquire_context that the target_name used by the client matches 225 either: 227 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, 228 where "service" is the service name specified in the application 229 protocol's profile, 231 or that 233 - the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two- 234 component principal where the first component matches the service 235 name specified in the application protocol's profile. 237 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 238 examines the context to ensure that it provides a level of protection 239 permitted by the server's security policy. In particular, if the 240 integ_avail flag is not set in the context, then no security layer 241 can be offered or accepted. If the conf_avail flag is not set in the 242 context, then no security layer with confidentiality can be offered 243 or accepted. If the context is acceptable, the server takes the 244 following actions: If the last call to GSS_Accept_sec_context 245 returned an output_token, the server returns it to the client in a 246 challenge and expects a reply from the client with no data. Whether 247 or not an output_token was returned (and after receipt of any 248 response from the client to such an output_token), the server then 249 constructs 4 octets of data, with the first octet containing a bit- 250 mask specifying the security layers supported by the server and the 251 second through fourth octets containing in network byte order the 252 maximum size output_token the server is able to receive (which MUST 253 be 0 if the server doesn't support any security layer). The server 254 must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE 255 and issue the generated output_message to the client in a challenge. 256 The server must then pass the resulting response to GSS_Unwrap and 257 interpret the first octet of resulting cleartext as the bit-mask for 258 the selected security layer, the second through fourth octets as the 259 maximum size output_message the client is able to receive (in network 260 byte order), and the remaining octets as the authorization identity. 261 The server verifies that the client has selected a security layer 262 that was offered, and that the client maximum buffer is 0 if no 263 security layer was chosen. The server must verify that the src_name 264 is authorized to act as the authorization identity. After these 265 verifications, the authentication process is complete. The server is 266 not expected to return any additional data with the success 267 indicator. 269 3.3. Security layer 271 The security layers and their corresponding bit-masks are as follows: 273 1 No security layer 274 2 Integrity protection. 275 Sender calls GSS_Wrap with conf_flag set to FALSE 276 4 Confidentiality protection. 277 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 When decoding any received data with GSS_Unwrap the major_status 283 other than the GSS_S_COMPLETE MUST be treated as a fatal error. 285 Note that SASL negotiates the maximum size of the output_message to 286 send. Implementations can use the GSS_Wrap_size_limit call to 287 determine the corresponding maximum size input_message. 289 4. IANA Considerations 291 The IANA is directed to modify the existing registration for "GSSAPI" 292 as follows: 294 Family of SASL mechanisms: NO 296 SASL mechanism name: GSSAPI 298 Security considerations: See Section 5 of RFC [THIS-DOC] 300 Published Specification: RFC [THIS-DOC] 301 Person & email address to contact for further information: Alexey 302 Melnikov 304 Intended usage: COMMON 306 Owner/Change controller: iesg@ietf.org 308 Additional Information: This mechanism is for the Kerberos V5 309 mechanism of GSS-API. 311 5. Security Considerations 313 Security issues are discussed throughout this memo. 315 When constructing the input_name_string, the client SHOULD NOT 316 canonicalize the server's fully qualified domain name using an 317 insecure or untrusted directory service. 319 For compatibility with deployed software this document requires that 320 the chan_binding (channel bindings) parameter to GSS_Init_sec_context 321 and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API 322 support for channel bindings. GSS-API channel bindings in SASL is 323 expected to be supported via a new GSS-API family of SASL mechanisms 324 (to be introduced in a future document). 326 Additional security considerations are in the [SASL] and [GSS-API] 327 specifications. Additional security considerations for the GSS-API 328 mechanism can be found in [KRB5GSS] and [KERBEROS]. 330 6. Acknowledgements 332 This document replaces section 7.2 of RFC 2222 [RFC2222] by John G. 333 Myers. He also contributed significantly to this revision. 335 Lawrence Greenfield converted text of this draft to the XML format. 337 Contributions of many members of the SASL mailing list are gratefully 338 acknowledged, in particular comments from Chris Newman, Nicolas 339 Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin and Martin 340 Rex. 342 7. Changes since RFC 2222 344 RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222 345 [RFC2222], which provided the original version of this specification. 347 That version of GSS-API did not provide the integ_integ_avail flag as 348 an input to GSS_Init_sec_context. Instead, integrity was always 349 requested. RFC 4422 [SASL] requires that when possible, the security 350 layer negotiation be integrity protected. To meet this requirement 351 and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API], 352 this specification requires that clients request integrity from 353 GSS_Init_sec_context so they can use GSS_Wrap to protect the security 354 layer negotiation. This specification does not require that the 355 mechanism offer the integrity security layer, simply that the 356 security layer negotiation be wrapped. 358 8. References 360 8.1. Normative References 362 [GSS-API] Linn, J., "Generic Security Service Application Program 363 Interface Version 2, Update 1", RFC 2743, January 2000. 365 [KERBEROS] 366 Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 367 Kerberos Network Authentication Service (V5)", RFC 4120, 368 July 2005. 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", 375 RFC 1964, June 1996. 377 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 378 Version 5 Generic Security Service Application Program 379 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 380 July 2005. 382 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 383 Security Layer (SASL)", RFC 4422, June 2006. 385 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 386 10646", RFC 3629, November 2003. 388 8.2. Informative References 390 [RFC2078] Linn, J., "Generic Security Service Application Program 391 Interface, Version 2", RFC 2078, January 1997. 393 [RFC2222] Myers, J., "Simple Authentication and Security Layer 394 (SASL)", RFC 2222, October 1997. 396 Author's Address 398 Alexey Melnikov (editor) 399 Isode Limited 400 5 Castle Business Village 401 36 Station Road 402 Hampton, Middlesex TW12 2BX 403 UK 405 Email: Alexey.Melnikov@isode.com 406 URI: http://www.melnikov.ca/ 408 Full Copyright Statement 410 Copyright (C) The Internet Society (2006). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 419 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 420 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 421 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; nor does it represent that it has 431 made any independent effort to identify any such rights. Information 432 on the procedures with respect to rights in RFC documents can be 433 found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use of 438 such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository at 440 http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights that may cover technology that may be required to implement 445 this standard. Please address the information to the IETF at 446 ietf-ipr@ietf.org. 448 Acknowledgment 450 Funding for the RFC Editor function is provided by the IETF 451 Administrative Support Activity (IASA).