draft-ietf-sasl-gs2-07.txt   draft-ietf-sasl-gs2-08.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Intended status: Standards Track Intended status: Standards Track
Expires: September 1, 2007 Expires: September 30, 2007
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-07 draft-ietf-sasl-gs2-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2007. This Internet-Draft will expire on September 30, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes how to use a Generic Security Service This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework. This is done by Authentication and Security Layer (SASL) framework. This is done by
skipping to change at page 6, line 52 skipping to change at page 6, line 52
00011100 11111000 11110100 00101011 01011010 00011100 11111000 11110100 00101011 01011010
10011111 10000000 11111010 11101001 11111000 10011111 10000000 11111010 11101001 11111000
binary in groups of 5: binary in groups of 5:
00011 10011 11100 01111 01000 01010 11010 11010 00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000 01111 10101 11010 01111 11000 10011 11110 00000 01111 10101 11010 01111 11000
decimal of each group: decimal of each group:
3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24 3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24
Translating each decimal value using table 3 in Base32 [6] yields the base32 encoding:
character sequence DT4PIK22T6APV2PY. Thus the SASL mechanism name
for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6APV2PY". 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 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 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
binary, and re-group them in groups of 5, and convert them back to binary, and re-group them in groups of 5, and convert them back to
decimal, which results in these computations: decimal, which results in these computations:
hex: hex:
82 d2 73 25 76 6b d6 c8 45 aa 82 d2 73 25 76 6b d6 c8 45 aa
skipping to change at page 7, line 28 skipping to change at page 7, line 32
10000010 11010010 01110011 00100101 01110110 10000010 11010010 01110011 00100101 01110110
01101011 11010110 11001000 01000101 10101010 01101011 11010110 11001000 01000101 10101010
binary in groups of 5: binary in groups of 5:
10000 01011 01001 00111 00110 01001 01011 10110 10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011 01100 10000 10001 01101 01010 01101 01111 01011 01100 10000 10001 01101 01010
decimal of each group: decimal of each group:
16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10
Translating each decimal value using table 3 in Base32 [6] yields the base32 encoding:
character sequence QLJHGJLWNPLNQRNK. Thus the SASL mechanism name Q L J H G J L W N P L M Q R N K
for the Kerberos V5 GSSAPI mechanism is "GS2-QLJHGJLWNPLNQRNK".
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".
4. SASL Authentication Exchange Message Format 4. SASL Authentication Exchange Message Format
4.1. SASL Messages 4.1. SASL Messages
During the SASL authentication exchange for GS2, a number of messages During the SASL authentication exchange for GS2, a number of messages
following the following format is sent between the client and server. following the following format is sent between the client and server.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 28, line 39 skipping to change at page 28, line 39
mechanism need to support integrity to provide support for mechanism need to support integrity to provide support for
channel bindings. channel bindings.
2. A client or server which supports mechanisms of different 2. A client or server which supports mechanisms of different
strengths should have a configurable minimum strength that it strengths should have a configurable minimum strength that it
will use. It is not sufficient for this minimum strength check will use. It is not sufficient for this minimum strength check
to only be on the server, since an active attacker can change to only be on the server, since an active attacker can change
which mechanisms the client sees as being supported, causing the which mechanisms the client sees as being supported, causing the
client to send authentication credentials for its weakest client to send authentication credentials for its weakest
supported mechanism. This solution, however, is not guaranteed supported mechanism. This solution, however, is not guaranteed
to the lead to the mutually most secure mechanism, and is to lead to the most secure mechanism supported by both parties,
therefor only recommended as an additional precaution. and is therefor only recommended as an additional precaution.
3. Specify how to use the SPNEGO mechanism in SASL. 3. Specify how to use the SPNEGO mechanism in SASL.
The channel binding is sent without privacy protection and knowledge The channel binding is sent without privacy protection and knowledge
of it is assumed to provide no advantage to an attacker. This is a of it is assumed to provide no advantage to an attacker. This is a
property that has to be considered when specifying channel bindings property that has to be considered when specifying channel bindings
for a security protocol that will be used with GS2. for a security protocol that will be used with GS2.
When constructing the input_name_string, the client should not When constructing the input_name_string, the client should not
canonicalize the server's fully qualified domain name using an canonicalize the server's fully qualified domain name using an
 End of changes. 6 change blocks. 
11 lines changed or deleted 18 lines changed or added

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