7 Expires: December 1, 2006 May 30, 2006
10 The Kerberos V5 ("GSSAPI") SASL mechanism
11 draft-ietf-sasl-gssapi-05
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 1, 2006.
40 Copyright (C) The Internet Society (2006).
44 The Simple Authentication and Security Layer (SASL, RFC XXXX) 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
48 in the Simple Authentication and Security Layer.
50 This document replaces section 7.2 of RFC 2222, the definition of the
51 "GSSAPI" SASL mechanism.
56 Melnikov Expires December 1, 2006 [Page 1]
58 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 2006
63 1. Conventions Used in this Document . . . . . . . . . . . . . . 3
64 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
65 3. Kerberos V5 GSS-API mechanism . . . . . . . . . . . . . . . . 3
66 3.1. Client side of authentication protocol exchange . . . . . 3
67 3.2. Server side of authentication protocol exchange . . . . . 4
68 3.3. Security layer . . . . . . . . . . . . . . . . . . . . . . 6
69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
74 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
76 Intellectual Property and Copyright Statements . . . . . . . . . . 10
112 Melnikov Expires December 1, 2006 [Page 2]
114 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 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].
124 2. Introduction and Overview
126 This specification documents currently deployed Kerberos V5 GSS-API
127 mechanism used within SASL framework [SASL]. The authentication
128 sequence is described in Section 3. Note that the described
129 authentication sequence has known limitations in particular it lacks
130 channel bindings and the number of round trips required to complete
131 authentication exchange is not minimal. SASL WG is working on a
132 separate document that should address these limitations.
134 The SASL mechanism name for the Kerberos V5 GSS-API mechanism
135 [RFC4121] is "GSSAPI".
138 3. Kerberos V5 GSS-API mechanism
140 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism,
141 i.e. it starts with the client sending a "response" created as
142 described in the following section.
144 The implementation MAY set any GSS-API flags or arguments not
145 mentioned in this specification as is necessary for the
146 implementation to enforce its security policy.
148 3.1. Client side of authentication protocol exchange
150 The client calls GSS_Init_sec_context, passing in
151 input_context_handle of 0 (initially), mech_type of the Kerberos V5
152 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
153 equal to output_name from GSS_Import_Name called with input_name_type
154 of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
155 "service@hostname" where "service" is the service name specified in
156 the protocol's profile, and "hostname" is the fully qualified host
157 name of the server. If the client will be requesting a security
158 layer, it MUST also supply to the GSS_Init_sec_context a
159 mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
160 integ_req_flag of TRUE. If the client will be requesting a security
161 layer providing confidentiality protection, it MUST also supply to
162 the GSS_Init_sec_context a conf_req_flag of TRUE. The client then
163 responds with the resulting output_token. If GSS_Init_sec_context
164 returns GSS_S_CONTINUE_NEEDED, then the client should expect the
168 Melnikov Expires December 1, 2006 [Page 3]
170 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 2006
173 server to issue a token in a subsequent challenge. The client must
174 pass the token to another call to GSS_Init_sec_context, repeating the
175 actions in this paragraph.
177 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
178 the context to ensure that it provides a level of protection
179 permitted by the client's security policy. If the context is
180 acceptable, the client takes the following actions: If the last call
181 to GSS_Init_sec_context returned an output_token, then the client
182 responds with the output_token, otherwise the client responds with no
183 data. The client should then expect the server to issue a token in a
184 subsequent challenge. The client passes this token to GSS_Unwrap and
185 interprets the first octet of resulting cleartext as a bit-mask
186 specifying the security layers supported by the server and the second
187 through fourth octets as the maximum size output_message the server
188 is able to receive (in network byte order). If the resulting
189 cleartext is not 4 octets long, the client fails the negotiation.
190 The client verifies that the server maximum buffer is 0 if the server
191 doesn't advertise support for any security layer. The client then
192 constructs data, with the first octet containing the bit-mask
193 specifying the selected security layer, the second through fourth
194 octets containing in network byte order the maximum size
195 output_message the client is able to receive (which MUST be 0 if the
196 client doesn't support any security layer), and the remaining octets
197 containing the UTF-8 [UTF8] encoded authorization identity.
198 (Implementation note: the authorization identity is not terminated
199 with the NUL (%x00) character). The client passes the data to
200 GSS_Wrap with conf_flag set to FALSE, and responds with the generated
201 output_message. The client can then consider the server
204 3.2. Server side of authentication protocol exchange
206 A server MUST NOT advertise support for the "GSSAPI" SASL mechanism
207 described in this document unless it has acceptor credential for the
208 Kerberos V GSS-API Mechanism [KRB5GSS].
210 The server passes the initial client response to
211 GSS_Accept_sec_context as input_token, setting input_context_handle
212 to 0 (initially), chan_binding of NULL, and a suitable
213 acceptor_cred_handle (see below). If GSS_Accept_sec_context returns
214 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
215 to the client in challenge and passes the resulting response to
216 another call to GSS_Accept_sec_context, repeating the actions in this
219 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
220 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
224 Melnikov Expires December 1, 2006 [Page 4]
226 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 2006
229 Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use
230 GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY
231 use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
232 for the server's principal name(s) (**) and the Kerberos V5 GSS-API
235 (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
236 GSS-API mechanism as an input parameter. The OID set can be created
237 by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can
238 be freed by calling the GSS_Release_oid_set.
240 (**) - Use of server's principal names having
241 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
242 where "service" is the service name specified in the protocol's
243 profile, is RECOMMENDED.
245 Upon successful establishment of the security context (i.e.
246 GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
247 verify that the negotiated GSS-API mechanism is indeed Kerberos V5
248 [KRB5GSS]. This is done by examining the value of the mech_type
249 parameter returned from the GSS_Accept_sec_context call. If the
250 value differ SASL authentication MUST be aborted.
252 Upon successful establishment of the security context the server
253 SHOULD also check using the GSS_Inquire_context that the target_name
254 used by the client matches either:
256 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
257 where "service" is the service name specified in the application
262 - the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-
263 component principal where the first component matches the service
264 name specified in the application protocol's profile.
266 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
267 examines the context to ensure that it provides a level of protection
268 permitted by the server's security policy. If the context is
269 acceptable, the server takes the following actions: If the last call
270 to GSS_Accept_sec_context returned an output_token, the server
271 returns it to the client in a challenge and expects a reply from the
272 client with no data. Whether or not an output_token was returned
273 (and after receipt of any response from the client to such an
274 output_token), the server then constructs 4 octets of data, with the
275 first octet containing a bit-mask specifying the security layers
276 supported by the server and the second through fourth octets
280 Melnikov Expires December 1, 2006 [Page 5]
282 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 2006
285 containing in network byte order the maximum size output_token the
286 server is able to receive (which MUST be 0 if the server doesn't
287 support any security layer). The server must then pass the plaintext
288 to GSS_Wrap with conf_flag set to FALSE and issue the generated
289 output_message to the client in a challenge. The server must then
290 pass the resulting response to GSS_Unwrap and interpret the first
291 octet of resulting cleartext as the bit-mask for the selected
292 security layer, the second through fourth octets as the maximum size
293 output_message the client is able to receive (in network byte order),
294 and the remaining octets as the authorization identity. The server
295 verifies that the client has selected a security layer that was
296 offered, and that the client maximum buffer is 0 if no security layer
297 was chosen. The server must verify that the src_name is authorized
298 to act as the authorization identity. After these verifications, the
299 authentication process is complete.
303 The security layers and their corresponding bit-masks are as follows:
306 2 Integrity protection.
307 Sender calls GSS_Wrap with conf_flag set to FALSE
308 4 Confidentiality protection.
309 Sender calls GSS_Wrap with conf_flag set to TRUE
311 Other bit-masks may be defined in the future; bits which are not
312 understood must be negotiated off.
314 Note that SASL negotiates the maximum size of the output_message to
315 send. Implementations can use the GSS_Wrap_size_limit call to
316 determine the corresponding maximum size input_message.
319 4. IANA Considerations
321 The IANA is directed to modify the existing registration for "GSSAPI"
324 Family of SASL mechanisms: NO
326 SASL mechanism name: GSSAPI
328 Security considerations: See Section 5 of RFC [THIS-DOC]
336 Melnikov Expires December 1, 2006 [Page 6]
338 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 2006
341 Published Specification: RFC [THIS-DOC]
343 Person & email address to contact for further information: Alexey
344 Melnikov <Alexey.Melnikov@isode.com>
346 Intended usage: COMMON
348 Owner/Change controller: iesg@ietf.org
350 Additional Information: This mechanism is for the Kerberos V5
351 mechanism of GSS-API.
354 5. Security Considerations
356 Security issues are discussed throughout this memo.
358 The integrity protection provided by the GSSAPI security layer is
359 useless to the client unless the client also requests mutual
360 authentication. Therefore, a client wishing to benefit from the
361 integrity protection of a security layer MUST pass to the
362 GSS_Init_sec_context call a mutual_req_flag of TRUE.
364 When constructing the input_name_string, the client SHOULD NOT
365 canonicalize the server's fully qualified domain name using an
366 insecure or untrusted directory service.
368 For compatibility with deployed software this document requires that
369 the chan_binding (channel bindings) parameter to GSS_Init_sec_context
370 and GSS_Accept_sec_context be NULL. SASL WG has reached consensus
371 that this limitation is worth addressing and a future document will
372 define a new GSS-API SASL mechanism that will not have this
375 Additional security considerations are in the [SASL] and [GSS-API]
376 specifications. Additional security considerations for the GSSAPI
377 mechanism can be found in [KRB5GSS].
382 This document replaces section 7.2 of RFC 2222 [SASL] by John G.
383 Myers. He also contributed significantly to this revision.
385 Thank you to Lawrence Greenfield for converting text of this draft to
388 Contributions of many members of the SASL mailing list are gratefully
392 Melnikov Expires December 1, 2006 [Page 7]
394 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 2006
397 acknowledged, in particular comments from Chris Newman, Nicolas
398 Williams and Jeffrey Hutzelman.
403 7.1. Normative References
405 [GSS-API] Linn, J., "Generic Security Service Application Program
406 Interface Version 2, Update 1", RFC 2743, January 2000.
409 Bradner, S., "Key words for use in RFCs to Indicate
410 Requirement Levels", BCP 14, RFC 2119, March 1997.
412 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
415 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
416 Version 5 Generic Security Service Application Program
417 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
420 [SASL] Myers, J., "Simple Authentication and Security Layer
421 (SASL)", RFC 2222, October 1997.
423 [SASL[2]] Melnikov, A., "Simple Authentication and Security Layer
424 (SASL)", draft-ietf-sasl-rfc2222bis (work in progress),
427 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
428 10646", RFC 3629, November 2003.
430 7.2. Informative References
448 Melnikov Expires December 1, 2006 [Page 8]
450 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 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 1, 2006 [Page 9]
506 Internet-Draft The Kerberos V5 ("GSSAPI") SASL mechanism May 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 1, 2006 [Page 10]