+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The
HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
truncating the output to 16 bytes. Hence, the length of the MAC is
16 bytes.) The derivation of the authentication key (K_aut) used in
the calculation of the MAC is specified in Section 7.
When the AT_MAC attribute is included in an EAP-AKA message, the
recipient MUST process the AT_MAC attribute before looking at any
other attributes, except when processing EAP-Request/AKA-Challenge.
The processing of EAP-Request/AKA-Challenge is specified in
Section 9.3. If the message authentication code is invalid, then the
recipient MUST ignore all other attributes in the message and operate
as specified in Section 6.3.
10.16. AT_COUNTER
The format of the AT_COUNTER attribute is shown below.
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_COUNTER | Length = 1 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT_COUNTER attribute consists of a 16-bit
unsigned integer counter value, represented in network byte order.
This attribute MUST always be encrypted by encapsulating it within
the AT_ENCR_DATA attribute.
10.17. AT_COUNTER_TOO_SMALL
The format of the AT_COUNTER_TOO_SMALL attribute is shown below.
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_COUNTER...| Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute consists of two reserved bytes,
which are set to zero upon sending and ignored upon reception. This
attribute MUST always be encrypted by encapsulating it within the
AT_ENCR_DATA attribute.
10.18. AT_NONCE_S
The format of the AT_NONCE_S attribute is shown below.
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_NONCE_S | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| NONCE_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT_NONCE_S attribute contains two reserved
bytes followed by a random number (16 bytes) that is freshly
generated by the server for this EAP-AKA fast re-authentication. The
random number is used as challenge for the peer and also as a seed
value for the new keying material. The reserved bytes are set to
zero upon sending and ignored upon reception. This attribute MUST
always be encrypted by encapsulating it within the AT_ENCR_DATA
attribute.
The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA
fast re-authentication exchange. The server SHOULD use a good source
of randomness to generate NONCE_S. Please see [RFC4086] for more
information about generating random numbers for security
applications.
10.19. AT_NOTIFICATION
The format of the AT_NOTIFICATION attribute is shown below.
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_NOTIFICATION| Length = 1 |S|P| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte notification
code. The first and second bit (S and P) of the notification code
are interpreted as described in Section 6.
The notification code values listed below have been reserved. The
descriptions below illustrate the semantics of the notifications.
The peer implementation MAY use different wordings when presenting
the notifications to the user. The "requested service" depends on
the environment where EAP-AKA is applied.
0 - General failure after authentication. (Implies failure, used
after successful authentication.)
16384 - General failure. (Implies failure, used before
authentication.)
32768 - Success. User has been successfully authenticated. (Does
not imply failure, used after successful authentication.) The usage
of this code is discussed in Section 6.2.
1026 - User has been temporarily denied access to the requested
service. (Implies failure, used after successful authentication.)
1031 - User has not subscribed to the requested service. (Implies
failure, used after successful authentication.)
10.20. AT_CLIENT_ERROR_CODE
The format of the AT_CLIENT_ERROR_CODE attribute is shown below.
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_CLIENT_ERR..| Length = 1 | Client Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte client error
code. The following error code values have been reserved.
0 "unable to process packet": a general error code
11. IANA and Protocol Numbering Considerations
IANA has assigned the EAP type number 23 for EAP-AKA authentication.
EAP-AKA shares most of the protocol design, such as attributes and
message Subtypes, with EAP-SIM [EAP-SIM]. EAP-AKA protocol numbers
should be administered in the same IANA registry with EAP-SIM. This
document establishes the registries and lists the initial protocol
numbers for both protocols.
EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is
a new numbering space for which IANA administration is required. The
Subtype is an 8-bit integer. The following Subtypes are specified in
this document and in [EAP-SIM]:
AKA-Challenge...................................1
AKA-Authentication-Reject.......................2
AKA-Synchronization-Failure.....................4
AKA-Identity....................................5
SIM-Start......................................10
SIM-Challenge..................................11
AKA-Notification and SIM-Notification..........12
AKA-Reauthentication and SIM-Reauthentication..13
AKA-Client-Error and SIM-Client-Error..........14
The messages are composed of attributes, which have 8-bit attribute
type numbers. Attributes numbered within the range 0 through 127 are
called non-skippable attributes, and attributes within the range of
128 through 255 are called skippable attributes. The EAP-AKA and
EAP-SIM attribute type number is a new numbering space for which IANA
administration is required. The following attribute types are
specified in this document in [EAP-SIM]:
AT_RAND.........................................1
AT_AUTN.........................................2
AT_RES..........................................3
AT_AUTS.........................................4
AT_PADDING......................................6
AT_NONCE_MT.....................................7
AT_PERMANENT_ID_REQ............................10
AT_MAC.........................................11
AT_NOTIFICATION................................12
AT_ANY_ID_REQ..................................13
AT_IDENTITY....................................14
AT_VERSION_LIST................................15
AT_SELECTED_VERSION............................16
AT_FULLAUTH_ID_REQ.............................17
AT_COUNTER.....................................19
AT_COUNTER_TOO_SMALL...........................20
AT_NONCE_S.....................................21
AT_CLIENT_ERROR_CODE...........................22
AT_IV.........................................129
AT_ENCR_DATA..................................130
AT_NEXT_PSEUDONYM.............................132
AT_NEXT_REAUTH_ID.............................133
AT_CHECKCODE..................................134
AT_RESULT_IND.................................135
The AT_NOTIFICATION attribute contains a 16-bit notification code
value. The most significant bit of the notification code is called
the S bit (success) and the second most significant bit is called the
P bit (phase). If the S bit is set to zero, then the notification
code indicates failure; notification codes with the S bit set to one
do not indicate failure. If the P bit is set to zero, then the
notification code can only be used before authentication has
occurred. If the P bit is set to one, then the notification code can
only be used after authentication. The notification code is a new
numbering space for which IANA administration is required. The
following values have been specified in this document and in
[EAP-SIM].
General failure after authentication......................0
User has been temporarily denied access................1026
User has not subscribed to the requested service.......1031
General failure.......................................16384
Success...............................................32768
The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in
[EAP-SIM], contain 16-bit EAP method version numbers. The EAP method
version number is a new numbering space for which IANA administration
is required. Value 1 for "EAP-SIM Version 1" has been specified in
[EAP-SIM]. Version numbers are not currently used in EAP-AKA.
The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error
code. The client error code is a new numbering space for which IANA
administration is required. Values 0, 1, 2, and 3 have been
specified in this document and in [EAP-SIM].
All requests for value assignment from the various number spaces
described in this document require proper documentation, according to
the "Specification Required" policy described in [RFC2434]. Requests
must be specified in sufficient detail so that interoperability
between independent implementations is possible. Possible forms of
documentation include, but are not limited to, RFCs, the products of
another standards body (e.g., 3GPP), or permanently and readily
available vendor design notes.
12. Security Considerations
The EAP specification [RFC3748] describes the security
vulnerabilities of EAP, which does not include its own security
mechanisms. This section discusses the claimed security properties
of EAP-AKA as well as vulnerabilities and security recommendations.
12.1. Identity Protection
EAP-AKA includes optional Identity privacy support that protects the
privacy of the subscriber identity against passive eavesdropping.
This document only specifies a mechanism to deliver pseudonyms from
the server to the peer as part of an EAP-AKA exchange. Hence, a peer
that has not yet performed any EAP-AKA exchanges does not typically
have a pseudonym available. If the peer does not have a pseudonym
available, then the privacy mechanism cannot be used, and the
permanent identity will have to be sent in the clear. The terminal
SHOULD store the pseudonym in non-volatile memory so that it can be
maintained across reboots. An active attacker that impersonates the
network may use the AT_PERMANENT_ID_REQ attribute (Section 4.1.2) to
learn the subscriber’s IMSI. However, as discussed in Section 4.1.2,
the terminal can refuse to send the cleartext IMSI if it believes
that the network should be able to recognize the pseudonym.
If the peer and server cannot guarantee that the pseudonym will be
maintained reliably, and Identity privacy is required then additional
protection from an external security mechanism (such as Protected
Extensible Authentication Protocol (PEAP) [PEAP]) may be used. The
benefits and the security considerations of using an external
security mechanism with EAP-AKA are beyond the scope of this
document.
12.2. Mutual Authentication
EAP-AKA provides mutual authentication via the 3rd generation AKA
mechanisms [TS33.102] and [S.S0055-A].
Note that this mutual authentication is with the EAP server. In
general, EAP methods do not authenticate the identity or services
provided by the EAP authenticator (if distinct from the EAP server)
unless they provide the so-called channel bindings property. The
vulnerabilities related to this have been discussed in [RFC3748],
[EAPKeying], [ServiceIdentity].
EAP-AKA does not provide the channel bindings property, so it only
authenticates the EAP server. However, ongoing work such as
[ServiceIdentity] may provide such support as an extension to popular
EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
12.3. Flooding the Authentication Centre
The EAP-AKA server typically obtains authentication vectors from the
Authentication Centre (AuC). EAP-AKA introduces a new usage for the
AuC. The protocols between the EAP-AKA server and the AuC are out of
the scope of this document. However, it should be noted that a
malicious EAP-AKA peer may generate a lot of protocol requests to
mount a denial-of-service attack. The EAP-AKA server implementation
SHOULD take this into account and SHOULD take steps to limit the
traffic that it generates towards the AuC, preventing the attacker
from flooding the AuC and from extending the denial-of-service attack
from EAP-AKA to other users of the AuC.
12.4. Key Derivation
EAP-AKA supports key derivation with 128-bit effective key strength.
The key hierarchy is specified in Section 7.
The Transient EAP Keys used to protect EAP-AKA packets (K_encr,
K_aut), the Master Session Keys, and the Extended Master Session Keys
are cryptographically separate. An attacker cannot derive any
non-trivial information about any of these keys based on the other
keys. An attacker also cannot calculate the pre-shared secret from
AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session
Key, or the Extended Master Session Key.
12.5. Brute-Force and Dictionary Attacks
The effective strength of EAP-AKA values is 128 bits, and there are
no known, computationally feasible brute-force attacks. Because AKA
is not a password protocol (the pre-shared secret is not a
passphrase, or derived from a passphrase), EAP-AKA is not vulnerable
to dictionary attacks.
12.6. Protection, Replay Protection, and Confidentiality
AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to
provide integrity, replay, and confidentiality protection for EAP-AKA
Requests and Responses. Integrity protection with AT_MAC includes
the EAP header. Integrity protection (AT_MAC) is based on a keyed
message authentication code. Confidentiality (AT_ENCR_DATA and
AT_IV) is based on a block cipher.
Because keys are not available in the beginning of the EAP methods,
the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity
messages. However, the AT_CHECKCODE attribute can optionally be used
to protect the integrity of the EAP/AKA-Identity roundtrip.
Confidentiality protection is applied only to a part of the protocol
fields. The table of attributes in Section 10.1 summarizes which
fields are confidentiality protected. It should be noted that the
error and notification code attributes AT_CLIENT_ERROR_CODE and
AT_NOTIFICATION are not confidential, but they are transmitted in the
clear. Identity protection is discussed in Section 12.1.
On full authentication, replay protection of the EAP exchange is
provided by RAND and AUTN values from the underlying AKA scheme.
Protection against replays of EAP-AKA messages is also based on the
fact that messages that can include AT_MAC can only be sent once with
a certain EAP-AKA Subtype, and on the fact that a different K_aut key
will be used for calculating AT_MAC in each full authentication
exchange.
On fast re-authentication, a counter included in AT_COUNTER and a
server random nonce is used to provide replay protection. The
AT_COUNTER attribute is also included in EAP-AKA notifications, if
they are used after successful authentication in order to provide
replay protection between re-authentication exchanges.
The contents of the user identity string are implicitly integrity
protected by including them in key derivation.
Because EAP-AKA is not a tunneling method, EAP-Request/Notification,
EAP-Response/Notification, EAP-Success, or EAP-Failure packets are
not confidential, integrity protected, or replay protected. On
physically insecure networks, this may enable an attacker to mount
denial-of-service attacks by spoofing these packets. As discussed in
Section 6.3, the peer will only accept EAP-Success after the peer
successfully authenticates the server. Hence, the attacker cannot
force the peer to believe successful mutual authentication has
occurred before the peer successfully authenticates the server or
after the peer failed to authenticate the server.
The security considerations of EAP-AKA result indications are covered
in Section 12.8
An eavesdropper will see the EAP Notification, EAP_Success and
EAP-Failure packets sent in the clear. With EAP-AKA, confidential
information MUST NOT be transmitted in EAP Notification packets.
12.7. Negotiation Attacks
EAP-AKA does not protect the EAP-Response/Nak packet. Because
EAP-AKA does not protect the EAP method negotiation, EAP method
downgrading attacks may be possible, especially if the user uses the
same identity with EAP-AKA and other EAP methods.
As described in Section 8, EAP-AKA allows the protocol to be extended
by defining new attribute types. When defining such attributes, it
should be noted that any extra attributes included in
EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not
included in the MACs later on, and thus some other precautions must
be taken to avoid modifications to them.
EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol
version negotiation.
12.8. Protected Result Indications
EAP-AKA supports optional protected success indications, and
acknowledged failure indications. If a failure occurs after
successful authentication, then the EAP-AKA failure indication is
integrity and replay protected.
Even if an EAP-Failure packet is lost when using EAP-AKA over an
unreliable medium, then the EAP-AKA failure indications will help
ensure that the peer and EAP server will know the other party’s
authentication decision. If protected success indications are used,
then the loss of Success packet will also be addressed by the
acknowledged, integrity, and replay protected EAP-AKA success
indication. If the optional success indications are not used, then
the peer may end up believing the server completed successful
authentication, when actually it failed. Because access will not be
granted in this case, protected result indications are not needed
unless the client is not able to realize it does not have access for
an extended period of time.
12.9. Man-in-the-Middle Attacks
In order to avoid man-in-the-middle attacks and session hijacking,
user data SHOULD be integrity protected on physically insecure
networks. The EAP-AKA Master Session Key or keys derived from it MAY
be used as the integrity protection keys, or, if an external security
mechanism such as PEAP is used, then the link integrity protection
keys MAY be derived by the external security mechanism.
There are man-in-the-middle attacks associated with the use of any
EAP method within a tunneled protocol. For instance, an early
version of PEAP [PEAP-02] was vulnerable to this attack. This
specification does not address these attacks. If EAP-AKA is used
with a tunneling protocol, there should be cryptographic binding
provided between the protocol and EAP-AKA to prevent
man-in-the-middle attacks through rogue authenticators being able to
setup one-way authenticated tunnels. For example, newer versions of
PEAP include such cryptographic binding. The EAP-AKA Master Session
Key MAY be used to provide the cryptographic binding. However, the
mechanism that provides the binding depends on the tunneling protocol
and is beyond the scope of this document.
12.10. Generating Random Numbers
An EAP-AKA implementation SHOULD use a good source of randomness to
generate the random numbers required in the protocol. Please see
[RFC4086] for more information on generating random numbers for
security applications.
13. Security Claims
This section provides the security claims required by [RFC3748].
Auth. Mechanism: EAP-AKA is based on the AKA mechanism, which is an
authentication and key agreement mechanism based on a symmetric
128-bit pre-shared secret.
Ciphersuite negotiation: No
Mutual authentication: Yes (Section 12.2)
Integrity protection: Yes (Section 12.6)
Replay protection: Yes (Section 12.6)
Confidentiality: Yes, except method-specific success and failure
indications (Section 12.1, Section 12.6)
Key derivation: Yes
Key strength: EAP-AKA supports key derivation with 128-bit effective
key strength.
Description of key hierarchy: Please see Section 7.
Dictionary attack protection: N/A (Section 12.5)
Fast reconnect: Yes
Cryptographic binding: N/A
Session independence: Yes (Section 12.4)
Fragmentation: No
Channel binding: No
Indication of vulnerabilities. Vulnerabilities are discussed in
Section 12.
14. Acknowledgements and Contributions
The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of
Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri
Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia,
Pasi Eronen of Nokia, Olivier Paridaens of Alcatel, and Ilkka
Uusitalo of Ericsson for interesting discussions in this problem
space.
Many thanks to Yoshihiro Ohba for reviewing the document.
This protocol has been partly developed in parallel with EAP-SIM
[EAP-SIM], and hence this specification incorporates many ideas from
EAP-SIM, and many contributions from the reviewer’s of EAP-SIM.
The attribute format is based on the extension format of Mobile IPv4
[RFC3344].
15. References
15.1. Normative References
[TS33.102] 3rd Generation Partnership Project, "3GPP Technical
Specification 3GPP TS 33.102 V5.1.0: "Technical
Specification Group Services and System Aspects; 3G
Security; Security Architecture (Release 5)"",
December 2002.
[S.S0055-A] 3rd Generation Partnership Project 2, "3GPP2
Enhanced Cryptographic Algorithms", September 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
"The Network Access Identifier", RFC 4282, December
2005.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
and H. Levkowetz, "Extensible Authentication
Protocol (EAP)", RFC 3748, June 2004.