draft-haverinen-pppext-eap-sim-14.txt		draft-haverinen-pppext-eap-sim-15r1.txt
	Network Working Group H. Haverinen, Ed.		Network Working Group H. Haverinen, Ed.
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: April 25, 2005 J. Salowey, Ed.		Expires: May 11, 2005 J. Salowey, Ed.
	Cisco Systems		Cisco Systems
	October 25, 2004		November 10, 2004
	Extensible Authentication Protocol Method for GSM Subscriber Identity		Extensible Authentication Protocol Method for GSM Subscriber Identity
	Modules (EAP-SIM)		Modules (EAP-SIM)
	draft-haverinen-pppext-eap-sim-14.txt		draft-haverinen-pppext-eap-sim-15r1.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 36		skipping to change at page 1, line 37
	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 April 25, 2005.		This Internet-Draft will expire on May 11, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document specifies an Extensible Authentication Protocol (EAP)		This document specifies an Extensible Authentication Protocol (EAP)
	mechanism for authentication and session key distribution using the		mechanism for authentication and session key distribution using the
	Global System for Mobile Communications (GSM) Subscriber Identity		Global System for Mobile Communications (GSM) Subscriber Identity
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	also includes network authentication, user anonymity support, result		also includes network authentication, user anonymity support, result
	indications, and a fast re-authentication procedure.		indications, and a fast re-authentication procedure.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1 Version Negotiation . . . . . . . . . . . . . . . . . . . 11		4.1 Version Negotiation . . . . . . . . . . . . . . . . . . . 11
	4.2 Identity Management . . . . . . . . . . . . . . . . . . . 11		4.2 Identity Management . . . . . . . . . . . . . . . . . . . 12
	4.2.1 Format, Generation and Usage of Peer Identities . . . 11		4.2.1 Format, Generation and Usage of Peer Identities . . . 12
	4.2.2 Communicating the Peer Identity to the Server . . . . 18		4.2.2 Communicating the Peer Identity to the Server . . . . 18
	4.2.3 Choice of Identity for the EAP-Response/Identity . . . 19		4.2.3 Choice of Identity for the EAP-Response/Identity . . . 19
	4.2.4 Server Operation in the Beginning of EAP-SIM		4.2.4 Server Operation in the Beginning of EAP-SIM
	Exchange . . . . . . . . . . . . . . . . . . . . . . . 19		Exchange . . . . . . . . . . . . . . . . . . . . . . . 20
	4.2.5 Processing of EAP-Request/SIM/Start by the Peer . . . 20		4.2.5 Processing of EAP-Request/SIM/Start by the Peer . . . 20
	4.2.6 Attacks against Identity Privacy . . . . . . . . . . . 21		4.2.6 Attacks against Identity Privacy . . . . . . . . . . . 22
	4.2.7 Processing of AT_IDENTITY by the Server . . . . . . . 22		4.2.7 Processing of AT_IDENTITY by the Server . . . . . . . 22
	4.3 Message Sequence Examples (Informative) . . . . . . . . . 23		4.3 Message Sequence Examples (Informative) . . . . . . . . . 23
	4.3.1 Full Authentication . . . . . . . . . . . . . . . . . 23		4.3.1 Full Authentication . . . . . . . . . . . . . . . . . 23
	4.3.2 Fast Re-authentication . . . . . . . . . . . . . . . . 24		4.3.2 Fast Re-authentication . . . . . . . . . . . . . . . . 24
	4.3.3 Fall Back to Full Authentication . . . . . . . . . . . 25		4.3.3 Fall Back to Full Authentication . . . . . . . . . . . 25
	4.3.4 Requesting the Permanent Identity 1 . . . . . . . . . 26		4.3.4 Requesting the Permanent Identity 1 . . . . . . . . . 26
	4.3.5 Requesting the Permanent Identity 2 . . . . . . . . . 27		4.3.5 Requesting the Permanent Identity 2 . . . . . . . . . 27
	4.3.6 Three EAP-SIM/Start Roundtrips . . . . . . . . . . . . 28		4.3.6 Three EAP-SIM/Start Roundtrips . . . . . . . . . . . . 28
	5. Fast Re-Authentication . . . . . . . . . . . . . . . . . . . 30		5. Fast Re-Authentication . . . . . . . . . . . . . . . . . . . 30
	5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 30		5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 30
	skipping to change at page 3, line 35		skipping to change at page 3, line 35
	9.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . 60		9.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . 60
	9.13 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . 62		9.13 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . 62
	9.14 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . 62		9.14 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . 62
	9.15 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . 63		9.15 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . 63
	9.16 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . 63		9.16 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . 63
	9.17 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . 63		9.17 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . 63
	9.18 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . 64		9.18 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . 64
	9.19 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . 65		9.19 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . 65
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 65		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 65
	11. Security Considerations . . . . . . . . . . . . . . . . . . 67		11. Security Considerations . . . . . . . . . . . . . . . . . . 67
	11.1 Identity Protection . . . . . . . . . . . . . . . . . . 67		11.1 A3 and A8 Algorithms . . . . . . . . . . . . . . . . . . 67
	11.2 Mutual Authentication and Triplet Exposure . . . . . . . 68		11.2 Identity Protection . . . . . . . . . . . . . . . . . . 67
	11.3 Flooding the Authentication Centre . . . . . . . . . . . 69		11.3 Mutual Authentication and Triplet Exposure . . . . . . . 68
	11.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . 69		11.4 Flooding the Authentication Centre . . . . . . . . . . . 69
	11.5 Dictionary Attacks . . . . . . . . . . . . . . . . . . . 70		11.5 Key Derivation . . . . . . . . . . . . . . . . . . . . . 69
	11.6 Credentials Reuse . . . . . . . . . . . . . . . . . . . 70		11.6 Cryptographic Separation of Keys and Session
	11.7 Integrity and Replay Protection, and Confidentiality . . 71		Independence . . . . . . . . . . . . . . . . . . . . . . 70
	11.8 Negotiation Attacks . . . . . . . . . . . . . . . . . . 72		11.7 Dictionary Attacks . . . . . . . . . . . . . . . . . . . 71
	11.9 Protected Result Indications . . . . . . . . . . . . . . 72		11.8 Credentials Reuse . . . . . . . . . . . . . . . . . . . 71
	11.10 Man-in-the-middle Attacks . . . . . . . . . . . . . . . 73		11.9 Integrity and Replay Protection, and Confidentiality . . 72
	11.11 Generating Random Numbers . . . . . . . . . . . . . . . 73		11.10 Negotiation Attacks . . . . . . . . . . . . . . . . . . 73
	12. Security Claims . . . . . . . . . . . . . . . . . . . . . . 73		11.11 Protected Result Indications . . . . . . . . . . . . . . 73
	13. Acknowledgements and Contributions . . . . . . . . . . . . . 74		11.12 Man-in-the-middle Attacks . . . . . . . . . . . . . . . 74
	13.1 Contributors . . . . . . . . . . . . . . . . . . . . . . 74		11.13 Generating Random Numbers . . . . . . . . . . . . . . . 74
	13.2 Acknowledgements . . . . . . . . . . . . . . . . . . . . 74		12. Security Claims . . . . . . . . . . . . . . . . . . . . . . 74
	13.2.1 Contributors' Addresses . . . . . . . . . . . . . . 75		13. Acknowledgements and Contributions . . . . . . . . . . . . . 75
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 76		13.1 Contributors . . . . . . . . . . . . . . . . . . . . . . 75
	14.1 Normative References . . . . . . . . . . . . . . . . . . . 76		13.2 Acknowledgements . . . . . . . . . . . . . . . . . . . . 76
	14.2 Informative References . . . . . . . . . . . . . . . . . . 77		13.2.1 Contributors' Addresses . . . . . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 78		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
	A. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 78		14.1 Normative References . . . . . . . . . . . . . . . . . . . 77
	A.1 EAP-Request/Identity . . . . . . . . . . . . . . . . . . . 78		14.2 Informative References . . . . . . . . . . . . . . . . . . 78
	A.2 EAP-Response/Identity . . . . . . . . . . . . . . . . . . 79		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 80
	A.3 EAP-Request/SIM/Start . . . . . . . . . . . . . . . . . . 79		A. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 80
	A.4 EAP-Response/SIM/Start . . . . . . . . . . . . . . . . . . 79		A.1 EAP-Request/Identity . . . . . . . . . . . . . . . . . . . 80
	A.5 EAP-Request/SIM/Challenge . . . . . . . . . . . . . . . . 80		A.2 EAP-Response/Identity . . . . . . . . . . . . . . . . . . 80
	A.6 EAP-Response/SIM/Challenge . . . . . . . . . . . . . . . . 82		A.3 EAP-Request/SIM/Start . . . . . . . . . . . . . . . . . . 81
	A.7 EAP-Success . . . . . . . . . . . . . . . . . . . . . . . 83		A.4 EAP-Response/SIM/Start . . . . . . . . . . . . . . . . . . 81
	A.8 Fast Re-authentication . . . . . . . . . . . . . . . . . . 83		A.5 EAP-Request/SIM/Challenge . . . . . . . . . . . . . . . . 82
	A.9 EAP-Request/SIM/Re-authentication . . . . . . . . . . . . 83		A.6 EAP-Response/SIM/Challenge . . . . . . . . . . . . . . . . 84
	A.10 EAP-Response/SIM/Re-authentication . . . . . . . . . . . 86		A.7 EAP-Success . . . . . . . . . . . . . . . . . . . . . . . 85
	B. Pseudo-Random Number Generator . . . . . . . . . . . . . . . 87		A.8 Fast Re-authentication . . . . . . . . . . . . . . . . . . 85
	Intellectual Property and Copyright Statements . . . . . . . 88		A.9 EAP-Request/SIM/Re-authentication . . . . . . . . . . . . 85
			A.10 EAP-Response/SIM/Re-authentication . . . . . . . . . . . 88
			B. Pseudo-Random Number Generator . . . . . . . . . . . . . . . 89
			Intellectual Property and Copyright Statements . . . . . . . 90
	1. Introduction		1. Introduction
	This document specifies an Extensible Authentication Protocol (EAP)		This document specifies an Extensible Authentication Protocol (EAP)
	[RFC3748] mechanism for authentication and session key distribution		[RFC3748] mechanism for authentication and session key distribution
	using the Global System for Mobile Communications (GSM) Subscriber		using the Global System for Mobile Communications (GSM) Subscriber
	Identity Module (SIM).		Identity Module (SIM).
	GSM is a second generation mobile network standard. Second		GSM is a second generation mobile network standard. Second
	generation mobile networks and third generation mobile networks use		generation mobile networks and third generation mobile networks use
	skipping to change at page 5, line 27		skipping to change at page 5, line 27
	GSM authentication is based on a challenge-response mechanism. The		GSM authentication is based on a challenge-response mechanism. The
	A3/A8 authentication and key derivation algorithms that run on the		A3/A8 authentication and key derivation algorithms that run on the
	SIM can be given a 128-bit random number (RAND) as a challenge. The		SIM can be given a 128-bit random number (RAND) as a challenge. The
	SIM runs operator-specific algorithms, which take the RAND and a		SIM runs operator-specific algorithms, which take the RAND and a
	secret key Ki stored on the SIM as input, and produce a 32-bit		secret key Ki stored on the SIM as input, and produce a 32-bit
	response (SRES) and a 64-bit long key Kc as output. The Kc key is		response (SRES) and a 64-bit long key Kc as output. The Kc key is
	originally intended to be used as an encryption key over the air		originally intended to be used as an encryption key over the air
	interface, but in this protocol it is used for deriving keying		interface, but in this protocol it is used for deriving keying
	material and not directly used. Hence the secrecy of Kc is critical		material and not directly used. Hence the secrecy of Kc is critical
	to the security of this protocol. Please find more information about		to the security of this protocol. Please find more information about
	GSM authentication in [GSM 03.20].		GSM authentication in [GSM 03.20]. Please see Section 11.1 for more
			discussion about the GSM algorithms used in EAP-SIM.
	The lack of mutual authentication is a weakness in GSM		The lack of mutual authentication is a weakness in GSM
	authentication. The 64 bit cipher key (Kc) that is derived is not		authentication. The 64 bit cipher key (Kc) that is derived is not
	strong enough for data networks where stronger and longer keys are		strong enough for data networks where stronger and longer keys are
	required. Hence in EAP-SIM, several RAND challenges are used for		required. Hence in EAP-SIM, several RAND challenges are used for
	generating several 64-bit Kc keys, which are combined to constitute		generating several 64-bit Kc keys, which are combined to constitute
	stronger keying material. In EAP-SIM the client issues a random		stronger keying material. In EAP-SIM the client issues a random
	number NONCE_MT to the network, in order to contribute to key		number NONCE_MT to the network, in order to contribute to key
	derivation, and to prevent replays of EAP-SIM requests from previous		derivation, and to prevent replays of EAP-SIM requests from previous
	exchanges. The NONCE_MT can be conceived as the client's challenge		exchanges. The NONCE_MT can be conceived as the client's challenge
	skipping to change at page 12, line 45		skipping to change at page 13, line 4
	EAP-SIM includes optional identity privacy (anonymity) support that		EAP-SIM includes optional identity privacy (anonymity) support that
	can be used to hide the cleartext permanent identity and thereby to		can be used to hide the cleartext permanent identity and thereby to
	make the subscriber's EAP exchanges untraceable to eavesdroppers.		make the subscriber's EAP exchanges untraceable to eavesdroppers.
	Because the permanent identity never changes, revealing it would help		Because the permanent identity never changes, revealing it would help
	observers to track the user. The permanent identity is usually based		observers to track the user. The permanent identity is usually based
	on the IMSI, which may further help the tracking, because the same		on the IMSI, which may further help the tracking, because the same
	identifier may be used in other contexts as well. Identity privacy		identifier may be used in other contexts as well. Identity privacy
	is based on temporary identities, or pseudonyms, which are equivalent		is based on temporary identities, or pseudonyms, which are equivalent
	to but separate from the Temporary Mobile Subscriber Identities		to but separate from the Temporary Mobile Subscriber Identities
	(TMSI) that are used on cellular networks. Please see Section 11.1		(TMSI) that are used on cellular networks. Please see Section 11.2
	for security considerations regarding identity privacy.		for security considerations regarding identity privacy.
	4.2.1.3 Username Types in EAP-SIM identities		4.2.1.3 Username Types in EAP-SIM identities
	There are three types of usernames in EAP-SIM peer identities:		There are three types of usernames in EAP-SIM peer identities:
	(1) Permanent usernames. For example,		(1) Permanent usernames. For example,
	1123456789098765@myoperator.com might be a valid permanent identity.		1123456789098765@myoperator.com might be a valid permanent identity.
	In this example, 1123456789098765 is the permanent username.		In this example, 1123456789098765 is the permanent username.
	skipping to change at page 67, line 26		skipping to change at page 67, line 26
	and EAP-SIM.		and EAP-SIM.
	11. Security Considerations		11. Security Considerations
	The EAP base protocol [RFC3748] highlights several attacks that are		The EAP base protocol [RFC3748] highlights several attacks that are
	possible against the EAP protocol as there is no inherent security		possible against the EAP protocol as there is no inherent security
	mechanisms provided. This section discusses the claimed security		mechanisms provided. This section discusses the claimed security
	properties of EAP-SIM as well as vulnerabilities and security		properties of EAP-SIM as well as vulnerabilities and security
	recommendations.		recommendations.
	11.1 Identity Protection		11.1 A3 and A8 Algorithms
			The GSM A3 and A8 algorithms are used in EAP-SIM. [GSM 03.20]
			specifies the general GSM authentication procedure and the external
			interface (inputs and outputs) of the A3 and A8 algorithms. The
			operation of these functions falls completely within the domain of an
			individual operator, and the functions are therefore specified by
			each operator rather than being fully standardised. The GSM-MILENAGE
			algorithm, specified publicly in [3GPP TS 55.205], is an example
			algorithm set for A3 and A8 algorithms.
			The security of the A3 and A8 algorithms is important to the security
			of EAP-SIM. Some A3/A8 algorithms have been compromised; see for
			example [GSM Cloning] for discussion about the security of COMP-128
			version 1. Note that several revised versions of the COMP-128 A3/A8
			algorithm have been devised after the publication of these weaknesses
			and that the publicly specified GSM-MILENAGE algorithm is not
			vulnerable to any known attacks.
			11.2 Identity Protection
	EAP-SIM includes optional identity privacy support that protects the		EAP-SIM includes optional identity privacy support that protects the
	privacy of the subscriber identity against passive eavesdropping.		privacy of the subscriber identity against passive eavesdropping.
	This document only specifies a mechanism to deliver pseudonyms from		This document only specifies a mechanism to deliver pseudonyms from
	the server to the peer as part of an EAP-SIM exchange. Hence, a peer		the server to the peer as part of an EAP-SIM exchange. Hence, a peer
	that has not yet performed any EAP-SIM exchanges does not typically		that has not yet performed any EAP-SIM exchanges does not typically
	have a pseudonym available. If the peer does not have a pseudonym		have a pseudonym available. If the peer does not have a pseudonym
	available, then the privacy mechanism cannot be used, but the		available, then the privacy mechanism cannot be used, but the
	permanent identity will have to be sent in the clear. The terminal		permanent identity will have to be sent in the clear. The terminal
	SHOULD store the pseudonym in a non-volatile memory so that it can be		SHOULD store the pseudonym in a non-volatile memory so that it can be
	skipping to change at page 68, line 5		skipping to change at page 68, line 24
	If the peer and server cannot guarantee that the pseudonym will be		If the peer and server cannot guarantee that the pseudonym will be
	maintained reliably and identity privacy is required then additional		maintained reliably and identity privacy is required then additional
	protection from an external security mechanism such as Protected		protection from an external security mechanism such as Protected
	Extensible Authentication Protocol (PEAP) [PEAP] may be used. If an		Extensible Authentication Protocol (PEAP) [PEAP] may be used. If an
	external security mechanism is in use the identity privacy features		external security mechanism is in use the identity privacy features
	of EAP-SIM may not be useful. The security considerations of using		of EAP-SIM may not be useful. The security considerations of using
	an external security mechanism with EAP-SIM are beyond the scope of		an external security mechanism with EAP-SIM are beyond the scope of
	this document.		this document.
	11.2 Mutual Authentication and Triplet Exposure		11.3 Mutual Authentication and Triplet Exposure
	EAP-SIM provides mutual authentication. The peer believes that the		EAP-SIM provides mutual authentication. The peer believes that the
	network is authentic because the network can calculate a correct		network is authentic because the network can calculate a correct
	AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate		AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate
	AT_MAC it is sufficient to know the RAND and Kc values from the GSM		AT_MAC it is sufficient to know the RAND and Kc values from the GSM
	triplets (RAND, SRES, Kc) used in the authentication. Because the		triplets (RAND, SRES, Kc) used in the authentication. Because the
	network selects the RAND challenges and the triplets, an attacker		network selects the RAND challenges and the triplets, an attacker
	that knows n (2 or 3) GSM triplets for the subscriber is able to		that knows n (2 or 3) GSM triplets for the subscriber is able to
	impersonate a valid network to the peer. (Some peers MAY employ an		impersonate a valid network to the peer. (Some peers MAY employ an
	implementation-specific counter-measure against impersonating a valid		implementation-specific counter-measure against impersonating a valid
	network by re-using a previously used RAND; see below.) Given		network by re-using a previously used RAND; see below.) Given
	physical access to the SIM card, it is easy to obtain any number of		physical access to the SIM card, it is easy to obtain any number of
	GSM triplets. Another way to obtain triplets is to mount an attack		GSM triplets. Another way to obtain triplets is to mount an attack
	on the peer platform via a virus or other malicious piece of		on the peer platform via a virus or other malicious piece of
	software. The peer SHOULD be protected against triplet querying		software. The peer SHOULD be protected against triplet querying
	attacks by malicious software.		attacks by malicious software.
	If the same SIM credentials are also used for GSM traffic, the		If the same SIM credentials are also used for GSM traffic, the
	triplets could be revealed in the GSM network; see Section 11.6.		triplets could be revealed in the GSM network; see Section 11.8.
	The security of EAP-SIM is based on the secrecy of Kc keys, which are		The security of EAP-SIM is based on the secrecy of Kc keys, which are
	considered secret intermediate results in the EAP-SIM cryptographic		considered secret intermediate results in the EAP-SIM cryptographic
	calculations. Care should be taken not to expose Kc keys to		calculations. Care should be taken not to expose Kc keys to
	attackers when they are transmitted between entities, stored or		attackers when they are transmitted between entities, stored or
	handled. Steps should be taken to limit the transport, storage and		handled. Steps should be taken to limit the transport, storage and
	handling of these values outside a protected environment. These		handling of these values outside a protected environment. These
	considerations are important at both the peer and EAP server		considerations are important at both the peer and EAP server
	implementations.		implementations.
	skipping to change at page 69, line 5		skipping to change at page 69, line 24
	used RANDs, and the peer MAY check the freshness of the server's		used RANDs, and the peer MAY check the freshness of the server's
	RANDs. The operation in cases when the peer detects that the RANDs		RANDs. The operation in cases when the peer detects that the RANDs
	are not fresh is specified in Section 6.3.1.		are not fresh is specified in Section 6.3.1.
	Preventing the re-use of authentication vectors has been taken into		Preventing the re-use of authentication vectors has been taken into
	account in the design of the UMTS Authentication and Key Agreement		account in the design of the UMTS Authentication and Key Agreement
	(AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet		(AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet
	re-use properties of EAP-SIM are not considered sufficient, it is		re-use properties of EAP-SIM are not considered sufficient, it is
	advised to use EAP-AKA.		advised to use EAP-AKA.
	11.3 Flooding the Authentication Centre		11.4 Flooding the Authentication Centre
	The EAP-SIM server typically obtains authentication vectors from the		The EAP-SIM server typically obtains authentication vectors from the
	Authentication Centre (AuC). EAP-SIM introduces a new usage for the		Authentication Centre (AuC). EAP-SIM introduces a new usage for the
	AuC. The protocols between the EAP-SIM server and the AuC are out of		AuC. The protocols between the EAP-SIM server and the AuC are out of
	the scope of this document. However, it should be noted that a		the scope of this document. However, it should be noted that a
	malicious EAP-SIM peer may generate a lot of protocol requests to		malicious EAP-SIM peer may generate a lot of protocol requests to
	mount a denial of service attack. The EAP-SIM server implementation		mount a denial of service attack. The EAP-SIM server implementation
	SHOULD take this into account and SHOULD take steps to limit the		SHOULD take this into account and SHOULD take steps to limit the
	traffic that it generates towards the AuC, preventing the attacker		traffic that it generates towards the AuC, preventing the attacker
	from flooding the AuC and from extending the denial of service attack		from flooding the AuC and from extending the denial of service attack
	from EAP-SIM to other users of the AuC.		from EAP-SIM to other users of the AuC.
	11.4 Key Derivation		11.5 Key Derivation
	EAP-SIM supports key derivation. The key hierarchy is specified in		EAP-SIM supports key derivation. The key hierarchy is specified in
	Section 6.4. EAP-SIM combines several GSM triplets in order to		Section 6.4. EAP-SIM combines several GSM triplets in order to
	generate stronger keying material and stronger AT_MAC values. The		generate stronger keying material and stronger AT_MAC values. The
	actual strength of the resulting keys depends, among other things, on		actual strength of the resulting keys depends, among other things, on
	some operator specific parameters including authentication		some operator specific parameters including authentication
	algorithms, the strength of the Ki key, and the quality of the RAND		algorithms, the strength of the Ki key, and the quality of the RAND
	challenges. For example, some SIM cards generate Kc keys with 10		challenges. For example, some SIM cards generate Kc keys with 10
	bits set to zero. Such restrictions may prevent the concatenation		bits set to zero. Such restrictions may prevent the concatenation
	technique from yielding strong session keys. Because the strength of		technique from yielding strong session keys. Because the strength of
	skipping to change at page 70, line 5		skipping to change at page 70, line 25
	values from AT_MAC would require the attacker to reverse the keyed		values from AT_MAC would require the attacker to reverse the keyed
	message authentication code function HMAC-SHA1-128.		message authentication code function HMAC-SHA1-128.
	As EAP-SIM does not expose any values calculated from an individual		As EAP-SIM does not expose any values calculated from an individual
	GSM Kc keys, it is not possible to mount a brute force attack on just		GSM Kc keys, it is not possible to mount a brute force attack on just
	one of the Kc keys in EAP-SIM. Therefore, when considering brute		one of the Kc keys in EAP-SIM. Therefore, when considering brute
	force attacks on the values exposed in EAP-SIM, the effective length		force attacks on the values exposed in EAP-SIM, the effective length
	of EAP-SIM session keys is not compromised by the fact that they are		of EAP-SIM session keys is not compromised by the fact that they are
	combined from several shorter keys, i.e the effective length of 128		combined from several shorter keys, i.e the effective length of 128
	bits may be achieved. For additional considerations see Section		bits may be achieved. For additional considerations see Section
	11.6. The EAP Transient Keys used to protect EAP-SIM packets		11.8.
	(K_encr, K_aut) and the Master Session Key are cryptographically
	separate. An attacker cannot derive any non-trivial information from
	K_encr or K_aut based on the Master Session Key or vice versa. An
	attacker also cannot calculate the pre-shared secret from the GSM Kc
	keys used, EAP-SIM K_encr, EAP-SIM K_aut, or from the Master Session
	Key.
	Each EAP-SIM exchange generates fresh keying material. The EAP-SIM		11.6 Cryptographic Separation of Keys and Session Independence
	peer contributes to the keying material with the NONCE_MT parameter,
	which must be chosen freshly for each full authentication exchange.
	Hence, even if the RAND challenges were reused from a previous
	session, the session keys will be different. On fast
	re-authentication, freshness is provided with a counter. Please see
	Section 11.2 for more information about RAND reuse.
	11.5 Dictionary Attacks		The EAP Transient Keys used to protect EAP-SIM packets (K_encr,
			K_aut), the Master Session Key, and the Extended Master Session Key
			are cryptographically separate in EAP-SIM. An attacker cannot derive
			any non-trivial information about any of these keys based on the
			other keys. An attacker also cannot calculate the pre-shared secret
			(Ki) from the GSM Kc keys, from EAP-SIM K_encr, from EAP-SIM K_aut,
			from the Master Session Key, or from the Extended Master Session Key.
			Each EAP-SIM exchange generates fresh keying material, and the keying
			material exported from the method upon separate EAP-SIM exchanges is
			cryptographically separate. The EAP-SIM peer contributes to the
			keying material with the NONCE_MT parameter, which must be chosen
			freshly for each full authentication exchange. The EAP server is
			mandated to choose the RAND challenges freshly for each full
			authentication exchange. If either the server or the peer chooses
			its random value (NONCE_MT or RAND challenges) freshly, even if the
			other entity reused its value from a previous exchange, then the EAP
			Transient Keys, the Master Session Key, and the Extended Master
			Session Key will be different and cryptographically separate from the
			corresponding values derived upon the previous full authentication
			exchange.
			On fast re-authentication, freshness of the Master Session Key and
			the Extended Master Session Key is provided with a counter
			(AT_COUNTER). The same EAP Transient Keys (K_encr, K_aut) as in the
			full authentication exchange are used to protect the EAP negotiation.
			However, replay and integrity protection across all the fast
			re-authentication exchanges that use the same EAP Transient Keys is
			provided with AT_COUNTER.
			[RFC3748] defines session independence as the "demonstration that
			passive attacks (such as capture of the EAP conversation) or active
			attacks (including compromise of the MSK or EMSK) do not enable
			compromise of subsequent or prior MSKs or EMSKs". As the MSKs and
			EMSKs are separate between EAP exchanges, EAP-SIM supports this
			security claim.
			It should be noted that [Patel 2003], which predates [RFC3748], uses
			a slightly different meaning for session independence. The EAP-SIM
			protocol does not allow the peer to ensure that different Kc key
			values would be used in different exchanges, but only the server is
			able to ensure that fresh RANDs and thereby fresh Kc keys are used.
			Hence, the peer cannot guarantee EAP-SIM sessions to be independent
			with regard to the internal Kc values. However, in EAP-SIM the Kc
			keys are considered to be secret intermediate results, which are not
			exported outside the method. Please see Section 11.3 for more
			information about RAND reuse.
			11.7 Dictionary Attacks
	Because EAP-SIM is not a password protocol, it is not vulnerable to		Because EAP-SIM is not a password protocol, it is not vulnerable to
	dictionary attacks. (The pre-shared symmetric secret stored on the		dictionary attacks. (The pre-shared symmetric secret stored on the
	SIM card shall not be a weak password.)		SIM card shall not be a weak password.)
	11.6 Credentials Reuse		11.8 Credentials Reuse
	EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks.		EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks.
	If the same SIM credentials are also used in GSM or GPRS, it is		If the same SIM credentials are also used in GSM or GPRS, it is
	possible to mount attacks over the cellular interface.		possible to mount attacks over the cellular interface.
	A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND,		A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND,
	SRES pairs. He can then use a brute force attack or other		SRES pairs. He can then use a brute force attack or other
	cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt		cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt
	the GSM or GPRS data. This makes it possible to attack each 64-bit		the GSM or GPRS data. This makes it possible to attack each 64-bit
	key separately.		key separately.
	skipping to change at page 71, line 4		skipping to change at page 72, line 11
	successful, the attacker can impersonate a valid network or decrypt		successful, the attacker can impersonate a valid network or decrypt
	previously seen traffic, because EAP-SIM does not provide perfect		previously seen traffic, because EAP-SIM does not provide perfect
	forward secrecy (PFS).		forward secrecy (PFS).
	Because this attack requires the attacker to build a rogue GSM base		Because this attack requires the attacker to build a rogue GSM base
	station (or at least eavesdrop the GSM traffic), the cost of the		station (or at least eavesdrop the GSM traffic), the cost of the
	attack is not negligible; it is the same cost as usually in GSM.		attack is not negligible; it is the same cost as usually in GSM.
	However, due to several weaknesses in the GSM encryption algorithms,		However, due to several weaknesses in the GSM encryption algorithms,
	the effective key strength of the Kc keys is much less than the		the effective key strength of the Kc keys is much less than the
	expected 64 bits (no more than 40 bits if the A5/1 GSM encryption		expected 64 bits (no more than 40 bits if the A5/1 GSM encryption
	algorithm is used; an active attacker can force the peer to use the		algorithm is used; as documented in [Barkan et al. 2003], an active
	weaker A5/2 algorithm that can be broken in less than a second).		attacker can force the peer to use the weaker A5/2 algorithm that can
			be broken in less than a second).
	Because the A5 encryption algorithm is not used in EAP-SIM, and		Because the A5 encryption algorithm is not used in EAP-SIM, and
	because EAP-SIM does not expose any values calculated from individual		because EAP-SIM does not expose any values calculated from individual
	Kc keys, it should be noted that these attacks are not possible if		Kc keys, it should be noted that these attacks are not possible if
	the SIM credentials used in EAP-SIM are not shared in GSM/GPRS.		the SIM credentials used in EAP-SIM are not shared in GSM/GPRS.
	11.7 Integrity and Replay Protection, and Confidentiality		11.9 Integrity and Replay Protection, and Confidentiality
	AT_MAC, AT_IV, AT_ENCR_DATA and AT_COUNTER attributes are used to		AT_MAC, AT_IV, AT_ENCR_DATA and AT_COUNTER attributes are used to
	provide integrity, replay and confidentiality protection for EAP-SIM		provide integrity, replay and confidentiality protection for EAP-SIM
	requests and responses. Integrity protection with AT_MAC includes		requests and responses. Integrity protection with AT_MAC includes
	the EAP header. These attributes cannot be used during the		the EAP header. These attributes cannot be used during the
	EAP/SIM/Start roundtrip. However, the protocol values (user identity		EAP/SIM/Start roundtrip. However, the protocol values (user identity
	string, NONCE_MT and version negotiation parameters) are (implicitly)		string, NONCE_MT and version negotiation parameters) are (implicitly)
	protected by later EAP-SIM messages by including them in key		protected by later EAP-SIM messages by including them in key
	derivation.		derivation.
	Integrity protection (AT_MAC) is based on a keyed message		Integrity protection (AT_MAC) is based on a keyed message
	authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is		authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is
	based on a block cipher.		based on a block cipher.
	Confidentiality protection is applied only to a part of the protocol		Confidentiality protection is applied only to a part of the protocol
	fields. The table of attributes in Section 9.1 summarizes which		fields. The table of attributes in Section 9.1 summarizes which
	fields are confidentiality protected. It should be noted that the		fields are confidentiality protected. It should be noted that the
	error and notification code attributes AT_CLIENT_ERROR_CODE and		error and notification code attributes AT_CLIENT_ERROR_CODE and
	AT_NOTIFICATION are not confidential but they are transmitted in the		AT_NOTIFICATION are not confidential but they are transmitted in the
	clear. Identity protection is discussed in Section 11.1.		clear. Identity protection is discussed in Section 11.2.
	On full authentication, replay protection of the EAP exchange is		On full authentication, replay protection of the EAP exchange is
	provided by the RAND values from the underlying GSM authentication		provided by the RAND values from the underlying GSM authentication
	scheme and the use of the NONCE_MT value. Protection against replays		scheme and the use of the NONCE_MT value. Protection against replays
	of EAP-SIM messages is also based on the fact that messages that can		of EAP-SIM messages is also based on the fact that messages that can
	include AT_MAC can only be sent once with a certain EAP-SIM Subtype,		include AT_MAC can only be sent once with a certain EAP-SIM Subtype,
	and on the fact that a different K_aut key will be used for		and on the fact that a different K_aut key will be used for
	calculating AT_MAC in each full authentication exchange.		calculating AT_MAC in each full authentication exchange.
	On fast re-authentication, a counter included in AT_COUNTER and a		On fast re-authentication, a counter included in AT_COUNTER and a
	skipping to change at page 72, line 13		skipping to change at page 73, line 21
	physically insecure networks, this may enable an attacker to send		physically insecure networks, this may enable an attacker to send
	false notifications to the peer and to mount denial of service		false notifications to the peer and to mount denial of service
	attacks by spoofing these packets. As discussed in Section 6.3, the		attacks by spoofing these packets. As discussed in Section 6.3, the
	peer will only accept EAP-Success after the peer successfully		peer will only accept EAP-Success after the peer successfully
	authenticates the server. Hence, the attacker cannot force the peer		authenticates the server. Hence, the attacker cannot force the peer
	to believe successful mutual authentication has occurred before the		to believe successful mutual authentication has occurred before the
	peer successfully authenticates the server or after the peer failed		peer successfully authenticates the server or after the peer failed
	to authenticate the server.		to authenticate the server.
	The security considerations of EAP-SIM result indications are covered		The security considerations of EAP-SIM result indications are covered
	in Section 11.9		in Section 11.11
	An eavesdropper will see the EAP-Request/Notification,		An eavesdropper will see the EAP-Request/Notification,
	EAP-Response/Notification, EAP-Success and EAP-Failure packets sent		EAP-Response/Notification, EAP-Success and EAP-Failure packets sent
	in the clear. With EAP-SIM, confidential information MUST NOT be		in the clear. With EAP-SIM, confidential information MUST NOT be
	transmitted in EAP Notification packets.		transmitted in EAP Notification packets.
	11.8 Negotiation Attacks		11.10 Negotiation Attacks
	EAP-SIM does not protect the EAP-Response/Nak packet. Because		EAP-SIM does not protect the EAP-Response/Nak packet. Because
	EAP-SIM does not protect the EAP method negotiation, EAP method		EAP-SIM does not protect the EAP method negotiation, EAP method
	downgrading attacks may be possible, especially if the user uses the		downgrading attacks may be possible, especially if the user uses the
	same identity with EAP-SIM and other EAP methods.		same identity with EAP-SIM and other EAP methods.
	EAP-SIM includes a version negotiation procedure. In EAP-SIM the		EAP-SIM includes a version negotiation procedure. In EAP-SIM the
	keying material derivation includes the version list and selected		keying material derivation includes the version list and selected
	version to ensure that the protocol cannot be downgraded and that the		version to ensure that the protocol cannot be downgraded and that the
	peer and server use the same version of EAP-SIM.		peer and server use the same version of EAP-SIM.
	EAP-SIM does not support ciphersuite negotiation.		EAP-SIM does not support ciphersuite negotiation.
	11.9 Protected Result Indications		11.11 Protected Result Indications
	EAP-SIM supports optional protected success indications, and		EAP-SIM supports optional protected success indications, and
	acknowledged failure indications. If a failure occurs after		acknowledged failure indications. If a failure occurs after
	successful authentication, then the EAP-SIM failure indication is		successful authentication, then the EAP-SIM failure indication is
	integrity and replay protected.		integrity and replay protected.
	Even if an EAP-Failure packet is lost when using EAP-SIM over an		Even if an EAP-Failure packet is lost when using EAP-SIM over an
	unreliable medium, then the EAP-SIM failure indications will help		unreliable medium, then the EAP-SIM failure indications will help
	ensure that the peer and EAP server will know the other parties		ensure that the peer and EAP server will know the other parties
	authentication decision. If protected success indications are used,		authentication decision. If protected success indications are used,
	then the loss of Success packet will also be addressed by the		then the loss of Success packet will also be addressed by the
	acknowledged, integrity and replay protected EAP-SIM success		acknowledged, integrity and replay protected EAP-SIM success
	indication. If the optional success indications are not used, then		indication. If the optional success indications are not used, then
	the peer may end up believing the server succeeded authentication		the peer may end up believing the server succeeded authentication
	when it actually failed. Since access will not be granted in this		when it actually failed. Since access will not be granted in this
	case protected result indications are not needed unless the client is		case protected result indications are not needed unless the client is
	not able to realize it does not have access for an extended period of		not able to realize it does not have access for an extended period of
	time.		time.
	11.10 Man-in-the-middle Attacks		11.12 Man-in-the-middle Attacks
	In order to avoid man-in-the-middle attacks and session hijacking,		In order to avoid man-in-the-middle attacks and session hijacking,
	user data SHOULD be integrity protected on physically insecure		user data SHOULD be integrity protected on physically insecure
	networks. The EAP-SIM Master Session Key or keys derived from it MAY		networks. The EAP-SIM Master Session Key or keys derived from it MAY
	be used as the integrity protection keys, or, if an external security		be used as the integrity protection keys, or, if an external security
	mechanism such as PEAP is used, then the link integrity protection		mechanism such as PEAP is used, then the link integrity protection
	keys MAY be derived by the external security mechanism.		keys MAY be derived by the external security mechanism.
	There are man-in-the-middle attacks associated with the use of any		There are man-in-the-middle attacks associated with the use of any
	EAP method within a tunneled protocol such as PEAP, or within a		EAP method within a tunneled protocol such as PEAP, or within a
	skipping to change at page 73, line 28		skipping to change at page 74, line 36
	does not address these attacks. If EAP-SIM is used with a tunneling		does not address these attacks. If EAP-SIM is used with a tunneling
	protocol or as part of a sequence of methods, there should be		protocol or as part of a sequence of methods, there should be
	cryptographic binding provided between the protocols and EAP-SIM to		cryptographic binding provided between the protocols and EAP-SIM to
	prevent man-in-the-middle attacks through rogue authenticators being		prevent man-in-the-middle attacks through rogue authenticators being
	able to setup one-way authenticated tunnels. The EAP-SIM Master		able to setup one-way authenticated tunnels. The EAP-SIM Master
	Session Key MAY be used to provide the cryptographic binding.		Session Key MAY be used to provide the cryptographic binding.
	However the mechanism how the binding is provided depends on the		However the mechanism how the binding is provided depends on the
	tunneling or sequencing protocol and is beyond the scope of this		tunneling or sequencing protocol and is beyond the scope of this
	document.		document.
	11.11 Generating Random Numbers		11.13 Generating Random Numbers
	An EAP-SIM implementation SHOULD use a good source of randomness to		An EAP-SIM implementation SHOULD use a good source of randomness to
	generate the random numbers required in the protocol. Please see		generate the random numbers required in the protocol. Please see
	[RFC1750] for more information on generating random numbers for		[RFC1750] for more information on generating random numbers for
	security applications.		security applications.
	12. Security Claims		12. Security Claims
	This section provides the security claims required by [RFC3748].		This section provides the security claims required by [RFC3748].
	Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is		Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is
	a challenge/response authentication and key agreement mechanism based		a challenge/response authentication and key agreement mechanism based
	on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of		on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of
	a peer challenge to provide mutual authentication.		a peer challenge to provide mutual authentication.
	Ciphersuite negotiation: No		Ciphersuite negotiation: No
	Mutual authentication: Yes (Section 11.2)		Mutual authentication: Yes (Section 11.3)
	Integrity protection: Yes (Section 11.7)		Integrity protection: Yes (Section 11.9)
			Replay protection: Yes (Section 11.9)
	Replay protection: Yes (Section 11.7)
	Confidentiality: Yes, except method specific success and failure		Confidentiality: Yes, except method specific success and failure
	indications (Section 11.1, Section 11.7)		indications (Section 11.2, Section 11.9)
	Key derivation: Yes		Key derivation: Yes
	Key strength: EAP-SIM supports key derivation with 128-bit effective		Key strength: EAP-SIM supports key derivation with 128-bit effective
	key strength. However, as discussed in Section 11, if the same		key strength (Section 11.5). However, as discussed in Section 11, if
	credentials are used in GSM/GPRS and in EAP-SIM, then the key		the same credentials are used in GSM/GPRS and in EAP-SIM, then the
	strength may be reduced considerably, basically to the same level as		key strength may be reduced considerably, basically to the same level
	in GSM, by mounting attacks over GSM/GPRS. For example an active		as in GSM, by mounting attacks over GSM/GPRS. For example an active
	attack using a false GSM/GPRS base station reduces the effective key		attack using a false GSM/GPRS base station reduces the effective key
	strength to almost zero.		strength to almost zero.
	Description of key hierarchy: Please see Section 6.4.		Description of key hierarchy: Please see Section 6.4.
	Dictinary attack protection: N/A (Section 11.5)		Dictinary attack protection: N/A (Section 11.7)
	Fast reconnect: Yes		Fast reconnect: Yes
	Cryptographic binding: N/A		Cryptographic binding: N/A
	Session independence: Yes (Section 11.4, Section 11.2)		Session independence: Yes (Section 11.6)
	Fragmentation: No		Fragmentation: No
	Channel binding: No		Channel binding: No
	Indication of vulnerabilities: Vulnerabilities are discussed in		Indication of vulnerabilities: Vulnerabilities are discussed in
	Section 11.		Section 11.
	13. Acknowledgements and Contributions		13. Acknowledgements and Contributions
	skipping to change at page 74, line 46		skipping to change at page 76, line 8
	In addition to the editors, Nora Dabbous, Jose Puthenkulam, and		In addition to the editors, Nora Dabbous, Jose Puthenkulam, and
	Prasanna Satarasinghe were significant contributors to this document.		Prasanna Satarasinghe were significant contributors to this document.
	Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.		Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.
	13.2 Acknowledgements		13.2 Acknowledgements
	Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka-		Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka-
	Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri		Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri
	Rinnemaa, Timo Takam„ki and Raimo Vuonnala contributed many original		Rinnemaa, Timo Takamäki and Raimo Vuonnala contributed many original
	ideas and concepts to this protocol.		ideas and concepts to this protocol.
	N. Asokan, Pasi Eronen and Jukka-Pekka Honkanen contributed and		N. Asokan, Pasi Eronen and Jukka-Pekka Honkanen contributed and
	helped in innumerable ways during the development of the protocol.		helped in innumerable ways during the development of the protocol.
	Valtteri Niemi and Kaisa Nyberg contributed substantially to the		Valtteri Niemi and Kaisa Nyberg contributed substantially to the
	design of the key derivation and the fast re-authentication		design of the key derivation and the fast re-authentication
	procedure, and have also provided their cryptographic expertise in		procedure, and have also provided their cryptographic expertise in
	many discussions related to this protocol.		many discussions related to this protocol.
	Simon Blake-Wilson provided most helpful comments on key derivation		Simon Blake-Wilson provided most helpful comments on key derivation
	and version negotiation.		and version negotiation.
	Thanks to Greg Rose for his most valuable comments to an early		Thanks to Greg Rose for his most valuable comments to an early
	version of this specification [S3-020125], and for reviewing and		version of this specification [S3-020125], and for reviewing and
	providing very useful comments on draft version 12.		providing very useful comments on draft version 12.
	Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani,		Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani,
	Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de		Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de
	Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar		Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar
	Patel, Tom Porcher, Michael Richardson, Stefan Schr÷der, Uma Shankar,		Patel, Tom Porcher, Michael Richardson, Stefan Schröder, Uma Shankar,
	Jesse Walker and Thomas Wieland for their contributions and		Jesse Walker and Thomas Wieland for their contributions and
	critiques. Special thanks to Max for proposing improvements to the		critiques. Special thanks to Max for proposing improvements to the
	MAC calculation.		MAC calculation.
	Thanks to Glen Zorn for reviewing this document and for providing		Thanks to Glen Zorn for reviewing this document and for providing
	most useful comments on the protocol.		most useful comments on the protocol.
			Thanks to Sarvar Patel for his review of the protocol [Patel 2003].
	The identity privacy support is based on the identity privacy support		The identity privacy support is based on the identity privacy support
	of [EAP-SRP]. The attribute format is based on the extension format		of [EAP-SRP]. The attribute format is based on the extension format
	of Mobile IPv4 [RFC3344].		of Mobile IPv4 [RFC3344].
	This protocol has been partly developed in parallel with EAP-AKA		This protocol has been partly developed in parallel with EAP-AKA
	[EAP-AKA], and hence this specification incorporates many ideas from		[EAP-AKA], and hence this specification incorporates many ideas from
	Jari Arkko.		Jari Arkko.
	13.2.1 Contributors' Addresses		13.2.1 Contributors' Addresses
	skipping to change at page 77, line 44		skipping to change at page 79, line 8
	[Draft 3GPP TS 23.003]		[Draft 3GPP TS 23.003]
	3rd Generation Partnership Project, "Draft 3GPP Technical		3rd Generation Partnership Project, "Draft 3GPP Technical
	Specification 3GPP TS 23.003 V 6.1.0: "3rd Generation		Specification 3GPP TS 23.003 V 6.1.0: "3rd Generation
	Partnership Project; Technical Specification Group Core		Partnership Project; Technical Specification Group Core
	Network; Numbering, addressing and identification (Release		Network; Numbering, addressing and identification (Release
	6)"", December 2003.		6)"", December 2003.
	work in progress		work in progress
			[3GPP TS 55.205]
			3rd Generation Partnership Project, "3GPP Technical
			Specification 3GPP TS 55.205 V 6.0.0: "3rd Generation
			Partnership Project; Technical Specification Group
			Services and System Aspects; Specification of the
			GSM-MILENAGE Algorithms: An example algorithm set for the
			GSM Authentication and Key Generation functions A3 and A8
			(Release 6)"", December 2002.
	[PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H.		[PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H.
	and S. Josefsson, "Protected EAP Protocol (PEAP)",		and S. Josefsson, "Protected EAP Protocol (PEAP)",
	draft-josefsson-pppext-eap-tls-eap-07 (work in progress),		draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
	October 2003.		October 2003.
	[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness		[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
	Recommendations for Security", RFC 1750, December 1994.		Recommendations for Security", RFC 1750, December 1994.
	[S3-020125]		[S3-020125]
	Qualcomm, "Comments on draft EAP/SIM, 3rd Generation		Qualcomm, "Comments on draft EAP/SIM, 3rd Generation
	skipping to change at page 78, line 23		skipping to change at page 79, line 44
	draft-arkko-pppext-eap-aka-12 (work in progress), Arpil		draft-arkko-pppext-eap-aka-12 (work in progress), Arpil
	2004.		2004.
	[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",		[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
	RFC 2548, March 1999.		RFC 2548, March 1999.
	[EAP-SRP] Carlson, J., Aboba, B. and H. Haverinen, "EAP SRP-SHA1		[EAP-SRP] Carlson, J., Aboba, B. and H. Haverinen, "EAP SRP-SHA1
	Authentication Protocol", Internet-Draft		Authentication Protocol", Internet-Draft
	draft-ietf-pppext-eap-srp-03, July 2001.		draft-ietf-pppext-eap-srp-03, July 2001.
			[GSM Cloning]
			Wagner, D., "GSM Cloning".
			Web page about COMP-128 version 1 vulnerabilities,
			available at
			http://www.isaac.cs.berkeley.edu/isaac/gsm.html
			[Barkan et al. 2003]
			Barkan, E., Biham, E. and N. Keller, "Instant
			Ciphertext-Only Cryptanalysis of GSM Encrypted
			Communications".
			available on-line at http://cryptome.org/gsm-crack-bbk.pdf
			[Patel 2003]
			Patel, S., "Analysis of EAP-SIM Session Key Agreement".
			Posted to the EAP mailing list 29 May,2003.
			http://mail.frascone.com/pipermail/public/eap/2003-May/001
			267.html
	Authors' Addresses		Authors' Addresses
	Henry Haverinen (editor)		Henry Haverinen (editor)
	Nokia Enterprise Solutions		Nokia Enterprise Solutions
	P.O. Box 12		P.O. Box 12
	FIN-40101 Jyvaskyla		FIN-40101 Jyvaskyla
	Finland		Finland
	EMail: henry.haverinen@nokia.com		EMail: henry.haverinen@nokia.com
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/