idnits 2.17.1 draft-ietf-sasl-gssapi-07.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 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 402. ** 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 (August 25, 2006) is 6453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'THIS-DOC' is mentioned on line 275, but not defined -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: Informational August 25, 2006 5 Expires: February 26, 2007 7 The Kerberos V5 ("GSSAPI") SASL mechanism 8 draft-ietf-sasl-gssapi-07 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 February 26, 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 . . . . . 3 57 3.2. Server side of authentication protocol exchange . . . . . 5 58 3.3. Security layer . . . . . . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Conventions Used in this Document 70 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 71 in this document are to be interpreted as defined in "Key words for 72 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 74 2. Introduction 76 This specification documents currently deployed Simple Authentication 77 and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5 78 [KERBEROS] Generic Security Service Application Program Interface 79 ([GSS-API]) mechanism [RFC4121]. The authentication sequence is 80 described in Section 3. Note that the described authentication 81 sequence has known limitations in particular it lacks channel 82 bindings and the number of round trips required to complete 83 authentication exchange is not minimal. SASL WG is working on a 84 separate document that should address these limitations. 86 2.1. Relationship to Other Documents 88 This document, together with RFC 4422, obsoletes RFC 2222 in its 89 entirety. This document replaces Section 7.2 of RFC 2222. The 90 remainder is obsoleted as detailed in Section 1.2 of RFC 4422. 92 3. Kerberos V5 GSS-API mechanism 94 The SASL mechanism name for the Kerberos V5 GSS-API mechanism 95 [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism, 96 the mechanism is specifically tied to Kerberos V5 and GSS-API's 97 Kerberos V5 mechanism. 99 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism, 100 i.e. it starts with the client sending a "response" created as 101 described in the following section. 103 The implementation MAY set any GSS-API flags or arguments not 104 mentioned in this specification as is necessary for the 105 implementation to enforce its security policy. 107 3.1. Client side of authentication protocol exchange 109 The client calls GSS_Init_sec_context, passing in 110 input_context_handle of 0 (initially), mech_type of the Kerberos V5 111 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name 112 equal to output_name from GSS_Import_Name called with input_name_type 113 of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of 114 "service@hostname" where "service" is the service name specified in 115 the protocol's profile, and "hostname" is the fully qualified host 116 name of the server. When calling the GSS_Init_sec_context the client 117 MUST pass the integ_req_flag of TRUE. If the client will be 118 requesting a security layer, it MUST also supply to the 119 GSS_Init_sec_context a mutual_req_flag of TRUE, and a 120 sequence_req_flag of TRUE. If the client will be requesting a 121 security layer providing confidentiality protection, it MUST also 122 supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The 123 client then responds with the resulting output_token. If 124 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 125 should expect the server to issue a token in a subsequent challenge. 126 The client must pass the token to another call to 127 GSS_Init_sec_context, repeating the actions in this paragraph. 129 (*) - Clients MAY use name types other than 130 GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but 131 only when they have a priori knowledge that the servers support 132 alternate name types. Otherwise clients MUST use 133 GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names. 135 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 136 the context to ensure that it provides a level of protection 137 permitted by the client's security policy. If the context is 138 acceptable, the client takes the following actions: If the last call 139 to GSS_Init_sec_context returned an output_token, then the client 140 responds with the output_token, otherwise the client responds with no 141 data. The client should then expect the server to issue a token in a 142 subsequent challenge. The client passes this token to GSS_Unwrap and 143 interprets the first octet of resulting cleartext as a bit-mask 144 specifying the security layers supported by the server and the second 145 through fourth octets as the maximum size output_message the server 146 is able to receive (in network byte order). If the resulting 147 cleartext is not 4 octets long, the client fails the negotiation. 148 The client verifies that the server maximum buffer is 0 if the server 149 doesn't advertise support for any security layer. The client then 150 constructs data, with the first octet containing the bit-mask 151 specifying the selected security layer, the second through fourth 152 octets containing in network byte order the maximum size 153 output_message the client is able to receive (which MUST be 0 if the 154 client doesn't support any security layer), and the remaining octets 155 containing the UTF-8 [UTF8] encoded authorization identity. 156 (Implementation note: the authorization identity is not terminated 157 with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the 158 NUL (U+0000) character)). The client passes the data to GSS_Wrap 159 with conf_flag set to FALSE, and responds with the generated 160 output_message. The client can then consider the server 161 authenticated. 163 3.2. Server side of authentication protocol exchange 165 A server MUST NOT advertise support for the "GSSAPI" SASL mechanism 166 described in this document unless it has acceptor credential for the 167 Kerberos V GSS-API Mechanism [KRB5GSS]. 169 The server passes the initial client response to 170 GSS_Accept_sec_context as input_token, setting input_context_handle 171 to 0 (initially), chan_binding of NULL, and a suitable 172 acceptor_cred_handle (see below). If GSS_Accept_sec_context returns 173 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 174 to the client in challenge and passes the resulting response to 175 another call to GSS_Accept_sec_context, repeating the actions in this 176 paragraph. 178 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred 179 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the 180 Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use 181 GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY 182 use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred 183 for the server's principal name(s) (**) and the Kerberos V5 GSS-API 184 mechanism [KRB5GSS]. 186 (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of 187 GSS-API mechanism as an input parameter. The OID set can be created 188 by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can 189 be freed by calling the GSS_Release_oid_set. 191 (**) - Use of server's principal names having 192 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, 193 where "service" is the service name specified in the protocol's 194 profile, is RECOMMENDED. 196 Upon successful establishment of the security context (i.e. 197 GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD 198 verify that the negotiated GSS-API mechanism is indeed Kerberos V5 199 [KRB5GSS]. This is done by examining the value of the mech_type 200 parameter returned from the GSS_Accept_sec_context call. If the 201 value differ SASL authentication MUST be aborted. 203 Upon successful establishment of the security context and if the 204 server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor 205 credential handle, the server SHOULD also check using the 206 GSS_Inquire_context that the target_name used by the client matches 207 either: 209 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, 210 where "service" is the service name specified in the application 211 protocol's profile, 213 or that 215 - the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two- 216 component principal where the first component matches the service 217 name specified in the application protocol's profile. 219 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 220 examines the context to ensure that it provides a level of protection 221 permitted by the server's security policy. If the context is 222 acceptable, the server takes the following actions: If the last call 223 to GSS_Accept_sec_context returned an output_token, the server 224 returns it to the client in a challenge and expects a reply from the 225 client with no data. Whether or not an output_token was returned 226 (and after receipt of any response from the client to such an 227 output_token), the server then constructs 4 octets of data, with the 228 first octet containing a bit-mask specifying the security layers 229 supported by the server and the second through fourth octets 230 containing in network byte order the maximum size output_token the 231 server is able to receive (which MUST be 0 if the server doesn't 232 support any security layer). The server must then pass the plaintext 233 to GSS_Wrap with conf_flag set to FALSE and issue the generated 234 output_message to the client in a challenge. The server must then 235 pass the resulting response to GSS_Unwrap and interpret the first 236 octet of resulting cleartext as the bit-mask for the selected 237 security layer, the second through fourth octets as the maximum size 238 output_message the client is able to receive (in network byte order), 239 and the remaining octets as the authorization identity. The server 240 verifies that the client has selected a security layer that was 241 offered, and that the client maximum buffer is 0 if no security layer 242 was chosen. The server must verify that the src_name is authorized 243 to act as the authorization identity. After these verifications, the 244 authentication process is complete. The server is not expected to 245 return any additional data with the success indicator. 247 3.3. Security layer 249 The security layers and their corresponding bit-masks are as follows: 251 1 No security layer 252 2 Integrity protection. 253 Sender calls GSS_Wrap with conf_flag set to FALSE 254 4 Confidentiality protection. 255 Sender calls GSS_Wrap with conf_flag set to TRUE 257 Other bit-masks may be defined in the future; bits which are not 258 understood must be negotiated off. 260 Note that SASL negotiates the maximum size of the output_message to 261 send. Implementations can use the GSS_Wrap_size_limit call to 262 determine the corresponding maximum size input_message. 264 4. IANA Considerations 266 The IANA is directed to modify the existing registration for "GSSAPI" 267 as follows: 269 Family of SASL mechanisms: NO 271 SASL mechanism name: GSSAPI 273 Security considerations: See Section 5 of RFC [THIS-DOC] 275 Published Specification: RFC [THIS-DOC] 277 Person & email address to contact for further information: Alexey 278 Melnikov 280 Intended usage: COMMON 282 Owner/Change controller: iesg@ietf.org 284 Additional Information: This mechanism is for the Kerberos V5 285 mechanism of GSS-API. 287 5. Security Considerations 289 Security issues are discussed throughout this memo. 291 When constructing the input_name_string, the client SHOULD NOT 292 canonicalize the server's fully qualified domain name using an 293 insecure or untrusted directory service. 295 For compatibility with deployed software this document requires that 296 the chan_binding (channel bindings) parameter to GSS_Init_sec_context 297 and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API 298 support for channel bindings. GSS-API channel bindings in SASL is 299 expected to be supported via a new GSS-API family of SASL mechanisms 300 (to be introduced in a future document). 302 Additional security considerations are in the [SASL] and [GSS-API] 303 specifications. Additional security considerations for the GSS-API 304 mechanism can be found in [KRB5GSS] and [KERBEROS]. 306 6. Acknowledgements 308 This document replaces section 7.2 of RFC 2222 [RFC2222] by John G. 309 Myers. He also contributed significantly to this revision. 311 Lawrence Greenfield converted text of this draft to the XML format. 313 Contributions of many members of the SASL mailing list are gratefully 314 acknowledged, in particular comments from Chris Newman, Nicolas 315 Williams and Jeffrey Hutzelman. 317 7. References 319 7.1. Normative References 321 [GSS-API] Linn, J., "Generic Security Service Application Program 322 Interface Version 2, Update 1", RFC 2743, January 2000. 324 [KERBEROS] 325 Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 326 Kerberos Network Authentication Service (V5)", RFC 4120, 327 July 2005. 329 [KEYWORDS] 330 Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 334 RFC 1964, June 1996. 336 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 337 Version 5 Generic Security Service Application Program 338 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 339 July 2005. 341 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 342 Security Layer (SASL)", RFC 4422, June 2006. 344 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 345 10646", RFC 3629, November 2003. 347 7.2. Informative References 349 [RFC2222] Myers, J., "Simple Authentication and Security Layer 350 (SASL)", RFC 2222, October 1997. 352 Author's Address 354 Alexey Melnikov (editor) 355 Isode Limited 356 5 Castle Business Village 357 36 Station Road 358 Hampton, Middlesex TW12 2BX 359 UK 361 Email: Alexey.Melnikov@isode.com 362 URI: http://www.melnikov.ca/ 364 Full Copyright Statement 366 Copyright (C) The Internet Society (2006). 368 This document is subject to the rights, licenses and restrictions 369 contained in BCP 78, and except as set forth therein, the authors 370 retain all their rights. 372 This document and the information contained herein are provided on an 373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 375 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 376 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 377 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 380 Intellectual Property 382 The IETF takes no position regarding the validity or scope of any 383 Intellectual Property Rights or other rights that might be claimed to 384 pertain to the implementation or use of the technology described in 385 this document or the extent to which any license under such rights 386 might or might not be available; nor does it represent that it has 387 made any independent effort to identify any such rights. Information 388 on the procedures with respect to rights in RFC documents can be 389 found in BCP 78 and BCP 79. 391 Copies of IPR disclosures made to the IETF Secretariat and any 392 assurances of licenses to be made available, or the result of an 393 attempt made to obtain a general license or permission for the use of 394 such proprietary rights by implementers or users of this 395 specification can be obtained from the IETF on-line IPR repository at 396 http://www.ietf.org/ipr. 398 The IETF invites any interested party to bring to its attention any 399 copyrights, patents or patent applications, or other proprietary 400 rights that may cover technology that may be required to implement 401 this standard. Please address the information to the IETF at 402 ietf-ipr@ietf.org. 404 Acknowledgment 406 Funding for the RFC Editor function is provided by the IETF 407 Administrative Support Activity (IASA).