draft-ietf-sasl-gs2-20.txt   rfc5801.txt 
Network Working Group S. Josefsson Internet Engineering Task Force (IETF) S. Josefsson
Internet-Draft SJD AB Request for Comments: 5801 SJD AB
Intended status: Standards Track N. Williams Category: Standards Track N. Williams
Expires: July 13, 2010 Sun Microsystems ISSN: 2070-1721 Oracle
January 9, 2010 July 2010
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using Generic Security Service Application Program Interface (GSS-API)
draft-ietf-sasl-gs2-20 Mechanisms in Simple Authentication and Security Layer (SASL):
The GS2 Mechanism Family
Abstract Abstract
This document describes how to use a Generic Security Service This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple Application Program Interface (GSS-API) mechanism in the Simple
Authentication and Security Layer (SASL) framework. This is done by Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous "SASL/ family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of authentication phase in some cases, and supports negotiable use of
channel binding. Only GSS-API mechanisms that support channel channel binding. Only GSS-API mechanisms that support channel
binding are supported. binding and mutual authentication are supported.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 13, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5801.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................4
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document ...............................5
3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Mechanism Name ..................................................5
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4 3.1. Generating SASL Mechanism Names from GSS-API OIDs ..........5
3.2. Computing mechanism names manually . . . . . . . . . . . . 5 3.2. Computing Mechanism Names Manually .........................6
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Examples ...................................................6
3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 6 3.4. Grandfathered Mechanism Names ..............................7
4. SASL Authentication Exchange Message Format . . . . . . . . . 6 4. SASL Authentication Exchange Message Format .....................8
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 5. Channel Bindings ...............................................10
5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10 5.1. Content of GSS-CHANNEL-BINDINGS Structure .................11
5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10 5.2. Default Channel Binding ...................................12
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Examples .......................................................12
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 12 7. Authentication Conditions ......................................14
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13 8. GSS-API Parameters .............................................15
9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Naming .........................................................15
10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 14 10. GSS_Inquire_SASLname_for_mech Call ............................15
10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15 10.1. gss_inquire_saslname_for_mech ............................16
11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15 11. GSS_Inquire_mech_for_SASLname Call ............................18
11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17 11.1. gss_inquire_mech_for_saslname ............................19
12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17 12. Security Layers ...............................................20
13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17 13. Interoperability with the SASL GSSAPI Mechanism ...............20
13.1. The interoperability problem . . . . . . . . . . . . . . . 17 13.1. The Interoperability Problem .............................20
13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18 13.2. Resolving the Problem ....................................20
13.3. Additional Recommendations . . . . . . . . . . . . . . . . 18 13.3. Additional Recommendations ...............................20
14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18 14. GSS-API Mechanisms That Negotiate Other Mechanisms ............21
14.1. The interoperability problem . . . . . . . . . . . . . . . 18 14.1. The Interoperability Problem .............................21
14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18 14.2. Security Problem .........................................21
14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 19 14.3. Resolving the Problems ...................................21
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15. IANA Considerations ...........................................22
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 16. Security Considerations .......................................22
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 17. Acknowledgements ..............................................24
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 18. References ....................................................24
18.1. Normative References . . . . . . . . . . . . . . . . . . . 21 18.1. Normative References .....................................24
18.2. Informative References . . . . . . . . . . . . . . . . . . 22 18.2. Informative References ...................................25
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
are known as the GS2 family of mechanisms. are known as the GS2 family of mechanisms.
The GS1 bridge failed to gain wide deployment for any GSS-API The GS1 bridge failed to gain wide deployment for any GSS-API
mechanism other than "The Kerberos V5 GSS-API mechanism" [RFC1964] mechanism other than "The Kerberos Version 5 GSS-API Mechanism"
[RFC4121], and has a number of problems that led us to desire a new [RFC1964] [RFC4121], and has a number of problems that led us to
bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 desire a new bridge. Specifically, a) GS1 was not round-trip
did not support channel binding [RFC5056]. These problems and the optimized and b) GS1 did not support channel binding [RFC5056].
opportunity to create the next SASL password-based mechanism, Salted These problems and the opportunity to create the next SASL password-
Challenge Response (SCRAM) SASL and GSS-API Mechanism based mechanism, "Salted Challenge Response Authentication Mechanism
[I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL (SCRAM) SASL and GSS-API Mechanisms" [RFC5802], as a GSS-API
applications via GS2, provide the motivation for GS2. mechanism used by SASL applications via GS2, provide the motivation
for GS2.
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 redundant because SASL applications tend to have an option to run and redundant because SASL applications tend to have an option to run
over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL
security layers is best replaced with channel binding to a TLS security layers is best replaced with channel binding to a TLS
channel. channel.
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 (a few bytes plus the length of Specifically, GS2 adds a small header (a few bytes plus the length of
the client requested SASL authorization identity) to the initial GSS- the client-requested SASL authorization identity) to the initial GSS-
API context token and to the application channel binding data. GS2 API context token and to the application channel binding data. GS2
uses SASL mechanism negotiation to implement channel binding uses SASL mechanism negotiation to implement channel binding
negotiation. All GS2 plaintext is protected via the use of GSS-API negotiation. Security-relevant GS2 plaintext is protected via the
channel binding. Additionally, to simplify the implementation of GS2 use of GSS-API channel binding. Additionally, to simplify the
mechanisms for implementors who will not implement a GSS-API implementation of GS2 mechanisms for implementors who will not
framework, we compress the initial security context token header implement a GSS-API framework, we compress the initial security
required by [RFC2743] (see section 3.1). context token header required by [RFC2743], Section 3.1.
2. Conventions used in this document GS2 does not protect any plaintext exchanged outside GS2, such as
SASL mechanism negotiation plaintext, or application messages
following authentication. But using channel binding to a secure
channel over which all SASL and application plaintext is sent will
cause all that plaintext to be authenticated.
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] The document uses many terms and function names defined in [RFC2743],
as updated by [RFC5554]. 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
denotes that the server does support channel binding. SASL denotes that the server does support channel binding. SASL
implementations can use the GSS_Inquire_SASLname_for_mech call (see implementations can use the GSS_Inquire_SASLname_for_mech call (see
below) to query for the SASL mechanism name of a GSS-API mechanism. below) to query for the SASL mechanism name of a GSS-API mechanism.
If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
implementation needs some other mechanism to map mechanism OIDs to implementation needs some other mechanism to map mechanism Object
SASL names internally. In this case, the implementation can only Identifiers (OIDs) to SASL names internally. In this case, the
support the mechanisms for which it knows the SASL name. If the implementation can only support the mechanisms for which it knows the
GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation SASL name. If GSS_Inquire_SASLname_for_mech() fails and the GS2
cannot map the OID to a SASL mechanism name using some other means, implementation cannot map the OID to a SASL mechanism name via some
it cannot use the particular GSS-API mechanism since it does not know other means, then the GS2 implementation MUST NOT use the given GSS-
its SASL mechanism name. API mechanism.
3.1. Generating SASL mechanism names from GSS-API OIDs 3.1. Generating SASL Mechanism Names from GSS-API OIDs
For GSS-API mechanisms whose SASL names are not defined together with For GSS-API mechanisms whose SASL names are not defined together with
the GSS-API mechanism or in this document, the SASL mechanism name is the GSS-API mechanism or in this document, the SASL mechanism name is
concatenation of the string "GS2-" and the Base32 encoding [RFC4648] concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
(with an upper case alphabet) of the first 55 bits of the binary (with an uppercase alphabet) of the first 55 bits of the binary SHA-1
SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER hash [FIPS.180-1.1995] string computed over the ASN.1 DER encoding
encoding [CCITT.X690.2002], including the tag and length octets, of [CCITT.X690.2002], including the tag and length octets, of the GSS-
the GSS-API mechanism's Object Identifier. The Base32 rules on API mechanism's Object Identifier. The Base32 rules on padding
padding characters and characters outside of the Base32 alphabet are characters and characters outside of the Base32 alphabet are not
not relevant to this use of Base32. If any padding or non-alphabet 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.
A GS2 mechanism that has a non-OID-derived SASL mechanism name is A GS2 mechanism that has a non-OID-derived SASL mechanism name is
said to have a "user friendly SASL mechanism name". said to have a "user-friendly SASL mechanism name".
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. This eliminates the need to implement Base32, SHA-1 and in advance. This eliminates the need to implement Base32, SHA-1, and
DER in the SASL mechanism. The computed mechanism name can be used DER in the SASL mechanism. The computed mechanism name can be used
directly in the implementation, and the implementation need not be directly in the implementation, and the implementation need not be
concerned if the mechanism is part of a mechanism family. concerned if 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 Simple Public-Key GSS-API Mechanism (SPKM-1)
ASN.1 DER encoding of the OID, including the tag and length, is (in [RFC2025] is 1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID,
hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER including the tag and length, is (in hex) 06 07 2b 06 01 05 05 01 01.
encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 The SHA-1 hash of the ASN.1 DER encoding is (in hex) 1c f8 f4 2b 5a
27 86 61 ad. Convert the first 7 octets to binary, drop the last 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad. Convert the first 7
bit, and re-group them in groups of 5, and convert them back to octets to binary, drop the last bit, and re-group them in groups of
decimal, which results in these computations: 5, and convert them back to decimal, which results in these
computations:
hex: hex:
1c f8 f4 2b 5a 9f 80 1c f8 f4 2b 5a 9f 80
binary: binary:
00011100 11111000 11110100 00101011 01011010 00011100 11111000 11110100 00101011 01011010
10011111 1000000 10011111 1000000
binary in groups of 5: binary in groups of 5:
00011 10011 11100 01111 01000 01010 11010 11010 00011 10011 11100 01111 01000 01010 11010 11010
skipping to change at page 6, line 43 skipping to change at page 7, line 4
binary: binary:
00011100 11111000 11110100 00101011 01011010 00011100 11111000 11110100 00101011 01011010
10011111 1000000 10011111 1000000
binary in groups of 5: binary in groups of 5:
00011 10011 11100 01111 01000 01010 11010 11010 00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000 10011 11110 00000
decimal of each group: decimal of each group:
3 19 28 15 8 10 26 26 19 30 0 3 19 28 15 8 10 26 26 19 30 0
base32 encoding: base32 encoding:
D T 4 P I K 2 2 T 6 A D T 4 P I K 2 2 T 6 A
The last step translates each decimal value using table 3 in Base32 The last step translates each decimal value using table 3 in Base32
[RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI [RFC4648]. Thus, the SASL mechanism name for the SPKM-1 GSSAPI
mechanism is "GS2-DT4PIK22T6A". mechanism is "GS2-DT4PIK22T6A".
The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop 93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop
the last bit, and re-group them in groups of 5, and convert them back the last bit, and re-group them in groups of 5, and convert them back
to decimal, which results in these computations: to decimal, which results in these computations:
hex: hex:
skipping to change at page 7, line 28 skipping to change at page 7, line 36
10000 01011 01001 00111 00110 01001 01011 10110 10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011 01101 01111 01011
decimal of each group: decimal of each group:
16 11 9 7 6 9 11 22 13 15 11 16 11 9 7 6 9 11 22 13 15 11
base32 encoding: base32 encoding:
Q L J H G J L W N P L Q L J H G J L W N P L
The last step translates each decimal value using table 3 in Base32 The last step translates each decimal value using table 3 in Base32
[RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI [RFC4648]. Thus, the SASL mechanism name for the Kerberos V5 GSS-API
mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next
section assigns the Kerberos V5 mechanism a non-hash-derived section assigns the Kerberos V5 mechanism a non-hash-derived
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 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 are sent between the client and
On success, this number is the same as the number of context tokens server. On success, this number is the same as the number of context
that the GSS-API mechanism would normally require in order to tokens that the GSS-API mechanism would normally require in order to
establish a security context. On failures, the exchange can be establish a security context. On failures, the exchange can be
terminated early by any party. terminated early by any party.
When using a GS2 mechanism the SASL client is always a GSS-API When using a GS2 mechanism the SASL client is always a GSS-API
initiator and the SASL server is always a GSS-API acceptor. The initiator and the SASL server is always a GSS-API acceptor. The
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 indicates an error condition, after sending the token, the As this indicates an error condition, after sending the token, the
sending side should fail the authentication. sending side should fail the authentication.
The initial security context token is modified as follows: The initial security context token is modified as follows:
o The initial context token header (see section 3.1 of [RFC2743])
o The initial context token header (see Section 3.1 of [RFC2743])
MUST be removed if present. If the header is not present, the MUST be removed if present. If the header is not present, the
client MUST send a "gs2-nonstd-flag" flag (see below). On the client MUST send a "gs2-nonstd-flag" flag (see below). On the
server side this header MUST be recomputed and restored prior to server side, this header MUST be recomputed and restored prior to
passing the token to GSS_Accept_sec_context, except when the "gs2- passing the token to GSS_Accept_sec_context, except when the "gs2-
nonstd-flag" is sent. nonstd-flag" is sent.
o A GS2 header MUST be prefixed to the resulting initial context o A GS2 header MUST be prefixed to the resulting initial context
token. This header has the form "gs2-header" given below in ABNF token. This header has the form "gs2-header" given below in ABNF
[RFC5234]. [RFC5234].
The figure below describes the permissible attributes, their use, and The figure below describes the permissible attributes, their use, and
the format of their values. All attribute names are single US-ASCII the format of their values. All attribute names are single US-ASCII
letters and are case-sensitive. letters and are case sensitive.
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except ;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",". ;; NUL, "=", and ",".
UTF8-2 = <as defined in RFC 3629 (STD 63)> UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)> UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)> UTF8-4 = <as defined in RFC 3629 (STD 63)>
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 ;; RFC 2743, Section 3.1 header was missing
cb-name = 1*(ALPHA / DIGIT / "." / "-") cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056 section 7 ;; See RFC 5056, Section 7.
gs2-cb-flag = ("p=" cb-name) / "n" / "y" 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 token header ([RFC2743] section 3.1) from the initial token remove a token header ([RFC2743], Section 3.1) 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, and the name of the channel binding type is indicated. A binding, and the name of the channel binding type is indicated. An
"n" means that the client does not support channel binding. A "y" "n" means that the client does not support channel binding. A "y"
means the client supports channel binding, but believes the server means the client supports channel binding, but believes the server
does not support it, so it did not use a channel binding. See the does not support it, so it did not use a channel binding. See the
next section for more details. 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 character is forbidden as required by section 3.4.1 of o The NUL character 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".
Upon receipt of this value the server verifies its correctness
Upon receipt of this value, the server verifies its correctness
according to the used SASL protocol profile. Failed verification according to the used SASL protocol profile. Failed verification
results in a failed authentication exchange. results in a failed authentication exchange.
5. Channel Bindings 5. Channel Bindings
GS2 supports channel binding to external secure channels, such as GS2 supports channel binding to external secure channels, such as
TLS. Clients and servers may or may not support channel binding, TLS. Clients and servers may or may not support channel binding;
therefore the use of channel binding is negotiable. GS2 does not therefore, the use of channel binding is negotiable. However, GS2
provide security layers, however, therefore it is imperative that GS2 does not provide security layers; therefore, it is imperative that
provide integrity protection for the negotiation of channel binding. GS2 provide integrity protection for the negotiation of channel
binding.
Use of channel binding is negotiated as follows: Use of channel binding is negotiated as follows:
o Servers SHOULD advertise both non-PLUS and the PLUS-variant of
each GS2 mechanism name. If the server cannot support channel o Servers that support the use of channel binding SHOULD advertise
binding, it MAY advertise only the non-PLUS variant. If the both the non-PLUS and PLUS-variant of each GS2 mechanism name. If
server would never succeed authentication of the non-PLUS variant the server cannot support channel binding, it SHOULD advertise
due to policy reasons, it MAY advertise only the PLUS-variant. only the non-PLUS-variant. If the server would never succeed in
o If the client negotiates mechanisms then clients MUST select the the authentication of the non-PLUS-variant due to policy reasons,
PLUS-variant if offered by the server. Otherwise (the client does it MUST advertise only the PLUS-variant.
not negotiate mechanisms), if the client has no prior knowledge
about mechanisms supported by the server and wasn't explicitly
configured to use a particular variant of the GS2 mechanism, then
it MUST select only non-PLUS version of the GS2 mechanism.
o If the client does not support channel binding then it MUST use a
"n" gs2-cb-flag.
o If the client supports channel binding and the server does not o If the client supports channel binding and the server does not
appear to (i.e., the client did not see the -PLUS name) then the appear to (i.e., the client did not see the -PLUS name advertised
client MUST either fail authentication or it MUST chose the non- by the server), then the client MUST NOT use an "n" gs2-cb-flag.
PLUS mechanism name and use a "y" gs2-cb-flag.
o If the client supports channel binding and the server appears to o Clients that support mechanism negotiation and channel binding
support it (i.e., the client see the -PLUS name), or if the client MUST use a "p" gs2-cb-flag when the server offers the PLUS-variant
wishes to use channel binding but the client does not negotiate of the desired GS2 mechanism.
mechanisms, then the client MUST use a "p" gs2-cb-flag to indicate
the channel binding type it is using. o If the client does not support channel binding, then it MUST use
o The client generate the chan_bindings input parameter for an "n" gs2-cb-flag. Conversely, if the client requires the use of
channel binding then it MUST use a "p" gs2-cb-flag. Clients that
do not support mechanism negotiation never use a "y" gs2-cb-flag,
they use either "p" or "n" according to whether they require and
support the use of channel binding or whether they do not,
respectively.
o The client generates the chan_bindings input parameter for
GSS_Init_sec_context as described below. GSS_Init_sec_context as described below.
o Upon receipt of the initial authentication message the server
o Upon receipt of the initial authentication message, the server
checks the gs2-cb-flag in the GS2 header and constructs a checks the gs2-cb-flag in the GS2 header and constructs a
chan_bindings parameter for GSS_Accept_sec_context as described chan_bindings parameter for GSS_Accept_sec_context as described
below. If the client channel binding flag was "y" and the server below. If the client channel binding flag was "y" and the server
did advertise support for channel bindings then the server MUST did advertise support for channel bindings (by advertising the
fail authentication. If the client channel binding flag was "p" PLUS-variant of the mechanism chosen by the client), then the
and the server does not support the indicated channel binding type server MUST fail authentication. If the client channel binding
then the server MUST fail authentication. flag was "p" and the server does not support the indicated channel
binding type, then the server MUST fail authentication.
o If the client used an "n" gs2-cb-flag and the server requires the
use of channel binding, then the server MUST fail authentication.
FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION
---- ----------------- ----------------- ----------- ---- ----------------- ----------------- -----------
n no support N/A If server disallows n no support N/A If server disallows
non-channel-bound non-channel-bound
authentication, then authentication, then
fail fail
y Yes, not required No Authentication may y Yes, not required No Authentication may
skipping to change at page 11, line 25 skipping to change at page 11, line 32
y Yes, not required Yes Authentication must fail y Yes, not required Yes Authentication must fail
p Yes Yes Authentication may p Yes Yes Authentication may
succeed, with CB used succeed, with CB used
p Yes No Authentication will fail p Yes No Authentication will fail
N/A Yes, required No Client does not even try N/A Yes, required No Client does not even try
For more discussions of channel bindings, and the syntax of the For more discussion 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. Content of GSS-CHANNEL-BINDINGS structure 5.1. Content of GSS-CHANNEL-BINDINGS Structure
The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a
chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS
structure [RFC5554]. structure [RFC5554].
The initiator-address-type and acceptor-address-type fields of the The initiator-address-type and acceptor-address-type fields of the
GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator- GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-
address and acceptor-address fields MUST be the empty string. address and acceptor-address fields MUST be the empty string.
The application-data field MUST be set to the gs2-header concatenated The application-data field MUST be set to the gs2-header, excluding
with, when a gs2-cb-flag of "p" is used, the application's channel the initial [gs2-nonstd-flag ","] part, concatenated with, when a
binding data. gs2-cb-flag of "p" is used, the application's channel binding data.
5.2. Default Channel Binding 5.2. Default Channel Binding
A default channel binding type agreement process for all SASL A default channel binding type agreement process for all SASL
application protocols that do not provide their own channel binding application protocols that do not provide their own channel binding
type agreement is provided as follows. type agreement is provided as follows.
'tls-unique' is the default channel binding type for any application 'tls-unique' is the default channel binding type for any application
that doesn't specify one. that doesn't specify one.
Servers MUST implement the "tls-unique" [tls-unique] Servers MUST implement the "tls-unique" [RFC5929] channel binding
[I-D.altman-tls-channel-bindings] channel binding type, if they type, if they implement any channel binding. Clients SHOULD
implement any channel binding. Clients SHOULD implement the "tls- implement the "tls-unique" channel binding type, if they implement
unique" channel binding type, if they implement any channel binding. any channel binding. Clients and servers SHOULD choose the highest-
Clients and servers SHOULD choose the highest-layer/innermost end-to- layer/innermost end-to-end TLS channel as the channel to which to
end TLS channel as the channel to bind to. bind.
Servers MUST choose the channel binding type indicated by the client, Servers MUST choose the channel binding type indicated by the client,
or fail authentication if they don't support it. or fail authentication if they don't 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
skipping to change at page 13, line 43 skipping to change at page 14, line 16
optional authzid given. optional authzid given.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: y,a=someuser,<initial C: y,a=someuser,<initial
context token with standard header removed> context token with standard header removed>
S: Send reply context token as is 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 or the 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 If GSS_Init/Accept_sec_context returns 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 If the client's initial GS2 header does not match the ABNF.
o In particular, if the initial character of the client message is o In particular, if the initial character of the client message is
anything except "F", "p", "n", or "y". 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 bindings. supports channel bindings.
o If the client's GS2 channel binding flag was "p" and the server o If the client's GS2 channel binding flag was "p" and the server
does not support the indicated channel binding. 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 If 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
GS2 does not use any GSS-API per-message tokens. Therefore the per- GS2 does not use any GSS-API per-message tokens. Therefore, the per-
message token ret_flags from GSS_Init_sec_context() and message token ret_flags from GSS_Init_sec_context() and
GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT
set the per-message req_flags. set the per-message req_flags.
The mutual_req_flag MUST be set. If channel binding is used then the The mutual_req_flag MUST be set. Clients MUST check that the
client MUST check that the corresponding ret_flag is set when the corresponding ret_flag is set when the context is fully established,
context is fully establish, else authentication MUST fail. else authentication MUST fail.
Use or non-use of deleg_req_flag and anon_req_flag is an Use or non-use of deleg_req_flag and anon_req_flag is an
implementation-specific detail. SASL and GS2 implementors are implementation-specific detail. SASL and GS2 implementors are
encouraged to provide programming interfaces by which clients may encouraged to provide programming interfaces by which clients may
choose to delegate credentials and by which servers may receive them. choose to delegate credentials and by which servers may receive them.
SASL and GS2 implementors are encouraged to provide programming SASL and GS2 implementors are encouraged to provide programming
interfaces which provide a good mapping of GSS-API naming options. interfaces that provide a good mapping of GSS-API naming options.
9. Naming 9. Naming
There's no requirement that any particular GSS-API name-types be There is no requirement that any particular GSS-API name-types be
used. However, typically SASL servers will have host-based acceptor used. However, typically, SASL servers will have host-based acceptor
principal names (see [RFC2743] section 4.1) and clients will principal names (see [RFC2743], Section 4.1) and clients will
typically have username initiator principal names (see [RFC2743] typically have username initiator principal names (see [RFC2743],
section 4.2). When a host-based acceptor principal name is used Section 4.2). When a host-based acceptor principal name is used
("service@hostname"), "service" is the service name specified in the ("service@hostname"), "service" is the service name specified in the
protocol's profile, and "hostname" is the fully qualified host name protocol's profile and "hostname" is the fully qualified host name of
of the server. the server.
10. GSS_Inquire_SASLname_for_mech call 10. GSS_Inquire_SASLname_for_mech Call
We specify a new GSS-API utility function to allow SASL We specify a new GSS-API utility function to allow SASL
implementations to more efficiently identify the GSS-API mechanism implementations to more efficiently identify the GSS-API mechanism to
that a particular SASL mechanism name refers to. which a particular SASL mechanism name refers.
Inputs: Inputs:
o desired_mech OBJECT IDENTIFIER o desired_mech OBJECT IDENTIFIER
Outputs: Outputs:
o major_status INTEGER
o minor_status INTEGER
o sasl_mech_name UTF-8 STRING -- SASL name for this o sasl_mech_name UTF-8 STRING -- SASL name for this
mechanism; caller must release with mechanism; caller must release with
GSS_Release_buffer() GSS_Release_buffer()
o mech_name UTF-8 STRING -- name of this mechanism, possibly o mech_name UTF-8 STRING -- name of this mechanism, possibly
localized; caller must release with GSS_Release_buffer() localized; caller must release with GSS_Release_buffer()
o mech_description UTF-8 STRING -- possibly localized o mech_description UTF-8 STRING -- possibly localized
description of this mechanism; caller must release with description of this mechanism; caller must release with
GSS_Release_buffer() GSS_Release_buffer()
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates successful completion, and that o GSS_S_COMPLETE indicates successful completion, and that
skipping to change at page 15, line 37 skipping to change at page 16, line 19
GSS_Release_buffer() GSS_Release_buffer()
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates successful completion, and that o GSS_S_COMPLETE indicates successful completion, and that
output parameters holds correct information. output parameters holds correct information.
o GSS_S_BAD_MECH indicates that a desired_mech was unsupported o GSS_S_BAD_MECH indicates that a desired_mech was unsupported
by the GSS-API implementation. by the GSS-API implementation.
o GSS_S_FAILURE indicates that the operation failed for reasons
unspecified at the GSS-API level.
The GSS_Inquire_SASLname_for_mech call is used to get the SASL The GSS_Inquire_SASLname_for_mech call is used to get the SASL
mechanism name for a GSS-API mechanism. It also returns a name mechanism name for a GSS-API mechanism. It also returns a name
and description of the mechanism in user friendly form. and description of the mechanism in user-friendly form.
The output variable sasl_mech_name will hold the IANA registered The output variable sasl_mech_name will hold the IANA registered
mechanism name for the GSS-API mechanism, or if none is mechanism name for the GSS-API mechanism, or if none is
registered, a mechanism name computed from the OID as described registered, a mechanism name computed from the OID as described
in section 3.1 of this document. in Section 3.1 of this document.
10.1. gss_inquire_saslname_for_mech 10.1. gss_inquire_saslname_for_mech
The C binding for the GSS_Inquire_SASLname_for_mech call is as The C binding for the GSS_Inquire_SASLname_for_mech call is as
follows. follows.
As mentioned in [RFC2744], routines may return GSS_S_FAILURE,
indicating an implementation-specific or mechanism-specific error
condition, further details of which are reported via the minor_status
parameter.
OM_uint32 gss_inquire_saslname_for_mech( OM_uint32 gss_inquire_saslname_for_mech(
OM_uint32 *minor_status, OM_uint32 *minor_status,
const gss_OID desired_mech, const gss_OID desired_mech,
gss_buffer_t sasl_mech_name, gss_buffer_t sasl_mech_name,
gss_buffer_t mech_name, gss_buffer_t mech_name,
gss_buffer_t mech_description gss_buffer_t mech_description
); );
Purpose: Purpose:
Output the SASL mechanism name of a GSS-API mechanism. Output the SASL mechanism name of a GSS-API mechanism.
It also returns a name and description of the mechanism in a It also returns a name and description of the mechanism in a
user friendly form. user-friendly form.
Parameters: Parameters:
minor_status Integer, modify minor_status Integer, modify
Mechanism specific status code. Mechanism-specific status code.
Function value: GSS status code desired_mech OID, read
Identifies the GSS-API mechanism to query.
GSS_S_COMPLETE Successful completion sasl_mech_name buffer, character-string, modify, optional
Buffer to receive SASL mechanism name.
The application must free storage associated
with this name after use with a call to
gss_release_buffer().
GSS_S_BAD_MECH The desired_mech OID is unsupported mech_name buffer, character-string, modify, optional
Buffer to receive human-readable mechanism name.
The application must free storage associated
with this name after use with a call to
gss_release_buffer().
11. GSS_Inquire_mech_for_SASLname call mech_description buffer, character-string, modify, optional
Buffer to receive description of mechanism.
The application must free storage associated
with this name after use with a call to
gss_release_buffer().
To allow SASL clients to more efficiently identify which GSS-API Function value: GSS status code:
mechanism a particular SASL mechanism name refers to we specify a new
GSS_S_COMPLETE Successful completion.
GSS_S_BAD_MECH The desired_mech OID is unsupported.
11. GSS_Inquire_mech_for_SASLname Call
To allow SASL clients to more efficiently identify to which GSS-API
mechanism a particular SASL mechanism name refers, we specify a new
GSS-API utility function for this purpose. GSS-API utility function for this purpose.
Inputs: Inputs:
o sasl_mech_name UTF-8 STRING -- SASL name of mechanism o sasl_mech_name UTF-8 STRING -- SASL name of mechanism.
Outputs: Outputs:
o major_status INTEGER
o minor_status INTEGER
o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, o mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
and not "default" specifier and not "default" specifier. Caller should treat as read-only
and should not attempt to release.
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates successful completion, and that output o GSS_S_COMPLETE indicates successful completion, and that output
parameters holds correct information. parameters holds correct information.
o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
had the indicated sasl_mech_name. had the indicated sasl_mech_name.
o GSS_S_FAILURE indicates that the operation failed for reasons
unspecified at the GSS-API level.
The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
mechanism OID associated with a SASL mechanism name. mechanism OID associated with a SASL mechanism name.
11.1. gss_inquire_mech_for_saslname 11.1. gss_inquire_mech_for_saslname
The C binding for the GSS_Inquire_mech_for_SASLname call is as The C binding for the GSS_Inquire_mech_for_SASLname call is as
follows. follows.
As mentioned in [RFC2744], routines may return GSS_S_FAILURE,
indicating an implementation-specific or mechanism-specific error
condition, further details of which are reported via the minor_status
parameter.
OM_uint32 gss_inquire_mech_for_saslname( OM_uint32 gss_inquire_mech_for_saslname(
OM_uint32 *minor_status, OM_uint32 *minor_status,
const gss_buffer_t sasl_mech_name, const gss_buffer_t sasl_mech_name,
gss_OID *mech_type gss_OID *mech_type
); );
Purpose: Purpose:
Output GSS-API mechanism OID of mechanism associated with given Output GSS-API mechanism OID of mechanism associated with given
sasl_mech_name. sasl_mech_name.
Parameters: Parameters:
minor_status Integer, modify minor_status Integer, modify
Mechanism specific status code. Mechanism-specific status code.
Function value: GSS status code sasl_mech_name buffer, character-string, read
Buffer with SASL mechanism name.
GSS_S_COMPLETE Successful completion mech_type OID, modify, optional
Actual mechanism used. The OID returned via
this parameter will be a pointer to static
storage that should be treated as read-only.
In particular, the application should not attempt
to free it. Specify NULL if not required.
GSS_S_BAD_MECH The desired_mech OID is unsupported Function value: GSS status code:
GSS_S_COMPLETE Successful completion.
GSS_S_BAD_MECH There is no GSS-API mechanism known
as sasl_mech_name.
12. Security Layers 12. Security Layers
GS2 does not support SASL security layers. Applications that need GS2 does not support SASL security layers. Applications that need
integrity or confidentiality protection can use either channel integrity or confidentiality protection can use either channel
binding to a secure external channel or another SASL mechanism that binding to a secure external channel or another SASL mechanism that
does provide security layers. does provide security layers.
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 [RFC4752]. The Kerberos V5 mechanism may
V5 mechanism may also be used with the GS2 family. This causes an also be used with the GS2 family. This causes an interoperability
interoperability problem, which is discussed and resolved below. problem, which is discussed and resolved below.
13.1. The interoperability problem 13.1. The Interoperability Problem
The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos The SASL "GSSAPI" mechanism is not wire compatible with the Kerberos
V GSS-API mechanism used as a SASL GS2 mechanism. V GSS-API mechanism used as a SASL GS2 mechanism.
If a client (or server) only support Kerberos V5 under the "GSSAPI" If a client (or server) only support Kerberos V5 under the "GSSAPI"
name and the server (or client) only support Kerberos V5 under the name, and the server (or client) only support Kerberos V5 under the
GS2 family, the mechanism negotiation will fail. GS2 family, the mechanism negotiation will fail.
13.2. Resolving the problem 13.2. Resolving the Problem
If the Kerberos V5 mechanism is supported under GS2 in a server, the If the Kerberos V5 mechanism is supported under GS2 in a server, the
server SHOULD also support Kerberos V5 through the "GSSAPI" server SHOULD also support Kerberos V5 through the "GSSAPI"
mechanism, to avoid interoperability problems with older clients. mechanism, to avoid interoperability problems with older clients.
Reasons for violating this recommendation may include security Reasons for violating this recommendation may include security
considerations regarding the absent features in the GS2 mechanism. considerations regarding the absent features in the GS2 mechanism.
The SASL "GSSAPI" mechanism lacks support for channel bindings, which The SASL "GSSAPI" mechanism lacks support for channel bindings, which
means that using an external secure channel may not be sufficient means that using an external secure channel may not be sufficient
protection against active attackers (see [RFC5056], [mitm]). protection against active attackers (see [RFC5056] and [MITM]).
13.3. Additional Recommendations 13.3. Additional Recommendations
If the application requires SASL security layers then it MUST use the If the application requires SASL security layers, then it MUST use
SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2-KRB5- the SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2-
PLUS". KRB5-PLUS".
If the application can use channel binding to an external channel If the application can use channel binding to an external channel,
then it is RECOMMENDED that it select Kerberos V5 through the GS2 then it is RECOMMENDED that it select Kerberos V5 through the GS2
mechanism rather than the "GSSAPI" mechanism. mechanism rather than the "GSSAPI" mechanism.
14. GSS-API Mechanisms that negotiate other mechanisms 14. GSS-API Mechanisms That Negotiate Other Mechanisms
A GSS-API mechanism that negotiates other mechanisms will interact A GSS-API mechanism that negotiates other mechanisms will interact
badly with the SASL mechanism negotiation. There are two problems. badly with the SASL mechanism negotiation. There are two problems.
The first is an interoperability problem and the second is a security The first is an interoperability problem and the second is a security
concern. The problems are described and resolved below. concern. The problems are described and resolved below.
14.1. The interoperability problem 14.1. The Interoperability Problem
If a client implements GSS-API mechanism X, potentially negotiated If a client implements GSS-API mechanism X, potentially negotiated
through a GSS-API mechanism Y, and the server also implements GSS-API through a GSS-API mechanism Y, and the server also implements GSS-API
mechanism X negotiated through a GSS-API mechanism Z, the mechanism X negotiated through a GSS-API mechanism Z, the
authentication negotiation will fail. authentication negotiation will fail.
14.2. Security problem 14.2. Security Problem
If a client's policy is to first prefer GSSAPI mechanism X, then non- If a client's policy is to first prefer GSSAPI mechanism X, then non-
GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
mechanisms Y and Z but not X, then if the client attempts to mechanisms Y and Z but not X, then if the client attempts to
negotiate mechanism X by using a GSS-API mechanism that negotiates negotiate mechanism X by using a GSS-API mechanism that negotiates
other mechanisms (such as SPNEGO [RFC4178]), it may end up using other mechanisms (such as Simple and Protected GSS-API Negotiation
mechanism Z when it ideally should have used mechanism Y. For this (SPNEGO) [RFC4178]), it may end up using mechanism Z when it ideally
reason, the use of GSS-API mechanisms that negotiate other mechanisms should have used mechanism Y. For this reason, the use of GSS-API
is disallowed under GS2. mechanisms that negotiate other mechanisms is 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. NOT choose the SPNEGO mechanism under any circumstances.
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
[RFC5587] can be used to identify such mechanisms. [RFC5587] can be used to identify such mechanisms.
15. IANA Considerations 15. IANA Considerations
The IANA is advised to register a SASL mechanism family as per The IANA has registered a SASL mechanism family as per [RFC4422]
[RFC4422] using the following information. using the following information.
Subject: Registration of SASL mechanism family GS2-* Subject: Registration of SASL mechanism family GS2-*
SASL mechanism prefix: GS2- SASL mechanism prefix: GS2-
Security considerations: RFC [THIS-DOC] Security considerations: RFC 5801
Published specification: RFC [THIS-DOC] Published specification: RFC 5801
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.
The IANA is advised that SASL mechanism names starting with "GS2-" The IANA is advised that SASL mechanism names starting with "GS2-"
are reserved for SASL mechanisms which conform to this document. The are reserved for SASL mechanisms that conform to this document. The
IANA is directed to place a statement to that effect in the sasl- IANA has placed a statement to that effect in the SASL Mechanisms
mechanisms registry. registry.
The IANA is further advised that GS2 SASL mechanism names MUST NOT The IANA is further advised that GS2 SASL mechanism names MUST NOT
end in "-PLUS" except as a version of another mechanism name simply end in "-PLUS" except as a version of another mechanism name simply
suffixed with "-PLUS". 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.
16. Security Considerations 16. Security Considerations
Security issues are also discussed throughout this memo. Security issues are also discussed throughout this memo.
The security provided by a GS2 mechanism depends on the security of The security provided by a GS2 mechanism depends on the security of
the GSS-API mechanism. The GS2 mechanism family depends on channel the GSS-API mechanism. The GS2 mechanism family depends on channel
binding support, so GSS-API mechanisms that do not support channel binding support, so GSS-API mechanisms that do not support channel
binding cannot be successfully used as SASL mechanisms via the GS2 binding cannot be successfully used as SASL mechanisms via the GS2
bridge. bridge.
Because GS2 does not support security layers it is strongly Because GS2 does not support security layers, it is strongly
RECOMMENDED that channel binding to a secure external channel be RECOMMENDED that channel binding to a secure external channel be
used. Successful channel binding eliminates the possibility of man- used. Successful channel binding eliminates the possibility of man-
in-the-middle (MITM) attacks, provided that the external channel and in-the-middle (MITM) attacks, provided that the external channel and
its channel binding data are secure and provided that the GSS-API its channel binding data are secure and that the GSS-API mechanism
mechanism used is secure. Authentication failure because of channel used is secure. Authentication failure because of channel binding
binding failure may indicate that an MITM attack was attempted, but failure may indicate that an MITM attack was attempted, but note that
note that a real MITM attacker would likely attempt to close the a real MITM attacker would likely attempt to close the connection to
connection to the client or simulate network partition , thus MITM the client or simulate network partition; thus, MITM attack detection
attack detection is heuristic. is heuristic.
Use of channel binding will also protect the SASL mechanism Use of channel binding will also protect the SASL mechanism
negotiation -- if there is no MITM then the external secure channel negotiation -- if there is no MITM, then the external secure channel
will have protected the SASL mechanism negotiation. will have protected the SASL mechanism negotiation.
The channel binding data MAY be sent (but the actual GSS-API The channel binding data MAY be sent (by the actual GSS-API mechanism
mechanism used) without confidentiality protection and knowledge of used) without confidentiality protection and knowledge of it is
it is assumed to provide no advantage to an MITM (who can, in any assumed to provide no advantage to an MITM (who can, in any case,
case, compute the channel binding data independently). If the compute the channel binding data independently). If the external
external channel does not provide confidentiality protection and the channel does not provide confidentiality protection and the GSS-API
GSS-API mechanism does not provide confidentiality protection for the mechanism does not provide confidentiality protection for the channel
channel binding data, then passive attackers (eavesdroppers) can binding data, then passive attackers (eavesdroppers) can recover the
recover the channel binding data. See [RFC5056]. channel binding data, see [RFC5056].
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 DNS Security (DNSSEC) [RFC4033].
SHA-1 is used to derive SASL mechanism names, but no traditional SHA-1 is used to derive SASL mechanism names, but no traditional
cryptographic properties are required -- the required property is cryptographic properties are required -- the required property is
that the truncated output for distinct inputs are different for that the truncated output for distinct inputs are different for
practical input values. GS2 does not use any other cryptographic practical input values. GS2 does not use any other cryptographic
algorithm. Therefor GS2 is "algorithm agile", or, as agile as the algorithm. Therefore, GS2 is "algorithm agile", or, as agile as the
GSS-API mechanisms that are available for use in SASL applications GSS-API mechanisms that are available for use in SASL applications
via GS2. via GS2.
GS2 does not protect against downgrade attacks of channel binding GS2 does not protect against downgrade attacks of channel binding
types. The complexities of negotiation a channel binding type, and types. Negotiation of channel binding type was intentionally left
handling down-grade attacks in that negotiation, was intentionally out of scope for this document.
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]), 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 RFC 2222. This document was derived from [SASL-GSSAPI],
draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with which was prepared by Alexey Melnikov with significant contributions
significant contributions from John G. Myers, although the majority from John G. Myers, although the majority of this document has been
of this document has been rewritten by the current authors. 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
acknowledged. In particular, ideas and feedback from Pasi Eronen, acknowledged. In particular, ideas and feedback from Pasi Eronen,
Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved
the document and the protocol. Other suggestions to the documents the document and the protocol. Other suggestions to the documents
were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert
Sparks, and Glen Zorn. Sparks, and Glen Zorn.
18. References 18. References
skipping to change at page 23, line 20 skipping to change at page 25, line 11
[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 [RFC5554] Williams, N., "Clarifications and Extensions to the
Generic Security Service Application Program Interface Generic Security Service Application Program Interface
(GSS-API) for the Use of Channel Bindings", RFC 5554, (GSS-API) for the Use of Channel Bindings", RFC 5554,
May 2009. May 2009.
[CCITT.X690.2002] [CCITT.X690.2002]
International International Telephone and Telegraph International Telephone and Telegraph Consultative
Consultative Committee, "ASN.1 encoding rules: Committee, "ASN.1 encoding rules: Specification of basic
Specification of basic encoding Rules (BER), Canonical encoding Rules (BER), Canonical encoding rules (CER) and
encoding rules (CER) and Distinguished encoding rules Distinguished encoding rules (DER)", CCITT Recommendation
(DER)", CCITT Recommendation X.690, July 2002. X.690, July 2002.
[tls-unique] [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
Zhu, L., "Registration of TLS unique channel binding for TLS", RFC 5929, July 2010.
(generic)", IANA http://www.iana.org/assignments/
channel-binding-types/tls-unique, 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.
[RFC2222] Myers, J., "Simple Authentication and Security Layer [RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
skipping to change at page 24, line 20 skipping to change at page 26, line 15
[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.
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism [RFC5587] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", RFC 5587, July 2009. Inquiry APIs", RFC 5587, July 2009.
[I-D.ietf-sasl-scram] [RFC5802] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams,
Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, "Salted Challenge Response Authentication Mechanism
"Salted Challenge Response (SCRAM) SASL and GSS-API (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
Mechanism", draft-ietf-sasl-scram-10 (work in progress),
October 2009.
[I-D.altman-tls-channel-bindings] [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
Altman, J., Williams, N., and L. Zhu, "Channel Bindings in Tunnelled Authentication", in 11th Security
for TLS", draft-altman-tls-channel-bindings-07 (work in Protocols Workshop, 2002.
progress), October 2009.
[mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle [SASL-GSSAPI]
in Tunneled Authentication", Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html. Work in Progress, March 2005.
Authors' Addresses Authors' Addresses
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Hagagatan 24 Hagagatan 24
Stockholm 113 47 Stockholm 113 47
SE SE
Email: simon@josefsson.org EMail: simon@josefsson.org
URI: http://josefsson.org/ URI: http://josefsson.org/
Nicolas Williams Nicolas Williams
Sun Microsystems Oracle
5300 Riata Trace Ct 5300 Riata Trace Ct
Austin, TX 78727 Austin, TX 78727
USA USA
Email: Nicolas.Williams@sun.com EMail: Nicolas.Williams@oracle.com
 End of changes. 128 change blocks. 
284 lines changed or deleted 357 lines changed or added

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