| blob | 5c6bb8724828afc6ac2dd18d90029229693cbe09 |
4 Network Working Group S. Josefsson
5 Internet-Draft June 26, 2006
6 Expires: December 28, 2006
9 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
10 draft-ietf-sasl-gs2-01
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on December 28, 2006.
37 Copyright Notice
39 Copyright (C) The Internet Society (2006).
41 Abstract
43 This document describes how to use a Generic Security Service
44 Application Program Interface (GSS-API) mechanism in the the Simple
45 Authentication and Security Layer (SASL) framework.
47 See <http://josefsson.org/sasl-gs2-*/> for more information.
55 Josefsson Expires December 28, 2006 [Page 1]
56 \f
57 Internet-Draft SASL GS2-* June 2006
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Conventions Used in this Document . . . . . . . . . . . . . . 3
64 3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3
65 3.1. Generating SASL Mechanism Names From GSS-API OIDs . . . . 3
66 3.2. Computing Mechanism Names Manually . . . . . . . . . . . . 4
67 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4
69 4.1. SASL Tokens . . . . . . . . . . . . . . . . . . . . . . . 4
70 4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5
71 4.3. Context Token . . . . . . . . . . . . . . . . . . . . . . 6
72 4.4. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . 7
73 4.4.1. Wrap Token Input For Client Requests . . . . . . . . . 7
74 4.4.2. WraP Token Input For Server Responses . . . . . . . . 8
75 4.4.3. Wrap Token Input For Server Requests . . . . . . . . . 9
76 4.4.4. Wrap Token Input For Client Responses . . . . . . . . 9
77 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10
78 5.1. Name Of Tls Channel For Use As Channel Binding . . . . . . 11
79 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
80 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 14
81 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 14
82 9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 15
83 10. Interoperability With The Gssapi Mechanism . . . . . . . . . . 15
84 10.1. The Interoperability problem . . . . . . . . . . . . . . . 15
85 10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 15
86 10.3. Additional recommendations . . . . . . . . . . . . . . . . 15
87 11. Mechanisms That Negotiate Other Mechanisms . . . . . . . . . . 16
88 11.1. The Interoperability Problem . . . . . . . . . . . . . . . 16
89 11.2. Security Problem . . . . . . . . . . . . . . . . . . . . . 16
90 11.3. Resolving the Problems . . . . . . . . . . . . . . . . . . 16
91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
92 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
93 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
94 15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 18
95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
96 16.1. Normative References . . . . . . . . . . . . . . . . . . . 18
97 16.2. Informative References . . . . . . . . . . . . . . . . . . 19
98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
99 Intellectual Property and Copyright Statements . . . . . . . . . . 21
111 Josefsson Expires December 28, 2006 [Page 2]
112 \f
113 Internet-Draft SASL GS2-* June 2006
116 1. Introduction
118 Generic Security Service Application Program Interface (GSS-API) [3]
119 is a framework that provide security services to applications.
120 Simple Authentication and Security Layer (SASL) [2] is a framework to
121 provide authentication and security layers for connection based
122 protocols. This document describe how to use a GSS-API mechanism in
123 a connection-based protocol using the SASL framework.
125 All GSSAPI mechanisms are implicitly registered for use within SASL
126 by this specification. The SASL mechanism defined in this document
127 is known as the GS2 family.
129 The "Kerberos V5 GSS-API mechanism" [9] is also supported in SASL
130 through "SASL GSSAPI mechanisms" [11]. The difference between that
131 protocol and the one described here, is that this protocol offer more
132 features (i.e., channel bindings and round-trip optimizations) while
133 the other protocol is more widely deployed. There are
134 interoperability concerns by having the same GSS-API mechanism
135 available under more than one SASL mechanism name, see the section
136 "Interoperability with the GSSAPI mechanism" below.
138 There are interoperability and security concerns if this SASL
139 mechanism is used together with a GSS-API mechanism that negotiate
140 other GSS-API mechanisms (such as SPNEGO [10]), see the section
141 "Mechanisms that negotiate other mechanisms" below.
143 SASL mechanism names starting with "GS2-" are reserved for SASL
144 mechanisms which conform to this document.
146 The IESG is considered to be the owner of all SASL mechanisms which
147 conform to this document. This does not necessarily imply that the
148 IESG is considered to be the owner of the underlying GSSAPI
149 mechanism.
152 2. Conventions Used in this Document
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156 document are to be interpreted as described in [1].
159 3. Mechanism Name
161 3.1. Generating SASL Mechanism Names From GSS-API OIDs
163 The SASL mechanism name for a GSS-API mechanism is the concatenation
167 Josefsson Expires December 28, 2006 [Page 3]
168 \f
169 Internet-Draft SASL GS2-* June 2006
172 of the string "GS2-" and the Base32 encoding [5] (with an upper case
173 alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
174 computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's
175 Object Identifier. The Base32 rules on padding characters and
176 characters outside of the base32 alphabet are not relevant to this
177 use of Base32. If any padding or non-alphabet characters are
178 encountered, the name is not a GS2 family mechanism name.
180 3.2. Computing Mechanism Names Manually
182 The SASL mechanism name may be computed manually. This is useful
183 when the set of supported GSS-API mechanisms is known in advance. It
184 also obliterate the need to implement Base32, SHA-1 and DER in the
185 SASL mechanism. The computed mechanism name can be used directly in
186 the implementation, and the implementation need not concern itself
187 with that the mechanism is part of a mechanism family.
189 3.3. Example
191 For example, the OID for the SPKM-1 mechanism [12] is
192 1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01
193 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is
194 1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the
195 first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL
196 mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-
197 DT4PIK22T6EPV2PY".
200 4. Packet Format
202 4.1. SASL Tokens
204 All top-level SASL packets for the GS2 mechanism family follow the
205 following format:
223 Josefsson Expires December 28, 2006 [Page 4]
224 \f
225 Internet-Draft SASL GS2-* June 2006
228 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
231 | Context length |
232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
233 | Flags |
234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
235 | /
236 / Context token /
237 / --------------------/
238 / ---------------------/ /
239 /--------------------/ /
240 / [Wrap token] /
241 / /
242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244 The "Context length" field is a 4 octet (32 bit) integer encoded in
245 network byte order, it indicate the length of the "Context token"
246 field.
248 The "Flags" field is a 4 octet (32 bit) bitmask that holds flags that
249 influence the authentication process.
251 The "Context token" field contain a GSS-API context establishment
252 token generated by GSS_Init_sec_context or GSS_Accept_sec_context.
254 The "Wrap token" field is optional, and if present will contain the
255 output generated by GSS_Wrap.
257 The length field does not include the length of the length field
258 itself. Whether the "Wrap token" field is included or not can be
259 infered from the length field; if the length field is shorter than
260 the entire packet size minus 4 octets, the "Wrap token" field is
261 present and begins after length+4 octets into the packet. The tokens
262 need not be aligned to 32-bit a boundary. There is no padding
263 between the tokens.
265 Packets shorter than 4 octets are invalid. If the length field is
266 longer than the entire packet size, minus 4 octets, the packet is
267 invalid.
269 4.2. Flags
271 Bit 0 signal whether GSS-API Channel bindings are used. It is only
272 useful in the first token sent from the client, and MUST be set to 0
273 in all other tokens. The bit is called the "Native Channel Bindings"
274 bit. The client chooses whether to set this bit or not depending on
275 local policy or user requests.
279 Josefsson Expires December 28, 2006 [Page 5]
280 \f
281 Internet-Draft SASL GS2-* June 2006
284 The other bits are not specified and MUST be zero. If a bit is set
285 that is not understood by the implementation, it MUST be ignored.
287 4.3. Context Token
289 The format of the "Context token" field inside the SASL token are
290 defined by the GSS-API specifications, and the data is computed by
291 the GSS_Init_sec_context and GSS_Accept_sec_context functions.
293 The client calls GSS_Init_sec_context, passing in
294 input_context_handle of 0 (initially), mech_type of the GSSAPI
295 mechanism for which this SASL mechanism is registered, the
296 chan_binding is set to NULL or the channel binding data depending on
297 the Native Channel Binding flag, and targ_name equal to output_name
298 from GSS_Import_Name called with input_name_type of
299 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
300 "service@hostname" where "service" is the service name specified in
301 the protocol's profile, and "hostname" is the fully qualified host
302 name of the server. If the client will be requesting a security
303 layer, it MUST also supply to the GSS_Init_sec_context a
304 mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
305 integ_req_flag of TRUE. If the client will be requesting a security
306 layer providing confidentiality protection, it MUST also supply to
307 the GSS_Init_sec_context a conf_req_flag of TRUE. If
308 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
309 should expect the server to issue a token in a subsequent challenge
310 or as additional information to the outcome of the authentication.
311 The client must pass the context token to another call to
312 GSS_Init_sec_context, repeating the actions in this paragraph, until
313 GSS_S_COMPLETE is returned or authentication is aborted. If the
314 server supply data beyond the context token, the context token should
315 be processed first, and then the overflow data should be passed to
316 GSS_Unwrap and the unwrapped data should be interpreted. During the
317 authentication exchange, the client will generate one Wrap token
318 using GSS_Wrap.
320 The server passes the first client response to GSS_Accept_sec_context
321 as input_token, setting input_context_handle to 0 (initially),
322 mech_type of the GSSAPI mechanism for which this SASL mechanism is
323 registered, the chan_binding set to NULL or the channel binding data
324 depending on the Native Channel Binding bit, and acceptor_cred_handle
325 equal to output_cred_handle from GSS_Acquire_cred called with
326 desired_name equal to output_name from GSS_Import_name with
327 input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string
328 of "service@hostname" where "service" is the service name specified
329 in the protocol's profile, and "hostname" is the fully qualified host
330 name of the server. The server must pass any resulting challenge
331 from the client to another call to GSS_Accept_sec_context, repeating
335 Josefsson Expires December 28, 2006 [Page 6]
336 \f
337 Internet-Draft SASL GS2-* June 2006
340 the actions in this paragraph, until GSS_S_COMPLETE is returned or
341 authentication is aborted. If the client supply data beyond the
342 context token, the context token should be processed first, and then
343 the overflow data should be passed to GSS_Unwrap and the unwrapped
344 data should be interpreted. During the authentication exchange, the
345 server will generate one Wrap token using GSS_Wrap.
347 4.4. Wrap Token
349 The Wrap token MUST NOT be sent before the PROT_READY flag has been
350 set locally (by GSS_Init_sec_context or Gss_Accept_sec_context), or
351 if the PROT_READY flag is never set, before the context has been
352 fully established. The GSS_Wrap token does not have to be sent
353 directly when the PROT_READY flag is set. During any exchange,
354 exactly one GSS_Wrap token is sent in each direction. The input to
355 the GSS_Wrap function MUST follow the format described below. If not
356 exactly one GSS_Wrap token is received by the client and by the
357 server, the authentication MUST fail.
359 If PROT_READY is never set by GSS_Init_sec_context or
360 GSS_Accept_sec_context, the flag is implied by successful context
361 negotiation. This is for GSS-API v1 mechanisms that do not support
362 PROT_READY. This may result in a SASL token consisting of a context
363 token length of 0 and a Wrap token.
365 The entity that sends its first Wrap token will have to specify a
366 bitmap of supported and preferred quality of protection schemes. The
367 entity that reply to the Wrap tokens will pick a scheme, based on the
368 bitmask and local policy.
370 Four input formats to the GSS_Wrap function are defined. The first
371 two input formats are used when the client sends the GSS_Wrap token
372 first and the server reponds. The other two input formats are used
373 when the server sends the GSS_Wrap token first and the client
374 responds.
376 The input formats below are passed to GSS_Wrap with conf_flag set to
377 FALSE, and the Wrap token output will be the generated
378 output_message.
380 Some fields in the input formats are optional, indicated by brackets
381 ("[" and "]") and explained by the text below.
383 4.4.1. Wrap Token Input For Client Requests
385 The input to GSS_Wrap when the client sends the GSS_Wrap token first
386 is as follows.
391 Josefsson Expires December 28, 2006 [Page 7]
392 \f
393 Internet-Draft SASL GS2-* June 2006
396 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
399 | client_qops | client_maxbuf |
400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
401 | channel_binding_length |
402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
403 |[client_cbqops]| [channel_binding_data] /
404 / /
405 / / [authzid] /
406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408 The "client_qops" integer indicate the client's preferred quality of
409 protection if channel bindings are absent or the negotiation of the
410 channel binding fails.
412 The "client_maxbuf" field indicate the maximum protected buffer size
413 the client can receive.
415 The "channel_binding_length" is a network byte order integer that
416 indicate the length of the "channel_binding_data" field.
418 The optional field "client_cbqops" is present only if
419 "channel_binding_length" is non-zero, and indicate the client's
420 preferred quality of protection if channel binding negotiation
421 succeeds.
423 The optional field "channel_binding_data" is present only if
424 "channel_binding_length" is non-zero, and contain the actual channel
425 binding data.
427 The optional field "authzid" contain the authorization identity. The
428 authorization identity is encoded using UTF-8 [6]. The authorization
429 identity is not terminated with the NUL (U+0000) character. Servers
430 MUST validate that the authorization identity is valid UTF-8.
432 4.4.2. WraP Token Input For Server Responses
434 The data format for input to GSS_Wrap when the server responds to the
435 previous GSS_Wrap token data is as follows.
437 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
440 | server_qop | server_maxbuf |
441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
443 The "server_qop" field integer indicate the selected quality of
447 Josefsson Expires December 28, 2006 [Page 8]
448 \f
449 Internet-Draft SASL GS2-* June 2006
452 protection.
454 The "server_maxbuf" field indicate the maximum data buffer size the
455 server can receive. It MUST be 0 if the server doesn't advertise
456 support for any security layer, the client MUST verify this.
458 4.4.3. Wrap Token Input For Server Requests
460 The data format for input to GSS_Wrap when the server sends the
461 GSS_Wrap token first is as follows.
463 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
464 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
466 | server_qops | server_maxbuf |
467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
468 | channel_binding_length |
469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
470 |[server_cbqops]| [channel_binding_data] /
471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473 The "server_qops" field is an integer indicating the server's
474 preferred quality of protection if channel bindings are absent or the
475 negotiation of the channel binding fails.
477 The "server_maxbuf" is the same as above.
479 The "channel_binding_length" is a network byte order integer that
480 indicate the length of the "channel_binding_data" field.
482 The optional field "server_cbqops" is present only if
483 "channel_binding_length" is non-zero, and indicate the server's
484 preferred quality of protection if channel binding negotiation
485 succeeds.
487 The optional field "channel_binding_data" is present only if
488 "channel_binding_length" is non-zero, and contain the actual channel
489 binding data.
491 4.4.4. Wrap Token Input For Client Responses
493 The data format for input to GSS_Wrap when the client responds to the
494 previous token is as follows.
503 Josefsson Expires December 28, 2006 [Page 9]
504 \f
505 Internet-Draft SASL GS2-* June 2006
508 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511 | client_qop | client_maxbuf |
512 / [authzid] |
513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515 The "client_qop" field is the selected quality of protection.
517 The "client_maxbuf" and "authzid" fields are as above.
520 5. Channel Bindings
522 [[This section is tentative further discussion on the topic. This
523 was written to provide an example of how the details of how one
524 approach to this concept could look like. There are other approaches
525 that may be preferable.]]
527 The GS2 mechanism provide its own token field for channel bindings,
528 in addition to the "chan_binding" parameter in the GSS-API context
529 functions. The reason for this is that the GS2 mechanism wish to
530 provide an option to proceed even if the channel bindings does not
531 match. The GSS-API framework specifies that authentication cannot
532 proceed if channel bindings does not match. The GSS-API framework
533 also does not specify the kind of privacy layer the channel binding
534 should be transferred under, thus making it possible for attackers to
535 modify it to always make channel binding negotiation succeed.
537 The client can select, using the "Native Channel Bindings" bit,
538 whether it wishes to use the "chan_bindings" parameter in the GSS-API
539 layer or not. If it wishes to use this, it is not possible to
540 continue after a failed channel binding negotiation.
542 A client that wish to continue with the authentication even if the
543 channel bindings does not match, set the "Native Channel Binding" bit
544 to 0. It MUST use the channel binding field in the GS2 token. It
545 MUST set the "chan_binding" parameter in the calls to
546 GSS_Init_sec_context to GSS_Accept_sec_context to NULL. The
547 application MUST set the "client_qops" field to include privacy
548 protection (to protect the SASL application data), and MAY set the
549 "client_cbqops" to no security layer (to avoid performance
550 degradation due to two security layers).
552 If a client do not wish to continue the authentication if channel
553 binding negotiation fails, or wishes to use the channel binding in
554 the GSS-API layer, it will set the "Native Channel Binding" bit to 1
555 in its first token. It MUST use both the channel binding field in
559 Josefsson Expires December 28, 2006 [Page 10]
560 \f
561 Internet-Draft SASL GS2-* June 2006
564 the GS2 token and the "chan_binding" parameter in the calls to
565 GSS_Init_sec_context and GSS_Accept_sec_context. The authentication
566 will fail in the GSS-API layer if the channel bindings does not
567 match, and thus the "client_qops" and "client_cbqops" MUST be set to
568 the same value. It MAY be set to no security layer (to avoid
569 performance degradation due to two security layers).
571 For TLS, the channel binding data is specified in the next section.
572 For other security layers, channel binding data will have to
573 specified elsewhere, and this specification will have to be updated
574 with explicit considerations.
576 [[All channel bindings should go into a separate document.]]
578 5.1. Name Of Tls Channel For Use As Channel Binding
580 The TLS Pseudo-Random Function (PRF) generate, using the constant
581 string "TLS channel binding", and based on the master secret and the
582 random values established during a TLS handshake, a 64 octet string
583 that make up the SASL channel binding data.
585 Using the terminology of TLS [13], the channel binding data is
586 computed as follows:
588 SASL_channel_binding =
589 PRF(SecurityParameters.master_secret,
590 "TLS channel binding",
591 SecurityParameters.server_random +
592 SecurityParameters.client_random) [0..64];
594 The derived data is intended to be used as a name of the TLS channel
595 that is cryptographically bound to the channel, for use in
596 authentication mechanisms tunneled over TLS.
599 6. Protocol Overview
601 This section describe several high-level protocol exchanges. The
602 descriptions do not assume any properties of the actual GSS-API
603 mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
604 and to some extent implementation and policy choices, will dictate
605 which packets are sent in what order. The protocol exchanges are
606 examples and other exchanges are permitted and will occur.
608 An authentication exchange using GS2 may look like:
615 Josefsson Expires December 28, 2006 [Page 11]
616 \f
617 Internet-Draft SASL GS2-* June 2006
620 C: Request authentication exchange
621 S: Send [length=0] token
622 C: Send [length, GSS_Init_sec_context] token
623 ...
624 S: After PROT_READY is set,
625 send [length, GSS_Accept_sec_context,
626 GSS_Wrap(server_qops, server_maxbuf,
627 channel_binding_length=0)]
628 ...
629 C: After PROT_READY is set,
630 send [length, GSS_Init_sec_context,
631 GSS_Wrap (client_qop, client_maxbuf, authzid)]
632 S: Send [length, GSS_Accept_sec_context] token
633 C: Send [length, GSS_Init_sec_context] token
634 ...
635 S: Outcome of authentication exchange
637 Because GSS-API authentication is initiated by the client, the length
638 field will be 0 in the initial token from the server to the client
639 when the protocol profile do not support additional information to be
640 sent together with the authentication request.
642 The next example illustrate when the client sends its Wrap token
643 first.
645 C: Request authentication exchange
646 S: Send [length=0] token
647 C: Send [length, GSS_Init_sec_context] token
648 ...
649 C: After PROT_READY is set,
650 send [length, GSS_Init_sec_context,
651 GSS_Wrap(client_qops, client_maxbuf,
652 channel_binding_length=0, authzid)]
653 ...
654 S: After PROT_READY is set,
655 send [length, GSS_Accept_sec_context,
656 GSS_Wrap (server_qop, server_maxbuf)]
657 C: Send [length, GSS_Init_sec_context] token
658 S: Send [length, GSS_Accept_sec_context] token
659 ...
660 S: Outcome of authentication exchange
662 If the protocol profile support the optional initial client response,
663 the first empty message can be optimized away, and then the protocol
664 exchange will look like:
671 Josefsson Expires December 28, 2006 [Page 12]
672 \f
673 Internet-Draft SASL GS2-* June 2006
676 C: Request authentication exchange and
677 send [length, GSS_Init_sec_context] token
678 S: Send [length, GSS_Accept_sec_context] token
679 ...
680 S: Outcome of authentication exchange
682 If the protocol profile can also send additional information when
683 indicating the outcome of the authentication, then the protocol
684 exchange will look like:
686 C: Request authentication exchange and
687 send [length, GSS_Init_sec_context] token
688 S: Send [length, GSS_Accept_sec_context] token
689 ...
690 C: Send [length, GSS_Init_sec_context] token
691 S: Indicate successful authentication and
692 send [length, GSS_Accept_sec_context] token
693 as additional information.
695 If the PROT_READY flag is never set by the GSS-API mechanism, the
696 GSS_Wrap message will be sent after the context has been established.
697 The protocol may look like:
699 C: Request authentication exchange
700 ...
701 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
702 a token, send [length, context token,
703 GSS_Wrap(server_qops, server_maxbuf,
704 channel_binding_length=0)]
705 C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
706 output a token, send
707 [length=0, context token,
708 GSS_Wrap(client_qop, client_maxbuf,
709 channel_binding_length=0, authzid)]
710 S: Outcome of authentication exchange
712 Alternatively, if the client finishes first, it may look like:
714 C: Request authentication exchange
715 ...
716 C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
717 token, send [length, context token,
718 GSS_Wrap(client_qops, client_maxbuf,
719 channel_binding_length=0, authzid)]
720 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
721 output a token, send [length, context token,
722 GSS_Wrap(server_qop, server_maxbuf,
723 channel_binding_length=0)]
727 Josefsson Expires December 28, 2006 [Page 13]
728 \f
729 Internet-Draft SASL GS2-* June 2006
732 S: Outcome of authentication exchange
734 If the protocol support initial data from the client, and the
735 PROT_READY flag is set in the client after the first call to
736 GSS_Init_sec_context, and the server can send additional data to the
737 client when indicating successful authentication, the following
738 protocol exchange will occur.
740 C: Request authentication exchange and
741 send [length, GSS_Init_sec_context,
742 GSS_Wrap (client_qops, client_maxbuf,
743 channel_binding_length=0, authzid)] token
744 S: Indicate successful authentication and
745 send [length, GSS_Accept_sec_context,
746 GSS_Wrap(server_qop, server_maxbuf)] token
747 as additional information.
749 The last example illustrate the optimal (round-trip wise)
750 authentication possible using this protocol.
753 7. Authentication Conditions
755 Authentication MUST NOT succeed if any one of the following
756 conditions are true:
757 o An invalid SASL token is received (i.e., length shorter than 4
758 octets).
759 o GSS_Init/Accept_sec_context() return anything other than
760 GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
761 o GSS_Wrap() returns anything other than GSS_S_COMPLETE.
762 o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There
763 can't be supplementary status codes in GS2 at this point, so any
764 indications of out of order processing or replays should be
765 fatal.)
766 o The token returned from GSS_Unwrap fail to parse correctly (e.g.,
767 too short, invalid maximum buffer size) as the expected Wrap
768 token.
769 o Local policy reject the attempt. For example, client and server
770 can't agree on qop proposal.
771 o (server-side) Authorization of client principal (i.e., src_name in
772 GSS_Acecpt_sec_context) to requested authzid failed.
775 8. GSS-API Parameters
777 The implementation MAY set any GSSAPI flags or arguments not
778 mentioned in this specification as is necessary for the
779 implementation to enforce its security policy.
783 Josefsson Expires December 28, 2006 [Page 14]
784 \f
785 Internet-Draft SASL GS2-* June 2006
788 9. Security Layer Bits
790 The security layers and their corresponding bit-masks are as follows:
792 1 No security layer
793 2 Integrity protection.
794 Sender calls GSS_Wrap with conf_flag set to FALSE
795 4 Confidentiality protection.
796 Sender calls GSS_Wrap with conf_flag set to TRUE
798 Other bit-masks may be defined in the future; bits which are not
799 understood must be negotiated off.
801 Note that SASL negotiates the maximum size of the output_message to
802 send. Implementations can use the GSS_Wrap_size_limit call to
803 determine the corresponding maximum size input_message.
806 10. Interoperability With The Gssapi Mechanism
808 The GSSAPI mechanism [11] describe how the Kerberos V5 GSS-API
809 mechanism [9] is used in SASL under the mechanism name "GSSAPI". The
810 same mechanism may also be used with the GS2 family. This causes an
811 interopability problem, which is discussed and resolved below.
813 10.1. The Interoperability problem
815 If a client (or server) only support Kerberos V5 under the "GSSAPI"
816 name and the server (or client) only support Kerberos V5 under the
817 GS2 family, the authentication negotiation will fail.
819 10.2. Resolving the problem
821 If the Kerberos V5 mechanism is supported under GS2 in a server, the
822 server SHOULD also support Kerberos V5 through the "GSSAPI"
823 mechanism, to avoid interoperability problems with older clients.
825 Reasons for violating this recommendation may include security
826 considerations regarding the absent features in the GS2 mechanism.
827 The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
828 could enable certain tunnel attacks [16].
830 10.3. Additional recommendations
832 It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
833 rather than through the "GSSAPI" mechanism, if both are available,
834 because of the additional features in the GS2 mechanism.
839 Josefsson Expires December 28, 2006 [Page 15]
840 \f
841 Internet-Draft SASL GS2-* June 2006
844 11. Mechanisms That Negotiate Other Mechanisms
846 A GSS-API mechanism that negotiate other mechanisms interact badly
847 with the SASL mechanism negotiation. There are two problems. The
848 first is an interoperability problem and the second is a security
849 concern. The problems are described and resolved below.
851 11.1. The Interoperability Problem
853 If a client implement GSS-API mechanism X, potentially negotiated
854 through a GSS-API mechanism Y, and the server also implement GSS-API
855 mechanism X negotiated through a GSS-API mechanism Z, the
856 authentication negotiation will fail.
858 11.2. Security Problem
860 If a client's policy is to first prefer GSSAPI mechanism X, then non-
861 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
862 mechanisms Y and Z but not X, then if the client attempts to
863 negotiate mechanism X by using a GSS-API mechanism that negotiate
864 other mechanisms (such as SPNEGO), it may end up using mechanism Z
865 when it should have used mechanism Y. For this reason, the use of
866 GSS-API mechanisms that negotiate other mechanisms are disallowed
867 under GS2.
869 11.3. Resolving the Problems
871 GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
872 with the GS2 SASL mechanism. This specifically exclude negotiating
873 SPNEGO [10] under GS2.
875 The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [15]
876 can be used to identify such mechanisms.
879 12. IANA Considerations
881 The IANA is advised that SASL mechanism names starting with "GS2-"
882 are reserved for SASL mechanisms which conform to this document. The
883 IANA is directed to place a statement to that effect in the sasl-
884 mechanisms registry.
895 Josefsson Expires December 28, 2006 [Page 16]
896 \f
897 Internet-Draft SASL GS2-* June 2006
900 Subject: Registration of SASL mechanism GS2-*
901 Family of SASL mechanisms: YES
902 SASL mechanism prefix: GS2-
903 Security considerations: RFC [THIS-DOC]
904 Published specification: RFC [THIS-DOC]
905 Person & email address to contact for further information:
906 Simon Josefsson <simon@josefsson.org>
907 Intended usage: COMMON
908 Owner/Change controller: iesg@ietf.org
909 Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
912 13. Security Considerations
914 Security issues are discussed throughout this memo.
916 When a server or client supports multiple authentication mechanisms,
917 each of which has a different security strength, it is possible for
918 an active attacker to cause a party to use the least secure mechanism
919 supported. There are several ways to mitigate this problem:
921 1. Integrity protected transports can be used, e.g., TLS [13]. To
922 protect against certain tunnel attacks [16] with that solution, a
923 mechanism that support channel bindings that can bind the
924 security layer (e.g., the TLS session id) to the authentication
925 is required.
926 2. A client or server which supports mechanisms of different
927 strengths should have a configurable minimum strength that it
928 will use. It is not sufficient for this minimum strength check
929 to only be on the server, since an active attacker can change
930 which mechanisms the client sees as being supported, causing the
931 client to send authentication credentials for its weakest
932 supported mechanism.
934 Because the negotiation of a GSS-API mechanism may be done in the
935 clear, it is important for the GSS-API mechanisms to be designed such
936 that an active attacker cannot obtain an authentication with weaker
937 security properties by modifying the challenges and responses.
939 The integrity protection provided by the security layer is useless to
940 the client unless the client also requests mutual authentication.
941 Therefore, a client wishing to benefit from the integrity protection
942 of a security layer MUST pass to the GSS_Init_sec_context call a
943 mutual_req_flag of TRUE.
945 When constructing the input_name_string, the client should not
946 canonicalize the server's fully qualified domain name using an
947 insecure or untrusted directory service, e.g., the Domain Name System
951 Josefsson Expires December 28, 2006 [Page 17]
952 \f
953 Internet-Draft SASL GS2-* June 2006
956 [8] without DNSSEC [14].
958 Additional security considerations are in the SASL and GSSAPI
959 specifications. Additional security considerations for the Kerberos
960 V5 GSSAPI mechanism can be found in [9]. We stress that service
961 names should not be canonicalized using an unsecured directory
962 service such as the DNS without DNSSEC.
965 14. Acknowledgements
967 This document is a revision of RFC 2222. This version was derived
968 from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov
969 with significant contributions from John G. Myers, although this
970 document has been rewritten by the current author.
972 Contributions of many members of the SASL mailing list are gratefully
973 acknowledged. In particular, ideas from Sam Hartman, Jeffrey
974 Hutzelman, and Nicolas Williams influenced the design of this
975 protocol.
978 15. Copying Conditions
980 Regarding the portion of this document that was written by Simon
981 Josefsson ("the author", for the remainder of this section), the
982 author makes no guarantees and is not responsible for any damage
983 resulting from its use. The author grants irrevocable permission to
984 anyone to use, modify, and distribute it in any way that does not
985 diminish the rights of anyone else to use, modify, and distribute it,
986 provided that redistributed derivative works do not contain
987 misleading author or version information. Derivative works need not
988 be licensed under similar terms. Contact the author to confirm which
989 sections are available under this license.
992 16. References
994 16.1. Normative References
996 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
997 Levels", BCP 14, RFC 2119, March 1997.
999 [2] Myers, J., "Simple Authentication and Security Layer (SASL)",
1000 RFC 2222, October 1997.
1002 [3] Linn, J., "Generic Security Service Application Program
1003 Interface Version 2, Update 1", RFC 2743, January 2000.
1007 Josefsson Expires December 28, 2006 [Page 18]
1008 \f
1009 Internet-Draft SASL GS2-* June 2006
1012 [4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
1013 RFC 3174, September 2001.
1015 [5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1016 draft-josefsson-rfc3548bis-04 (work in progress), May 2006.
1018 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1019 STD 63, RFC 3629, November 2003.
1021 [7] "Information Processing Systems - Open Systems Interconnection -
1022 Specification of Abstract Syntax Notation One (ASN.1)", ISO
1023 Standard 8824.
1025 16.2. Informative References
1027 [8] Mockapetris, P., "Domain names - concepts and facilities",
1028 STD 13, RFC 1034, November 1987.
1030 [9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
1031 June 1996.
1033 [10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
1034 Negotiation Mechanism", RFC 2478, December 1998.
1036 [11] Melnikov, A., "SASL GSSAPI mechanisms",
1037 draft-ietf-sasl-gssapi-03 (work in progress), September 2005.
1039 [12] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
1040 RFC 2025, October 1996.
1042 [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1043 RFC 2246, January 1999.
1045 [14] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1046 "DNS Security Introduction and Requirements", RFC 4033,
1047 March 2005.
1049 [15] Williams, N., "Extended Generic Security Service Mechanism
1050 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work
1051 in progress), October 2005.
1053 [16] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
1054 Tunneled Authentication",
1055 WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
1063 Josefsson Expires December 28, 2006 [Page 19]
1064 \f
1065 Internet-Draft SASL GS2-* June 2006
1068 Author's Address
1070 Simon Josefsson
1072 Email: simon@josefsson.org
1119 Josefsson Expires December 28, 2006 [Page 20]
1120 \f
1121 Internet-Draft SASL GS2-* June 2006
1124 Intellectual Property Statement
1126 The IETF takes no position regarding the validity or scope of any
1127 Intellectual Property Rights or other rights that might be claimed to
1128 pertain to the implementation or use of the technology described in
1129 this document or the extent to which any license under such rights
1130 might or might not be available; nor does it represent that it has
1131 made any independent effort to identify any such rights. Information
1132 on the procedures with respect to rights in RFC documents can be
1133 found in BCP 78 and BCP 79.
1135 Copies of IPR disclosures made to the IETF Secretariat and any
1136 assurances of licenses to be made available, or the result of an
1137 attempt made to obtain a general license or permission for the use of
1138 such proprietary rights by implementers or users of this
1139 specification can be obtained from the IETF on-line IPR repository at
1140 http://www.ietf.org/ipr.
1142 The IETF invites any interested party to bring to its attention any
1143 copyrights, patents or patent applications, or other proprietary
1144 rights that may cover technology that may be required to implement
1145 this standard. Please address the information to the IETF at
1146 ietf-ipr@ietf.org.
1149 Disclaimer of Validity
1151 This document and the information contained herein are provided on an
1152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1160 Copyright Statement
1162 Copyright (C) The Internet Society (2006). This document is subject
1163 to the rights, licenses and restrictions contained in BCP 78, and
1164 except as set forth therein, the authors retain all their rights.
1167 Acknowledgment
1169 Funding for the RFC Editor function is currently provided by the
1170 Internet Society.
1175 Josefsson Expires December 28, 2006 [Page 21]
1176 \f