draft-ietf-sasl-gs2-09.txt   draft-ietf-sasl-gs2-10.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Intended status: Standards Track Intended status: Standards Track
Expires: April 11, 2008 Expires: January 14, 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-09 draft-ietf-sasl-gs2-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 April 11, 2008. This Internet-Draft will expire on January 14, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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/GSS-API
mechanism: it is more general, uses fewer messages for the 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 a SASL-specific
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12 4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12
4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12 4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12
4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13 4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13
4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14 4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14
4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14 4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22 9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22
9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24 10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24
11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25 11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25
11.1. The interoperability problem . . . . . . . . . . . . . . . 25 11.1. The interoperability problem . . . . . . . . . . . . . . . 25
11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25 11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25
11.3. Additional recommendations . . . . . . . . . . . . . . . . 25 11.3. Additional recommendations . . . . . . . . . . . . . . . . 25
12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26 12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26
12.1. The interoperability problem . . . . . . . . . . . . . . . 26 12.1. The interoperability problem . . . . . . . . . . . . . . . 26
12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26 12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26
12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26 12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Introduction 1. Introduction
Generic Security Service Application Program Interface (GSS-API) [3] Generic Security Service Application Program Interface (GSS-API)
is a framework that provide security services to applications. [RFC2743] is a framework that provide security services to
Simple Authentication and Security Layer (SASL) [2] is a framework to applications. Simple Authentication and Security Layer (SASL)
provide authentication and security layers for connection based [RFC4422] is a framework to provide authentication and security
protocols. This document describe how to use a GSS-API mechanism in layers for connection based protocols. This document describe how to
a connection-based protocol using the SASL framework. use a GSS-API mechanism in a connection-based protocol using the SASL
framework.
All GSSAPI mechanisms are implicitly registered for use within SASL All GSSAPI mechanisms are implicitly registered for use within SASL
by this specification. The SASL mechanism defined in this document by this specification. The SASL mechanism defined in this document
is known as the GS2 family. is known as the GS2 family.
The "Kerberos V5 GSS-API mechanism" [10] is also supported in SASL The "Kerberos V5 GSS-API mechanism" [RFC1964] is also supported in
through "SASL GSSAPI mechanisms" [12]. The difference between that SASL through "SASL GSSAPI mechanisms" [RFC4752]. The difference
protocol and the one described here, is that this protocol offer more between that protocol and the one described here, is that this
features (i.e., channel bindings and round-trip optimizations) while protocol offer more features (i.e., channel bindings and round-trip
the other protocol is more widely deployed. There are optimizations) while the other protocol is more widely deployed.
interoperability concerns by having the same GSS-API mechanism There are interoperability concerns by having the same GSS-API
available under more than one SASL mechanism name, see the section mechanism available under more than one SASL mechanism name, see the
"Interoperability with the GSSAPI mechanism" below. section "Interoperability with the GSSAPI mechanism" below.
There are interoperability and security concerns if this SASL There are interoperability and security concerns if this SASL
mechanism is used together with a GSS-API mechanism that negotiate mechanism is used together with a GSS-API mechanism that negotiate
other GSS-API mechanisms (such as SPNEGO [11]), see the section other GSS-API mechanisms (such as SPNEGO [RFC4178]), see the section
"Mechanisms that negotiate other mechanisms" below. "Mechanisms that negotiate other mechanisms" below.
There are interoperability and security concerns with GSSAPI There are interoperability and security concerns with GSSAPI
mechanism that do not provide integrity, see the section "Non- mechanism that do not provide integrity, see the section "Non-
integrity capable GSS-API mechanisms" below. integrity capable GSS-API mechanisms" below.
SASL mechanism names starting with "GS2-" are reserved for SASL SASL mechanism names starting with "GS2-" are reserved for SASL
mechanisms which conform to this document. mechanisms which conform to this document.
The IESG is considered to be the owner of all SASL mechanisms which The IESG is considered to be the owner of all SASL mechanisms which
conform to this document. This does not necessarily imply that the conform to this document. This does not necessarily imply that the
IESG is considered to be the owner of the underlying GSSAPI IESG is considered to be the owner of the underlying GSSAPI
mechanism. mechanism.
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 [1]. 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 The SASL mechanism name for a GSS-API mechanism is the concatenation
of the string "GS2-" and the Base32 encoding [6] (with an upper case of the string "GS2-" and the Base32 encoding [RFC4648] (with an upper
alphabet) of the first ten bytes of the binary SHA-1 hash [4] string case alphabet) of the first ten bytes of the binary SHA-1 hash
computed over the ASN.1 DER encoding [7], including the tag and [FIPS.180-1.1995] string computed over the ASN.1 DER encoding
length octets, of the GSS-API mechanism's Object Identifier. The [ITU.X690.1994], including the tag and length octets, of the GSS-API
Base32 rules on padding characters and characters outside of the mechanism's Object Identifier. The Base32 rules on padding
base32 alphabet are not relevant to this use of Base32. If any characters and characters outside of the base32 alphabet are not
padding or non-alphabet characters are encountered, the name is not a relevant to this use of Base32. If any padding or non-alphabet
GS2 family mechanism name. characters are encountered, the name is not a GS2 family mechanism
name.
3.2. Computing mechanism names manually 3.2. Computing mechanism names manually
The SASL mechanism name may be computed manually. This is useful The SASL mechanism name may be computed manually. This is useful
when the set of supported GSS-API mechanisms is known in advance. It when the set of supported GSS-API mechanisms is known in advance. It
also obliterate the need to implement Base32, SHA-1 and DER in the also obliterate the need to implement Base32, SHA-1 and DER in the
SASL mechanism. The computed mechanism name can be used directly in SASL mechanism. The computed mechanism name can be used directly in
the implementation, and the implementation need not concern itself the implementation, and the implementation need not concern itself
with that the mechanism is part of a mechanism family. with that the mechanism is part of a mechanism family.
3.3. Examples 3.3. Examples
The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1. The ASN.1 The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The
DER encoding of the OID, including the tag and length, is (in hex) 06 ASN.1 DER encoding of the OID, including the tag and length, is (in
07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER
(in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad. encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
Convert the first ten octets to binary, and re-group them in groups 27 86 61 ad. Convert the first ten octets to binary, and re-group
of 5, and convert them back to decimal, which results in these them in groups of 5, and convert them back to decimal, which results
computations: in these computations:
hex: hex:
1c f8 f4 2b 5a 9f 80 fa e9 f8 1c f8 f4 2b 5a 9f 80 fa e9 f8
binary: binary:
00011100 11111000 11110100 00101011 01011010 00011100 11111000 11110100 00101011 01011010
10011111 10000000 11111010 11101001 11111000 10011111 10000000 11111010 11101001 11111000
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 7, line 4 skipping to change at page 7, line 20
10011111 10000000 11111010 11101001 11111000 10011111 10000000 11111010 11101001 11111000
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 01111 10101 11010 01111 11000
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 15 21 26 15 24
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 P V 2 P Y
The last step translate each decimal value using table 3 in Base32 The last step translate each decimal value using table 3 in Base32
[6]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI
"GS2-DT4PIK22T6APV2PY". mechanism is "GS2-DT4PIK22T6APV2PY".
The OID for the Kerberos V5 GSS-API mechanism [10] 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 c8 45 aa
binary: binary:
skipping to change at page 7, line 36 skipping to change at page 7, line 51
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 01100 10000 10001 01101 01010
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 12 16 17 13 10
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 M Q R N K
The last step translate each decimal value using table 3 in Base32 The last step translate each decimal value using table 3 in Base32
[6]. 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 is "GS2-QLJHGJLWNPLMQRNK".
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.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
skipping to change at page 13, line 23 skipping to change at page 13, line 23
The optional field "client_cbqops" is present only if The optional field "client_cbqops" is present only if
"channel_binding_length" is non-zero, and indicate the client's "channel_binding_length" is non-zero, and indicate the client's
preferred quality of protection if channel binding negotiation preferred quality of protection if channel binding negotiation
succeeds. The quality of protection values are defined in section 9. succeeds. The quality of protection values are defined in section 9.
The optional field "channel_binding_data" is present only if The optional field "channel_binding_data" is present only if
"channel_binding_length" is non-zero, and contain the actual channel "channel_binding_length" is non-zero, and contain the actual channel
binding data. binding data.
The optional field "authzid" contain the authorization identity. The The optional field "authzid" contain the authorization identity. The
authorization identity is encoded using UTF-8 [5]. The authorization authorization identity is encoded using UTF-8 [RFC3629]. The
identity is not terminated with the NUL (U+0000) character. Servers authorization identity is not terminated with the NUL (U+0000)
MUST validate that the authorization identity is valid UTF-8. character. Servers MUST validate that the authorization identity is
valid UTF-8.
4.3.3. Server last GS2_Wrap input 4.3.3. Server last GS2_Wrap input
The input to GS2_Wrap when the server sends a Wrap token field, after 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 receiving the Wrap token in the previous section from the client, is
as follows. as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 22 skipping to change at page 15, line 22
channel bindings do not match. channel bindings do not match.
Client and servers MUST set the "chan_binding" parameter in the calls Client and servers MUST set the "chan_binding" parameter in the calls
to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to
NULL. NULL.
Implementations SHOULD set the "client_cbqops" and "server_cbqops" to Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
no security layer and instead depend on the session security afforded no security layer and instead depend on the session security afforded
by the bound-in channel. by the bound-in channel.
In order to accomodate the requirement in [16] "Authentication In order to accomodate the requirement in [RFC5056] "Authentication
frameworks and mechanisms that support channel binding MUST frameworks and mechanisms that support channel binding MUST
communicate channel binding failure to applications" implementations communicate channel binding failure to applications" implementations
MUST provide a way to communicate channel binding failures to assert a bit in the security layer bitmask (see Section 9) on
applications. negotiation failures.
Use of no SASL security layers in combination with channel binding Use of no SASL security layers in combination with channel binding
should provide better performance than using SASL security layers should provide better performance than using SASL security layers
over secure channels, and better security characteristics than using over secure channels, and better security characteristics than using
no SASL security layers over secure channels without channel binding. no SASL security layers over secure channels without channel binding.
For more discussions of channel bindings, and the syntax of the For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [8]. For channel binding data for various security protocols, see [RFC5056].
easy reference, the channel binding format used for The Transport For easy reference, the channel binding format used for The Transport
Layer Security (TLS) Protocol [14] is specified in [16]. Layer Security (TLS) Protocol [RFC4346] is specified in
[I-D.altman-tls-channel-bindings].
6. Protocol Overview 6. Protocol Overview
This section describe several high-level protocol exchanges. The This section describe several high-level protocol exchanges. The
descriptions do not assume any properties of the actual GSS-API descriptions do not assume any properties of the actual GSS-API
mechanism. Protocol profiles, GSS-API mechanism specific behaviour, mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
and to some extent implementation and policy choices, will dictate and to some extent implementation and policy choices, will dictate
which packets are sent in what order. The protocol exchanges are which packets are sent in what order. The protocol exchanges are
examples and other exchanges are permitted and will occur. examples and other exchanges are permitted and will occur.
skipping to change at page 16, line 44 skipping to change at page 16, line 44
GS2_Wrap (client_qop | client_maxbuf | authzid)] GS2_Wrap (client_qop | client_maxbuf | authzid)]
S: Send [GSS_Accept_sec_context, ""] token S: Send [GSS_Accept_sec_context, ""] token
C: Send [GSS_Init_sec_context, ""] token C: Send [GSS_Init_sec_context, ""] token
... ...
S: Outcome of authentication exchange 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 [2]. the client. See section 3 of [RFC4422].
The next example illustrate when the client sends its Wrap token The next example illustrate when the client sends its Wrap token
first. first.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: Send [GSS_Init_sec_context, ""] token C: Send [GSS_Init_sec_context, ""] token
... ...
C: After PROT_READY is set, C: After PROT_READY is set,
send [GSS_Init_sec_context, send [GSS_Init_sec_context,
skipping to change at page 20, line 27 skipping to change at page 20, line 27
o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There
can't be supplementary status codes in GS2 at this point, so any can't be supplementary status codes in GS2 at this point, so any
indications of out of order processing or replays is fatal.) indications of out of order processing or replays is fatal.)
o The token returned from GSS_Unwrap fail to parse correctly (e.g., o The token returned from GSS_Unwrap fail to parse correctly (e.g.,
too short, invalid maximum buffer size) as the expected Wrap too short, invalid maximum buffer size) as the expected Wrap
token. token.
o Local policy reject the attempt. For example, client and server o Local policy reject the attempt. For example, client and server
can't agree on qop proposal. can't agree on qop proposal, or channel binding negotiation
failed.
o (server-side) Authorization of client principal (i.e., src_name in o (server-side) Authorization of client principal (i.e., src_name in
GSS_Acecpt_sec_context) to requested authzid failed. GSS_Acecpt_sec_context) to requested authzid failed.
8. GSS-API Parameters 8. GSS-API Parameters
The implementation MAY set any GSSAPI flags or arguments not The implementation MAY set any GSSAPI flags or arguments not
mentioned in this specification as is necessary for the mentioned in this specification as is necessary for the
implementation to enforce its security policy. implementation to enforce its security policy.
skipping to change at page 22, line 23 skipping to change at page 22, line 23
layer. layer.
Note that "client_qop" and "server_qop" MAY indicate a quality of Note that "client_qop" and "server_qop" MAY indicate a quality of
protection that was not offered by the server and client, protection that was not offered by the server and client,
respectively. This SHOULD only be used when the server or client respectively. This SHOULD only be used when the server or client
(respectively) would otherwise fail the entire authentication (respectively) would otherwise fail the entire authentication
exchange. The server/client that receives a "client_qop"/ exchange. The server/client that receives a "client_qop"/
"server_qop" MUST verify that it corresponds to an acceptable "server_qop" MUST verify that it corresponds to an acceptable
security level. security level.
Whether the channel binding negotiation is successful or not may
influence the security layer selection. The most significant bit is
used to signal failed channel binding negotiation. Implementations
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: The security layers and their corresponding bit-masks are as follows:
1 No security layer 1 No security layer.
2 Integrity protection. 2 Integrity protection.
Sender calls GSS_Wrap with conf_flag set to FALSE Sender calls GSS_Wrap with conf_flag set to FALSE.
4 Confidentiality protection. 4 Confidentiality protection.
Sender calls GSS_Wrap with conf_flag set to TRUE Sender calls GSS_Wrap with conf_flag set to TRUE.
8-64 Reserved.
128 Channel binding negotiation failed.
Other bit-masks may be defined in the future; bits which are not The bit-masks 8-64 are reserved and may be defined in the future;
understood MUST be negotiated off. bits which are not understood MUST be negotiated off.
When decoding any received data with GSS_Unwrap the major_status When decoding any received data with GSS_Unwrap the major_status
other than the GSS_S_COMPLETE MUST be treated as a fatal error. other than the GSS_S_COMPLETE MUST be treated as a fatal error.
For integrity and confidentiality protection, GS2 negotiates the For integrity and confidentiality protection, GS2 negotiates the
maximum size of the output_message to send. Implementations can use maximum size of the output_message to send. Implementations can use
the GSS_Wrap_size_limit call to determine the corresponding maximum the GSS_Wrap_size_limit call to determine the corresponding maximum
size input_message. size input_message.
9.1. Examples 9.1. Examples
When no security layer is negotiated the octet will encode an integer When no security layer is negotiated the octet will encode an integer
1 as follows. 1 as follows.
0 1 2 3 4 5 6 7 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|1| |0|0|0|0|0|0|0|1|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
When integrity is negotiated the octet will encode an integer 2 as When integrity is negotiated the octet will encode an integer 2 as
follows. follows.
0 1 2 3 4 5 6 7 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|1|0| |0|0|0|0|0|0|1|0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
When confidentiality is negotiated the octet will encode an integer 4 When confidentiality is negotiated, and channel binding negotiation
as follows. failed, the octet will encode an integer 128+4=132 as follows.
0 1 2 3 4 5 6 7 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|0|0| |1|0|0|0|0|1|0|0|
+-+-+-+-+-+-+-+-+
When a bitmask that indicates that all security layers are
acceptable, the octet will encode an integer 1+2+4=7 as follows.
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|1|1|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
10. Non-integrity capable GSS-API mechanisms 10. Non-integrity capable GSS-API mechanisms
Mechanisms that do not support integrity can be used with GS2, but Mechanisms that do not support integrity can be used with GS2, but
some security features cannot be provided, in particular including some security features cannot be provided, in particular including
channel bindings, security layers, and integrity protection of the channel bindings, security layers, and integrity protection of the
authorization identity. authorization identity.
Channel bindings and security layers MUST NOT be negotiated when the Channel bindings and security layers MUST NOT be negotiated when the
skipping to change at page 25, line 7 skipping to change at page 25, line 7
GSS_Init_sec_context with a integ_req_flag of FALSE when it knows GSS_Init_sec_context with a integ_req_flag of FALSE when it knows
that the particular GSS-API mechanism will not be able to negotiate that the particular GSS-API mechanism will not be able to negotiate
per-message protection services. per-message protection services.
Implementations MAY have a policy to disallow non-integrity capable Implementations MAY have a policy to disallow non-integrity capable
mechanisms, and always call GSS_Init_sec_context with the mechanisms, and always call GSS_Init_sec_context with the
integ_req_flag set to TRUE. integ_req_flag set to TRUE.
11. Interoperability with the SASL "GSSAPI" mechanism 11. Interoperability with the SASL "GSSAPI" mechanism
The Kerberos V5 GSS-API [10] 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 [12]. The Kerberos V5 under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The
mechanism may also be used with the GS2 family. This causes an Kerberos V5 mechanism may also be used with the GS2 family. This
interopability problem, which is discussed and resolved below. causes an interopability problem, which is discussed and resolved
below.
11.1. The interoperability problem 11.1. The interoperability problem
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 authentication negotiation will fail.
11.2. Resolving the problem 11.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 Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
could enable certain tunnel attacks [18]. could enable certain tunnel attacks [mitm].
11.3. Additional recommendations 11.3. Additional recommendations
It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
rather than through the "GSSAPI" mechanism, if both are available, rather than through the "GSSAPI" mechanism, if both are available,
because of the additional features in the GS2 mechanism. because of the additional features in the GS2 mechanism.
12. Mechanisms that negotiate other mechanisms 12. 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
skipping to change at page 26, line 34 skipping to change at page 26, line 34
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 12.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. This specifically exclude negotiating
SPNEGO [11] under GS2. SPNEGO [RFC4178] under GS2.
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [17] The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech()
can be used to identify such mechanisms. [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
mechanisms.
13. IANA Considerations 13. IANA Considerations
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.
Subject: Registration of SASL mechanism GS2-* Subject: Registration of SASL mechanism GS2-*
SASL mechanism prefix: GS2- SASL mechanism prefix: GS2-
skipping to change at page 28, line 22 skipping to change at page 28, line 22
GSS-API mechanism widely on the Internet that do not support GSS-API mechanism widely on the Internet that do not support
integrity. integrity.
Because the negotiation of a particular GSS-API mechanism may be done 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 in the clear, it is important for the GSS-API mechanisms to be
designed such that an active attacker cannot obtain an authentication designed such that an active attacker cannot obtain an authentication
with weaker security properties by modifying the challenges and with weaker security properties by modifying the challenges and
responses. This is a generic design critera for the GSS-API responses. This is a generic design critera for the GSS-API
mechanisms used under GS2. mechanisms used under GS2.
GS2 permits channel binding negotiation to fail. Implementation may
have a local policy to reject authentication attempts in this case.
When a server or client supports multiple GSS-API mechanisms, each of When a server or client supports multiple GSS-API mechanisms, each of
which has a different security strength, it is possible for an active which has a different security strength, it is possible for an active
attacker to cause a party to use the least secure mechanism attacker to cause a party to use the least secure mechanism
supported. This problem and a solution is discussed in section 6.1.2 supported. This problem and a solution is discussed in section 6.1.2
of [2], but some additional methods to mitigate the problem include: of [RFC4422], but some additional methods to mitigate the problem
include:
1. Use of an integrity protected transport, such as TLS [14]. To 1. Use of an integrity protected transport, such as TLS [RFC4346].
protect against certain tunnel attacks [18], channel bindings To protect against certain tunnel attacks [mitm], channel
need to be used. bindings need to be used.
2. A client or server which supports mechanisms of different 2. A client or server which supports mechanisms of different
strengths should have a configurable minimum strength that it strengths should have a configurable minimum strength that it
will use. It is not sufficient for this minimum strength check will use. It is not sufficient for this minimum strength check
to only be on the server, since an active attacker can change to only be on the server, since an active attacker can change
which mechanisms the client sees as being supported, causing the which mechanisms the client sees as being supported, causing the
client to send authentication credentials for its weakest client to send authentication credentials for its weakest
supported mechanism. This solution, however, is not guaranteed supported mechanism. This solution, however, is not guaranteed
to lead to the most secure mechanism supported by both parties, to lead to the most secure mechanism supported by both parties,
and is therefor only recommended as an additional precaution. and is therefor only recommended as an additional precaution.
The channel binding is sent without privacy protection and knowledge The channel binding is sent without privacy protection and knowledge
of it is assumed to provide no advantage to an attacker. This is a of it is assumed to provide no advantage to an attacker. This is a
property that has to be considered when specifying channel bindings property that has to be considered when specifying channel bindings
for a security protocol that will be used with GS2. for a security protocol that will be used with GS2.
When constructing the input_name_string, the client should not When constructing the input_name_string, 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 [9] without DNSSEC [15]. System [RFC1034] without DNSSEC [RFC4033].
The GS2 protocol hard code the SHA-1 algorithm for computing the The GS2 protocol hard code the SHA-1 algorithm for computing the
mechanism names. It is not possible to negotiate another hash mechanism names. It is not possible to negotiate another hash
algorithm. However, no traditional cryptographic hash properties algorithm. However, no traditional cryptographic hash properties
(such as collision resistance or pre-image resistance) are required (such as collision resistance or pre-image resistance) are required
nor assumed. The required and assumed property is that it is nor assumed. The required and assumed property is that it is
statistically unlikely that two different DER-encoded OID's share the statistically unlikely that two different DER-encoded OID's share the
same first 10 octets of the SHA-1 value. It is possible to same first 10 octets of the SHA-1 value. It is possible to
practically confirm that the SHA-1 algorithm has the necessary practically confirm that the SHA-1 algorithm has the necessary
property, by testing many different inputs. property, by testing many different inputs.
Additional security considerations are in the SASL and GSSAPI Additional security considerations are in the SASL and GSSAPI
specifications. Additional security considerations for the Kerberos specifications. Additional security considerations for the Kerberos
V5 GSSAPI mechanism can be found in [10]. We stress that service V5 GSSAPI mechanism can be found in [RFC1964]. We stress that
names should not be canonicalized using an unsecured directory service names should not be canonicalized using an unsecured
service such as the DNS without DNSSEC. Security issues are also directory service such as the DNS without DNSSEC. Security issues
discussed throughout this memo. are also discussed throughout this memo.
15. Acknowledgements 15. 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 described in
RFC 2222. The GSSAPI mechanism had some drawbacks, which created a RFC 2222. The GSSAPI mechanism had some drawbacks, which created a
need for an improved version. 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 author.
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, Nicolas Williams, and Tom Yu
improved the document and the protocol. improved the document and the protocol.
16. References 16. References
16.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[3] 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.
[4] National Institute of Standards and Technology, "Secure Hash [FIPS.180-1.1995]
Standard", FIPS PUB 180-1, April 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>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[7] International Telecommunications Union, "Information Technology [ITU.X690.1994]
- ASN.1 encoding rules: Specification of Basic Encoding Rules International Telecommunications Union, "Information
(BER), Canonical Encoding Rules (CER) and Distinguished Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994.
[8] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", draft-williams-on-channel-binding-04 (work in Channels", RFC 5056, November 2007.
progress), August 2007.
16.2. Informative References 16.2. Informative References
[9] 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.
[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
June 1996. RFC 1964, June 1996.
[11] 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", RFC 4178, Program Interface (GSS-API) Negotiation Mechanism",
October 2005. RFC 4178, October 2005.
[12] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
and Security Layer (SASL) Mechanism", RFC 4752, November 2006. Authentication and Security Layer (SASL) Mechanism",
RFC 4752, November 2006.
[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
RFC 2025, October 1996. (SPKM)", RFC 2025, October 1996.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
"DNS Security Introduction and Requirements", RFC 4033, Rose, "DNS Security Introduction and Requirements",
March 2005. RFC 4033, March 2005.
[16] Altman, J. and N. Williams, "On the Use of Channel Bindings to [I-D.altman-tls-channel-bindings]
Secure Channels", draft-altman-tls-channel-bindings-01 (work in Altman, J. and N. Williams, "On the Use of Channel
progress), December 2006. Bindings to Secure Channels",
draft-altman-tls-channel-bindings-01 (work in progress),
December 2006.
[17] Williams, N., "Extended Generic Security Service Mechanism [I-D.ietf-kitten-extended-mech-inquiry]
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-02 (work Williams, N., "Extended Generic Security Service Mechanism
in progress), June 2006. Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-02
(work in progress), June 2006.
[18] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
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 Author's Address
Simon Josefsson Simon Josefsson
Email: simon@josefsson.org Email: simon@josefsson.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 34, line 44 skipping to change at line 1170
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 60 change blocks. 
124 lines changed or deleted 153 lines changed or added

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