7 Expires: December 11, 2006 June 9, 2006
10 The Kerberos V5 ("GSSAPI") SASL mechanism
11 draft-ietf-sasl-gssapi-06
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on December 11, 2006.
40 Copyright (C) The Internet Society (2006).
44 The Simple Authentication and Security Layer (SASL, RFC 4422) is a
45 framework for adding authentication support to connection-based
46 protocols. This document describes the method for using the Generic
47 Security Service Application Program Interface (GSS-API) Kerberos V5
50 This document replaces section 7.2 of RFC 2222, the definition of the
51 "GSSAPI" SASL mechanism.
56 Melnikov Expires December 11, 2006 [Page 1]
58 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
63 1. Conventions Used in this Document . . . . . . . . . . . . . . 3
64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
65 2.1. Relationship to Other Documents . . . . . . . . . . . . . 3
66 3. Kerberos V5 GSS-API mechanism . . . . . . . . . . . . . . . . 3
67 3.1. Client side of authentication protocol exchange . . . . . 3
68 3.2. Server side of authentication protocol exchange . . . . . 4
69 3.3. Security layer . . . . . . . . . . . . . . . . . . . . . . 6
70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
75 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
77 Intellectual Property and Copyright Statements . . . . . . . . . . 10
112 Melnikov Expires December 11, 2006 [Page 2]
114 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
117 1. Conventions Used in this Document
119 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
120 in this document are to be interpreted as defined in "Key words for
121 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
126 This specification documents currently deployed Simple Authentication
127 and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5
128 [KERBEROS] Generic Security Service Application Program Interface
129 ([GSS-API]) mechanism [RFC4121]. The authentication sequence is
130 described in Section 3. Note that the described authentication
131 sequence has known limitations in particular it lacks channel
132 bindings and the number of round trips required to complete
133 authentication exchange is not minimal. SASL WG is working on a
134 separate document that should address these limitations.
136 2.1. Relationship to Other Documents
138 This document, together with RFC 4422, obsoletes RFC 2222 in its
139 entirety. This document replaces Section 7.2 of RFC 2222. The
140 remainder is obsoleted as detailed in Section 1.2 of RFC 4422.
143 3. Kerberos V5 GSS-API mechanism
145 The SASL mechanism name for the Kerberos V5 GSS-API mechanism
146 [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism,
147 the mechanism is specifically tied to Kerberos V5 and GSS-API's
148 Kerberos V5 mechanism.
150 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism,
151 i.e. it starts with the client sending a "response" created as
152 described in the following section.
154 The implementation MAY set any GSS-API flags or arguments not
155 mentioned in this specification as is necessary for the
156 implementation to enforce its security policy.
158 3.1. Client side of authentication protocol exchange
160 The client calls GSS_Init_sec_context, passing in
161 input_context_handle of 0 (initially), mech_type of the Kerberos V5
162 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
163 equal to output_name from GSS_Import_Name called with input_name_type
164 of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
168 Melnikov Expires December 11, 2006 [Page 3]
170 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
173 "service@hostname" where "service" is the service name specified in
174 the protocol's profile, and "hostname" is the fully qualified host
175 name of the server. If the client will be requesting a security
176 layer, it MUST also supply to the GSS_Init_sec_context a
177 mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
178 integ_req_flag of TRUE. If the client will be requesting a security
179 layer providing confidentiality protection, it MUST also supply to
180 the GSS_Init_sec_context a conf_req_flag of TRUE. The client then
181 responds with the resulting output_token. If GSS_Init_sec_context
182 returns GSS_S_CONTINUE_NEEDED, then the client should expect the
183 server to issue a token in a subsequent challenge. The client must
184 pass the token to another call to GSS_Init_sec_context, repeating the
185 actions in this paragraph.
187 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
188 the context to ensure that it provides a level of protection
189 permitted by the client's security policy. If the context is
190 acceptable, the client takes the following actions: If the last call
191 to GSS_Init_sec_context returned an output_token, then the client
192 responds with the output_token, otherwise the client responds with no
193 data. The client should then expect the server to issue a token in a
194 subsequent challenge. The client passes this token to GSS_Unwrap and
195 interprets the first octet of resulting cleartext as a bit-mask
196 specifying the security layers supported by the server and the second
197 through fourth octets as the maximum size output_message the server
198 is able to receive (in network byte order). If the resulting
199 cleartext is not 4 octets long, the client fails the negotiation.
200 The client verifies that the server maximum buffer is 0 if the server
201 doesn't advertise support for any security layer. The client then
202 constructs data, with the first octet containing the bit-mask
203 specifying the selected security layer, the second through fourth
204 octets containing in network byte order the maximum size
205 output_message the client is able to receive (which MUST be 0 if the
206 client doesn't support any security layer), and the remaining octets
207 containing the UTF-8 [UTF8] encoded authorization identity.
208 (Implementation note: the authorization identity is not terminated
209 with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the
210 NUL (U+0000) character)). The client passes the data to GSS_Wrap
211 with conf_flag set to FALSE, and responds with the generated
212 output_message. The client can then consider the server
215 3.2. Server side of authentication protocol exchange
217 A server MUST NOT advertise support for the "GSSAPI" SASL mechanism
218 described in this document unless it has acceptor credential for the
219 Kerberos V GSS-API Mechanism [KRB5GSS].
224 Melnikov Expires December 11, 2006 [Page 4]
226 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
229 The server passes the initial client response to
230 GSS_Accept_sec_context as input_token, setting input_context_handle
231 to 0 (initially), chan_binding of NULL, and a suitable
232 acceptor_cred_handle (see below). If GSS_Accept_sec_context returns
233 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
234 to the client in challenge and passes the resulting response to
235 another call to GSS_Accept_sec_context, repeating the actions in this
238 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
239 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
240 Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use
241 GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY
242 use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
243 for the server's principal name(s) (**) and the Kerberos V5 GSS-API
246 (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
247 GSS-API mechanism as an input parameter. The OID set can be created
248 by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can
249 be freed by calling the GSS_Release_oid_set.
251 (**) - Use of server's principal names having
252 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
253 where "service" is the service name specified in the protocol's
254 profile, is RECOMMENDED.
256 Upon successful establishment of the security context (i.e.
257 GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
258 verify that the negotiated GSS-API mechanism is indeed Kerberos V5
259 [KRB5GSS]. This is done by examining the value of the mech_type
260 parameter returned from the GSS_Accept_sec_context call. If the
261 value differ SASL authentication MUST be aborted.
263 Upon successful establishment of the security context the server
264 SHOULD also check using the GSS_Inquire_context that the target_name
265 used by the client matches either:
267 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
268 where "service" is the service name specified in the application
273 - the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-
274 component principal where the first component matches the service
275 name specified in the application protocol's profile.
280 Melnikov Expires December 11, 2006 [Page 5]
282 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
285 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
286 examines the context to ensure that it provides a level of protection
287 permitted by the server's security policy. If the context is
288 acceptable, the server takes the following actions: If the last call
289 to GSS_Accept_sec_context returned an output_token, the server
290 returns it to the client in a challenge and expects a reply from the
291 client with no data. Whether or not an output_token was returned
292 (and after receipt of any response from the client to such an
293 output_token), the server then constructs 4 octets of data, with the
294 first octet containing a bit-mask specifying the security layers
295 supported by the server and the second through fourth octets
296 containing in network byte order the maximum size output_token the
297 server is able to receive (which MUST be 0 if the server doesn't
298 support any security layer). The server must then pass the plaintext
299 to GSS_Wrap with conf_flag set to FALSE and issue the generated
300 output_message to the client in a challenge. The server must then
301 pass the resulting response to GSS_Unwrap and interpret the first
302 octet of resulting cleartext as the bit-mask for the selected
303 security layer, the second through fourth octets as the maximum size
304 output_message the client is able to receive (in network byte order),
305 and the remaining octets as the authorization identity. The server
306 verifies that the client has selected a security layer that was
307 offered, and that the client maximum buffer is 0 if no security layer
308 was chosen. The server must verify that the src_name is authorized
309 to act as the authorization identity. After these verifications, the
310 authentication process is complete.
314 The security layers and their corresponding bit-masks are as follows:
317 2 Integrity protection.
318 Sender calls GSS_Wrap with conf_flag set to FALSE
319 4 Confidentiality protection.
320 Sender calls GSS_Wrap with conf_flag set to TRUE
322 Other bit-masks may be defined in the future; bits which are not
323 understood must be negotiated off.
325 Note that SASL negotiates the maximum size of the output_message to
326 send. Implementations can use the GSS_Wrap_size_limit call to
327 determine the corresponding maximum size input_message.
330 4. IANA Considerations
332 The IANA is directed to modify the existing registration for "GSSAPI"
336 Melnikov Expires December 11, 2006 [Page 6]
338 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
343 Family of SASL mechanisms: NO
345 SASL mechanism name: GSSAPI
347 Security considerations: See Section 5 of RFC [THIS-DOC]
349 Published Specification: RFC [THIS-DOC]
351 Person & email address to contact for further information: Alexey
352 Melnikov <Alexey.Melnikov@isode.com>
354 Intended usage: COMMON
356 Owner/Change controller: iesg@ietf.org
358 Additional Information: This mechanism is for the Kerberos V5
359 mechanism of GSS-API.
362 5. Security Considerations
364 Security issues are discussed throughout this memo.
366 The integrity protection provided by the GSSAPI security layer is
367 useless to the client unless the client also requests mutual
368 authentication. Therefore, a client wishing to benefit from the
369 integrity protection of a security layer MUST pass to the
370 GSS_Init_sec_context call a mutual_req_flag of TRUE.
372 When constructing the input_name_string, the client SHOULD NOT
373 canonicalize the server's fully qualified domain name using an
374 insecure or untrusted directory service.
376 For compatibility with deployed software this document requires that
377 the chan_binding (channel bindings) parameter to GSS_Init_sec_context
378 and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API
379 support for channel bindings. GSS-API channel bindings in SASL is
380 expected to be supported via a new GSS-API family of SASL mechanisms
381 (to be introduced in a future document).
383 Additional security considerations are in the [SASL] and [GSS-API]
384 specifications. Additional security considerations for the GSS-API
385 mechanism can be found in [KRB5GSS] and [KERBEROS].
392 Melnikov Expires December 11, 2006 [Page 7]
394 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
399 This document replaces section 7.2 of RFC 2222 [RFC2222] by John G.
400 Myers. He also contributed significantly to this revision.
402 Lawrence Greenfield converted text of this draft to the XML format.
404 Contributions of many members of the SASL mailing list are gratefully
405 acknowledged, in particular comments from Chris Newman, Nicolas
406 Williams and Jeffrey Hutzelman.
411 7.1. Normative References
413 [GSS-API] Linn, J., "Generic Security Service Application Program
414 Interface Version 2, Update 1", RFC 2743, January 2000.
417 Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
418 Kerberos Network Authentication Service (V5)", RFC 4120,
422 Bradner, S., "Key words for use in RFCs to Indicate
423 Requirement Levels", BCP 14, RFC 2119, March 1997.
425 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
428 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
429 Version 5 Generic Security Service Application Program
430 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
433 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
434 Security Layer (SASL)", RFC 4422, June 2006.
436 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
437 10646", RFC 3629, November 2003.
439 7.2. Informative References
441 [RFC2222] Myers, J., "Simple Authentication and Security Layer
442 (SASL)", RFC 2222, October 1997.
448 Melnikov Expires December 11, 2006 [Page 8]
450 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
455 Alexey Melnikov (Ed.)
457 5 Castle Business Village
459 Hampton, Middlesex TW12 2BX
462 Email: Alexey.Melnikov@isode.com
463 URI: http://www.melnikov.ca/
504 Melnikov Expires December 11, 2006 [Page 9]
506 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism June 2006
509 Intellectual Property Statement
511 The IETF takes no position regarding the validity or scope of any
512 Intellectual Property Rights or other rights that might be claimed to
513 pertain to the implementation or use of the technology described in
514 this document or the extent to which any license under such rights
515 might or might not be available; nor does it represent that it has
516 made any independent effort to identify any such rights. Information
517 on the procedures with respect to rights in RFC documents can be
518 found in BCP 78 and BCP 79.
520 Copies of IPR disclosures made to the IETF Secretariat and any
521 assurances of licenses to be made available, or the result of an
522 attempt made to obtain a general license or permission for the use of
523 such proprietary rights by implementers or users of this
524 specification can be obtained from the IETF on-line IPR repository at
525 http://www.ietf.org/ipr.
527 The IETF invites any interested party to bring to its attention any
528 copyrights, patents or patent applications, or other proprietary
529 rights that may cover technology that may be required to implement
530 this standard. Please address the information to the IETF at
534 Disclaimer of Validity
536 This document and the information contained herein are provided on an
537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
547 Copyright (C) The Internet Society (2006). This document is subject
548 to the rights, licenses and restrictions contained in BCP 78, and
549 except as set forth therein, the authors retain all their rights.
554 Funding for the RFC Editor function is currently provided by the
560 Melnikov Expires December 11, 2006 [Page 10]