draft-arkko-eap-rfc5448bis-00.txt   draft-arkko-eap-rfc5448bis.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft V. Lehtovirta Internet-Draft V. Lehtovirta
Obsoletes: 5448 (if approved) Ericsson Obsoletes: 5448 (if approved) V. Torvinen
Intended status: Informational P. Eronen Intended status: Informational Ericsson
Expires: May 3, 2018 Nokia Expires: September 6, 2018 P. Eronen
October 30, 2017 Nokia
March 5, 2018
Improved Extensible Authentication Protocol Method for 3rd Generation Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA') Authentication and Key Agreement (EAP-AKA')
draft-arkko-eap-rfc5448bis-00 draft-arkko-eap-rfc5448bis-01
Abstract Abstract
This specification defines a new EAP method, EAP-AKA', a small This specification defines a new EAP method, EAP-AKA', a small
revision of the EAP-AKA method. The change is a new key derivation revision of the EAP-AKA method. The change is a new key derivation
function that binds the keys derived within the method to the name of function that binds the keys derived within the method to the name of
the access network. The new key derivation mechanism has been the access network. The new key derivation mechanism has been
defined in the 3rd Generation Partnership Project (3GPP). This defined in the 3rd Generation Partnership Project (3GPP). This
specification allows its use in EAP in an interoperable manner. In specification allows its use in EAP in an interoperable manner. In
addition, EAP-AKA' employs SHA-256 instead of SHA-1. addition, EAP-AKA' employs SHA-256 instead of SHA-1.
skipping to change at page 1, line 46 skipping to change at page 1, line 47
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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 6 3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 7
3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 11 3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 11
3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 13 3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 13 3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 14
4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 14 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Identifier Usage in 5G . . . . . . . . . . . . . . . . . . . 16
5.1. Security Properties of Binding Network Names . . . . . . 18 5.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 17
6.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 19 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 18
6.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.3. Key Derivation Function Namespace . . . . . . . . . . . . 20 7.1. Security Properties of Binding Network Names . . . . . . 21
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. Importance of Explicit Negotiation . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 26
Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 26
Appendix C. Importance of Explicit Negotiation . . . . . . . . . 26
Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This specification defines a new Extensible Authentication Protocol This specification defines a new Extensible Authentication Protocol
(EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA
method originally defined in [RFC4187]. What is new in EAP-AKA' is method originally defined in [RFC4187]. What is new in EAP-AKA' is
that it has a new key derivation function, specified in that it has a new key derivation function, specified in
[TS-3GPP.33.402]. This function binds the keys derived within the [TS-3GPP.33.402]. This function binds the keys derived within the
method to the name of the access network. This limits the effects of method to the name of the access network. This limits the effects of
compromised access network nodes and keys. This specification compromised access network nodes and keys. This specification
skipping to change at page 3, line 45 skipping to change at page 3, line 45
function to SHA-256 [FIPS.180-2.2002]. But it is otherwise function to SHA-256 [FIPS.180-2.2002]. But it is otherwise
equivalent to RFC 4187. Given that a different EAP method type value equivalent to RFC 4187. Given that a different EAP method type value
is used for EAP-AKA and EAP-AKA', a mutually supported method may be is used for EAP-AKA and EAP-AKA', a mutually supported method may be
negotiated using the standard mechanisms in EAP [RFC3748]. negotiated using the standard mechanisms in EAP [RFC3748].
Note: Appendix C explains why it is important to be explicit about Note: Appendix C explains why it is important to be explicit about
the change of semantics for the keys, and why other approaches the change of semantics for the keys, and why other approaches
would lead to severe interoperability problems. would lead to severe interoperability problems.
This version of the EAP-AKA' specification is an update to RFC 5448. This version of the EAP-AKA' specification is an update to RFC 5448.
The update is to the reference on how the Network Name field is The update consists of three things:
constructed in the protocol. The update helps ensure that EAP-AKA'
becomes compatible with 5G deployments as well. RFC 5448 referred to
the 2008 version of that reference ([TS-3GPP.24.302]) and this update
points to the 5G version of that reference.
Arguably, the update is small, as the 3GPP specification number for o Update the reference on how the Network Name field is constructed
the updated calculation has not changed, only the version. But this in the protocol. The update helps ensure that EAP-AKA' becomes
reference is crucial in correct calculation of the keys resulting compatible with 5G deployments as well. RFC 5448 referred to the
from running the EAP-AKA' method, so an update of the RFC with the 2008 version of that reference ([TS-3GPP.24.302]) and this update
newest version pointer may be warranted. As always, feedback is points to the 5G version of that reference.
welcome on that point as well as on any other topic within this
document. o Specify how EAP and EAP-AKA' use identifiers in 5G, as additional
identifiers are introduced, and for interoperability, it is
important that implementations use the right ones.
o Specify session identifiers and other exported parameters, as
those were not specified in [RFC5448] despite requirements set
forward in [RFC5247] to do so. Also, while [RFC5247] specified
session identifiers for EAP-AKA, it only did so for the full
authentication case, not for the case of fast re-authentication.
Arguably, the updates are small. For the first update, the 3GPP
specification number for the updated calculation has not changed,
only the version. But this reference is crucial in correct
calculation of the keys resulting from running the EAP-AKA' method,
so an update of the RFC with the newest version pointer may be
warranted. As always, feedback is welcome on that point as well as
on any other topic within this document.
Note: It is an open issue whether this update should refer to only Note: It is an open issue whether this update should refer to only
the 5G version of the definition, or be explicit that any further the 5G version of the definition, or be explicit that any further
update of that specification is something that EAP-AKA' update of that specification is something that EAP-AKA'
implementations should take into account. Note that one should implementations should take into account. Note that one should
keep in mind that specification being automatically updated is keep in mind that specification being automatically updated is
different from implementations taking notice of new things. different from implementations taking notice of new things.
The second update is needed to ensure that implementations use the
correct identifiers in the context of 5G, as it introduces additional
privacy-protected identifiers, and it is no longer clear which
identifiers are used in EAP-AKA'.
The third update is necessary in order to fix a problem in previous
RFCs.
It is an explicit non-goal of this draft to include any other It is an explicit non-goal of this draft to include any other
technical modifications, addition of new features or other changes. technical modifications, addition of new features or other changes.
The EAP-AKA' base protocol is stable and needs to stay that way. If The EAP-AKA' base protocol is stable and needs to stay that way. If
there are any extensions or variants, those need to be proposed as there are any extensions or variants, those need to be proposed as
standalone extensions or even as different authentication methods. standalone extensions or even as different authentication methods.
The rest of this specification is structured as follows. Section 3 The rest of this specification is structured as follows. Section 3
defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to
prevent bidding down attacks from EAP-AKA'. Section 5 explains the prevent bidding down attacks from EAP-AKA'. Section 7 explains the
security differences between EAP-AKA and EAP-AKA'. Section 6 security differences between EAP-AKA and EAP-AKA'. Section 8
describes the IANA considerations and Appendix A and Appendix B describes the IANA considerations and Appendix A and Appendix B
explains what updates to RFC 5448 AKA' and RFC 4187 EAP-AKA have been explains what updates to RFC 5448 AKA' and RFC 4187 EAP-AKA have been
made in this specification. Appendix C explains some of the design made in this specification. Appendix C explains some of the design
rationale for creating EAP-AKA' Finally, Appendix D provides test rationale for creating EAP-AKA' Finally, Appendix D provides test
vectors. vectors.
Editor's Note: The publication of this RFC depends on its Editor's Note: The publication of this RFC depends on its
normative references [TS-3GPP.24.302] and [TS-3GPP.33.501] from normative references [TS-3GPP.24.302] and [TS-3GPP.33.501] from
3GPP reaching their final Release 15 status at 3GPP. This is 3GPP reaching their final Release 15 status at 3GPP. This is
expected to happen shortly. The RFC Editor should check with the expected to happen shortly. The RFC Editor should check with the
skipping to change at page 14, line 35 skipping to change at page 14, line 51
negotiated via EAP. negotiated via EAP.
In order to prevent such attacks, this RFC specifies a new mechanism In order to prevent such attacks, this RFC specifies a new mechanism
for EAP-AKA that allows the endpoints to securely discover the for EAP-AKA that allows the endpoints to securely discover the
capabilities of each other. This mechanism comes in the form of the capabilities of each other. This mechanism comes in the form of the
AT_BIDDING attribute. This allows both endpoints to communicate AT_BIDDING attribute. This allows both endpoints to communicate
their desire and support for EAP-AKA' when exchanging EAP-AKA their desire and support for EAP-AKA' when exchanging EAP-AKA
messages. This attribute is not included in EAP-AKA' messages as messages. This attribute is not included in EAP-AKA' messages as
defined in this RFC. It is only included in EAP-AKA messages. This defined in this RFC. It is only included in EAP-AKA messages. This
is based on the assumption that EAP-AKA' is always preferable (see is based on the assumption that EAP-AKA' is always preferable (see
Section 5). If during the EAP-AKA authentication process it is Section 7). If during the EAP-AKA authentication process it is
discovered that both endpoints would have been able to use EAP-AKA', discovered that both endpoints would have been able to use EAP-AKA',
the authentication process SHOULD be aborted, as a bidding down the authentication process SHOULD be aborted, as a bidding down
attack may have happened. attack may have happened.
The format of the AT_BIDDING attribute is shown below. The format of the AT_BIDDING attribute is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_BIDDING | Length |D| Reserved | | AT_BIDDING | Length |D| Reserved |
skipping to change at page 15, line 30 skipping to change at page 15, line 46
The server sends this attribute in the EAP-Request/AKA-Challenge The server sends this attribute in the EAP-Request/AKA-Challenge
message. If the peer supports EAP-AKA', it compares the received message. If the peer supports EAP-AKA', it compares the received
value to its own capabilities. If it turns out that both the server value to its own capabilities. If it turns out that both the server
and peer would have been able to use EAP-AKA' and preferred it over and peer would have been able to use EAP-AKA' and preferred it over
EAP-AKA, the peer behaves as if AUTN had been incorrect and fails the EAP-AKA, the peer behaves as if AUTN had been incorrect and fails the
authentication (see Figure 3 of [RFC4187]). A peer not supporting authentication (see Figure 3 of [RFC4187]). A peer not supporting
EAP-AKA' will simply ignore this attribute. In all cases, the EAP-AKA' will simply ignore this attribute. In all cases, the
attribute is protected by the integrity mechanisms of EAP-AKA, so it attribute is protected by the integrity mechanisms of EAP-AKA, so it
cannot be removed by a man-in-the-middle attacker. cannot be removed by a man-in-the-middle attacker.
Note that we assume (Section 5) that EAP-AKA' is always stronger than Note that we assume (Section 7) that EAP-AKA' is always stronger than
EAP-AKA. As a result, there is no need to prevent bidding "down" EAP-AKA. As a result, there is no need to prevent bidding "down"
attacks in the other direction, i.e., attackers forcing the endpoints attacks in the other direction, i.e., attackers forcing the endpoints
to use EAP-AKA'. to use EAP-AKA'.
5. Security Considerations 5. Identifier Usage in 5G
In EAP-AKA', the peer identity may be communicated to the server in
one of three ways:
o As a part of link layer establishment procedures, externally to
EAP.
o With the EAP-Response/Identity message in the beginning of the EAP
exchange, but before the selection of EAP-AKA'.
o Transmitted from the peer to the server using EAP-AKA messages
instead of EAP-Response/Identity. In this case, the server
includes an identity requesting attribute (AT_ANY_ID_REQ,
AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA-
Identity message; and the peer includes the AT_IDENTITY attribute,
which contains the peer's identity, in the EAP-Response/AKA-
Identity message.
The identity carried above may be a permanent identity or a pseudonym
identity or fast re-authentication identity as defined in this RFC.
In networks where EAP is the only part handling such pseudonym or
fast re-authentication identities, this usage is clear. However, 5G
supports the concept of pseudonym or privacy identifiers, and it is
important for interoperability that the right type of identifiers are
used in the right place.
5G defines the SUbscription Permanent Identifier (SUPI) and
SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501]
[TS-3GPP.33.501]. SUPI is globally unique and allocated to each
subscriber. However, it is only used internally in the 5G network,
and is privacy sensitive. The SUCI is a privacy preserving
identifier containing the concealed SUPI, using public key
cryptography to encrypt the SUPI.
Given the choice between these two types of identifiers, two areas
need further specification in EAP-AKA' to ensure that different
implementations understand each other and stay interoperable:
o Where identifiers are used within EAP-AKA' -- such as key
derivation -- specify what values exactly should be used, to avoid
ambiguity.
o Where identifiers are carried within EAP-AKA' packets -- such as
in the AT_IDENTITY attribute -- specify which identifiers should
be filled in.
In 5G, the normal mode of operation is that identifiers are only
transmitted outside EAP. However, in a system involving terminals
from many generations and several connectivity options via 5G and
other mechanisms, implementations and the EAP-AKA' specification need
to prepare for many different situations, including sometimes having
to communicate identities within EAP.
The following sections propose one way of clarifying which
identifiers are used and how. However, other answers are also
possible (e.g., always use the permanent identity). Further
discussion on this point is welcome!
5.1. Key Derivation
In EAP-AKA', the peer identity is used in the Section 3.3 key
derivation formula. The identity used in this formula MUST be
exactly the one sent in EAP-AKA' AT_IDENTITY attribute, if one was
sent, regardless of the kind of identity that it may have been. If
no AT_IDENTITY was sent, the identity MUST be the exactly the one
sent in the generic EAP Identity exchange, if one was made. Again,
the identity MUST be used exactly as sent.
Alternative specification: This could also require that the SUPI
identity be always used, regardless of what identity was sent.
If no identity was communicated inside EAP, then the identity is the
one communicated outside EAP in link layer messaging.
In this case, the used identity MUST be the identity most recently
communicated by the peer to the network, again regardless of what
type of identity it may have been.
5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute
The EAP authentication option is only available in 5G when the new 5G
core network is also in use. However, in other networks an EAP-AKA'
peer may be connecting to other types of networks and existing
equipment.
When the EAP peer is connecting to a 5G access network and uses the
5G core network signalling mechanisms, it MUST assume that the EAP
server is in a 5G network. In that situation, the EAP peer SHOULD
employ only the privacy preserving SUCI identifier within EAP (either
in EAP Identity Response or EAP-AKA' AT_IDENTITY attribute).
Similarly, if the peer is explicitly communicating through mechanisms
developed for 5G to connect to 5G networks over WLAN, it MUST assume
that the EAP server is in a 5G network, and again employ the SUCI
within EAP.
Otherwise, the peer SHOULD employ IMSI or SUPI as it is configured to
use.
The use of fast re-authentication and pseudonym identifiers in 5G or
other networks is for further discussion. Discussion of this topic
is again welcome!
6. Exported Parameters
The EAP-AKA' Session-Id is the concatenation of the EAP Type Code
(50, one octet) with the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the AUTN field in the AT_AUTN
attribute:
Session-Id = 50 || RAND || AUTN
When using fast re-authentication, the EAP-AKA' Session-Id is the
concatenation of the EAP Type Code (50) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from EAP-Request/AKA-
Reauthentication:
Session-Id = 50 || NONCE_S || MAC
The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning. Note that the contents are used as they are
transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast EAP re-authentication identity. The
Server-Id is the null string (zero length).
7. Security Considerations
A summary of the security properties of EAP-AKA' follows. These A summary of the security properties of EAP-AKA' follows. These
properties are very similar to those in EAP-AKA. We assume that properties are very similar to those in EAP-AKA. We assume that
SHA-256 is at least as secure as SHA-1. This is called the SHA-256 SHA-256 is at least as secure as SHA-1. This is called the SHA-256
assumption in the remainder of this section. Under this assumption, assumption in the remainder of this section. Under this assumption,
EAP-AKA' is at least as secure as EAP-AKA. EAP-AKA' is at least as secure as EAP-AKA.
If the AT_KDF attribute has value 1, then the security properties of If the AT_KDF attribute has value 1, then the security properties of
EAP-AKA' are as follows: EAP-AKA' are as follows:
skipping to change at page 17, line 16 skipping to change at page 20, line 12
K_aut, K_re), the MSK, and the EMSK are cryptographically K_aut, K_re), the MSK, and the EMSK are cryptographically
separate. If we make the assumption that SHA-256 behaves as a separate. If we make the assumption that SHA-256 behaves as a
pseudo-random function, an attacker is incapable of deriving any pseudo-random function, an attacker is incapable of deriving any
non-trivial information about any of these keys based on the other non-trivial information about any of these keys based on the other
keys. An attacker also cannot calculate the pre-shared secret keys. An attacker also cannot calculate the pre-shared secret
from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any
practically feasible means. practically feasible means.
EAP-AKA' adds an additional layer of key derivation functions EAP-AKA' adds an additional layer of key derivation functions
within itself to protect against the use of compromised keys. within itself to protect against the use of compromised keys.
This is discussed further in Section 5.1. This is discussed further in Section 7.1.
EAP-AKA' uses a pseudo-random function modeled after the one used EAP-AKA' uses a pseudo-random function modeled after the one used
in IKEv2 [RFC4306] together with SHA-256. in IKEv2 [RFC4306] together with SHA-256.
Key strength Key strength
See above. See above.
Dictionary attack resistance Dictionary attack resistance
skipping to change at page 18, line 28 skipping to change at page 21, line 22
attributes can be used to add channel binding support in the attributes can be used to add channel binding support in the
future, if required. future, if required.
However, including the Network Name field in the AKA' algorithms However, including the Network Name field in the AKA' algorithms
(which are also used for other purposes than EAP-AKA') provides a (which are also used for other purposes than EAP-AKA') provides a
form of cryptographic separation between different network names, form of cryptographic separation between different network names,
which resembles channel bindings. However, the network name does which resembles channel bindings. However, the network name does
not typically identify the EAP (pass-through) authenticator. See not typically identify the EAP (pass-through) authenticator. See
the following section for more discussion. the following section for more discussion.
5.1. Security Properties of Binding Network Names 7.1. Security Properties of Binding Network Names
The ability of EAP-AKA' to bind the network name into the used keys The ability of EAP-AKA' to bind the network name into the used keys
provides some additional protection against key leakage to provides some additional protection against key leakage to
inappropriate parties. The keys used in the protocol are specific to inappropriate parties. The keys used in the protocol are specific to
a particular network name. If key leakage occurs due to an accident, a particular network name. If key leakage occurs due to an accident,
access node compromise, or another attack, the leaked keys are only access node compromise, or another attack, the leaked keys are only
useful when providing access with that name. For instance, a useful when providing access with that name. For instance, a
malicious access point cannot claim to be network Y if it has stolen malicious access point cannot claim to be network Y if it has stolen
keys from network X. Obviously, if an access point is compromised, keys from network X. Obviously, if an access point is compromised,
the malicious node can still represent the compromised node. As a the malicious node can still represent the compromised node. As a
skipping to change at page 19, line 35 skipping to change at page 22, line 29
obviously on the way names are assigned to different access networks. obviously on the way names are assigned to different access networks.
This is specified in [TS-3GPP.24.302]. See also [TS-3GPP.23.003]. This is specified in [TS-3GPP.24.302]. See also [TS-3GPP.23.003].
Ideally, the names allow separating each different access technology, Ideally, the names allow separating each different access technology,
each different access network, and each different NAS within a each different access network, and each different NAS within a
domain. If this is not possible, the full benefits may not be domain. If this is not possible, the full benefits may not be
achieved. For instance, if the names identify just an access achieved. For instance, if the names identify just an access
technology, use of compromised keys in a different technology can be technology, use of compromised keys in a different technology can be
prevented, but it is not possible to prevent their use by other prevented, but it is not possible to prevent their use by other
domains or devices using the same technology. domains or devices using the same technology.
6. IANA Considerations 8. IANA Considerations
6.1. Type Value 8.1. Type Value
EAP-AKA' has the EAP Type value 50 in the Extensible Authentication EAP-AKA' has the EAP Type value 50 in the Extensible Authentication
Protocol (EAP) Registry under Method Types. Per Section 6.2 of Protocol (EAP) Registry under Method Types. Per Section 6.2 of
[RFC3748], this allocation can be made with Designated Expert and [RFC3748], this allocation can be made with Designated Expert and
Specification Required. Specification Required.
6.2. Attribute Type Values 8.2. Attribute Type Values
EAP-AKA' shares its attribute space and subtypes with EAP-SIM EAP-AKA' shares its attribute space and subtypes with EAP-SIM
[RFC4186] and EAP-AKA [RFC4187]. No new registries are needed. [RFC4186] and EAP-AKA [RFC4187]. No new registries are needed.
However, a new Attribute Type value (23) in the non-skippable range However, a new Attribute Type value (23) in the non-skippable range
has been assigned for AT_KDF_INPUT (Section 3.1) in the EAP-AKA and has been assigned for AT_KDF_INPUT (Section 3.1) in the EAP-AKA and
EAP-SIM Parameters registry under Attribute Types. EAP-SIM Parameters registry under Attribute Types.
Also, a new Attribute Type value (24) in the non-skippable range has Also, a new Attribute Type value (24) in the non-skippable range has
been assigned for AT_KDF (Section 3.2). been assigned for AT_KDF (Section 3.2).
Finally, a new Attribute Type value (136) in the skippable range has Finally, a new Attribute Type value (136) in the skippable range has
been assigned for AT_BIDDING (Section 4). been assigned for AT_BIDDING (Section 4).
6.3. Key Derivation Function Namespace 8.3. Key Derivation Function Namespace
IANA has also created a new namespace for EAP-AKA' AT_KDF Key IANA has also created a new namespace for EAP-AKA' AT_KDF Key
Derivation Function Values. This namespace exists under the EAP-AKA Derivation Function Values. This namespace exists under the EAP-AKA
and EAP-SIM Parameters registry. The initial contents of this and EAP-SIM Parameters registry. The initial contents of this
namespace are given below; new values can be created through the namespace are given below; new values can be created through the
Specification Required policy [RFC5226]. Specification Required policy [RFC5226].
Value Description Reference Value Description Reference
--------- ---------------------- --------------- --------- ---------------------- ---------------
0 Reserved [RFC 5448] 0 Reserved [RFC 5448]
1 EAP-AKA' with CK'/IK' [RFC 5448] 1 EAP-AKA' with CK'/IK' [RFC 5448]
2-65535 Unassigned 2-65535 Unassigned
7. Contributors 9. Contributors
The test vectors in Appendix C were provided by Yogendra Pal and The test vectors in Appendix C were provided by Yogendra Pal and
Jouni Malinen, based on two independent implementations of this Jouni Malinen, based on two independent implementations of this
specification. specification.
8. Acknowledgments Jouni Malinen provided suggested text for Section 6.
10. Acknowledgments
The authors would like to thank Guenther Horn, Joe Salowey, Mats The authors would like to thank Guenther Horn, Joe Salowey, Mats
Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad
Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni
Malinen, Brian Weis, Russ Housley, Alfred Hoenes, Vesa Torvinen, and Malinen, Brian Weis, Russ Housley, Alfred Hoenes, Vesa Torvinen,
Mohit Sethi for their in-depth reviews and interesting discussions in Anand Palanigounder, and Mohit Sethi for their in-depth reviews and
this problem space. interesting discussions in this problem space.
9. References 11. References
9.1. Normative References 11.1. Normative References
[TS-3GPP.23.501]
3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G
Security; Security architecture and procedures for 5G
System; (Release 15)", 3GPP Technical Specification
23.501, December 2017.
[TS-3GPP.24.302] [TS-3GPP.24.302]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Access to Specification Group Core Network and Terminals; Access to
the 3GPP Evolved Packet Core (EPC) via non-3GPP access the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3; (Release 15)", 3GPP Draft Technical networks; Stage 3; (Release 15)", 3GPP Draft Technical
Specification 24.302, September 2017. Specification 24.302, September 2017.
[TS-3GPP.33.102] [TS-3GPP.33.102]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
skipping to change at page 22, line 5 skipping to change at page 25, line 5
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
January 2006, <https://www.rfc-editor.org/info/rfc4187>. January 2006, <https://www.rfc-editor.org/info/rfc4187>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, DOI IANA Considerations Section in RFCs", RFC 5226, DOI
10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/ 10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/
info/rfc5226>. info/rfc5226>.
9.2. Informative References 11.2. Informative References
[TS-3GPP.23.003] [TS-3GPP.23.003]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Numbering, Specification Group Core Network and Terminals; Numbering,
addressing and identification (Release 8)", 3GPP Technical addressing and identification (Release 8)", 3GPP Technical
Specification 23.003, December 2008. Specification 23.003, December 2008.
[TS-3GPP.35.208] [TS-3GPP.35.208]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
skipping to change at page 23, line 5 skipping to change at page 26, line 5
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari,
"Network Discovery and Selection Problem", RFC 5113, DOI "Network Discovery and Selection Problem", RFC 5113, DOI
10.17487/RFC5113, January 2008, <https://www.rfc- 10.17487/RFC5113, January 2008, <https://www.rfc-
editor.org/info/rfc5113>. editor.org/info/rfc5113>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008, <https://www RFC 5247, DOI 10.17487/RFC5247, August 2008, <https://www
.rfc-editor.org/info/rfc5247>. .rfc-editor.org/info/rfc5247>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009, <https://www
.rfc-editor.org/info/rfc5448>.
Appendix A. Changes from RFC 5448 Appendix A. Changes from RFC 5448
The changes consist solely of referring to a newer version of The changes consist first of all, referring to a newer version of
[TS-3GPP.24.302]. The new version includes an updated definition of [TS-3GPP.24.302]. The new version includes an updated definition of
the Network Name field, to include 5G. the Network Name field, to include 5G.
Secondly, identifier usage for 5G has been specified in Section 5.
Thirdly, exported parameters for EAP-AKA' have been defined in
Section 6, as required by [RFC5247], including the definition of
those parameters for both full authentication and fast re-
authentication.
Appendix B. Changes from RFC 4187 to RFC 5448 Appendix B. Changes from RFC 4187 to RFC 5448
The changes to RFC 4187 relate only to the bidding down prevention The changes to RFC 4187 relate only to the bidding down prevention
support defined in Section 4. In particular, this document does not support defined in Section 4. In particular, this document does not
change how the Master Key (MK) is calculated in RFC 4187 (it uses CK change how the Master Key (MK) is calculated in RFC 4187 (it uses CK
and IK, not CK' and IK'); neither is any processing of the AMF bit and IK, not CK' and IK'); neither is any processing of the AMF bit
added to RFC 4187. added to RFC 4187.
Appendix C. Importance of Explicit Negotiation Appendix C. Importance of Explicit Negotiation
skipping to change at page 28, line 18 skipping to change at page 31, line 26
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Vesa Lehtovirta Vesa Lehtovirta
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: vesa.lehtovirta@ericsson.com Email: vesa.lehtovirta@ericsson.com
Vesa Torvinen
Ericsson
Jorvas 02420
Finland
Email: vesa.torvinen@ericsson.com
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com Email: pasi.eronen@nokia.com
 End of changes. 30 change blocks. 
59 lines changed or deleted 243 lines changed or added

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