imapext-2007
view docs/rfc/rfc4752.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group A. Melnikov, Ed.
8 Request for Comments: 4752 Isode
9 Obsoletes: 2222 November 2006
10 Category: Standards Track
13 The Kerberos V5 ("GSSAPI")
14 Simple Authentication and Security Layer (SASL) Mechanism
16 Status of This Memo
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright Notice
26 Copyright (C) The IETF Trust (2006).
28 Abstract
30 The Simple Authentication and Security Layer (SASL) is a framework
31 for adding authentication support to connection-based protocols.
32 This document describes the method for using the Generic Security
33 Service Application Program Interface (GSS-API) Kerberos V5 in the
34 SASL.
36 This document replaces Section 7.2 of RFC 2222, the definition of the
37 "GSSAPI" SASL mechanism. This document, together with RFC 4422,
38 obsoletes RFC 2222.
58 Melnikov Standards Track [Page 1]
60 RFC 4752 SASL GSSAPI Mechanism November 2006
63 Table of Contents
65 1. Introduction ....................................................2
66 1.1. Relationship to Other Documents ............................2
67 2. Conventions Used in This Document ...............................2
68 3. Kerberos V5 GSS-API Mechanism ...................................2
69 3.1. Client Side of Authentication Protocol Exchange ............3
70 3.2. Server Side of Authentication Protocol Exchange ............4
71 3.3. Security Layer .............................................6
72 4. IANA Considerations .............................................7
73 5. Security Considerations .........................................7
74 6. Acknowledgements ................................................8
75 7. Changes since RFC 2222 ..........................................8
76 8. References ......................................................8
77 8.1. Normative References .......................................8
78 8.2. Informative References .....................................9
80 1. Introduction
82 This specification documents currently deployed Simple Authentication
83 and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5
84 [KERBEROS] Generic Security Service Application Program Interface
85 ([GSS-API]) mechanism [RFC4121]. The authentication sequence is
86 described in Section 3. Note that the described authentication
87 sequence has known limitations, in particular, it lacks channel
88 bindings and the number of round-trips required to complete
89 authentication exchange is not minimal. SASL WG is working on a
90 separate document that should address these limitations.
92 1.1. Relationship to Other Documents
94 This document, together with RFC 4422, obsoletes RFC 2222 in its
95 entirety. This document replaces Section 7.2 of RFC 2222. The
96 remainder is obsoleted as detailed in Section 1.2 of RFC 4422.
98 2. Conventions Used in This Document
100 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
101 in this document are to be interpreted as defined in "Key words for
102 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
104 3. Kerberos V5 GSS-API Mechanism
106 The SASL mechanism name for the Kerberos V5 GSS-API mechanism
107 [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism,
108 the mechanism is specifically tied to Kerberos V5 and GSS-API's
109 Kerberos V5 mechanism.
114 Melnikov Standards Track [Page 2]
116 RFC 4752 SASL GSSAPI Mechanism November 2006
119 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism;
120 i.e., it starts with the client sending a "response" created as
121 described in the following section.
123 The implementation MAY set any GSS-API flags or arguments not
124 mentioned in this specification as is necessary for the
125 implementation to enforce its security policy.
127 Note that major status codes returned by GSS_Init_sec_context() or
128 GSS_Accept_sec_context() other than GSS_S_COMPLETE or
129 GSS_S_CONTINUE_NEEDED cause authentication failure. Major status
130 codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any
131 additional supplementary status codes) cause authentication and/or
132 security layer failure.
134 3.1. Client Side of Authentication Protocol Exchange
136 The client calls GSS_Init_sec_context, passing in
137 input_context_handle of 0 (initially), mech_type of the Kerberos V5
138 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
139 equal to output_name from GSS_Import_Name called with input_name_type
140 of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
141 "service@hostname" where "service" is the service name specified in
142 the protocol's profile, and "hostname" is the fully qualified host
143 name of the server. When calling the GSS_Init_sec_context, the
144 client MUST pass the integ_req_flag of TRUE (**). If the client will
145 be requesting a security layer, it MUST also supply to the
146 GSS_Init_sec_context a mutual_req_flag of TRUE, and a
147 sequence_req_flag of TRUE. If the client will be requesting a
148 security layer providing confidentiality protection, it MUST also
149 supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The
150 client then responds with the resulting output_token. If
151 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
152 should expect the server to issue a token in a subsequent challenge.
153 The client must pass the token to another call to
154 GSS_Init_sec_context, repeating the actions in this paragraph.
156 (*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE
157 to import servers' acceptor names, but only when they have a priori
158 knowledge that the servers support alternate name types. Otherwise
159 clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
160 names.
162 (**) Note that RFC 2222 [RFC2222] implementations will not work with
163 GSS-API implementations that require integ_req_flag to be true. No
164 implementations of RFC 1964 [KRB5GSS] or RFC 4121 [RFC4121] that
165 require integ_req_flag to be true are believed to exist and it is
166 expected that any future update to [RFC4121] will require that
170 Melnikov Standards Track [Page 3]
172 RFC 4752 SASL GSSAPI Mechanism November 2006
175 integrity be available even in not explicitly requested by the
176 application.
178 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
179 the context to ensure that it provides a level of protection
180 permitted by the client's security policy. In particular, if the
181 integ_avail flag is not set in the context, then no security layer
182 can be offered or accepted.
184 If the conf_avail flag is not set in the context, then no security
185 layer with confidentiality can be offered or accepted. If the
186 context is acceptable, the client takes the following actions: If the
187 last call to GSS_Init_sec_context returned an output_token, then the
188 client responds with the output_token, otherwise the client responds
189 with no data. The client should then expect the server to issue a
190 token in a subsequent challenge. The client passes this token to
191 GSS_Unwrap and interprets the first octet of resulting cleartext as a
192 bit-mask specifying the security layers supported by the server and
193 the second through fourth octets as the maximum size output_message
194 the server is able to receive (in network byte order). If the
195 resulting cleartext is not 4 octets long, the client fails the
196 negotiation. The client verifies that the server maximum buffer is 0
197 if the server does not advertise support for any security layer.
199 The client then constructs data, with the first octet containing the
200 bit-mask specifying the selected security layer, the second through
201 fourth octets containing in network byte order the maximum size
202 output_message the client is able to receive (which MUST be 0 if the
203 client does not support any security layer), and the remaining octets
204 containing the UTF-8 [UTF8] encoded authorization identity.
205 (Implementation note: The authorization identity is not terminated
206 with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the
207 NUL (U+0000) character)). The client passes the data to GSS_Wrap
208 with conf_flag set to FALSE and responds with the generated
209 output_message. The client can then consider the server
210 authenticated.
212 3.2. Server Side of Authentication Protocol Exchange
214 A server MUST NOT advertise support for the "GSSAPI" SASL mechanism
215 described in this document unless it has acceptor credential for the
216 Kerberos V GSS-API mechanism [KRB5GSS].
218 The server passes the initial client response to
219 GSS_Accept_sec_context as input_token, setting input_context_handle
220 to 0 (initially), chan_binding of NULL, and a suitable
221 acceptor_cred_handle (see below). If GSS_Accept_sec_context returns
222 GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
226 Melnikov Standards Track [Page 4]
228 RFC 4752 SASL GSSAPI Mechanism November 2006
231 to the client in challenge and passes the resulting response to
232 another call to GSS_Accept_sec_context, repeating the actions in this
233 paragraph.
235 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
236 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the Object
237 Identifier (OID) of the Kerberos V5 GSS-API mechanism [KRB5GSS](*).
238 Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle.
239 Servers MAY use a credential obtained by calling GSS_Acquire_cred or
240 GSS_Add_cred for the server's principal name(s) (**) and the Kerberos
241 V5 GSS-API mechanism [KRB5GSS].
243 (*) Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of GSS-
244 API mechanism as an input parameter. The OID set can be created by
245 using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can be
246 freed by calling the GSS_Release_oid_set.
249 (**) Use of server's principal names having
250 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
251 where "service" is the service name specified in the protocol's
252 profile, and "hostname" is the fully qualified host name of the
253 server, is RECOMMENDED. The server name is generated by calling
254 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
255 and input_name_string of "service@hostname".
257 Upon successful establishment of the security context (i.e.,
258 GSS_Accept_sec_context returns GSS_S_COMPLETE), the server SHOULD
259 verify that the negotiated GSS-API mechanism is indeed Kerberos V5
260 [KRB5GSS]. This is done by examining the value of the mech_type
261 parameter returned from the GSS_Accept_sec_context call. If the
262 value differs, SASL authentication MUST be aborted.
264 Upon successful establishment of the security context and if the
265 server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
266 credential handle, the server SHOULD also check using the
267 GSS_Inquire_context that the target_name used by the client matches
268 either
270 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
271 where "service" is the service name specified in the application
272 protocol's profile,
274 or
276 - the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-
277 component principal where the first component matches the service
278 name specified in the application protocol's profile.
282 Melnikov Standards Track [Page 5]
284 RFC 4752 SASL GSSAPI Mechanism November 2006
287 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
288 examines the context to ensure that it provides a level of protection
289 permitted by the server's security policy. In particular, if the
290 integ_avail flag is not set in the context, then no security layer
291 can be offered or accepted. If the conf_avail flag is not set in the
292 context, then no security layer with confidentiality can be offered
293 or accepted.
295 If the context is acceptable, the server takes the following actions:
296 If the last call to GSS_Accept_sec_context returned an output_token,
297 the server returns it to the client in a challenge and expects a
298 reply from the client with no data. Whether or not an output_token
299 was returned (and after receipt of any response from the client to
300 such an output_token), the server then constructs 4 octets of data,
301 with the first octet containing a bit-mask specifying the security
302 layers supported by the server and the second through fourth octets
303 containing in network byte order the maximum size output_token the
304 server is able to receive (which MUST be 0 if the server does not
305 support any security layer). The server must then pass the plaintext
306 to GSS_Wrap with conf_flag set to FALSE and issue the generated
307 output_message to the client in a challenge.
309 The server must then pass the resulting response to GSS_Unwrap and
310 interpret the first octet of resulting cleartext as the bit-mask for
311 the selected security layer, the second through fourth octets as the
312 maximum size output_message the client is able to receive (in network
313 byte order), and the remaining octets as the authorization identity.
314 The server verifies that the client has selected a security layer
315 that was offered and that the client maximum buffer is 0 if no
316 security layer was chosen. The server must verify that the src_name
317 is authorized to act as the authorization identity. After these
318 verifications, the authentication process is complete. The server is
319 not expected to return any additional data with the success
320 indicator.
322 3.3. Security Layer
324 The security layers and their corresponding bit-masks are as follows:
326 1 No security layer
327 2 Integrity protection.
328 Sender calls GSS_Wrap with conf_flag set to FALSE
329 4 Confidentiality protection.
330 Sender calls GSS_Wrap with conf_flag set to TRUE
332 Other bit-masks may be defined in the future; bits that are not
333 understood must be negotiated off.
338 Melnikov Standards Track [Page 6]
340 RFC 4752 SASL GSSAPI Mechanism November 2006
343 When decoding any received data with GSS_Unwrap, the major_status
344 other than the GSS_S_COMPLETE MUST be treated as a fatal error.
346 Note that SASL negotiates the maximum size of the output_message to
347 send. Implementations can use the GSS_Wrap_size_limit call to
348 determine the corresponding maximum size input_message.
350 4. IANA Considerations
352 IANA modified the existing registration for "GSSAPI" as follows:
354 Family of SASL mechanisms: NO
356 SASL mechanism name: GSSAPI
358 Security considerations: See Section 5 of RFC 4752
360 Published specification: RFC 4752
362 Person & email address to contact for further information:
363 Alexey Melnikov <Alexey.Melnikov@isode.com>
365 Intended usage: COMMON
367 Owner/Change controller: iesg@ietf.org
369 Additional information: This mechanism is for the Kerberos V5
370 mechanism of GSS-API.
372 5. Security Considerations
374 Security issues are discussed throughout this memo.
376 When constructing the input_name_string, the client SHOULD NOT
377 canonicalize the server's fully qualified domain name using an
378 insecure or untrusted directory service.
380 For compatibility with deployed software, this document requires that
381 the chan_binding (channel bindings) parameter to GSS_Init_sec_context
382 and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API
383 support for channel bindings. GSS-API channel bindings in SASL is
384 expected to be supported via a new GSS-API family of SASL mechanisms
385 (to be introduced in a future document).
387 Additional security considerations are in the [SASL] and [GSS-API]
388 specifications. Additional security considerations for the GSS-API
389 mechanism can be found in [KRB5GSS] and [KERBEROS].
394 Melnikov Standards Track [Page 7]
396 RFC 4752 SASL GSSAPI Mechanism November 2006
399 6. Acknowledgements
401 This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G.
402 Myers. He also contributed significantly to this revision.
404 Lawrence Greenfield converted text of this document to the XML
405 format.
407 Contributions of many members of the SASL mailing list are gratefully
408 acknowledged, in particular comments from Chris Newman, Nicolas
409 Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin, and Martin
410 Rex.
412 7. Changes since RFC 2222
414 RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222
415 [RFC2222], which provided the original version of this specification.
416 That version of GSS-API did not provide the integ_integ_avail flag as
417 an input to GSS_Init_sec_context. Instead, integrity was always
418 requested. RFC 4422 [SASL] requires that when possible, the security
419 layer negotiation be integrity protected. To meet this requirement
420 and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API],
421 this specification requires that clients request integrity from
422 GSS_Init_sec_context so they can use GSS_Wrap to protect the security
423 layer negotiation. This specification does not require that the
424 mechanism offer the integrity security layer, simply that the
425 security layer negotiation be wrapped.
427 8. References
429 8.1. Normative References
431 [GSS-API] Linn, J., "Generic Security Service Application Program
432 Interface Version 2, Update 1", RFC 2743, January 2000.
434 [KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
435 Kerberos Network Authentication Service (V5)", RFC 4120,
436 July 2005.
438 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
439 Requirement Levels", BCP 14, RFC 2119, March 1997.
441 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
442 1964, June 1996.
450 Melnikov Standards Track [Page 8]
452 RFC 4752 SASL GSSAPI Mechanism November 2006
455 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
456 Version 5 Generic Security Service Application Program
457 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
458 2005.
460 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
461 Security Layer (SASL)", RFC 4422, June 2006.
463 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
464 10646", STD 63, RFC 3629, November 2003.
466 8.2. Informative References
468 [RFC2078] Linn, J., "Generic Security Service Application Program
469 Interface, Version 2", RFC 2078, January 1997.
471 [RFC2222] Myers, J., "Simple Authentication and Security Layer
472 (SASL)", RFC 2222, October 1997.
474 Editor's Address
476 Alexey Melnikov
477 Isode Limited
478 5 Castle Business Village
479 36 Station Road
480 Hampton, Middlesex TW12 2BX
481 UK
483 EMail: Alexey.Melnikov@isode.com
484 URI: http://www.melnikov.ca/
506 Melnikov Standards Track [Page 9]
508 RFC 4752 SASL GSSAPI Mechanism November 2006
511 Full Copyright Statement
513 Copyright (C) The IETF Trust (2006).
515 This document is subject to the rights, licenses and restrictions
516 contained in BCP 78, and except as set forth therein, the authors
517 retain all their rights.
519 This document and the information contained herein are provided on an
520 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
521 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
522 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
523 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
524 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
525 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
526 PURPOSE.
528 Intellectual Property
530 The IETF takes no position regarding the validity or scope of any
531 Intellectual Property Rights or other rights that might be claimed to
532 pertain to the implementation or use of the technology described in
533 this document or the extent to which any license under such rights
534 might or might not be available; nor does it represent that it has
535 made any independent effort to identify any such rights. Information
536 on the procedures with respect to rights in RFC documents can be
537 found in BCP 78 and BCP 79.
539 Copies of IPR disclosures made to the IETF Secretariat and any
540 assurances of licenses to be made available, or the result of an
541 attempt made to obtain a general license or permission for the use of
542 such proprietary rights by implementers or users of this
543 specification can be obtained from the IETF on-line IPR repository at
544 http://www.ietf.org/ipr.
546 The IETF invites any interested party to bring to its attention any
547 copyrights, patents or patent applications, or other proprietary
548 rights that may cover technology that may be required to implement
549 this standard. Please address the information to the IETF at
550 ietf-ipr@ietf.org.
552 Acknowledgement
554 Funding for the RFC Editor function is currently provided by the
555 Internet Society.
562 Melnikov Standards Track [Page 10]