[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS gsasl/doc/specification
|
From: |
gsasl-commit |
|
Subject: |
CVS gsasl/doc/specification |
|
Date: |
Fri, 18 Nov 2005 00:03:25 +0100 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv14312
Added Files:
draft-josefsson-sasl-gs2-00.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-josefsson-sasl-gs2-00.txt
2005/11/17 23:03:25 NONE
+++ /home/cvs/gsasl/doc/specification/draft-josefsson-sasl-gs2-00.txt
2005/11/17 23:03:25 1.1
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,
[664 lines skipped]