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