Network Working Group S. Josefsson
Internet-Draft October 9, 2007
Intended status: Standards Track
Expires: April 11, 2008
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-09
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Josefsson Expires April 11, 2008 [Page 1]
Internet-Draft SASL GS2-* October 2007
Abstract
This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
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.
Josefsson Expires April 11, 2008 [Page 2]
Internet-Draft SASL GS2-* October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 6
3.2. Computing mechanism names manually . . . . . . . . . . . . 6
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. SASL Authentication Exchange Message Format . . . . . . . . . 8
4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9
4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10
4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12
4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12
4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13
4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14
4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22
9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24
11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25
11.1. The interoperability problem . . . . . . . . . . . . . . . 25
11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25
11.3. Additional recommendations . . . . . . . . . . . . . . . . 25
12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26
12.1. The interoperability problem . . . . . . . . . . . . . . . 26
12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26
12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
Josefsson Expires April 11, 2008 [Page 3]
Internet-Draft SASL GS2-* October 2007
1. Introduction
Generic Security Service Application Program Interface (GSS-API) [3]
is a framework that provide security services to applications.
Simple Authentication and Security Layer (SASL) [2] is a framework to
provide authentication and security layers for connection based
protocols. This document describe how to use a GSS-API mechanism in
a connection-based protocol using the SASL framework.
All GSSAPI mechanisms are implicitly registered for use within SASL
by this specification. The SASL mechanism defined in this document
is known as the GS2 family.
The "Kerberos V5 GSS-API mechanism" [10] is also supported in SASL
through "SASL GSSAPI mechanisms" [12]. The difference between that
protocol and the one described here, is that this protocol offer more
features (i.e., channel bindings and round-trip optimizations) while
the other protocol is more widely deployed. There are
interoperability concerns by having the same GSS-API mechanism
available under more than one SASL mechanism name, see the section
"Interoperability with the GSSAPI mechanism" below.
There are interoperability and security concerns if this SASL
mechanism is used together with a GSS-API mechanism that negotiate
other GSS-API mechanisms (such as SPNEGO [11]), see the section
"Mechanisms that negotiate other mechanisms" below.
There are interoperability and security concerns with GSSAPI
mechanism that do not provide integrity, see the section "Non-
integrity capable GSS-API mechanisms" below.
SASL mechanism names starting with "GS2-" are reserved for SASL
mechanisms which conform to this document.
The IESG is considered to be the owner of all SASL mechanisms which
conform to this document. This does not necessarily imply that the
IESG is considered to be the owner of the underlying GSSAPI
mechanism.
Josefsson Expires April 11, 2008 [Page 4]
Internet-Draft SASL GS2-* October 2007
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Josefsson Expires April 11, 2008 [Page 5]
Internet-Draft SASL GS2-* October 2007
3. Mechanism name
3.1. Generating SASL mechanism names from GSS-API OIDs
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
alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
computed over the ASN.1 DER encoding [7], including the tag and
length octets, of the GSS-API mechanism's Object Identifier. The
Base32 rules on padding characters and characters outside of the
base32 alphabet are not relevant to this use of Base32. If any
padding or non-alphabet characters are encountered, the name is not a
GS2 family mechanism name.
3.2. Computing mechanism names manually
The SASL mechanism name may be computed manually. This is useful
when the set of supported GSS-API mechanisms is known in advance. It
also obliterate the need to implement Base32, SHA-1 and DER in the
SASL mechanism. The computed mechanism name can be used directly in
the implementation, and the implementation need not concern itself
with that the mechanism is part of a mechanism family.
3.3. Examples
The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1. The ASN.1
DER encoding of the OID, including the tag and length, is (in hex) 06
07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is
(in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad.
Convert the first ten octets to binary, and re-group them in groups
of 5, and convert them back to decimal, which results in these
computations:
hex:
1c f8 f4 2b 5a 9f 80 fa e9 f8
binary:
00011100 11111000 11110100 00101011 01011010
10011111 10000000 11111010 11101001 11111000
binary in groups of 5:
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
base32 encoding:
Josefsson Expires April 11, 2008 [Page 6]
Internet-Draft SASL GS2-* October 2007
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
[6]. 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
base32 encoding:
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
[6]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI
mechanism is "GS2-QLJHGJLWNPLMQRNK".
Josefsson Expires April 11, 2008 [Page 7]
Internet-Draft SASL GS2-* October 2007
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrap token length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ [Context token] /
/ --------------------/
/ ---------------------/ /
/--------------------/ /
/ [Wrap token] /
/ /
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Context length" and "Wrap token length" fields each contain a 4
octet (32 bit) integer encoded in network byte order, that indicate
the length of the "Context token" and "Wrap token" fields,
respectively. A length of 0 means that a particular field is not
present.
The "Context token" field, if present, contain a GSS-API context
establishment token generated by GSS_Init_sec_context or
GSS_Accept_sec_context.
The "Wrap token" field, if present, contain the output generated by
the GS2_Wrap function.
The fields need not be aligned to 32-bit a boundary. There is no
padding between fields.
Messages shorter than or equal to 8 octets are invalid. (The only
exception is the initial empty challenge sent by the server which may
be 0 octets.) From that it follows that at least one of the "Context
token length" and the "Wrap token length" integers MUST be non-zero
in a particular message. If the sum of the length integers is longer
than the entire message size, minus 8 octets for the length fields,
the message is invalid.
Josefsson Expires April 11, 2008 [Page 8]
Internet-Draft SASL GS2-* October 2007
During any successful authentication exchange, the client and server
will each send exactly one (non-empty) "Wrap token".
Conforming implementations MUST NOT send additional data after the
above message syntax, and MUST ignore additional data. To
illustrate, implementations MUST NOT assume that the last "Wrap token
length" octets of the packet correspond to the "Wrap token", because
that would be incorrect if the packet contained additional data not
described by this document.
4.2. Context Token Field
The format of the "Context token" field inside the SASL token is
defined by each GSS-API mechanism, and the data is computed by (for
the client) GSS_Init_sec_context and (for the server)
GSS_Accept_sec_context.
4.2.1. Client side
The client calls GSS_Init_sec_context, passing in
input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of
the GSSAPI mechanism for which this SASL mechanism is registered, the
chan_binding is set to NULL, and targ_name equal to output_name from
GSS_Import_Name called with input_name_type of
GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
"service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host
name of the server.
(*) - Clients MAY use name types other than
GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but
only when they have a priori knowledge that the servers support
alternate name types. Otherwise clients MUST use
GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
When calling the GSS_Init_sec_context the client SHOULD pass the
integ_req_flag of TRUE, but MAY set it to FALSE (see section 10
below). If the client intends to request a security layer, it MUST
also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE,
and a sequence_req_flag of TRUE. If the client will be requesting a
security layer providing confidentiality protection, it MUST also
supply to the GSS_Init_sec_context a conf_req_flag of TRUE.
The client then responds with any resulting output_token.
If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
client expect the server to issue a token in a subsequent challenge
or as additional information to the outcome of the authentication.
Josefsson Expires April 11, 2008 [Page 9]
Internet-Draft SASL GS2-* October 2007
The client pass the context token to another call to
GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE
is returned or authentication is aborted.
If the server sent a (non-empty) "Wrap token", the context token is
processed before processing the other tokens. This is required
because GSS_Unwrap may need the context to be in the state it is
after the "Context token" in the message has been processed.
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client MUST
examine the context to ensure that it provides a level of protection
permitted by the client's security policy.
4.2.2. Server side
The server passes the first context token to GSS_Accept_sec_context
as input_token, setting input_context_handle to GSS_C_NO_CONTEXT
(initially), the chan_binding set to NULL, and a suitable
acceptor_cred_handle (see below).
Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
GSS-API mechanism for which this SASL mechanism is registered (*).
Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle.
Servers MAY use a credential obtained by calling GSS_Acquire_cred or
GSS_Add_cred for the server's principal name(s) (**) and the GSS-API
mechanism for which this SASL mechanism is registered.
(*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
GSS-API mechanism as an input parameter. The OID set can be created
by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can
be freed by calling the GSS_Release_oid_set.
(**) - Use of server's principal names having
GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
where "service" is the service name specified in the protocol's
profile, and "hostname" is the fully qualified host name of the
server, is RECOMMENDED. The server name can be generated by calling
GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
and input_name_string of "service@hostname".
The server then responds with any resulting output_token.
The server pass any resulting challenge from the client to another
call to GSS_Accept_sec_context, repeating the procedure, until
GSS_S_COMPLETE is returned or authentication is aborted.
If the client sent a (non-empty) "Wrap token", the context token is
Josefsson Expires April 11, 2008 [Page 10]
Internet-Draft SASL GS2-* October 2007
processed first.
Upon successful establishment of the security context (i.e.
GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
verify that the negotiated GSS-API mechanism is indeed the registered
one. This is done by examining the value of the mech_type parameter
returned from the GSS_Accept_sec_context call. If the value differ,
the SASL authentication MUST be aborted.
Upon successful establishment of the security context and if the
server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
credential handle, the server SHOULD also check using the
GSS_Inquire_context that the target_name used by the client matches:
- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
where "service" is the service name specified in the application
protocol's profile, and "hostname" is the fully qualified host name
of the server.
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server MUST
examine the context to ensure that it provides a level of protection
permitted by the server's security policy.
4.3. Wrap Token Field
The Wrap token field MUST NOT be sent or received before the
PROT_READY flag is set locally (by GSS_Init_sec_context or
Gss_Accept_sec_context), or if the PROT_READY flag is never set,
before the context has been fully established. The Wrap token field
does not have to be present directly when the PROT_READY flag is set.
During any exchange, exactly one Wrap token field is sent in each
direction. The GS2_Wrap function is defined below, and its inputs
MUST follow the format described below. If not exactly one Wrap
token is received by the client and by the server, the authentication
MUST fail.
If PROT_READY is never set by GSS_Init_sec_context or
GSS_Accept_sec_context, the flag is implied by successful context
negotiation. This is for GSS-API v1 mechanisms that do not support
PROT_READY, or for GSS-API mechanism that do not provide per-message
protection. This may result in a SASL token consisting of a context
token length of 0 and a Wrap token.
The entity that sends the first Wrap token will have to specify a
bitmap of supported and preferred quality of protection schemes. The
entity that replies to the Wrap tokens will pick a scheme, based on
the bitmask and local policy. The quality of protection values are
defined in section 9.
Josefsson Expires April 11, 2008 [Page 11]
Internet-Draft SASL GS2-* October 2007
Two pairs of input formats to the GS2_Wrap function are defined. The
first pair is used when the client sends the Wrap token first and the
server responds. The other pair is used when the server sends the
Wrap token first and the client responds.
The inputs below are passed to GS2_Wrap, and the output is used as
the Wrap token value.
Some fields in the input formats are optional, indicated by brackets
("[" and "]") and explained by the text below.
4.3.1. The GS2_Wrap function
The GS2_Wrap function have two implementations, and which one is used
depends on whether the negotiated GSS-API context supports per-
message protection. When a context is successfully negotiated (i.e.,
when GSS_S_COMPLETE is returned from, for clients,
GSS_Init_sec_context, or, for servers, GSS_Accept_sec_context) and
the output variable integ_avail is FALSE, then GSS_Wrap cannot be
used and instead we define GS2_Wrap to be the identity function.
When integ_avail is negotiated TRUE, the GS2_Wrap is identical to
calling the GSS_Wrap function with conf_flag set to FALSE and using
the generated output_message as the output data.
4.3.2. Client first GS2_Wrap input
The input to GS2_Wrap when the client sends a Wrap token field first
is as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channel_binding_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[client_cbqops]| [channel_binding_data] /
/ /
/ / [authzid] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "client_qops" integer indicate the client's preferred quality of
protection if channel bindings are absent or the negotiation of the
channel binding fails. The quality of protection values are defined
in section 9.
The "client_maxbuf" field indicate the maximum protected buffer size
the client can receive in network byte order. It MUST be 0 if the
Josefsson Expires April 11, 2008 [Page 12]
Internet-Draft SASL GS2-* October 2007
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
indicate the length of the "channel_binding_data" field.
The optional field "client_cbqops" is present only if
"channel_binding_length" is non-zero, and indicate the client's
preferred quality of protection if channel binding negotiation
succeeds. The quality of protection values are defined in section 9.
The optional field "channel_binding_data" is present only if
"channel_binding_length" is non-zero, and contain the actual channel
binding data.
The optional field "authzid" contain the authorization identity. The
authorization identity is encoded using UTF-8 [5]. The authorization
identity is not terminated with the NUL (U+0000) character. Servers
MUST validate that the authorization identity is valid UTF-8.
4.3.3. Server last GS2_Wrap input
The input to GS2_Wrap when the server sends a Wrap token field, after
receiving the Wrap token in the previous section from the client, is
as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_qop | server_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "server_qop" field integer indicate the selected quality of
protection. The quality of protection values are defined in section
9.
The "server_maxbuf" field indicate the maximum protected data buffer
size the server can receive in network byte order. It MUST be 0 if
the server doesn't advertise support for any security layer, the
client MUST verify this. Small values can make it impossible for the
client to send any protected message to the server, due to the
overhead added by GSS_Wrap, and the client MAY reject the
authentication if it detects this situation.
Josefsson Expires April 11, 2008 [Page 13]
Internet-Draft SASL GS2-* October 2007
4.3.4. Server first GS2_Wrap input
The input to GS2_Wrap when the server sends the Wrap token first is
as follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_qops | server_maxbuf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[server_cbqops]| [channel_binding_data] /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "server_qops" field is an integer indicating the server's
preferred quality of protection if channel bindings are absent or the
negotiation of the channel binding fails. The quality of protection
values are defined in section 9.
The "server_maxbuf" is the same as above.
The optional field "server_cbqops" indicate the server's preferred
quality of protection if channel binding negotiation succeeds. The
quality of protection values are defined in section 9.
The optional field "channel_binding_data" contain the actual channel
binding data.
4.3.5. Client last GS2_Wrap input
The input to GS2_Wrap when the clients sends a Wrap token field,
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
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 |
/ [authzid] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Josefsson Expires April 11, 2008 [Page 14]
Internet-Draft SASL GS2-* October 2007
5. Channel Bindings
The GS2 mechanism provide its own channel binding mechanism, instead
of using the "chan_binding" parameter in the GSS-API context
functions. The reason for this is that the GS2 mechanism 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 do not match.
Client and servers MUST set the "chan_binding" parameter in the calls
to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to
NULL.
Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
no security layer and instead depend on the session security afforded
by the bound-in channel.
In order to accomodate the requirement in [16] "Authentication
frameworks and mechanisms that support channel binding MUST
communicate channel binding failure to applications" implementations
MUST provide a way to communicate channel binding failures to
applications.
Use of no SASL security layers in combination with channel binding
should provide better performance than using SASL security layers
over secure channels, and better security characteristics than using
no SASL security layers over secure channels without channel binding.
For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [8]. For
easy reference, the channel binding format used for The Transport
Layer Security (TLS) Protocol [14] is specified in [16].
Josefsson Expires April 11, 2008 [Page 15]
Internet-Draft SASL GS2-* October 2007
6. Protocol Overview
This section describe several high-level protocol exchanges. The
descriptions do not assume any properties of the actual GSS-API
mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
and to some extent implementation and policy choices, will dictate
which packets are sent in what order. The protocol exchanges are
examples and other exchanges are permitted and will occur.
An informal pseudo-language is used to describe the packets sent
below. GS2_Wrap refer to the operation of calling GS2_Wrap on the
indicated fields, formatted in the structures described earlier.
GSS_Init_sec_context and GSS_Accept_sec_context refer to the context
token generated by calling the respective function. The GS2 SASL
Message is denoted as [Context_token, Wrap_token], and the length
fields are not mentioned.
An authentication exchange using GS2 may look like:
C: Request authentication exchange
S: Empty Challenge
C: Send [GSS_Init_sec_context, ""] token
...
S: After PROT_READY is set,
send [GSS_Accept_sec_context,
GS2_Wrap(server_qops | server_maxbuf]
...
C: After PROT_READY is set,
send [GSS_Init_sec_context,
GS2_Wrap (client_qop | client_maxbuf | authzid)]
S: Send [GSS_Accept_sec_context, ""] token
C: Send [GSS_Init_sec_context, ""] token
...
S: Outcome of authentication exchange
GSS-API authentication is always initiated by the client. The SASL
framework allows either the client and server to initiate
authentication. In GS2 the server will send an initial empty
challenge (zero byte string) if it has not yet received a token from
the client. See section 3 of [2].
The next example illustrate when the client sends its Wrap token
first.
Josefsson Expires April 11, 2008 [Page 16]
Internet-Draft SASL GS2-* October 2007
C: Request authentication exchange
S: Empty Challenge
C: Send [GSS_Init_sec_context, ""] token
...
C: After PROT_READY is set,
send [GSS_Init_sec_context,
GS2_Wrap(client_qops | client_maxbuf |
channel_binding_length=0 | authzid)]
...
S: After PROT_READY is set,
send [GSS_Accept_sec_context,
GS2_Wrap (server_qop | server_maxbuf)]
C: Send [GSS_Init_sec_context, ""] token
S: Send [GSS_Accept_sec_context, ""] token
...
S: Outcome of authentication exchange
If the protocol profile support the optional initial client response,
the first empty message can be optimized away, and then the protocol
exchange will look like:
C: Request authentication exchange and
send [GSS_Init_sec_context, ""] token
S: Send [GSS_Accept_sec_context, ""] token
...
S: Outcome of authentication exchange
If the protocol profile can also send additional information when
indicating the outcome of the authentication, then the protocol
exchange will look like:
C: Request authentication exchange and
send [GSS_Init_sec_context, ""] token
S: Send [GSS_Accept_sec_context, ""] token
...
C: Send [GSS_Init_sec_context, ""] token
S: Indicate successful authentication and
send [GSS_Accept_sec_context, ""] token
as additional information.
If the PROT_READY flag is never set by the GSS-API mechanism, the
GS2_Wrap message will be sent after the context has been established.
The protocol may look like:
Josefsson Expires April 11, 2008 [Page 17]
Internet-Draft SASL GS2-* October 2007
C: Request authentication exchange
...
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
a token, send ["", GS2_Wrap(server_qops | server_maxbuf)]
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
output a token, send
["", GS2_Wrap(client_qop | client_maxbuf |
channel_binding_length=0 | authzid)]
S: Outcome of authentication exchange
Alternatively, if the client finishes first, it may look like:
C: Request authentication exchange
...
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
token, send ["", GS2_Wrap(client_qops | client_maxbuf |
channel_binding_length=0 | authzid)]
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
output a token, send ["", GS2_Wrap(server_qop | server_maxbuf |
channel_binding_length=0)]
S: Outcome of authentication exchange
Adding channel bindings to the last examples, gives the following
complex situation. Here the client request confidentiality for the
application data if channel binding fails but no SASL security layer
if channel binding negotiation succeeds:
C: Request authentication exchange
...
C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
token, send [GSS_Init_sec_context,
GS2_Wrap(client_qops=0x04 | client_maxbuf |
channel_binding_length=n |
client_cbqops=0x01 | channel_binding_data |
authzid)]
S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
output a token, send ["",
GS2_Wrap(server_qop | server_maxbuf |
channel_binding_length=0)]
S: Outcome of authentication exchange
If the protocol support initial data from the client, and the
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
client when indicating successful authentication, the following
protocol exchange will occur.
Josefsson Expires April 11, 2008 [Page 18]
Internet-Draft SASL GS2-* October 2007
C: Request authentication exchange and
send [GSS_Init_sec_context,
GS2_Wrap (client_qops | client_maxbuf |
channel_binding_length=0 | authzid)] token
S: Indicate successful authentication and
send [GSS_Accept_sec_context,
GS2_Wrap(server_qop | server_maxbuf)] token
as additional information.
The last example illustrate the optimal (round-trip wise)
authentication possible using this protocol.
Josefsson Expires April 11, 2008 [Page 19]
Internet-Draft SASL GS2-* October 2007
7. Authentication Conditions
Authentication MUST NOT succeed if any one of the following
conditions are true:
o An invalid SASL token is received (e.g., length field checks
discussed in section 4.1 fail).
o GSS_Init/Accept_sec_context() return anything other than
GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
o GSS_Wrap() returns anything other than GSS_S_COMPLETE.
o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There
can't be supplementary status codes in GS2 at this point, so any
indications of out of order processing or replays is fatal.)
o The token returned from GSS_Unwrap fail to parse correctly (e.g.,
too short, invalid maximum buffer size) as the expected Wrap
token.
o Local policy reject the attempt. For example, client and server
can't agree on qop proposal.
o (server-side) Authorization of client principal (i.e., src_name in
GSS_Acecpt_sec_context) to requested authzid failed.
Josefsson Expires April 11, 2008 [Page 20]
Internet-Draft SASL GS2-* October 2007
8. GSS-API Parameters
The implementation MAY set any GSSAPI flags or arguments not
mentioned in this specification as is necessary for the
implementation to enforce its security policy.
Josefsson Expires April 11, 2008 [Page 21]
Internet-Draft SASL GS2-* October 2007
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:
1 No security layer
2 Integrity protection.
Sender calls GSS_Wrap with conf_flag set to FALSE
4 Confidentiality protection.
Sender calls GSS_Wrap with conf_flag set to TRUE
Other bit-masks may be defined in the future; bits which are not
understood MUST be negotiated off.
When decoding any received data with GSS_Unwrap the major_status
other than the GSS_S_COMPLETE MUST be treated as a fatal error.
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.
9.1. Examples
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
Josefsson Expires April 11, 2008 [Page 22]
Internet-Draft SASL GS2-* October 2007
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|
+-+-+-+-+-+-+-+-+
Josefsson Expires April 11, 2008 [Page 23]
Internet-Draft SASL GS2-* October 2007
10. Non-integrity capable GSS-API mechanisms
Mechanisms that do not support integrity can be used with GS2, but
some security features cannot be provided, in particular including
channel bindings, security layers, and integrity protection of the
authorization identity.
Channel bindings and security layers MUST NOT be negotiated when the
GSS-API mechanism do not support integrity. It should also be
understood that the authorization identity is not integrity
protected.
Whether a mechanism supports integrity or not, for the purpose of
GS2, is decided by whether the integ_avail output variable from
GSS_Init_sec_context (for clients) and GSS_Accept_sec_context (for
servers). If integ_avail is FALSE, integrity is not supported.
There is a potential interoperability problem if a client call
GSS_Init_sec_context with integ_req_flag of TRUE and the context
negotiation fails because the mechanism (due to design, the
capability of the credentials, or policy) cannot provide per-message
protection. Calling GSS_Init_sec_context with a FALSE integ_req_flag
instead is not optimal, since a mechanism may then negotiate less
security than it would have otherwise done.
It is RECOMMENDED that implementations only ever call
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
per-message protection services.
Implementations MAY have a policy to disallow non-integrity capable
mechanisms, and always call GSS_Init_sec_context with the
integ_req_flag set to TRUE.
Josefsson Expires April 11, 2008 [Page 24]
Internet-Draft SASL GS2-* October 2007
11. Interoperability with the SASL "GSSAPI" mechanism
The Kerberos V5 GSS-API [10] mechanism is currently used in SASL
under the name "GSSAPI", see GSSAPI mechanism [12]. The Kerberos V5
mechanism may also be used with the GS2 family. This causes an
interopability problem, which is discussed and resolved below.
11.1. The interoperability problem
If a client (or server) only support Kerberos V5 under the "GSSAPI"
name and the server (or client) only support Kerberos V5 under the
GS2 family, the authentication negotiation will fail.
11.2. Resolving the problem
If the Kerberos V5 mechanism is supported under GS2 in a server, the
server SHOULD also support Kerberos V5 through the "GSSAPI"
mechanism, to avoid interoperability problems with older clients.
Reasons for violating this recommendation may include security
considerations regarding the absent features in the GS2 mechanism.
The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
could enable certain tunnel attacks [18].
11.3. Additional recommendations
It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
rather than through the "GSSAPI" mechanism, if both are available,
because of the additional features in the GS2 mechanism.
Josefsson Expires April 11, 2008 [Page 25]
Internet-Draft SASL GS2-* October 2007
12. Mechanisms that negotiate other mechanisms
A GSS-API mechanism that negotiate other mechanisms interact badly
with the SASL mechanism negotiation. There are two problems. The
first is an interoperability problem and the second is a security
concern. The problems are described and resolved below.
12.1. The interoperability problem
If a client implement GSS-API mechanism X, potentially negotiated
through a GSS-API mechanism Y, and the server also implement GSS-API
mechanism X negotiated through a GSS-API mechanism Z, the
authentication negotiation will fail.
12.2. Security problem
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
mechanisms Y and Z but not X, then if the client attempts to
negotiate mechanism X by using a GSS-API mechanism that negotiate
other mechanisms (such as SPNEGO), it may end up using mechanism Z
when it ideally should have used mechanism Y. For this reason, the
use of GSS-API mechanisms that negotiate other mechanisms are
disallowed under GS2.
12.3. Resolving the problems
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. This specifically exclude negotiating
SPNEGO [11] under GS2.
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [17]
can be used to identify such mechanisms.
Josefsson Expires April 11, 2008 [Page 26]
Internet-Draft SASL GS2-* October 2007
13. IANA Considerations
The IANA is advised that SASL mechanism names starting with "GS2-"
are reserved for SASL mechanisms which conform to this document. The
IANA is directed to place a statement to that effect in the sasl-
mechanisms registry.
Subject: Registration of SASL mechanism GS2-*
SASL mechanism prefix: GS2-
Security considerations: RFC [THIS-DOC]
Published specification: RFC [THIS-DOC]
Person & email address to contact for further information:
Simon Josefsson <simon@josefsson.org>
Intended usage: COMMON
Owner/Change controller: iesg@ietf.org
Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
Josefsson Expires April 11, 2008 [Page 27]
Internet-Draft SASL GS2-* October 2007
14. Security Considerations
The security provided by GS2 depends on the security provided by the
GSS-API mechanism. If the mechanism do not provide integrity
protection, the authorization identity can be replaced by a man in
the middle, and channel bindings and security layers cannot be
negotiated. Therefor, it is generally recommended against using any
GSS-API mechanism widely on the Internet that do not support
integrity.
Because the negotiation of a particular GSS-API mechanism may be done
in the clear, it is important for the GSS-API mechanisms to be
designed such that an active attacker cannot obtain an authentication
with weaker security properties by modifying the challenges and
responses. This is a generic design critera for the GSS-API
mechanisms used under GS2.
When a server or client supports multiple GSS-API mechanisms, 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
supported. This problem and a solution is discussed in section 6.1.2
of [2], but some additional methods to mitigate the problem include:
1. Use of an integrity protected transport, such as TLS [14]. To
protect against certain tunnel attacks [18], channel bindings
need to be used.
2. A client or server which supports mechanisms of different
strengths should have a configurable minimum strength that it
will use. It is not sufficient for this minimum strength check
to only be on the server, since an active attacker can change
which mechanisms the client sees as being supported, causing the
client to send authentication credentials for its weakest
supported mechanism. This solution, however, is not guaranteed
to lead to the most secure mechanism supported by both parties,
and is therefor only recommended as an additional precaution.
The channel binding is sent without privacy protection and knowledge
of it is assumed to provide no advantage to an attacker. This is a
property that has to be considered when specifying channel bindings
for a security protocol that will be used with GS2.
When constructing the input_name_string, the client should not
canonicalize the server's fully qualified domain name using an
insecure or untrusted directory service, such as the Domain Name
System [9] without DNSSEC [15].
Josefsson Expires April 11, 2008 [Page 28]
Internet-Draft SASL GS2-* October 2007
The GS2 protocol hard code the SHA-1 algorithm for computing the
mechanism names. It is not possible to negotiate another hash
algorithm. However, no traditional cryptographic hash properties
(such as collision resistance or pre-image resistance) are required
nor assumed. The required and assumed property is that it is
statistically unlikely that two different DER-encoded OID's share the
same first 10 octets of the SHA-1 value. It is possible to
practically confirm that the SHA-1 algorithm has the necessary
property, by testing many different inputs.
Additional security considerations are in the SASL and GSSAPI
specifications. Additional security considerations for the Kerberos
V5 GSSAPI mechanism can be found in [10]. We stress that service
names should not be canonicalized using an unsecured directory
service such as the DNS without DNSSEC. Security issues are also
discussed throughout this memo.
Josefsson Expires April 11, 2008 [Page 29]
Internet-Draft SASL GS2-* October 2007
15. Acknowledgements
The history of GS2 can be traced to the GSSAPI mechanism described in
RFC 2222. The GSSAPI mechanism had some drawbacks, which created a
need for an improved version. This document was derived from
draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
significant contributions from John G. Myers, although the majority
of this document has been rewritten by the current author.
Contributions of many members of the SASL mailing list are gratefully
acknowledged. In particular, ideas and feedback from Sam Hartman,
Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
improved the document and the protocol.
Josefsson Expires April 11, 2008 [Page 30]
Internet-Draft SASL GS2-* October 2007
16. References
16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[3] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[4] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 4648, October 2006.
[7] International Telecommunications Union, "Information Technology
- ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
[8] Williams, N., "On the Use of Channel Bindings to Secure
Channels", draft-williams-on-channel-binding-04 (work in
progress), August 2007.
16.2. Informative References
[9] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996.
[11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism", RFC 4178,
October 2005.
[12] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication
and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
Josefsson Expires April 11, 2008 [Page 31]
Internet-Draft SASL GS2-* October 2007
[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, October 1996.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[16] Altman, J. and N. Williams, "On the Use of Channel Bindings to
Secure Channels", draft-altman-tls-channel-bindings-01 (work in
progress), December 2006.
[17] Williams, N., "Extended Generic Security Service Mechanism
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
Tunneled Authentication",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
Josefsson Expires April 11, 2008 [Page 32]
Internet-Draft SASL GS2-* October 2007
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires April 11, 2008 [Page 33]
Internet-Draft SASL GS2-* October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Expires April 11, 2008 [Page 34]
