< draft-morand-http-digest-2g-aka-03.txt		draft-morand-http-digest-2g-aka-04.txt >
	Network Working Group L. Morand		Network Working Group L. Morand
	Internet-Draft France Telecom - Orange		Internet-Draft Orange Labs
	Intended status: Informational January 21, 2013		Intended status: Informational October 03, 2013
	Expires: July 25, 2013		Expires: April 06, 2014
	Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G		Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G
	Authentication and Key Agreement (AKA)		Authentication and Key Agreement (AKA)
	draft-morand-http-digest-2g-aka-03		draft-morand-http-digest-2g-aka-04
	Abstract		Abstract
	This memo specifies a one-time password generation mechanism for		This document specifies a one-time password generation mechanism for
	Hypertext Transfer Protocol (HTTP) Digest access authentication based		Hypertext Transfer Protocol (HTTP) Digest access authentication based
	on Global System for Mobile Communications (GSM) authentication and		on Global System for Mobile Communications (GSM) authentication and
	key generation functions A3 and A8, also known as GSM AKA or 2G AKA.		key generation functions A3 and A8, also known as GSM AKA or 2G AKA.
	The HTTP Authentication Framework includes two authentication		The HTTP Authentication Framework includes two authentication
	schemes: Basic and Digest. Both schemes employ a shared secret based		schemes: Basic and Digest. Both schemes employ a shared secret based
	mechanism for access authentication. The GSM AKA mechanism performs		mechanism for access authentication. The GSM AKA mechanism performs
	user authentication and session key distribution in GSM and Universal		user authentication and session key distribution in GSM and Universal
	Mobile Telecommunications System (UMTS) networks. GSM AKA is a		Mobile Telecommunications System (UMTS) networks. GSM AKA is a
	challenge-response based mechanism that uses symmetric cryptography.		challenge-response based mechanism that uses symmetric cryptography.
	Requirements Language		Status of This Memo
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on July 25, 2013.		This Internet-Draft will expire on April 06, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3		1. Introduction and Motivations . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4		4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4
	5. Specification of Digest 2G AKA . . . . . . . . . . . . . . . . 6		5. Example of Digest 2G AKA operations . . . . . . . . . . . . . 6
	5.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 7		6. Specification of Digest 2G AKA . . . . . . . . . . . . . . . 8
	5.2. Creating a Challenge . . . . . . . . . . . . . . . . . . . 7		6.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 8
	5.3. Client Authentication . . . . . . . . . . . . . . . . . . 7		6.2. Creating a Challenge . . . . . . . . . . . . . . . . . . 9
	5.4. Server Authentication . . . . . . . . . . . . . . . . . . 8		6.3. Client Authentication . . . . . . . . . . . . . . . . . . 9
	6. Example of Digest 2G AKA operations . . . . . . . . . . . . . 8		6.4. Server Authentication . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8.1. Authentication of Clients using Digest 2G AKA . . . . . . 11		8.1. Authentication of Clients using Digest 2G AKA . . . . . . 10
	8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 11		8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 10
	8.3. Multiple Authentication Schemes and Algorithms . . . . . . 12		8.3. Multiple Authentication Schemes and Algorithms . . . . . 11
	8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 12		8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 11
	8.5. Session Protection . . . . . . . . . . . . . . . . . . . . 12		8.5. Session Protection . . . . . . . . . . . . . . . . . . . 11
	8.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 13		8.6. Replay Protection . . . . . . . . . . . . . . . . . . . . 12
	8.7. Mutual Authentication . . . . . . . . . . . . . . . . . . 13		8.7. Mutual Authentication . . . . . . . . . . . . . . . . . . 12
	8.8. Flooding the Authentication Centre . . . . . . . . . . . . 13		8.8. Flooding the Authentication Centre . . . . . . . . . . . 12
	8.9. AKA Security . . . . . . . . . . . . . . . . . . . . . . . 13		8.9. AKA Security . . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		8.10. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 14
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction and Motivation		1. Introduction and Motivations
	The Hypertext Transfer Protocol (HTTP) Authentication Framework,		The Hypertext Transfer Protocol (HTTP) Authentication Framework,
	described in [RFC2617], includes two authentication schemes: Basic		described in [RFC2617], includes two authentication schemes: Basic
	and Digest. Both schemes employ a shared secret based mechanism for		and Digest. Both schemes employ a shared secret based mechanism for
	access authentication. The Basic scheme is inherently insecure in		access authentication. The Basic scheme is inherently insecure in
	that it transmits user credentials in plain text. The Digest scheme		that it transmits user credentials in plain text. The Digest scheme
	improves security by hiding user credentials with cryptographic		improves security by hiding user credentials with cryptographic
	hashes, and additionally by providing limited message integrity.		hashes, and additionally by providing limited message integrity.
	The 2G AKA functions [TS55.205] perform authentication and session		The 2G AKA functions [TS55.205] perform authentication and session
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 38 ¶
	mobile operators who have not yet fully deployed USIMs and have still		mobile operators who have not yet fully deployed USIMs and have still
	millions of SIMs deployed in the network. Digest 2G AKA allows		millions of SIMs deployed in the network. Digest 2G AKA allows
	access to applications in a more secure way than would be possible		access to applications in a more secure way than would be possible
	with the use of passwords or with GSM without enhancements.		with the use of passwords or with GSM without enhancements.
	Moreover, as the Session Initiation Protocol (SIP) [RFC3261]		Moreover, as the Session Initiation Protocol (SIP) [RFC3261]
	Authentication Framework closely follows the HTTP Authentication		Authentication Framework closely follows the HTTP Authentication
	Framework, Digest 2G AKA is directly applicable to SIP as well as to		Framework, Digest 2G AKA is directly applicable to SIP as well as to
	any other embodiment of HTTP Digest.		any other embodiment of HTTP Digest.
	2. Requirements Language		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	3. Terminology
	This section explains the terminology used in this document.		3. Acronyms
	AuC Authentication Center.		AuC Authentication Center.
	AKA Authentication and Key Agreement.		AKA Authentication and Key Agreement.
	GSM Global System for Mobile Communication.		GSM Global System for Mobile Communication.
	IMS IP Multimedia Subsystem.		IMS IP Multimedia Subsystem.
	IMSI International Mobile Subscriber Identity		IMSI International Mobile Subscriber Identity
	ISIM IMS Subscriber Identity Module.		ISIM IMS Subscriber Identity Module.
	Kc Cypher Key. Ki Subscriber Key.		Kc Cipher Key.
			Ki Subscriber Key.
	RAND Random Challenge.		RAND Random Challenge.
	SIM Subscriber Identity Module.		SIM Subscriber Identity Module.
	SRES Signed Authentication Response.		SRES Signed Authentication Response.
	UMTS Universal Mobile Telecommunications System.		UMTS Universal Mobile Telecommunications System.
	USIM UMTS Subscriber Identity Module.		USIM UMTS Subscriber Identity Module.
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 32 ¶
	mechanism, which is based on a shared secret key (Ki) and the use of		mechanism, which is based on a shared secret key (Ki) and the use of
	A3/A8 algorithms.		A3/A8 algorithms.
	The GSM 2G AKA mechanism is a challenge-response mechanism that		The GSM 2G AKA mechanism is a challenge-response mechanism that
	allows the authentication of the mobile subscriber/device in the		allows the authentication of the mobile subscriber/device in the
	network. This mechanism involves the Subscriber Identity Module		network. This mechanism involves the Subscriber Identity Module
	(SIM) hosted by the mobile subscriber's device, a server in the		(SIM) hosted by the mobile subscriber's device, a server in the
	serving network and the Authentication Centre (AuC) in the mobile		serving network and the Authentication Centre (AuC) in the mobile
	subscriber's home network. When required, the authentication of the		subscriber's home network. When required, the authentication of the
	mobile subscriber is performed by the serving network using		mobile subscriber is performed by the serving network using
	authentification material provided by the AuC.		authentication material provided by the AuC.
	A shared secret (Ki) is established beforehand between the SIM and		A shared secret (Ki) is established beforehand between the SIM and
	the AuC. The secret is stored in the SIM, which resides on a smart		the AuC. The secret is stored in the SIM, which resides on a smart
	card like, tamper resistant device. The SIM is identified by the		card like, tamper resistant device. The SIM is identified by the
	IMSI (International Mobile Subscriber Identity), which is also used		IMSI (International Mobile Subscriber Identity), which is also used
	to identify the mobile subscriber/device in the network and the		to identify the mobile subscriber/device in the network and the
	shared secret (Ki) in the AuC (Authentication Center).		shared secret (Ki) in the AuC (Authentication Center).
	SIM Server AuC		SIM Server AuC
	(Ki) (Ki)		(Ki) (Ki)
	| | |		| | |
	|---- 1.Request (IMSI) ----->| |		|---- 1.Request (IMSI) ----->| |
	| | 2.Authen. Data Request (IMSI) |		| | 2.Authen. Data Request (IMSI) |
	| |------------------------------>|		| |------------------------------>|
	| | |		| | |
	| | +-----------------+----+		| | +-----------------+----+
	| | | (3) |		| | | (3) |
	| | | IMSI --> Ki |		| | | IMSI --> Ki |
	| | | A3(RAND,Ki) = SRES |		| | | A3(RAND,Ki) = SRES |
	| | | A8(RAND,Ki) = Kc |		| | | A8(RAND,Ki) = Kc |
	| | +----------------+-----+		| | +----------------+-----+
	| | |		| | |
	| |<--- 4.AV (RAND, SRES, Kc) ---|		| |<--- 4.AV (RAND, SRES, Kc) ---|
	|<-- 5.Auth. Request (RAND) -| |		|<-- 5.Auth. Request (RAND) -| |
	| | |		| | |
	+-----+---------------+ | |		+-----+---------------+ | |
	| (6) | | |		| (6) | | |
	| A3(RAND,Ki) = SRES* | | |		| A3(RAND,Ki) = SRES* | | |
	| A8(RAND,Ki) = Kc | | |		| A8(RAND,Ki) = Kc | | |
	+-----+---------------+ | |		+-----+---------------+ | |
	| | |		| | |
	|- 7.Auth. Response (SRES*)->| |		|- 7.Auth. Response (SRES*)->| |
	| | |		| | |
	| +-------+------+ |		| +-------+------+ |
	| | (8) | |		| | (8) | |
	| | SRES*= SRES? | |		| | SRES*= SRES? | |
	| +-------+------+ |		| +-------+------+ |
	| | |		| | |
	Figure 1. GSM 2G AKA overview		Figure 1. GSM 2G AKA overview
	1. The mobile subscriber initiates a access/service request towards a		1. The mobile subscriber initiates a access/service request towards a
	server in the serving network. The request contains the IMSI.		server in the serving network. The request contains the IMSI.
	2. When the request needs to be authenticated, the server queries		2. When the request needs to be authenticated, the server queries
	the AuC of the mobile subscriber's home network to retrieve the		the AuC of the mobile subscriber's home network to retrieve the
	necessary material for authenticating the mobile subscriber		necessary material for authenticating the mobile subscriber
	identified by the IMSI.		identified by the IMSI.
	3. The IMSI received from the server is used as key entry by the AuC		3. The IMSI received from the server is used as key entry by the AuC
	to select the corresponding shared secret Ki. The AuC uses the		to select the corresponding shared secret Ki. The AuC uses the
	shared secret Ki and a generated random value (RAND) for calculating		shared secret Ki and a generated random value (RAND) for calculating
	the expected response (SRES) using the A3 algorithm and the ciffering		the expected response (SRES) using the A3 algorithm and the cipher
	key Kc using the A8 algorithm. the triple RAND, SRES and Kc form an		key Kc using the A8 algorithm. the triple RAND, SRES and Kc form an
	Authentication Vector (AV).		Authentication Vector (AV).
	4. The authentication vector (RAND, SRES, Kc) is downloaded to a		4. The authentication vector (RAND, SRES, Kc) is downloaded to a
	server. Optionally, if request by the server, the AuC can		server. Optionally, if request by the server, the AuC can
	also download more than one authentication vector, each AV generated		also download more than one authentication vector, each AV generated
	with a different RAND value.		with a different RAND value.
	5. The server creates an authentication request, which contains the		5. The server creates an authentication request, which contains the
	random challenge RAND and the authentication request is delivered		random challenge RAND and the authentication request is delivered
	to the client.		to the client.
	6. The client produces a authentication response RES, using		6. The client produces a authentication response RES, using
	the shared secret Ki and the random challenge RAND provided in		the shared secret Ki and the random challenge RAND provided in
	the authentication request received from the server.		the authentication request received from the server.
	7. The authentication response RES is delivered to the server.		7. The authentication response RES is delivered to the server.
	8. The server compares the authentication response RES with the		8. The server compares the authentication response RES with the
	expected response SRES. If the two match, the user has been		expected response SRES. If the two match, the user has been
	successfully authenticated, and the session key Kc can be used		successfully authenticated, and the session key Kc can be used
	for protecting further communication between the client and the		for protecting further communication between the client and the
	server		server
	5. Specification of Digest 2G AKA		5. Example of Digest 2G AKA operations
			Figure 2 below describes a message flow describing a Digest 2G AKA
			process of authenticating a SIP request, namely the SIP REGISTER
			request.
			SIM HTTP Server AuC
			(Ki) (Ki)
			| 1) GET (IMSI) | |
			|--------------------------->| |
			| | 2) Authen. Data Request (IMSI)|
			| |------------------------------>|
			| | |
			| | +-----------------+--+
			| | | IMSI --> Ki |
			| | | A3(RAND,Ki) = SRES |
			| | | A8(RAND,Ki) = Kc |
			| | +-----------------+--+
			| | |
			| | 3) AV (RAND, SRES, Kc) |
			| |<------------------------------|
			| 4) 401 Unauthorized (RAND) | |
			|<---------------------------| |
			| | |
			+-----+---------------+ | |
			| A3(RAND,Ki) = SRES* | | |
			| A8(RAND,Ki) = Kc | | |
			+-----+---------------+ | |
			| | |
			| 5) GET (IMSI, RAND, SRES) | |
			|--------------------------->| |
			| | |
			| +-------+------+ |
			| | SRES*= SRES? | |
			| +-------+------+ |
			| | |
			| 6) 200 OK | |
			|<---------------------------| |
			| | |
			Figure 2: Message flow representing a successful authentication
			1) Initial request
			GET / HTTP/1.1
			Authorization: Digest
			username="user1_private@home1.net",
			realm="service1.home1.net",
			nonce="",
			uri="/",
			response=""
			2) Request to the AuC for 2G AKA authentication vector (AV) for the
			given IMSI
			3) Response from the AuC providing 2G AKA AV (RAND, SRES, Kc)
			associated with the IMSI
			4) Response containing a challenge
			HTTP/1.1 401 Unauthorized
			WWW-Authenticate: Digest
			realm="service1.home1.net",
			nonce="base64(RAND)",
			qop="auth,auth-int",
			opaque="6dae728da9089dab9112373c9f0a9731",
			algorithm=2GAKA-MD5
			5) Request containing credentials
			GET / HTTP/1.1
			Authorization: Digest
			username="user1_private@home1.net",
			realm="service1.home1.net",
			nonce="base64(RAND)",
			uri="/",
			nc=00000001,
			cnonce="0b8f29d6",
			response="6629fae49393a05397450978507c4ef1",
			opaque="6dae728da9089dab9112373c9f0a9731",
			algorithm=2GAKA-MD5
			6) Successful response
			HTTP/1.1 200 OK
			Authentication-Info:
			qop=auth-int,
			rspauth="6629fae49394a05397450978507c4ef1",
			cnonce="6629fae49393a05397450978507c4ef1",
			nc=00000001,
			opaque="6dae728da9089dab9112373c9f0a9731",
			nonce="base64(RAND)"
			6. Specification of Digest 2G AKA
	In general, the Digest 2G AKA operation is identical to the Digest		In general, the Digest 2G AKA operation is identical to the Digest
	operation in [RFC2617]. This chapter specifies the parts in which		operation in [RFC2617]. This chapter specifies the parts in which
	Digest 2G AKA extends the Digest operation. The notation used in the		Digest 2G AKA extends the Digest operation. The notation used in the
	Augmented BNF definitions for the new and modified syntax elements in		Augmented BNF definitions for the new and modified syntax elements in
	this section is as used in SIP [RFC3261], and any elements not		this section is as used in SIP [RFC3261], and any elements not
	defined in this section are as defined in SIP and the documents to		defined in this section are as defined in SIP and the documents to
	which it refers.		which it refers.
	5.1. Algorithm Directive		6.1. Algorithm Directive
	In order to direct the client into using 2G AKA for authentication		In order to direct the client into using 2G AKA for authentication
	instead of the standard password system, the RFC 2617 defined		instead of the standard password system, the RFC 2617 defined
	algorithm directive is overloaded in Digest 2G AKA:		algorithm directive is overloaded in Digest 2G AKA:
	algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value		algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value
	)		)
	2GAKA-namespace = "2GAKA" "-" algorithm-value		2GAKA-namespace = "2GAKA" "-" algorithm-value
	skipping to change at page 7, line 19 ¶		skipping to change at page 9, line 4 ¶
	algorithm directive is overloaded in Digest 2G AKA:		algorithm directive is overloaded in Digest 2G AKA:
	algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value		algorithm = "algorithm" EQUAL ( 2GAKA-namespace / algorithm-value
	)		)
	2GAKA-namespace = "2GAKA" "-" algorithm-value		2GAKA-namespace = "2GAKA" "-" algorithm-value
	algorithm-value = ( "MD5" / "MD5-sess" / token )		algorithm-value = ( "MD5" / "MD5-sess" / token )
	algorithm		algorithm
	A string indicating the algorithm used in producing the digest and		A string indicating the algorithm used in producing the digest and
	the checksum. If the directive is not understood, the nonce		the checksum. If the directive is not understood, the nonce
	SHOULD be ignored, and another challenge (if one is present)		SHOULD be ignored, and another challenge (if one is present)
	should be used instead. Reuse of the same SRES value in		should be used instead. Reuse of the same SRES value in
	authenticating subsequent requests and responses is NOT		authenticating subsequent requests and responses is NOT
	RECOMMENDED. An SRES value SHOULD only be used as a one-time		RECOMMENDED. An SRES value SHOULD only be used as a one-time
	password, and algorithms such as "MD5-sess", which limit the		password, and algorithms such as "MD5-sess", which limit the
	amount of material hashed with a single key, by producing a		amount of material hashed with a single key, by producing a
	session key for authentication, SHOULD NOT be used.		session key for authentication, SHOULD NOT be used.
	5.2. Creating a Challenge		6.2. Creating a Challenge
	In order to deliver the GSM 2G AKA authentication challenge to the		In order to deliver the GSM 2G AKA authentication challenge to the
	client in Digest 2G AKA, the nonce directive defined in [RFC2617] is		client in Digest 2G AKA, the nonce directive defined in [RFC2617] is
	extended:		extended:
	nonce = "nonce" EQUAL ( 2GAKA-nonce / nonce-value )		nonce = "nonce" EQUAL ( 2GAKA-nonce / nonce-value )
	2GAKA-nonce = LDQUOT 2GAKA-nonce-value RDQUOT		2GAKA-nonce = LDQUOT 2GAKA-nonce-value RDQUOT
	2GAKA-nonce-value = <base64 encoding of RAND>		2GAKA-nonce-value = <base64 encoding of RAND>
	nonce		nonce
	A parameter which is populated with the Base64 [RFC2045] encoding		A parameter which is populated with the Base64 [RFC2045] encoding
	of the 2G AKA authentication random challenge RAND.		of the 2G AKA authentication random challenge RAND.
	5.3. Client Authentication		6.3. Client Authentication
	When a client receives a Digest 2G AKA authentication challenge, it		When a client receives a Digest 2G AKA authentication challenge, it
	extracts the RAND from the "nonce" parameter and runs the A3-A8		extracts the RAND from the "nonce" parameter and runs the A3-A8
	algorithms with the RAND challenge and shared secret Ki.		algorithms with the RAND challenge and shared secret Ki.
	The resulting A3-A8 SRES parameter is treated as a "password" when		The resulting A3-A8 SRES parameter is treated as a "password" when
	calculating the response directive of [RFC2617]. Due to the fact		calculating the response directive of [RFC2617]. Due to the fact
	that the SRES parameter is 32 bits and the response directive of		that the SRES parameter is 32 bits and the response directive of
	[RFC2617] is defined as 32 hex digits, SRES is encoded in the low		[RFC2617] is defined as 32 hex digits, SRES is encoded in the low
	order (i.e. rightmost) 32 bits of "response", padded with leading		order (i.e. rightmost) 32 bits of "response", padded with leading
	zeroes.		zeroes.
	Example:		Example:
	SRES="0000000000000000000000007018d8a1"		SRES="0000000000000000000000007018d8a1"
	5.4. Server Authentication		6.4. Server Authentication
	With Digest 2G AKA, the server MUST use the expected response SRES		With Digest 2G AKA, the server MUST use the expected response SRES
	received in the authentication vector as "password" when calculating		received in the authentication vector as "password" when calculating
	the "response-auth" of the "Authentication-Info" header defined in		the "response-auth" of the "Authentication-Info" header defined in
	[RFC2617].		[RFC2617].
	6. Example of Digest 2G AKA operations
	Figure 2 below describes a message flow describing a Digest 2G AKA
	process of authenticating a SIP request, namely the SIP REGISTER
	request.
	SIM HTTP Server AuC
	(Ki) (Ki)
	| 1) GET (IMSI) | |
	|--------------------------->| |
	| | 2) Authen. Data Request (IMSI)|
	| |------------------------------>|
	| | |
	| | +-----------------+--+
	| | | IMSI --> Ki |
	| | | A3(RAND,Ki) = SRES |
	| | | A8(RAND,Ki) = Kc |
	| | +-----------------+--+
	| | |
	| | 3) AV (RAND, SRES, Kc) |
	| |<------------------------------|
	| 4) 401 Unauthorized (RAND) | |
	|<---------------------------| |
	| | |
	+-----+---------------+ | |
	| A3(RAND,Ki) = SRES* | | |
	| A8(RAND,Ki) = Kc | | |
	+-----+---------------+ | |
	| | |
	| 5) GET (IMSI, RAND, SRES) | |
	|--------------------------->| |
	| | |
	| +-------+------+ |
	| | SRES*= SRES? | |
	| +-------+------+ |
	| | |
	| 6) 200 OK | |
	|<---------------------------| |
	| | |
	Figure 2: Message flow representing a successful authentication
	1) Initial request
	GET / HTTP/1.1
	Authorization: Digest
	username="user1_private@home1.net",
	realm="service1.home1.net",
	nonce="",
	uri="/",
	response=""
	2) Request to the AuC for 2G AKA authentication vector (AV) for the
	given IMSI
	3) Response from the AuC providing 2G AKA AV (RAND, SRES, Kc)
	associated with the IMSI
	4) Response containing a challenge
	HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Digest
	realm="service1.home1.net",
	nonce="base64(RAND)",
	qop="auth,auth-int",
	opaque="6dae728da9089dab9112373c9f0a9731",
	algorithm=2GAKA-MD5
	5) Request containing credentials
	GET / HTTP/1.1
	Authorization: Digest
	username="user1_private@home1.net",
	realm="service1.home1.net",
	nonce="base64(RAND)",
	uri="/",
	nc=00000001,
	cnonce="0b8f29d6",
	response="6629fae49393a05397450978507c4ef1",
	opaque="6dae728da9089dab9112373c9f0a9731",
	algorithm=2GAKA-MD5
	6) Successful response
	HTTP/1.1 200 OK
	Authentication-Info:
	qop=auth-int,
	rspauth="6629fae49394a05397450978507c4ef1",
	cnonce="6629fae49393a05397450978507c4ef1",
	nc=00000001,
	opaque="6dae728da9089dab9112373c9f0a9731",
	nonce="base64(RAND)"
	7. IANA Considerations		7. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	8. Security Considerations		8. Security Considerations
	In general, Digest 2G AKA is vulnerable to the same security threats		In general, Digest 2G AKA is vulnerable to the same security threats
	skipping to change at page 13, line 23 ¶		skipping to change at page 12, line 28 ¶
	2G AKA. The server is mandated to use fresh triplets (RAND		2G AKA. The server is mandated to use fresh triplets (RAND
	challenges) in consecutive authentication exchanges. Digest 2G AKA		challenges) in consecutive authentication exchanges. Digest 2G AKA
	does not mandate any means for the client to check if the RANDs are		does not mandate any means for the client to check if the RANDs are
	fresh, so the security of the scheme leans on the secrecy of the		fresh, so the security of the scheme leans on the secrecy of the
	triplets. However, the peer MAY employ implementation-specific		triplets. However, the peer MAY employ implementation-specific
	mechanisms to remember some of the previously used RANDs, and the		mechanisms to remember some of the previously used RANDs, and the
	client MAY check the freshness of the server's RANDs.		client MAY check the freshness of the server's RANDs.
	8.7. Mutual Authentication		8.7. Mutual Authentication
	With Digest 2G AKA, network authentication is performed only after UE		With Digest 2G AKA, network authentication is performed only after
	authentication, in contrary to Digest AKA [RFC3310] in which the UE		client authentication, in contrary to Digest AKA [RFC3310] in which
	authenticates the network before responding to the challenge. To		the UE authenticates the network before responding to the challenge.
	prevent an impersonation attack of the server to the UE, the		To prevent an impersonation attack of the server to the client, the
	authentication of the server to the UE SHOULD be improved by		authentication of the server to the UE SHOULD be improved by
	protecting the communication with TLS. An attacker succeeds only if		protecting the communication with Transport Layer Security (TLS). An
	he can break both, the certificate-based TLS authentication to the UE		attacker succeeds only if he can break both, the certificate-based
	and mutual authentication provided by HTTP Digest using a password		TLS authentication to the client and mutual authentication provided
	derived from GSM procedures. One way to break TLS is to compromise		by HTTP Digest using a password derived from GSM procedures. One way
	the certificate.		to break TLS is to compromise the certificate. However, the risk of
			clients using the root certificates associated with a compromised
			Certification Authority (CA) is minimized if the clients use a
			preconfigured list of trusted root certificates restricted to a low
			number of CAs trusted by the operator, as opposed to the list of all
			root certificates in a browser's key store, as described in section
			8.10.
			When TLS is used for server authentication, the recommendations given
			in section 8.10 apply.
	8.8. Flooding the Authentication Centre		8.8. Flooding the Authentication Centre
	The server typically obtains authentication vectors from the		The server typically obtains authentication vectors from the
	Authentication Centre (AuC). Digest 2G AKA introduces a new usage		Authentication Centre (AuC). Digest 2G AKA introduces a new usage
	for the AuC. The protocols between the server and the AuC are out of		for the AuC. The protocols between the 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 client may generate a lot of protocol requests to mount a		malicious client may generate a lot of protocol requests to mount a
	denial of service attack. The server implementation SHOULD take this		denial of service attack. The server implementation SHOULD take this
	into account and SHOULD take steps to limit the traffic that it		into account and SHOULD take steps to limit the traffic that it
	skipping to change at page 14, line 10 ¶		skipping to change at page 13, line 25 ¶
	Evolutions of GSM networks, specifically Universal Mobile		Evolutions of GSM networks, specifically Universal Mobile
	Telecommunications System (UMTS) and IP Multimedia System (IMS)		Telecommunications System (UMTS) and IP Multimedia System (IMS)
	networks, use an enhanced shared secret based mechanism for		networks, use an enhanced shared secret based mechanism for
	authentication known as Authentication and Key Agreement (AKA). In		authentication known as Authentication and Key Agreement (AKA). In
	these networks, AKA is typically run in a UMTS Services Identity		these networks, AKA is typically run in a UMTS Services Identity
	Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM		Module (USIM) or IP Multimedia Services Identity Module (ISIM). GSM
	phones can also be equipped with a USIM or ISIM. In that case,		phones can also be equipped with a USIM or ISIM. In that case,
	Digest AKA as described in [RFC3310] is used for authentication as		Digest AKA as described in [RFC3310] is used for authentication as
	opposed to Digest 2G AKA.		opposed to Digest 2G AKA.
			8.10. TLS Profile
			When TLS is used for server authentication prior to the Digest 2G AKA
			authentication procedures, the following recommendations apply.
			o The TLS endpoints MUST support TLS version 1.1 as specified in RFC
			4346 [RFC4346] and SHOULD support TLS version 1.2 as specified in
			RFC 5246 [RFC5246] should be supported. -
			o The highest TLS version supported on both TLS endpoints MUST be
			used.
			o The TLS endpoints MUST comply with the 3GPP TLS profile given in
			3GPP TS 33.310, Annex E [TS33.310] is . The only difference is
			that TLS cipher suites without encryption MUST not be used.
			o The certificates used for TLS MUST comply with the 3GPP
			certificate profile defined in the section 6.1 of 3GPP TS 33.310
			[TS33.310] is .
			o Support of certificate revocation and of the related fields in
			certificates is recommended.
			o Server name matching MUST be performed by the client using the
			matching rules specified by RFC 2818 [RFC2818] is .
			o The client MUST use a preconfigured list of trusted root
			certificates for server certificate validation.
			o Server certificate validation MUST not require manual user
			interaction.
			o The server MUST not request a certificate in a Server Hello
			Message from the client (as the client is authenticated using
			Digest 2G AKA as described in section 5).
			o The TLS endpoints MUST allow for resuming a session. The lifetime
			of a Session ID is subject to local policies set on the TLS
			endpoints.
	9. Acknowledgements		9. Acknowledgements
	This memo is based on an initial draft written by Brett Wallis		This memo is based on an initial draft written by Brett Wallis
	(draft-ietf-http-digest-auth-a3a8-01).		(draft-ietf-http-digest-auth-a3a8-01).
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 42 ¶
	[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.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
	10.2. Informative References		10.2. Informative References
			[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer		[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
	Protocol (HTTP) Digest Authentication Using Authentication		Protocol (HTTP) Digest Authentication Using Authentication
	and Key Agreement (AKA)", RFC 3310, September 2002.		and Key Agreement (AKA)", RFC 3310, September 2002.
			[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.1", RFC 4346, April 2006.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[TS33.310]
			, "Network Domain Security (NDS); Authentication Framework
			(AF) (Release 12)", June 2013.
	[TS55.205]		[TS55.205]
	"Specification of the GSM- MILENAGE algorithms (Release		, "Specification of the GSM- MILENAGE algorithms (Release
	9)", December 2009.		11)", September 2012.
	Author's Address		Author's Address
	Lionel Morand		Lionel Morand
	France Telecom - Orange		Orange Labs
	38-40 rue du general Leclerc		38/40 rue du General Leclerc
	Issy-Les-Moulineaux Cedex 9 92794		Issy-Les-Moulineaux Cedex 9 92794
	France		France
	Phone: +33 1 4529 6257		Phone: +33145296257
	Email: lionel.morand@orange.com		Email: lionel.morand@orange.com
End of changes. 38 change blocks.
	223 lines changed or deleted		275 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/