idnits 2.17.1 draft-ietf-sasl-gssapi-04.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 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 320. ** 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 : ---------------------------------------------------------------------------- ** 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 (February 11, 2006) is 6646 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 212, but not defined ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) Summary: 5 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: August 15, 2006 February 11, 2006 6 The Kerberos V5 ("GSSAPI") SASL mechanism 7 draft-ietf-sasl-gssapi-04 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 August 15, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Simple Authentication and Security Layer [SASL] is a method for 41 adding authentication support to connection-based protocols. This 42 document describes the method for using the Generic Security Service 43 Application Program Interface [GSSAPI] KERBEROS V5 in the Simple 44 Authentication and Security Layer [SASL]. 46 This document replaces section 7.2 of RFC 2222 [SASL], the definition 47 of the "GSSAPI" SASL mechanism. 49 Table of Contents 51 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 52 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 53 3. Kerberos V5 GSSAPI mechanism . . . . . . . . . . . . . . . . . 5 54 3.1 Client side of authentication protocol exchange . . . . . 5 55 3.2 Server side of authentication protocol exchange . . . . . 6 56 3.3 Security layer . . . . . . . . . . . . . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 62 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 64 Intellectual Property and Copyright Statements . . . . . . . . 12 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 GSSAPI 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 GSSAPI mechanism 83 [KRB5GSS] is "GSSAPI". 85 3. Kerberos V5 GSSAPI mechanism 87 The implementation MAY set any GSSAPI flags or arguments not 88 mentioned in this specification as is necessary for the 89 implementation to enforce its security policy. 91 3.1 Client side of authentication protocol exchange 93 The client calls GSS_Init_sec_context, passing in 94 input_context_handle of 0 (initially), mech_type of the GSSAPI 95 mechanism for which this SASL mechanism is registered, chan_binding 96 of NULL, and targ_name equal to output_name from GSS_Import_Name 97 called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and 98 input_name_string of "service@hostname" where "service" is the 99 service name specified in the protocol's profile, and "hostname" is 100 the fully qualified host name of the server. If the client will be 101 requesting a security layer, it MUST also supply to the 102 GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag 103 of TRUE, and an integ_req_flag of TRUE. If the client will be 104 requesting a security layer providing confidentiality protection, it 105 MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. 106 The client then responds with the resulting output_token. If 107 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 108 should expect the server to issue a token in a subsequent challenge. 109 The client must pass the token to another call to 110 GSS_Init_sec_context, repeating the actions in this paragraph. 112 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 113 the context to ensure that it provides a level of protection 114 permitted by the client's security policy. If the context is 115 acceptable, the client takes the following actions: If the last call 116 to GSS_Init_sec_context returned an output_token, then the client 117 responds with the output_token, otherwise the client responds with no 118 data. The client should then expect the server to issue a token in a 119 subsequent challenge. The client passes this token to GSS_Unwrap and 120 interprets the first octet of resulting cleartext as a bit-mask 121 specifying the security layers supported by the server and the second 122 through fourth octets as the maximum size output_message the server 123 is able to receive (in network byte order). If the resulting 124 cleartext is not 4 octets long, the client fails the negotiation. 125 The client verifies that the server maximum buffer is 0 if the server 126 doesn't advertise support for any security layer. The client then 127 constructs data, with the first octet containing the bit-mask 128 specifying the selected security layer, the second through fourth 129 octets containing in network byte order the maximum size 130 output_message the client is able to receive (which MUST be 0 if the 131 client doesn't support any security layer), and the remaining octets 132 containing the UTF-8 [UTF8] encoded authorization identity. 134 (Implementation note: the authorization identity is not terminated 135 with the NUL (%x00) character). The client passes the data to 136 GSS_Wrap with conf_flag set to FALSE, and responds with the generated 137 output_message. The client can then consider the server 138 authenticated. 140 3.2 Server side of authentication protocol exchange 142 The server passes the initial client response to 143 GSS_Accept_sec_context as input_token, setting input_context_handle 144 to 0 (initially), mech_type of the GSSAPI mechanism for which this 145 SASL mechanism is registered, chan_binding of NULL, and 146 acceptor_cred_handle equal to output_cred_handle from 147 GSS_Acquire_cred called with desired_name equal to output_name from 148 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE 149 and input_name_string of "service@hostname" where "service" is the 150 service name specified in the protocol's profile, and "hostname" is 151 the fully qualified host name of the server. If 152 GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server 153 returns the generated output_token to the client in challenge and 154 passes the resulting response to another call to 155 GSS_Accept_sec_context, repeating the actions in this paragraph. 157 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 158 examines the context to ensure that it provides a level of protection 159 permitted by the server's security policy. If the context is 160 acceptable, the server takes the following actions: If the last call 161 to GSS_Accept_sec_context returned an output_token, the server 162 returns it to the client in a challenge and expects a reply from the 163 client with no data. Whether or not an output_token was returned 164 (and after receipt of any response from the client to such an 165 output_token), the server then constructs 4 octets of data, with the 166 first octet containing a bit-mask specifying the security layers 167 supported by the server and the second through fourth octets 168 containing in network byte order the maximum size output_token the 169 server is able to receive (which MUST be 0 if the server doesn't 170 support any security layer). The server must then pass the plaintext 171 to GSS_Wrap with conf_flag set to FALSE and issue the generated 172 output_message to the client in a challenge. The server must then 173 pass the resulting response to GSS_Unwrap and interpret the first 174 octet of resulting cleartext as the bit-mask for the selected 175 security layer, the second through fourth octets as the maximum size 176 output_message the client is able to receive (in network byte order), 177 and the remaining octets as the authorization identity. The server 178 verifies that the client has selected a security layer that was 179 offered, and that the client maximum buffer is 0 if no security layer 180 was chosen. The server must verify that the src_name is authorized 181 to act as the authorization identity. After these verifications, the 182 authentication process is complete. 184 3.3 Security layer 186 The security layers and their corresponding bit-masks are as follows: 188 1 No security layer 189 2 Integrity protection. 190 Sender calls GSS_Wrap with conf_flag set to FALSE 191 4 Confidentiality protection. 192 Sender calls GSS_Wrap with conf_flag set to TRUE 194 Other bit-masks may be defined in the future; bits which are not 195 understood must be negotiated off. 197 Note that SASL negotiates the maximum size of the output_message to 198 send. Implementations can use the GSS_Wrap_size_limit call to 199 determine the corresponding maximum size input_message. 201 4. IANA Considerations 203 The IANA is directed to modify the existing registration for "GSSAPI" 204 as follows: 206 Family of SASL mechanisms: NO 208 SASL mechanism name: GSSAPI 210 Security considerations: See Section 5 of RFC [THIS-DOC] 212 Published Specification: RFC [THIS-DOC] 214 Person & email address to contact for further information: Alexey 215 Melnikov 217 Intended usage: COMMON 219 Owner/Change controller: iesg@ietf.org 221 Additional Information: This mechanism is for the Kerberos V5 222 mechanism of GSSAPI. 224 5. Security Considerations 226 Security issues are discussed throughout this memo. 228 The integrity protection provided by the GSSAPI security layer is 229 useless to the client unless the client also requests mutual 230 authentication. Therefore, a client wishing to benefit from the 231 integrity protection of a security layer MUST pass to the 232 GSS_Init_sec_context call a mutual_req_flag of TRUE. 234 When constructing the input_name_string, the client SHOULD NOT 235 canonicalize the server's fully qualified domain name using an 236 insecure or untrusted directory service. 238 For compatibility with deployed software this document requires that 239 the chan_binding (channel bindings) parameter to GSS_Init_sec_context 240 and GSS_Accept_sec_context be NULL. SASL WG has reached consensus 241 that this limitation is worth addressing and a future document will 242 define a new GSSAPI SASL mechanism that will not have this 243 limitation. 245 Additional security considerations are in the [SASL] and [GSSAPI] 246 specifications. Additional security considerations for the GSSAPI 247 mechanism can be found in [KRB5GSS]. 249 6. Acknowledgements 251 This document replaces section 7.2 of RFC 2222 [SASL] by John G. 252 Myers. He also contributed significantly to this revision. 254 Thank you to Lawrence Greenfield for converting text of this draft to 255 XML format. 257 Contributions of many members of the SASL mailing list are gratefully 258 acknowledged. 260 7. References 262 7.1 Normative References 264 [GSSAPI] Linn, J., "Generic Security Service Application Program 265 Interface Version 2, Update 1", RFC 2743, January 2000. 267 [KEYWORDS] 268 Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 272 RFC 1964, June 1996. 274 [SASL] Myers, J., "Simple Authentication and Security Layer 275 (SASL)", RFC 2222, October 1997. 277 [SASL[2]] Melnikov, A., "Simple Authentication and Security Layer 278 (SASL)", draft-ietf-sasl-rfc2222bis (work in progress), 279 June 2004. 281 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 282 10646", RFC 3629, November 2003. 284 7.2 Informative References 286 Author's Address 288 Alexey Melnikov (Ed.) 289 Isode Limited 290 5 Castle Business Village 291 36 Station Road 292 Hampton, Middlesex TW12 2BX 293 UK 295 Email: Alexey.Melnikov@isode.com 296 URI: http://www.melnikov.ca/ 298 Intellectual Property Statement 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be 307 found in BCP 78 and BCP 79. 309 Copies of IPR disclosures made to the IETF Secretariat and any 310 assurances of licenses to be made available, or the result of an 311 attempt made to obtain a general license or permission for the use of 312 such proprietary rights by implementers or users of this 313 specification can be obtained from the IETF on-line IPR repository at 314 http://www.ietf.org/ipr. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 this standard. Please address the information to the IETF at 320 ietf-ipr@ietf.org. 322 Disclaimer of Validity 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Copyright Statement 334 Copyright (C) The Internet Society (2006). This document is subject 335 to the rights, licenses and restrictions contained in BCP 78, and 336 except as set forth therein, the authors retain all their rights. 338 Acknowledgment 340 Funding for the RFC Editor function is currently provided by the 341 Internet Society.