One document matched: draft-arkko-eap-aka-kdf-00.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="full3978" iprnotified="yes" docName="draft-arkko-eap-aka-kdf-00" category="info" updates="4187">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="EAP-AKA'">Improved Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA')</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials='V.' surname="Lehtovirta" fullname='Vesa Lehtovirta'>
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>vesa.lehtovirta@ericsson.com</email>
</address>
</author>
<author initials='P.' surname="Eronen" fullname='Pasi Eronen'>
<organization abbrev='Nokia'>Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<city>FIN-00045 Nokia Group</city>
<country>Finland</country>
</postal>
<email>pasi.eronen@nokia.com</email>
</address>
</author>
<date month="July" year="2008" />
<keyword>EAP</keyword>
<keyword>AKA</keyword>
<keyword>AKA'</keyword>
<keyword>3GPP</keyword>
<abstract>
<t>This specification defines a new EAP method, EAP-AKA', a small
revision of the EAP-AKA method. The change is a new key derivation
function that binds the name of the access network to the keys derived
within the method. As a result, it becomes possible to authenticate
the network name. The new key derivation mechanism has been defined in
3GPP. This specification allows its use in EAP in an interoperable
manner.</t>
<t>This specification also updates RFC 4187 EAP-AKA to add support for
preventing bidding down attacks between itself and EAP-AKA'.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This specification defines a new Extensible Authentication Protocol
(EAP)<xref target="RFC3748"/> method, EAP-AKA', a small revision of
the EAP-AKA method originally defined in
<xref target="RFC4187"/>. What is new in EAP-AKA' is that it has a new
key derivation function specified in <xref target="3GPP.33.402"/>. This
function binds the name of the access network to the keys derived
within the method. As a result, it becomes possible to authenticate
the network name, limiting the effects of compromised nodes and
keys. This specification defines the EAP encapsulation for AKA when
the new key derivation mechanism is in use.</t>
<t>3GPP has defined a number of applications for the revised AKA
mechanism, some based on native encapsulation of AKA over 3GPP radio
access networks and others based on the use of EAP.</t>
<t>For making the new key derivation mechanisms usable in EAP-AKA
additional protocol mechanisms are necessary. Given that RFC 4187
calls for the use of CK (the encryption key) and IK (the integrity
key) from AKA directly, existing implementations continue to use
these. Any change of the key derivation must be unambiguous to both
sides in the protocol. That is, it must not be possible to
accidentally connect old equipment to new equipment and get the key
derivation wrong or attempt to use wrong keys without getting a proper
error message.</t>
<t>This specification therefore introduces a variant of the EAP-AKA
method, called EAP-AKA'. This method can employ the derived keys CK'
and IK' from the 3GPP specification but it is otherwise 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 negotiated
using the standard mechanisms in EAP <xref target="RFC3748"/>.
<list style="empty">
<t>Editor's Note: A number of other possible ways to use the new key
derivation functions have been proposed. These include configuration
and reliance on a particular domain employing only the new
functions. <xref target="baddesign"/> explains why these approaches
lead to severe interoperability problems and why it is important to be
explicit about the change of semantics in protocol design.</t>
</list></t>
<t>The rest of this specification is structured as
follows. <xref target="prime"/> defines the EAP-AKA'
method. <xref target="bidding"/> adds support to EAP-AKA
to prevent bidding down attacks from EAP-AKA'. <xref target="security"/>
explains the security differences between EAP-AKA and
EAP-AKA'. <xref target="iana"/> describes the IANA considerations and
<xref target="diff"/> explains what updates to RFC 4187 EAP-AKA have
been made in this specification.</t>
</section>
<section anchor="prime" title="EAP-AKA'">
<t>EAP-AKA' is a new EAP method that follows EAP-AKA specification
<xref target="RFC4187"/> in all other respects except the following:
<list style="symbols">
<t>It uses the Type code TBD1 BY IANA, not 23 which is used by
EAP-AKA.</t>
<t>It carries the AT_KDF_INPUT attribute, as defined in
<xref target="netbind"/> to ensure that both parties know the name of
the access network.</t>
<t>It calculates the Master Key (MK) as defined in
<xref target="key"/>, not as defined in EAP-AKA.</t>
<t>It uses the optional AT_KDF attribute as defined in
<xref target="keyderiv"/> to control possible future key derivation
function changes.</t>
</list>
</t>
<t>Figure 1 shows an example of the authentication process. Each
message AKA'-Challenge and so on represents the corresponding message
from EAP-AKA, but with EAP-AKA' Type code. The definition of these
messages, along with the definition of attributes AT_RAND, AT_AUTN,
AT_MAC, and AT_RES can be found from <xref target="RFC4187"/>.</t>
<figure>
<artwork>
Peer Server
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +-------------------------------+
| | Server runs AKA' algorithms, |
| | generates AT_RAND and AT_AUTN.|
| | For creating AT_MAC, the |
| | server employs CK' and IK'. |
| +-------------------------------+
| EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF_INPUT, AT_MAC)|
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA' algorithms, | |
| verifies AT_AUTN and AT_MAC, derives| |
| AT_RES and session keys. Again, for | |
| verifying AT_MAC and creating | |
| AT_RES, the peer uses CK' and IK' | |
+-------------------------------------+ |
| EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server checks the given AT_RES,|
| | and MAC and finds them correct.|
| +--------------------------------+
| EAP-Success |
|<------------------------------------------------------|
Figure 1: EAP-AKA' Authentication Process
</artwork>
</figure>
<section title="The AT_KDF_INPUT Attribute" anchor="netbind">
<t>The format of the AT_KDF_INPUT attribute is shown below.</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_INPUT | Length | Actual Network Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Network Name .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields are as follows:</t>
<t><list style="hanging">
<t hangText="AT_KDF_INPUT"><vspace blankLines="1"/>This is set to TBD2 BY
IANA.</t>
<t hangText="Length"><vspace blankLines="1"/>The length of the
attribute, calculated as defined in <xref target="RFC4187"/> Section
8.1.</t>
<t hangText="Actual Network Name Length"><vspace blankLines="1"/>This a
2-byte actual length field, needed due to the requirement that
previous field is expressed in multiples of 4 bytes per the usual
EAP-SIM and EAP rules. The Actual Network Name Length field provides the
length of the Network Name in bytes.</t>
<t hangText="Network Name"><vspace blankLines="1"/>This field contains
the network name of the access network for which the authentication is
being performed. The name does not include any terminating null
characters. Because the length of the entire attribute must be a
multiple of 4 bytes, the sender pads the name with zero bytes when
necessary.
</t>
</list></t>
<t>Only the server sends the AT_KDF_INPUT attribute. The peer SHOULD
check the received value against its own understanding of the network
name. Upon detecting a discrepancy, the peer MAY either log an
error and continue, or fail the authentication process.</t>
<t>The Network Name field contains an octet string. This string MUST
be constructed as specified in <xref target="3GPP.23.003"/>. For
network types where this reference does not provide an instruction on
how to construct the name, the empty octet string SHOULD be used.
<list style="empty">
<t>Editor's Note: This 3GPP specification is still being worked on.
It is assumed that the specification ensures that conflicts
potentially arising from using the same name in different types of
networks are avoided. It is also assumed that the 3GPP specification
will have detailed rules about how a client can determine these based
on information available to the client, such as the type of protocol
used to attach to the network, beacons sent out by the network, and so
on. Information that the client cannot directly observe (such as the
type or version of the home network) should not be used by this
algorithm.</t>
</list></t>
</section>
<section anchor="keyderiv" title="AT_KDF">
<t>AT_KDF is an optional attribute that the server MAY use when
it wishes to employ a specific key derivation function. This is useful
for future evolution of the key derivation functions.</t>
<t>The format of the AT_KDF attribute is shown below.</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF | Length | Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields are as follows:</t>
<t><list style="hanging">
<t hangText="AT_KDF"><vspace blankLines="1"/>This is set to TBD3 BY
IANA.</t>
<t hangText="Length"><vspace blankLines="1"/>The length of the
attribute, MUST be set to 1.</t>
<t hangText="Key Derivation Function"><vspace blankLines="1"/>An
enumerated value representing the key derivation function that the
server (or peer) wishes to use. Value 1 represents RFC 4187 key
derivation, i.e., fallback to EAP-AKA functionality. Value 2
represents the default key derivation function for EAP-AKA', i.e.,
employing CK' and IK' as defined in <xref target="key"/>.</t>
</list></t>
<t>Servers MAY choose to send one or more AT_KDF attributes
in the EAP-Request/AKA'-Challenge message. The first of these
attributes represents the desired function and the other ones are
acceptable alternatives, the most desired alternative being the second
attribute.</t>
<t>Upon receiving this attribute, if the peer supports and is willing
to use the key derivation function indicated by the first attribute,
the function is taken into use and no further action is necessary.
However, if the peer does not support this function or is unwilling to
use it, it responds with the EAP-Response/AKA'-Challenge message that
contains only one attribute, AT_KDF with the value set to the
selected alternative. If there is no suitable alternative, the peer
behaves as if AT_MAC had been incorrect and authentication fails.</t>
<t>Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from
the peer, the server checks that the alternative was in its offer. If
not, it behaves as if AT_MAC of the response had been incorrect and
fails the authentication. Otherwise, the server re-sends the
EAP-Response/AKA'-Challenge message, but moves the selected
alternative to the beginning of the list of AT_KDF
attributes.</t>
<t>When the peer receives the new EAP-Request/AKA'-Challenge message,
it MUST check that requested change, and only the requested change
occurred in the list of AT_KDF attributes. If yes, it continues.
If not, it behaves as if AT_MAC had been incorrect and fails the
authentication.</t>
</section>
<section anchor="key" title="Key Generation">
<t>Both the peer and server MUST derive the Master Key (MK) from
underlying AKA values and the identity, as follows.
<list style="hanging">
<t hangText="AT_KDF set to 1"><vspace blankLines="1"/>
MK is as defined in <xref target="RFC4187"/>.</t>
<t hangText="AT_KDF not present or set to
2"><vspace blankLines="1"/>
MK is as follows:<vspace blankLines="1"/>
<list style="empty"><t>MK = SHA1(Identity|IK'|CK')</t></list>
Here SHA1 and Identity are as specified in <xref target="RFC4187"/>
and IK' and CK' are derived as specified in
<xref target="3GPP.33.402"/>. The functions that derive IK' and CK'
take the following parameters: CK and IK produced by the AKA algorithm
and value of the Network Name field (without length or padding) from
AT_KDF_INPUT as the access network identity.</t>
<t hangText="AT_KDF is present and has any other
value"><vspace blankLines="1"/>
Future variations of key derivation functions may be defined, and they
will be represented by new values of AT_KDF. If the peer does not
recognize the value it cannot calculate the keys and behaves as
explained in <xref target="keyderiv"/>.</t>
</list></t>
<t>If the peer supports a given key derivation function but is
unwilling to perform it for policy reasons, it refuses to calculate
the keys and behaves as explained in <xref target="keyderiv"/>.</t>
</section>
<section title="Hash Function Update">
<t>Given that we are defining a new method, it would potentially be a
convenient time to introduce a change of the hash functions from those
used in EAP-AKA (SHA1) to SHA256 which is used in new 3GPP
systems. Would this be desirable?</t>
</section>
</section>
<section anchor="bidding" title="Bidding Down Prevention for EAP-AKA">
<t>As discussed in <xref target="RFC3748"/>, negotiation of methods
within EAP is insecure. That is, a man-in-the-middle attacker may
force the endpoints to use a method that is not the strongest one they
both support. This is a problem, as we expect EAP-AKA and EAP-AKA' to
be negotiated via EAP.</t>
<t>In order to prevent such attacks, this specification specifies a
new mechanism for EAP-AKA that allows the endpoints to securely
discover the capabilities of each other. This mechanism comes in the
form of the AT_BIDDING attribute. This allows both endpoints to
communicate their desire and support for EAP-AKA' when exchanging
EAP-AKA messages. This attribute is not included in EAP-AKA' messages
as defined in this RFC. If during the authentication process it is
discovered that both endpoints would have been able to use EAP-AKA',
the authentication process SHOULD be aborted, as a bidding down attack
may have happened.</t>
<t>The format of the AT_BIDDING attribute is shown below.</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_BIDDING | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields are as follows:</t>
<t><list style="hanging">
<t hangText="AT_BIDDING"><vspace blankLines="1"/>This is set to TBD4 BY
IANA.</t>
<t hangText="Length"><vspace blankLines="1"/>The length of the
attribute, MUST be set to 1.</t>
<t hangText="D"><vspace blankLines="1"/>This bit is set to 1 if the
sender does support EAP-AKA', is willing to use it, and prefers it
over EAP-AKA. Otherwise it should be set to 0.</t>
<t hangText="Reserved"><vspace blankLines="1"/>This field MUST be set
to zero when sent and ignored on receipt.</t>
</list></t>
<t>The server sends this attribute in the EAP-Request/AKA-Challenge
message. The peer compares the received 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 EAP-AKA, the peer
behaves as if AT_MAC had been incorrect, and fails the
authentication.</t>
</section>
<section anchor="security" title='Security Considerations'>
<t>A summary of the security properties of EAP-AKA' follows. As there
has been only a minor change in the method, most of the security
properties are unchanged from EAP-AKA.
<list style="hanging">
<t hangText="Protected ciphersuite negotiation"><vspace blankLines="1"/>
The ciphersuite negotiation mechanisms of EAP-AKA are also present
in EAP-AKA'. Refer to <xref target="RFC4187"/> Section 12 for further
details. However, EAP-AKA' adds a new negotiation mechanism for
selecting the key derivation function that feeds CK' and IK' into MK.
This mechanism is secure against bidding down attacks.</t>
<t hangText="Mutual authentication"><vspace blankLines="1"/> The
properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to <xref target="RFC4187"/> Section 12 for further
details.</t>
<t hangText="Integrity protection"><vspace blankLines="1"/> The
properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to <xref target="RFC4187"/> Section 12 for further
details.</t>
<t hangText="Replay protection"><vspace blankLines="1"/> The
properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to <xref target="RFC4187"/> Section 12 for further
details.</t>
<t hangText="Confidentiality"><vspace blankLines="1"/> The properties
of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to
<xref target="RFC4187"/> Section 12 for further details.</t>
<t hangText="Key derivation"><vspace blankLines="1"/> The key
derivation mechanisms of EAP-AKA are also present in EAP-AKA'. Refer
to <xref target="RFC4187"/> Section 12 for further details. However,
EAP-AKA' adds an additional layer of key derivation functions within
itself. This does not affect the type of keys the method exports. However,
the additional functions make it harder to use compromised keys in a
different context.</t>
<t hangText="Key strength"><vspace blankLines="1"/> The properties of
EAP-AKA' are exactly as those of EAP-AKA in this respect, on the
assumption that key derivation functions do not change the strength of
the keys. This is currently the case with the functions defined in
<xref target="3GPP.33.402"/>. Refer to <xref target="RFC4187"/>
Section 12 for further details.</t>
<t hangText="Dictionary attack resistance"><vspace blankLines="1"/>
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to <xref target="RFC4187"/> Section 12 for further
details.</t>
<t hangText="Fast reconnect"><vspace blankLines="1"/> The properties
of EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to
<xref target="RFC4187"/> Section 12 for further details. Note that
implementations MUST prevent performing a fast reconnect across method
types.</t>
<t hangText="Cryptographic binding"><vspace blankLines="1"/> Note that
this term refers to a very specific form of binding, something that is
performed between two layers of authentication. It is not the same as
the binding to a particular network name. The properties of EAP-AKA'
are exactly as those of EAP-AKA in this respect, i.e., as it is not a
tunnel method this property is not applicable to it. Refer to
<xref target="RFC4187"/> Section 12 for further details.</t>
<t hangText="Session independence"><vspace blankLines="1"/> The
properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to <xref target="RFC4187"/> Section 12 for further
details.</t>
<t hangText="Fragmentation"><vspace blankLines="1"/> The properties of
EAP-AKA' are exactly as those of EAP-AKA in this respect. Refer to
<xref target="RFC4187"/> Section 12 for further details.</t>
<t hangText="Channel binding"><vspace blankLines="1"/> EAP-AKA' provides
a simple form of channel binding.</t>
</list></t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>EAP-AKA' has the EAP Type value TBD1 BY IANA. Per
<xref target="RFC3748"/> Section 6.2, this allocation can be made with
Designated Expert and Specification Required.</t>.
<t>EAP-AKA' shares its attribute space and message Subtypes, with
EAP-SIM <xref target="RFC4186"/> and EAP-AKA
<xref target="RFC4186"/>.</t>
<t>However, a new Attribute Type value (TBD2) in the non-skippable range
needs to be assigned for AT_KDF_INPUT (<xref target="netbind"/>).</t>
<t>Also, a new Attribute Type value (TBD3) in the non-skippable range
needs to be assigned for AT_KDF (<xref target="keyderiv"/>).
IANA also needs to create a
registry for EAP-AKA' KDF Type values. The initial contents of this
registry are given below; new values can be created through
Specification Required policy <xref target="RFC5226"/>.
<figure><artwork>
Value Description Reference
--------- ---------------------- ---------------
0 Reserved
1 EAP-AKA with CK/IK [this document]
2 EAP-AKA' with CK'/IK' [this document]
3-65535 Unassigned
</artwork></figure>
</t>
<t>Finally, a new Attribute Type value (TBD4) in the skippable range
needs to be assigned for AT_BIDDING (<xref target="bidding"/>).</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Guenther Horn, Joe Salowey, Mats
Naslund, and Stefan Rommer for interesting discussions in this problem
space.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3748.xml"?>
<?rfc include="reference.RFC.4187.xml"?>
<?rfc include="reference.RFC.5226.xml"?>
<?rfc include="reference.3GPP.23003.xml"?>
<?rfc include="reference.3GPP.33402.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4186.xml"?>
<?rfc include="reference.RFC.4284.xml"?>
<?rfc include="reference.RFC.5113.xml"?>
</references>
<section anchor="diff" title="Changes from RFC 4187">
<t>The changes to RFC 4187 relate only to the bidding down prevention
support defined <xref target="bidding"/>.</t>
</section>
<section anchor="baddesign" title="Importance of Explicit Negotiation">
<t>Choosing between the traditional and revised AKA key derivation
functions is easy when their use is unambiguously tied to a particular
radio access network, e.g LTE as defined by 3GPP or eHRPD as defined
by 3GPP2. There is no possibility for interoperability problems if
this radio access network is always used in conjunction with new
protocols that cannot be mixed with the old ones; clients will always
know whether they are connecting to the old or new system.</t>
<t>However, using the new key derivation functions over EAP introduces
several degrees of separation, making the choice of the correct key
derivation functions much harder. Many different types of networks
employ EAP. Most of these networks have no means to carry any
information about what is expected from the authentication process.
EAP itself is severely limited in carrying any additional information,
as noted in <xref target="RFC4284"/> <xref target="RFC5113"/>. Even if
these networks or EAP were extended to carry additional information,
it would not affect millions of deployed access networks and clients
attaching to them.</t>
<t>Simply changing the key derivation functions that EAP-AKA
<xref target="RFC4187"/> uses would cause interoperability problems
with all of the existing implementations. Perhaps it would be possible
to employ strict separation into domain names that should be used by
the new clients and networks. Only these new devices would then employ
the new key derivation mechanism. While this can be made to work for
specific cases, it would be an extremely brittle mechanism, ripe to
result in problems whenever client configuration, routing of
authentication requests, or server configuration does not match
expectations. It also does not help to assume that the EAP client and
server are running a particular release of 3GPP network
specifications. Network vendors often provide features from the future
releases early or do not provide all features of the current
release. And obviously, there are many EAP and even some EAP-AKA
implementations that are not bundled with the 3GPP network
offerings. In general, these approaches are expected to lead to
hard-to-diagnose problems and increased support calls.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:26:54 |