Diff: draft-puthenkulam-eap-binding-03.txt - draft-puthenkulam-eap-binding-04.txt

	< draft-puthenkulam-eap-binding-03.txt		draft-puthenkulam-eap-binding-04.txt >
	EAP Working Group Jose Puthenkulam		EAP Working Group Jose Puthenkulam
	INTERNET-DRAFT Victor Lortz		INTERNET-DRAFT Victor Lortz

	Category: Informational Intel Corporation		Category: Experimental Intel Corporation
	Ashwin Palekar		Ashwin Palekar

	<draft-puthenkulam-eap-binding-03.txt> Dan Simon		<draft-puthenkulam-eap-binding-04.txt> Dan Simon
	30 June 2003 Microsoft		27 October 2003 Microsoft

	The Compound Authentication Binding Problem		The Compound Authentication Binding Problem

	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC 2026.		provisions of Section 10 of RFC 2026.

	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.


	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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.

	Copyright Notice		Copyright Notice

	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.

	Abstract		Abstract

	There are several motivations for using compound authentication methods		There are several motivations for using compound authentication methods

	using tunnels, but man-in-the-middle attacks are possible in certain		using tunnels, but man-in-the-middle attacks have been found in these
	circumstances when they are used, without cryptographically binding the		protocols under certain circumstances. They occur when the inner
	methods together. At the time of writing this document, several		methods used inside a tunnel method are also used outside it, without
	protocols being proposed within the IETF are vulnerable to these		cryptographically binding the methods together. At the time of writing
	attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and		this document, several protocols being proposed within the IETF were
	PEAP. This document studies the problems and suggests potential		vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over
	solutions to mitigate them.		TLS, EAP TTLS and PEAP. This document studies the problems and suggests
			potential solutions to mitigate them. We also provide a reference
			solution for an EAP tunneling protocol like PEAP.

	Table of Contents		Table of Contents

	1. Introduction .......................................... 3		1. Introduction .......................................... 3

	1.1 Scope ........................................... 3		1.1 Scope ........................................... 3
	1.2 Motivations for Compound Methods ................ 4		1.2 Motivations for Compound Methods ................ 4
	1.3 Problem Statement ............................... 5		1.3 Problem Statement ............................... 5
	1.4 Requirements Language ........................... 5		1.4 Requirements Language ........................... 5
	1.5 Terminology ..................................... 6		1.5 Terminology ..................................... 6

	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	4.2 Binding Phase Handshake.......................... 23		4.2 Binding Phase Handshake.......................... 23
	4.3 Compound MAC and Session Key derivation.......... 26		4.3 Compound MAC and Session Key derivation.......... 26
	4.4 Binding Message Formats ......................... 27		4.4 Binding Message Formats ......................... 27
	4.5 IANA Considerations.............................. 31		4.5 IANA Considerations.............................. 31
	4.6 Security Considerations ......................... 31		4.6 Security Considerations ......................... 31

	5. Normative references .................................. 31		5. Normative references .................................. 31

	6. Informative references ................................ 33		6. Informative references ................................ 33


	ACKNOWLEDGMENTS .............................................. 35		Acknowledgements.............................................. 35


	AUTHORS' ADDRESSES ........................................... 35		Author's Addresses ........................................... 35

			Intellectual Property Statement .............................. 36

	Full Copyright Statement ..................................... 37		Full Copyright Statement ..................................... 37
	1. Introduction		1. Introduction

	As authentication protocols evolved over time, weaker ones have		As authentication protocols evolved over time, weaker ones have
	either been replaced or modified to meet the increasing security needs		either been replaced or modified to meet the increasing security needs
	in new environments. The development of secure tunneling techniques like		in new environments. The development of secure tunneling techniques like
	[TLS] and [IPSEC] have generated a lot of interest in securing legacy or		[TLS] and [IPSEC] have generated a lot of interest in securing legacy or
	weaker authentication protocols using tunnels. We call such compositions		weaker authentication protocols using tunnels. We call such compositions
	of multiple authentication protocols that are used in concert to		of multiple authentication protocols that are used in concert to
	accomplish a specific purpose, Compound Authentication Methods. They may		accomplish a specific purpose, Compound Authentication Methods. They may
	be used for several purposes, including user authentication for granting		be used for several purposes, including user authentication for granting
	network access or establishing a security association for		network access or establishing a security association for
	confidentiality and integrity protection of data traffic.		confidentiality and integrity protection of data traffic.


	We highlight certain �man-in-the-middle� vulnerabilities associated with		We highlight certain man-in-the-middle vulnerabilities associated with
	the composition of compound authentication methods that are being		the composition of compound authentication methods that are being
	proposed or already in use today. These include authentication methods		proposed or already in use today. These include authentication methods
	that are commonly encapsulated within an independently authenticated		that are commonly encapsulated within an independently authenticated
	tunnel that provides additional protective properties. Some examples of		tunnel that provides additional protective properties. Some examples of
	compound authentication methods using tunnels include EAPMD5 using		compound authentication methods using tunnels include EAPMD5 using
	[EAPTTLS], [EAPMSCHAPV2] using [PEAP], PANA over TLS [PANATLS], HTTP		[EAPTTLS], [EAPMSCHAPV2] using [PEAP], PANA over TLS [PANATLS], HTTP
	authentication over TLS, [XAUTH] with ISAKMP as part of IKE, and secure		authentication over TLS, [XAUTH] with ISAKMP as part of IKE, and secure
	legacy authentication support for IKEv2 [SLA]. These may also include		legacy authentication support for IKEv2 [SLA]. These may also include
	multiple authentication methods used in sequence when multiple		multiple authentication methods used in sequence when multiple
	credentials are used in different stages of authentication.		credentials are used in different stages of authentication.

	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶

	This document identifies the man-in-the-middle attacks that are possible		This document identifies the man-in-the-middle attacks that are possible
	when one-way authenticated tunnels are used to protect communications of		when one-way authenticated tunnels are used to protect communications of
	one or a sequence of authentication methods; and characterizes the		one or a sequence of authentication methods; and characterizes the
	solution(s) that address the attack. The context studied is the use of		solution(s) that address the attack. The context studied is the use of
	compound authentication for granting network access using a client and		compound authentication for granting network access using a client and
	authentication server setup.		authentication server setup.

	Intuitively, certain attacks may also be possible with sequences of		Intuitively, certain attacks may also be possible with sequences of
	authentication methods even if they are not used within tunnels, but we		authentication methods even if they are not used within tunnels, but we

	don�t address those scenarios here. This is because such authentication		do not address those scenarios here. This is because such authentication
	sequences are open-ended and unless a protocol method defines the		sequences are open-ended and unless a protocol method defines the
	security constructs of the sequence in totality, its difficult to		security constructs of the sequence in totality, its difficult to
	analyze the attack scenarios. Also at the time of writing, the authors		analyze the attack scenarios. Also at the time of writing, the authors
	are not aware of such open-ended sequences with clearly defined		are not aware of such open-ended sequences with clearly defined
	security constructs.		security constructs.

	constructs. If they do exist further study may be needed to see if the		constructs. If they do exist further study may be needed to see if the
	attacks we describe apply to them and also whether the solutions make		attacks we describe apply to them and also whether the solutions make
	sense.		sense.


	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	the specification. These words are often capitalized. The key words		the specification. These words are often capitalized. The key words
	"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD		"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
	NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be		NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
	interpreted as described in [RFC2119].		interpreted as described in [RFC2119].

	1.5. Terminology		1.5. Terminology

	This document frequently uses the following terms:		This document frequently uses the following terms:

	Authenticator		Authenticator

	The entity at one end of a network access segment that		The end of the link initiating authentication. In IEEE 802.1X
	requires the entity at the other end of the link to be		the term authenticator is defined and it has the same meaning
	authenticated. It is also referred to as a NAS (Network		here. It is also referred to as a NAS (Network Access Server).
	Access Server).


	Peer The other end of the point-to-point link (PPP), point-to-point		Peer The end of the link, which is being authenticated by the
	LAN segment (IEEE 802.1x) or 802.11 wireless link, which is		Authenticator. In IEEE 802.1X, this end is known as the
	being authenticated by the Authenticator. In IEEE 802.1X, this		Supplicant. We also sometimes refer to the Peer as a Client
	end is known as the Supplicant. We also sometimes refer to the		of the Authentication Server.
	Peer as a Client of the Authentication Server.

	Authentication Server		Authentication Server
	It is an entity that provides an Authentication Service to an		It is an entity that provides an Authentication Service to an
	Authenticator. This service verifies from the credentials		Authenticator. This service verifies from the credentials
	provided by the Peer, the claim of identity made by the Peer.		provided by the Peer, the claim of identity made by the Peer.

			It is also referred to as the backend authentication server.

	Legacy Authentication Methods		Legacy Authentication Methods
	These are mostly one-way authentication methods widely used		These are mostly one-way authentication methods widely used
	today that are either based on passwords or secure tokens or		today that are either based on passwords or secure tokens or
	challenge-response methods that have no key derivation,		challenge-response methods that have no key derivation,
	no message authenticity or integrity protection, no identity		no message authenticity or integrity protection, no identity
	privacy protection, use weak algorithms and are vulnerable to		privacy protection, use weak algorithms and are vulnerable to
	many well known attacks.		many well known attacks.
	ex: PAP - Password Authentication Protocol		ex: PAP - Password Authentication Protocol


	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 8 ¶
	authentication is complete after the final method in the		authentication is complete after the final method in the
	sequence is completed.		sequence is completed.

	Tunneled Methods		Tunneled Methods
	The first method sets up a tunnel and subsequent method(s) run		The first method sets up a tunnel and subsequent method(s) run
	within the tunnel.		within the tunnel.

	Binding Phase		Binding Phase
	The protocol stage where validation of the peers		The protocol stage where validation of the peers
	participating in the compound authentication method is carried		participating in the compound authentication method is carried

	out after all the individual methods have completed.		out after all the methods have completed or one or more
			successive individual methods have completed.

	Compound MAC		Compound MAC
	A Message Authentication Code (MAC) computed using keying		A Message Authentication Code (MAC) computed using keying
	material from multiple methods used in a compound		material from multiple methods used in a compound
	authentication method. This is computed during the binding		authentication method. This is computed during the binding
	phase.		phase.

	Compound Keys		Compound Keys
	Session keys computed using keying material from multiple		Session keys computed using keying material from multiple
	methods used in a compound authentication method. This is		methods used in a compound authentication method. This is

	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 37 ¶
	an AP and functions as one entity with malicious intent. This is		an AP and functions as one entity with malicious intent. This is
	relatively easy to accomplish given the low cost of equipment and tools.		relatively easy to accomplish given the low cost of equipment and tools.
	This may be relatively more difficult to accomplish on dial-up RAS		This may be relatively more difficult to accomplish on dial-up RAS
	servers.		servers.

	[CC-C] The inability of the authentication server to validate that the		[CC-C] The inability of the authentication server to validate that the
	client authentication occurring inside a tunnel originated at the		client authentication occurring inside a tunnel originated at the
	same endpoint as the tunnel itself.		same endpoint as the tunnel itself.

	ex: When an EAP method runs inside of EAP-TTLS or PEAP, the tunnel		ex: When an EAP method runs inside of EAP-TTLS or PEAP, the tunnel

	endpoint that is not authenticated really doesn�t prove that it		endpoint that is not authenticated really does not prove that it
	originated the inner EAP conversation as link is protected only by the		originated the inner EAP conversation as link is protected only by the
	tunnel keys.		tunnel keys.

	[CC-D] The data link being authenticated is always confidentiality-		[CC-D] The data link being authenticated is always confidentiality-
	and/or integrity-protected using tunnel keys instead of the keys		and/or integrity-protected using tunnel keys instead of the keys
	derived from the client method running inside the tunnel.		derived from the client method running inside the tunnel.

	ex: The keys from any EAP method running inside of EAP-TTLS or PEAP are		ex: The keys from any EAP method running inside of EAP-TTLS or PEAP are
	not used today.		not used today.


	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 14 ¶

	The mechanisms to provide cryptographic proof involve combining some		The mechanisms to provide cryptographic proof involve combining some
	knowledge derived from each authentication method involved in a compound		knowledge derived from each authentication method involved in a compound
	authentication to prove that both parties are the real peers. This		authentication to prove that both parties are the real peers. This
	knowledge may be in the form of keying material available to both		knowledge may be in the form of keying material available to both
	parties. This information can be used as part of a two-stage solution.		parties. This information can be used as part of a two-stage solution.

	[Stage 1] Binding Phase Exchange with Compound Keyed MACs		[Stage 1] Binding Phase Exchange with Compound Keyed MACs

	Here we execute an additional 2-way handshake to the tunneling protocol		Here we execute an additional 2-way handshake to the tunneling protocol

	or base protocol, we call it the �Binding Phase Exchange�. This phase is		or base protocol, we call it the �Binding Phase Exchange�. This phase is
	entered only if the server knows that all the individual		entered only if the server knows that all the individual
	authentication methods inside the tunnel have completed. (There maybe		authentication methods inside the tunnel have completed. (There maybe
	some situations where binding maybe carried out after each inner method		some situations where binding maybe carried out after each inner method
	completes. However that is beyond our scope at the moment.)		completes. However that is beyond our scope at the moment.)

	In case of the tunnel server endpoint not being the final		In case of the tunnel server endpoint not being the final
	authentication server, it has possession of the inner method keys if		authentication server, it has possession of the inner method keys if
	they are available. The keys from all the inner methods and the tunnel		they are available. The keys from all the inner methods and the tunnel
	keys are used to compute keyed compound MACs as described in section 4.2.		keys are used to compute keyed compound MACs as described in section 4.2.
	The validation of the compound MACs protects against the		The validation of the compound MACs protects against the

	skipping to change at page 19, line 32 ¶		skipping to change at page 19, line 32 ¶
	computed using from all the inner method keys if they are available		computed using from all the inner method keys if they are available
	and the tunnel keys. The resultant keys called Compound Session Keys		and the tunnel keys. The resultant keys called Compound Session Keys
	(CSKs) are provided to the link layer for ciphering and integrity		(CSKs) are provided to the link layer for ciphering and integrity
	protection. These keys provide the assurance that all packets		protection. These keys provide the assurance that all packets
	are being exchanged between the real peers and no man-in-the-middle is		are being exchanged between the real peers and no man-in-the-middle is
	actually decrypting the conversation. The Compound Session Key		actually decrypting the conversation. The Compound Session Key
	derivation is specified in section 4.2.		derivation is specified in section 4.2.

	Though from our analysis, compound MACs used in the Stage 1 Binding		Though from our analysis, compound MACs used in the Stage 1 Binding
	Phase Exchange provide the necessary protection, we argue that for		Phase Exchange provide the necessary protection, we argue that for

	additional protection one could also use Stage 2.		additional protection one could also use Stage 2. The main reason for
			Stage 2 is to allow each tunnel packet privacy protection to also be
			cryptographically bound to the inner methods it carries.

	Performing Stage 1 prevents a man-in-the-middle from gaining		Performing Stage 1 prevents a man-in-the-middle from gaining
	authenticated access. It also prevents false authenticated states		authenticated access. It also prevents false authenticated states
	which could result in a Denial-of-Service attack that could result		which could result in a Denial-of-Service attack that could result
	if only Stage 2 is done.		if only Stage 2 is done.

	Only implementing Stage 2 does not require additional round trips, but		Only implementing Stage 2 does not require additional round trips, but
	it enables the man-in-the-middle to authenticate, although not to		it enables the man-in-the-middle to authenticate, although not to
	obtain keys used for subsequent link-level authentication and encryption		obtain keys used for subsequent link-level authentication and encryption
	of the data. This implies that the client will only discover an attack		of the data. This implies that the client will only discover an attack

	skipping to change at page 25, line 12 ¶		skipping to change at page 25, line 12 ¶
	number of the protocol extension, a 256 bit C_NONCE, a RESULT TLV that		number of the protocol extension, a 256 bit C_NONCE, a RESULT TLV that
	provides acknowledgment for the protected success/failure indication.		provides acknowledgment for the protected success/failure indication.

	A client side MAC (B2_MAC) is computed for this message body using the		A client side MAC (B2_MAC) is computed for this message body using the
	CMK_B2, with the MAC bits set to zero, and is included in the B2		CMK_B2, with the MAC bits set to zero, and is included in the B2
	message. Figure 4 shows both the messages in the success case.		message. Figure 4 shows both the messages in the success case.

	There are several conditions that can cause invalid B1 or B2 messages,		There are several conditions that can cause invalid B1 or B2 messages,
	they include the following:		they include the following:


	� Invalid B1_MAC or B2_MAC		� Invalid B1_MAC or B2_MAC
	� Incompatible protocol version		� Incompatible protocol version
	� Invalid RESULT_TLV		� Invalid RESULT_TLV

	A man-in-the-middle attack can cause these conditions to occur. More		A man-in-the-middle attack can cause these conditions to occur. More
	details on detecting these conditions are described as part of the		details on detecting these conditions are described as part of the
	message formats in section 4.3. Here we describe how they are handled		message formats in section 4.3. Here we describe how they are handled
	as the failure authentication cases.		as the failure authentication cases.

	[1] Client receiving an invalid B1 message		[1] Client receiving an invalid B1 message

	If the client finds the Binding Request (B1) message to be invalid, it		If the client finds the Binding Request (B1) message to be invalid, it

	doesn�t send any response. It can make a decision to drop the connection		does not send any response. It can make a decision to drop the connection
	at this time, as it is not certain, that its talking to the right server.		at this time, as it is not certain, that its talking to the right server.
	Any other Binding Requests (B1) messages if they arrive subsequently,		Any other Binding Requests (B1) messages if they arrive subsequently,
	and if they are valid, are responded to using proper Binding Response		and if they are valid, are responded to using proper Binding Response
	(B2) messages. This is to allow for packet loss during the server retry		(B2) messages. This is to allow for packet loss during the server retry
	time period. The retry of packets is handled by the EAP layer; and is		time period. The retry of packets is handled by the EAP layer; and is
	transparent to the EAP methods. The packets should not be different		transparent to the EAP methods. The packets should not be different
	because the media is unreliable.		because the media is unreliable.

	[2] Client never receiving a B1 message		[2] Client never receiving a B1 message


	skipping to change at page 26, line 9 ¶		skipping to change at page 26, line 9 ¶
	[4] Server never receiving a B2 message		[4] Server never receiving a B2 message

	In this case, the server will time out and can do a retry, up to 3 times		In this case, the server will time out and can do a retry, up to 3 times
	with new B1 messages. It must use a new S_NONCE every time it sends a		with new B1 messages. It must use a new S_NONCE every time it sends a
	new message.		new message.

	4.3 Compound MAC and Session Key derivation		4.3 Compound MAC and Session Key derivation

	The input for the cryptographic binding we use includes the 128-octet		The input for the cryptographic binding we use includes the 128-octet
	Tunnel Session Key (TSK), the 64-octet Tunnel Initialization Vector		Tunnel Session Key (TSK), the 64-octet Tunnel Initialization Vector

	(TIV), and the inner method provided session keys, ISK1, ISK2,�ISKN,		(TIV), and the inner method provided session keys, ISK1, ISK2,..ISKN,
	that belong to the N authentication methods used inside the tunnel.		that belong to the N authentication methods used inside the tunnel.
	These keys may all be of varying sizes, so a known size in multiples		These keys may all be of varying sizes, so a known size in multiples
	of 32 bits between 64 and 256 bits is chosen of each of the methods		of 32 bits between 64 and 256 bits is chosen of each of the methods
	based on available keying material.		based on available keying material.

	The Compound MAC for the client (the B2_MAC) and the server (the B1_MAC)		The Compound MAC for the client (the B2_MAC) and the server (the B1_MAC)
	are derived from two different MAC keys called CMK_B2 and CMK_B1		are derived from two different MAC keys called CMK_B2 and CMK_B1
	respectively. A compound session key (CSK) is also derived on both the		respectively. A compound session key (CSK) is also derived on both the
	client and server for cryptographic purposes. If the binding phase is		client and server for cryptographic purposes. If the binding phase is
	implemented, that alone prevents the man-in-the-middle attacks, so the		implemented, that alone prevents the man-in-the-middle attacks, so the
	CSKs are really not needed and the tunnel session keys can still be used		CSKs are really not needed and the tunnel session keys can still be used
	for ciphering purposes, just as the TSK is in a normal EAP-TLS session.		for ciphering purposes, just as the TSK is in a normal EAP-TLS session.

	The CMK_B1, CMK_B2 and CSK are derived as follows for the PEAP protocol.		The CMK_B1, CMK_B2 and CSK are derived as follows for the PEAP protocol.
	PEAP tunnel session key (TSK); TSK is calculated using the EAP-TLS		PEAP tunnel session key (TSK); TSK is calculated using the EAP-TLS

	algorithm (RFC2716 section 3.5), and is 128 octets. PEAP tunnel IV		algorithm (RFC2716 section 3.5), and is 128 octets. This includes the
	(TIV); TIV is calculated using the EAP-TLS algorithm (RFC2716 section		first 64 octets of MSK (Master Session Key) and next 64 octets of EMSK
	3.5), and is 64-octets.		(Extended Master Session Key).


	ISK1��ISKn are the EAP inner session keys obtained from methods 1 to n.		ISK1..ISKn are the EAP inner session keys (MSK) obtained from methods 1
			to n.


	In some cases, ISKi, for some i, may be the null string ("").		In some cases, ISKi, for some i, may be the null string (""), when the
			corresponding method does not derive keying material.

	We use the P_SHA-1 PRF specified in the TLS specification [RFC2246]		We use the P_SHA-1 PRF specified in the TLS specification [RFC2246]
	for PEAP, though this PRF selection decision can be made independently		for PEAP, though this PRF selection decision can be made independently
	for each tunneling protocol.		for each tunneling protocol.

	Compound MAC Key derivation algorithm:		Compound MAC Key derivation algorithm:


	Take the second 256 bits of TSK (128-octet TLS/SChannel output)		Take the second 256 bits (32 octets) of MSK portion of the TSK.
			output)

	IPMK0 = TSK		IPMK0 = TSK

	for j = 1 to n do		for j = 1 to n do

	IPMKj = PRF(IPMK(j-1),"Intermediate PEAP MAC key", ISKj);		IPMKj = PRF(IPMK(j-1),"Intermediate PEAP MAC key", ISKj);


	CMK_B1 = PRF(IPMKn,"PEAP Server B1 MAC key",S_NONCE)		Where j denotes the last inner method that runs inside the tunnel. Each
			IPMKj output is 32 octets. IPMKn is the intermediate combined key used
			to derive compound session and compound MAC keys.


	CMK_B2 = PRF(IPMKn,"PEAP Client B2 MAC key",C_NONCE\|S_NONCE)		The Compound MAC Key for the server (the B1_MAC) is derived CMK_B1

			CMK_B1 = P_SHA1(IPMKn,"PEAP Server B1 MAC key" \| S_NONCE);

			The Compound MAC Key for the client (the B2_MAC) is derived from MAC key called CMK B2.

			CMK_B2 = P_SHA1(IPMKn,"PEAP Client B2 MAC key" \| C_NONCE \| S_NONCE);

			The compound MAC keys (CMK_B1 and CMK_B2) are each 20 octets long.

	("\|" denotes concatenation)		("\|" denotes concatenation)
	The pseudorandom function PRF(k,label,string) is computed as		The pseudorandom function PRF(k,label,string) is computed as
	P_SHA-1(k,label\|string) (or substitute, if necessary, any other PRF that		P_SHA-1(k,label\|string) (or substitute, if necessary, any other PRF that
	produces output of sufficient length). Here the outputs are taken to		produces output of sufficient length). Here the outputs are taken to
	as many bits as are necessary (typically 256 bits for a key).		as many bits as are necessary (typically 256 bits for a key).

	Compound Session Key derivation:		Compound Session Key derivation:

	The following function provides the necessary keying material.		The following function provides the necessary keying material.

	CSK = PRF(IPMKn, "PEAP compound session key",		CSK = PRF(IPMKn, "PEAP compound session key",
	C_NONCE\|S_NONCE, OutputLength);		C_NONCE\|S_NONCE, OutputLength);

	where the PRF is the same one used for CMK derivation. The output is		where the PRF is the same one used for CMK derivation. The output is

	taken to 128 octets. The compound IV (CIV) is identical to the Tunnel		taken to 128 octets. The first 64 octets are taken and the MSK and the
	IV (TIV).		second 64 octets are taken as the EMSK. The MSK and EMSK are described
			in [RFC2284bis].

	4.4 Binding Message Formats		4.4 Binding Message Formats

	The Binding Messages are represented using TLVs defined below.		The Binding Messages are represented using TLVs defined below.

	The generic TLV format is defined in [TLV] in section 3.1		The generic TLV format is defined in [PEAP] in section 3.1
	and duplicated below.		and duplicated below.

	0 1 2 3		0 1 2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|M\|R\| Type \| Length \|		\|M\|R\| Type \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Value...		\| Value...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	skipping to change at page 28, line 22 ¶		skipping to change at page 28, line 22 ¶
	3 - Result TLV (Acknowledged Result)		3 - Result TLV (Acknowledged Result)

	Length		Length

	The length of the Value field in octets.		The length of the Value field in octets.

	Value		Value

	The value of the object.		The value of the object.


	We also use the Result TLV that also define in [TLV] to indicate the		We also use the Result TLV that also defined in [PEAP] to indicate the
	final success acknowledgement. The following is the duplicated		final success acknowledgement. The following is the duplicated
	definition of the Result TLV.		definition of the Result TLV.

	Result TLV:		Result TLV:


	This is defined in draft-hiller-eap-tlv-00.txt [TLV] in section 3.2		This is defined in [PEAP] and is duplicated below.
	and duplicated below.

	The Result TLV provides support for acknowledged Success and Failure		The Result TLV provides support for acknowledged Success and Failure
	messages within EAP. It is defined as follows:		messages within EAP. It is defined as follows:

	0 1 2 3		0 1 2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|M\|R\| Type \| Length \|		\|M\|R\| Type \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Status \|		\| Status \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	M		M


	1 - Mandatory TLV		1 bit. Value = 1 - Mandatory TLV

	R		R


	Reserved, set to zero (0)		1 bit. Reserved, set to zero (0)

	TLV Type		TLV Type


	3 - Success/Failure		14 bits. Value = 3 - Success/Failure

	Length		Length


	2		2 octets

	Status		Status

	The status field is two octets. Values include:		The status field is two octets. Values include:
	1 - Success		1 - Success
	2 - Failure		2 - Failure

	The Cryptographic Binding is performed using the Binding TLV. It is		The Cryptographic Binding is performed using the Binding TLV. It is
	described below. Both the Binding Request (B1) and Binding Response (B2)		described below. Both the Binding Request (B1) and Binding Response (B2)
	use the same packet format. However the SubType indicates whether it is		use the same packet format. However the SubType indicates whether it is
	B1 or B2. The Binding TLV and other TLVs are carried in the EAP-TLV		B1 or B2. The Binding TLV and other TLVs are carried in the EAP-TLV

	packet defined in [TLV]. The Binding TLV can be used to perform		packet defined in [PEAP]. The Binding TLV can be used to perform
	cryptographic Binding after each EAP method is complete. If this is the		cryptographic Binding after each EAP method is complete. If this is the
	final method, then the EAP-TLV packet must also include the Result TLV		final method, then the EAP-TLV packet must also include the Result TLV
	along with the Binding TLV.		along with the Binding TLV.

	Binding TLV (Also called Tunnel Authenticity/Integrity Check TLV):		Binding TLV (Also called Tunnel Authenticity/Integrity Check TLV):

	This message format is used for the Binding Request (B1) and also the		This message format is used for the Binding Request (B1) and also the
	Binding Response. This uses TLV type CRYPTO_BINDING_TLV. The format is		Binding Response. This uses TLV type CRYPTO_BINDING_TLV. The format is
	as given below.		as given below.

	0 1 2 3		0 1 2 3

	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|M\|R\| TLV Type \| Length \|		\|M\|R\| TLV Type \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| Version \| SubType \|		\| Version \| Recvd. Version\| SubType \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|		\| \|
	+ NONCE +		+ NONCE +
	\| \|		\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|		\| \|
	+ Compound MAC +		+ Compound MAC +
	\| \|		\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	M		M


	1 - Mandatory TLV		1 bit. Value = 1 - Mandatory TLV

	R		R


	Reserved, set to zero (0)		1 bit. Reserved, set to zero (0)

	TLV Type		TLV Type


	CRYPTO_BINDING_TLV. See IANA Considerations.		14 bits. Value = CRYPTO_BINDING_TLV. See IANA Considerations.

	Length		Length


	2 octets		2 octets. Value = 52 (excludes the 16 bit EAP-TLV header)

	Version		Version


	Version of tunnel protocol extension for binding. Initially set to		1 octet. Version of tunnel protocol extension for binding.
	0.		Initially set to 0.

			Received Version

			1 octet. PEAP version number received to prevent downgrade attacks.

	SubType		SubType

	2 octets.		2 octets.
	0 - Binding Request		0 - Binding Request
	1 - Binding Response		1 - Binding Response

	Nonce		Nonce
	32 octets. 256 bit Random number that is never repeated and is		32 octets. 256 bit Random number that is never repeated and is
	used for compound MAC key derivation at each end. It is a S_NONCE		used for compound MAC key derivation at each end. It is a S_NONCE

	skipping to change at page 31, line 14 ¶		skipping to change at page 31, line 14 ¶

	4.5 IANA Considerations		4.5 IANA Considerations

	IANA has assigned the EAP type number 33 for TLVs.		IANA has assigned the EAP type number 33 for TLVs.

	This protocol extension defines a new TLV types for cryptographic		This protocol extension defines a new TLV types for cryptographic
	binding that are defined below.		binding that are defined below.

	CRYPTO_BINDING_TLV 5		CRYPTO_BINDING_TLV 5


	It also uses the Result TLV (RESULT_TLV) defined in the draft[TLV, PEAP]		It also uses the Result TLV (RESULT_TLV) defined in the draft[PEAP]

	4.6 Security Considerations		4.6 Security Considerations

	This section describes the limitations of the solutions provided in this		This section describes the limitations of the solutions provided in this
	document and also provides guidelines for ensuring proper		document and also provides guidelines for ensuring proper
	implementation.		implementation.

	For our cryptographic binding based solution to work, the tunnel session		For our cryptographic binding based solution to work, the tunnel session
	keys (TSKs) and all the inner methods keys (ISKs) need to be guaranteed		keys (TSKs) and all the inner methods keys (ISKs) need to be guaranteed
	to be fresh and derived for new for every compound authentication		to be fresh and derived for new for every compound authentication

	skipping to change at page 31, line 50 ¶		skipping to change at page 31, line 50 ¶
	[EAP-MD5] [RFC2284]		[EAP-MD5] [RFC2284]

	[ISAKMP] [RFC2408]		[ISAKMP] [RFC2408]

	[IKE] [RFC2409]		[IKE] [RFC2409]

	[PEAPV0] Kamath, V., Palekar, A., Wodrich,M., "Microsoft's PEAP		[PEAPV0] Kamath, V., Palekar, A., Wodrich,M., "Microsoft's PEAP
	version 0 (Implementation in Windows XP SP1)", October		version 0 (Implementation in Windows XP SP1)", October
	2002 (work in progress)		2002 (work in progress)


	[TLV] Hiller, T., Palekar, A., Zorn, Glen, "A Container Type
	for the Extensible Authentication Protocol (EAP)",
	October 2002 (work in progress)

	[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,		[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
	RFC 1661, July 1994.		RFC 1661, July 1994.

	[RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC		[RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC
	1938, May 1996.		1938, May 1996.

	[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication		[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
	Protocol (CHAP)", RFC 1994, August 1996.		Protocol (CHAP)", RFC 1994, August 1996.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

	skipping to change at page 32, line 27 ¶		skipping to change at page 32, line 27 ¶
	November 2001.		November 2001.

	[EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS		[EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS
	Authentication Protocol", Internet draft (work in		Authentication Protocol", Internet draft (work in
	progress), February 2002.		progress), February 2002.

	[DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel		[DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel
	Mode", Internet draft (work in progress), draft-ietf-		Mode", Internet draft (work in progress), draft-ietf-
	ipsec-dhcp-13.txt, June 2001.		ipsec-dhcp-13.txt, June 2001.


	[PEAP] Andersson, H., et al., "Protected EAP Protocol (PEAP)",		[PEAP] Palekar et al., "Protected EAP Protocol (PEAP)",
	Internet draft (work in progress), draft-josefsson-		Internet draft (work in progress), draft-josefsson-

	pppext-eap-tls-eap-05.txt, September 2002.		pppext-eap-tls-eap-07.txt, October 2003.

	[PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE		[PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE
	Credential Provisioning Protocol", Internet draft (work		Credential Provisioning Protocol", Internet draft (work
	in progress), draft-ietf-ipsra-pic-06.txt, September		in progress), draft-ietf-ipsra-pic-06.txt, September
	2002.		2002.

	[IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec		[IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec
	Remote Access Scenarios", Internet draft (work in		Remote Access Scenarios", Internet draft (work in
	progress), draft-ietf-ipsra- reqmts-05.txt, September		progress), draft-ietf-ipsra- reqmts-05.txt, September
	2002.		2002.

	skipping to change at page 33, line 38 ¶		skipping to change at page 33, line 38 ¶

	[RFC1510] Kohl, J., Neuman, C., "The Kerberos Network		[RFC1510] Kohl, J., Neuman, C., "The Kerberos Network
	Authentication Service (V5)", RFC 1510, September 1993.		Authentication Service (V5)", RFC 1510, September 1993.

	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, November 1998.		RFC 2246, November 1998.

	[RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier",		[RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier",
	RFC 2486, January 1999.		RFC 2486, January 1999.


			[RFC2486bis] Blunk, L, Vollbrecht, J., Aboba, B., Carlson, J.,
			Levkowetz, H., "Extensible Authentication Protocol",
			RFC 2486bis-06.txt (work in progress), September 2003.

	[RFC2401] Atkinson, R., Kent, S., "Security Architecture for the		[RFC2401] Atkinson, R., Kent, S., "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.

	[RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC		[RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC
	2402, November 1998.		2402, November 1998.

	[RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload		[RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload
	(ESP)", RFC 2406, November 1998.		(ESP)", RFC 2406, November 1998.

	[RFC2407] Piper, D., "The Internet IP Security Domain of		[RFC2407] Piper, D., "The Internet IP Security Domain of

	skipping to change at page 35, line 43 ¶		skipping to change at page 35, line 43 ¶
	[IKEv2] Kaufman, C. (Editor), "Internet Key Exchange (IKEv2),		[IKEv2] Kaufman, C. (Editor), "Internet Key Exchange (IKEv2),
	draft-ietf-ipsec-ikev2-05.txt, February2003		draft-ietf-ipsec-ikev2-05.txt, February2003
	(work in progress)		(work in progress)

	Acknowledgments		Acknowledgments

	We wish to thank N. Asokan, Valtteri Niemi, Kaisa Nyberg and Henry		We wish to thank N. Asokan, Valtteri Niemi, Kaisa Nyberg and Henry
	Haverinen of Nokia for initially making us aware of the problem [MITM].		Haverinen of Nokia for initially making us aware of the problem [MITM].

	Special thanks to Bernard Aboba, N.Asokan, Jesse Walker, Farid Adrangi,		Special thanks to Bernard Aboba, N.Asokan, Jesse Walker, Farid Adrangi,

	Nancy Cam-Winget, Joe Salowey, Jari Arkko and Mohan Parthasarathy for		Nancy Cam-Winget, Joe Salowey, Jari Arkko, Mohan Parthasarathy,
	their valuable comments and suggestions.		Jukka Ylitalo, Michael Richardson, DongGook Park and Hao Zhou for their
			valuable comments and suggestions.

	Also additional thanks to Bernard Aboba for his expert advice and		Also additional thanks to Bernard Aboba for his expert advice and
	editorial assistance with the early versions of this document.		editorial assistance with the early versions of this document.

	Authors' Addresses		Authors' Addresses

	Jose Puthenkulam		Jose Puthenkulam
	Intel Corporation		Intel Corporation
	2111 NE 25th Avenue, JF2-58		2111 NE 25th Avenue, JF2-58
	Hillsboro, OR 97124		Hillsboro, OR 97124

	EMail: jose.p.puthenkulam@intel.com		EMail: jose.p.puthenkulam@intel.com
	Phone: +1 503 264 6121		Phone: +1 503 264 6121

	Fax: +1 503 264 8154		Fax: +1 503 264 4230
	Victor Lortz		Victor Lortz
	Intel Corporation		Intel Corporation
	2111 NE 25th Avenue, JF3-206		2111 NE 25th Avenue, JF3-206
	Hillsboro, OR 97124		Hillsboro, OR 97124

	EMail: victor.lortz@intel.com		EMail: victor.lortz@intel.com
	Phone: +1 503 264 3253		Phone: +1 503 264 3253
	Fax: +1 503 264 4230		Fax: +1 503 264 4230

	Ashwin Palekar		Ashwin Palekar
	Dan Simon		Dan Simon
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052

	EMail: {ashwinp, dansimon}@microsoft.com		EMail: {ashwinp, dansimon}@microsoft.com
	Phone: +1 425 882 8080		Phone: +1 425 882 8080
	Fax: +1 425 936 7329		Fax: +1 425 936 7329


			Intellectual Property Statement

			The IETF takes no position regarding the validity or scope of any
			intellectual property 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; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication 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 implementors or users of this specification can
			be obtained from the IETF Secretariat.

			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.

	Full Copyright Statement		Full Copyright Statement

	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it or
	assist in its implementation may be prepared, copied, published and		assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are included		provided that the above copyright notice and this paragraph are included
	on all such copies and derivative works. However, this document itself		on all such copies and derivative works. However, this document itself
	may not be modified in any way, such as by removing the copyright notice		may not be modified in any way, such as by removing the copyright notice

	skipping to change at page 37, line 4 ¶		skipping to change at page 37, line 27 ¶
	which case the procedures for copyrights defined in the Internet		which case the procedures for copyrights defined in the Internet
	Standards process must be followed, or as required to translate it into		Standards process must be followed, or as required to translate it into
	languages other than English. The limited permissions granted above are		languages other than English. The limited permissions granted above are
	perpetual and will not be revoked by the Internet Society or its		perpetual and will not be revoked by the Internet Society or its
	successors or assigns. This document and the information contained		successors or assigns. This document and the information contained
	herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE		herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


	EAP Issues		EAP Issues

	Open issues relating to EAP, including the issues described in this		Open issues relating to EAP, including the issues described in this
	document, are tracked on the following web site:		document, are tracked on the following web site:

	http://www.drizzle.com/~aboba/EAP/eapissues.html		http://www.drizzle.com/~aboba/EAP/eapissues.html

	Expiration Date		Expiration Date


	This memo is filed as <draft-puthenkulam-eap-binding-03.txt>, and		This memo is filed as <draft-puthenkulam-eap-binding-04.txt>, and
	expires on November 30,2003.		expires on April 26, 2004.

End of changes. 49 change blocks.
	69 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/