rfc4169.txt   draft-rfc4169-algupdate.txt 
Network Working Group V. Torvinen Network Working Group J. Arkko
Request for Comments: 4169 Turku Polytechnic Internet-Draft V. Lehtovirta
Category: Informational J. Arkko Obsoletes: 3310,4169 (if approved) Ericsson
M. Naslund Intended status: Informational March 15, 2021
Ericsson Expires: September 16, 2021
November 2005
Hypertext Transfer Protocol (HTTP) Digest Authentication Using Hypertext Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA) Version-2 Authentication and Key Agreement (AKA) Version-2
draft-rfc4169-algupdate-00-pre4
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
HTTP Digest, as specified in RFC 2617, is known to be vulnerable to HTTP Digest, as specified in RFC 7616, is known to be vulnerable to
man-in-the-middle attacks if the client fails to authenticate the man-in-the-middle attacks if the client fails to authenticate the
server in TLS, or if the same passwords are used for authentication server in TLS, or if the same passwords are used for authentication
in some other context without TLS. This is a general problem that in some other context without TLS. This is a general problem that
exists not just with HTTP Digest, but also with other IETF protocols exists not just with HTTP Digest, but also with other IETF protocols
that use tunneled authentication. This document specifies version 2 that use tunneled authentication. This document specifies version 2
of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be of the HTTP Digest AKA algorithm. This algorithm can be implemented
implemented in a way that it is resistant to the man-in-the-middle in a way that it is resistant to the man-in-the-middle attack, and
attack. uses updated hash algorithms.
This document obsoletes both HTTP Digest AKAv1 (RFC 3110) and AKAv2
(RFC 4169).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 16, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. HTTP Digest AKAv2 . . . . . . . . . . . . . . . . . . . . . . 5 2. HTTP Digest AKAv2 . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Password generation . . . . . . . . . . . . . . . . . . 6 2.1. Password Generation . . . . . . . . . . . . . . . . . . . 6
2.2. Session keys . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Session Keys . . . . . . . . . . . . . . . . . . . . . . 7
3. Example Digest AKAv2 Operation . . . . . . . . . . . . . . . . 7 3. Example Digest AKAv2 Operation . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Multiple Authentication Schemes and Algorithms . . . . . 7 4.1. Multiple Authentication Schemes and Algorithms . . . . . 8
4.2. Session Protection . . . . . . . . . . . . . . . . . . . 7 4.2. Session Protection . . . . . . . . . . . . . . . . . . . 9
4.3. Man-in-the-middle attacks . . . . . . . . . . . . . . . 8 4.3. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 9
4.4. Entropy . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Registration Information . . . . . . . . . . . . . . . . 10 5.1. Registration Information . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 3310 and RFC 4169 . . . . . . . . 13
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 14
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) Digest Authentication, The Hypertext Transfer Protocol (HTTP) Digest Authentication,
described in [4], has been extended in [6] to support the described in [RFC7616], has been extended in [RFC3310] to support the
Authentication and Key Agreement (AKA) mechanism [7]. The AKA Authentication and Key Agreement (AKA) mechanism [TS-3GPP.33.102].
mechanism performs authentication and session key agreement in The AKA mechanism performs authentication and session key agreement
Universal Mobile Telecommunications System (UMTS) networks. HTTP in Universal Mobile Telecommunications System (UMTS) networks. HTTP
Digest AKA enables the usage of AKA as a one-time password generation Digest AKA enables the usage of AKA as a one-time password generation
mechanism for Digest authentication. mechanism for Digest authentication.
HTTP Digest is known to be vulnerable to man-in-the-middle attacks, HTTP Digest is known to be vulnerable to man-in-the-middle attacks,
even when run inside TLS, if the same HTTP Digest authentication even when run inside TLS, if the same HTTP Digest authentication
credentials are used in some other context without TLS. The attacker credentials are used in some other context without TLS. The attacker
may initiate a TLS session with a server, and when the server may initiate a TLS session with a server, and when the server
challenges the attacker with HTTP Digest, the attacker masquerades challenges the attacker with HTTP Digest, the attacker masquerades
the server to the victim. If the victim responds to the challenge, the server to the victim. If the victim responds to the challenge,
the attacker is able to use this response towards the server in HTTP the attacker is able to use this response towards the server in HTTP
Digest. Note that this attack is an instance of a general attack Digest. Note that this attack is an instance of a general attack
that affects a number of IETF protocols, such as PIC. The general that affects a number of IETF protocols, such as PIC. The general
problem is discussed in [8] and [9]. problem is discussed in [Asokan] and [Puthenkulam].
Because of the vulnerability described above, the use of HTTP Digest Because of the vulnerability described above, the use of HTTP Digest
"AKAv1" should be limited to the situations in which the client is "AKAv1" should be limited to the situations in which the client is
able to demonstrate that, in addition to the AKA response, it able to demonstrate that, in addition to the AKA response, it
possesses the AKA session keys. This is possible, for example, if possesses the AKA session keys. This is possible, for example, if
the underlying security protocol uses the AKA-generated session keys the underlying security protocol uses the AKA-generated session keys
to protect the authentication response. This is the case, for to protect the authentication response. This is the case, for
example, in the 3GPP IP Multimedia Core Network Subsystem (IMS), example, in the 3GPP IP Multimedia Core Network Subsystem (IMS),
where HTTP Digest "AKAv1" is currently applied. However, HTTP Digest where HTTP Digest "AKAv1" is currently applied. However, HTTP Digest
"AKAv1" should not be used with tunnelled security protocols that do "AKAv1" should not be used with tunnelled security protocols that do
skipping to change at page 3, line 42 skipping to change at page 4, line 8
4. Authentication credentials are used in a cryptographically 4. Authentication credentials are used in a cryptographically
different way for each application. different way for each application.
This document specifies a new algorithm version for HTTP Digest AKA This document specifies a new algorithm version for HTTP Digest AKA
(i.e., "AKAv2"). "AKAv2" specifies a cryptographically different way (i.e., "AKAv2"). "AKAv2" specifies a cryptographically different way
to use AKA credentials in use cases that are based on either HTTP to use AKA credentials in use cases that are based on either HTTP
Digest authentication or UMTS authentication (cf. approach 4 above). Digest authentication or UMTS authentication (cf. approach 4 above).
The only difference to "AKAv1" is that, in addition to an AKA The only difference to "AKAv1" is that, in addition to an AKA
response RES, the AKA related session keys, IK and CK, are also used response RES, the AKA related session keys, IK and CK, are also used
as the password for HTTP Digest. AKAv2 is immune to the as the password for HTTP Digest. AKAv2 is immune to the man-in-the-
man-in-the-middle attack described above. However, if AKAv2 is used middle attack described above. However, if AKAv2 is used in some
in some environment, both with and without some underlying security, environment, both with and without some underlying security, such as
such as TLS, the problem still exists. TLS, the problem still exists.
New HTTP Digest AKA algorithm versions can be registered with IANA, New HTTP Digest AKA algorithm versions can be registered with IANA,
based on Expert Review. Documentation of new algorithm versions is based on Expert Review. Documentation of new algorithm versions is
not mandated as RFCs. However, "AKAv2" is documented as an RFC not mandated as RFCs. However, "AKAv2" is documented as an RFC
because the use of different AKA algorithm versions includes security because the use of different AKA algorithm versions includes security
implications of which the implementors should be aware. The implications of which the implementors should be aware. The
extension version and security implications are presented in this extension version and security implications are presented in this
document. document.
This new version of this specification incorporates the definition of
the use of AKAv2 with the SHA-256 algorithm, aligning industry usage
between IETF and 3GPP [TS-3GPP.33.203].
This version of the HTTP Digest AKAv2 specification obsoletes both
the earlier AKAv2 specification (RFC 4169) as well as the AKAv1
specification (RFC 3110). Those existing RFCs continue to be usable
by implementations that already conform to the existing RFCs, and
other standards may still refer to those older RFCs. However,
adopting this memo over RFC 3310 and RFC 4169 provides better
security.
TODO: Decide whether we should update 3310 algorithm separately
(giving some further life to 3310), just provide this
specififation as an "update" not replacement, or declare that this
is the new specification and obseleting the old ones (as is done
in the -pre3 version).
1.1. Terminology 1.1. Terminology
This chapter explains the terminology used in this document. This chapter explains the terminology used in this document.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [3]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
AKA AKA
Authentication and Key Agreement. Authentication and Key Agreement.
AKA is a challenge-response based mechanism that uses symmetric AKA is a challenge-response based mechanism that uses symmetric
cryptography. AKA can be run in a UMTS IM Services Identity cryptography. AKA can be run in a UMTS IM Services Identity
Module (ISIM) or in UMTS Subscriber Identity Module (USIM), which Module (ISIM) or in UMTS Subscriber Identity Module (USIM), which
reside on a smart-card-like device that also provides tamper reside on a smart-card-like device that also provides tamper
resistant storage of shared secrets. resistant storage of shared secrets.
skipping to change at page 5, line 34 skipping to change at page 6, line 18
SIM. SIM.
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.
2. HTTP Digest AKAv2 2. HTTP Digest AKAv2
In general, the Digest AKAv2 operation is identical to the Digest In general, the Digest AKAv2 operation is identical to the Digest
AKAv1 operation described in [6]. This chapter specifies the parts AKAv1 operation described in [RFC3310]. This chapter specifies the
in which Digest AKAv2 is different from Digest AKAv1 operation. The parts in which Digest AKAv2 is different from Digest AKAv1 operation.
notation used in the Augmented BNF definitions for the new and The notation used in the Augmented BNF definitions for the new and
modified syntax elements in this section is as used in SIP [5], and modified syntax elements in this section is as used in SIP [RFC3261],
any elements not defined in this section are as defined in [6]. and any elements not defined in this section are as defined in
[RFC3310].
In order to direct the client into using AKAv2 for authentication In order to direct the client into using AKAv2 for authentication
instead of other AKA versions or other HTTP Digest algorithms, the instead of other AKA versions or other HTTP Digest algorithms, the
AKA version directive of [6] shall have the following new value: AKA version directive of [RFC3310] shall have the following new
value:
aka-version = "AKAv2" aka-version = "AKAv2"
The AKA version directive is used as a part of the algorithm field as The AKA version directive is used as a part of the algorithm field as
defined in [6]. defined in [RFC3310].
Example: algorithm=AKAv2-MD5 Example: algorithm=AKAv2-MD5
Another example: algorithm=AKAv2-SHA-256
2.1. Password Generation 2.1. Password Generation
The client shall use base64 encoded [1] parameters PRF(RES||IK||CK, The client shall use base64 encoded [RFC2045] parameters
"http-digest-akav2-password") as a "password" when calculating the PRF(RES||IK||CK, "http-digest-akav2-password") as a "password" when
HTTP Digest response directive for AKAv2. calculating the HTTP Digest response directive for AKAv2.
The server shall use base64 encoded [1] parameters PRF(XRES||IK||CK, The server shall use base64 encoded [RFC2045] parameters
"http-digest-akav2-password") as a "password" when checking the HTTP PRF(XRES||IK||CK, "http-digest-akav2-password") as a "password" when
Digest response or when calculating the "response-auth" of the checking the HTTP Digest response or when calculating the "response-
"Authentication-Info" header. auth" of the "Authentication-Info" header.
The pseudo-random function (PRF) used to construct the HTTP Digest The pseudo-random function (PRF) used to construct the HTTP Digest
password is equal to HMAC [2] using the hash algorithm that is used password is equal to HMAC [RFC2104] using the hash algorithm that is
in producing the digest and the checksum. For example, if the used in producing the digest and the checksum. For example, if the
algorithm is AKAv2-MD5, then the PRF is HMAC_MD5. algorithm is AKAv2-MD5, then the PRF is HMAC_MD5 [RFC1321] [RFC2104].
If the algorithm is AKAv2-SHA-256, then the PRF is HMAC_SHA256
[FIPS.180-4] [RFC2104].
Support for AKAv2-SHA-256 is REQUIRED for servers implementing 3GPP
Release 17 or above specifications. Support for AKAv2-SHA-256 is
RECOMMENDED for all clients, and REQUIRED for Release 17 clients.
The string "http-digest-akav2-password" included in the key The string "http-digest-akav2-password" included in the key
derivation is case sensitive. derivation is case sensitive.
2.2. Session keys 2.2. Session Keys
Even though the HTTP Digest AKA framework does not specify the use of Even though the HTTP Digest AKA framework does not specify the use of
the session keys IK and CK for confidentiality and integrity the session keys IK and CK for confidentiality and integrity
protection, the keys may be used for creating additional security protection, the keys may be used for creating additional security
within HTTP authentication or some other security mechanism. within HTTP authentication or some other security mechanism.
However, the original session keys IK and CK MUST NOT be directly However, the original session keys IK and CK MUST NOT be directly re-
re-used for such additional security in "AKAv2". Instead, session used for such additional security in "AKAv2". Instead, session keys
keys IK' and CK' are derived from the original keys IK and CK in the IK' and CK' are derived from the original keys IK and CK in the
following way: following way:
IK' = PRF(IK, "http-digest-akav2-integritykey") IK' = PRF(IK, "http-digest-akav2-integritykey")
CK' = PRF(CK, "http-digest-akav2-cipherkey") CK' = PRF(CK, "http-digest-akav2-cipherkey")
Any application using the HTTP authentication framework is allowed to Any application using the HTTP authentication framework is allowed to
use these masked session keys. The unmasked session keys MAY also be use these masked session keys. The unmasked session keys MAY also be
re-used in some other context if application-specific strings other re-used in some other context if application-specific strings other
than "http-digest-akav2-integritykey" or than "http-digest-akav2-integritykey" or "http-digest-
"http-digest-akav2-cipherkey" are used to mask the original session akav2-cipherkey" are used to mask the original session keys.
keys.
The pseudo-random function (PRF) used to construct the HTTP Digest The pseudo-random function (PRF) used to construct the HTTP Digest
session keys is equal to HMAC [2] using the hash algorithm that is session keys is equal to HMAC [RFC2104] using the hash algorithm that
used in producing the digest and the checksum. For example, if the is used in producing the digest and the checksum. For example, if
algorithm is AKAv2-MD5, then the PRF is HMAC_MD5. The algorithm MUST the algorithm is AKAv2-MD5, then the PRF is HMAC_MD5. If the
be used in the HMAC format, as defined in [2]. algorithm is AKAv2-SHA-256, then the PRF is HMAC_SHA256. The
algorithms MUST be used in the HMAC format, as defined in [RFC2104].
Support for AKAv2-SHA-256 is again REQUIRED.
The strings "http-digest-akav2-integritykey" and "http-digest-akav2- The strings "http-digest-akav2-integritykey" and "http-digest-akav2-
cipherkey" included in the key derivation are case sensitive. cipherkey" included in the key derivation are case sensitive.
3. Example Digest AKAv2 Operation 3. Example Digest AKAv2 Operation
This document does not introduce any changes to the operations of This document does not introduce any changes to the operations of
HTTP Digest or HTTP Digest AKA. Examples defined in [6] apply HTTP Digest or HTTP Digest AKA. Examples defined in [RFC3310] apply
directly to AKAv2 with the following two exceptions: directly to AKAv2 with the following two exceptions:
1. The algorithm directive has a prefix "AKAv2" instead of "AKAv1". 1. The algorithm directive has a prefix "AKAv2" instead of "AKAv1".
2. The HTTP Digest password is derived from base64 encoded PRF(RES|| 2. The HTTP Digest password is derived from base64 encoded PRF(RES||
IK||CK, "http-digest-akav2-password") or PRF(XRES||IK||CK, "http- IK||CK, "http-digest-akav2-password") or PRF(XRES||IK||CK, "http-
digest-akav2-password") instead of (RES) or (XRES) respectively. digest-akav2-password") instead of (RES) or (XRES) respectively.
3. The optional session keys are derived from PRF(IK, "http-digest- 3. The optional session keys are derived from PRF(IK, "http-digest-
akav2-integritykey") and PRF(CK, "http-digest-akav2-cipherkey") akav2-integritykey") and PRF(CK, "http-digest-akav2-cipherkey")
instead of IK and CK respectively. instead of IK and CK respectively.
Note that the password in "AKAv1" is in binary format. The "AKAv2" Note that the password in "AKAv1" is in binary format. The "AKAv2"
password is base64 encoded [1]. password is base64 encoded [RFC2045].
4. Security Considerations 4. Security Considerations
This specification provides two specific improvements over RFC 3310
and and one over RFC 4169:
o Algorithm update, to prevent vulnerabilities associated with
weaker hash algorithms. This is a change over both RFC 3310 and
RFC 4169.
o Key calculation update, to prevent vulnerabilities associated with
man-in-the-middle attacks. This is a change over RFC 3310, while
RFC 4169 already had protection for this.
The next subsections discuss specific details of the properties of
this specification.
4.1. Multiple Authentication Schemes and Algorithms 4.1. Multiple Authentication Schemes and Algorithms
The rules for a user agent for choosing among multiple authentication The rules for a user agent for choosing among multiple authentication
schemes and algorithms are as defined in [6], except that the user schemes and algorithms are as defined in [RFC3310], except that the
agent MUST choose "AKAv2" if both "AKAv1" and "AKAv2" are present. user agent MUST choose "AKAv2" if both "AKAv1" and "AKAv2" are
present. Similarly, the user agent MUST choose AKAv2-SHA-256 if both
AKAv2-MD5 and AKAv2-SHA-256 is present and AKAv2-SHA-256 is supported
by the user agent.
TODO: Figure out if the negotiation actually works in the details,
and in the HTTP protocol exchanges.
Since HTTP Digest is known to be vulnerable for bidding-down attacks Since HTTP Digest is known to be vulnerable for bidding-down attacks
in environments where multiple authentication schemes and/or in environments where multiple authentication schemes and/or
algorithms are used, the system implementors should pay special algorithms are used, the system implementors should pay special
attention to scenarios in which both "AKAv1" and "AKAv2" are used. attention to scenarios in which both "AKAv1" and "AKAv2" are used.
The use of both AKA algorithm versions should be avoided, especially The use of both AKA algorithm versions should be avoided, especially
if the AKA generated sessions keys or some other additional security if the AKA generated sessions keys or some other additional security
measures to authenticate the clients (e.g., client certificates) are measures to authenticate the clients (e.g., client certificates) are
not used. not used.
skipping to change at page 8, line 10 skipping to change at page 9, line 22
within HTTP authentication or some other security mechanism. This within HTTP authentication or some other security mechanism. This
recommendation is based on the assumption that algorithms used in recommendation is based on the assumption that algorithms used in
HTTP Digest, such as MD5, are sufficiently strong one-way functions, HTTP Digest, such as MD5, are sufficiently strong one-way functions,
and, consequently, HTTP Digest responses leak no or very little and, consequently, HTTP Digest responses leak no or very little
computational information about IK and CK. Furthermore, the session computational information about IK and CK. Furthermore, the session
keys are masked into IK' and CK' before they can be used for session keys are masked into IK' and CK' before they can be used for session
protection. protection.
4.3. Man-in-the-Middle Attacks 4.3. Man-in-the-Middle Attacks
Reference [8] describes a "man-in-the-middle" attack related to Reference [Asokan] describes a "man-in-the-middle" attack related to
tunnelled authentication protocols. The attack can occur in an EAP tunnelled authentication protocols. The attack can occur in an EAP
context or any similar contexts where tunnelled authentication is context or any similar contexts where tunnelled authentication is
used and where the same authentication credentials are used without used and where the same authentication credentials are used without
protection in some other context or the client fails to authenticate protection in some other context or the client fails to authenticate
the server. the server.
For example, the use of TLS with HTTP Digest authentication (i.e., For example, the use of TLS with HTTP Digest authentication (i.e.,
TLS for server authentication, and subsequent use of HTTP Digest for TLS for server authentication, and subsequent use of HTTP Digest for
client authentication) is an instance of such scenario. HTTP client authentication) is an instance of such scenario. HTTP
challenges and responses can be fetched from and to different TLS challenges and responses can be fetched from and to different TLS
skipping to change at page 10, line 32 skipping to change at page 11, line 43
The underlying AKA protocol (e.g., UMTS AKA) has been designed to The underlying AKA protocol (e.g., UMTS AKA) has been designed to
keep CK and IK confidential, but will typically send RES in the keep CK and IK confidential, but will typically send RES in the
clear. We note that, even if (by some unfortunate misuse of AKA) RES clear. We note that, even if (by some unfortunate misuse of AKA) RES
values were revealed, the inclusion of RES in PRF(RES||IK||CK) is values were revealed, the inclusion of RES in PRF(RES||IK||CK) is
still beneficial, as it makes pre-calculated dictionaries of IK||CK still beneficial, as it makes pre-calculated dictionaries of IK||CK
values rather useless (though such dictionaries are infeasible for values rather useless (though such dictionaries are infeasible for
typical sizes of IK and CK). typical sizes of IK and CK).
5. IANA Considerations 5. IANA Considerations
This document specifies a new aka-version, "AKAv2", to the This document specifies a new aka-version, "AKAv2", to the aka-
aka-version namespace maintained by IANA. The procedure for version namespace maintained by IANA. The procedure for allocation
allocation of new aka-versions is defined in [6]. of new aka-versions is defined in [RFC3310].
5.1. Registration Information 5.1. Registration Information
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: "AKAv2" Version identifier: "AKAv2"
Contacts for further information: Vesa.Torvinen@turkuamk.fi, Contacts for further information: vesa.lehtovirta@ericsson.com o
jari.arkko@ericsson.com, or mats.naslund@ericsson.com jari.arkko@ericsson.com.
6. References 6. References
6.1. Normative References 6.1. Normative References
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Extensions (MIME) Part One: Format of Internet Message Bodies", DOI 10.17487/RFC1321, April 1992, <https://www.rfc-
RFC 2045, November 1996. editor.org/info/rfc1321>.
[2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
for Message Authentication", RFC 2104, February 1997. Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Levels", BCP 14, RFC 2119, March 1997. Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
editor.org/info/rfc2104>.
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Requirement Levels", BCP 14, RFC 2119,
Basic and Digest Access Authentication", RFC 2617, June 1999. DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>.
[6] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Protocol (HTTP) Digest Authentication Using Authentication and Digest Access Authentication", RFC 7616,
Key Agreement (AKA)", RFC 3310, September 2002. DOI 10.17487/RFC7616, September 2015, <https://www.rfc-
editor.org/info/rfc7616>.
6.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[7] 3rd Generation Partnership Project, "Security Architecture [FIPS.180-4]
(Release 4)", TS 33.102, December 2001. National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[8] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in 6.2. Informative References
Tunnelled Authentication Protocols", Cryptology ePrint Archive,
http://eprint.iacr.org Report 2002/163, October 2002.
[9] Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, "The [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Compound Authentication Binding Problem", Work in Progress, Protocol (HTTP) Digest Authentication Using Authentication
March 2003. and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310,
September 2002, <https://www.rfc-editor.org/info/rfc3310>.
Authors' Addresses [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext
Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA) Version-2",
RFC 4169, DOI 10.17487/RFC4169, November 2005,
<https://www.rfc-editor.org/info/rfc4169>.
Vesa Torvinen [TS-3GPP.33.102]
Turku Polytechnic 3GPP, "3rd Generation Partnership Project, "Security
Ylhaistentie 2 Architecture (Release 4)", 3GPP Technical
Salo FIN 24130 Specification33.102, December 2001.
Finland
Phone: +358 10 5536210 [TS-3GPP.33.203]
EMail: vesa.torvinen@turkuamk.fi 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G
security; Access security for IP-based services (Release
15)", 3GPP Technical Specification33.203, March 2018.
Jari Arkko [Asokan] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
Ericsson in Tunnelled Authentication Protocols", Cryptology ePrint
Hirsalantie 1 Archive http://eprint.iacr.org Report 2002/163, October
Jorvas FIN 02420 2002.
Finland
Phone: +358 40 5079256 [Puthenkulam]
EMail: jari.arkko@ericsson.com Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
"The Compound Authentication Binding Problem", March 2003
(Work in Progress).
Mats Naeslund Appendix A. Changes from RFC 3310 and RFC 4169
Ericsson
Torshamnsgatan 23
Stockholm SE 16480
Sweden
Phone: +46 8 58533739 This version of the specification has changed the algorithms so that
EMail: mats.naslund@ericsson.com support for SHA256 is now available. User agent preferences to force
the selecetion of the preferred algorithm have also changed.
Full Copyright Statement This version of the specification also adopts the key generation that
is resistant to man-in-the-middle attacks, i.e., the use of AKAv2
instead of AKAv1, thereby requesting switching AKAv1 usage to AKAv2.
Copyright (C) The Internet Society (2005). Other changes in this document include some minor editorial
improvements, and the update of references to their most current
versions.
This document is subject to the rights, licenses and restrictions Appendix B. Contributors
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This is a new version of a specification based on [RFC3310] and
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS [RFC4169]. Much of the text in those RFCs was provided by Mats
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET Naslund and Vesa Torvinen, and text largely remains in this version
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, as well.
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Appendix C. Acknowledgements
The IETF takes no position regarding the validity or scope of any The authors would like to thank John Mattsson, Mohit Sethi, Pinar
Intellectual Property Rights or other rights that might be claimed to Comak, Ferhat Karakoc, and Christer Holmberg for discussions around
pertain to the implementation or use of the technology described in this problem space.
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Authors' Addresses
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Jari Arkko
copyrights, patents or patent applications, or other proprietary Ericsson
rights that may cover technology that may be required to implement Jorvas 02420
this standard. Please address the information to the IETF at ietf- Finland
ipr@ietf.org.
Acknowledgement Email: jari.arkko@piuha.net
Funding for the RFC Editor function is currently provided by the Vesa Lehtovirta
Internet Society. Ericsson
Jorvas 02420
Finland
Email: vesa.lehtovirta@ericsson.com
 End of changes. 57 change blocks. 
168 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/