draft-ietf-sasl-gs2-01.txt   draft-ietf-sasl-gs2.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Expires: December 28, 2006 Intended status: Standards Track
Expires: June 10, 2007
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-01 draft-ietf-sasl-gs2-04
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 33 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 December 28, 2006. This Internet-Draft will expire on June 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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. Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous SASL/GSS-API
mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports a SASL-specific
notion of channel binding.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Generating SASL Mechanism Names From GSS-API OIDs . . . . 3 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4
3.2. Computing Mechanism Names Manually . . . . . . . . . . . . 4 3.2. Computing mechanism names manually . . . . . . . . . . . . 4
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SASL Authentication Exchange Message Format . . . . . . . . . 5
4.1. SASL Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 6
4.3. Context Token . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 6
4.4. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 7
4.4.1. Wrap Token Input For Client Requests . . . . . . . . . 7 4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. WraP Token Input For Server Responses . . . . . . . . 8 4.3.1. Client first GSS_Wrap input . . . . . . . . . . . . . 9
4.4.3. Wrap Token Input For Server Requests . . . . . . . . . 9 4.3.2. Server last GSS_Wrap input . . . . . . . . . . . . . . 10
4.4.4. Wrap Token Input For Client Responses . . . . . . . . 9 4.3.3. Server first GSS_Wrap input . . . . . . . . . . . . . 11
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.4. Client last GSS_Wrap input . . . . . . . . . . . . . . 12
5.1. Name Of Tls Channel For Use As Channel Binding . . . . . . 11 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 14 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 16
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 14 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 15 9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 16
10. Interoperability With The Gssapi Mechanism . . . . . . . . . . 15 9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. The Interoperability problem . . . . . . . . . . . . . . . 15 10. Interoperability with the GSSAPI mechanism . . . . . . . . . . 18
10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 15 10.1. The interoperability problem . . . . . . . . . . . . . . . 18
10.3. Additional recommendations . . . . . . . . . . . . . . . . 15 10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18
11. Mechanisms That Negotiate Other Mechanisms . . . . . . . . . . 16 10.3. Additional recommendations . . . . . . . . . . . . . . . . 18
11.1. The Interoperability Problem . . . . . . . . . . . . . . . 16 11. Mechanisms that negotiate other mechanisms . . . . . . . . . . 18
11.2. Security Problem . . . . . . . . . . . . . . . . . . . . . 16 11.1. The interoperability problem . . . . . . . . . . . . . . . 19
11.3. Resolving the Problems . . . . . . . . . . . . . . . . . . 16 11.2. Security problem . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11.3. Resolving the problems . . . . . . . . . . . . . . . . . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 18 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
16.2. Informative References . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
Generic Security Service Application Program Interface (GSS-API) [3] Generic Security Service Application Program Interface (GSS-API) [3]
is a framework that provide security services to applications. is a framework that provide security services to applications.
Simple Authentication and Security Layer (SASL) [2] is a framework to Simple Authentication and Security Layer (SASL) [2] is a framework to
provide authentication and security layers for connection based provide authentication and security layers for connection based
protocols. This document describe how to use a GSS-API mechanism in protocols. This document describe how to use a GSS-API mechanism in
a connection-based protocol using the SASL framework. 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" [9] is also supported in SASL The "Kerberos V5 GSS-API mechanism" [10] is also supported in SASL
through "SASL GSSAPI mechanisms" [11]. The difference between that through "SASL GSSAPI mechanisms" [12]. The difference between that
protocol and the one described here, is that this protocol offer more protocol and the one described here, is that this protocol offer more
features (i.e., channel bindings and round-trip optimizations) while features (i.e., channel bindings and round-trip optimizations) while
the other protocol is more widely deployed. There are the other protocol is more widely deployed. There are
interoperability concerns by having the same GSS-API mechanism interoperability concerns by having the same GSS-API mechanism
available under more than one SASL mechanism name, see the section available under more than one SASL mechanism name, see the section
"Interoperability with the GSSAPI mechanism" below. "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 [10]), see the section other GSS-API mechanisms (such as SPNEGO [11]), see the section
"Mechanisms that negotiate other mechanisms" below. "Mechanisms that negotiate other 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 [1].
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 [5] (with an upper case of the string "GS2-" and the Base32 encoding [6] (with an upper case
alphabet) of the first ten bytes of the binary SHA-1 hash [4] string alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's computed over the ASN.1 DER encoding [8], including the tag and
Object Identifier. The Base32 rules on padding characters and length octets, of the GSS-API mechanism's Object Identifier. The
characters outside of the base32 alphabet are not relevant to this Base32 rules on padding characters and characters outside of the
use of Base32. If any padding or non-alphabet characters are base32 alphabet are not relevant to this use of Base32. If any
encountered, the name is not a GS2 family mechanism name. padding or non-alphabet 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. Example 3.3. Examples
For example, the OID for the SPKM-1 mechanism [12] is The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1. The ASN.1
1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01 DER encoding of the OID, including the tag and length, is (in hex) 06
05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is
1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad.
first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL Convert the first ten octets to binary, and re-group them in groups
mechanism name for the SPKM-1 GSSAPI mechanism is "GS2- of 5, and convert them back to decimal, which results in these
DT4PIK22T6EPV2PY". computations:
4. Packet Format hex:
1c f8 f4 2b 5a 9f 80 fa e9 f8
4.1. SASL Tokens binary:
00011100 11111000 11110100 00101011 01011010
10011111 10000000 11111010 11101001 11111000
All top-level SASL packets for the GS2 mechanism family follow the binary in groups of 5:
following format: 00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000 01111 10101 11010 01111 11000
decimal of each group:
3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24
Translating each decimal value using table 3 in Base32 [6] yields the
character sequence DT4PIK22T6APV2PY. Thus the SASL mechanism name
for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6APV2PY".
The OID for the Kerberos V5 GSS-API mechanism [10] is
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
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
decimal, which results in these computations:
hex:
82 d2 73 25 76 6b d6 c8 45 aa
binary:
10000010 11010010 01110011 00100101 01110110
01101011 11010110 11001000 01000101 10101010
binary in groups of 5:
10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011 01100 10000 10001 01101 01010
decimal of each group:
16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10
Translating each decimal value using table 3 in Base32 [6] yields the
character sequence QLJHGJLWNPLNQRNK. Thus the SASL mechanism name
for the Kerberos V5 GSSAPI mechanism is "GS2-QLJHGJLWNPLNQRNK".
4. SASL Authentication Exchange Message Format
4.1. SASL Messages
During the SASL authentication exchange for GS2, a number of messages
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context length | | Context length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Wrap token length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
/ Context token / / [Context token] /
/ --------------------/ / --------------------/
/ ---------------------/ / / ---------------------/ /
/--------------------/ / /--------------------/ /
/ [Wrap token] / / [Wrap token] /
/ / / /
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Context length" field is a 4 octet (32 bit) integer encoded in The "Context length" and "Wrap token length" fields each contain a 4
network byte order, it indicate the length of the "Context token" octet (32 bit) integer encoded in network byte order, that indicate
field. the length of the "Context token" and "Wrap token" fields,
respectively. A length of 0 means that a particular field is not
The "Flags" field is a 4 octet (32 bit) bitmask that holds flags that present.
influence the authentication process.
The "Context token" field contain a GSS-API context establishment The "Context token" field, if present, contain a GSS-API context
token generated by GSS_Init_sec_context or GSS_Accept_sec_context. establishment token generated by GSS_Init_sec_context or
GSS_Accept_sec_context.
The "Wrap token" field is optional, and if present will contain the The "Wrap token" field, if present, contain the output generated by
output generated by GSS_Wrap. GSS_Wrap.
The length field does not include the length of the length field The fields need not be aligned to 32-bit a boundary. There is no
itself. Whether the "Wrap token" field is included or not can be padding between fields.
infered from the length field; if the length field is shorter than
the entire packet size minus 4 octets, the "Wrap token" field is
present and begins after length+4 octets into the packet. The tokens
need not be aligned to 32-bit a boundary. There is no padding
between the tokens.
Packets shorter than 4 octets are invalid. If the length field is Messages shorter than or equal to 12 octets are invalid. From that
longer than the entire packet size, minus 4 octets, the packet is 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. invalid.
4.2. Flags During any successful authentication exchange, the client and server
will each send exactly one (non-empty) "Wrap token".
Bit 0 signal whether GSS-API Channel bindings are used. It is only
useful in the first token sent from the client, and MUST be set to 0
in all other tokens. The bit is called the "Native Channel Bindings"
bit. The client chooses whether to set this bit or not depending on
local policy or user requests.
The other bits are not specified and MUST be zero. If a bit is set Conforming implementations MUST NOT send additional data after the
that is not understood by the implementation, it MUST be ignored. 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.3. Context Token 4.2. Context Token Field
The format of the "Context token" field inside the SASL token are The format of the "Context token" field inside the SASL token are
defined by the GSS-API specifications, and the data is computed by defined by the GSS-API specifications, and the data is computed by
the GSS_Init_sec_context and GSS_Accept_sec_context functions. the GSS_Init_sec_context (for the client) and GSS_Accept_sec_context
(for the server) functions.
4.2.1. Client side
The client calls GSS_Init_sec_context, passing in The client calls GSS_Init_sec_context, passing in
input_context_handle of 0 (initially), mech_type of the GSSAPI input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of
mechanism for which this SASL mechanism is registered, the the GSSAPI mechanism for which this SASL mechanism is registered, the
chan_binding is set to NULL or the channel binding data depending on chan_binding is set to NULL, and targ_name equal to output_name from
the Native Channel Binding flag, and targ_name equal to output_name GSS_Import_Name called with input_name_type of
from GSS_Import_Name called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
"service@hostname" where "service" is the service name specified in "service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host the protocol's profile, and "hostname" is the fully qualified host
name of the server. If the client will be requesting a security 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 MUST pass the
integ_req_flag of TRUE. If the client intends to request a security
layer, it MUST also supply to the GSS_Init_sec_context a layer, it MUST also supply to the GSS_Init_sec_context a
mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an mutual_req_flag of TRUE, and a sequence_req_flag of TRUE. If the
integ_req_flag of TRUE. If the client will be requesting a security client will be requesting a security layer providing confidentiality
layer providing confidentiality protection, it MUST also supply to protection, it MUST also supply to the GSS_Init_sec_context a
the GSS_Init_sec_context a conf_req_flag of TRUE. If conf_req_flag of TRUE.
GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
should expect the server to issue a token in a subsequent challenge 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. or as additional information to the outcome of the authentication.
The client must pass the context token to another call to The client pass the context token to another call to
GSS_Init_sec_context, repeating the actions in this paragraph, until GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE
GSS_S_COMPLETE is returned or authentication is aborted. If the is returned or authentication is aborted.
server supply data beyond the context token, the context token should
be processed first, and then the overflow data should be passed to
GSS_Unwrap and the unwrapped data should be interpreted. During the
authentication exchange, the client will generate one Wrap token
using GSS_Wrap.
The server passes the first client response to GSS_Accept_sec_context If the server sent a (non-empty) "Wrap token", the context token is
as input_token, setting input_context_handle to 0 (initially), processed before processing the other tokens. This is required
mech_type of the GSSAPI mechanism for which this SASL mechanism is because GSS_Unwrap may need the context to be in the state it is
registered, the chan_binding set to NULL or the channel binding data after the "Context token" in the message has been processed.
depending on the Native Channel Binding bit, and acceptor_cred_handle
equal to output_cred_handle from GSS_Acquire_cred called with
desired_name equal to output_name from GSS_Import_name 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. The server must pass any resulting challenge
from the client to another call to GSS_Accept_sec_context, repeating
the actions in this paragraph, until GSS_S_COMPLETE is returned or
authentication is aborted. If the client supply data beyond the
context token, the context token should be processed first, and then
the overflow data should be passed to GSS_Unwrap and the unwrapped
data should be interpreted. During the authentication exchange, the
server will generate one Wrap token using GSS_Wrap.
4.4. Wrap Token When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
the context to ensure that it provides a level of protection
permitted by the client's security policy.
The Wrap token MUST NOT be sent before the PROT_READY flag has been 4.2.2. Server side
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 The server passes the first context token to GSS_Accept_sec_context
fully established. The GSS_Wrap token does not have to be sent as input_token, setting input_context_handle to GSS_C_NO_CONTEXT
directly when the PROT_READY flag is set. During any exchange, (initially), the chan_binding set to NULL, and a suitable
exactly one GSS_Wrap token is sent in each direction. The input to acceptor_cred_handle (see below).
the GSS_Wrap function MUST follow the format described below. If not
exactly one GSS_Wrap token is received by the client and by the Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
server, the authentication MUST fail. 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
examines 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 input to the GSS_Wrap function 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 If PROT_READY is never set by GSS_Init_sec_context or
GSS_Accept_sec_context, the flag is implied by successful context GSS_Accept_sec_context, the flag is implied by successful context
negotiation. This is for GSS-API v1 mechanisms that do not support negotiation. This is for GSS-API v1 mechanisms that do not support
PROT_READY. This may result in a SASL token consisting of a context PROT_READY. This may result in a SASL token consisting of a context
token length of 0 and a Wrap token. token length of 0 and a Wrap token.
The entity that sends its first Wrap token will have to specify a The entity that sends its first Wrap token will have to specify a
bitmap of supported and preferred quality of protection schemes. The bitmap of supported and preferred quality of protection schemes. The
entity that reply to the Wrap tokens will pick a scheme, based on the entity that replies to the Wrap tokens will pick a scheme, based on
bitmask and local policy. the bitmask and local policy. The quality of protection values are
defined in section 9.
Four input formats to the GSS_Wrap function are defined. The first Two pairs of input formats to the GSS_Wrap function are defined. The
two input formats are used when the client sends the GSS_Wrap token first pair is used when the client sends the GSS_Wrap token first and
first and the server reponds. The other two input formats are used the server responds. The other pair is used when the server sends
when the server sends the GSS_Wrap token first and the client the GSS_Wrap token first and the client responds.
responds.
The input formats below are passed to GSS_Wrap with conf_flag set to The inputs below are passed to GSS_Wrap with conf_flag set to FALSE,
FALSE, and the Wrap token output will be the generated and the Wrap token will be the generated output_message.
output_message.
Some fields in the input formats are optional, indicated by brackets Some fields in the input formats are optional, indicated by brackets
("[" and "]") and explained by the text below. ("[" and "]") and explained by the text below.
4.4.1. Wrap Token Input For Client Requests 4.3.1. Client first GSS_Wrap input
The input to GSS_Wrap when the client sends the GSS_Wrap token first The input to GSS_Wrap when the client sends a Wrap token field first
is as follows. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client_qops | client_maxbuf | | client_qops | client_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channel_binding_length | | channel_binding_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[client_cbqops]| [channel_binding_data] / |[client_cbqops]| [channel_binding_data] /
/ / / /
/ / [authzid] / / / [authzid] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "client_qops" integer indicate the client's preferred quality of The "client_qops" integer indicate the client's preferred quality of
protection if channel bindings are absent or the negotiation of the protection if channel bindings are absent or the negotiation of the
channel binding fails. channel binding fails. The quality of protection values are defined
in section 9.
The "client_maxbuf" field indicate the maximum protected buffer size The "client_maxbuf" field indicate the maximum protected buffer size
the client can receive. the client can receive in network byte order. It MUST be 0 if the
client doesn't advertise support for any security layer, the server
MUST verify this. Small values can make it impossible for the server
to send any protected message to the client, due to the overhead
added by GSS_Wrap, and the server MAY reject the authentication if it
detects this situation.
The "channel_binding_length" is a network byte order integer that The "channel_binding_length" is a network byte order integer that
indicate the length of the "channel_binding_data" field. indicate the length of the "channel_binding_data" field.
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. 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 [6]. The authorization authorization identity is encoded using UTF-8 [5]. The authorization
identity is not terminated with the NUL (U+0000) character. Servers identity is not terminated with the NUL (U+0000) character. Servers
MUST validate that the authorization identity is valid UTF-8. MUST validate that the authorization identity is valid UTF-8.
4.4.2. WraP Token Input For Server Responses 4.3.2. Server last GSS_Wrap input
The data format for input to GSS_Wrap when the server responds to the The input to GSS_Wrap when the server sends a Wrap token field, after
previous GSS_Wrap token data is as follows. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_qop | server_maxbuf | | server_qop | server_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "server_qop" field integer indicate the selected quality of The "server_qop" field integer indicate the selected quality of
protection. protection. The quality of protection values are defined in section
9.
The "server_maxbuf" field indicate the maximum data buffer size the The "server_maxbuf" field indicate the maximum protected data buffer
server can receive. It MUST be 0 if the server doesn't advertise size the server can receive in network byte order. It MUST be 0 if
support for any security layer, the client MUST verify this. 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.4.3. Wrap Token Input For Server Requests 4.3.3. Server first GSS_Wrap input
The data format for input to GSS_Wrap when the server sends the The input to GSS_Wrap when the server sends the Wrap token first is
GSS_Wrap token first 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_qops | server_maxbuf | | server_qops | server_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channel_binding_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[server_cbqops]| [channel_binding_data] / |[server_cbqops]| [channel_binding_data] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "server_qops" field is an integer indicating the server's The "server_qops" field is an integer indicating the server's
preferred quality of protection if channel bindings are absent or the preferred quality of protection if channel bindings are absent or the
negotiation of the channel binding fails. 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 "server_maxbuf" is the same as above.
The "channel_binding_length" is a network byte order integer that The optional field "server_cbqops" indicate the server's preferred
indicate the length of the "channel_binding_data" field. quality of protection if channel binding negotiation succeeds. The
quality of protection values are defined in section 9.
The optional field "server_cbqops" is present only if
"channel_binding_length" is non-zero, and indicate the server's
preferred quality of protection if channel binding negotiation
succeeds.
The optional field "channel_binding_data" is present only if The optional field "channel_binding_data" contain the actual channel
"channel_binding_length" is non-zero, and contain the actual channel
binding data. binding data.
4.4.4. Wrap Token Input For Client Responses 4.3.4. Client last GSS_Wrap input
The data format for input to GSS_Wrap when the client responds to the The input to GSS_Wrap when the clients sends a Wrap token field,
previous token is as follows. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client_qop | client_maxbuf | | client_qop | client_maxbuf |
/ [authzid] | / [authzid] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "client_qop" field is the selected quality of protection. The "client_qop" field is the selected quality of protection. The
quality of protection values are defined in section 9.
The "client_maxbuf" and "authzid" fields are as above. The "client_maxbuf" and "authzid" fields are as above.
5. Channel Bindings 5. Channel Bindings
[[This section is tentative further discussion on the topic. This The GS2 mechanism provide its own channel binding mechanism, instead
was written to provide an example of how the details of how one of using the "chan_binding" parameter in the GSS-API context
approach to this concept could look like. There are other approaches functions. The reason for this is that the GS2 mechanism provide an
that may be preferable.]] option to proceed even if the channel bindings does not match. The
GSS-API framework specifies that authentication cannot proceed if
The GS2 mechanism provide its own token field for channel bindings, channel bindings do not match.
in addition to the "chan_binding" parameter in the GSS-API context
functions. The reason for this is that the GS2 mechanism wish to
provide an option to proceed even if the channel bindings does not
match. The GSS-API framework specifies that authentication cannot
proceed if channel bindings does not match. The GSS-API framework
also does not specify the kind of privacy layer the channel binding
should be transferred under, thus making it possible for attackers to
modify it to always make channel binding negotiation succeed.
The client can select, using the "Native Channel Bindings" bit,
whether it wishes to use the "chan_bindings" parameter in the GSS-API
layer or not. If it wishes to use this, it is not possible to
continue after a failed channel binding negotiation.
A client that wish to continue with the authentication even if the
channel bindings does not match, set the "Native Channel Binding" bit
to 0. It MUST use the channel binding field in the GS2 token. It
MUST set the "chan_binding" parameter in the calls to
GSS_Init_sec_context to GSS_Accept_sec_context to NULL. The
application MUST set the "client_qops" field to include privacy
protection (to protect the SASL application data), and MAY set the
"client_cbqops" to no security layer (to avoid performance
degradation due to two security layers).
If a client do not wish to continue the authentication if channel
binding negotiation fails, or wishes to use the channel binding in
the GSS-API layer, it will set the "Native Channel Binding" bit to 1
in its first token. It MUST use both the channel binding field in
the GS2 token and the "chan_binding" parameter in the calls to
GSS_Init_sec_context and GSS_Accept_sec_context. The authentication
will fail in the GSS-API layer if the channel bindings does not
match, and thus the "client_qops" and "client_cbqops" MUST be set to
the same value. It MAY be set to no security layer (to avoid
performance degradation due to two security layers).
For TLS, the channel binding data is specified in the next section.
For other security layers, channel binding data will have to
specified elsewhere, and this specification will have to be updated
with explicit considerations.
[[All channel bindings should go into a separate document.]]
5.1. Name Of Tls Channel For Use As Channel Binding
The TLS Pseudo-Random Function (PRF) generate, using the constant Client and servers MUST set the "chan_binding" parameter in the calls
string "TLS channel binding", and based on the master secret and the to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to
random values established during a TLS handshake, a 64 octet string NULL.
that make up the SASL channel binding data.
Using the terminology of TLS [13], the channel binding data is Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
computed as follows: no security layer and instead depend on the session security afforded
by the bound-in channel.
SASL_channel_binding = Use of no SASL security layers in combination with channel binding
PRF(SecurityParameters.master_secret, should provide better performance than using SASL security layers
"TLS channel binding", over secure channels, and better security characteristics than using
SecurityParameters.server_random + no SASL security layers over secure channels without channel binding.
SecurityParameters.client_random) [0..64];
The derived data is intended to be used as a name of the TLS channel For more discussions of channel bindings, and the syntax of the
that is cryptographically bound to the channel, for use in channel binding data for various security protocols, see [7].
authentication mechanisms tunneled over TLS.
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.
An informal pseudo-language is used to describe the packets sent
below. In particular, when GSS_Wrap() is mentioned below, it refer
to the operation of calling GSS_Wrap on the indicated fields,
formatted in the structures described earlier.
An authentication exchange using GS2 may look like: An authentication exchange using GS2 may look like:
C: Request authentication exchange C: Request authentication exchange
S: Send [length=0] token S: Send [length=0] token
C: Send [length, GSS_Init_sec_context] token C: Send [length, GSS_Init_sec_context] token
... ...
S: After PROT_READY is set, S: After PROT_READY is set,
send [length, GSS_Accept_sec_context, send [length, GSS_Accept_sec_context,
GSS_Wrap(server_qops, server_maxbuf, GSS_Wrap(server_qops | server_maxbuf]
channel_binding_length=0)]
... ...
C: After PROT_READY is set, C: After PROT_READY is set,
send [length, GSS_Init_sec_context, send [length, GSS_Init_sec_context,
GSS_Wrap (client_qop, client_maxbuf, authzid)] GSS_Wrap (client_qop | client_maxbuf | authzid)]
S: Send [length, GSS_Accept_sec_context] token S: Send [length, GSS_Accept_sec_context] token
C: Send [length, GSS_Init_sec_context] token C: Send [length, GSS_Init_sec_context] token
... ...
S: Outcome of authentication exchange S: Outcome of authentication exchange
Because GSS-API authentication is initiated by the client, the length Because GSS-API authentication is initiated by the client, the length
field will be 0 in the initial token from the server to the client field will be 0 in the initial token from the server to the client
when the protocol profile do not support additional information to be when the protocol profile does not support additional information to
sent together with the authentication request. be sent together with the authentication request.
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: Send [length=0] token S: Send [length=0] token
C: Send [length, GSS_Init_sec_context] token C: Send [length, GSS_Init_sec_context] token
... ...
C: After PROT_READY is set, C: After PROT_READY is set,
send [length, GSS_Init_sec_context, send [length, GSS_Init_sec_context,
GSS_Wrap(client_qops, client_maxbuf, GSS_Wrap(client_qops | client_maxbuf |
channel_binding_length=0, authzid)] channel_binding_length=0 | authzid)]
... ...
S: After PROT_READY is set, S: After PROT_READY is set,
send [length, GSS_Accept_sec_context, send [length, GSS_Accept_sec_context,
GSS_Wrap (server_qop, server_maxbuf)] GSS_Wrap (server_qop | server_maxbuf)]
C: Send [length, GSS_Init_sec_context] token C: Send [length, GSS_Init_sec_context] token
S: Send [length, GSS_Accept_sec_context] token S: Send [length, GSS_Accept_sec_context] token
... ...
S: Outcome of authentication exchange S: Outcome of authentication exchange
If the protocol profile support the optional initial client response, If the protocol profile support the optional initial client response,
the first empty message can be optimized away, and then the protocol the first empty message can be optimized away, and then the protocol
exchange will look like: exchange will look like:
C: Request authentication exchange and C: Request authentication exchange and
skipping to change at page 13, line 32 skipping to change at page 15, line 9
as additional information. as additional information.
If the PROT_READY flag is never set by the GSS-API mechanism, the If the PROT_READY flag is never set by the GSS-API mechanism, the
GSS_Wrap message will be sent after the context has been established. GSS_Wrap message will be sent after the context has been established.
The protocol may look like: The protocol may look like:
C: Request authentication exchange C: Request authentication exchange
... ...
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
a token, send [length, context token, a token, send [length, context token,
GSS_Wrap(server_qops, server_maxbuf, GSS_Wrap(server_qops | server_maxbuf)]
channel_binding_length=0)]
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
output a token, send output a token, send
[length=0, context token, [length=0, context token,
GSS_Wrap(client_qop, client_maxbuf, GSS_Wrap(client_qop | client_maxbuf |
channel_binding_length=0, authzid)] channel_binding_length=0 | authzid)]
S: Outcome of authentication exchange S: Outcome of authentication exchange
Alternatively, if the client finishes first, it may look like: Alternatively, if the client finishes first, it may look like:
C: Request authentication exchange C: Request authentication exchange
... ...
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
token, send [length, context token, token, send [length, context token,
GSS_Wrap(client_qops, client_maxbuf, GSS_Wrap(client_qops | client_maxbuf |
channel_binding_length=0, authzid)] channel_binding_length=0 | authzid)]
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
output a token, send [length, context token, output a token, send [length, context token,
GSS_Wrap(server_qop, server_maxbuf, GSS_Wrap(server_qop | server_maxbuf |
channel_binding_length=0)]
S: Outcome of authentication exchange
Adding channel bindings to the last examples, gives the following
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
...
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
token, send [length, context token,
GSS_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 [length, context token,
GSS_Wrap(server_qop | server_maxbuf |
channel_binding_length=0)] channel_binding_length=0)]
S: Outcome of authentication exchange S: Outcome of authentication exchange
If the protocol support initial data from the client, and the If the protocol support initial data from the client, and the
PROT_READY flag is set in the client after the first call to PROT_READY flag is set in the client after the first call to
GSS_Init_sec_context, and the server can send additional data to the GSS_Init_sec_context, and the server can send additional data to the
client when indicating successful authentication, the following client when indicating successful authentication, the following
protocol exchange will occur. protocol exchange will occur.
C: Request authentication exchange and C: Request authentication exchange and
send [length, GSS_Init_sec_context, send [length, GSS_Init_sec_context,
GSS_Wrap (client_qops, client_maxbuf, GSS_Wrap (client_qops | client_maxbuf |
channel_binding_length=0, authzid)] token channel_binding_length=0 | authzid)] token
S: Indicate successful authentication and S: Indicate successful authentication and
send [length, GSS_Accept_sec_context, send [length, GSS_Accept_sec_context,
GSS_Wrap(server_qop, server_maxbuf)] token GSS_Wrap(server_qop | server_maxbuf)] token
as additional information. as additional information.
The last example illustrate the optimal (round-trip wise) The last example illustrate the optimal (round-trip wise)
authentication possible using this protocol. authentication possible using this protocol.
7. Authentication Conditions 7. Authentication Conditions
Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following
conditions are true: conditions are true:
o An invalid SASL token is received (i.e., length shorter than 4 o An invalid SASL token is received (i.e., length shorter than 4
octets). octets).
o GSS_Init/Accept_sec_context() return anything other than o GSS_Init/Accept_sec_context() return anything other than
GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
o GSS_Wrap() returns anything other than GSS_S_COMPLETE. o GSS_Wrap() returns anything other than GSS_S_COMPLETE.
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 should be indications of out of order processing or replays is fatal.)
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.
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.
9. Security Layer Bits 9. Security Layer Bits
The fields "client_qops", "server_qops", "client_cbqops", and
"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
layer.
Note that "client_qop" and "server_qop" MAY indicate a quality of
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.
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
Other bit-masks may be defined in the future; bits which are not Other bit-masks may be defined in the future; bits which are not
understood must be negotiated off. understood MUST be negotiated off.
Note that SASL negotiates the maximum size of the output_message to When decoding any received data with GSS_Unwrap the major_status
send. Implementations can use the GSS_Wrap_size_limit call to other than the GSS_S_COMPLETE MUST be treated as a fatal error.
determine the corresponding maximum size input_message.
10. Interoperability With The Gssapi Mechanism For integrity and confidentiality protection, GS2 negotiates the
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.
The GSSAPI mechanism [11] describe how the Kerberos V5 GSS-API 9.1. Examples
mechanism [9] is used in SASL under the mechanism name "GSSAPI". The
same mechanism may also be used with the GS2 family. This causes an
interopability problem, which is discussed and resolved below.
10.1. The Interoperability problem When no security layer is negotiated the octet will encode an integer
1 as follows.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|1|
+-+-+-+-+-+-+-+-+
When integrity is negotiated the octet will encode an integer 2 as
follows.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|1|0|
+-+-+-+-+-+-+-+-+
When confidentiality is negotiated the octet will encode an integer 4
as follows.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|0|0|
+-+-+-+-+-+-+-+-+
10. Interoperability with the GSSAPI mechanism
The GSSAPI mechanism [12] describe how the Kerberos V5 GSS-API
mechanism [10] is used in SASL under the mechanism name "GSSAPI".
The same mechanism may also be used with the GS2 family. This causes
an interopability problem, which is discussed and resolved below.
10.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.
10.2. Resolving the problem 10.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 [16]. could enable certain tunnel attacks [17].
10.3. Additional recommendations 10.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.
11. Mechanisms That Negotiate Other Mechanisms 11. 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.
11.1. The Interoperability Problem 11.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.
11.2. Security Problem 11.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 should have used mechanism Y. For this reason, the use of when it ideally should have used mechanism Y. For this reason, the
GSS-API mechanisms that negotiate other mechanisms are disallowed use of GSS-API mechanisms that negotiate other mechanisms are
under GS2. disallowed under GS2.
11.3. Resolving the Problems 11.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 [10] under GS2. SPNEGO [11] under GS2.
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [15] The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [16]
can be used to identify such mechanisms. can be used to identify such mechanisms.
12. IANA Considerations 12. 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-*
Family of SASL mechanisms: YES
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.
13. Security Considerations 13. Security Considerations
Security issues are discussed throughout this memo. Security issues are discussed throughout this memo.
When a server or client supports multiple authentication mechanisms, When a server or client supports multiple authentication mechanisms,
each of which has a different security strength, it is possible for each of which has a different security strength, it is possible for
an active attacker to cause a party to use the least secure mechanism an active attacker to cause a party to use the least secure mechanism
supported. There are several ways to mitigate this problem: supported. There are several ways to mitigate this problem:
1. Integrity protected transports can be used, e.g., TLS [13]. To 1. Integrity protected transports can be used, e.g., TLS [14]. To
protect against certain tunnel attacks [16] with that solution, a protect against certain tunnel attacks [17] with that solution, a
mechanism that support channel bindings that can bind the mechanism that support channel bindings that can bind the
security layer (e.g., the TLS session id) to the authentication security layer (e.g., the TLS session id) to the authentication
is required. is required.
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. supported mechanism.
Because the negotiation of a GSS-API mechanism may be done in the Because the negotiation of a GSS-API mechanism may be done in the
clear, it is important for the GSS-API mechanisms to be designed such clear, it is important for the GSS-API mechanisms to be designed such
that an active attacker cannot obtain an authentication with weaker that an active attacker cannot obtain an authentication with weaker
security properties by modifying the challenges and responses. security properties by modifying the challenges and responses.
The integrity protection provided by the security layer is useless to The channel binding is sent without privacy protection and knowledge
the client unless the client also requests mutual authentication. of it is assumed to provide no advantage to an attacker. This is a
Therefore, a client wishing to benefit from the integrity protection property that has to be considered when specifying channel bindings
of a security layer MUST pass to the GSS_Init_sec_context call a for a security protocol.
mutual_req_flag of TRUE.
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, e.g., the Domain Name System insecure or untrusted directory service, e.g., the Domain Name System
[8] without DNSSEC [14]. [9] without DNSSEC [15].
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 [9]. We stress that service V5 GSSAPI mechanism can be found in [10]. We stress that service
names should not be canonicalized using an unsecured directory names should not be canonicalized using an unsecured directory
service such as the DNS without DNSSEC. service such as the DNS without DNSSEC.
14. Acknowledgements 14. Acknowledgements
This document is a revision of RFC 2222. This version was derived This document is a revision of RFC 2222. This version was derived
from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov
with significant contributions from John G. Myers, although this with significant contributions from John G. Myers, although the
document has been rewritten by the current author. majority 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 from Sam Hartman, Jeffrey acknowledged. In particular, ideas and feedback from Sam Hartman,
Hutzelman, and Nicolas Williams influenced the design of this Jeffrey Hutzelman, Alexey Melnikov, and Nicolas Williams influenced
protocol. the design of the document and protocol.
15. Copying Conditions 15. Copying Conditions
Copyright (C) 2005, 2006 Simon Josefsson
Regarding the portion of this document that was written by Simon Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to resulting from its use. The author grants irrevocable permission to
anyone to use, modify, and distribute it in any way that does not anyone to use, modify, and distribute it in any way that does not
diminish the rights of anyone else to use, modify, and distribute it, diminish the rights of anyone else to use, modify, and distribute it,
provided that redistributed derivative works do not contain provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not misleading author or version information. Derivative works need not
be licensed under similar terms. Contact the author to confirm which be licensed under similar terms. Contact the author to confirm which
sections are available under this license. sections are available under this license.
16. References 16. References
16.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Myers, J., "Simple Authentication and Security Layer (SASL)", [2] Melnikov, A. and K. Zeilenga, "Simple Authentication and
RFC 2222, October 1997. Security Layer (SASL)", RFC 4422, June 2006.
[3] Linn, J., "Generic Security Service Application Program [3] 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] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001. RFC 3174, September 2001.
[5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
draft-josefsson-rfc3548bis-04 (work in progress), May 2006.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[7] "Information Processing Systems - Open Systems Interconnection - [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
Specification of Abstract Syntax Notation One (ASN.1)", ISO RFC 4648, October 2006.
Standard 8824.
[7] Williams, N., "On the Use of Channel Bindings to Secure
Channels", draft-ietf-nfsv4-channel-bindings-04 (work in
progress), June 2006.
[8] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)",
ISO Standard 8824, December 1990.
16.2. Informative References 16.2. Informative References
[8] Mockapetris, P., "Domain names - concepts and facilities", [9] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, [10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996. June 1996.
[10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API [11] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998. Negotiation Mechanism", RFC 2478, December 1998.
[11] Melnikov, A., "SASL GSSAPI mechanisms", [12] Melnikov, A., "SASL GSSAPI mechanisms",
draft-ietf-sasl-gssapi-03 (work in progress), September 2005. draft-ietf-sasl-gssapi-03 (work in progress), September 2005.
[12] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, October 1996. RFC 2025, October 1996.
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
RFC 2246, January 1999. Protocol Version 1.1", RFC 4346, April 2006.
[14] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[15] Williams, N., "Extended Generic Security Service Mechanism [16] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work
in progress), October 2005. in progress), October 2005.
[16] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in [17] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication", 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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 21, line 29 skipping to change at page 23, line 45
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 114 change blocks. 
343 lines changed or deleted 484 lines changed or added

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