idnits 2.17.1 draft-ietf-sasl-gssapi-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (May 30, 2006) is 6534 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 251, but not defined ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SASL A. Melnikov 3 Internet-Draft Isode 4 Expires: December 1, 2006 May 30, 2006 6 The Kerberos V5 ("GSSAPI") SASL mechanism 7 draft-ietf-sasl-gssapi-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 1, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Simple Authentication and Security Layer (SASL, RFC XXXX) is a 41 framework for adding authentication support to connection-based 42 protocols. This document describes the method for using the Generic 43 Security Service Application Program Interface (GSS-API) KERBEROS V5 44 in the Simple Authentication and Security Layer. 46 This document replaces section 7.2 of RFC 2222, the definition of the 47 "GSSAPI" SASL mechanism. 49 Table of Contents 51 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 52 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 53 3. Kerberos V5 GSS-API mechanism . . . . . . . . . . . . . . . . 3 54 3.1. Client side of authentication protocol exchange . . . . . 3 55 3.2. Server side of authentication protocol exchange . . . . . 4 56 3.3. Security layer . . . . . . . . . . . . . . . . . . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Intellectual Property and Copyright Statements . . . . . . . . . . 10 66 1. Conventions Used in this Document 68 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 69 in this document are to be interpreted as defined in "Key words for 70 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 72 2. Introduction and Overview 74 This specification documents currently deployed Kerberos V5 GSS-API 75 mechanism used within SASL framework [SASL]. The authentication 76 sequence is described in Section 3. Note that the described 77 authentication sequence has known limitations in particular it lacks 78 channel bindings and the number of round trips required to complete 79 authentication exchange is not minimal. SASL WG is working on a 80 separate document that should address these limitations. 82 The SASL mechanism name for the Kerberos V5 GSS-API mechanism 83 [RFC4121] is "GSSAPI". 85 3. Kerberos V5 GSS-API mechanism 87 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism, 88 i.e. it starts with the client sending a "response" created as 89 described in the following section. 91 The implementation MAY set any GSS-API flags or arguments not 92 mentioned in this specification as is necessary for the 93 implementation to enforce its security policy. 95 3.1. Client side of authentication protocol exchange 97 The client calls GSS_Init_sec_context, passing in 98 input_context_handle of 0 (initially), mech_type of the Kerberos V5 99 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name 100 equal to output_name from GSS_Import_Name called with input_name_type 101 of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 102 "service@hostname" where "service" is the service name specified in 103 the protocol's profile, and "hostname" is the fully qualified host 104 name of the server. If the client will be requesting a security 105 layer, it MUST also supply to the GSS_Init_sec_context a 106 mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an 107 integ_req_flag of TRUE. If the client will be requesting a security 108 layer providing confidentiality protection, it MUST also supply to 109 the GSS_Init_sec_context a conf_req_flag of TRUE. The client then 110 responds with the resulting output_token. If GSS_Init_sec_context 111 returns GSS_S_CONTINUE_NEEDED, then the client should expect the 112 server to issue a token in a subsequent challenge. The client must 113 pass the token to another call to GSS_Init_sec_context, repeating the 114 actions in this paragraph. 116 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 117 the context to ensure that it provides a level of protection 118 permitted by the client's security policy. If the context is 119 acceptable, the client takes the following actions: If the last call 120 to GSS_Init_sec_context returned an output_token, then the client 121 responds with the output_token, otherwise the client responds with no 122 data. The client should then expect the server to issue a token in a 123 subsequent challenge. The client passes this token to GSS_Unwrap and 124 interprets the first octet of resulting cleartext as a bit-mask 125 specifying the security layers supported by the server and the second 126 through fourth octets as the maximum size output_message the server 127 is able to receive (in network byte order). If the resulting 128 cleartext is not 4 octets long, the client fails the negotiation. 129 The client verifies that the server maximum buffer is 0 if the server 130 doesn't advertise support for any security layer. The client then 131 constructs data, with the first octet containing the bit-mask 132 specifying the selected security layer, the second through fourth 133 octets containing in network byte order the maximum size 134 output_message the client is able to receive (which MUST be 0 if the 135 client doesn't support any security layer), and the remaining octets 136 containing the UTF-8 [UTF8] encoded authorization identity. 137 (Implementation note: the authorization identity is not terminated 138 with the NUL (%x00) character). The client passes the data to 139 GSS_Wrap with conf_flag set to FALSE, and responds with the generated 140 output_message. The client can then consider the server 141 authenticated. 143 3.2. Server side of authentication protocol exchange 145 A server MUST NOT advertise support for the "GSSAPI" SASL mechanism 146 described in this document unless it has acceptor credential for the 147 Kerberos V GSS-API Mechanism [KRB5GSS]. 149 The server passes the initial client response to 150 GSS_Accept_sec_context as input_token, setting input_context_handle 151 to 0 (initially), chan_binding of NULL, and a suitable 152 acceptor_cred_handle (see below). If GSS_Accept_sec_context returns 153 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 154 to the client in challenge and passes the resulting response to 155 another call to GSS_Accept_sec_context, repeating the actions in this 156 paragraph. 158 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred 159 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the 160 Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use 161 GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY 162 use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred 163 for the server's principal name(s) (**) and the Kerberos V5 GSS-API 164 mechanism [KRB5GSS]. 166 (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of 167 GSS-API mechanism as an input parameter. The OID set can be created 168 by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can 169 be freed by calling the GSS_Release_oid_set. 171 (**) - Use of server's principal names having 172 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, 173 where "service" is the service name specified in the protocol's 174 profile, is RECOMMENDED. 176 Upon successful establishment of the security context (i.e. 177 GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD 178 verify that the negotiated GSS-API mechanism is indeed Kerberos V5 179 [KRB5GSS]. This is done by examining the value of the mech_type 180 parameter returned from the GSS_Accept_sec_context call. If the 181 value differ SASL authentication MUST be aborted. 183 Upon successful establishment of the security context the server 184 SHOULD also check using the GSS_Inquire_context that the target_name 185 used by the client matches either: 187 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, 188 where "service" is the service name specified in the application 189 protocol's profile, 191 or that 193 - the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two- 194 component principal where the first component matches the service 195 name specified in the application protocol's profile. 197 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 198 examines the context to ensure that it provides a level of protection 199 permitted by the server's security policy. If the context is 200 acceptable, the server takes the following actions: If the last call 201 to GSS_Accept_sec_context returned an output_token, the server 202 returns it to the client in a challenge and expects a reply from the 203 client with no data. Whether or not an output_token was returned 204 (and after receipt of any response from the client to such an 205 output_token), the server then constructs 4 octets of data, with the 206 first octet containing a bit-mask specifying the security layers 207 supported by the server and the second through fourth octets 208 containing in network byte order the maximum size output_token the 209 server is able to receive (which MUST be 0 if the server doesn't 210 support any security layer). The server must then pass the plaintext 211 to GSS_Wrap with conf_flag set to FALSE and issue the generated 212 output_message to the client in a challenge. The server must then 213 pass the resulting response to GSS_Unwrap and interpret the first 214 octet of resulting cleartext as the bit-mask for the selected 215 security layer, the second through fourth octets as the maximum size 216 output_message the client is able to receive (in network byte order), 217 and the remaining octets as the authorization identity. The server 218 verifies that the client has selected a security layer that was 219 offered, and that the client maximum buffer is 0 if no security layer 220 was chosen. The server must verify that the src_name is authorized 221 to act as the authorization identity. After these verifications, the 222 authentication process is complete. 224 3.3. Security layer 226 The security layers and their corresponding bit-masks are as follows: 228 1 No security layer 229 2 Integrity protection. 230 Sender calls GSS_Wrap with conf_flag set to FALSE 231 4 Confidentiality protection. 232 Sender calls GSS_Wrap with conf_flag set to TRUE 234 Other bit-masks may be defined in the future; bits which are not 235 understood must be negotiated off. 237 Note that SASL negotiates the maximum size of the output_message to 238 send. Implementations can use the GSS_Wrap_size_limit call to 239 determine the corresponding maximum size input_message. 241 4. IANA Considerations 243 The IANA is directed to modify the existing registration for "GSSAPI" 244 as follows: 246 Family of SASL mechanisms: NO 248 SASL mechanism name: GSSAPI 250 Security considerations: See Section 5 of RFC [THIS-DOC] 251 Published Specification: RFC [THIS-DOC] 253 Person & email address to contact for further information: Alexey 254 Melnikov 256 Intended usage: COMMON 258 Owner/Change controller: iesg@ietf.org 260 Additional Information: This mechanism is for the Kerberos V5 261 mechanism of GSS-API. 263 5. Security Considerations 265 Security issues are discussed throughout this memo. 267 The integrity protection provided by the GSSAPI security layer is 268 useless to the client unless the client also requests mutual 269 authentication. Therefore, a client wishing to benefit from the 270 integrity protection of a security layer MUST pass to the 271 GSS_Init_sec_context call a mutual_req_flag of TRUE. 273 When constructing the input_name_string, the client SHOULD NOT 274 canonicalize the server's fully qualified domain name using an 275 insecure or untrusted directory service. 277 For compatibility with deployed software this document requires that 278 the chan_binding (channel bindings) parameter to GSS_Init_sec_context 279 and GSS_Accept_sec_context be NULL. SASL WG has reached consensus 280 that this limitation is worth addressing and a future document will 281 define a new GSS-API SASL mechanism that will not have this 282 limitation. 284 Additional security considerations are in the [SASL] and [GSS-API] 285 specifications. Additional security considerations for the GSSAPI 286 mechanism can be found in [KRB5GSS]. 288 6. Acknowledgements 290 This document replaces section 7.2 of RFC 2222 [SASL] by John G. 291 Myers. He also contributed significantly to this revision. 293 Thank you to Lawrence Greenfield for converting text of this draft to 294 XML format. 296 Contributions of many members of the SASL mailing list are gratefully 297 acknowledged, in particular comments from Chris Newman, Nicolas 298 Williams and Jeffrey Hutzelman. 300 7. References 302 7.1. Normative References 304 [GSS-API] Linn, J., "Generic Security Service Application Program 305 Interface Version 2, Update 1", RFC 2743, January 2000. 307 [KEYWORDS] 308 Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 312 RFC 1964, June 1996. 314 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 315 Version 5 Generic Security Service Application Program 316 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 317 July 2005. 319 [SASL] Myers, J., "Simple Authentication and Security Layer 320 (SASL)", RFC 2222, October 1997. 322 [SASL[2]] Melnikov, A., "Simple Authentication and Security Layer 323 (SASL)", draft-ietf-sasl-rfc2222bis (work in progress), 324 June 2004. 326 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 327 10646", RFC 3629, November 2003. 329 7.2. Informative References 330 Author's Address 332 Alexey Melnikov (Ed.) 333 Isode Limited 334 5 Castle Business Village 335 36 Station Road 336 Hampton, Middlesex TW12 2BX 337 UK 339 Email: Alexey.Melnikov@isode.com 340 URI: http://www.melnikov.ca/ 342 Intellectual Property Statement 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org. 366 Disclaimer of Validity 368 This document and the information contained herein are provided on an 369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 371 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 372 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 373 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Copyright Statement 378 Copyright (C) The Internet Society (2006). This document is subject 379 to the rights, licenses and restrictions contained in BCP 78, and 380 except as set forth therein, the authors retain all their rights. 382 Acknowledgment 384 Funding for the RFC Editor function is currently provided by the 385 Internet Society.