draft-ietf-sasl-gs2-13.txt   draft-ietf-sasl-gs2-14.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB Internet-Draft SJD AB
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: November 27, 2009 Sun Microsystems Expires: December 29, 2009 Sun Microsystems
May 26, 2009 June 27, 2009
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-13 draft-ietf-sasl-gs2-14
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2009. This Internet-Draft will expire on December 29, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5
3.2. Computing mechanism names manually . . . . . . . . . . . . 6 3.2. Computing mechanism names manually . . . . . . . . . . . . 6
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7 3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7
4. SASL Authentication Exchange Message Format . . . . . . . . . 7 3.5. Which mechanism names to advertise and select . . . . . . 7
4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7 4. SASL Authentication Exchange Message Format . . . . . . . . . 8
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Channel Binding to TLS Channels . . . . . . . . . . . . . 10 5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 12 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 13
9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13
10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 12 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 14 10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 14
11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 14 10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15
11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 16 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15
12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17
12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17
13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17 13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17
13.1. The interoperability problem . . . . . . . . . . . . . . . 17 13.1. The interoperability problem . . . . . . . . . . . . . . . 17
13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 17 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18
13.3. Additional Recommendations . . . . . . . . . . . . . . . . 17 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 18
14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18 14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18
14.1. The interoperability problem . . . . . . . . . . . . . . . 18 14.1. The interoperability problem . . . . . . . . . . . . . . . 18
14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18
14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 18 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 19
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
16. Security Considerations . . . . . . . . . . . . . . . . . . . 19 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . . 20 18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . . 21 18.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Generic Security Service Application Program Interface (GSS-API) Generic Security Service Application Program Interface (GSS-API)
[RFC2743] is a framework that provides security services to [RFC2743] is a framework that provides security services to
applications using a variety of authentication "mechanisms". Simple applications using a variety of authentication mechanisms. Simple
Authentication and Security Layer (SASL) [RFC4422] is a framework to Authentication and Security Layer (SASL) [RFC4422] is a framework to
provide authentication and "security layers" for connection based provide authentication and security layers for connection based
protocols, also using a variety of mechanisms. This document protocols, also using a variety of mechanisms. This document
describes how to use a GSS-API mechanism as though it were a SASL describes how to use a GSS-API mechanism as though it were a SASL
mechanism. This facility is called GS2 -- a moniker that indicates mechanism. This facility is called GS2 -- a moniker that indicates
that this is the second GSS-API->SASL mechanism bridge. The original that this is the second GSS-API->SASL mechanism bridge. The original
GSS-API->SASL mechanism bridge was specified by [RFC2222], now GSS-API->SASL mechanism bridge was specified by [RFC2222], now
[RFC4752]; we shall sometimes refer to the original bridge as GS1 in [RFC4752]; we shall sometimes refer to the original bridge as GS1 in
this document. this document.
All GSS-API mechanisms are implicitly registered for use within SASL All GSS-API mechanisms are implicitly registered for use within SASL
by this specification. The SASL mechanisms defined in this document by this specification. The SASL mechanisms defined in this document
skipping to change at page 4, line 43 skipping to change at page 4, line 43
In particular, the current consensus of the SASL community appears to In particular, the current consensus of the SASL community appears to
be that SASL "security layers" (i.e., confidentiality and integrity be that SASL "security layers" (i.e., confidentiality and integrity
protection of application data after authentication) are too complex protection of application data after authentication) are too complex
and, since SASL applications tend to have an option to run over a and, since SASL applications tend to have an option to run over a
Transport Layer Security (TLS) [RFC5246] channel, redundant and best Transport Layer Security (TLS) [RFC5246] channel, redundant and best
replaced with channel binding. replaced with channel binding.
GS2 is designed to be as simple as possible. It adds to GSS-API GS2 is designed to be as simple as possible. It adds to GSS-API
security context token exchanges only the bare minimum to support security context token exchanges only the bare minimum to support
SASL semantics and negotiation of use of channel binding. SASL semantics and negotiation of use of channel binding.
Specifically, GS2 adds a small header (2 bytes or 3 bytes plus the Specifically, GS2 adds a small header (a few bytes plus the length of
length of the client requested SASL authorization ID (authzid)) to the client requested SASL authorization identity) to the initial GSS-
the initial context token and to the application channel binding API context token and to the application channel binding data. GS2
data, and it uses SASL mechanism negotiation to implement channel uses SASL mechanism negotiation to implement channel binding
binding negotiation. All GS2 plaintext is protected via the use of negotiation. All GS2 plaintext is protected via the use of GSS-API
GSS-API channel binding. Additionally, to simplify the channel binding. Additionally, to simplify the implementation of GS2
implementation of GS2 mechanisms for implementors who will not mechanisms for implementors who will not implement a GSS-API
implement a GSS-API framework, we compress the initial security framework, we compress the initial security context token header
context token header required by [RFC2743] (see section 3.1). required by [RFC2743] (see section 3.1).
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The document uses many terms and function names defined in [RFC2743]
as updated by [RFC5554].
3. Mechanism name 3. Mechanism name
There are two SASL mechanism names for any GSS-API mechanism used There are two SASL mechanism names for any GSS-API mechanism used
through this facility. One denotes that the server supports channel through this facility. One denotes that the server supports channel
binding. The other denotes that it does not. binding. The other denotes that it does not.
The SASL mechanism name for a GSS-API mechanism is that which is The SASL mechanism name for a GSS-API mechanism is that which is
provided by that mechanism when it was specified, if one was provided by that mechanism when it was specified, if one was
specified. This name denotes that the server does not support specified. This name denotes that the server does not support
channel binding. Add the suffix "-PLUS" and the resulting name channel binding. Add the suffix "-PLUS" and the resulting name
skipping to change at page 6, line 9 skipping to change at page 6, line 9
not relevant to this use of Base32. If any padding or non-alphabet not relevant to this use of Base32. If any padding or non-alphabet
characters are encountered, the name is not a GS2 family mechanism characters are encountered, the name is not a GS2 family mechanism
name. This name denotes that the server does not support channel name. This name denotes that the server does not support channel
binding. Add the suffix "-PLUS" and the resulting name denotes that binding. Add the suffix "-PLUS" and the resulting name denotes that
the server does support channel binding. the server does support channel binding.
3.2. Computing mechanism names manually 3.2. Computing mechanism names manually
The hash-derived GS2 SASL mechanism name may be computed manually. The hash-derived GS2 SASL mechanism name may be computed manually.
This is useful when the set of supported GSS-API mechanisms is known This is useful when the set of supported GSS-API mechanisms is known
in advance. It also obliterate the need to implement Base32, SHA-1 in advance. This obliterate the need to implement Base32, SHA-1 and
and DER in the SASL mechanism. The computed mechanism name can be DER in the SASL mechanism. The computed mechanism name can be used
used directly in the implementation, and the implementation need not directly in the implementation, and the implementation need not
concern itself with that the mechanism is part of a mechanism family. concern itself with that the mechanism is part of a mechanism family.
3.3. Examples 3.3. Examples
The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The
ASN.1 DER encoding of the OID, including the tag and length, is (in ASN.1 DER encoding of the OID, including the tag and length, is (in
hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER
encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
27 86 61 ad. Convert the first 7 octets to binary, drop the last 27 86 61 ad. Convert the first 7 octets to binary, drop the last
bit, and re-group them in groups of 5, and convert them back to bit, and re-group them in groups of 5, and convert them back to
skipping to change at page 7, line 37 skipping to change at page 7, line 37
mechanism name. mechanism name.
3.4. Grandfathered mechanism names 3.4. Grandfathered mechanism names
Some older GSS-API mechanisms were not specified with a SASL GS2 Some older GSS-API mechanisms were not specified with a SASL GS2
mechanism name. Using a shorter name can be useful nonetheless. We mechanism name. Using a shorter name can be useful nonetheless. We
specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5 specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5
mechanism, to be used as if the original specification documented it. mechanism, to be used as if the original specification documented it.
See Section 15. See Section 15.
4. SASL Authentication Exchange Message Format 3.5. Which mechanism names to advertise and select
4.1. SASL Messages Servers SHOULD advertise both non-PLUS and the PLUS-variant of a GS2
mechanism name. If the server cannot support channel binding, it MAY
advertise only the non-PLUS variant. If the server would never
succeed authentication of the non-PLUS variant due to policy reasons,
it MAY advertise only the PLUS-variant.
If the client negotiates mechanisms then clients MUST select the
PLUS-variant if offered by the server. Otherwise, if the client does
not negotiate mechanisms then it MUST use the non-PLUS variant.
4. SASL Authentication Exchange Message Format
During the SASL authentication exchange for GS2, a number of messages During the SASL authentication exchange for GS2, a number of messages
following the following format is sent between the client and server. following the following format is sent between the client and server.
This number is the same as the number of context tokens that the GSS- On success, this number is the same as the number of context tokens
API mechanism would normally require in order to establish a security that the GSS-API mechanism would normally require in order to
context (or to fail to do so). establish a security context. On failures, the exchange can be
terminated early by any party.
Note that when using a GS2 mechanism the SASL client is always a GSS- When using a GS2 mechanism the SASL client is always a GSS-API
API initiator and the SASL server is always a GSS-API acceptor. Thus initiator and the SASL server is always a GSS-API acceptor. The
the SASL client calls GSS_Init_sec_context and the server calls client calls GSS_Init_sec_context and the server calls
GSS_Accept_sec_context. GSS_Accept_sec_context.
All the SASL authentication messages exchanged are exactly the same All the SASL authentication messages exchanged are exactly the same
as the security context tokens of the GSS-API mechanism, except for as the security context tokens of the GSS-API mechanism, except for
the initial security context token. the initial security context token.
The client and server MAY send GSS-API error tokens (tokens output by The client and server MAY send GSS-API error tokens (tokens output by
GSS_Init_sec_context() or GSS_Accept_sec_context() when the major GSS_Init_sec_context() or GSS_Accept_sec_context() when the major
status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED). status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED).
As this indicate an error condition, after sending the token, the As this indicate an error condition, after sending the token, the
skipping to change at page 8, line 42 skipping to change at page 9, line 21
UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4 UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
saslname = 1*(UTF8-char-safe / "=2C" / "=3D") saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
gs2-authzid = "a=" saslname gs2-authzid = "a=" saslname
;; GS2 has to transport an authzid since ;; GS2 has to transport an authzid since
;; the GSS-API has no equivalent ;; the GSS-API has no equivalent
gs2-nonstd-flag = "F" gs2-nonstd-flag = "F"
;; "F" means the mechanism is not a ;; "F" means the mechanism is not a
;; standard GSS-API mechanism in that the ;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing ;; RFC2743 section 3.1 header was missing
gs2-cb-flag = "p" / "n" / "y" cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056 section 7
gs2-cb-flag = "p=" cb-name / "n" / "y"
;; GS2 channel binding (CB) flag ;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB ;; "p" -> client supports and used CB
;; "n" -> client does not support CB ;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server ;; "y" -> client supports CB, thinks the server
;; does not ;; does not
gs2-header = [gs2-nonstd-flag] gs2-cb-flag [gs2-authzid] "," gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header. ;; The GS2 header is gs2-header.
When the "gs2-nonstd-flag" flag is present, the client did not find/ When the "gs2-nonstd-flag" flag is present, the client did not find/
remove a [RFC2743] section 3.1 token header from the initial token remove a [RFC2743] section 3.1 token header from the initial token
returned by GSS_Init_sec_context. This signals to the server that it returned by GSS_Init_sec_context. This signals to the server that it
MUST NOT re-add the data that is normally removed by the client. MUST NOT re-add the data that is normally removed by the client.
The "gs2-cb-flag" signals the channel binding mode. One of "p", "n", The "gs2-cb-flag" signals the channel binding mode. One of "p", "n",
or "y" is used. A "p" means the client supports and used a channel or "y" is used. A "p" means the client supports and used a channel
binding. A "n" means that the client does not support channel binding, and the name of the channel binding type is indicated. A
binding. A "y" means the client supports channel binding, but "n" means that the client does not support channel binding. A "y"
believes the server does not, so it did not use a channel binding. means the client supports channel binding, but believes the server
See the next section for more details. does not support it, so it did not use a channel binding. See the
next section for more details.
The "gs2-authzid" holds the SASL authorization identity. It is The "gs2-authzid" holds the SASL authorization identity. It is
encoded using UTF-8 [RFC3629] with three exceptions: encoded using UTF-8 [RFC3629] with three exceptions:
o The NUL characters is forbidden as required by section 3.4.1 of o The NUL characters is forbidden as required by section 3.4.1 of
[RFC4422]. [RFC4422].
o The server MUST replace any "," (comma) in the string with "=2C". o The server MUST replace any "," (comma) in the string with "=2C".
o The server MUST replace any "=" (equals) in the string with "=3D". o The server MUST replace any "=" (equals) in the string with "=3D".
If a server sends a string that does not conform to this syntax, the
client MUST reject authentication.
5. Channel Bindings 5. Channel Bindings
If the server supports channel binding then it MUST list both forms If the client does not support channel binding then it MUST use a "n"
of the SASL mechanism name for each GSS-API mechanism supported via gs2-cb-flag.
GS2 (i.e., GSS-API mechanisms that support channel binding).
If the client supports channel binding and the server does not (i.e., If the client supports channel binding and the server does not appear
the server did not advertise the -PLUS names) then the client MUST to (i.e., the client did not see a -PLUS name) then the client MUST
either fail authentication or it MUST set the channel binding flag in either fail authentication or it MUST chose the non-PLUS mechanism
the GS2 initial security context token to "y" and MUST NOT include name and use a "y" gs2-cb-flag.
application channel binding data in the GSS-API channel binding input
to GSS_Init_sec_context.
If the client supports channel binding and the server also does then If the client supports channel binding and the server appears to
the client MUST set the channel binding flag in the GS2 initial support it (i.e., the client see a -PLUS name) then the client MUST
security context token to "p" and MUST include application channel use a "p" gs2-cb-flag to indicate the channel binding type it is
binding data in the GSS-API channel binding input to using.
GSS_Init_sec_context. This is done by pre-pending the gs2-header to
the application's channel binding data. If the application did not
provide channel binding data then the GS2 header is used as though it
were application-provided channel binding data.
If the client does not support channel binding then it MUST set the The client generate the chan_bindings input parameter for
channel binding flag in the GS2 initial security context token to "n" GSS_Init_sec_context as described below.
and MUST NOT include application channel binding data in the GSS-API
channel binding input to GSS_Init_sec_context.
Upon receipt of the initial authentication message the server checks Upon receipt of the initial authentication message the server checks
the channel binding flag in the GS2 header and constructs a channel the gs2-cb-flag in the GS2 header and constructs a chan_bindings
binding data input for GSS_Accept_sec_context accordingly. If the parameter for GSS_Accept_sec_context as described below. If the
client channel binding flag was "n" then the server MUST NOT include client channel binding flag was "y" and the server did advertise
application channel binding data in the GSS-API channel binding input support for channel bindings then the server MUST fail
to GSS_Accept_sec_context. If the client channel binding flag was authentication. If the client channel binding flag was "p" and the
"y" and the server does support channel binding then the server MUST server does not support the indicated channel binding type then the
fail authentication. If the client channel binding flag was "p" the server MUST fail authentication.
server MUST include application channel binding data in the GSS-API
channel binding input to GSS_Accept_sec_context.
For more discussions of channel bindings, and the syntax of the For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [RFC5056]. channel binding data for various security protocols, see [RFC5056].
5.1. Channel Binding to TLS Channels 5.1. Content of GSS-CHANNEL-BINDINGS structure
If an external TLS channel is to be bound into the GS2 The calls to GSS_Init_sec_context and GSS_Accept_sec_context takes a
authentication, and if the channel was established using a X.509 chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS
[RFC5280] server certificate to authenticate the server, then the GS2 structure [RFC5554].
client and server MUST use the 'tls-server-end-point' channel binding
type. See the IANA Channel Binding Types registry.
If an external TLS channel is to be bound into the GS2 The initiator-address-type and acceptor-address-type fields of the
authentication, and if the channel was established either without the GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-
use of any X.509 server certificate to authenticate the server, or address and acceptor-address fields MUST be the empty string.
with a non X.509 server certificate, then the GS2 client and server
MUST use the 'tls-unique' channel binding type. The application-data field MUST be set to the gs2-header concatenated
with, when a gs2-cb-flag of "p" is used, the application's channel
binding data (if any).
5.2. Default Channel Binding
A default channel binding type agreement process for all SASL
application protocols that do not provide their own channel binding
type agreement is provided as follows.
Clients and servers MUST implement the "tls-unique" [tls-unique]
channel binding type. Clients and servers SHOULD choose the highest-
layer/innermost end-to-end TLS channel as the channel to bind to.
Clients SHOULD choose the tls-unique channel binding type.
Conversely, clients MAY choose a different channel binding type based
on user input, configuration, or a future, as-yet undefined channel
binding type negotiation protocol. Servers MUST choose the channel
binding type indicated by the client, if they support it.
6. Examples 6. Examples
Example #1: a one round-trip GSS-API context token exchange, no Example #1: a one round-trip GSS-API context token exchange, no
channel binding, optional authzid given. channel binding, optional authzid given.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: na=someuser,<initial context token with standard C: n,a=someuser,<initial context token with standard
header removed> header removed>
S: Send reply context token as is S: Send reply context token as is
C: Empty message C: Empty message
S: Outcome of authentication exchange S: Outcome of authentication exchange
Example #2: a one and one half round-trip GSS-API context token Example #2: a one and one half round-trip GSS-API context token
exchange. exchange, no channel binding.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: na=someuser,<initial context token with standard C: n,<initial context token with standard
header removed> header removed>
S: Send reply context token as is S: Send reply context token as is
C: Send reply context token as is C: Send reply context token as is
S: Outcome of authentication exchange S: Outcome of authentication exchange
Example #3: a two round-trip GSS-API context token exchange, no Example #3: a two round-trip GSS-API context token exchange, no
standard token header. channel binding, no standard token header.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: Fna=someuser,<initial context token without C: F,n,<initial context token without
standard header> standard header>
S: Send reply context token as is S: Send reply context token as is
C: Send reply context token as is C: Send reply context token as is
S: Send reply context token as is S: Send reply context token as is
C: Empty message C: Empty message
S: Outcome of authentication exchange S: Outcome of authentication exchange
Example #4: using channel binding Example #4: using channel binding, optional authzid given.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: pa=someuser,<initial context token with standard C: p=tls-unique,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
...
Example #5: using channel binding.
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,<initial context token with standard
header removed>
S: Send reply context token as is
...
Example #6: using non-standard channel binding (requires out-of-band
negotiation).
C: Request authentication exchange
S: Empty Challenge
C: p=tls-server-end-point,<initial context token with standard
header removed> header removed>
S: Send reply context token as is S: Send reply context token as is
... ...
Example #7: client supports channel bindings but server does not,
optional authzid given.
C: Request authentication exchange
S: Empty Challenge
C: y,a=someuser,<initial
context token with standard header removed>
S: Send reply context token as is
...
GSS-API authentication is always initiated by the client. The SASL GSS-API authentication is always initiated by the client. The SASL
framework allows either the client and server to initiate framework allows either the client and server to initiate
authentication. In GS2 the server will send an initial empty authentication. In GS2 the server will send an initial empty
challenge (zero byte string) if it has not yet received a token from challenge (zero byte string) if it has not yet received a token from
the client. See section 3 of [RFC4422]. the client. See section 3 of [RFC4422].
7. Authentication Conditions 7. Authentication Conditions
Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following
conditions are true: conditions are true:
o GSS_Init/Accept_sec_context return anything other than o GSS_Init/Accept_sec_context return anything other than
GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
o If the client's initial GS2 header does not match the ABNF.
o In particular, if the initial character of the client message is
anything except "F", "p", "n", or "y".
o If the client's GS2 channel binding flag was "y" and the server o If the client's GS2 channel binding flag was "y" and the server
supports channel binding. supports channel bindings.
o If the client's GS2 channel binding flag was "p" and the server
does not support the indicated channel binding.
o If the client requires use of channel binding and the server did o If the client requires use of channel binding and the server did
not advertise support for channel binding. not advertise support for channel binding.
o Authorization of client principal (i.e., src_name in o Authorization of client principal (i.e., src_name in
GSS_Accept_sec_context) to requested authzid failed. GSS_Accept_sec_context) to requested authzid failed.
o If the client is not authorized to the requested authzid or an o If the client is not authorized to the requested authzid or an
authzid could not be derived from the client's initiator principal authzid could not be derived from the client's initiator principal
name. name.
8. GSS-API Parameters 8. GSS-API Parameters
skipping to change at page 16, line 34 skipping to change at page 17, line 34
Mechanism specific status code. Mechanism specific status code.
Function value: GSS status code Function value: GSS status code
GSS_S_COMPLETE Successful completion GSS_S_COMPLETE Successful completion
GSS_S_BAD_MECH The desired_mech OID is unsupported GSS_S_BAD_MECH The desired_mech OID is unsupported
12. Security Layers 12. Security Layers
GS2 does not currently support SASL security layers. Applications GS2 does not support SASL security layers. Applications that need
that need integrity protection or confidentiality and integrity integrity or confidentiality protection can use either channel
protection MUST use either channel binding to a secure external binding to a secure external channel or another SASL mechanism that
channel or a SASL mechanism that does provide security layers. does provide security layers.
NOTE WELL: the GS2 client's first authentication message MUST always
start with "F", "p", "n" or "y", otherwise the server MUST fail
authentication. This will allow us to add support for security
layers in the future if it were to become necessary. Note that
adding security layer support to GS2 must not break existing SASL/GS2
applications, which can be accomplished by making security layers
optional.
[A sketch of how to add sec layer support... Add a way for the
client to: a) make an offer of sec layers and max buffer, b) make an
opportunistic selection of sec layer and buffer size, both in the
first client authentication message, and starting with a character
other than "F", "n", "y" or "p". The server could accept the
opportunistic proposal (reply token prefixed with a byte indicating
acceptance) or reject it along with an indication of the server's
acceptable sec layers and max buffer size. In the latter case the
GSS-API security context token exchange must be abandoned and
recommenced, although this would be a detail of the GS2 bridge not
exposed to the SASL application. The negotiation would be protected
via GSS channel binding, as with the rest of GS2.]
13. Interoperability with the SASL GSSAPI mechanism 13. Interoperability with the SASL GSSAPI mechanism
The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
under the name GSSAPI, see GSSAPI mechanism [RFC4752]. The Kerberos under the name GSSAPI, see GSSAPI mechanism [RFC4752]. The Kerberos
V5 mechanism may also be used with the GS2 family. This causes an V5 mechanism may also be used with the GS2 family. This causes an
interoperability problem, which is discussed and resolved below. interoperability problem, which is discussed and resolved below.
13.1. The interoperability problem 13.1. The interoperability problem
skipping to change at page 18, line 37 skipping to change at page 19, line 14
use of GSS-API mechanisms that negotiate other mechanisms are use of GSS-API mechanisms that negotiate other mechanisms are
disallowed under GS2. disallowed under GS2.
14.3. Resolving the problems 14.3. Resolving the problems
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
be used as a GS2 mechanism. To make this easier for SASL be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST
NOT choose the SPNEGO mechanism under any circumstances. [What about NOT choose the SPNEGO mechanism under any circumstances.
SASL apps that don't do mechanism negotiation? Probably none exist.
But if any did then presumably it would OK to use the SPNEGO
mechanism, no? -Nico]
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech
[I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
mechanisms. mechanisms.
15. IANA Considerations 15. IANA Considerations
The IANA is advised that SASL mechanism names starting with "GS2-"
are reserved for SASL mechanisms which conform to this document. The
IANA is directed to place a statement to that effect in the sasl-
mechanisms registry.
The IANA is further advised that GS2 SASL mechanism names MUST NOT
end in "-PLUS" except as a version of another mechanism name simply
suffixed with "-PLUS".
The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121] The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121]
[RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS". [RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".
The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be
"SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL "SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL
"SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are
provided as a convenience for SASL library implementors. provided as a convenience for SASL library implementors.
The IANA is advised that SASL mechanism names starting with "GS2-"
are reserved for SASL mechanisms which conform to this document. The
IANA is directed to place a statement to that effect in the sasl-
mechanisms registry.
The IANA is further advised that SASL mechanisms MUST NOT end in
"-PLUS" except as a version of another mechanism name simply suffixed
with "-PLUS".
Subject: Registration of SASL mechanism GS2-* Subject: Registration of SASL mechanism GS2-*
SASL mechanism prefix: GS2- SASL mechanism prefix: GS2-
Security considerations: RFC [THIS-DOC] Security considerations: RFC [THIS-DOC]
Published specification: RFC [THIS-DOC] Published specification: RFC [THIS-DOC]
Person & email address to contact for further information: Person & email address to contact for further information:
Simon Josefsson <simon@josefsson.org> Simon Josefsson <simon@josefsson.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: iesg@ietf.org Owner/Change controller: iesg@ietf.org
Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
skipping to change at page 20, line 23 skipping to change at page 20, line 48
When constructing the input_name_string for GSS_Import_name with the When constructing the input_name_string for GSS_Import_name with the
GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT
canonicalize the server's fully qualified domain name using an canonicalize the server's fully qualified domain name using an
insecure or untrusted directory service, such as the Domain Name insecure or untrusted directory service, such as the Domain Name
System [RFC1034] without DNSSEC [RFC4033]. System [RFC1034] without DNSSEC [RFC4033].
GS2 does not directly use any cryptographic algorithms, therefore it GS2 does not directly use any cryptographic algorithms, therefore it
is automatically "algorithm agile", or, as agile as the GSS-API is automatically "algorithm agile", or, as agile as the GSS-API
mechanisms that are available for use in SASL applications via GS2. mechanisms that are available for use in SASL applications via GS2.
The exception is the use of SHA-1 for deriving SASL mechanism names,
but no cryptographic properties are required. The required property
is that the truncated output for distinct inputs are different for
practical input values.
GS2 does not protect against downgrade attacks of channel binding
types. The complexities of negotiation a channel binding type, and
handling down-grade attacks in that negotiation, was intentionally
left out of scope for this document.
The security considerations of SASL [RFC4422], the GSS-API [RFC2743], The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
channel binding [RFC5056], any external channels (such as TLS, channel binding [RFC5056], any external channels (such as TLS,
[RFC5246], channel binding types (see the IANA channel binding type [RFC5246], channel binding types (see the IANA channel binding type
registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism
[RFC4121] [RFC1964]), may also apply. [RFC4121] [RFC1964]), also apply.
17. Acknowledgements 17. Acknowledgements
The history of GS2 can be traced to the "GSSAPI" mechanism originally The history of GS2 can be traced to the "GSSAPI" mechanism originally
specified by RFC2222. This document was derived from specified by RFC2222. This document was derived from
draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
significant contributions from John G. Myers, although the majority significant contributions from John G. Myers, although the majority
of this document has been rewritten by the current authors. of this document has been rewritten by the current authors.
Contributions of many members of the SASL mailing list are gratefully Contributions of many members of the SASL mailing list are gratefully
skipping to change at page 21, line 26 skipping to change at page 22, line 12
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5554] Williams, N., "Clarifications and Extensions to the
Generic Security Service Application Program Interface
(GSS-API) for the Use of Channel Bindings", RFC 5554,
May 2009.
[CCITT.X690.2002] [CCITT.X690.2002]
International International Telephone and Telegraph International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules: Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002. (DER)", CCITT Recommendation X.690, July 2002.
[tls-unique]
Zhu, L., "Registration of TLS unique channel binding
(generic)", July 2008.
18.2. Informative References 18.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996. RFC 1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996. (SPKM)", RFC 2025, October 1996.
skipping to change at page 22, line 19 skipping to change at page 23, line 15
Program Interface (GSS-API) Negotiation Mechanism", Program Interface (GSS-API) Negotiation Mechanism",
RFC 4178, October 2005. RFC 4178, October 2005.
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
Authentication and Security Layer (SASL) Mechanism", Authentication and Security Layer (SASL) Mechanism",
RFC 4752, November 2006. RFC 4752, November 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[I-D.ietf-sasl-scram] [I-D.ietf-sasl-scram]
Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams,
"Salted Challenge Response (SCRAM) SASL Mechanism", "Salted Challenge Response (SCRAM) SASL Mechanism",
draft-ietf-sasl-scram-00 (work in progress), May 2009. draft-ietf-sasl-scram-01 (work in progress), May 2009.
[I-D.ietf-kitten-extended-mech-inquiry] [I-D.ietf-kitten-extended-mech-inquiry]
Williams, N., "Extended Generic Security Service Mechanism Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06
(work in progress), April 2009. (work in progress), April 2009.
[mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication", in Tunneled Authentication",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html. WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
 End of changes. 49 change blocks. 
154 lines changed or deleted 196 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/