< draft-morand-http-digest-2g-aka-02.txt		draft-morand-http-digest-2g-aka-03.txt >
	Network Working Group L. Morand		Network Working Group L. Morand
	Internet-Draft France Telecom - Orange		Internet-Draft France Telecom - Orange
	Intended status: Informational February 13, 2012		Intended status: Informational January 21, 2013
	Expires: August 16, 2012		Expires: July 25, 2013
	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-02		draft-morand-http-digest-2g-aka-03
	Abstract		Abstract
	This memo specifies a one-time password generation mechanism for		This memo 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
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 August 16, 2012.		This Internet-Draft will expire on July 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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 Motivation . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4		4. GSM 2G AKA Mechanism Overview . . . . . . . . . . . . . . . . 4
	5. Specification of Digest 2G AKA . . . . . . . . . . . . . . . . 6		5. Specification of Digest 2G AKA . . . . . . . . . . . . . . . . 6
	5.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 6		5.1. Algorithm Directive . . . . . . . . . . . . . . . . . . . 7
	5.2. Creating a Challenge . . . . . . . . . . . . . . . . . . . 7		5.2. Creating a Challenge . . . . . . . . . . . . . . . . . . . 7
	5.3. Client Authentication . . . . . . . . . . . . . . . . . . 7		5.3. Client Authentication . . . . . . . . . . . . . . . . . . 7
	5.4. Server Authentication . . . . . . . . . . . . . . . . . . 8		5.4. Server Authentication . . . . . . . . . . . . . . . . . . 8
	6. Example of Digest 2G AKA operations . . . . . . . . . . . . . 8		6. Example of Digest 2G AKA operations . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8.1. Authentication of Clients using Digest 2G AKA . . . . . . 11		8.1. Authentication of Clients using Digest 2G AKA . . . . . . 11
	8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 11		8.2. Limited Use of Nonce Values . . . . . . . . . . . . . . . 11
	8.3. Multiple Authentication Schemes and Algorithms . . . . . . 12		8.3. Multiple Authentication Schemes and Algorithms . . . . . . 12
	8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 12		8.4. Online Dictionary Attacks . . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	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
	key distribution in Global System for Mobile Communication (GSM) and		key distribution in Global System for Mobile Communication (GSM) and
	Universal Mobile Telecommunications System (UMTS) networks. 2G AKA is		Universal Mobile Telecommunications System (UMTS) networks. 2G AKA is
	a challenge-response based mechanism that uses symmetric		a challenge-response based mechanism that uses symmetric
	cryptography. GSM AKA is typically run in a GSM Subscriber Identity		cryptography. 2G AKA is typically run in a GSM Subscriber Identity
	Module (SIM), which resides in a smart card like device that also		Module (SIM), which resides in a smart card like device that also
	provides tamper resistant storage of shared secrets. The 3G		provides tamper resistant storage of shared secrets. The 3G
	Authentication and Key Agreement (AKA) mechanism, also known as UMTS		Authentication and Key Agreement (AKA) mechanism, also known as UMTS
	AKA, relying on the use of the UMTS Subscriber Identity Module (USIM)		AKA, relying on the use of the UMTS Subscriber Identity Module (USIM)
	instead of the GSM SIM, is most closely associated with UMTS;		instead of the GSM SIM, is most closely associated with UMTS;
	however, mobile operators commonly distribute GSM SIMs with UMTS		however, mobile operators commonly distribute GSM SIMs with UMTS
	mobile phones, resulting in the use of GSM 2G AKA in place of UMTS		mobile phones, resulting in the use of 2G (GSM) AKA in place of UMTS
	AKA.		AKA.
	This document specifies a mapping of GSM AKA parameters onto HTTP		This document specifies a mapping of GSM AKA parameters onto HTTP
	Digest authentication. In essence, this mapping enables the usage of		Digest authentication. In essence, this mapping enables the usage of
	GSM 2G AKA as a one-time password generation mechanism for Digest		GSM 2G AKA as a one-time password generation mechanism for Digest
	authentication.		authentication.
	This document is based heavily on [RFC3310] which specified a mapping		This document is based heavily on [RFC3310] which specified a mapping
	of Authentication and Key Agreement (AKA) onto HTTP Digest		of Authentication and Key Agreement (AKA) onto HTTP Digest
	authentication. While Digest AKA can be generally used when the		authentication. While Digest AKA can be generally used when the
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	This section explains the terminology used in this document.		This section explains the terminology used in this document.
	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
	ISIM IMS Subscriber Identity Module.		ISIM IMS Subscriber Identity Module.
	Kc Cypher Key. Ki Subscriber Key.		Kc Cypher 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.
	4. GSM 2G AKA Mechanism Overview		4. GSM 2G AKA Mechanism Overview
	This chapter describes the GSM AKA mechanism based on a shared secret		This following figure (Fig. 1) provides an overview of the GSM 2G AKA
	key (Ki) and the use of A3/A8 algorithms:		mechanism, which is based on a shared secret key (Ki) and the use of
			A3/A8 algorithms.
	1. A shared secret Ki is established beforehand between the SIM and		The GSM 2G AKA mechanism is a challenge-response mechanism that
	the Authentication Center (AuC). The secret is stored in the		allows the authentication of the mobile subscriber/device in the
	SIM, which resides on a smart card like, tamper resistant device.		network. This mechanism involves the Subscriber Identity Module
			(SIM) hosted by the mobile subscriber's device, a server in the
			serving network and the Authentication Centre (AuC) in the mobile
			subscriber's home network. When required, the authentication of the
			mobile subscriber is performed by the serving network using
			authentification material provided by the AuC.
	2. The AuC of the home network produces an authentication vector		A shared secret (Ki) is established beforehand between the SIM and
	(AV), based on the shared secret Ki and a generated random value		the AuC. The secret is stored in the SIM, which resides on a smart
	(RAND). Using Ki and RAND, the A3 algorihm is used for		card like, tamper resistant device. The SIM is identified by the
	calculating the expected response (SRES) and the A8 algorithm is		IMSI (International Mobile Subscriber Identity), which is also used
	used for calculating the ciffering key Kc.		to identify the mobile subscriber/device in the network and the
			shared secret (Ki) in the AuC (Authentication Center).
	3. The authentication vector (RAND, SRES, Kc) is downloaded to a		SIM Server AuC
	server. Optionally, the server can also download a batch of AVs,		(Ki) (Ki)
	containing more than one authentication vector generated by
	adding different RAND values.
	4. The server creates an authentication request, which contains the		| | |
	random challenge RAND.		|---- 1.Request (IMSI) ----->| |
			| | 2.Authen. Data Request (IMSI) |
			| |------------------------------>|
			| | |
			| | +-----------------+----+
			| | | (3) |
			| | | IMSI --> Ki |
			| | | A3(RAND,Ki) = SRES |
			| | | A8(RAND,Ki) = Kc |
			| | +----------------+-----+
			| | |
			| |<--- 4.AV (RAND, SRES, Kc) ---|
			|<-- 5.Auth. Request (RAND) -| |
			| | |
			+-----+---------------+ | |
			| (6) | | |
			| A3(RAND,Ki) = SRES* | | |
			| A8(RAND,Ki) = Kc | | |
			+-----+---------------+ | |
			| | |
			|- 7.Auth. Response (SRES*)->| |
			| | |
			| +-------+------+ |
			| | (8) | |
			| | SRES*= SRES? | |
			| +-------+------+ |
			| | |
	5. The authentication request is delivered to the client.		Figure 1. GSM 2G AKA overview
	6. The client produces a signed authentication response RES, using		1. The mobile subscriber initiates a access/service request towards a
	the shared secret Ki and the random challenge RAND.		server in the serving network. The request contains the IMSI.
			2. When the request needs to be authenticated, the server queries
			the AuC of the mobile subscriber's home network to retrieve the
			necessary material for authenticating the mobile subscriber
			identified by the IMSI.
			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
			shared secret Ki and a generated random value (RAND) for calculating
			the expected response (SRES) using the A3 algorithm and the ciffering
			key Kc using the A8 algorithm. the triple RAND, SRES and Kc form an
			Authentication Vector (AV).
			4. The authentication vector (RAND, SRES, Kc) is downloaded to a
			server. Optionally, if request by the server, the AuC can
			also download more than one authentication vector, each AV generated
			with a different RAND value.
			5. The server creates an authentication request, which contains the
			random challenge RAND and the authentication request is delivered
			to the client.
			6. The client produces a authentication response RES, using
			the shared secret Ki and the random challenge RAND provided in
			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
	SIM Server AuC
	(Ki) (Ki)
	| | |
	|--- Request (IMSI) ------>| |
	| | Authen. Data Request (IMSI) |
	| |---------------------------->|
	| | |
	| | +-----------------+----+
	| | | IMSI --> Ki |
	| | | A3(RAND,Ki) = SRES |
	| | | A8(RAND,Ki) = Kc |
	| | +----------------+-----+
	| | |
	| |<--- AV (RAND, SRES, Kc) ---|
	|<-- Auth. Request (RAND) -| |
	| | |
	+-----+---------------+ | |
	| A3(RAND,Ki) = SRES* | | |
	| A8(RAND,Ki) = Kc | | |
	+-----+---------------+ | |
	| | |
	|- Auth. Response (SRES*)->| |
	| | |
	| +-------+------+ |
	| | SRES*= SRES? | |
	| +-------+------+ |
	| | |
	Figure 1. GSM 2G AKA overview
	5. Specification of Digest 2G AKA		5. Specification of Digest 2G AKA
	In general, the Digest GSM 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		5.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
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 32 ¶
	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		5.2. Creating a Challenge
	In order to deliver the GSM 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
End of changes. 18 change blocks.
	59 lines changed or deleted		87 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/