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/