< draft-ietf-sip-digest-aka		rfc3310.txt
	Network Working Group A. Niemi		Network Working Group A. Niemi
	Internet-Draft Nokia		Request for Comments: 3310 Nokia
	Expires: November 13, 2002 J. Arkko		Category: Informational J. Arkko
	V. Torvinen		V. Torvinen
	Ericsson		Ericsson
	May 15, 2002		September 2002
	HTTP Digest Authentication Using AKA		Hypertext Transfer Protocol (HTTP) Digest Authentication
	draft-ietf-sip-digest-aka-02		Using Authentication and Key Agreement (AKA)
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This memo provides information for the Internet community. It does
	all provisions of Section 10 of RFC2026.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 13, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) Authentication Framework		This memo specifies an Authentication and Key Agreement (AKA) based
	includes two authentication schemes: Basic and Digest. Both schemes		one-time password generation mechanism for Hypertext Transfer
	employ a shared secret based mechanism for access authentication.		Protocol (HTTP) Digest access authentication. The HTTP
	The Authentication and Key Agreement (AKA) mechanism performs user		Authentication Framework includes two authentication schemes: Basic
			and Digest. Both schemes employ a shared secret based mechanism for
			access authentication. The AKA mechanism performs user
	authentication and session key distribution in Universal Mobile		authentication and session key distribution in Universal Mobile
	Telecommunications System (UMTS) networks. AKA is a challenge-		Telecommunications System (UMTS) networks. AKA is a challenge-
	response based mechanism that uses symmetric cryptography. This memo		response based mechanism that uses symmetric cryptography.
	specifies an AKA based one-time password generation mechanism for
	HTTP Digest access authentication.
	Table of Contents		Table of Contents
	1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3		1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . 4		2. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . 4
	3. Specification of Digest AKA . . . . . . . . . . . . . . . . . 5		3. Specification of Digest AKA . . . . . . . . . . . . . . . . . 5
	3.1 Algorithm Directive . . . . . . . . . . . . . . . . . . . . . 6		3.1 Algorithm Directive . . . . . . . . . . . . . . . . . . . . . 5
	3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . . 6		3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . . 6
	3.3 Client Authentication . . . . . . . . . . . . . . . . . . . . 7		3.3 Client Authentication . . . . . . . . . . . . . . . . . . . . 7
	3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 8		3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 7
	3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8		3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8
	4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 9		4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 12		5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 13
	5.2 Limited Use of Nonce Values . . . . . . . . . . . . . . . . . 13		5.2 Limited Use of Nonce Values . . . . . . . . . . . . . . . . . 13
	5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 13		5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 14
	5.4 Online Dictionary Attacks . . . . . . . . . . . . . . . . . . 14		5.4 Online Dictionary Attacks . . . . . . . . . . . . . . . . . . 14
	5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 14		5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 14
	5.6 Replay Protection . . . . . . . . . . . . . . . . . . . . . . 14		5.6 Replay Protection . . . . . . . . . . . . . . . . . . . . . . 15
	5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15		5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.1 Registration Template . . . . . . . . . . . . . . . . . . . . 16		6.1 Registration Template . . . . . . . . . . . . . . . . . . . . 16
	Normative References . . . . . . . . . . . . . . . . . . . . . 16		Normative References . . . . . . . . . . . . . . . . . . . . . 16
	Informative References . . . . . . . . . . . . . . . . . . . . 16		Informative References . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
	A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18		Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
	1. Introduction and Motivation		1. Introduction and Motivation
	The Hypertext Transfer Protocol (HTTP) Authentication Framework		The Hypertext Transfer Protocol (HTTP) Authentication Framework,
	described in RFC 2617 [2] includes two authentication schemes: Basic		described in RFC 2617 [2], 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 Authentication and Key Agreement (AKA) [6] mechanism performs		The Authentication and Key Agreement (AKA) [6] mechanism performs
	authentication and session key distribution in Universal Mobile		authentication and session key distribution in Universal Mobile
	Telecommunications System (UMTS) networks. AKA is a challenge-		Telecommunications System (UMTS) networks. AKA is a challenge-
	response based mechanism that uses symmetric cryptography. AKA is		response based mechanism that uses symmetric cryptography. AKA is
	typically run in a UMTS IM Services Identity Module (ISIM), which		typically run in a UMTS IM Services Identity Module (ISIM), which
	resides on a smart card like device that also provides tamper proof		resides on a smart card like device that also provides tamper
	storage of shared secrets.		resistant storage of shared secrets.
	This document specifies a mapping of AKA parameters onto HTTP Digest		This document specifies a mapping of AKA parameters onto HTTP Digest
	authentication. In essence, this mapping enables the usage of AKA as		authentication. In essence, this mapping enables the usage of AKA as
	a one-time password generation mechanism for Digest authentication.		a one-time password generation mechanism for Digest authentication.
	As the Session Initiation Protocol (SIP) [3] Authentication Framework		As the Session Initiation Protocol (SIP) [3] Authentication Framework
	closely follows the HTTP Authentication Framework, Digest AKA is		closely follows the HTTP Authentication Framework, Digest AKA is
	directly applicable to SIP as well as any other embodiment of HTTP		directly applicable to SIP as well as any other embodiment of HTTP
	Digest.		Digest.
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 21 ¶
	UMTS		UMTS
	Universal Mobile Telecommunications System.		Universal Mobile Telecommunications System.
	XRES		XRES
	Expected Authentication Response. In a successful authentication		Expected Authentication Response. In a successful authentication
	this is equal to RES.		this is equal to RES.
	1.2 Conventions		1.2 Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in BCP 14, RFC 2119 [1].
	2. AKA Mechanism Overview		2. AKA Mechanism Overview
	This chapter describes the AKA operation in detail:		This chapter describes the AKA operation in detail:
	1. A shared secret K is established beforehand between the ISIM and		1. A shared secret K is established beforehand between the ISIM and
	the Authentication Center (AuC). The secret is stored in the		the Authentication Center (AuC). The secret is stored in the
	ISIM, which resides on a smart card like, tamper proof device.		ISIM, which resides on a smart card like, tamper resistant device.
	2. The AuC of the home network produces an authentication vector AV		2. The AuC of the home network produces an authentication vector AV,
	based on the shared secret K and a sequence number SQN. The		based on the shared secret K and a sequence number SQN. The
	authentication vector contains a random challenge RAND, network		authentication vector contains a random challenge RAND, network
	authentication token AUTN, expected authentication result XRES, a		authentication token AUTN, expected authentication result XRES, a
	session key for integrity check IK, and a session key for		session key for integrity check IK, and a session key for
	encryption CK.		encryption CK.
	3. The authentication vector is downloaded to a server. Optionally,		3. The authentication vector is downloaded to a server. Optionally,
	the server can also download a batch of AVs, containing more than		the server can also download a batch of AVs, containing more than
	one authentication vector.		one authentication vector.
	4. The server creates an authentication request, which contains the		4. The server creates an authentication request, which contains the
	random challenge RAND, and the network authenticator token AUTN.		random challenge RAND, and the network authenticator token AUTN.
	5. The authentication request is delivered to the client.		5. The authentication request is delivered to the client.
	6. Using the shared secret K and the sequence number SQN, the client		6. Using the shared secret K and the sequence number SQN, the client
	verifies the AUTN with the ISIM. If the verification is		verifies the AUTN with the ISIM. If the verification is
	successful, the network has been authenticated. The client then		successful, the network has been authenticated. The client then
	produces an authentication response RES, using the shared secret		produces an authentication response RES, using the shared secret K
	K and the random challenge RAND.		and the random challenge RAND.
	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 XRES. If the two match, the user has been		expected response, XRES. If the two match, the user has been
	successfully authenticated, and the session keys IK and CK can be		successfully authenticated, and the session keys, IK and CK, can
	used for protecting further communications between the client and		be used for protecting further communications between the client
	the server.		and the server.
	When verifying the AUTN, the client may detect, that the sequence		When verifying the AUTN, the client may detect that the sequence
	numbers between the client and the server have fallen out of sync.		numbers between the client and the server have fallen out of sync.
	In this case, the client produces a synchronization parameter AUTS,		In this case, the client produces a synchronization parameter AUTS,
	using the shared secret K and the client sequence number SQN. The		using the shared secret K and the client sequence number SQN. The
	AUTS parameter is delivered to the network in the authentication		AUTS parameter is delivered to the network in the authentication
	response, and the authentication can be tried again based on		response, and the authentication can be tried again based on
	authentication vectors generated with the synchronized sequence		authentication vectors generated with the synchronized sequence
	number.		number.
	For a specification of the AKA mechanism and the generation of the		For a specification of the AKA mechanism and the generation of the
	cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference		cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference
	3GPP TS 33.102 [6].		3GPP TS 33.102 [6].
	3. Specification of Digest AKA		3. Specification of Digest AKA
	In general, Digest AKA operation is identical to Digest operation in		In general, the Digest AKA operation is identical to the Digest
	RFC 2617 [2]. This chapter specifies the parts, in which Digest AKA		operation in RFC 2617 [2]. This chapter specifies the parts in which
	extends the Digest operation. The notation used in the Augmented BNF		Digest AKA extends the Digest operation. The notation used in the
	definitions for the new and modified syntax elements in this section		Augmented BNF definitions for the new and modified syntax elements in
	is as used in SIP [3], and any elements not defined in this section		this section is as used in SIP [3], and any elements not defined in
	are as defined in SIP and the documents to which it refers.		this section are as defined in SIP and the documents to which it
			refers.
	3.1 Algorithm Directive		3.1 Algorithm Directive
	In order to direct the client into using AKA for authentication		In order to direct the client into using 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 AKA:		algorithm directive is overloaded in Digest AKA:
	algorithm = "algorithm" EQUAL aka-namespace		algorithm = "algorithm" EQUAL ( aka-namespace
			/ algorithm-value )
	aka-namespace = aka-version "-" algorithm-value		aka-namespace = aka-version "-" algorithm-value
	aka-version = "AKAv" 1*DIGIT		aka-version = "AKAv" 1*DIGIT
	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. The default aka-version is "AKAv1".		should be used instead. The default aka-version is "AKAv1".
	Further AKA versions can be specified, with version numbers		Further AKA versions can be specified, with version numbers
	assigned by IANA [7]. When the algorithm directive is not		assigned by IANA [7]. When the algorithm directive is not
	present, it is assumed to be "MD5". This indicates, that AKA is		present, it is assumed to be "MD5". This indicates, that AKA is
	not used to produce the Digest password.		not used to produce the Digest password.
	Example:		Example:
	algorithm=AKAv1-MD5		algorithm=AKAv1-MD5
	If the entropy of the used RES value is limited (e.g., only 32 bits),		If the entropy of the used RES value is limited (e.g., only 32
	reuse of the same RES value in authenticating subsequent requests and		bits), reuse of the same RES value in authenticating subsequent
	responses is NOT RECOMMENDED. Such a RES value SHOULD only be used		requests and responses is NOT RECOMMENDED. Such a RES value
	as a one-time password and algorithms such as "MD5-sess", which limit		SHOULD only be used as a one-time password, and algorithms such as
	the amount of material hashed with a single key by producing a		"MD5-sess", which limit the amount of material hashed with a
	session key for authentication, SHOULD NOT be used.		single key, by producing a session key for authentication, SHOULD
			NOT be used.
	3.2 Creating a Challenge		3.2 Creating a Challenge
	In order to deliver the AKA authentication challenge to the client in		In order to deliver the AKA authentication challenge to the client in
	Digest AKA, the nonce directive defined in RFC 2617 is extended:		Digest AKA, the nonce directive defined in RFC 2617 is extended:
	nonce = "nonce" EQUAL aka-nonce		nonce = "nonce" EQUAL ( aka-nonce
			/ nonce-value )
	aka-nonce = LDQUOT aka-nonce-value RDQUOT		aka-nonce = LDQUOT aka-nonce-value RDQUOT
	aka-nonce-value = <base64 encoding of RAND, AUTN, and		aka-nonce-value = <base64 encoding of RAND, AUTN, and
	server specific data>		server specific data>
	nonce		nonce
	A parameter, which is populated with the Base64 [4] encoding of		A parameter, which is populated with the Base64 [4] encoding of
	the concatenation of the AKA authentication challenge RAND, the		the concatenation of the AKA authentication challenge RAND, the
	AKA AUTN token, and optionally some server specific data, as in		AKA AUTN token, and optionally some server specific data, as in
	Figure 1.		Figure 1.
	Example:		Example:
	nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="		nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| RAND |		| RAND |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| AUTN |		| AUTN |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Server Data...		| Server Data...
	+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Generating the nonce value.		Figure 1: Generating the nonce value.
	If the server receives a client authentication containing the "auts"		If the server receives a client authentication containing the "auts"
	parameter defined in Section 3.4 that includes a valid AKA AUTS		parameter defined in Section 3.4, that includes a valid AKA AUTS
	parameter, the server MUST use it to generate a new challenge to the		parameter, the server MUST use it to generate a new challenge to the
	client. Note that when the AUTS is present, the included "response"		client. Note that when the AUTS is present, the included "response"
	parameter is calculated using an empty password (password of ""),		parameter is calculated using an empty password (password of ""),
	instead of a RES.		instead of a RES.
	3.3 Client Authentication		3.3 Client Authentication
	When a client receives a Digest AKA authentication challenge, it		When a client receives a Digest AKA authentication challenge, it
	extracts the RAND and AUTN from the "nonce" parameter, and assesses		extracts the RAND and AUTN from the "nonce" parameter, and assesses
	the AUTN token provided by the server. If the client successfully		the AUTN token provided by the server. If the client successfully
	authenticates the server with the AUTN, and determines that the SQN		authenticates the server with the AUTN, and determines that the SQN
	used in generating the challenge is within expected range, the AKA		used in generating the challenge is within expected range, the AKA
	algorithms are run with the RAND challenge and shared secret K.		algorithms are run with the RAND challenge and shared secret K.
	The resulting AKA RES parameter is treated as "password" when		The resulting AKA RES parameter is treated as a "password" when
	calculating the response directive of RFC 2617.		calculating the response directive of RFC 2617.
	3.4 Synchronization Failure		3.4 Synchronization Failure
	For indicating an AKA sequence number synchronization failure, and to		For indicating an AKA sequence number synchronization failure, and to
	re-synchronize the SQN in the AuC using the AUTS token, a new		re-synchronize the SQN in the AuC using the AUTS token, a new
	directive is defined for the "digest-response" of the "Authorization"		directive is defined for the "digest-response" of the "Authorization"
	request header defined in RFC 2617:		request header defined in RFC 2617:
	auts = "auts" EQUAL auts-param		auts = "auts" EQUAL auts-param
	auts-param = LDQUOT auts-value RDQUOT		auts-param = LDQUOT auts-value RDQUOT
	auts-value = <base64 encoding of AUTS>		auts-value = <base64 encoding of AUTS>
	auts		auts
	A string carrying a base64 encoded AKA AUTS parameter. This		A string carrying a base64 encoded AKA AUTS parameter. This
	directive is used to re-synchronize the server side SQN. If the		directive is used to re-synchronize the server side SQN. If the
	directive is present, the client doesn't use any password when		directive is present, the client doesn't use any password when
	calculating its credentials. Instead, the client MUST calculate		calculating its credentials. Instead, the client MUST calculate
	its credentials using an empty password (password of "").		its credentials using an empty password (password of "").
	Example:		Example:
	auts="CjkyMzRfOiwg5CfkJ2UK="		auts="CjkyMzRfOiwg5CfkJ2UK="
	Upon receiving the "auts" parameter, the server will check the		Upon receiving the "auts" parameter, the server will check the
	validity of the parameter value using the shared secret K. A valid		validity of the parameter value using the shared secret K. A valid
	AUTS parameter is used to re-synchronize the SQN in the AuC. The		AUTS parameter is used to re-synchronize the SQN in the AuC. The
	synchronized SQN is then used to generate a fresh authentication		synchronized SQN is then used to generate a fresh authentication
	vector AV, with which the client is then re-challenged.		vector AV, with which the client is then re-challenged.
	3.5 Server Authentication		3.5 Server Authentication
	Even though AKA provides inherent mutual authentication with the AKA		Even though AKA provides inherent mutual authentication with the AKA
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 40 ¶
	| +------------------------------+		| +------------------------------+
	| | Server checks the given RES, |		| | Server checks the given RES, |
	| | and finds it correct. |		| | and finds it correct. |
	| +------------------------------+		| +------------------------------+
	| |		| |
	| 4) 200 OK |		| 4) 200 OK |
	| Authentication-Info: (XRES is used) |		| Authentication-Info: (XRES is used) |
	|<------------------------------------------------------|		|<------------------------------------------------------|
	| |		| |
	Figure 2: Message flow representing a successful authentication.		Figure 2: Message flow representing a successful authentication.
	1) Initial request		1) Initial request
	REGISTER sip:home.mobile.biz SIP/2.0		REGISTER sip:home.mobile.biz SIP/2.0
	2) Response containing a challenge		2) Response containing a challenge
	SIP/2.0 401 Unauthorized		SIP/2.0 401 Unauthorized
	WWW-Authenticate: Digest		WWW-Authenticate: Digest
	realm="RoamingUsers@mobile.biz",		realm="RoamingUsers@mobile.biz",
	skipping to change at page 13, line 50 ¶		skipping to change at page 14, line 9 ¶
	A server may allow each nonce value to be used only once by sending a		A server may allow each nonce value to be used only once by sending a
	next-nonce directive in the Authentication-Info header field of every		next-nonce directive in the Authentication-Info header field of every
	response. However, this may cause a synchronization failure, and		response. However, this may cause a synchronization failure, and
	consequently some additional round trips in AKA, if the same SQN		consequently some additional round trips in AKA, if the same SQN
	space is also used for other access schemes at the same time.		space is also used for other access schemes at the same time.
	5.3 Multiple Authentication Schemes and Algorithms		5.3 Multiple Authentication Schemes and Algorithms
	In HTTP authentication, a user agent MUST choose the strongest		In HTTP authentication, a user agent MUST choose the strongest
	authentication scheme it understands and request credentials from the		authentication scheme it understands and request credentials from the
	user based upon that challenge.		user, based upon that challenge.
	In general, using passwords generated by Digest AKA with other HTTP		In general, using passwords generated by Digest AKA with other HTTP
	authentication schemes is not recommended even though the realm		authentication schemes is not recommended even though the realm
	values or protection domains would coincide. In these cases, a		values or protection domains would coincide. In these cases, a
	password should be requested from the end-user instead. Digest AKA		password should be requested from the end-user instead. Digest AKA
	passwords MUST NOT be re-used with such HTTP authentication schemes,		passwords MUST NOT be re-used with such HTTP authentication schemes,
	which send the password in clear. In particular, AKA passwords MUST		which send the password in clear. In particular, AKA passwords MUST
	NOT be re-used with HTTP Basic.		NOT be re-used with HTTP Basic.
	The same principle must be applied within a scheme if several		The same principle must be applied within a scheme if several
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 39 ¶
	which are in the dictionary [2]. This potential threat does not		which are in the dictionary [2]. This potential threat does not
	exist in HTTP Digest AKA because the algorithm will use ISIM		exist in HTTP Digest AKA because the algorithm will use ISIM
	originated passwords. However, the end-user must still be careful		originated passwords. However, the end-user must still be careful
	with PIN codes. Even though HTTP Digest AKA password requests are		with PIN codes. Even though HTTP Digest AKA password requests are
	never displayed to the end-user, she will be authenticated to the		never displayed to the end-user, she will be authenticated to the
	ISIM via a PIN code. Commonly known initial PIN codes are typically		ISIM via a PIN code. Commonly known initial PIN codes are typically
	installed to the ISIM during manufacturing and if the end-users do		installed to the ISIM during manufacturing and if the end-users do
	not change them, there is a danger that an unauthorized user may be		not change them, there is a danger that an unauthorized user may be
	able to use the device. Naturally this requires that the		able to use the device. Naturally this requires that the
	unauthorized user has access to the physical device, and that the		unauthorized user has access to the physical device, and that the
	end-user has not changed the initial PIN code. For this reason, end-		end-user has not changed the initial PIN code. For this reason,
	users are strongly encouraged to change their PIN codes when they		end-users are strongly encouraged to change their PIN codes when they
	receive an ISIM.		receive an ISIM.
	5.5 Session Protection		5.5 Session Protection
	Digest AKA is able to generate additional session keys for integrity		Digest AKA is able to generate additional session keys for integrity
	(IK) and confidentiality (CK) protection. Even though this document		(IK) and confidentiality (CK) protection. Even though this document
	does not specify the use of these additional keys, they may be used		does not specify the use of these additional keys, they may be used
	for creating additional security within HTTP authentication or some		for creating additional security within HTTP authentication or some
	other security mechanism.		other security mechanism.
	skipping to change at page 15, line 9 ¶		skipping to change at page 15, line 19 ¶
	protected even if the RAND parameter happened to be the same for two		protected even if the RAND parameter happened to be the same for two
	authentication requests. More importantly, this offers additional		authentication requests. More importantly, this offers additional
	protection for the case where an attacker replays an old		protection for the case where an attacker replays an old
	authentication request sent by the network. The client will be able		authentication request sent by the network. The client will be able
	to detect that the request is old, and refuse authentication. This		to detect that the request is old, and refuse authentication. This
	proves liveliness of the authentication request even in the case		proves liveliness of the authentication request even in the case
	where a MitM attacker tries to trick the client into providing an		where a MitM attacker tries to trick the client into providing an
	authentication response, and then replaces parts of the message with		authentication response, and then replaces parts of the message with
	something else. In other words, a client challenged by Digest AKA is		something else. In other words, a client challenged by Digest AKA is
	not vulnerable for chosen plain text attacks. Finally, frequent		not vulnerable for chosen plain text attacks. Finally, frequent
	sequence number errors would reveal an attack where the tamper-		sequence number errors would reveal an attack where the tamper
	resistant card has been cloned and is being used in multiple devices.		resistant card has been cloned and is being used in multiple devices.
	The downside of sequence number tracking is that servers must hold		The downside of sequence number tracking is that servers must hold
	more information for each user than just their long-term secret,		more information for each user than just their long-term secret,
	namely the current SQN value. However, this information is typically		namely the current SQN value. However, this information is typically
	not stored in the SIP nodes, but in dedicated authentication servers		not stored in the SIP nodes, but in dedicated authentication servers
	instead.		instead.
	5.7 Improvements to AKA Security		5.7 Improvements to AKA Security
	Even though AKA is perceived as a secure mechanism, Digest AKA is		Even though AKA is perceived as a secure mechanism, Digest AKA is
	able to improve it. More specifically the AKA parameters carried		able to improve it. More specifically, the AKA parameters carried
	between the client and the server during authentication may be		between the client and the server during authentication may be
	protected along with other parts of the message, by using Digest AKA.		protected along with other parts of the message by using Digest AKA.
	This is not possible with plain AKA.		This is not possible with plain AKA.
	6. IANA Considerations		6. IANA Considerations
	(This section is not applicable until this document is published as
	an RFC.)
	This document specifies an aka-version namespace in Section 3.1 which		This document specifies an aka-version namespace in Section 3.1 which
	requires a central coordinating body. The body responsible for this		requires a central coordinating body. The body responsible for this
	coordination is the Internet Assigned Numbers Authority (IANA).		coordination is the Internet Assigned Numbers Authority (IANA).
	The default aka-version defined in this document is "AKAv1".		The default aka-version defined in this document is "AKAv1".
	Following the policies outlined in [5], versions above 1 are		Following the policies outlined in [5], versions above 1 are
	allocated as Expert Review.		allocated as Expert Review.
	Registrations with the IANA MUST include the version number being		Registrations with the IANA MUST include the version number being
	registered, including the "AKAv" prefix. For example, a registration		registered, including the "AKAv" prefix. For example, a registration
	skipping to change at page 16, line 7 ¶		skipping to change at page 16, line 11 ¶
	for "FOOv2" or "2" would not be valid. Further, the registration		for "FOOv2" or "2" would not be valid. Further, the registration
	MUST include contact information for the party responsible for the		MUST include contact information for the party responsible for the
	registration.		registration.
	As this document defines the default aka-version, the initial IANA		As this document defines the default aka-version, the initial IANA
	registration for aka-version values will contain an entry for		registration for aka-version values will contain an entry for
	"AKAv1".		"AKAv1".
	6.1 Registration Template		6.1 Registration Template
	To: ietf-digest-aka@iana.org		To: ietf-digest-aka@iana.org
	Subject: Registration of a new AKA version		Subject: Registration of a new AKA version
	Version identifier:		Version identifier:
	(Must contain a valid aka-version value,		(Must contain a valid aka-version value,
	as described in section 3.1.)		as described in section 3.1.)
	Person & email address to contact for further information:		Person & email address to contact for further information:
	(Must contain contact information for the		(Must contain contact information for the
	person(s) responsible for the registration.)		person(s) responsible for the registration.)
	Normative References		Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:		Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
	Basic and Digest Access Authentication", RFC 2617, June 1999.		Basic and Digest Access Authentication", RFC 2617, June 1999.
	[3] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation		[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	February 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message Bodies",		Extensions (MIME) Part One: Format of Internet Message Bodies",
	RFC 2045, November 1996.		RFC 2045, November 1996.
	Informative References		Informative References
	[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[6] 3rd Generation Partnership Project, "Security Architecture		[6] 3rd Generation Partnership Project, "Security Architecture
	(Release 4)", TS 33.102, December 2001.		(Release 4)", TS 33.102, December 2001.
	[7] http://www.iana.org, "Assigned Numbers", February 2002.		[7] http://www.iana.org, "Assigned Numbers".
			Appendix A. Acknowledgements
			The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete
			McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney,
			Allison Mankin and Greg Rose.
	Authors' Addresses		Authors' Addresses
	Aki Niemi		Aki Niemi
	Nokia		Nokia
	P.O. Box 301		P.O. Box 301
	NOKIA GROUP, FIN 00045		NOKIA GROUP, FIN 00045
	Finland		Finland
	Phone: +358 50 389 1644		Phone: +358 50 389 1644
	skipping to change at page 17, line 34 ¶		skipping to change at page 18, line 5 ¶
	Vesa Torvinen		Vesa Torvinen
	Ericsson		Ericsson
	Joukahaisenkatu 1		Joukahaisenkatu 1
	Turku, FIN 20520		Turku, FIN 20520
	Finland		Finland
	Phone: +358 40 7230822		Phone: +358 40 7230822
	EMail: vesa.torvinen@ericsson.fi		EMail: vesa.torvinen@ericsson.fi
	Appendix A. Acknowledgements
	The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete
	McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney,
	Allison Mankin and Greg Rose.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
End of changes. 57 change blocks.
	139 lines changed or deleted		124 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/