Internet DRAFT - draft-josefsson-sasl-gs2
draft-josefsson-sasl-gs2
Network Working Group S. Josefsson
Internet-Draft November 17, 2005
Expires: May 21, 2006
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-josefsson-sasl-gs2-00
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 May 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how to use a Generic Security Service
Application Program Interface mechanism in the the Simple
Authentication and Security Layer framework.
See <http://josefsson.org/sasl-gs2-*/> for more information.
Josefsson Expires May 21, 2006 [Page 1]
Internet-Draft SASL GS2-* November 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . . 3
3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 3
3.2. Computing mechanism names manually . . . . . . . . . . . . 4
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol specification . . . . . . . . . . . . . . . . . . . . 4
4.1. Packet format . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 5
4.3. GSS-API parameters . . . . . . . . . . . . . . . . . . . . 9
4.4. Security layer bits . . . . . . . . . . . . . . . . . . . 9
4.5. Authorization identity format . . . . . . . . . . . . . . 10
4.6. Client side of authentication protocol exchange . . . . . 10
4.7. Server side of authentication protocol exchange . . . . . 12
5. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Josefsson Expires May 21, 2006 [Page 2]
Internet-Draft SASL GS2-* November 2005
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 mechanism is implicitly registered by this specification
for use within SASL. The SASL mechanism defined in this document is
known as the GS2 family.
The "Kerberos V5 GSS-API mechanism" [9] and "The Simple and Protected
GSS-API Negotiation Mechanism" [10] are also supported in SASL
through "SASL GSSAPI mechanisms" [11]. 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 with supporting GSS-API mechanisms through
more than one SASL mechanism, see the section on SPNEGO 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.
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].
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 [5] (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] 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
Josefsson Expires May 21, 2006 [Page 3]
Internet-Draft SASL GS2-* November 2005
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. Example
For example, the OID for the SPKM-1 mechanism [12] is
1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 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
first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL
mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-
DT4PIK22T6EPV2PY".
4. Protocol specification
Each SASL mechanism conforming to this document uses the following
specification.
4.1. Packet format
All messages follow the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ GSS_Init_sec_context or /
/ GSS_Accept_sec_context token, /
/ of given length /
/ --------------------/
/ ---------------------/ /
/--------------------/ /
/ Optional GSS_Wrap token /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Josefsson Expires May 21, 2006 [Page 4]
Internet-Draft SASL GS2-* November 2005
The "length" field is a 4 octet (32 bit) integer encoded in network
byte order, indicating the length of the next field, containing a
GSS-API context establishment token. The length field does not
include the length of the length field itself. The GSS_Wrap token is
optional. Whether it is included or not can be infered from the
length field; if the length field is shorter than the entire packet
size minus 4 octets, the GSS_Wrap is present and begins after
length+4 octets into the packet. The GSS_Wrap token need not be
aligned to 32-bit a boundary. There is no padding between the
context establishment token and the GSS_Wrap token.
Packets shorter than 4 octets are invalid. If the length field is
longer than the entire packet size, minus 4 octets, the message is
invalid.
4.2. Protocol overview
This section describe several examples of 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.
An authentication exchange using GS2 may look like:
C: Request authentication exchange
S: Send [length=0] token
C: Send [length, GSS_Init_sec_context] token
...
S: After PROT_READY is set,
send [length, GSS_Accept_sec_context,
GSS_Wrap(server_qops, server_maxbuf)]
C: After PROT_READY is set,
send [length, GSS_Init_sec_context,
GSS_Wrap (client_qop, client_maxbuf, authzid)]
S: Send [length, GSS_Accept_sec_context] token
C: Send [length, GSS_Init_sec_context] token
...
S: Outcome of authentication exchange
The length field contain the length of the GSS_Init_sec_context or
GSS_Accept_sec_context token. The receiver can distinguish the case
where the GSS_Wrap token is present by comparing the length field
value with the total length of the token. The length 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 sent together
with the authentication request), because GSS-API authentication is
initiated by the client.
Josefsson Expires May 21, 2006 [Page 5]
Internet-Draft SASL GS2-* November 2005
If the PROT_READY flag become set in the client before the server,
the client can send the GSS_Wrap token first. In this case, the
client must send a bitmap of supported/preferred quality of
protection schemes, rather than one single quality of protection
method.
C: Request authentication exchange
S: Send [length=0] token
C: Send [length, GSS_Init_sec_context] token
...
C: After PROT_READY is set,
send [length, GSS_Init_sec_context,
GSS_Wrap(client_qops, client_maxbuf, authzid)]
S: After PROT_READY is set,
send [length, GSS_Accept_sec_context,
GSS_Wrap (server_qop, server_maxbuf)]
C: Send [length, GSS_Init_sec_context] token
S: Send [length, GSS_Accept_sec_context] token
...
S: Outcome of authentication exchange
The GSS_Wrap tokens can only be sent by the client and server after
the PROT_READY flag has been set by GSS_Init_sec_context and
GSS_Accept_sec_context, respectively. During any exchange, exactly
one GSS_Wrap token is sent in each direction. If more than one
GSS_Wrap token is received by either the client or the server, the
authentication MUST fail. The GSS_Wrap token does not have to be
sent directly whenever the PROT_READY flag is set.
If PROT_READY is never set by GSS_Init_sec_context or
GSS_Accept_sec_context, the GSS_Wrap messages can be sent after the
context has been established. In this case, the length field will
encode the integer 0, indicating that the context token is absent.
If the context has not been established at that point, the
authentication MUST fail.
If the protocol profile support the optional initial client response,
then the protocol exchange will look like:
Josefsson Expires May 21, 2006 [Page 6]
Internet-Draft SASL GS2-* November 2005
C: Request authentication exchange and
send [length, GSS_Init_sec_context] token
S: Send [length, GSS_Accept_sec_context] token
C: Send [length, GSS_Init_sec_context] token
...
S: Send [length, GSS_Accept_sec_context,
GSS_Wrap(server_qops, server_maxbuf)] token
C: Send [length, GSS_Init_sec_context,
GSS_Wrap (client_qop, client_maxbuf, authzid)] token
S: Send [length, GSS_Accept_sec_context] token
C: Send [length, GSS_Init_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 [length, GSS_Init_sec_context] token
S: Send [length, GSS_Accept_sec_context] token
C: Send [length, GSS_Init_sec_context] token
...
S: Send [length, GSS_Accept_sec_context,
GSS_Wrap(server_qops, server_maxbuf)] token
C: Send [length, GSS_Init_sec_context,
GSS_Wrap (client_qop, client_maxbuf, authzid)] 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: Indicate successful authentication and
send [length, GSS_Accept_sec_context] token
as additional information.
The client MUST verify that GSS_Init_context return GSS_S_COMPLETE
rather than trust the server's signaling of whether the
authentication was successful or not. If the server report
successful authentication and GSS_Init_sec_context did not return
GSS_S_COMPLETE on the last token, the authentication MUST be aborted
by the client.
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.
The protocol may look like:
Josefsson Expires May 21, 2006 [Page 7]
Internet-Draft SASL GS2-* November 2005
C: Request authentication exchange
...
S: GSS_Accept_sec_context return GSS_S_COMPLETE,
send [length, GSS_Accept_sec_context] token
C: GSS_Init_sec_context return GSS_S_COMPLETE,
send [length, GSS_Init_sec_context] token
S: Send [length=0, GSS_Wrap(server_qops, server_maxbuf)] token
C: Send [length=0,
GSS_Wrap(client_qop, client_maxbuf, authzid)] token
S: Outcome of authentication exchange
Alternatively, if the client finishes first, it may look like:
C: Request authentication exchange
...
C: GSS_Init_sec_context return GSS_S_COMPLETE,
send [length, GSS_Init_sec_context] token
S: GSS_Accept_sec_context return GSS_S_COMPLETE,
send [length, GSS_Accept_sec_context] token
C: Send [length=0,
GSS_Wrap(client_qops, client_maxbuf, authzid)] token
S: Send [length=0, GSS_Wrap(server_qop, server_maxbuf)] token
C: Empty Response
S: Outcome of authentication exchange
If the entity the finish first does not wish to send its GSS_Wrap
message first, it send an empty token to indicate this. Only one
empty token is permitted, more than one MUST lead to authentication
failure. Empty tokens are not permitted during the initial conext
establishment. The following figure illustrate this scenario:
C: Request authentication exchange
...
C: GSS_Init_sec_context return GSS_S_COMPLETE,
send [length, GSS_Init_sec_context] token
S: GSS_Accept_sec_context return GSS_S_COMPLETE,
send [length, GSS_Accept_sec_context] token
C: Empty Response
S: Send [length=0, GSS_Wrap(server_qops, server_maxbuf)] token
C: Send [length=0,
GSS_Wrap(client_qop, client_maxbuf, authzid)] token
S: Outcome of authentication exchange
This alter which side chose the resulting quality of protection.
Earlier, the client sent a bit mask of which quality of protection he
support/prefer and the server chose one. Now, the server send a bit
mask of which quality of protections it support/prefer, and the
client chose one. Implementations are encouraged to pick the
Josefsson Expires May 21, 2006 [Page 8]
Internet-Draft SASL GS2-* November 2005
strongest available method if there is a choice, but local policy may
dictate that a weaker method is to be used. If the client_qop or
server_qop received by the server or client does not match the
server_qops or client_qops bitmask, the semantic is that the
indicated (i.e., through client_qop or server_qop) quality of
protection is required by the other end to complete the
authentication. The entity receiving such a message may decide using
local policy whether to continue authentication or not. Normally,
the authentication is aborted (because the other end did not meet the
supported/preferred quality of protections announced by the local
end), but in some cases, accepting the other ends decision may be
acceptable. Note that the quality of protection fields are both
integrity and privacy protected, thus protecting this negotiation.
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.
C: Request authentication exchange and
send [length, GSS_Init_sec_context,
GSS_Wrap (client_qops, client_maxbuf, authzid)] token
S: Indicate successful authentication and
send [length, GSS_Accept_sec_context,
GSS_Wrap(server_qop, server_maxbuf)] token
as additional information.
The last example illustrate the optimal (round-trip wise)
authentication possible using this protocol.
4.3. 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.
4.4. Security layer bits
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
Josefsson Expires May 21, 2006 [Page 9]
Internet-Draft SASL GS2-* November 2005
understood must be negotiated off.
Note that SASL 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.
4.5. Authorization identity format
The authorization identity is encoded using UTF-8 [6]. The
authorization identity is not terminated with the NUL (U+0000)
character.
4.6. Client side of authentication protocol exchange
The client calls GSS_Init_sec_context, passing in
input_context_handle of 0 (initially), mech_type of the GSSAPI
mechanism for which this SASL mechanism is registered, any
chan_binding if requested by the application, 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. If the client will be requesting a security
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
integ_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
send a four-octet network byte order integer encoding the length of
the resulting output_token, concatenated with the actual token. If
GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
should expect the server to issue a token in a subsequent challenge
or as additional information to the outcome of the authentication.
The token received from the server will be prefixed with a four-octet
network byte-order integer encoding the length of the context token.
The client must pass the context token to another call to
GSS_Init_sec_context, repeating the actions in this paragraph, until
GSS_S_COMPLETE is returned or authentication is aborted. If the
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 as described
below.
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. If the context is
unacceptable, the client abort the authentication. Otherwise, if the
last call to GSS_Init_sec_context returned an output_token, that
Josefsson Expires May 21, 2006 [Page 10]
Internet-Draft SASL GS2-* November 2005
token is returned to the server (prefixed with the length integer)
together with a GSS_Wrap token, unless the client already sent the
GSS_Wrap token earlier. If the call to GSS_Init_sec_context did not
return any additional token in output_token, it will respond with an
empty context token (i.e., a length field value of 0) and a GSS_Wrap
token, unless the client already sent the GSS_Wrap token earlier.
When the context has been established, or if the PROT_READY flag is
set by the call to GSS_Init_sec_context, the client may send, in
addition to the length field and output_token (if any), a GSS_Wrap
token. The client passes data to GSS_Wrap with conf_flag set to
FALSE, and responds with the generated output_message.
If the client has not received a GSS_Wrap token from the server yet,
the data will contain one octet with a bit-mask indicating the
client's supported/preferred security layer ("client_qops"), then
three octets encoding, in network byte order, an integer indicating
the maximum message size ("client_maxbuf") that the client can
receive (set to 0 if no integrity or privacy layer is requested), and
the remaining data is the UTF-8 [6] encoded authorization identity
("authzid") which may be empty. The client will later expect a
GSS_Wrap token from the server. The client passes this token to
GSS_Unwrap and interprets the first octet of resulting cleartext as
the selected security layer ("server_qop"), and the second through
fourth octets as the network byte order maximum size output_message
to send to the server ("server_maxbuf"). The client will verify that
the selected security layer is acceptable, it may be different from
what was requested in "client_qops".
If the client has received a GSS_Wrap token from the server earlier,
the client passes that token to GSS_Unwrap and interprets the first
octet of resulting cleartext as a bit-mask indicating the supported/
preferred security layer that the server wish to use ("server_qops"),
and the second through fourth octets as the network byte order
integer indicating the maximum size output_message to send to the
server ("server_maxbuf"). The client then proceed to create the data
used as input to GSS_Wrap. The data will contain one octet
indicating the selected quality of protection level ("client_qop"),
which should be one of those indicated in the bit-mask received from
the server (but may be different if the client would abort
authentication here and want to give the server a chance to use a
different security method), three octets encoding, in network byte
order, an integer indicating the maximum buffer size
("client_maxbuf") that the client can receive (set to 0 if no
integrity or privacy layer is requested), and the remaining octets
containing the UTF-8 [6] encoded authorization identity ("authzid")
which may be empty.
Josefsson Expires May 21, 2006 [Page 11]
Internet-Draft SASL GS2-* November 2005
The client must validate the GSS_Wrap token it receive from the
server. If the resulting cleartext received from GSS_Unwrap is not 4
octets long, the client fails the negotiation. The client verifies
that the server maximum buffer is 0 if the server doesn't advertise
support for any security layer.
4.7. Server side of authentication protocol exchange
The server passes the first client response to GSS_Accept_sec_context
as input_token, setting input_context_handle to 0 (initially),
mech_type of the GSSAPI mechanism for which this SASL mechanism is
registered, any chan_binding if requested by the application, 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. If
GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server send
to the client the challenge, consisting of a four-octet network byte
order integer encoding the length of the resulting output_token,
concatenated with the actual token. The server must pass the
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 as
described below.
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. If the context is
unacceptable, the server abort the authentication. Otherwise, if the
last call to GSS_Accept_sec_context returned an output_token, the
server returns it to the client in a challenge (prefixed with the
length integer) together with a GSS_Wrap token, unless the server
already sent the GSS_Wrap token earlier. If the
GSS_Accept_sec_context did not return an output token, the server
return an empty context (i.e., length=0) together with a GSS_Wrap
token, unless the server already sent the GSS_Wrap token earlier.
When the context has been established, or if the PROT_READY flag is
set by the call to GSS_Accept_sec_context, the server may send, in
addition to the length field and output_token (if any), a GSS_Wrap
token. The server passes data to GSS_Wrap with conf_flag set to
FALSE, and responds with the generated output_message.
Josefsson Expires May 21, 2006 [Page 12]
Internet-Draft SASL GS2-* November 2005
If the server has not received a GSS_Wrap token from the client yet,
the data will contain one octet with a bit-mask indicating the
server's supported/preferred security layer ("server_qops"), then
three octets encoding, in network byte order, an integer indicating
the maximum message size ("server_maxbuf") that the server can
receive (set to 0 if no integrity or privacy layer is requested).
The server will later expect a GSS_Wrap token from the client. The
server pass this token to GSS_Unwrap and interprets the first octet
of resulting cleartext as the selected security layer ("client_qop"),
and the second through fourth octets as the network byte order
maximum size output_message to send to the client ("client_maxbuf").
The server will verify that the selected security layer is
acceptable, it may be different from what indicated in "server_qops".
If the server has received a GSS_Wrap token from the client earlier,
the server passes that token to GSS_Unwrap and interprets the first
octet of resulting cleartext as a bit-mask indicating the client's
supported/preferred security layer ("client_qops"), and the second
through fourth octets as the network byte order integer indicating
the maximum size output_message to send to the client
("client_maxbuf"). The server then proceed to create the data used
as input to GSS_Wrap. The data will contain one octet indicating the
selected security layer ("server_qop"), which should be one of those
indicated in the bit-mask received from the client (but may be
different if the server would abort authentication here and want to
give the client a chance to use a different security method), three
octets encoding, in network byte order, an integer indicating the
maximum buffer size ("server_maxbuf") that the server can receive
(set to 0 if no integrity or privacy layer is requested), and the
remaining octets containing the UTF-8 [6] encoded authorization
identity ("authzid") which may be empty. The server must verify that
the src_name identity is authorized to authenticate as the
authorization identity. After these verifications, the
authentication process is complete.
The server must validate the GSS_Wrap token it receive from the
client. If the resulting cleartext received from GSS_Unwrap is
shorter than 4 octets, the server fails the negotiation. The server
verifies that the server maximum buffer is 0 if the server doesn't
advertise support for any security layer.
5. SPNEGO
Use of The Simple and Protected GSS-API Negotiation Mechanism [10]
(SPNEGO) underneath SASL introduces subtle interoperability problems
and security considerations. To address these, this section places
additional requirements on implementations which support SPNEGO
Josefsson Expires May 21, 2006 [Page 13]
Internet-Draft SASL GS2-* November 2005
underneath SASL.
A client which supports, for example, the Kerberos V5 GSSAPI
mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
mechanism will not interoperate with a server which supports the
Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
mechanism. A client that only support Kerberos V5 underneath "GSS-
SPNEGO" will not interoperate with a server that only support
Kerberos V5 in the GS2 mechanism and the GS2 SPNEGO mechanism.
Since SASL is capable of negotiating amongst GSSAPI mechanisms, the
only reason for a server or client to support the "GSS-SPNEGO"
mechanism is to allow a policy of only using mechanisms below a
certain strength if those mechanism's negotiation is protected. In
such a case, a client or server would only want to negotiate those
weaker mechanisms through SPNEGO. In any case, there is no down-
negotiation security consideration with using the strongest mechanism
and set of options the implementation supports, so for
interoperability that mechanism and set of options MUST be negotiable
without using the "GSS-SPNEGO" or the GS2 SPNEGO mechanism.
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 the "GSS-SPNEGO" or the GS2 SPNEGO
mechanism, it may end up using mechanism Z when it should have used
mechanism Y. For this reason, implementations MUST exclude from
SPNEGO those GSSAPI mechanisms which are weaker than the strongest
non-GSSAPI SASL mechanism advertised by the server.
The situation is complicated by the fact that SPNEGO may be
negotiated through both the "GSS-SPNEGO" mechanism and the GS2 SPNEGO
mechanism. Because all the functionality in the "GSSAPI" and "GSS-
SPNEGO" mechanisms are available through the GS2 mechanism, and the
GS2 family in addition also offer channel bindings and round-trip
optimizations, it is expected that migration to the GS2 family will
eventually happen.
6. 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.
Josefsson Expires May 21, 2006 [Page 14]
Internet-Draft SASL GS2-* November 2005
Subject: Registration of SASL mechanism GS2-*
Family of SASL mechanisms: YES
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:
The Kerberos V5 and SPNEGO mechanisms are also supported
through the GSSAPI and GSS-SPNEGO mechanisms, respectively.
7. Security Considerations
Security issues are discussed throughout this memo.
When a server or client supports multiple authentication 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. There are several ways to mitigate this problem:
1. Integrity protected transports can be used, e.g., TLS [13]. To
protect against certain tunnel attacks [15] with that solution, a
mechanism that support channel bindings that can bind the
security layer (e.g., the TLS session id) to the authentication
is required.
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.
3. The SPNEGO mechanism can be used securely negotiate among GSS-API
mechanisms. This solution can only be used if all the SASL
mechanisms are GSS-API mechanisms.
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
that an active attacker cannot obtain an authentication with weaker
security properties by modifying the challenges and responses.
SPNEGO [10] has protection against many of these down-negotiation
attacks, SASL does not itself have such protection. The section
titled "SPNEGO" mentions considerations of choosing negotiation
through SASL versus SPNEGO.
Josefsson Expires May 21, 2006 [Page 15]
Internet-Draft SASL GS2-* November 2005
The integrity protection provided by the security layer is useless to
the client unless the client also requests mutual authentication.
Therefore, a client wishing to benefit from the integrity protection
of a security layer MUST pass to the GSS_Init_sec_context call a
mutual_req_flag of TRUE.
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, e.g., the Domain Name System
[8] without DNSSEC [14].
Additional security considerations are in the SASL and GSSAPI
specifications. Additional security considerations for the Kerberos
V5 GSSAPI mechanism can be found in [9]. We stress that service
names should not be canonicalized using an unsecured directory
service such as the DNS without DNSSEC.
8. Acknowledgements
This document is a revision of RFC 2222 written by John G. Myers. He
also contributed significantly to this revision. This version was
derived from draft-ietf-sasl-gssapi-02 which was prepared by Alexey
Melnikov.
Contributions of many members of the SASL mailing list are gratefully
acknowledged.
9. Copying conditions
Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to
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,
provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not
be licensed under similar terms.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Josefsson Expires May 21, 2006 [Page 16]
Internet-Draft SASL GS2-* November 2005
[2] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[3] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[7] "Information Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)", ISO
Standard 8824.
10.2. Informative References
[8] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996.
[10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[11] Melnikov, A., "SASL GSSAPI mechanisms",
draft-ietf-sasl-gssapi-03 (work in progress), September 2005.
[12] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, October 1996.
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[14] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[15] 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 May 21, 2006 [Page 17]
Internet-Draft SASL GS2-* November 2005
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires May 21, 2006 [Page 18]
Internet-Draft SASL GS2-* November 2005
Intellectual Property Statement
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.
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 (2005). 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson Expires May 21, 2006 [Page 19]
