draft-ietf-sasl-gs2-10.txt   draft-ietf-sasl-gs2-11.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB
Intended status: Standards Track Intended status: Standards Track N. Williams
Expires: January 14, 2009 Expires: September 24, 2009 Sun Microsystems
March 23, 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-10 draft-ietf-sasl-gs2-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 14, 2009. This Internet-Draft will expire on September 24, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 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/GSS-API family offers a number of improvements over the previous "SASL/
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 a SASL-specific authentication phase in some cases, and supports negotiable use of
notion of channel binding. channel binding. Only GSS-API mechanisms that support channel
binding are supported.
See <http://josefsson.org/sasl-gs2-*/> for more information. See <http://josefsson.org/sasl-gs2-*/> for more information.
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 . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 6 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5
3.2. Computing mechanism names manually . . . . . . . . . . . . 6 3.2. Computing mechanism names manually . . . . . . . . . . . . 5
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. SASL Authentication Exchange Message Format . . . . . . . . . 8 4. SASL Authentication Exchange Message Format . . . . . . . . . 7
4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11
4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12 10. GSS_Mechanism_SASLname call . . . . . . . . . . . . . . . . . 11
4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13 10.1. gss_mechanism_saslname . . . . . . . . . . . . . . . . . . 13
4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13
4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 15
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 15
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16 13. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 16
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20 13.1. The interoperability problem . . . . . . . . . . . . . . . 16
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 16
9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16
9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17
10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24 14.1. The interoperability problem . . . . . . . . . . . . . . . 17
11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17
11.1. The interoperability problem . . . . . . . . . . . . . . . 25 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17
11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11.3. Additional recommendations . . . . . . . . . . . . . . . . 25 16. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. The interoperability problem . . . . . . . . . . . . . . . 26 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26 18.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26 18.2. Informative References . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
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 provide security services to [RFC2743] is a framework that provides security services to
applications. Simple Authentication and Security Layer (SASL) applications using a variety of authentication "mechanisms". Simple
[RFC4422] is a framework to provide authentication and security Authentication and Security Layer (SASL) [RFC4422] is a framework to
layers for connection based protocols. This document describe how to provide authentication and "security layers" for connection based
use a GSS-API mechanism in a connection-based protocol using the SASL protocols, also using a variety of mechanisms. This document
framework. describes how to use a GSS-API mechanism as though it were a SASL
mechanism. This facility is called "GS2" -- a moniker that indicates
All GSSAPI mechanisms are implicitly registered for use within SASL that this is the second GSS-API->SASL mechanism bridge. The original
by this specification. The SASL mechanism defined in this document GSS-API->SASL mechanism bridge was specified by [RFC2222], now
is known as the GS2 family. [RFC4752]; we shall sometimes refer to the original bridge as "GS1"
in this document.
The "Kerberos V5 GSS-API mechanism" [RFC1964] is also supported in
SASL through "SASL GSSAPI mechanisms" [RFC4752]. The difference
between that protocol and the one described here, is that this
protocol offer more features (i.e., channel bindings and round-trip
optimizations) while the other protocol is more widely deployed.
There are interoperability concerns by having the same GSS-API
mechanism available under more than one SASL mechanism name, see the
section "Interoperability with the GSSAPI mechanism" below.
There are interoperability and security concerns if this SASL All GSS-API mechanisms are implicitly registered for use within SASL
mechanism is used together with a GSS-API mechanism that negotiate by this specification. The SASL mechanisms defined in this document
other GSS-API mechanisms (such as SPNEGO [RFC4178]), see the section are known as the "GS2 family of mechanisms".
"Mechanisms that negotiate other mechanisms" below.
There are interoperability and security concerns with GSSAPI The GS1 bridge failed to gain wide deployment for any GSS-API
mechanism that do not provide integrity, see the section "Non- mechanism other than The "Kerberos V GSS-API mechanism" [RFC1964]
integrity capable GSS-API mechanisms" below. [RFC4121], and has a number of problems that lead us to desire a new
bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1
did not support channel binding [RFC5056]. These problems and the
opportunity to create the next SASL password-based mechanism, SCRAM
[I-D.newman-auth-scram], as a GSS-API mechanism used by SASL
applications via GS2, provide the motivation for GS2.
SASL mechanism names starting with "GS2-" are reserved for SASL In particular, the current consensus of the SASL community appears to
mechanisms which conform to this document. be that SASL "security layers" (i.e., confidentiality and integrity
protection of application data after authentication) are too complex
and, since SASL applications tend to have an option to run over a
Transport Layer Security (TLS) [RFC5246] channel, redundant and best
replaced with channel binding.
The IESG is considered to be the owner of all SASL mechanisms which GS2 is designed to be as simple as possible. It adds to GSS-API
conform to this document. This does not necessarily imply that the security context token exchanges only the bare minimum to support
IESG is considered to be the owner of the underlying GSSAPI SASL semantics and negotiation of use of channel binding.
mechanism. Specifically, GS2 adds a small header (2 bytes or 4 bytes plus the
length of the client requested SASL authorization ID (authzid)) to
the initial context token and to the application channel binding
data, and it uses SASL mechanism negotiation to implement channel
binding negotiation. All GS2 plaintext is protected via the use of
GSS-API channel binding. Additionally, to simplify the
implementation of GS2 mechanisms for implementors who will not
implement a GSS-API framework, we compress the initial security
context token header 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].
3. Mechanism name 3. Mechanism name
3.1. Generating SASL mechanism names from GSS-API OIDs 3.1. Generating SASL mechanism names from GSS-API OIDs
The SASL mechanism name for a GSS-API mechanism is the concatenation There are two SASL mechanism names for any GSS-API mechanism used
of the string "GS2-" and the Base32 encoding [RFC4648] (with an upper through this facility. One denotes that the server supports channel
case alphabet) of the first ten bytes of the binary SHA-1 hash binding. The other denotes that it does not.
[FIPS.180-1.1995] string computed over the ASN.1 DER encoding
[ITU.X690.1994], including the tag and length octets, of the GSS-API The SASL mechanism name for a GSS-API mechanism is that which is
mechanism's Object Identifier. The Base32 rules on padding provided by that mechanism when it was specified, if one was
characters and characters outside of the base32 alphabet are not specified. This name denotes that the server does not support
relevant to this use of Base32. If any padding or non-alphabet channel binding. Add the suffix "-PLUS" and the resulting name
denotes that the server does support channel binding. SASL
implementations can use the GSS_Mechanism_Name call (see below) to
query for the SASL mechanism name of a GSS-API mechanism.
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
concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
(with an upper case alphabet) of the first 55 bits of the binary
SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER
encoding [CCITT.X690.2002], including the tag and length octets, of
the GSS-API mechanism's Object Identifier. The Base32 rules on
padding characters and characters outside of the base32 alphabet are
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. name. This name denotes that the server does not support channel
binding. Add the suffix "-PLUS" and the resulting name denotes that
the server does support channel binding.
3.2. Computing mechanism names manually 3.2. Computing mechanism names manually
The SASL mechanism name may be computed manually. This is useful The hash-derived GS2 SASL mechanism name may be computed manually.
when the set of supported GSS-API mechanisms is known in advance. It This is useful when the set of supported GSS-API mechanisms is known
also obliterate the need to implement Base32, SHA-1 and DER in the in advance. It also obliterate the need to implement Base32, SHA-1
SASL mechanism. The computed mechanism name can be used directly in and DER in the SASL mechanism. The computed mechanism name can be
the implementation, and the implementation need not concern itself used directly in the implementation, and the implementation need not
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 ten octets to binary, and re-group 27 86 61 ad. Convert the first 7 octets to binary, drop the last
them in groups of 5, and convert them back to decimal, which results bit, and re-group them in groups of 5, and convert them back to
in these computations: decimal, which results in these computations:
hex: hex:
1c f8 f4 2b 5a 9f 80 fa e9 f8 1c f8 f4 2b 5a 9f 80
binary: binary:
00011100 11111000 11110100 00101011 01011010 00011100 11111000 11110100 00101011 01011010
10011111 10000000 11111010 11101001 11111000 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 01111 10101 11010 01111 11000 10011 11110 00000
decimal of each group: decimal of each group:
3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24 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 P V 2 P Y D T 4 P I K 2 2 T 6 A
The last step translate each decimal value using table 3 in Base32 The last step translate 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-DT4PIK22T6APV2PY". 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 first ten octets to 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
binary, and re-group them in groups of 5, and convert them back to binary, and re-group them in groups of 5, and convert them back to
decimal, which results in these computations: decimal, which results in these computations:
hex: hex:
82 d2 73 25 76 6b d6 c8 45 aa 82 d2 73 25 76 6b d6
binary: binary:
10000010 11010010 01110011 00100101 01110110 10000010 11010010 01110011 00100101 01110110
01101011 11010110 11001000 01000101 10101010 01101011 1101011
binary in groups of 5: binary in groups of 5:
10000 01011 01001 00111 00110 01001 01011 10110 10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011 01100 10000 10001 01101 01010 01101 01111 01011
decimal of each group: decimal of each group:
16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 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 M Q R N K Q L J H G J L W N P L
The last step translate each decimal value using table 3 in Base32 The last step translate 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 GSSAPI
mechanism is "GS2-QLJHGJLWNPLMQRNK". mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
supports channel binding) "GS2-QLJHGJLWNPL-PLUS". But instead, we
assign the Kerberos V mechanism a non-hash-derived mechanism name:
"KerberosV-GS2" and "KerberosV-GS2-PLUS" (see Section 15).
4. SASL Authentication Exchange Message Format 4. SASL Authentication Exchange Message Format
4.1. SASL Messages 4.1. SASL Messages
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-
API mechanism would normally require in order to establish a security
context (or to fail to do so).
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 Note that when using a GS2 mechanism the SASL client is always a GSS-
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 API initiator and the SASL server is always a GSS-API acceptor. Thus
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the SASL client calls GSS_Init_sec_context() and the server calls
| Context length | GSS_Accept_sec_context().
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrap token length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ [Context token] /
/ --------------------/
/ ---------------------/ /
/--------------------/ /
/ [Wrap token] /
/ /
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Context length" and "Wrap token length" fields each contain a 4
octet (32 bit) integer encoded in network byte order, that indicate
the length of the "Context token" and "Wrap token" fields,
respectively. A length of 0 means that a particular field is not
present.
The "Context token" field, if present, contain a GSS-API context
establishment token generated by GSS_Init_sec_context or
GSS_Accept_sec_context.
The "Wrap token" field, if present, contain the output generated by
the GS2_Wrap function.
The fields need not be aligned to 32-bit a boundary. There is no
padding between fields.
Messages shorter than or equal to 8 octets are invalid. (The only
exception is the initial empty challenge sent by the server which may
be 0 octets.) From that it follows that at least one of the "Context
token length" and the "Wrap token length" integers MUST be non-zero
in a particular message. If the sum of the length integers is longer
than the entire message size, minus 8 octets for the length fields,
the message is invalid.
During any successful authentication exchange, the client and server
will each send exactly one (non-empty) "Wrap token".
Conforming implementations MUST NOT send additional data after the
above message syntax, and MUST ignore additional data. To
illustrate, implementations MUST NOT assume that the last "Wrap token
length" octets of the packet correspond to the "Wrap token", because
that would be incorrect if the packet contained additional data not
described by this document.
4.2. Context Token Field
The format of the "Context token" field inside the SASL token is
defined by each GSS-API mechanism, and the data is computed by (for
the client) GSS_Init_sec_context and (for the server)
GSS_Accept_sec_context.
4.2.1. Client side
The client calls GSS_Init_sec_context, passing in
input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of
the GSSAPI mechanism for which this SASL mechanism is registered, the
chan_binding is set to NULL, and targ_name equal to output_name from
GSS_Import_Name called with input_name_type of
GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
"service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host
name of the server.
(*) - Clients MAY use name types other than
GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but
only when they have a priori knowledge that the servers support
alternate name types. Otherwise clients MUST use
GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
When calling the GSS_Init_sec_context the client SHOULD pass the
integ_req_flag of TRUE, but MAY set it to FALSE (see section 10
below). If the client intends to request a security layer, it MUST
also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE,
and a sequence_req_flag of TRUE. If the client will be requesting a
security layer providing confidentiality protection, it MUST also
supply to the GSS_Init_sec_context a conf_req_flag of TRUE.
The client then responds with any resulting output_token.
If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
client expect the server to issue a token in a subsequent challenge
or as additional information to the outcome of the authentication.
The client pass the context token to another call to
GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE
is returned or authentication is aborted.
If the server sent a (non-empty) "Wrap token", the context token is
processed before processing the other tokens. This is required
because GSS_Unwrap may need the context to be in the state it is
after the "Context token" in the message has been processed.
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client MUST
examine the context to ensure that it provides a level of protection
permitted by the client's security policy.
4.2.2. Server side
The server passes the first context token to GSS_Accept_sec_context
as input_token, setting input_context_handle to GSS_C_NO_CONTEXT
(initially), the chan_binding set to NULL, and a suitable
acceptor_cred_handle (see below).
Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
GSS-API mechanism for which this SASL mechanism is registered (*).
Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle.
Servers MAY use a credential obtained by calling GSS_Acquire_cred or
GSS_Add_cred for the server's principal name(s) (**) and the GSS-API
mechanism for which this SASL mechanism is registered.
(*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
GSS-API mechanism as an input parameter. The OID set can be created
by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can
be freed by calling the GSS_Release_oid_set.
(**) - Use of server's principal names having
GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
where "service" is the service name specified in the protocol's
profile, and "hostname" is the fully qualified host name of the
server, is RECOMMENDED. The server name can be generated by calling
GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
and input_name_string of "service@hostname".
The server then responds with any resulting output_token.
The server pass any resulting challenge from the client to another
call to GSS_Accept_sec_context, repeating the procedure, until
GSS_S_COMPLETE is returned or authentication is aborted.
If the client sent a (non-empty) "Wrap token", the context token is
processed first.
Upon successful establishment of the security context (i.e.
GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
verify that the negotiated GSS-API mechanism is indeed the registered
one. This is done by examining the value of the mech_type parameter
returned from the GSS_Accept_sec_context call. If the value differ,
the SASL authentication MUST be aborted.
Upon successful establishment of the security context and if the
server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
credential handle, the server SHOULD also check using the
GSS_Inquire_context that the target_name used by the client matches:
- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
where "service" is the service name specified in the application
protocol's profile, and "hostname" is the fully qualified host name
of the server.
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server MUST
examine the context to ensure that it provides a level of protection
permitted by the server's security policy.
4.3. Wrap Token Field
The Wrap token field MUST NOT be sent or received before the
PROT_READY flag is set locally (by GSS_Init_sec_context or
Gss_Accept_sec_context), or if the PROT_READY flag is never set,
before the context has been fully established. The Wrap token field
does not have to be present directly when the PROT_READY flag is set.
During any exchange, exactly one Wrap token field is sent in each
direction. The GS2_Wrap function is defined below, and its inputs
MUST follow the format described below. If not exactly one Wrap
token is received by the client and by the server, the authentication
MUST fail.
If PROT_READY is never set by GSS_Init_sec_context or
GSS_Accept_sec_context, the flag is implied by successful context
negotiation. This is for GSS-API v1 mechanisms that do not support
PROT_READY, or for GSS-API mechanism that do not provide per-message
protection. This may result in a SASL token consisting of a context
token length of 0 and a Wrap token.
The entity that sends the first Wrap token will have to specify a
bitmap of supported and preferred quality of protection schemes. The
entity that replies to the Wrap tokens will pick a scheme, based on
the bitmask and local policy. The quality of protection values are
defined in section 9.
Two pairs of input formats to the GS2_Wrap function are defined. The
first pair is used when the client sends the Wrap token first and the
server responds. The other pair is used when the server sends the
Wrap token first and the client responds.
The inputs below are passed to GS2_Wrap, and the output is used as
the Wrap token value.
Some fields in the input formats are optional, indicated by brackets
("[" and "]") and explained by the text below.
4.3.1. The GS2_Wrap function
The GS2_Wrap function have two implementations, and which one is used
depends on whether the negotiated GSS-API context supports per-
message protection. When a context is successfully negotiated (i.e.,
when GSS_S_COMPLETE is returned from, for clients,
GSS_Init_sec_context, or, for servers, GSS_Accept_sec_context) and
the output variable integ_avail is FALSE, then GSS_Wrap cannot be
used and instead we define GS2_Wrap to be the identity function.
When integ_avail is negotiated TRUE, the GS2_Wrap is identical to
calling the GSS_Wrap function with conf_flag set to FALSE and using
the generated output_message as the output data.
4.3.2. Client first GS2_Wrap input
The input to GS2_Wrap when the client sends a Wrap token field first
is as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 All the SASL authentication messages exchanged are exactly the same
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 as the security context tokens of the GSS-API mechanism, except for
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the initial security context token.
| client_qops | client_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channel_binding_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[client_cbqops]| [channel_binding_data] /
/ /
/ / [authzid] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "client_qops" integer indicate the client's preferred quality of Also, the server SHOULD refrain from sending GSS-API error tokens
protection if channel bindings are absent or the negotiation of the (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
channel binding fails. The quality of protection values are defined along with a major status code other than GSS_S_COMPLETE or
in section 9. GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
The "client_maxbuf" field indicate the maximum protected buffer size The initial security context token is modified as follows:
the client can receive in network byte order. It MUST be 0 if the o The [RFC2743] section 3.1 initial context token header MUST be
client doesn't advertise support for any security layer, the server removed if present, and its presence is noted (see below). On the
MUST verify this. Small values can make it impossible for the server server side this header MUST be recomputed and restored prior to
to send any protected message to the client, due to the overhead passing the token to GSS_Accept_sec_context().
added by GSS_Wrap, and the server MAY reject the authentication if it o A GS2 header MUST be prefixed to the resulting initial context
detects this situation. token. This header has the form given below in ABNF [RFC5234].
The "channel_binding_length" is a network byte order integer that UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
indicate the length of the "channel_binding_data" field. ;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",".
UTF8-2 = <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-char-safe = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
The optional field "client_cbqops" is present only if saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
"channel_binding_length" is non-zero, and indicate the client's gs2-authzid = "a=" saslname
preferred quality of protection if channel binding negotiation ;; GS2 has to transport an authzid since
succeeds. The quality of protection values are defined in section 9. ;; the GSS-API has no equivalent
gs2-std-mech = "F"
;; "F" means the mechanism is NOT is a
;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing
gs2-cb-flag = "n" / "y" / "p"
;; GS2 channel binding (CB) flag
;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server
;; does not
;; "p" -> client supports and used CB
gs2-header = [gs2-std-mech] gs2-cb-flag [gs2-authzid] ","
;; The GS2 header is gs2-header.
;; gs2-std-mech is present if the GSS-API
;; mechanism's initial context token did not
;; have the standard header defined in
;; [RFC2743] section 3.1.
The optional field "channel_binding_data" is present only if The GS2 header is also prepended to the application's channel binding
"channel_binding_length" is non-zero, and contain the actual channel 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. binding data.
The optional field "authzid" contain the authorization identity. The The "gs2-authzid" holds the SASL authorization identity. It is
authorization identity is encoded using UTF-8 [RFC3629]. The encoded using UTF-8 [RFC3629] with three exceptions:
authorization identity is not terminated with the NUL (U+0000) o The NUL characters is forbidden as required by section 3.4.1 of
character. Servers MUST validate that the authorization identity is [RFC4422].
valid UTF-8.
4.3.3. Server last GS2_Wrap input
The input to GS2_Wrap when the server sends a Wrap token field, after
receiving the Wrap token in the previous section from the client, is
as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_qop | server_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "server_qop" field integer indicate the selected quality of
protection. The quality of protection values are defined in section
9.
The "server_maxbuf" field indicate the maximum protected data buffer
size the server can receive in network byte order. It MUST be 0 if
the server doesn't advertise support for any security layer, the
client MUST verify this. Small values can make it impossible for the
client to send any protected message to the server, due to the
overhead added by GSS_Wrap, and the client MAY reject the
authentication if it detects this situation.
4.3.4. Server first GS2_Wrap input
The input to GS2_Wrap when the server sends the Wrap token first is
as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_qops | server_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[server_cbqops]| [channel_binding_data] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "server_qops" field is an integer indicating the server's
preferred quality of protection if channel bindings are absent or the
negotiation of the channel binding fails. The quality of protection
values are defined in section 9.
The "server_maxbuf" is the same as above.
The optional field "server_cbqops" indicate the server's preferred
quality of protection if channel binding negotiation succeeds. The
quality of protection values are defined in section 9.
The optional field "channel_binding_data" contain the actual channel o The server MUST replace any occurance of "," (comma) in the string
binding data. with "=2C".
o The server MUST replace any occurance of "=" (comma) in the string
with "=3D".
4.3.5. Client last GS2_Wrap input If a server sends a string that does not conform to this syntax, the
client MUST reject authentication.
The input to GS2_Wrap when the clients sends a Wrap token field, 5. Channel Bindings
after receiving the Wrap token in the previous section from the
server, is as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 If the server supports channel binding then it must list both forms
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 of the SASL mechanism name for each GSS-API mechanism supported via
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GS2 (i.e., GSS-API mechanisms that support channel binding).
| client_qop | client_maxbuf |
/ [authzid] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "client_qop" field is the selected quality of protection. The If the client supports channel binding and the server does not (i.e.,
quality of protection values are defined in section 9. the server did not advertise the -PLUS names) then the client MUST
either fail authentication or it MUST set the channel binding flag in
the GS2 initial security context token to "y" and MUST NOT include
application channel binding data in the GSS-API channel binding input
to GSS_Init_sec_context().
The "client_maxbuf" and "authzid" fields are as above. If the client supports channel binding and the server also does then
the client MUST set the channel binding flag in the GS2 initial
security context token to "p" and MUST include application channel
binding data in the GSS-API channel binding input to
GSS_Init_sec_context().
5. Channel Bindings If the client does not support channel binding then it MUST set the
channel binding flag in the GS2 initial security context token to "n"
and MUST NOT include application channel binding data in the GSS-API
channel binding input to GSS_Init_sec_context().
The GS2 mechanism provide its own channel binding mechanism, instead Upon receipt of the initial authentication message the server checks
of using the "chan_binding" parameter in the GSS-API context the channel binding flag in the GS2 header and constructs a channel
functions. The reason for this is that the GS2 mechanism provide an binding data input for GSS_Accept_sec_context() accordingly. If the
option to proceed even if the channel bindings does not match. The client channel binding flag was "n" then the server MUST NOT include
GSS-API framework specifies that authentication cannot proceed if application channel binding data in the GSS-API channel binding input
channel bindings do not match. to GSS_Accept_sec_context(). If the client channel binding flag was
"y" and the server does support channel binding then the server MUST
fail authentication. If the client channel binding flag was "p" the
server MUST include application channel binding data in the GSS-API
channel binding input to GSS_Accept_sec_context().
Client and servers MUST set the "chan_binding" parameter in the calls For more discussions of channel bindings, and the syntax of the
to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to channel binding data for various security protocols, see [RFC5056].
NULL.
Implementations SHOULD set the "client_cbqops" and "server_cbqops" to 6. Examples
no security layer and instead depend on the session security afforded
by the bound-in channel.
In order to accomodate the requirement in [RFC5056] "Authentication Example #1: a one round-trip GSS-API context token exchange, no
frameworks and mechanisms that support channel binding MUST channel binding, optional authzid given.
communicate channel binding failure to applications" implementations
assert a bit in the security layer bitmask (see Section 9) on
negotiation failures.
Use of no SASL security layers in combination with channel binding C: Request authentication exchange
should provide better performance than using SASL security layers S: Empty Challenge
over secure channels, and better security characteristics than using C: nauthzid=someuser, <initial context token with standard
no SASL security layers over secure channels without channel binding. header removed>
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
For more discussions of channel bindings, and the syntax of the Example #2: a one and one half round-trip GSS-API context token
channel binding data for various security protocols, see [RFC5056]. exchange.
For easy reference, the channel binding format used for The Transport
Layer Security (TLS) Protocol [RFC4346] is specified in
[I-D.altman-tls-channel-bindings].
6. Protocol Overview C: Request authentication exchange
S: Empty Challenge
C: nauthzid=someuser, <initial context token with standard
header removed>
S: Send reply context token as is
C: Send reply context token as is
S: Outcome of authentication exchange
This section describe several high-level protocol exchanges. The Example #3: a two round-trip GSS-API context token exchange.
descriptions do not assume any properties of the actual GSS-API
mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
and to some extent implementation and policy choices, will dictate
which packets are sent in what order. The protocol exchanges are
examples and other exchanges are permitted and will occur.
An informal pseudo-language is used to describe the packets sent C: Request authentication exchange
below. GS2_Wrap refer to the operation of calling GS2_Wrap on the S: Empty Challenge
indicated fields, formatted in the structures described earlier. C: nauthzid=someuser, <initial context token with standard
GSS_Init_sec_context and GSS_Accept_sec_context refer to the context header removed>
token generated by calling the respective function. The GS2 SASL S: Send reply context token as is
Message is denoted as [Context_token, Wrap_token], and the length C: Send reply context token as is
fields are not mentioned. S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
An authentication exchange using GS2 may look like: Example #4: using channel binding.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: Send [GSS_Init_sec_context, ""] token C: yauthzid=someuser, <initial context token with standard
... header removed>
S: After PROT_READY is set, S: Send reply context token as is
send [GSS_Accept_sec_context,
GS2_Wrap(server_qops | server_maxbuf]
...
C: After PROT_READY is set,
send [GSS_Init_sec_context,
GS2_Wrap (client_qop | client_maxbuf | authzid)]
S: Send [GSS_Accept_sec_context, ""] token
C: Send [GSS_Init_sec_context, ""] token
... ...
S: Outcome of authentication exchange
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].
The next example illustrate when the client sends its Wrap token 7. Authentication Conditions
first.
C: Request authentication exchange Authentication MUST NOT succeed if any one of the following
S: Empty Challenge conditions are true:
C: Send [GSS_Init_sec_context, ""] token
...
C: After PROT_READY is set,
send [GSS_Init_sec_context,
GS2_Wrap(client_qops | client_maxbuf |
channel_binding_length=0 | authzid)]
...
S: After PROT_READY is set,
send [GSS_Accept_sec_context,
GS2_Wrap (server_qop | server_maxbuf)]
C: Send [GSS_Init_sec_context, ""] token
S: Send [GSS_Accept_sec_context, ""] token
...
S: Outcome of authentication exchange
If the protocol profile support the optional initial client response, o GSS_Init/Accept_sec_context() return anything other than
the first empty message can be optimized away, and then the protocol GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
exchange will look like: o If the client's GS2 channel binding flag was "y" and the server
supports channel binding.
o If the client requires use of channel binding and the server did
not advertise support for channel binding.
o Authorization of client principal (i.e., src_name in
GSS_Accept_sec_context()) to requested authzid failed.
o If the client is not authorized to the requested authzid or an
authzid could not be derived from the client's initiator principal
name.
C: Request authentication exchange and 8. GSS-API Parameters
send [GSS_Init_sec_context, ""] token
S: Send [GSS_Accept_sec_context, ""] token
...
S: Outcome of authentication exchange
If the protocol profile can also send additional information when GS2 does not use any GSS-API per-message tokens. Therefore the
indicating the outcome of the authentication, then the protocol setting of req_flags related to per-message tokens is irrelevant.
exchange will look like:
C: Request authentication exchange and 9. Naming
send [GSS_Init_sec_context, ""] token
S: Send [GSS_Accept_sec_context, ""] token
...
C: Send [GSS_Init_sec_context, ""] token
S: Indicate successful authentication and
send [GSS_Accept_sec_context, ""] token
as additional information.
If the PROT_READY flag is never set by the GSS-API mechanism, the There's no requirement that any particular GSS-API name-types be
GS2_Wrap message will be sent after the context has been established. used. However, typically SASL servers will have host-based acceptor
The protocol may look like: principal names (see [RFC2743] section 4.1) and clients will
typically have username initiator principal names (see [RFC2743]
section 4.2).
C: Request authentication exchange 10. GSS_Mechanism_SASLname call
...
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
a token, send ["", GS2_Wrap(server_qops | server_maxbuf)]
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
output a token, send
["", GS2_Wrap(client_qop | client_maxbuf |
channel_binding_length=0 | authzid)]
S: Outcome of authentication exchange
Alternatively, if the client finishes first, it may look like: To allow SASL implementations to query for the SASL mechanism name of
a GSS-API mechanism, we specify a new GSS-API function for this
purpose.
C: Request authentication exchange Inputs:
...
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
token, send ["", GS2_Wrap(client_qops | client_maxbuf |
channel_binding_length=0 | authzid)]
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
output a token, send ["", GS2_Wrap(server_qop | server_maxbuf |
channel_binding_length=0)]
S: Outcome of authentication exchange
Adding channel bindings to the last examples, gives the following o desired_mech OBJECT IDENTIFIER
complex situation. Here the client request confidentiality for the
application data if channel binding fails but no SASL security layer
if channel binding negotiation succeeds:
C: Request authentication exchange Outputs:
...
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
token, send [GSS_Init_sec_context,
GS2_Wrap(client_qops=0x04 | client_maxbuf |
channel_binding_length=n |
client_cbqops=0x01 | channel_binding_data |
authzid)]
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
output a token, send ["",
GS2_Wrap(server_qop | server_maxbuf |
channel_binding_length=0)]
S: Outcome of authentication exchange
If the protocol support initial data from the client, and the o sasl_mech_name OCTET STRING -- SASL name for this mechanism
PROT_READY flag is set in the client after the first call to (really, ASCII)
GSS_Init_sec_context, and the server can send additional data to the
client when indicating successful authentication, the following
protocol exchange will occur.
C: Request authentication exchange and o mech_name UTF-8 STRING -- name of this mechanism, possibly
send [GSS_Init_sec_context, localized
GS2_Wrap (client_qops | client_maxbuf |
channel_binding_length=0 | authzid)] token
S: Indicate successful authentication and
send [GSS_Accept_sec_context,
GS2_Wrap(server_qop | server_maxbuf)] token
as additional information.
The last example illustrate the optimal (round-trip wise) o mech_description UTF-8 STRING -- possibly localized
authentication possible using this protocol. description of this mechanism.
7. Authentication Conditions Return major_status codes:
Authentication MUST NOT succeed if any one of the following o GSS_S_COMPLETE indicates successful completion, and that output
conditions are true: parameters holds correct information.
o An invalid SASL token is received (e.g., length field checks o GSS_S_BAD_MECH indicates that a disred_mech was unsupported by
discussed in section 4.1 fail). the GSS-API implementation.
o GSS_Init/Accept_sec_context() return anything other than The GSS_Mechanism_SASLname call is used to get the SASL mechanism
GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. name for a GSS-API mechanism. It also returns a name and
description of the mechanism in a human readable form.
o GSS_Wrap() returns anything other than GSS_S_COMPLETE. 10.1. gss_mechanism_saslname
o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There The C binding for the GSS_Mechanism_SASLname call is as follows.
can't be supplementary status codes in GS2 at this point, so any
indications of out of order processing or replays is fatal.)
o The token returned from GSS_Unwrap fail to parse correctly (e.g., OM_uint32 gss_mechanism_saslname(
too short, invalid maximum buffer size) as the expected Wrap OM_uint32 *minor_status,
token. const gss_OID desired_mech,
gss_buffer_t sasl_mech_name,
gss_buffer_t mech_name,
gss_buffer_t mech_description,
);
o Local policy reject the attempt. For example, client and server Purpose:
can't agree on qop proposal, or channel binding negotiation
failed.
o (server-side) Authorization of client principal (i.e., src_name in Output the SASL mechanism name of a GSS-API mechanism. Also output
GSS_Acecpt_sec_context) to requested authzid failed. a name and description of the mechanism in a human readable form.
8. GSS-API Parameters Parameters:
The implementation MAY set any GSSAPI flags or arguments not minor_status Integer, modify
mentioned in this specification as is necessary for the Mechanism specific status code.
implementation to enforce its security policy.
9. Security Layer Bits Function value: GSS status code
The fields "client_qops", "server_qops", "client_cbqops", and GSS_S_COMPLETE Successful completion
"server_cbqops" are bit-fields that encode a set of requested quality
of protection. The fields "client_qop" and "server_qop" encode a
single quality of protection value.
The "client_qop" and "server_qop" will contains the chosen security GSS_S_BAD_MECH The desired_mech OID is unsupported
layer.
Note that "client_qop" and "server_qop" MAY indicate a quality of 11. GSS_Inquire_mech_for_SASLname call
protection that was not offered by the server and client,
respectively. This SHOULD only be used when the server or client
(respectively) would otherwise fail the entire authentication
exchange. The server/client that receives a "client_qop"/
"server_qop" MUST verify that it corresponds to an acceptable
security level.
Whether the channel binding negotiation is successful or not may To allow SASL clients to more efficiently identify which GSS-API
influence the security layer selection. The most significant bit is mechanism a particular SASL mechanism name refers to we specify a new
used to signal failed channel binding negotiation. Implementations GSS-API utility function for this purpose.
MUST set the bit if channel bindings were provided from the other end
and a local channel binding is absent or not equal. Implementation
MUST clear the bit otherwise.
The security layers and their corresponding bit-masks are as follows: Inputs:
1 No security layer. o sasl_mech_name OCTET STRING -- SASL name of mechanism
2 Integrity protection. (really, ASCII)
Sender calls GSS_Wrap with conf_flag set to FALSE.
4 Confidentiality protection.
Sender calls GSS_Wrap with conf_flag set to TRUE.
8-64 Reserved.
128 Channel binding negotiation failed.
The bit-masks 8-64 are reserved and may be defined in the future; Outputs:
bits which are not understood MUST be negotiated off.
When decoding any received data with GSS_Unwrap the major_status o mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
other than the GSS_S_COMPLETE MUST be treated as a fatal error. and not "default" specifier
For integrity and confidentiality protection, GS2 negotiates the Return major_status codes:
maximum size of the output_message to send. Implementations can use
the GSS_Wrap_size_limit call to determine the corresponding maximum
size input_message.
9.1. Examples o GSS_S_COMPLETE indicates successful completion, and that output
parameters holds correct information.
When no security layer is negotiated the octet will encode an integer o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
1 as follows. had the indicated sasl_mech_name.
7 6 5 4 3 2 1 0 The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
+-+-+-+-+-+-+-+-+ mechanism OID associated with a SASL mechanism name.
|0|0|0|0|0|0|0|1|
+-+-+-+-+-+-+-+-+
When integrity is negotiated the octet will encode an integer 2 as 11.1. gss_inquire_mech_for_saslname
The C binding for the GSS_Inquire_mech_for_SASLname call is as
follows. follows.
7 6 5 4 3 2 1 0 OM_uint32 gss_inquire_mech_for_saslname(
+-+-+-+-+-+-+-+-+ OM_uint32 *minor_status,
|0|0|0|0|0|0|1|0| const gss_buffer_t sasl_mech_name,
+-+-+-+-+-+-+-+-+ gss_OID *mech_type
);
When confidentiality is negotiated, and channel binding negotiation Purpose:
failed, the octet will encode an integer 128+4=132 as follows.
7 6 5 4 3 2 1 0 Output GSS-API mechanism OID of mechanism associated with given
+-+-+-+-+-+-+-+-+ sasl_mech_name.
|1|0|0|0|0|1|0|0|
+-+-+-+-+-+-+-+-+
When a bitmask that indicates that all security layers are Parameters:
acceptable, the octet will encode an integer 1+2+4=7 as follows.
7 6 5 4 3 2 1 0 minor_status Integer, modify
+-+-+-+-+-+-+-+-+ Mechanism specific status code.
|0|0|0|0|0|1|1|1|
+-+-+-+-+-+-+-+-+
10. Non-integrity capable GSS-API mechanisms Function value: GSS status code
Mechanisms that do not support integrity can be used with GS2, but GSS_S_COMPLETE Successful completion
some security features cannot be provided, in particular including
channel bindings, security layers, and integrity protection of the
authorization identity.
Channel bindings and security layers MUST NOT be negotiated when the GSS_S_BAD_MECH The desired_mech OID is unsupported
GSS-API mechanism do not support integrity. It should also be
understood that the authorization identity is not integrity
protected.
Whether a mechanism supports integrity or not, for the purpose of 12. Security Layers
GS2, is decided by whether the integ_avail output variable from
GSS_Init_sec_context (for clients) and GSS_Accept_sec_context (for
servers). If integ_avail is FALSE, integrity is not supported.
There is a potential interoperability problem if a client call GS2 does not currently support SASL security layers. Applications
GSS_Init_sec_context with integ_req_flag of TRUE and the context that need integrity protection or confidentiality and integrity
negotiation fails because the mechanism (due to design, the protection MUST use either channel binding to a secure external
capability of the credentials, or policy) cannot provide per-message channel or a SASL mechanism that does provide security layers.
protection. Calling GSS_Init_sec_context with a FALSE integ_req_flag
instead is not optimal, since a mechanism may then negotiate less
security than it would have otherwise done.
It is RECOMMENDED that implementations only ever call NOTE WELL: the GS2 client's first authentication message MUST always
GSS_Init_sec_context with a integ_req_flag of FALSE when it knows start with "F", "n", "y" or "p", otherwise the server MUST fail
that the particular GSS-API mechanism will not be able to negotiate authentication. This will allow us to add support for security
per-message protection services. 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.
Implementations MAY have a policy to disallow non-integrity capable [A sketch of how to add sec layer support... Add a way for the
mechanisms, and always call GSS_Init_sec_context with the client to: a) make an offer of sec layers and max buffer, b) make an
integ_req_flag set to TRUE. 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.]
11. 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 under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The
Kerberos V5 mechanism may also be used with the GS2 family. This Kerberos V5 mechanism may also be used with the GS2 family. This
causes an interopability problem, which is discussed and resolved causes an interopability problem, which is discussed and resolved
below. below.
11.1. The interoperability problem 13.1. The interoperability problem
The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos
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 authentication negotiation will fail. GS2 family, the mechanism negotiation will fail.
11.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 Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which The SASL "GSSAPI" mechanism lacks support for channel bindings, which
could enable certain tunnel attacks [mitm]. means that using an external secure channel may not be sufficient
protection against active attackers (see [RFC5056], [mitm]).
11.3. Additional recommendations 13.3. Additional Recommendations
It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism If the application requires security layers then it MUST prefer the
rather than through the "GSSAPI" mechanism, if both are available, SASL "GSSAPI" mechanism over "KerberosV-GS2".
because of the additional features in the GS2 mechanism.
12. Mechanisms that negotiate other mechanisms If the application can use channel binding to an external channel
then it is RECOMMENDED that it select Kerberos V5 through the GS2
mechanism rather than the "GSSAPI" mechanism.
14. Mechanisms that negotiate other mechanisms
A GSS-API mechanism that negotiate other mechanisms interact badly A GSS-API mechanism that negotiate other mechanisms interact badly
with the SASL mechanism negotiation. There are two problems. The with the SASL mechanism negotiation. There are two problems. The
first is an interoperability problem and the second is a security 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.
12.1. The interoperability problem 14.1. The interoperability problem
If a client implement GSS-API mechanism X, potentially negotiated If a client implement GSS-API mechanism X, potentially negotiated
through a GSS-API mechanism Y, and the server also implement GSS-API through a GSS-API mechanism Y, and the server also implement 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.
12.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 negotiate negotiate mechanism X by using a GSS-API mechanism that negotiate
other mechanisms (such as SPNEGO), it may end up using mechanism Z other mechanisms (such as SPNEGO), it may end up using mechanism Z
when it ideally should have used mechanism Y. For this reason, the when it ideally should have used mechanism Y. For this reason, the
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.
12.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. This specifically exclude negotiating with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
SPNEGO [RFC4178] under GS2. be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST
NOT choose the SPNEGO mechanism under any circumstances. [What about
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.
13. IANA Considerations 15. IANA Considerations
The SASL names for the Kerberos V GSS-API mechanism [RFC4121]
[RFC1964] used via GS2 SHALL be "KerberosV-GS2" and "KerberosV-GS2-
PLUS".
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" MUST NOT be used. These names are
provided as a convienience for SASL library implementors.
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 which conform to this document. The
IANA is directed to place a statement to that effect in the sasl- IANA is directed to place a statement to that effect in the sasl-
mechanisms registry. 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.
14. Security Considerations 16. Security Considerations
The security provided by GS2 depends on the security provided by the
GSS-API mechanism. If the mechanism do not provide integrity
protection, the authorization identity can be replaced by a man in
the middle, and channel bindings and security layers cannot be
negotiated. Therefor, it is generally recommended against using any
GSS-API mechanism widely on the Internet that do not support
integrity.
Because the negotiation of a particular GSS-API mechanism may be done
in the clear, it is important for the GSS-API mechanisms to be
designed such that an active attacker cannot obtain an authentication
with weaker security properties by modifying the challenges and
responses. This is a generic design critera for the GSS-API
mechanisms used under GS2.
GS2 permits channel binding negotiation to fail. Implementation may Security issues are also discussed throughout this memo.
have a local policy to reject authentication attempts in this case.
When a server or client supports multiple GSS-API mechanisms, each of The security provided by a GS2 mechanism depends on the security of
which has a different security strength, it is possible for an active the GSS-API mechanism. The GS2 mechanism family depends on channel
attacker to cause a party to use the least secure mechanism binding support, so GSS-API mechanisms that do not support channel
supported. This problem and a solution is discussed in section 6.1.2 binding cannot be successfully used as SASL mechanisms via the GS2
of [RFC4422], but some additional methods to mitigate the problem bridge.
include:
1. Use of an integrity protected transport, such as TLS [RFC4346]. Because GS2 does not support security layers it is strongly
To protect against certain tunnel attacks [mitm], channel RECOMMENDED that channel binding to a secure external channel be
bindings need to be used. used. Successful channel binding eliminates the possibility of man-
in-the-middle (MITM) attacks, provided that the external channel and
its channel binding data are secure and provided that the GSS-API
mechanism used is secure. Authentication failure because of channel
binding failure may indicate that an MITM attack was attempted, but
note that a real MITM attacker would likely attempt to close the
connection to the client or simulate network partition , thus MITM
attack detection is heuristic.
2. A client or server which supports mechanisms of different Use of channel binding will also protect the SASL mechanism
strengths should have a configurable minimum strength that it negotiation -- if there is no MITM then the external secure channel
will use. It is not sufficient for this minimum strength check will have protected the SASL mechanism negotiation.
to only be on the server, since an active attacker can change
which mechanisms the client sees as being supported, causing the
client to send authentication credentials for its weakest
supported mechanism. This solution, however, is not guaranteed
to lead to the most secure mechanism supported by both parties,
and is therefor only recommended as an additional precaution.
The channel binding is sent without privacy protection and knowledge The channel binding data MAY be sent (byt the actual GSS-API
of it is assumed to provide no advantage to an attacker. This is a mechanism used) without confidentiality protection and knowledge of
property that has to be considered when specifying channel bindings it is assumed to provide no advantage to an MITM (who can, in any
for a security protocol that will be used with GS2. case, compute the channel binding data independently). If the
external channel does not provide confidentiality protection and the
GSS-API mechanism does not provide confidentiality protection for the
channel binding data, then passive attackers (eavesdroppers) can
recover the channel binding data. See [RFC5056].
When constructing the input_name_string, the client should not When constructing the input_name_string for GSS_Import_name() with
the 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].
The GS2 protocol hard code the SHA-1 algorithm for computing the GS2 does not directly use any cryptographic algorithms, therefore it
mechanism names. It is not possible to negotiate another hash is automatically "algorithm agile", or, as agile as the GSS-API
algorithm. However, no traditional cryptographic hash properties mechanisms that are available for use in SASL apoplications via GS2.
(such as collision resistance or pre-image resistance) are required
nor assumed. The required and assumed property is that it is
statistically unlikely that two different DER-encoded OID's share the
same first 10 octets of the SHA-1 value. It is possible to
practically confirm that the SHA-1 algorithm has the necessary
property, by testing many different inputs.
Additional security considerations are in the SASL and GSSAPI The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
specifications. Additional security considerations for the Kerberos channel binding [RFC5056], any external channels (such as TLS,
V5 GSSAPI mechanism can be found in [RFC1964]. We stress that [RFC5246], channel binding types (see the IANA channel binding type
service names should not be canonicalized using an unsecured registry), and GSS-API mechanisms (such as the Kerberos V mechanism
directory service such as the DNS without DNSSEC. Security issues [RFC4121] [RFC1964]), may also apply.
are also discussed throughout this memo.
15. Acknowledgements 17. Acknowledgements
The history of GS2 can be traced to the GSSAPI mechanism described in The history of GS2 can be traced to the "GSSAPI" mechanism originally
RFC 2222. The GSSAPI mechanism had some drawbacks, which created a specified by RFC2222. This document was derived from
need for an improved version. 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 author. 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
acknowledged. In particular, ideas and feedback from Sam Hartman, acknowledged. In particular, ideas and feedback from Sam Hartman,
Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document
improved the document and the protocol. and the protocol.
16. References 18. References
16.1. Normative References 18.1. Normative References
[FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[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.
[ITU.X690.1994]
International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994.
[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.
16.2. Informative References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[CCITT.X690.2002]
International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002.
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
(SPKM)", RFC 2025, October 1996.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application Simple and Protected Generic Security Service Application
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.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(SPKM)", RFC 2025, October 1996. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[I-D.altman-tls-channel-bindings] [I-D.newman-auth-scram]
Altman, J. and N. Williams, "On the Use of Channel Menon-Sen, A., Melnikov, A., and C. Newman, "Salted
Bindings to Secure Channels", Challenge Response (SCRAM) SASL Mechanism",
draft-altman-tls-channel-bindings-01 (work in progress), draft-newman-auth-scram-10 (work in progress),
December 2006. February 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-02 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-04
(work in progress), June 2006. (work in progress), March 2008.
[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.
Author's Address Authors' Addresses
Simon Josefsson Simon Josefsson
SJD AB
Hagagatan 24
Stockholm 113 47
SE
Email: simon@josefsson.org Email: simon@josefsson.org
URI: http://josefsson.org/
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
USA
Full Copyright Statement Email: Nicolas.Williams@sun.com
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 150 change blocks. 
795 lines changed or deleted 540 lines changed or added

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