draft-ietf-hokey-emsk-hierarchy-05.txt		draft-ietf-hokey-emsk-hierarchy-06.txt
	Network Working Group J. Salowey		Network Working Group J. Salowey
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track L. Dondeti		Updates: eap-keying (RFC Ed to L. Dondeti
	Expires: October 24, 2008 V. Narayanan		replace this with RFC number) V. Narayanan
	Qualcomm, Inc		(if approved) Qualcomm, Inc
	M. Nakhjiri		Intended status: Standards Track M. Nakhjiri
	Motorola		Expires: December 25, 2008 Motorola
	April 22, 2008		June 23, 2008
	Specification for the Derivation of Root Keys from an Extended Master		Specification for the Derivation of Root Keys from an Extended Master
	Session Key (EMSK)		Session Key (EMSK)
	draft-ietf-hokey-emsk-hierarchy-05.txt		draft-ietf-hokey-emsk-hierarchy-06
	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 39		skipping to change at page 1, line 39
	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 October 24, 2008.		This Internet-Draft will expire on December 25, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The Extensible Authentication Protocol (EAP) defined the Extended		The Extensible Authentication Protocol (EAP) defined the Extended
	Master Session Key (EMSK) generation, but reserved it for unspecified		Master Session Key (EMSK) generation, but reserved it for unspecified
	future uses. This memo reserves the EMSK for the sole purpose of		future uses. This memo reserves the EMSK for the sole purpose of
	deriving root keys. Root keys are are master keys that can be used		deriving root keys. Root keys are are master keys that can be used
	for multiple purposes, identified by usage definitions. This		for multiple purposes, identified by usage definitions. This
	document also specifies a mechanism for avoiding conflicts between		document also specifies a mechanism for avoiding conflicts between
	root keys by deriving them in a manner that guarantee cryptographic		root keys by deriving them in a manner that guarantee cryptographic
	separation. Finally, this document also defines one such root key		separation. Finally, this document also defines one such root key
	usage: domain specific root keys are root keys made available to and		usage: domain specific root keys are root keys made available to and
	used within specific key management domains.		used within specific key management domains.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Applicable usages of keys derived from the EMSK . . . . . 3		1.1. Applicable usages of keys derived from the EMSK . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Cryptographic Separation and Coordinated Key Derivation . . . 5		2. Cryptographic Separation and Coordinated Key Derivation . . . 6
	3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 6		3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7
	3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7		3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 7
	3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8		3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 8
	3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 8		3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9
	3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9		3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 9
	4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10		4. Domain Specific Root Key Derivation . . . . . . . . . . . . . 10
	4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 11		4.1. Applicability of Multi-Domain usages . . . . . . . . . . . 12
	5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12		5. Requirements for Usage Definitions . . . . . . . . . . . . . . 12
	5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 12		5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13
	6. Requirements for EAP System . . . . . . . . . . . . . . . . . 13		6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14		7.1. Key strength . . . . . . . . . . . . . . . . . . . . . . . 14
	7.2. Cryptographic separation of keys . . . . . . . . . . . . . 14		7.2. Cryptographic separation of keys . . . . . . . . . . . . . 15
	7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 14		7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15
	7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 14		7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 15
	7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15		7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 15
	7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 15		7.6. Entropy consideration . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 15		8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 16		8.2. PRF numbers . . . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 20
	1. Introduction		1. Introduction
	This document deals with keys generated by authenticated key exchange		This document deals with keys generated by authenticated key exchange
	mechanisms defined within the EAP framework [RFC3748]. EAP defines		mechanisms defined within the EAP framework [RFC3748]. EAP defines
	two types of keying material; a Master Session Key (MSK) and an		two types of keying material; a Master Session Key (MSK) and an
	Extended Master Session Key (EMSK). The EAP specification implicitly		Extended Master Session Key (EMSK). The EAP specification implicitly
	assumes that the MSK produced by EAP will be used for a single		assumes that the MSK produced by EAP will be used for a single
	purpose at a single device, however it does reserve the EMSK for		purpose at a single device, however it does reserve the EMSK for
	future use. This document defines the EMSK to be used solely for		future use. This document defines the EMSK to be used solely for
	skipping to change at page 3, line 49		skipping to change at page 3, line 49
	Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs		Specific Usage Specific Root Keys (DSUSRK). The DSUSRKs are USRKs
	specific to a particular key management domain.		specific to a particular key management domain.
	In order to keep root keys for specific purposes separate from one		In order to keep root keys for specific purposes separate from one
	another, two requirements are defined in the following sections. One		another, two requirements are defined in the following sections. One
	is coordinated key derivation and another is cryptographic		is coordinated key derivation and another is cryptographic
	separation.		separation.
	1.1. Applicable usages of keys derived from the EMSK		1.1. Applicable usages of keys derived from the EMSK
	The EMSK is established as part of network access authentication and		The EMSK is typically established as part of network access
	authorization. The derived keys need to be distributed to the		authentication and authorization. It is expected that keys derived
	involved parties along with context necessary to use them. The		from EMSK will be used in protocols related to network access, such
	security of the system relies upon trust relationships between the		as handover optimizations, and the scope of these protocols is
	parties involved in this process. These trust relationships are the		usually restricted to the endpoints of the lower layers over which
	basis for applying protection during key transport and ensuring		EAP packets are sent.
	proper key usage. Hence, deriving USRKs or DSUSRKs for purposes
	where placing trust in the entities involved in establishing network
	access is inappropriate or not possible is NOT RECOMMENDED.
	It is also only feasible to make use of EMSK usages when network		In particular, it is inappropriate for the security of higher layer
	access occurs over an EAP-capable interface. If it is possible for		applications to solely rely on keys derived from network access
	an entity to access these services though an interface that does not		authentication. Even when used together with another, independent
	involve EAP authentication and authorization with the appropriate		security mechanism, the use of these keys needs to be carefully
	entities then alternate means of authentication and key establishment		evaluated with regards to the benefits of the optimization and the
	for these services needs to be provided.		need to support multiple solutions. Performance optimizations may
			not warrant the close tie-in that may be required between the layers
			in order to use EAP-based keys. Such optimizations may be offset by
			the complexities of managing the validity and usage of key materials.
			Keys generated from subsequent EAP authentications may be beyond the
			knowledge and control of applications.
			From an architectural point of view, applications should not make
			assumptions about the lower layer technology (such as network access
			authentication) used on any particular hop along the path between the
			application endpoints.
			From a practical point of view, making such assumptions would
			complicate using those applications over lower layers that do not use
			EAP, and make it more difficult for applications and network access
			technologies to evolve independently of each other.
			Parties using keys derived from EMSK also need trust relationships
			with the EAP endpoints, and mechanisms for securely communicating the
			keys.
			For most applications, it is not appropriate to assume that all
			current and future access networks are trusted to secure the
			application function. Instead, applications should implement the
			required security mechanisms in access independent manner.
			Implementation considerations may also complicate communication of
			keys to an application from the lower layer. For instance, in many
			configurations applications may run on a different device than the
			one providing EAP-based network access to it.
			Given all this, it is NOT RECOMMENDED to use keys derived from the
			EMSK as an exclusive security mechanism, when their usage is not
			inherently, and by permanent nature, tied to the lower layer where
			network access authentication was performed.
			Keys derived from EAP are pairwise by nature and are not directly
			suitable for multicast or other group usages such as those involved
			in some routing protocols. It is possible to use keys derived from
			EAP in protocols that distribute group keys to group participants.
			The definition of these group key distribution protocols is beyond
			the scope of this document and would require additional
			specification.
	1.2. Terminology		1.2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119]		document are to be interpreted as described in [RFC2119]
	The following terms are taken from [RFC3748]: EAP Server, peer,		The following terms are taken from [RFC3748]: EAP Server, peer,
	authenticator, Master Session Key (MSK), Extended Master Session Key		authenticator, Master Session Key (MSK), Extended Master Session Key
	(EMSK), Cryptographic Separation.		(EMSK), Cryptographic Separation.
	skipping to change at page 8, line 32		skipping to change at page 9, line 17
	additional KDFs. KDFs are assigned numbers through IANA following		additional KDFs. KDFs are assigned numbers through IANA following
	the policy set in section Section 8. The rules for negotiating a KDF		the policy set in section Section 8. The rules for negotiating a KDF
	are as follows:		are as follows:
	o If no other KDF is specified the KDF specified in this document		o If no other KDF is specified the KDF specified in this document
	MUST be used. This is the "default" KDF.		MUST be used. This is the "default" KDF.
	o The initial authenticated key exchange MAY specify a favored KDF.		o The initial authenticated key exchange MAY specify a favored KDF.
	For example an EAP method may define a preferred KDF to use in its		For example an EAP method may define a preferred KDF to use in its
	specification. If the initial authenticated key exchange		specification. If the initial authenticated key exchange
	specifies a KDF then this MUST override the default KDF.		specifies a KDF then this MUST override the default KDF.
	o A system MAY specify a separate default KDF if all participants
	within the system have the knowledge of which KDF to use. If
	specified this MUST take precedence over key exchange defined KDF.
	Note that usage definitions MUST NOT concern themselves with the		Note that usage definitions MUST NOT concern themselves with the
	details of the KDF construction or the KDF selection, they only need		details of the KDF construction or the KDF selection, they only need
	to worry about the inputs specified in Section 3.		to worry about the inputs specified in Section 3.
	3.1.2. Default KDF		3.1.2. Default KDF
	The default KDF for deriving root keys from an EMSK is taken from the		The default KDF for deriving root keys from an EMSK is taken from the
	PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256		PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256
	[SHA256]. The PRF+ construction was chosen because of its simplicity		[SHA256]. The PRF+ construction was chosen because of its simplicity
	skipping to change at page 14, line 17		skipping to change at page 14, line 35
	this specification may be exported from this boundary.		this specification may be exported from this boundary.
	o The EMSK MUST be unique for each EAP session		o The EMSK MUST be unique for each EAP session
	o The EAP method MUST provide an identifier for the EAP transaction		o The EAP method MUST provide an identifier for the EAP transaction
	that generated the key		that generated the key
	o The system MUST define which usage definitions are used and how		o The system MUST define which usage definitions are used and how
	they are invoked.		they are invoked.
	o The system may define ways to select an alternate PRF for key		o The system may define ways to select an alternate PRF for key
	derivation as defined in Section 3.1.		derivation as defined in Section 3.1.
	The system MAY use the MSK transmitted to the NAS in any way it		The system MAY use the MSK transmitted to the NAS in any way it
	chooses. This is required for backward compatibility. New usage		chooses in accordance with [RFC3748] [I-D.ietf-eap-keying] and other
	definitions following this specification MUST NOT use the MSK. If		relevant specifications. This is required for backward
	more than one usage uses the MSK, then the cryptographic separation		compatibility. New usage definitions following this specification
	is not achieved. Implementations MUST prevent such combinations.		MUST NOT use the MSK. If more than one usage uses the MSK, then the
			cryptographic separation is not achieved. Implementations MUST
			prevent such combinations.
	7. Security Considerations		7. Security Considerations
	7.1. Key strength		7.1. Key strength
	The effective key strength of the derived keys will never be greater		The effective key strength of the derived keys will never be greater
	than the strength of the EMSK (or a master key internal to an EAP		than the strength of the EMSK (or a master key internal to an EAP
	mechanism).		mechanism).
	7.2. Cryptographic separation of keys		7.2. Cryptographic separation of keys
	skipping to change at page 15, line 42		skipping to change at page 16, line 16
	The number of root keys derived from the EMSK is expected to be low.		The number of root keys derived from the EMSK is expected to be low.
	Note that there is no randomness required to be introduced into the		Note that there is no randomness required to be introduced into the
	EMSK to root key derivation beyond the root key labels. Thus, if		EMSK to root key derivation beyond the root key labels. Thus, if
	many keys are going to be derived from an Root Key it is important		many keys are going to be derived from an Root Key it is important
	that Root Key to child key derivation introduce fresh random numbers		that Root Key to child key derivation introduce fresh random numbers
	in deriving each key.		in deriving each key.
	8. IANA Considerations		8. IANA Considerations
	The keywords "PRIVATE USE", "SPECIFICATION REQUIRED" and "IETF		The keywords "Private Use", "Specification Required" and "IETF
	CONSENSUS" that appear in this document when used to describe		Consensus" that appear in this document when used to describe
	namespace allocation are to be interpreted as described in [RFC2434].		namespace allocation are to be interpreted as described in [RFC5226].
	8.1. Key Labels		8.1. Key Labels
	This specification introduces a new name space for "USRK key labels".		This specification introduces a new name space for "USRK key labels".
	Key labels are of one of two formats: "label-string" or		Key labels MUST be printable US-ASCII strings, and MUST NOT contain
	"label-string@specorg" (without the double quotes).		the characters at-sign ("@") except as noted below, comma (","),
			whitespace, control characters (ASCII codes 32 or less), or the ASCII
			code 127 (DEL). Labels are case-sensitive, and MUST NOT be longer
			than 64 characters.
	Labels of the form "label-string" registered by the IANA MUST be		Labels can be assigned based on Specification Required policy
	printable US-ASCII strings, and MUST NOT contain the characters at-		[RFC5226]. In addition, the labels "experimental1" and
	sign ("@"), comma (","), whitespace, control characters (ASCII codes		"experimental2" are reserved for experimental use. The following
	32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive,		considerations apply to their use:
	and MUST NOT be longer than 64 characters. Labels of this form are
	assigned based on the IETF CONSENSUS policy.
	Labels with the at-sign in them of the form "label-string@specorg"		Production networks do not necessarily support the use of
	where the part preceding the at-sign is the label. The format of the		experimental code points. The network scope of support for
	part preceding the at-sign is not specified; however, these labels		experimental values should carefully be evaluated before deploying
	MUST be printable US-ASCII strings, and MUST NOT contain the comma		any experiment across extended network domains, such as the public
	character (","), whitespace, control characters (ASCII codes 32 or		Internet. The potential to disrupt the stable operation of EAP
	less), or the ASCII code 127 (DEL). They MUST have only a single at-		devices is a consideration when planning an experiment using such
	sign in them. The part following the at-sign MUST be a valid, fully		code points.
	qualified Internet domain name [RFC1034] controlled by the person or
	organization defining the label. Labels are case-sensitive, and MUST
	NOT be longer than 64 characters. It is up to each organization how
	it manages its local namespace. Note that the total number of octets
	in a label is limited to 255. It has been noted that these labels
	resemble STD 11 [RFC0822] addresses and network access identifiers
	(NAI) defined in [RFC4282]. This is purely coincidental and has
	nothing to do with STD 11 [RFC0822] or [RFC4282]. An example of a
	key label is "service@example.com" (without the double quotes).
	Labels within the "ietf.org" organization are assigned based on the		The network administrators should ensure that each code point is used
	IETF CONSENSUS policy with specification recommended. Labels from		consistently to avoid interference between experiments. Particular
	other organizations may be registered with IANA by the person or		attention should be given to security vulnerabilities and the freedom
	organization controlling the domain with an assignment policy of		of different domains to employ their own experiments. Cross-domain
	SPECIFICATION REQUIRED. It is RECOMMENDED that the specification		usage is NOT RECOMMENDED.
	contain the following information:
	The following labels are reserved by this document: "EMSK",		Similarly, labels "private1" and "private2" have been reserved for
	"dsrk@ietf.org".		Private Use within an organization. Again, cross-domain usage of
			these labels is NOT RECOMMENDED.
			Labels starting with a string and followed by the "@" and a valid,
			fully qualified Internet domain name [RFC1034] can be requested by by
			the person or organization who are in control of the domain name.
			Such labels can be allocated based on Specification Required. It is
			RECOMMENDED that the specification contain the following information:
	o A description of the usage		o A description of the usage
	o The key label to be used		o The key label to be used
	o Length of the Root Key		o Length of the Root Key
	o If optional data is used, what it is and how it is maintained		o If optional data is used, what it is and how it is maintained
	o How child keys will be derived from the Root Key and how they will		o How child keys will be derived from the Root Key and how they will
	be used		be used
	o How lifetime of the Root Key and its child keys will be managed		o How lifetime of the Root Key and its child keys will be managed
	o Where the Root Keys or child keys will be used and how they are		o Where the Root Keys or child keys will be used and how they are
	communicated if necessary		communicated if necessary
			The following labels are reserved by this document: "EMSK",
			"dsrk@ietf.org".
	8.2. PRF numbers		8.2. PRF numbers
	This specification introduces a new number space for "EMSK PRF		This specification introduces a new number space for "EMSK PRF
	numbers". The numbers are int he range 0 to 255 Numbers from 0 to		numbers". The numbers are int he range 0 to 255 Numbers from 0 to
	220 are assigned through the policy IETF CONSENSUS and numbers in the		220 are assigned through the policy IETF Consensus and numbers in the
	range 221 to 255 are left for PRIVATE USE. The initial registry		range 221 to 255 are left for Private Use. The initial registry
	should contain the following values:		should contain the following values:
	0 RESERVED		0 RESERVED
	1 HMAC-SHA-256 PRF+ (Default)		1 HMAC-SHA-256 PRF+ (Default)
	9. Acknowledgements		9. Acknowledgements
	This document expands upon previous collaboration with Pasi Eronen.		This document expands upon previous collaboration with Pasi Eronen.
	This document reflects conversations with Bernard Aboba, Jari Arkko,		This document reflects conversations with Bernard Aboba, Jari Arkko,
	Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen		Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen
	Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members		Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba and members
	of the EAP and HOKEY working groups.		of the EAP and HOKEY working groups.
	Thanks to Dan Harkins for the idea of using a single root key name to		Thanks to Dan Harkins for the idea of using a single root key name to
	refer to all keys.		refer to all keys.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-eap-keying]
			Aboba, B., Simon, D., and P. Eronen, "Extensible
			Authentication Protocol (EAP) Key Management Framework",
			draft-ietf-eap-keying-22 (work in progress),
			November 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[SHA256] National Institute of Standards and Technology, "Secure		[SHA256] National Institute of Standards and Technology, "Secure
	Hash Standard", FIPS 180-2, August 2002.		Hash Standard", FIPS 180-2, August 2002.
	With Change Notice 1 dated February 2004		With Change Notice 1 dated February 2004
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-eap-keying]
	Aboba, B., Simon, D., and P. Eronen, "Extensible
	Authentication Protocol (EAP) Key Management Framework",
	draft-ietf-eap-keying-22 (work in progress),
	November 2007.
	[RFC0822] Crocker, D., "Standard for the format of ARPA Internet		[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.		text messages", STD 11, RFC 822, August 1982.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The		[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
	Network Access Identifier", RFC 4282, December 2005.		Network Access Identifier", RFC 4282, December 2005.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	skipping to change at page 19, line 44		skipping to change at line 898
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 27 change blocks.
	100 lines changed or deleted		136 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/