4428 lines
190 KiB
Plaintext
4428 lines
190 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group J. Arkko
|
|||
|
Request for Comments: 4187 Ericsson
|
|||
|
Category: Informational H. Haverinen
|
|||
|
Nokia
|
|||
|
January 2006
|
|||
|
|
|||
|
|
|||
|
Extensible Authentication Protocol Method for 3rd Generation
|
|||
|
Authentication and Key Agreement (EAP-AKA)
|
|||
|
|
|||
|
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 (2006).
|
|||
|
|
|||
|
IESG Note
|
|||
|
|
|||
|
The EAP-AKA protocol was developed by 3GPP. The documentation of
|
|||
|
EAP-AKA is provided as information to the Internet community. While
|
|||
|
the EAP WG has verified that EAP-AKA is compatible with EAP as
|
|||
|
defined in RFC 3748, no other review has been done, including
|
|||
|
validation of the security claims. The IETF has also not reviewed
|
|||
|
the security of the underlying UMTS AKA algorithms.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This document specifies an Extensible Authentication Protocol (EAP)
|
|||
|
mechanism for authentication and session key distribution that uses
|
|||
|
the Authentication and Key Agreement (AKA) mechanism. AKA is used in
|
|||
|
the 3rd generation mobile networks Universal Mobile
|
|||
|
Telecommunications System (UMTS) and CDMA2000. AKA is based on
|
|||
|
symmetric keys, and typically runs in a Subscriber Identity Module,
|
|||
|
which is a UMTS Subscriber Identity Module, USIM, or a (Removable)
|
|||
|
User Identity Module, (R)UIM, similar to a smart card.
|
|||
|
|
|||
|
EAP-AKA includes optional identity privacy support, optional result
|
|||
|
indications, and an optional fast re-authentication procedure.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 1]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1. Introduction and Motivation .....................................4
|
|||
|
2. Terms and Conventions Used in This Document .....................5
|
|||
|
3. Protocol Overview ...............................................9
|
|||
|
4. Operation ......................................................15
|
|||
|
4.1. Identity Management .......................................15
|
|||
|
4.1.1. Format, Generation, and Usage of Peer Identities ...15
|
|||
|
4.1.2. Communicating the Peer Identity to the Server ......21
|
|||
|
4.1.3. Choice of Identity for the EAP-Response/Identity ...23
|
|||
|
4.1.4. Server Operation in the Beginning of
|
|||
|
EAP-AKA Exchange ...................................23
|
|||
|
4.1.5. Processing of EAP-Request/AKA-Identity by
|
|||
|
the Peer ...........................................24
|
|||
|
4.1.6. Attacks against Identity Privacy ...................25
|
|||
|
4.1.7. Processing of AT_IDENTITY by the Server ............26
|
|||
|
4.2. Message Sequence Examples (Informative) ...................27
|
|||
|
4.2.1. Usage of AT_ANY_ID_REQ .............................27
|
|||
|
4.2.2. Fall Back on Full Authentication ...................28
|
|||
|
4.2.3. Requesting the Permanent Identity 1 ................29
|
|||
|
4.2.4. Requesting the Permanent Identity 2 ................30
|
|||
|
4.2.5. Three EAP/AKA-Identity Round Trips .................30
|
|||
|
5. Fast Re-Authentication .........................................32
|
|||
|
5.1. General ...................................................32
|
|||
|
5.2. Comparison to AKA .........................................33
|
|||
|
5.3. Fast Re-Authentication Identity ...........................33
|
|||
|
5.4. Fast Re-Authentication Procedure ..........................35
|
|||
|
5.5. Fast Re-Authentication Procedure when Counter is
|
|||
|
Too Small .................................................37
|
|||
|
6. EAP-AKA Notifications ..........................................38
|
|||
|
6.1. General ...................................................38
|
|||
|
6.2. Result Indications ........................................39
|
|||
|
6.3. Error Cases ...............................................40
|
|||
|
6.3.1. Peer Operation .....................................41
|
|||
|
6.3.2. Server Operation ...................................41
|
|||
|
6.3.3. EAP-Failure ........................................42
|
|||
|
6.3.4. EAP-Success ........................................42
|
|||
|
7. Key Generation .................................................43
|
|||
|
8. Message Format and Protocol Extensibility ......................45
|
|||
|
8.1. Message Format ............................................45
|
|||
|
8.2. Protocol Extensibility ....................................47
|
|||
|
9. Messages .......................................................48
|
|||
|
9.1. EAP-Request/AKA-Identity ..................................48
|
|||
|
9.2. EAP-Response/AKA-Identity .................................48
|
|||
|
9.3. EAP-Request/AKA-Challenge .................................49
|
|||
|
9.4. EAP-Response/AKA-Challenge ................................49
|
|||
|
9.5. EAP-Response/AKA-Authentication-Reject ....................50
|
|||
|
9.6. EAP-Response/AKA-Synchronization-Failure ..................50
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 2]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
9.7. EAP-Request/AKA-Reauthentication ..........................50
|
|||
|
9.8. EAP-Response/AKA-Reauthentication .........................51
|
|||
|
9.9. EAP-Response/AKA-Client-Error .............................52
|
|||
|
9.10. EAP-Request/AKA-Notification .............................52
|
|||
|
9.11. EAP-Response/AKA-Notification ............................52
|
|||
|
10. Attributes ....................................................53
|
|||
|
10.1. Table of Attributes ......................................53
|
|||
|
10.2. AT_PERMANENT_ID_REQ ......................................54
|
|||
|
10.3. AT_ANY_ID_REQ ............................................54
|
|||
|
10.4. AT_FULLAUTH_ID_REQ .......................................54
|
|||
|
10.5. AT_IDENTITY ..............................................55
|
|||
|
10.6. AT_RAND ..................................................55
|
|||
|
10.7. AT_AUTN ..................................................56
|
|||
|
10.8. AT_RES ...................................................56
|
|||
|
10.9. AT_AUTS ..................................................57
|
|||
|
10.10. AT_NEXT_PSEUDONYM .......................................57
|
|||
|
10.11. AT_NEXT_REAUTH_ID .......................................58
|
|||
|
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................58
|
|||
|
10.13. AT_CHECKCODE ............................................60
|
|||
|
10.14. AT_RESULT_IND ...........................................62
|
|||
|
10.15. AT_MAC ..................................................63
|
|||
|
10.16. AT_COUNTER ..............................................64
|
|||
|
10.17. AT_COUNTER_TOO_SMALL ....................................64
|
|||
|
10.18. AT_NONCE_S ..............................................65
|
|||
|
10.19. AT_NOTIFICATION .........................................65
|
|||
|
10.20. AT_CLIENT_ERROR_CODE ....................................66
|
|||
|
11. IANA and Protocol Numbering Considerations ....................66
|
|||
|
12. Security Considerations .......................................68
|
|||
|
12.1. Identity Protection ......................................69
|
|||
|
12.2. Mutual Authentication ....................................69
|
|||
|
12.3. Flooding the Authentication Centre .......................69
|
|||
|
12.4. Key Derivation ...........................................70
|
|||
|
12.5. Brute-Force and Dictionary Attacks .......................70
|
|||
|
12.6. Protection, Replay Protection, and Confidentiality .......70
|
|||
|
12.7. Negotiation Attacks ......................................71
|
|||
|
12.8. Protected Result Indications .............................72
|
|||
|
12.9. Man-in-the-Middle Attacks ................................72
|
|||
|
12.10. Generating Random Numbers ...............................73
|
|||
|
13. Security Claims ...............................................73
|
|||
|
14. Acknowledgements and Contributions ............................74
|
|||
|
15. References ....................................................74
|
|||
|
15.1. Normative References .....................................74
|
|||
|
15.2. Informative References ...................................76
|
|||
|
Appendix A. Pseudo-Random Number Generator .......................77
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 3]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
1. Introduction and Motivation
|
|||
|
|
|||
|
This document specifies an Extensible Authentication Protocol (EAP)
|
|||
|
mechanism for authentication and session key distribution that uses
|
|||
|
the 3rd generation Authentication and Key Agreement mechanism,
|
|||
|
specified for Universal Mobile Telecommunications System (UMTS) in
|
|||
|
[TS33.102] and for CDMA2000 in [S.S0055-A]. UMTS and CDMA2000 are
|
|||
|
global 3rd generation mobile network standards that use the same AKA
|
|||
|
mechanism.
|
|||
|
|
|||
|
2nd generation mobile networks and 3rd generation mobile networks use
|
|||
|
different authentication and key agreement mechanisms. The Global
|
|||
|
System for Mobile communications (GSM) is a 2nd generation mobile
|
|||
|
network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism
|
|||
|
that is based on the GSM authentication and key agreement primitives.
|
|||
|
|
|||
|
AKA is based on challenge-response mechanisms and symmetric
|
|||
|
cryptography. AKA typically runs in a UMTS Subscriber Identity
|
|||
|
Module (USIM) or a CDMA2000 (Removable) User Identity Module
|
|||
|
((R)UIM). In this document, both modules are referred to as identity
|
|||
|
modules. Compared to the 2nd generation mechanisms such as GSM AKA,
|
|||
|
the 3rd generation AKA provides substantially longer key lengths and
|
|||
|
mutual authentication.
|
|||
|
|
|||
|
The introduction of AKA inside EAP allows several new applications.
|
|||
|
These include the following:
|
|||
|
|
|||
|
o The use of the AKA also as a secure PPP authentication method in
|
|||
|
devices that already contain an identity module.
|
|||
|
o The use of the 3rd generation mobile network authentication
|
|||
|
infrastructure in the context of wireless LANs
|
|||
|
o Relying on AKA and the existing infrastructure in a seamless way
|
|||
|
with any other technology that can use EAP.
|
|||
|
|
|||
|
AKA works in the following manner:
|
|||
|
|
|||
|
o The identity module and the home environment have agreed on a
|
|||
|
secret key beforehand. (The "home environment" refers to the home
|
|||
|
operator's authentication network infrastructure.)
|
|||
|
o The actual authentication process starts by having the home
|
|||
|
environment produce an authentication vector, based on the secret
|
|||
|
key and a sequence number. The authentication vector contains a
|
|||
|
random part RAND, an authenticator part AUTN used for
|
|||
|
authenticating the network to the identity module, an expected
|
|||
|
result part XRES, a 128-bit session key for integrity check IK,
|
|||
|
and a 128-bit session key for encryption CK.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 4]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
o The RAND and the AUTN are delivered to the identity module.
|
|||
|
o The identity module verifies the AUTN, again based on the secret
|
|||
|
key and the sequence number. If this process is successful (the
|
|||
|
AUTN is valid and the sequence number used to generate AUTN is
|
|||
|
within the correct range), the identity module produces an
|
|||
|
authentication result RES and sends it to the home environment.
|
|||
|
o The home environment verifies the correct result from the identity
|
|||
|
module. If the result is correct, IK and CK can be used to
|
|||
|
protect further communications between the identity module and the
|
|||
|
home environment.
|
|||
|
|
|||
|
When verifying AUTN, the identity module may detect that the sequence
|
|||
|
number the network uses is not within the correct range. In this
|
|||
|
case, the identity module calculates a sequence number
|
|||
|
synchronization parameter AUTS and sends it to the network. AKA
|
|||
|
authentication may then be retried with a new authentication vector
|
|||
|
generated using the synchronized sequence number.
|
|||
|
|
|||
|
For a specification of the AKA mechanisms and how the cryptographic
|
|||
|
values AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for
|
|||
|
UMTS and [S.S0055-A] for CDMA2000.
|
|||
|
|
|||
|
In EAP-AKA, the EAP server node obtains the authentication vectors,
|
|||
|
compares RES and XRES, and uses CK and IK in key derivation.
|
|||
|
|
|||
|
In the 3rd generation mobile networks, AKA is used for both radio
|
|||
|
network authentication and IP multimedia service authentication
|
|||
|
purposes. Different user identities and formats are used for these;
|
|||
|
the radio network uses the International Mobile Subscriber Identifier
|
|||
|
(IMSI), whereas the IP multimedia service uses the Network Access
|
|||
|
Identifier (NAI) [RFC4282].
|
|||
|
|
|||
|
2. Terms and Conventions Used in This Document
|
|||
|
|
|||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
document are to be interpreted as described in [RFC2119].
|
|||
|
|
|||
|
The terms and abbreviations "authenticator", "backend authentication
|
|||
|
server", "EAP server", "peer", "Silently Discard", "Master Session
|
|||
|
Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
|
|||
|
are to be interpreted as described in [RFC3748].
|
|||
|
|
|||
|
This document frequently uses the following terms and abbreviations.
|
|||
|
The AKA parameters are specified in detail in [TS33.102] for UMTS and
|
|||
|
[S.S0055-A] for CDMA2000.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 5]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
AAA protocol
|
|||
|
|
|||
|
Authentication, Authorization and Accounting protocol
|
|||
|
|
|||
|
AKA
|
|||
|
|
|||
|
Authentication and Key Agreement
|
|||
|
|
|||
|
AuC
|
|||
|
|
|||
|
Authentication Centre. The mobile network element that can
|
|||
|
authenticate subscribers in the mobile networks.
|
|||
|
|
|||
|
AUTN
|
|||
|
|
|||
|
AKA parameter. AUTN is an authentication value generated by
|
|||
|
the AuC, which, together with the RAND, authenticates the
|
|||
|
server to the peer, 128 bits.
|
|||
|
|
|||
|
AUTS
|
|||
|
|
|||
|
AKA parameter. A value generated by the peer upon
|
|||
|
experiencing a synchronization failure, 112 bits.
|
|||
|
|
|||
|
EAP
|
|||
|
|
|||
|
Extensible Authentication Protocol [RFC3748]
|
|||
|
|
|||
|
Fast Re-Authentication
|
|||
|
|
|||
|
An EAP-AKA authentication exchange that is based on keys
|
|||
|
derived upon a preceding full authentication exchange. The
|
|||
|
3rd Generation AKA is not used in the fast re-authentication
|
|||
|
procedure.
|
|||
|
|
|||
|
Fast Re-Authentication Identity
|
|||
|
|
|||
|
A fast re-authentication identity of the peer, including an
|
|||
|
NAI realm portion in environments where a realm is used.
|
|||
|
Used on re-authentication only.
|
|||
|
|
|||
|
Fast Re-Authentication Username
|
|||
|
|
|||
|
The username portion of fast re-authentication identity,
|
|||
|
i.e., not including any realm portions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 6]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Full Authentication
|
|||
|
|
|||
|
An EAP-AKA authentication exchange that is based on the
|
|||
|
3rd Generation AKA procedure.
|
|||
|
|
|||
|
GSM
|
|||
|
|
|||
|
Global System for Mobile communications.
|
|||
|
|
|||
|
NAI
|
|||
|
|
|||
|
Network Access Identifier [RFC4282]
|
|||
|
|
|||
|
Identity Module
|
|||
|
|
|||
|
Identity module is used in this document to refer to the
|
|||
|
part of the mobile device that contains authentication and
|
|||
|
key agreement primitives. The identity module may be an
|
|||
|
integral part of the mobile device or it may be an application
|
|||
|
on a smart card distributed by a mobile operator. USIM and
|
|||
|
(R)UIM are identity modules.
|
|||
|
|
|||
|
Nonce
|
|||
|
|
|||
|
A value that is used at most once or that is never repeated
|
|||
|
within the same cryptographic context. In general, a nonce can
|
|||
|
be predictable (e.g., a counter) or unpredictable (e.g., a
|
|||
|
random value). Because some cryptographic properties may
|
|||
|
depend on the randomness of the nonce, attention should be paid
|
|||
|
to whether a nonce is required to be random or not. In this
|
|||
|
document, the term nonce is only used to denote random nonces,
|
|||
|
and it is not used to denote counters.
|
|||
|
|
|||
|
Permanent Identity
|
|||
|
|
|||
|
The permanent identity of the peer, including an NAI realm
|
|||
|
portion in environments where a realm is used. The permanent
|
|||
|
identity is usually based on the IMSI. Used on full
|
|||
|
authentication only.
|
|||
|
|
|||
|
Permanent Username
|
|||
|
|
|||
|
The username portion of permanent identity, i.e., not including
|
|||
|
any realm portions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 7]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Pseudonym Identity
|
|||
|
|
|||
|
A pseudonym identity of the peer, including an NAI realm
|
|||
|
portion in environments where a realm is used. Used on full
|
|||
|
authentication only.
|
|||
|
|
|||
|
Pseudonym Username
|
|||
|
|
|||
|
The username portion of pseudonym identity, i.e., not including
|
|||
|
any realm portions.
|
|||
|
|
|||
|
RAND
|
|||
|
|
|||
|
An AKA parameter. Random number generated by the AuC,
|
|||
|
128 bits.
|
|||
|
|
|||
|
RES
|
|||
|
|
|||
|
Authentication result from the peer, which, together with
|
|||
|
the RAND, authenticates the peer to the server,
|
|||
|
128 bits.
|
|||
|
|
|||
|
(R)UIM
|
|||
|
|
|||
|
CDMA2000 (Removable) User Identity Module. (R)UIM is an
|
|||
|
application that is resident on devices such as smart cards,
|
|||
|
which may be fixed in the terminal or distributed by CDMA2000
|
|||
|
operators (when removable).
|
|||
|
|
|||
|
SQN
|
|||
|
|
|||
|
An AKA parameter. Sequence number used in the authentication
|
|||
|
process, 48 bits.
|
|||
|
|
|||
|
SIM
|
|||
|
|
|||
|
Subscriber Identity Module. The SIM is traditionally a smart
|
|||
|
card distributed by a GSM operator.
|
|||
|
|
|||
|
SRES
|
|||
|
|
|||
|
The authentication result parameter in GSM, corresponds to
|
|||
|
the RES parameter in 3G AKA, 32 bits.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 8]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
UAK
|
|||
|
|
|||
|
UIM Authentication Key, used in CDMA2000 AKA. Both the
|
|||
|
identity module and the network can optionally generate the UAK
|
|||
|
during the AKA computation in CDMA2000. UAK is not used in
|
|||
|
this version of EAP-AKA.
|
|||
|
|
|||
|
UIM
|
|||
|
|
|||
|
Please see (R)UIM.
|
|||
|
|
|||
|
USIM
|
|||
|
|
|||
|
UMTS Subscriber Identity Module. USIM is an application that
|
|||
|
is resident on devices such as smart cards distributed by UMTS
|
|||
|
operators.
|
|||
|
|
|||
|
3. Protocol Overview
|
|||
|
|
|||
|
Figure 1 shows the basic, successful full authentication exchange in
|
|||
|
EAP-AKA, when optional result indications are not used. The
|
|||
|
authenticator typically communicates with an EAP server that is
|
|||
|
located on a backend authentication server using an AAA protocol.
|
|||
|
The authenticator shown in the figure is often simply relaying EAP
|
|||
|
messages to and from the EAP server, but these backend AAA
|
|||
|
communications are not shown. At the minimum, EAP-AKA uses two
|
|||
|
roundtrips to authenticate and authorize the peer and generate
|
|||
|
session keys. As in other EAP schemes, an identity request/response
|
|||
|
message pair is usually exchanged first. On full authentication, the
|
|||
|
peer's identity response includes either the user's International
|
|||
|
Mobile Subscriber Identity (IMSI), or a temporary identity
|
|||
|
(pseudonym) if identity privacy is in effect, as specified in
|
|||
|
Section 4.1. (As specified in [RFC3748], the initial identity
|
|||
|
request is not required, and MAY be bypassed in cases where the
|
|||
|
network can presume the identity, such as when using leased lines,
|
|||
|
dedicated dial-ups, etc. Please see Section 4.1.2 for specification
|
|||
|
of how to obtain the identity via EAP AKA messages.)
|
|||
|
|
|||
|
After obtaining the subscriber identity, the EAP server obtains an
|
|||
|
authentication vector (RAND, AUTN, RES, CK, IK) for use in
|
|||
|
authenticating the subscriber. From the vector, the EAP server
|
|||
|
derives the keying material, as specified in Section 6.4. The vector
|
|||
|
may be obtained by contacting an Authentication Centre (AuC) on the
|
|||
|
mobile network; for example, per UMTS specifications, several vectors
|
|||
|
may be obtained at a time. Vectors may be stored in the EAP server
|
|||
|
for use at a later time, but they may not be reused.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 9]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
In CDMA2000, the vector may include a sixth value called the User
|
|||
|
Identity Module Authentication Key (UAK). This key is not used in
|
|||
|
EAP-AKA.
|
|||
|
|
|||
|
Next, the EAP server starts the actual AKA protocol by sending an
|
|||
|
EAP-Request/AKA-Challenge message. EAP-AKA packets encapsulate
|
|||
|
parameters in attributes, encoded in a Type, Length, Value format.
|
|||
|
The packet format and the use of attributes are specified in
|
|||
|
Section 8. The EAP-Request/AKA-Challenge message contains a RAND
|
|||
|
random number (AT_RAND), a network authentication token (AT_AUTN),
|
|||
|
and a message authentication code (AT_MAC). The EAP-Request/
|
|||
|
AKA-Challenge message MAY optionally contain encrypted data, which is
|
|||
|
used for identity privacy and fast re-authentication support, as
|
|||
|
described in Section 4.1. The AT_MAC attribute contains a message
|
|||
|
authentication code covering the EAP packet. The encrypted data is
|
|||
|
not shown in the figures of this section.
|
|||
|
|
|||
|
The peer runs the AKA algorithm (typically using an identity module)
|
|||
|
and verifies the AUTN. If this is successful, the peer is talking to
|
|||
|
a legitimate EAP server and proceeds to send the EAP-Response/
|
|||
|
AKA-Challenge. This message contains a result parameter that allows
|
|||
|
the EAP server, in turn, to authenticate the peer, and the AT_MAC
|
|||
|
attribute to integrity protect the EAP message.
|
|||
|
|
|||
|
The EAP server verifies that the RES and the MAC in the EAP-Response/
|
|||
|
AKA-Challenge packet are correct. Because protected success
|
|||
|
indications are not used in this example, the EAP server sends the
|
|||
|
EAP-Success packet, indicating that the authentication was
|
|||
|
successful. (Protected success indications are discussed in
|
|||
|
Section 6.2.) The EAP server may also include derived keying
|
|||
|
material in the message it sends to the authenticator. The peer has
|
|||
|
derived the same keying material, so the authenticator does not
|
|||
|
forward the keying material to the peer along with EAP-Success.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 10]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| EAP-Request/Identity |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/Identity |
|
|||
|
| (Includes user's NAI) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server runs AKA algorithms, |
|
|||
|
| | generates RAND and AUTN. |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Challenge |
|
|||
|
| (AT_RAND, AT_AUTN, AT_MAC) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
+-------------------------------------+ |
|
|||
|
| Peer runs AKA algorithms, | |
|
|||
|
| verifies AUTN and MAC, derives RES | |
|
|||
|
| and session key | |
|
|||
|
+-------------------------------------+ |
|
|||
|
| EAP-Response/AKA-Challenge |
|
|||
|
| (AT_RES, AT_MAC) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +--------------------------------+
|
|||
|
| | Server checks the given RES, |
|
|||
|
| | and MAC and finds them correct.|
|
|||
|
| +--------------------------------+
|
|||
|
| EAP-Success |
|
|||
|
|<------------------------------------------------------|
|
|||
|
|
|||
|
Figure 1: EAP-AKA full authentication procedure
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 11]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Figure 2 shows how the EAP server rejects the Peer due to a failed
|
|||
|
authentication.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| EAP-Request/Identity |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/Identity |
|
|||
|
| (Includes user's NAI) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server runs AKA algorithms, |
|
|||
|
| | generates RAND and AUTN. |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Challenge |
|
|||
|
| (AT_RAND, AT_AUTN, AT_MAC) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
+-------------------------------------+ |
|
|||
|
| Peer runs AKA algorithms, | |
|
|||
|
| possibly verifies AUTN, and sends an| |
|
|||
|
| invalid response | |
|
|||
|
+-------------------------------------+ |
|
|||
|
| EAP-Response/AKA-Challenge |
|
|||
|
| (AT_RES, AT_MAC) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------------------+
|
|||
|
| | Server checks the given RES and the MAC, |
|
|||
|
| | and finds one of them incorrect. |
|
|||
|
| +------------------------------------------+
|
|||
|
| EAP-Request/AKA-Notification |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/AKA-Notification |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| EAP-Failure |
|
|||
|
|<------------------------------------------------------|
|
|||
|
|
|||
|
Figure 2: Peer authentication fails
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 12]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Figure 3 shows the peer rejecting the AUTN of the EAP server.
|
|||
|
|
|||
|
The peer sends an explicit error message (EAP-Response/
|
|||
|
AKA-Authentication-Reject) to the EAP server, as usual in AKA when
|
|||
|
AUTN is incorrect. This allows the EAP server to produce the same
|
|||
|
error statistics that AKA generally produces in UMTS or CDMA2000.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| EAP-Request/Identity |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/Identity |
|
|||
|
| (Includes user's NAI) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server runs AKA algorithms, |
|
|||
|
| | generates RAND and a bad AUTN|
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Challenge |
|
|||
|
| (AT_RAND, AT_AUTN, AT_MAC) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
+-------------------------------------+ |
|
|||
|
| Peer runs AKA algorithms | |
|
|||
|
| and discovers AUTN that can not be | |
|
|||
|
| verified | |
|
|||
|
+-------------------------------------+ |
|
|||
|
| EAP-Response/AKA-Authentication-Reject |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| EAP-Failure |
|
|||
|
|<------------------------------------------------------|
|
|||
|
|
|||
|
Figure 3: Network authentication fails
|
|||
|
|
|||
|
The AKA uses shared secrets between the Peer and the Peer's home
|
|||
|
operator, together with a sequence number, to actually perform an
|
|||
|
authentication. In certain circumstances, shown in Figure 4, it is
|
|||
|
possible for the sequence numbers to get out of sequence.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 13]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| EAP-Request/Identity |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/Identity |
|
|||
|
| (Includes user's NAI) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server runs AKA algorithms, |
|
|||
|
| | generates RAND and AUTN. |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Challenge |
|
|||
|
| (AT_RAND, AT_AUTN, AT_MAC) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
+-------------------------------------+ |
|
|||
|
| Peer runs AKA algorithms | |
|
|||
|
| and discovers AUTN that contains an | |
|
|||
|
| inappropriate sequence number | |
|
|||
|
+-------------------------------------+ |
|
|||
|
| EAP-Response/AKA-Synchronization-Failure |
|
|||
|
| (AT_AUTS) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +---------------------------+
|
|||
|
| | Perform resynchronization |
|
|||
|
| | Using AUTS and |
|
|||
|
| | the sent RAND |
|
|||
|
| +---------------------------+
|
|||
|
| |
|
|||
|
|
|||
|
Figure 4: Sequence number synchronization
|
|||
|
|
|||
|
After the resynchronization process has taken place in the server and
|
|||
|
AAA side, the process continues by the server side sending a new
|
|||
|
EAP-Request/AKA-Challenge message.
|
|||
|
|
|||
|
In addition to the full authentication scenarios described above,
|
|||
|
EAP-AKA includes a fast re-authentication procedure, which is
|
|||
|
specified in Section 5. Fast re-authentication is based on keys
|
|||
|
derived on full authentication. If the peer has maintained state
|
|||
|
information for re-authentication and wants to use fast
|
|||
|
re-authentication, then the peer indicates this by using a specific
|
|||
|
fast re-authentication identity instead of the permanent identity or
|
|||
|
a pseudonym identity.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 14]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
4. Operation
|
|||
|
|
|||
|
4.1. Identity Management
|
|||
|
|
|||
|
4.1.1. Format, Generation, and Usage of Peer Identities
|
|||
|
|
|||
|
4.1.1.1. General
|
|||
|
|
|||
|
In the beginning of EAP authentication, the Authenticator or the EAP
|
|||
|
server usually issues the EAP-Request/Identity packet to the peer.
|
|||
|
The peer responds with EAP-Response/Identity, which contains the
|
|||
|
user's identity. The formats of these packets are specified in
|
|||
|
[RFC3748].
|
|||
|
|
|||
|
Subscribers of mobile networks are identified with the International
|
|||
|
Mobile Subscriber Identity (IMSI) [TS23.003]. The IMSI is a string
|
|||
|
of not more than 15 digits. It is composed of a Mobile Country Code
|
|||
|
(MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and
|
|||
|
a Mobile Subscriber Identification Number (MSIN) of not more than 10
|
|||
|
digits. MCC and MNC uniquely identify the GSM operator and help
|
|||
|
identify the AuC from which the authentication vectors need to be
|
|||
|
retrieved for this subscriber.
|
|||
|
|
|||
|
Internet AAA protocols identify users with the Network Access
|
|||
|
Identifier (NAI) [RFC4282]. When used in a roaming environment, the
|
|||
|
NAI is composed of a username and a realm, separated with "@"
|
|||
|
(username@realm). The username portion identifies the subscriber
|
|||
|
within the realm.
|
|||
|
|
|||
|
This section specifies the peer identity format used in EAP-AKA. In
|
|||
|
this document, the term identity or peer identity refers to the whole
|
|||
|
identity string that is used to identify the peer. The peer identity
|
|||
|
may include a realm portion. "Username" refers to the portion of the
|
|||
|
peer identity that identifies the user, i.e., the username does not
|
|||
|
include the realm portion.
|
|||
|
|
|||
|
4.1.1.2. Identity Privacy Support
|
|||
|
|
|||
|
EAP-AKA includes optional identity privacy (anonymity) support that
|
|||
|
can be used to hide the cleartext permanent identity and thereby make
|
|||
|
the subscriber's EAP exchanges untraceable to eavesdroppers. Because
|
|||
|
the permanent identity never changes, revealing it would help
|
|||
|
observers to track the user. The permanent identity is usually based
|
|||
|
on the IMSI, which may further help the tracking, because the same
|
|||
|
identifier may be used in other contexts as well. Identity privacy
|
|||
|
is based on temporary identities, or pseudonyms, which are equivalent
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 15]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
to but separate from the Temporary Mobile Subscriber Identities
|
|||
|
(TMSI) that are used on cellular networks. Please see Section 12.1
|
|||
|
for security considerations regarding identity privacy.
|
|||
|
|
|||
|
4.1.1.3. Username Types in EAP-AKA Identities
|
|||
|
|
|||
|
There are three types of usernames in EAP-AKA peer identities:
|
|||
|
|
|||
|
(1) Permanent usernames. For example,
|
|||
|
0123456789098765@myoperator.com might be a valid permanent identity.
|
|||
|
In this example, 0123456789098765 is the permanent username.
|
|||
|
|
|||
|
(2) Pseudonym usernames. For example, 2s7ah6n9q@myoperator.com might
|
|||
|
be a valid pseudonym identity. In this example, 2s7ah6n9q is the
|
|||
|
pseudonym username.
|
|||
|
|
|||
|
(3) Fast re-authentication usernames. For example,
|
|||
|
43953754@myoperator.com might be a valid fast re-authentication
|
|||
|
identity. In this case, 43953754 is the fast re-authentication
|
|||
|
username. Unlike permanent usernames and pseudonym usernames, fast
|
|||
|
re-authentication usernames are one-time identifiers, which are not
|
|||
|
re-used across EAP exchanges.
|
|||
|
|
|||
|
The first two types of identities are used only on full
|
|||
|
authentication, and the last type only on fast re-authentication.
|
|||
|
When the optional identity privacy support is not used, the
|
|||
|
non-pseudonym permanent identity is used on full authentication. The
|
|||
|
fast re-authentication exchange is specified in Section 5.
|
|||
|
|
|||
|
4.1.1.4. Username Decoration
|
|||
|
|
|||
|
In some environments, the peer may need to decorate the identity by
|
|||
|
prepending or appending the username with a string, in order to
|
|||
|
indicate supplementary AAA routing information in addition to the NAI
|
|||
|
realm. (The usage of an NAI realm portion is not considered to be
|
|||
|
decoration.) Username decoration is out of the scope of this
|
|||
|
document. However, it should be noted that username decoration might
|
|||
|
prevent the server from recognizing a valid username. Hence,
|
|||
|
although the peer MAY use username decoration in the identities that
|
|||
|
the peer includes in EAP-Response/Identity, and although the EAP
|
|||
|
server MAY accept a decorated peer username in this message, the peer
|
|||
|
or the EAP server MUST NOT decorate any other peer identities that
|
|||
|
are used in various EAP-AKA attributes. Only the identity used in
|
|||
|
EAP-Response/Identity may be decorated.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 16]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
4.1.1.5. NAI Realm Portion
|
|||
|
|
|||
|
The peer MAY include a realm portion in the peer identity, as per the
|
|||
|
NAI format. The use of a realm portion is not mandatory.
|
|||
|
|
|||
|
If a realm is used, the realm MAY be chosen by the subscriber's home
|
|||
|
operator and it MAY be a configurable parameter in the EAP-AKA peer
|
|||
|
implementation. In this case, the peer is typically configured with
|
|||
|
the NAI realm of the home operator. Operators MAY reserve a specific
|
|||
|
realm name for EAP-AKA users. This convention makes it easy to
|
|||
|
recognize that the NAI identifies an AKA subscriber. Such a reserved
|
|||
|
NAI realm may be useful as a hint of the first authentication method
|
|||
|
to use during method negotiation. When the peer is using a pseudonym
|
|||
|
username instead of the permanent username, the peer selects the
|
|||
|
realm name portion similarly to how it selects the realm portion when
|
|||
|
using the permanent username.
|
|||
|
|
|||
|
If no configured realm name is available, the peer MAY derive the
|
|||
|
realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED
|
|||
|
way to derive the realm from the IMSI, using the realm
|
|||
|
3gppnetwork.org, will be specified in [TS23.003].
|
|||
|
|
|||
|
Some old implementations derive the realm name from the IMSI by
|
|||
|
concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
|
|||
|
of IMSI, and ".owlan.org". For example, if the IMSI is
|
|||
|
123456789098765, and the MNC is three digits long, then the derived
|
|||
|
realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers
|
|||
|
running at owlan.org, these realm names can only be used with
|
|||
|
manually configured AAA routing. New implementations SHOULD use the
|
|||
|
mechanism specified in [TS23.003] instead of owlan.org.
|
|||
|
|
|||
|
The IMSI is a string of digits without any explicit structure, so the
|
|||
|
peer may not be able to determine the length of the MNC portion. If
|
|||
|
the peer is not able to determine whether the MNC is two or three
|
|||
|
digits long, the peer MAY use a 3-digit MNC. If the correct length
|
|||
|
of the MNC is two, then the MNC used in the realm name includes the
|
|||
|
first digit of MSIN. Hence, when configuring AAA networks for
|
|||
|
operators that have 2-digit MNC's, the network SHOULD also be
|
|||
|
prepared for realm names with incorrect 3-digit MNC's.
|
|||
|
|
|||
|
4.1.1.6. Format of the Permanent Username
|
|||
|
|
|||
|
The non-pseudonym permanent username SHOULD be derived from the IMSI.
|
|||
|
In this case, the permanent username MUST be of the format "0" |
|
|||
|
IMSI, where the character "|" denotes concatenation. In other words,
|
|||
|
the first character of the username is the digit zero (ASCII value 30
|
|||
|
hexadecimal), followed by the IMSI. The IMSI is an ASCII string that
|
|||
|
consists of not more than 15 decimal digits (ASCII values between 30
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 17]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
and 39 hexadecimal), one character per IMSI digit, in the order as
|
|||
|
specified in [TS23.003]. For example, a permanent username derived
|
|||
|
from the IMSI 295023820005424 would be encoded as the ASCII string
|
|||
|
"0295023820005424" (byte values in hexadecimal notation: 30 32 39 35
|
|||
|
30 32 33 38 32 30 30 30 35 34 32 34)
|
|||
|
|
|||
|
The EAP server MAY use the leading "0" as a hint to try EAP-AKA as
|
|||
|
the first authentication method during method negotiation, rather
|
|||
|
than using, for example, EAP-SIM. The EAP-AKA server MAY propose
|
|||
|
EAP-AKA even if the leading character was not "0".
|
|||
|
|
|||
|
Alternatively, an implementation MAY choose a permanent username that
|
|||
|
is not based on the IMSI. In this case the selection of the
|
|||
|
username, its format, and its processing is out of the scope of this
|
|||
|
document. In this case, the peer implementation MUST NOT prepend any
|
|||
|
leading characters to the username.
|
|||
|
|
|||
|
4.1.1.7. Generating Pseudonyms and Fast Re-Authentication Identities by
|
|||
|
the Server
|
|||
|
|
|||
|
Pseudonym usernames and fast re-authentication identities are
|
|||
|
generated by the EAP server. The EAP server produces pseudonym
|
|||
|
usernames and fast re-authentication identities in an
|
|||
|
implementation-dependent manner. Only the EAP server needs to be
|
|||
|
able to map the pseudonym username to the permanent identity, or to
|
|||
|
recognize a fast re-authentication identity.
|
|||
|
|
|||
|
EAP-AKA includes no provisions to ensure that the same EAP server
|
|||
|
that generated a pseudonym username will be used on the
|
|||
|
authentication exchange when the pseudonym username is used. It is
|
|||
|
recommended that the EAP servers implement some centralized mechanism
|
|||
|
to allow all EAP servers of the home operator to map pseudonyms
|
|||
|
generated by other severs to the permanent identity. If no such
|
|||
|
mechanism is available, then the EAP server, failing to understand a
|
|||
|
pseudonym issued by another server, can request the peer to send the
|
|||
|
permanent identity.
|
|||
|
|
|||
|
When issuing a fast re-authentication identity, the EAP server may
|
|||
|
include a realm name in the identity that will cause the fast
|
|||
|
re-authentication request to be forwarded to the same EAP server.
|
|||
|
|
|||
|
When generating fast re-authentication identities, the server SHOULD
|
|||
|
choose a fresh, new fast re-authentication identity that is different
|
|||
|
from the previous ones that were used after the same full
|
|||
|
authentication exchange. A full authentication exchange and the
|
|||
|
associated fast re-authentication exchanges are referred to here as
|
|||
|
the same "full authentication context". The fast re-authentication
|
|||
|
identity SHOULD include a random component. The random component
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 18]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
works as a full authentication context identifier. A context-
|
|||
|
specific fast re-authentication identity can help the server to
|
|||
|
detect whether its fast re-authentication state information matches
|
|||
|
the peer's fast re-authentication state information (in other words,
|
|||
|
whether the state information is from the same full authentication
|
|||
|
exchange). The random component also makes the fast re-
|
|||
|
authentication identities unpredictable, so an attacker cannot
|
|||
|
initiate a fast re-authentication exchange to get the server's
|
|||
|
EAP-Request/AKA-Reauthentication packet.
|
|||
|
|
|||
|
Transmitting pseudonyms and fast re-authentication identities from
|
|||
|
the server to the peer is discussed in Section 4.1.1.8. The
|
|||
|
pseudonym is transmitted as a username, without an NAI realm, and the
|
|||
|
fast re-authentication identity is transmitted as a complete NAI,
|
|||
|
including a realm portion if a realm is required. The realm is
|
|||
|
included in the fast re-authentication identity in order to allow the
|
|||
|
server to include a server-specific realm.
|
|||
|
|
|||
|
Regardless of construction method, the pseudonym username MUST
|
|||
|
conform to the grammar specified for the username portion of an NAI.
|
|||
|
Also, the fast re-authentication identity MUST conform to the NAI
|
|||
|
grammar. The EAP servers that the subscribers of an operator can use
|
|||
|
MUST ensure that the pseudonym usernames and the username portions
|
|||
|
used in fast re-authentication identities that they generate are
|
|||
|
unique.
|
|||
|
|
|||
|
In any case, it is necessary that permanent usernames, pseudonym
|
|||
|
usernames, and fast re-authentication usernames are separate and
|
|||
|
recognizable from each other. It is also desirable that EAP-SIM and
|
|||
|
EAP-AKA usernames be recognizable from each other as an aid to the
|
|||
|
server when deciding which method to offer.
|
|||
|
|
|||
|
In general, it is the task of the EAP server and the policies of its
|
|||
|
administrator to ensure sufficient separation of the usernames.
|
|||
|
Pseudonym usernames and fast re-authentication usernames are both
|
|||
|
produced and used by the EAP server. The EAP server MUST compose
|
|||
|
pseudonym usernames and fast re-authentication usernames so that it
|
|||
|
can recognize if an NAI username is an EAP-AKA pseudonym username or
|
|||
|
an EAP-AKA fast re-authentication username. For instance, when the
|
|||
|
usernames have been derived from the IMSI, the server could use
|
|||
|
different leading characters in the pseudonym usernames and fast
|
|||
|
re-authentication usernames (e.g., the pseudonym could begin with a
|
|||
|
leading "2" character). When mapping a fast re-authentication
|
|||
|
identity to a permanent identity, the server SHOULD only examine the
|
|||
|
username portion of the fast re-authentication identity and ignore
|
|||
|
the realm portion of the identity.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 19]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Because the peer may fail to save a pseudonym username that was sent
|
|||
|
in an EAP-Request/AKA-Challenge (for example, due to malfunction),
|
|||
|
the EAP server SHOULD maintain, at least, the most recently used
|
|||
|
pseudonym username in addition to the most recently issued pseudonym
|
|||
|
username. If the authentication exchange is not completed
|
|||
|
successfully, then the server SHOULD NOT overwrite the pseudonym
|
|||
|
username that was issued during the most recent successful
|
|||
|
authentication exchange.
|
|||
|
|
|||
|
4.1.1.8. Transmitting Pseudonyms and Fast Re-Authentication Identities
|
|||
|
to the Peer
|
|||
|
|
|||
|
The server transmits pseudonym usernames and fast re-authentication
|
|||
|
identities to the peer in cipher, using the AT_ENCR_DATA attribute.
|
|||
|
|
|||
|
The EAP-Request/AKA-Challenge message MAY include an encrypted
|
|||
|
pseudonym username and/or an encrypted fast re-authentication
|
|||
|
identity in the value field of the AT_ENCR_DATA attribute. Because
|
|||
|
identity privacy support and fast re-authentication are optional to
|
|||
|
implement, the peer MAY ignore the AT_ENCR_DATA attribute and always
|
|||
|
use the permanent identity. On fast re-authentication (discussed in
|
|||
|
Section 5), the server MAY include a new, encrypted fast re-
|
|||
|
authentication identity in the EAP-Request/AKA-Reauthentication
|
|||
|
message.
|
|||
|
|
|||
|
On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the
|
|||
|
encrypted data in AT_ENCR_DATA; and if a pseudonym username is
|
|||
|
included, the peer may use the obtained pseudonym username on the
|
|||
|
next full authentication. If a fast re-authentication identity is
|
|||
|
included, then the peer MAY save it together with other fast re-
|
|||
|
authentication state information, as discussed in Section 5, for the
|
|||
|
next fast re-authentication.
|
|||
|
|
|||
|
If the peer does not receive a new pseudonym username in the
|
|||
|
EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
|
|||
|
username instead of the permanent username on next full
|
|||
|
authentication. The username portions of fast re-authentication
|
|||
|
identities are one-time usernames, which the peer MUST NOT re-use.
|
|||
|
When the peer uses a fast re-authentication identity in an EAP
|
|||
|
exchange, the peer MUST discard the fast re-authentication identity
|
|||
|
and not re-use it in another EAP authentication exchange, even if the
|
|||
|
authentication exchange was not completed.
|
|||
|
|
|||
|
4.1.1.9. Usage of the Pseudonym by the Peer
|
|||
|
|
|||
|
When the optional identity privacy support is used on full
|
|||
|
authentication, the peer MAY use a pseudonym username received as
|
|||
|
part of a previous full authentication sequence as the username
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 20]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
portion of the NAI. The peer MUST NOT modify the pseudonym username
|
|||
|
received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer
|
|||
|
MAY need to decorate the username in some environments by appending
|
|||
|
or prepending the username with a string that indicates supplementary
|
|||
|
AAA routing information.
|
|||
|
|
|||
|
When using a pseudonym username in an environment where a realm
|
|||
|
portion is used, the peer concatenates the received pseudonym
|
|||
|
username with the "@" character and an NAI realm portion. The
|
|||
|
selection of the NAI realm is discussed above. The peer can select
|
|||
|
the realm portion similarly, regardless of whether it uses the
|
|||
|
permanent username or a pseudonym username.
|
|||
|
|
|||
|
4.1.1.10. Usage of the Fast Re-Authentication Identity by the Peer
|
|||
|
|
|||
|
On fast re-authentication, the peer uses the fast re-authentication
|
|||
|
identity received as part of the previous authentication sequence. A
|
|||
|
new fast re-authentication identity may be delivered as part of both
|
|||
|
full authentication and fast re-authentication. The peer MUST NOT
|
|||
|
modify the username part of the fast re-authentication identity
|
|||
|
received in AT_NEXT_REAUTH_ID, except in cases when username
|
|||
|
decoration is required. Even in these cases, the "root" fast
|
|||
|
re-authentication username must not be modified, but it may be
|
|||
|
appended or prepended with another string.
|
|||
|
|
|||
|
4.1.2. Communicating the Peer Identity to the Server
|
|||
|
|
|||
|
4.1.2.1. General
|
|||
|
|
|||
|
The peer identity MAY be communicated to the server with the
|
|||
|
EAP-Response/Identity message. This message MAY contain the
|
|||
|
permanent identity, a pseudonym identity, or a fast re-authentication
|
|||
|
identity. If the peer uses the permanent identity or a pseudonym
|
|||
|
identity, which the server is able to map to the permanent identity,
|
|||
|
then the authentication proceeds as discussed in the overview of
|
|||
|
Section 3. If the peer uses a fast re-authentication identity, and
|
|||
|
if the fast re-authentication identity matches with a valid fast
|
|||
|
re-authentication identity maintained by the server, then a fast
|
|||
|
re-authentication exchange is performed, as described in Section 5.
|
|||
|
|
|||
|
The peer identity can also be 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 AT_ANY_ID_REQ attribute is a
|
|||
|
general identity requesting attribute, which the server uses if it
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 21]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
does not specify which kind of an identity the peer should return in
|
|||
|
AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to
|
|||
|
request either the permanent identity or a pseudonym identity. The
|
|||
|
server uses the AT_PERMANENT_ID_REQ attribute to request that the
|
|||
|
peer send its permanent identity. The EAP-Request/AKA-Challenge,
|
|||
|
EAP-Response/AKA-Challenge, or the packets used on fast re-
|
|||
|
authentication may optionally include the AT_CHECKCODE attribute,
|
|||
|
which enables the protocol peers to ensure the integrity of the
|
|||
|
AKA-Identity packets. AT_CHECKCODE is specified in Section 10.13.
|
|||
|
|
|||
|
The identity format in the AT_IDENTITY attribute is the same as in
|
|||
|
the EAP-Response/Identity packet (except that identity decoration is
|
|||
|
not allowed). The AT_IDENTITY attribute contains a permanent
|
|||
|
identity, a pseudonym identity, or a fast re-authentication identity.
|
|||
|
|
|||
|
Please note that only the EAP-AKA peer and the EAP-AKA server process
|
|||
|
the AT_IDENTITY attribute and entities that pass through; EAP packets
|
|||
|
do not process this attribute. Hence, the authenticator and other
|
|||
|
intermediate AAA elements (such as possible AAA proxy servers) will
|
|||
|
continue to refer to the peer with the original identity from the
|
|||
|
EAP-Response/Identity packet unless the identity authenticated in the
|
|||
|
AT_IDENTITY attribute is communicated to them in another way within
|
|||
|
the AAA protocol.
|
|||
|
|
|||
|
4.1.2.2. Relying on EAP-Response/Identity Discouraged
|
|||
|
|
|||
|
The EAP-Response/Identity packet is not method specific; therefore,
|
|||
|
in many implementations it may be handled by an EAP Framework. This
|
|||
|
introduces an additional layer of processing between the EAP peer and
|
|||
|
EAP server. The extra layer of processing may cache identity
|
|||
|
responses or add decorations to the identity. A modification of the
|
|||
|
identity response will cause the EAP peer and EAP server to use
|
|||
|
different identities in the key derivation, which will cause the
|
|||
|
protocol to fail.
|
|||
|
|
|||
|
For this reason, it is RECOMMENDED that the EAP peer and server use
|
|||
|
the method-specific identity attributes in EAP-AKA, and the server is
|
|||
|
strongly discouraged from relying upon the EAP-Response/Identity.
|
|||
|
|
|||
|
In particular, if the EAP server receives a decorated identity in
|
|||
|
EAP-Response/Identity, then the EAP server MUST use the
|
|||
|
identity-requesting attributes to request the peer to send an
|
|||
|
unmodified and undecorated copy of the identity in AT_IDENTITY.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 22]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
4.1.3. Choice of Identity for the EAP-Response/Identity
|
|||
|
|
|||
|
If EAP-AKA peer is started upon receiving an EAP-Request/Identity
|
|||
|
message, then the peer MAY use an EAP-AKA identity in the EAP-
|
|||
|
Response/Identity packet. In this case, the peer performs the
|
|||
|
following steps.
|
|||
|
|
|||
|
If the peer has maintained fast re-authentication state information
|
|||
|
and if the peer wants to use fast re-authentication, then the peer
|
|||
|
transmits the fast re-authentication identity in
|
|||
|
EAP-Response/Identity.
|
|||
|
|
|||
|
Else, if the peer has a pseudonym username available, then the peer
|
|||
|
transmits the pseudonym identity in EAP-Response/Identity.
|
|||
|
|
|||
|
In other cases, the peer transmits the permanent identity in
|
|||
|
EAP-Response/Identity.
|
|||
|
|
|||
|
4.1.4. Server Operation in the Beginning of EAP-AKA Exchange
|
|||
|
|
|||
|
As discussed in Section 4.1.2.2, the server SHOULD NOT rely on an
|
|||
|
identity string received in EAP-Response/Identity. Therefore, the
|
|||
|
RECOMMENDED way to start an EAP-AKA exchange is to ignore any
|
|||
|
received identity strings. The server SHOULD begin the EAP-AKA
|
|||
|
exchange by issuing the EAP-Request/AKA-Identity packet with an
|
|||
|
identity-requesting attribute to indicate that the server wants the
|
|||
|
peer to include an identity in the AT_IDENTITY attribute of the EAP-
|
|||
|
Response/AKA-Identity message. Three methods to request an identity
|
|||
|
from the peer are discussed below.
|
|||
|
|
|||
|
If the server chooses to not ignore the contents of
|
|||
|
EAP-Response/Identity, then the server may already receive an EAP-AKA
|
|||
|
identity in this packet. However, if the EAP server has not received
|
|||
|
any EAP-AKA peer identity (permanent identity, pseudonym identity, or
|
|||
|
fast re-authentication identity) from the peer when sending the first
|
|||
|
EAP-AKA request, or if the EAP server has received an
|
|||
|
EAP-Response/Identity packet but the contents do not appear to be a
|
|||
|
valid permanent identity, pseudonym identity, or a re-authentication
|
|||
|
identity, then the server MUST request an identity from the peer
|
|||
|
using one of the methods below.
|
|||
|
|
|||
|
The server sends the EAP-Request/AKA-Identity message with the
|
|||
|
AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
|
|||
|
peer to include the permanent identity in the AT_IDENTITY attribute
|
|||
|
of the EAP-Response/AKA-Identity message. This is done in the
|
|||
|
following cases:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 23]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
o The server does not support fast re-authentication or identity
|
|||
|
privacy.
|
|||
|
o The server decided to process a received identity, and the server
|
|||
|
recognizes the received identity as a pseudonym identity, but the
|
|||
|
server is not able to map the pseudonym identity to a permanent
|
|||
|
identity.
|
|||
|
|
|||
|
The server issues the EAP-Request/AKA-Identity packet with the
|
|||
|
AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
|
|||
|
peer to include a full authentication identity (pseudonym identity or
|
|||
|
permanent identity) in the AT_IDENTITY attribute of the
|
|||
|
EAP-Response/AKA-Identity message. This is done in the following
|
|||
|
cases:
|
|||
|
|
|||
|
o The server does not support fast re-authentication and the server
|
|||
|
supports identity privacy
|
|||
|
o The server decided to process a received identity, and the server
|
|||
|
recognizes the received identity as a re-authentication identity
|
|||
|
but the server is not able to map the re-authentication identity
|
|||
|
to a permanent identity
|
|||
|
|
|||
|
The server issues the EAP-Request/AKA-Identity packet with the
|
|||
|
AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
|
|||
|
include an identity in the AT_IDENTITY attribute of the
|
|||
|
EAP-Response/AKA-Identity message, and the server does not indicate
|
|||
|
any preferred type for the identity. This is done in other cases,
|
|||
|
such as when the server ignores a received EAP-Response/Identity,
|
|||
|
when the server does not have any identity, or when the server does
|
|||
|
not recognize the format of a received identity.
|
|||
|
|
|||
|
4.1.5. Processing of EAP-Request/AKA-Identity by the Peer
|
|||
|
|
|||
|
Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST
|
|||
|
perform the following steps.
|
|||
|
|
|||
|
If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if
|
|||
|
the peer does not have a pseudonym available, then the peer MUST
|
|||
|
respond with EAP-Response/AKA-Identity and include the permanent
|
|||
|
identity in AT_IDENTITY. If the peer has a pseudonym available, then
|
|||
|
the peer MAY refuse to send the permanent identity; hence, in this
|
|||
|
case the peer MUST either respond with EAP-Response/AKA-Identity and
|
|||
|
include the permanent identity in AT_IDENTITY or respond with
|
|||
|
EAP-Response/AKA-Client-Error packet with code "unable to process
|
|||
|
packet".
|
|||
|
|
|||
|
If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if
|
|||
|
the peer has a pseudonym available, then the peer SHOULD respond with
|
|||
|
EAP-Response/AKA-Identity and include the pseudonym identity in
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 24]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
AT_IDENTITY. If the peer does not have a pseudonym when it receives
|
|||
|
this message, then the peer MUST respond with EAP-Response/
|
|||
|
AKA-Identity and include the permanent identity in AT_IDENTITY. The
|
|||
|
Peer MUST NOT use a fast re-authentication identity in the
|
|||
|
AT_IDENTITY attribute.
|
|||
|
|
|||
|
If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the
|
|||
|
peer has maintained fast re-authentication state information and
|
|||
|
wants to use fast re-authentication, then the peer responds with
|
|||
|
EAP-Response/AKA-Identity and includes the fast re-authentication
|
|||
|
identity in AT_IDENTITY. Else, if the peer has a pseudonym identity
|
|||
|
available, then the peer responds with EAP-Response/AKA-Identity and
|
|||
|
includes the pseudonym identity in AT_IDENTITY. Else, the peer
|
|||
|
responds with EAP-Response/AKA-Identity and includes the permanent
|
|||
|
identity in AT_IDENTITY.
|
|||
|
|
|||
|
An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The
|
|||
|
server may issue a second EAP-Request/AKA-Identity, if it was not
|
|||
|
able to recognize the identity the peer used in the previous
|
|||
|
AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be
|
|||
|
used, so the peer MUST NOT respond to more than three
|
|||
|
EAP-Request/AKA-Identity messages within an EAP exchange. The peer
|
|||
|
MUST verify that the sequence of EAP-Request/AKA-Identity packets the
|
|||
|
peer receives comply with the sequencing rules defined in this
|
|||
|
document. That is, AT_ANY_ID_REQ can only be used in the first
|
|||
|
EAP-Request/AKA-Identity; in other words, AT_ANY_ID_REQ MUST NOT be
|
|||
|
used in the second or third EAP-Request/AKA-Identity.
|
|||
|
AT_FULLAUTH_ID_REQ MUST NOT be used if the previous
|
|||
|
EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ. The peer
|
|||
|
operation, in cases when it receives an unexpected attribute or an
|
|||
|
unexpected message, is specified in Section 6.3.1.
|
|||
|
|
|||
|
4.1.6. Attacks against Identity Privacy
|
|||
|
|
|||
|
The section above specifies two possible ways the peer can operate
|
|||
|
upon receipt of AT_PERMANENT_ID_REQ because a received
|
|||
|
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
|
|||
|
network. However, an active attacker may transmit an
|
|||
|
EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
|
|||
|
to the peer, in an effort to find out the true identity of the user.
|
|||
|
If the peer does not want to reveal its permanent identity, then the
|
|||
|
peer sends the EAP-Response/AKA-Client-Error packet with the error
|
|||
|
code "unable to process packet", and the authentication exchange
|
|||
|
terminates.
|
|||
|
|
|||
|
Basically, there are two different policies that the peer can employ
|
|||
|
with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes
|
|||
|
that the network is able to maintain pseudonyms robustly. Therefore,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 25]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
if a conservative peer has a pseudonym username, the peer responds
|
|||
|
with EAP-Response/AKA-Client-Error to the EAP packet with
|
|||
|
AT_PERMANENT_ID_REQ, because the peer believes that the valid network
|
|||
|
is able to map the pseudonym identity to the peer's permanent
|
|||
|
identity. (Alternatively, the conservative peer may accept
|
|||
|
AT_PERMANENT_ID_REQ in certain circumstances, for example if the
|
|||
|
pseudonym was received a long time ago.) The benefit of this policy
|
|||
|
is that it protects the peer against active attacks on anonymity. On
|
|||
|
the other hand, a "liberal" peer always accepts the
|
|||
|
AT_PERMANENT_ID_REQ and responds with the permanent identity. The
|
|||
|
benefit of this policy is that it works even if the valid network
|
|||
|
sometimes loses pseudonyms and is not able to map them to the
|
|||
|
permanent identity.
|
|||
|
|
|||
|
4.1.7. Processing of AT_IDENTITY by the Server
|
|||
|
|
|||
|
When the server receives an EAP-Response/AKA-Identity message with
|
|||
|
the AT_IDENTITY (in response to the server's identity requesting
|
|||
|
attribute), the server MUST operate as follows.
|
|||
|
|
|||
|
If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
|
|||
|
not contain a valid permanent identity, then the server sends an
|
|||
|
EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
|
|||
|
"General failure" (16384) to terminate the EAP exchange. If the
|
|||
|
server recognizes the permanent identity and is able to continue,
|
|||
|
then the server proceeds with full authentication by sending
|
|||
|
EAP-Request/AKA-Challenge.
|
|||
|
|
|||
|
If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
|
|||
|
valid permanent identity or a pseudonym identity that the server can
|
|||
|
map to a valid permanent identity, then the server proceeds with full
|
|||
|
authentication by sending EAP-Request/AKA-Challenge. If AT_IDENTITY
|
|||
|
contains a pseudonym identity that the server is not able to map to a
|
|||
|
valid permanent identity, or an identity that the server is not able
|
|||
|
to recognize or classify, then the server sends EAP-Request/
|
|||
|
AKA-Identity with AT_PERMANENT_ID_REQ.
|
|||
|
|
|||
|
If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
|
|||
|
valid permanent identity or a pseudonym identity that the server can
|
|||
|
map to a valid permanent identity, then the server proceeds with full
|
|||
|
authentication by sending EAP-Request/ AKA-Challenge.
|
|||
|
|
|||
|
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
|
|||
|
fast re-authentication identity and the server agrees on using
|
|||
|
re-authentication, then the server proceeds with fast
|
|||
|
re-authentication by sending EAP-Request/AKA-Reauthentication
|
|||
|
(Section 5).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 26]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
If the server used AT_ANY_ID_REQ, and if the peer sent an EAP-
|
|||
|
Response/AKA-Identity with AT_IDENTITY that contains an identity that
|
|||
|
the server recognizes as a fast re-authentication identity, but the
|
|||
|
server is not able to map the identity to a permanent identity, then
|
|||
|
the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
|
|||
|
|
|||
|
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
|
|||
|
fast re-authentication identity, which the server is able to map to a
|
|||
|
permanent identity, and if the server does not want to use fast
|
|||
|
re-authentication, then the server proceeds with full authentication
|
|||
|
by sending EAP-Request/AKA-Challenge.
|
|||
|
|
|||
|
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
|
|||
|
identity that the server recognizes as a pseudonym identity but the
|
|||
|
server is not able to map the pseudonym identity to a permanent
|
|||
|
identity, then the server sends EAP-Request/AKA-Identity with
|
|||
|
AT_PERMANENT_ID_REQ.
|
|||
|
|
|||
|
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
|
|||
|
identity that the server is not able to recognize or classify, then
|
|||
|
the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
|
|||
|
|
|||
|
4.2. Message Sequence Examples (Informative)
|
|||
|
|
|||
|
This section contains non-normative message sequence examples to
|
|||
|
illustrate how the peer identity can be communicated to the server.
|
|||
|
|
|||
|
4.2.1. Usage of AT_ANY_ID_REQ
|
|||
|
|
|||
|
Obtaining the peer identity with EAP-AKA attributes is illustrated in
|
|||
|
Figure 5 below.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| |
|
|||
|
| +------------------------------+
|
|||
|
| | Server does not have any |
|
|||
|
| | Subscriber identity available|
|
|||
|
| | When starting EAP-AKA |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_ANY_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| |
|
|||
|
Figure 5: Usage of AT_ANY_ID_REQ
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 27]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
4.2.2. Fall Back on Full Authentication
|
|||
|
|
|||
|
Figure 6 illustrates the case when the server does not recognize the
|
|||
|
fast re-authentication identity the peer used in AT_IDENTITY.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| |
|
|||
|
| +------------------------------+
|
|||
|
| | Server does not have any |
|
|||
|
| | Subscriber identity available|
|
|||
|
| | When starting EAP-AKA |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_ANY_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY containing a fast re-auth. identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server does not recognize |
|
|||
|
| | The fast re-auth. |
|
|||
|
| | Identity |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_FULLAUTH_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY with a full-auth. Identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| |
|
|||
|
|
|||
|
Figure 6: Fall back on full authentication
|
|||
|
|
|||
|
If the server recognizes the fast re-authentication identity, but
|
|||
|
still wants to fall back on full authentication, the server may issue
|
|||
|
the EAP-Request/AKA-Challenge packet. In this case, the full
|
|||
|
authentication procedure proceeds as usual.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 28]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
4.2.3. Requesting the Permanent Identity 1
|
|||
|
|
|||
|
Figure 7 illustrates the case when the EAP server fails to decode a
|
|||
|
pseudonym identity included in the EAP-Response/Identity packet.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| EAP-Request/Identity |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/Identity |
|
|||
|
| (Includes a pseudonym) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server fails to decode the |
|
|||
|
| | Pseudonym. |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_PERMANENT_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY with permanent identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| |
|
|||
|
|
|||
|
Figure 7: Requesting the permanent identity 1
|
|||
|
|
|||
|
If the server recognizes the permanent identity, then the
|
|||
|
authentication sequence proceeds as usual with the EAP Server issuing
|
|||
|
the EAP-Request/AKA-Challenge message.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 29]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
4.2.4. Requesting the Permanent Identity 2
|
|||
|
|
|||
|
Figure 8 illustrates the case when the EAP server fails to decode the
|
|||
|
pseudonym included in the AT_IDENTITY attribute.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| |
|
|||
|
| +------------------------------+
|
|||
|
| | Server does not have any |
|
|||
|
| | Subscriber identity available|
|
|||
|
| | When starting EAP-AKA |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_ANY_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
|EAP-Response/AKA-Identity |
|
|||
|
|(AT_IDENTITY with a pseudonym identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server fails to decode the |
|
|||
|
| | Pseudonym in AT_IDENTITY |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_PERMANENT_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY with permanent identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| |
|
|||
|
|
|||
|
Figure 8: Requesting the permanent identity 2
|
|||
|
|
|||
|
4.2.5. Three EAP/AKA-Identity Round Trips
|
|||
|
|
|||
|
Figure 9 illustrates the case with three EAP/AKA-Identity round
|
|||
|
trips.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 30]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| |
|
|||
|
| +------------------------------+
|
|||
|
| | Server does not have any |
|
|||
|
| | Subscriber identity available|
|
|||
|
| | When starting EAP-AKA |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_ANY_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY with fast re-auth. identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server does not accept |
|
|||
|
| | The fast re-authentication |
|
|||
|
| | Identity |
|
|||
|
| +------------------------------+
|
|||
|
| |
|
|||
|
: :
|
|||
|
: :
|
|||
|
|
|||
|
|
|||
|
: :
|
|||
|
: :
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_FULLAUTH_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
|EAP-Response/AKA-Identity |
|
|||
|
|(AT_IDENTITY with a pseudonym identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +------------------------------+
|
|||
|
| | Server fails to decode the |
|
|||
|
| | Pseudonym in AT_IDENTITY |
|
|||
|
| +------------------------------+
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_PERMANENT_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY with permanent identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| |
|
|||
|
|
|||
|
Figure 9: Three EAP-AKA Start rounds
|
|||
|
|
|||
|
After the last EAP-Response/AKA-Identity message, the full
|
|||
|
authentication sequence proceeds as usual.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 31]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
5. Fast Re-Authentication
|
|||
|
|
|||
|
5.1. General
|
|||
|
|
|||
|
In some environments, EAP authentication may be performed frequently.
|
|||
|
Because the EAP-AKA full authentication procedure uses the AKA
|
|||
|
algorithms, and therefore requires fresh authentication vectors from
|
|||
|
the Authentication Centre, the full authentication procedure may
|
|||
|
result in many network operations when used very frequently.
|
|||
|
Therefore, EAP-AKA includes a more inexpensive fast re-authentication
|
|||
|
procedure that does not make use of the AKA algorithms and does not
|
|||
|
need new vectors from the Authentication Centre.
|
|||
|
|
|||
|
Fast re-authentication is optional to implement for both the EAP-AKA
|
|||
|
server and peer. On each EAP authentication, either one of the
|
|||
|
entities may fall back on full authentication if is does not want to
|
|||
|
use fast re-authentication.
|
|||
|
|
|||
|
Fast re-authentication is based on the keys derived on the preceding
|
|||
|
full authentication. The same K_aut and K_encr keys used in full
|
|||
|
authentication are used to protect EAP-AKA packets and attributes,
|
|||
|
and the original Master Key from full authentication is used to
|
|||
|
generate a fresh Master Session Key, as specified in Section 7.
|
|||
|
|
|||
|
The fast re-authentication exchange makes use of an unsigned 16-bit
|
|||
|
counter, included in the AT_COUNTER attribute. The counter has three
|
|||
|
goals: 1) it can be used to limit the number of successive
|
|||
|
reauthentication exchanges without full-authentication 2) it
|
|||
|
contributes to the keying material, and 3) it protects the peer and
|
|||
|
the server from replays. On full authentication, both the server and
|
|||
|
the peer initialize the counter to one. The counter value of at
|
|||
|
least one is used on the first fast re-authentication. On subsequent
|
|||
|
fast re-authentications, the counter MUST be greater than on any of
|
|||
|
the previous fast re-authentications. For example, on the second
|
|||
|
fast re-authentication, counter value is two or greater, etc. The
|
|||
|
AT_COUNTER attribute is encrypted.
|
|||
|
|
|||
|
Both the peer and the EAP server maintain a copy of the counter. The
|
|||
|
EAP server sends its counter value to the peer in the fast
|
|||
|
re-authentication request. The peer MUST verify that its counter
|
|||
|
value is less than or equal to the value sent by the EAP server.
|
|||
|
|
|||
|
The server includes an encrypted server random nonce (AT_NONCE_S) in
|
|||
|
the fast re-authentication request. The AT_MAC attribute in the
|
|||
|
peer's response is calculated over NONCE_S to provide a
|
|||
|
challenge/response authentication scheme. The NONCE_S also
|
|||
|
contributes to the new Master Session Key.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 32]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Both the peer and the server SHOULD have an upper limit for the
|
|||
|
number of subsequent fast re-authentications allowed before a full
|
|||
|
authentication needs to be performed. Because a 16-bit counter is
|
|||
|
used in fast re-authentication, the theoretical maximum number of
|
|||
|
re-authentications is reached when the counter value reaches FFFF
|
|||
|
hexadecimal. In order to use fast re-authentication, the peer and
|
|||
|
the EAP server need to store the following values: Master Key, latest
|
|||
|
counter value and the next fast re-authentication identity. K_aut
|
|||
|
and K_encr may either be stored or derived again from MK. The server
|
|||
|
may also need to store the permanent identity of the user.
|
|||
|
|
|||
|
5.2. Comparison to AKA
|
|||
|
|
|||
|
When analyzing the fast re-authentication exchange, it may be helpful
|
|||
|
to compare it with the 3rd generation Authentication and Key
|
|||
|
Agreement (AKA) exchange used on full authentication. The counter
|
|||
|
corresponds to the AKA sequence number, NONCE_S corresponds to RAND,
|
|||
|
the AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN,
|
|||
|
the AT_MAC in EAP-Response/AKA-Reauthentication corresponds to RES,
|
|||
|
AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter
|
|||
|
corresponds to the usage of the Anonymity Key. Also, the key
|
|||
|
generation on fast re-authentication, with regard to random or fresh
|
|||
|
material, is similar to AKA -- the server generates the NONCE_S and
|
|||
|
counter values, and the peer only verifies that the counter value is
|
|||
|
fresh.
|
|||
|
|
|||
|
It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER,
|
|||
|
or AT_COUNTER_TOO_SMALL attributes is not important to the security
|
|||
|
of the fast re-authentication exchange.
|
|||
|
|
|||
|
5.3. Fast Re-Authentication Identity
|
|||
|
|
|||
|
The fast re-authentication procedure makes use of separate
|
|||
|
re-authentication user identities. Pseudonyms and the permanent
|
|||
|
identity are reserved for full authentication only. If a fast
|
|||
|
re-authentication identity is lost and the network does not recognize
|
|||
|
it, the EAP server can fall back on full authentication. If the EAP
|
|||
|
server supports fast re-authentication, it MAY include the skippable
|
|||
|
AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/-
|
|||
|
AKA-Challenge message. This attribute contains a new
|
|||
|
re-authentication identity for the next fast re-authentication. The
|
|||
|
attribute also works as a capability flag that indicates that the
|
|||
|
server supports fast re-authentication and that the server wants to
|
|||
|
continue using fast re-authentication within the current context.
|
|||
|
The peer MAY ignore this attribute, in which case it will use full
|
|||
|
authentication next time. If the peer wants to use fast
|
|||
|
re-authentication, it uses this fast re-authentication identity on
|
|||
|
next authentication. Even if the peer has a fast re-authentication
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 33]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
identity, the peer MAY discard the re-authentication identity and use
|
|||
|
a pseudonym or the permanent identity instead, in which case full
|
|||
|
authentication MUST be performed. If the EAP server does not include
|
|||
|
the AT_NEXT_REAUTH_ID in the encrypted data of
|
|||
|
EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication, then
|
|||
|
the peer MUST discard its current fast re-authentication state
|
|||
|
information and perform a full authentication next time.
|
|||
|
|
|||
|
In environments where a realm portion is needed in the peer identity,
|
|||
|
the fast re-authentication identity received in AT_NEXT_REAUTH_ID
|
|||
|
MUST contain both a username portion and a realm portion, as per the
|
|||
|
NAI format. The EAP Server can choose an appropriate realm part in
|
|||
|
order to have the AAA infrastructure route subsequent fast
|
|||
|
re-authentication-related requests to the same AAA server. For
|
|||
|
example, the realm part MAY include a portion that is specific to the
|
|||
|
AAA server. Hence, it is sufficient to store the context required
|
|||
|
for fast re-authentication in the AAA server that performed the full
|
|||
|
authentication.
|
|||
|
|
|||
|
The peer MAY use the fast re-authentication identity in the
|
|||
|
EAP-Response/Identity packet or, in response to the server's
|
|||
|
AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication
|
|||
|
identity in the AT_IDENTITY attribute of the EAP-Response/
|
|||
|
AKA-Identity packet.
|
|||
|
|
|||
|
The peer MUST NOT modify the username portion of the fast
|
|||
|
re-authentication identity, but the peer MAY modify the realm portion
|
|||
|
or replace it with another realm portion. The peer might need to
|
|||
|
modify the realm in order to influence the AAA routing, for example,
|
|||
|
to make sure that the correct server is reached. It should be noted
|
|||
|
that sharing the same fast re-authentication key among several
|
|||
|
servers may have security risks, so changing the realm portion of the
|
|||
|
NAI in order to change the EAP server is not desirable.
|
|||
|
|
|||
|
Even if the peer uses a fast re-authentication identity, the server
|
|||
|
may want to fall back on full authentication, for example, because
|
|||
|
the server does not recognize the fast re-authentication identity or
|
|||
|
does not want to use fast re-authentication. If the server was able
|
|||
|
to decode the fast re-authentication identity to the permanent
|
|||
|
identity, the server issues the EAP-Request/AKA-Challenge packet to
|
|||
|
initiate full authentication. If the server was not able to recover
|
|||
|
the peer's identity from the fast re-authentication identity, the
|
|||
|
server starts the full authentication procedure by issuing an
|
|||
|
EAP-Request/AKA-Identity packet. This packet always starts a full
|
|||
|
authentication sequence if it does not include the AT_ANY_ID_REQ
|
|||
|
attribute.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 34]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
5.4. Fast Re-Authentication Procedure
|
|||
|
|
|||
|
Figure 10 illustrates the fast re-authentication procedure. In this
|
|||
|
example, the optional protected success indication is not used.
|
|||
|
Encrypted attributes are denoted with '*'. The peer uses its fast
|
|||
|
re-authentication identity in the EAP-Response/Identity packet. As
|
|||
|
discussed above, an alternative way to communicate the fast
|
|||
|
re-authentication identity to the server is for the peer to use the
|
|||
|
AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This
|
|||
|
latter case is not illustrated in the figure below, and it is only
|
|||
|
possible when the server requests that the peer send its identity by
|
|||
|
including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-Identity
|
|||
|
packet.
|
|||
|
|
|||
|
If the server recognizes the identity as a valid fast
|
|||
|
re-authentication identity, and if the server agrees to use fast
|
|||
|
re-authentication, then the server sends the EAP- Request/AKA-
|
|||
|
Reauthentication packet to the peer. This packet MUST include the
|
|||
|
encrypted AT_COUNTER attribute, with a fresh counter value, the
|
|||
|
encrypted AT_NONCE_S attribute that contains a random number chosen
|
|||
|
by the server, the AT_ENCR_DATA and the AT_IV attributes used for
|
|||
|
encryption, and the AT_MAC attribute that contains a message
|
|||
|
authentication code over the packet. The packet MAY also include an
|
|||
|
encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast
|
|||
|
re-authentication identity.
|
|||
|
|
|||
|
Fast re-authentication identities are one-time identities. If the
|
|||
|
peer does not receive a new fast re-authentication identity, it MUST
|
|||
|
use either the permanent identity or a pseudonym identity on the next
|
|||
|
authentication to initiate full authentication.
|
|||
|
|
|||
|
The peer verifies that AT_MAC is correct and that the counter value
|
|||
|
is fresh (greater than any previously used value). The peer MAY save
|
|||
|
the next fast re-authentication identity from the encrypted
|
|||
|
AT_NEXT_REAUTH_ID for next time. If all checks are successful, the
|
|||
|
peer responds with the EAP-Response/AKA-Reauthentication packet,
|
|||
|
including the AT_COUNTER attribute with the same counter value and
|
|||
|
the AT_MAC attribute.
|
|||
|
|
|||
|
The server verifies the AT_MAC attribute and also verifies that the
|
|||
|
counter value is the same that it used in the
|
|||
|
EAP-Request/AKA-Reauthentication packet. If these checks are
|
|||
|
successful, the fast re-authentication has succeeded and the server
|
|||
|
sends the EAP-Success packet to the peer.
|
|||
|
|
|||
|
If protected success indications (Section 6.2) were used, the
|
|||
|
EAP-Success packet would be preceded by an EAP-AKA notification
|
|||
|
round.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 35]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| |
|
|||
|
| EAP-Request/Identity |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/Identity |
|
|||
|
| (Includes a fast re-authentication identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +--------------------------------+
|
|||
|
| | Server recognizes the identity |
|
|||
|
| | and agrees on using fast |
|
|||
|
| | re-authentication |
|
|||
|
| +--------------------------------+
|
|||
|
| EAP-Request/AKA-Reauthentication |
|
|||
|
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
|
|||
|
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
: :
|
|||
|
: :
|
|||
|
|
|||
|
|
|||
|
: :
|
|||
|
: :
|
|||
|
| |
|
|||
|
+-----------------------------------------------+ |
|
|||
|
| Peer verifies AT_MAC and the freshness of | |
|
|||
|
| the counter. Peer MAY store the new re- | |
|
|||
|
| authentication identity for next re-auth. | |
|
|||
|
+-----------------------------------------------+ |
|
|||
|
| |
|
|||
|
| EAP-Response/AKA-Reauthentication |
|
|||
|
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
|
|||
|
| AT_MAC) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +--------------------------------+
|
|||
|
| | Server verifies AT_MAC and |
|
|||
|
| | the counter |
|
|||
|
| +--------------------------------+
|
|||
|
| EAP-Success |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
|
|||
|
Figure 10: Reauthentication
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 36]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
5.5. Fast Re-Authentication Procedure when Counter is Too Small
|
|||
|
|
|||
|
If the peer does not accept the counter value of EAP-Request/
|
|||
|
AKA-Reauthentication, it indicates the counter synchronization
|
|||
|
problem by including the encrypted AT_COUNTER_TOO_SMALL in
|
|||
|
EAP-Response/AKA-Reauthentication. The server responds with
|
|||
|
EAP-Request/AKA-Challenge to initiate a normal full authentication
|
|||
|
procedure. This is illustrated in Figure 11. Encrypted attributes
|
|||
|
are denoted with '*'.
|
|||
|
|
|||
|
Peer Authenticator
|
|||
|
| EAP-Request/AKA-Identity |
|
|||
|
| (AT_ANY_ID_REQ) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
| |
|
|||
|
| EAP-Response/AKA-Identity |
|
|||
|
| (AT_IDENTITY) |
|
|||
|
| (Includes a fast re-authentication identity) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| |
|
|||
|
| EAP-Request/AKA-Reauthentication |
|
|||
|
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
|
|||
|
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|
|||
|
|<------------------------------------------------------|
|
|||
|
+-----------------------------------------------+ |
|
|||
|
| AT_MAC is valid but the counter is not fresh. | |
|
|||
|
+-----------------------------------------------+ |
|
|||
|
| EAP-Response/AKA-Reauthentication |
|
|||
|
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, |
|
|||
|
| *AT_COUNTER, AT_MAC) |
|
|||
|
|------------------------------------------------------>|
|
|||
|
| +----------------------------------------------+
|
|||
|
| | Server verifies AT_MAC but detects |
|
|||
|
| | That peer has included AT_COUNTER_TOO_SMALL|
|
|||
|
| +----------------------------------------------+
|
|||
|
| EAP-Request/AKA-Challenge |
|
|||
|
|<------------------------------------------------------|
|
|||
|
+---------------------------------------------------------------+
|
|||
|
| Normal full authentication follows. |
|
|||
|
+---------------------------------------------------------------+
|
|||
|
| |
|
|||
|
|
|||
|
Figure 11: Fast re-authentication counter too small
|
|||
|
|
|||
|
In the figure above, the first three messages are similar to the
|
|||
|
basic fast re-authentication case. When the peer detects that the
|
|||
|
counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
|
|||
|
attribute in EAP-Response/AKA-Reauthentication. This attribute
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 37]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
doesn't contain any data but it is a request for the server to
|
|||
|
initiate full authentication. In this case, the peer MUST ignore the
|
|||
|
contents of the server's AT_NEXT_REAUTH_ID attribute.
|
|||
|
|
|||
|
On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
|
|||
|
verifies that AT_COUNTER contains the same counter value as in the
|
|||
|
EAP-Request/AKA-Reauthentication packet. If not, the server
|
|||
|
terminates the authentication exchange by sending the
|
|||
|
EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
|
|||
|
"General failure" (16384). If all checks on the packet are
|
|||
|
successful, the server transmits an EAP-Request/AKA-Challenge packet
|
|||
|
and the full authentication procedure is performed as usual. Because
|
|||
|
the server already knows the subscriber identity, it MUST NOT use the
|
|||
|
EAP-Request/AKA-Identity packet to request the identity.
|
|||
|
|
|||
|
It should be noted that in this case, peer identity is only
|
|||
|
transmitted in the AT_IDENTITY attribute at the beginning of the
|
|||
|
whole EAP exchange. The fast re-authentication identity used in this
|
|||
|
AT_IDENTITY attribute will be used in key derivation (see Section 7).
|
|||
|
|
|||
|
6. EAP-AKA Notifications
|
|||
|
|
|||
|
6.1. General
|
|||
|
|
|||
|
EAP-AKA does not prohibit the use of the EAP Notifications as
|
|||
|
specified in [RFC3748]. EAP Notifications can be used at any time in
|
|||
|
the EAP-AKA exchange. It should be noted that EAP-AKA does not
|
|||
|
protect EAP Notifications. EAP-AKA also specifies method-specific
|
|||
|
EAP-AKA notifications, which are protected in some cases.
|
|||
|
|
|||
|
The EAP server can use EAP-AKA notifications to convey notifications
|
|||
|
and result indications (Section 6.2) to the peer.
|
|||
|
|
|||
|
The server MUST use notifications in cases discussed in
|
|||
|
Section 6.3.2. When the EAP server issues an
|
|||
|
EAP-Request/AKA-Notification packet to the peer, the peer MUST
|
|||
|
process the notification packet. The peer MAY show a notification
|
|||
|
message to the user and the peer MUST respond to the EAP server with
|
|||
|
an EAP-Response/AKA-Notification packet, even if the peer did not
|
|||
|
recognize the notification code.
|
|||
|
|
|||
|
An EAP-AKA full authentication exchange or a fast re-authentication
|
|||
|
exchange MUST NOT include more than one EAP-AKA notification round.
|
|||
|
|
|||
|
The notification code is a 16-bit number. The most significant bit
|
|||
|
is called the Success bit (S bit). The S bit specifies whether the
|
|||
|
notification implies failure. The code values with the S bit set to
|
|||
|
zero (code values 0...32767) are used on unsuccessful cases. The
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 38]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
receipt of a notification code from this range implies failed EAP
|
|||
|
exchange, so the peer can use the notification as a failure
|
|||
|
indication. After receiving the EAP-Response/AKA-Notification for
|
|||
|
these notification codes, the server MUST send the EAP-Failure
|
|||
|
packet.
|
|||
|
|
|||
|
The receipt of a notification code with the S bit set to one (values
|
|||
|
32768...65536) does not imply failure. Notification code "Success"
|
|||
|
(32768) has been reserved as a general notification code to indicate
|
|||
|
successful authentication.
|
|||
|
|
|||
|
The second most significant bit of the notification code is called
|
|||
|
the Phase bit (P bit). It specifies at which phase of the EAP-AKA
|
|||
|
exchange the notification can be used. If the P bit is set to zero,
|
|||
|
the notification can only be used after a successful EAP/AKA-
|
|||
|
Challenge round in full authentication or a successful EAP/AKA-
|
|||
|
Reauthentication round in re-authentication. A re-authentication
|
|||
|
round is considered successful only if the peer has successfully
|
|||
|
verified AT_MAC and AT_COUNTER attributes, and does not include the
|
|||
|
AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.
|
|||
|
|
|||
|
If the P bit is set to one, the notification can only by used before
|
|||
|
the EAP/AKA-Challenge round in full authentication or before the
|
|||
|
EAP/AKA-Reauthentication round in reauthentication. These
|
|||
|
notifications can only be used to indicate various failure cases. In
|
|||
|
other words, if the P bit is set to one, then the S bit MUST be set
|
|||
|
to zero.
|
|||
|
|
|||
|
Section 9.10 and Section 9.11 specify what other attributes must be
|
|||
|
included in the notification packets.
|
|||
|
|
|||
|
Some of the notification codes are authorization related and hence
|
|||
|
not usually considered as part of the responsibility of an EAP
|
|||
|
method. However, they are included as part of EAP-AKA because there
|
|||
|
are currently no other ways to convey this information to the user in
|
|||
|
a localizable way, and the information is potentially useful for the
|
|||
|
user. An EAP-AKA server implementation may decide never to send
|
|||
|
these EAP-AKA notifications.
|
|||
|
|
|||
|
6.2. Result Indications
|
|||
|
|
|||
|
As discussed in Section 6.3, the server and the peer use explicit
|
|||
|
error messages in all error cases. If the server detects an error
|
|||
|
after successful authentication, the server uses an EAP-AKA
|
|||
|
notification to indicate failure to the peer. In this case, the
|
|||
|
result indication is integrity and replay protected.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 39]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
By sending an EAP-Response/AKA-Challenge packet or an
|
|||
|
EAP-Response/AKA-Reauthentication packet (without
|
|||
|
AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
|
|||
|
authenticated the server and that the peer's local policy accepts the
|
|||
|
EAP exchange. In other words, these packets are implicit success
|
|||
|
indications from the peer to the server.
|
|||
|
|
|||
|
EAP-AKA also supports optional protected success indications from the
|
|||
|
server to the peer. If the EAP server wants to use protected success
|
|||
|
indications, it includes the AT_RESULT_IND attribute in the
|
|||
|
EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication
|
|||
|
packet. This attribute indicates that the EAP server would like to
|
|||
|
use result indications in both successful and unsuccessful cases. If
|
|||
|
the peer also wants this, the peer includes AT_RESULT_IND in
|
|||
|
EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication. The
|
|||
|
peer MUST NOT include AT_RESULT_IND if it did not receive
|
|||
|
AT_RESULT_IND from the server. If both the peer and the server used
|
|||
|
AT_RESULT_IND, then the EAP exchange is not complete yet, but an
|
|||
|
EAP-AKA notification round will follow. The following EAP-AKA
|
|||
|
notification may indicate either failure or success.
|
|||
|
|
|||
|
Success indications with the AT_NOTIFICATION code "Success" (32768)
|
|||
|
can only be used if both the server and the peer indicate they want
|
|||
|
to use them with AT_RESULT_IND. If the server did not include
|
|||
|
AT_RESULT_IND in the EAP-Request/AKA-Challenge or
|
|||
|
EAP-Request/AKA-Reauthentication packet, or if the peer did not
|
|||
|
include AT_RESULT_IND in the corresponding response packet, then the
|
|||
|
server MUST NOT use protected success indications.
|
|||
|
|
|||
|
Because the server uses the AT_NOTIFICATION code "Success" (32768) to
|
|||
|
indicate that the EAP exchange has completed successfully, the EAP
|
|||
|
exchange cannot fail when the server processes the EAP-AKA response
|
|||
|
to this notification. Hence, the server MUST ignore the contents of
|
|||
|
the EAP-AKA response it receives to the EAP-Request/AKA-Notification
|
|||
|
with this code. Regardless of the contents of the EAP-AKA response,
|
|||
|
the server MUST send EAP-Success as the next packet.
|
|||
|
|
|||
|
6.3. Error Cases
|
|||
|
|
|||
|
This section specifies the operation of the peer and the server in
|
|||
|
error cases. The subsections below require the EAP-AKA peer and
|
|||
|
server to send an error packet (EAP-Response/AKA-Client-Error,
|
|||
|
EAP-Response/AKA-Authentication-Reject or
|
|||
|
EAP-Response/AKA-Synchronization-Failure from the peer and
|
|||
|
EAP-Request/AKA-Notification from the server) in error cases.
|
|||
|
However, implementations SHOULD NOT rely upon the correct error
|
|||
|
reporting behavior of the peer, authenticator, or server. It is
|
|||
|
possible for error messages and other messages to be lost in transit,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 40]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
or for a malicious participant to attempt to consume resources by not
|
|||
|
issuing error messages. Both the peer and the EAP server SHOULD have
|
|||
|
a mechanism to clean up state even if an error message or EAP-Success
|
|||
|
is not received after a timeout period.
|
|||
|
|
|||
|
6.3.1. Peer Operation
|
|||
|
|
|||
|
Two special error messages have been specified for error cases that
|
|||
|
are related to the processing of the AKA AUTN parameter, as described
|
|||
|
in Section 3: (1) if the peer does not accept AUTN, the peer responds
|
|||
|
with EAP-Response/AKA-Authentication-Reject (Section 9.5), and the
|
|||
|
server issues EAP-Failure, and (2) if the peer detects that the
|
|||
|
sequence number in AUTN is not correct, the peer responds with
|
|||
|
EAP-Response/AKA-Synchronization-Failure (Section 9.6), and the
|
|||
|
server proceeds with a new EAP-Request/AKA-Challenge.
|
|||
|
|
|||
|
In other error cases, when an EAP-AKA peer detects an error in a
|
|||
|
received EAP-AKA packet, the EAP-AKA peer responds with the
|
|||
|
EAP-Response/AKA-Client-Error packet. In response to the
|
|||
|
EAP-Response/AKA-Client-Error, the EAP server MUST issue the
|
|||
|
EAP-Failure packet, and the authentication exchange terminates.
|
|||
|
|
|||
|
By default, the peer uses the client error code 0, "unable to process
|
|||
|
packet". This error code is used in the following cases:
|
|||
|
|
|||
|
o EAP exchange is not acceptable according to the peer's local
|
|||
|
policy.
|
|||
|
o The peer is not able to parse the EAP request, i.e., the EAP
|
|||
|
request is malformed.
|
|||
|
o The peer encountered a malformed attribute.
|
|||
|
o Wrong attribute types or duplicate attributes have been included
|
|||
|
in the EAP request.
|
|||
|
o A mandatory attribute is missing.
|
|||
|
o Unrecognized non-skippable attribute.
|
|||
|
o Unrecognized or unexpected EAP-AKA Subtype in the EAP request.
|
|||
|
o Invalid AT_MAC. The peer SHOULD log this event.
|
|||
|
o Invalid AT_CHECKCODE. The peer SHOULD log this event.
|
|||
|
o Invalid pad bytes in AT_PADDING.
|
|||
|
o The peer does not want to process AT_PERMANENT_ID_REQ.
|
|||
|
|
|||
|
6.3.2. Server Operation
|
|||
|
|
|||
|
If an EAP-AKA server detects an error in a received EAP-AKA response,
|
|||
|
the server MUST issue the EAP-Request/AKA-Notification packet with an
|
|||
|
AT_NOTIFICATION code that implies failure. By default, the server
|
|||
|
uses one of the general failure codes ("General failure after
|
|||
|
authentication" (0) or "General failure" (16384)). The choice
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 41]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
between these two codes depends on the phase of the EAP-AKA exchange,
|
|||
|
see Section 6. The error cases when the server issues an
|
|||
|
EAP-Request/AKA-Notification that implies failure include the
|
|||
|
following:
|
|||
|
|
|||
|
o The server is not able to parse the peer's EAP response.
|
|||
|
o The server encounters a malformed attribute, a non-recognized
|
|||
|
non-skippable attribute, or a duplicate attribute.
|
|||
|
o A mandatory attribute is missing or an invalid attribute was
|
|||
|
included.
|
|||
|
o Unrecognized or unexpected EAP-AKA Subtype in the EAP Response.
|
|||
|
o Invalid AT_MAC. The server SHOULD log this event.
|
|||
|
o Invalid AT_CHECKCODE. The server SHOULD log this event.
|
|||
|
o Invalid AT_COUNTER.
|
|||
|
|
|||
|
6.3.3. EAP-Failure
|
|||
|
|
|||
|
The EAP-AKA server sends EAP-Failure in three cases:
|
|||
|
|
|||
|
1. In response to an EAP-Response/AKA-Client-Error packet the server
|
|||
|
has received from the peer, or
|
|||
|
|
|||
|
2. In response to an EAP-Response/AKA-Authentication-Reject packet
|
|||
|
the server has received from the peer, or
|
|||
|
|
|||
|
3. Following an EAP-AKA notification round, when the AT_NOTIFICATION
|
|||
|
code implies failure.
|
|||
|
|
|||
|
The EAP-AKA server MUST NOT send EAP-Failure in other cases than
|
|||
|
these three. However, it should be noted that even though the
|
|||
|
EAP-AKA server would not send an EAP-Failure, an authorization
|
|||
|
decision that happens outside EAP-AKA, such as in the AAA server or
|
|||
|
in an intermediate AAA proxy, may result in a failed exchange.
|
|||
|
|
|||
|
The peer MUST accept the EAP-Failure packet in case 1), case 2), and
|
|||
|
case 3) above. The peer SHOULD silently discard the EAP-Failure
|
|||
|
packet in other cases.
|
|||
|
|
|||
|
6.3.4. EAP-Success
|
|||
|
|
|||
|
On full authentication, the server can only send EAP-Success after
|
|||
|
the EAP/AKA-Challenge round. The peer MUST silently discard any
|
|||
|
EAP-Success packets if they are received before the peer has
|
|||
|
successfully authenticated the server and sent the
|
|||
|
EAP-Response/AKA-Challenge packet.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 42]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
If the peer did not indicate that it wants to use protected success
|
|||
|
indications with AT_RESULT_IND (as discussed in Section 6.2) on full
|
|||
|
authentication, then the peer MUST accept EAP-Success after a
|
|||
|
successful EAP/AKA-Challenge round.
|
|||
|
|
|||
|
If the peer indicated that it wants to use protected success
|
|||
|
indications with AT_RESULT_IND (as discussed in Section 6.2), then
|
|||
|
the peer MUST NOT accept EAP-Success after a successful EAP/
|
|||
|
AKA-Challenge round. In this case, the peer MUST only accept
|
|||
|
EAP-Success after receiving an EAP-AKA Notification with the
|
|||
|
AT_NOTIFICATION code "Success" (32768).
|
|||
|
|
|||
|
On fast re-authentication, EAP-Success can only be sent after the
|
|||
|
EAP/AKA-Reauthentication round. The peer MUST silently discard any
|
|||
|
EAP-Success packets if they are received before the peer has
|
|||
|
successfully authenticated the server and sent the
|
|||
|
EAP-Response/AKA-Reauthentication packet.
|
|||
|
|
|||
|
If the peer did not indicate that it wants to use protected success
|
|||
|
indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
|
|||
|
re-authentication, then the peer MUST accept EAP-Success after a
|
|||
|
successful EAP/AKA-Reauthentication round.
|
|||
|
|
|||
|
If the peer indicated that it wants to use protected success
|
|||
|
indications with AT_RESULT_IND (as discussed in Section 6.2), then
|
|||
|
the peer MUST NOT accept EAP-Success after a successful EAP/AKA-
|
|||
|
Reauthentication round. In this case, the peer MUST only accept
|
|||
|
EAP-Success after receiving an EAP-AKA Notification with the
|
|||
|
AT_NOTIFICATION code "Success" (32768).
|
|||
|
|
|||
|
If the peer receives an EAP-AKA notification (Section 6) that
|
|||
|
indicates failure, then the peer MUST no longer accept the
|
|||
|
EAP-Success packet, even if the server authentication was
|
|||
|
successfully completed.
|
|||
|
|
|||
|
7. Key Generation
|
|||
|
|
|||
|
This section specifies how keying material is generated.
|
|||
|
|
|||
|
On EAP-AKA full authentication, a Master Key (MK) is derived from the
|
|||
|
underlying AKA values (CK and IK keys), and the identity, as follows.
|
|||
|
|
|||
|
MK = SHA1(Identity|IK|CK)
|
|||
|
|
|||
|
In the formula above, the "|" character denotes concatenation.
|
|||
|
Identity denotes the peer identity string without any terminating
|
|||
|
null characters. It is the identity from the last AT_IDENTITY
|
|||
|
attribute sent by the peer in this exchange, or, if AT_IDENTITY was
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 43]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
not used, the identity from the EAP-Response/Identity packet. The
|
|||
|
identity string is included as-is, without any changes. As discussed
|
|||
|
in Section 4.1.2.2, relying on EAP-Response/Identity for conveying
|
|||
|
the EAP-AKA peer identity is discouraged, and the server SHOULD use
|
|||
|
the EAP-AKA method-specific identity attributes. The hash function
|
|||
|
SHA-1 is specified in [SHA-1].
|
|||
|
|
|||
|
The Master Key is fed into a Pseudo-Random number Function (PRF),
|
|||
|
which generates separate Transient EAP Keys (TEKs) for protecting
|
|||
|
EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
|
|||
|
security and an Extended Master Session Key (EMSK) for other
|
|||
|
purposes. On fast re-authentication, the same TEKs MUST be used for
|
|||
|
protecting EAP packets, but a new MSK and a new EMSK MUST be derived
|
|||
|
from the original MK and from new values exchanged in the fast
|
|||
|
re-authentication.
|
|||
|
|
|||
|
EAP-AKA requires two TEKs for its own purposes: the authentication
|
|||
|
key K_aut, to be used with the AT_MAC attribute, and the encryption
|
|||
|
key K_encr, to be used with the AT_ENCR_DATA attribute. The same
|
|||
|
K_aut and K_encr keys are used in full authentication and subsequent
|
|||
|
fast re-authentications.
|
|||
|
|
|||
|
Key derivation is based on the random number generation specified in
|
|||
|
NIST Federal Information Processing Standards (FIPS) Publication
|
|||
|
186-2 [PRF]. The pseudo-random number generator is specified in the
|
|||
|
change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
|
|||
|
specified in the change notice (page 74), when Algorithm 1 is used as
|
|||
|
a general-purpose pseudo-random number generator, the "mod q" term in
|
|||
|
step 3.3 is omitted. The function G used in the algorithm is
|
|||
|
constructed via Secure Hash Standard as specified in Appendix 3.3 of
|
|||
|
the standard. It should be noted that the function G is very similar
|
|||
|
to SHA-1, but the message padding is different. Please refer to
|
|||
|
[PRF] for full details. For convenience, the random number algorithm
|
|||
|
with the correct modification is cited in Annex A.
|
|||
|
|
|||
|
160-bit XKEY and XVAL values are used, so b = 160. On each full
|
|||
|
authentication, the Master Key is used as the initial secret seed-key
|
|||
|
XKEY. The optional user input values (XSEED_j) in step 3.1 are set
|
|||
|
to zero.
|
|||
|
|
|||
|
On full authentication, the resulting 320-bit random numbers x_0,
|
|||
|
x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized
|
|||
|
chunks and used as keys in the following order: K_encr (128 bits),
|
|||
|
K_aut (128 bits), Master Session Key (64 bytes), Extended Master
|
|||
|
Session Key (64 bytes).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 44]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
On fast re-authentication, the same pseudo-random number generator
|
|||
|
can be used to generate a new Master Session Key and a new Extended
|
|||
|
Master Session Key. The seed value XKEY' is calculated as follows:
|
|||
|
|
|||
|
XKEY' = SHA1(Identity|counter|NONCE_S| MK)
|
|||
|
|
|||
|
In the formula above, the Identity denotes the fast re-authentication
|
|||
|
identity, without any terminating null characters, from the
|
|||
|
AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if
|
|||
|
EAP-Response/AKA-Identity was not used on fast re-authentication, it
|
|||
|
denotes the identity string from the EAP-Response/Identity packet.
|
|||
|
The counter denotes the counter value from the AT_COUNTER attribute
|
|||
|
used in the EAP-Response/AKA-Reauthentication packet. The counter is
|
|||
|
used in network byte order. NONCE_S denotes the 16-byte random
|
|||
|
NONCE_S value from the AT_NONCE_S attribute used in the
|
|||
|
EAP-Request/AKA-Reauthentication packet. The MK is the Master Key
|
|||
|
derived on the preceding full authentication.
|
|||
|
|
|||
|
On fast re-authentication, the pseudo-random number generator is run
|
|||
|
with the new seed value XKEY', and the resulting 320-bit random
|
|||
|
numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into
|
|||
|
64-byte chunks and used as the new 64-byte Master Session Key and the
|
|||
|
new 64-byte Extended Master Session Key. Note that because K_encr
|
|||
|
and K_aut are not derived on fast re-authentication, the Master
|
|||
|
Session Key and the Extended Master Session key are obtained from the
|
|||
|
beginning of the key stream x_0, x_1, ....
|
|||
|
|
|||
|
The first 32 bytes of the MSK can be used as the Pairwise Master Key
|
|||
|
(PMK) for IEEE 802.11i.
|
|||
|
|
|||
|
When the RADIUS attributes specified in [RFC2548] are used to
|
|||
|
transport keying material, then the first 32 bytes of the MSK
|
|||
|
correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
|
|||
|
MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material
|
|||
|
(the MSK) are used.
|
|||
|
|
|||
|
8. Message Format and Protocol Extensibility
|
|||
|
|
|||
|
8.1. Message Format
|
|||
|
|
|||
|
As specified in [RFC3748], EAP packets begin with the Code,
|
|||
|
Identifiers, Length, and Type fields, which are followed by
|
|||
|
EAP-method-specific Type-Data. The Code field in the EAP header is
|
|||
|
set to 1 for EAP requests, and to 2 for EAP Responses. The usage of
|
|||
|
the Length and Identifier fields in the EAP header is also specified
|
|||
|
in [RFC3748]. In EAP-AKA, the Type field is set to 23.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 45]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists
|
|||
|
of a 1-octet Subtype field, and a 2-octet reserved field. The
|
|||
|
Subtype values used in EAP-AKA are defined in Section 11. The
|
|||
|
formats of the EAP header and the EAP-AKA header are 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
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Code | Identifier | Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Type | Subtype | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The rest of the Type-Data, immediately following the EAP-AKA header,
|
|||
|
consists of attributes that are encoded in Type, Length, Value
|
|||
|
format. The figure below shows the generic format of an attribute.
|
|||
|
|
|||
|
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
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|Attribute Type | Length | Value...
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Attribute Type
|
|||
|
|
|||
|
Indicates the particular type of attribute. The attribute type
|
|||
|
values are listed in Section 11.
|
|||
|
|
|||
|
Length
|
|||
|
|
|||
|
Indicates the length of this attribute in multiples of 4 bytes.
|
|||
|
The maximum length of an attribute is 1024 bytes. The length
|
|||
|
includes the Attribute Type and Length bytes.
|
|||
|
|
|||
|
Value
|
|||
|
|
|||
|
The particular data associated with this attribute. This field
|
|||
|
is always included and it is two or more bytes in length. The
|
|||
|
type and length fields determine the format and length of the
|
|||
|
value field.
|
|||
|
|
|||
|
Attributes numbered within the range 0 through 127 are called
|
|||
|
non-skippable attributes. When an EAP-AKA peer encounters a
|
|||
|
non-skippable attribute type that the peer does not recognize, the
|
|||
|
peer MUST send the EAP-Response/AKA-Client-Error packet, and the
|
|||
|
authentication exchange terminates. If an EAP-AKA server encounters
|
|||
|
a non-skippable attribute that the server does not recognize, then
|
|||
|
the server sends EAP-Request/AKA-Notification packet with an
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 46]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
AT_NOTIFICATION code that implies general failure ("General failure
|
|||
|
after authentication" (0), or "General failure" (16384), depending on
|
|||
|
the phase of the exchange), and the authentication exchange
|
|||
|
terminates.
|
|||
|
|
|||
|
When an attribute numbered in the range 128 through 255 is
|
|||
|
encountered but not recognized, that particular attribute is ignored,
|
|||
|
but the rest of the attributes and message data MUST still be
|
|||
|
processed. The Length field of the attribute is used to skip the
|
|||
|
attribute value when searching for the next attribute. These
|
|||
|
attributes are called skippable attributes.
|
|||
|
|
|||
|
Unless otherwise specified, the order of the attributes in an EAP-AKA
|
|||
|
message is insignificant, and an EAP-AKA implementation should not
|
|||
|
assume a certain order will be used.
|
|||
|
|
|||
|
Attributes can be encapsulated within other attributes. In other
|
|||
|
words, the value field of an attribute type can be specified to
|
|||
|
contain other attributes.
|
|||
|
|
|||
|
8.2. Protocol Extensibility
|
|||
|
|
|||
|
EAP-AKA can be extended by specifying new attribute types. If
|
|||
|
skippable attributes are used, it is possible to extend the protocol
|
|||
|
without breaking old implementations. As specified in Section 10.13,
|
|||
|
if new attributes are specified for EAP-Request/AKA-Identity or
|
|||
|
EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to
|
|||
|
integrity protect the new attributes.
|
|||
|
|
|||
|
When specifying new attributes, it should be noted that EAP-AKA does
|
|||
|
not support message fragmentation. Hence, the sizes of the new
|
|||
|
extensions MUST be limited so that the maximum transfer unit (MTU) of
|
|||
|
the underlying lower layer is not exceeded. According to [RFC3748],
|
|||
|
lower layers must provide an EAP MTU of 1020 bytes or greater, so any
|
|||
|
extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes.
|
|||
|
|
|||
|
EAP-AKA packets do not include a version field. However, should
|
|||
|
there be a reason to revise this protocol in the future, new
|
|||
|
non-skippable or skippable attributes could be specified in order to
|
|||
|
implement revised EAP-AKA versions in a backward-compatible manner.
|
|||
|
It is possible to introduce version negotiation in the
|
|||
|
EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by
|
|||
|
specifying new skippable attributes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 47]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
9. Messages
|
|||
|
|
|||
|
This section specifies the messages used in EAP-AKA. It specifies
|
|||
|
when a message may be transmitted or accepted, which attributes are
|
|||
|
allowed in a message, which attributes are required in a message, and
|
|||
|
other message-specific details. Message format is specified in
|
|||
|
Section 8.1.
|
|||
|
|
|||
|
9.1. EAP-Request/AKA-Identity
|
|||
|
|
|||
|
The EAP/AKA-Identity roundtrip MAY be used for obtaining the peer
|
|||
|
identity from the server. As discussed in Section 4.1, several
|
|||
|
AKA-Identity rounds may be required in order to obtain a valid peer
|
|||
|
identity.
|
|||
|
|
|||
|
The server MUST include one of the following identity requesting
|
|||
|
attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ.
|
|||
|
These three attributes are mutually exclusive, so the server MUST NOT
|
|||
|
include more than one of the attributes.
|
|||
|
|
|||
|
If the server has previously issued an EAP-Request/AKA-Identity
|
|||
|
message with the AT_PERMANENT_ID_REQ attribute, and if the server has
|
|||
|
received a response from the peer, then the server MUST NOT issue a
|
|||
|
new EAP-Request/AKA-Identity packet.
|
|||
|
|
|||
|
If the server has previously issued an EAP-Request/AKA-Identity
|
|||
|
message with the AT_FULLAUTH_ID_REQ attribute, and if the server has
|
|||
|
received a response from the peer, then the server MUST NOT issue a
|
|||
|
new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or
|
|||
|
AT_FULLAUTH_ID_REQ attributes.
|
|||
|
|
|||
|
If the server has previously issued an EAP-Request/AKA-Identity
|
|||
|
message with the AT_ANY_ID_REQ attribute, and if the server has
|
|||
|
received a response from the peer, then the server MUST NOT issue a
|
|||
|
new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ.
|
|||
|
|
|||
|
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
|
|||
|
|
|||
|
9.2. EAP-Response/AKA-Identity
|
|||
|
|
|||
|
The peer sends EAP-Response/AKA-Identity in response to a valid
|
|||
|
EAP-Request/AKA-Identity from the server.
|
|||
|
|
|||
|
The peer MUST include the AT_IDENTITY attribute. The usage of
|
|||
|
AT_IDENTITY is defined in Section 4.1.
|
|||
|
|
|||
|
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 48]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
9.3. EAP-Request/AKA-Challenge
|
|||
|
|
|||
|
The server sends the EAP-Request/AKA-Challenge on full authentication
|
|||
|
after successfully obtaining the subscriber identity.
|
|||
|
|
|||
|
The AT_RAND attribute MUST be included.
|
|||
|
|
|||
|
AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no
|
|||
|
message-specific data covered by the MAC, see Section 10.15.
|
|||
|
|
|||
|
The AT_RESULT_IND attribute MAY be included. The usage of this
|
|||
|
attribute is discussed in Section 6.2.
|
|||
|
|
|||
|
The AT_CHECKCODE attribute MAY be included, and in certain cases
|
|||
|
specified in Section 10.13, it MUST be included.
|
|||
|
|
|||
|
The EAP-Request/AKA-Challenge packet MAY include encrypted attributes
|
|||
|
for identity privacy and for communicating the next re-authentication
|
|||
|
identity. In this case, the AT_IV and AT_ENCR_DATA attributes are
|
|||
|
included (Section 10.12).
|
|||
|
|
|||
|
The plaintext of the AT_ENCR_DATA value field consists of nested
|
|||
|
attributes. The nested attributes MAY include AT_PADDING (as
|
|||
|
specified in Section 10.12). If the server supports identity privacy
|
|||
|
and wants to communicate a pseudonym to the peer for the next full
|
|||
|
authentication, then the nested encrypted attributes include the
|
|||
|
AT_NEXT_PSEUDONYM attribute. If the server supports
|
|||
|
re-authentication and wants to communicate a fast re-authentication
|
|||
|
identity to the peer, then the nested encrypted attributes include
|
|||
|
the AT_NEXT_REAUTH_ID attribute. Later versions of this protocol MAY
|
|||
|
specify additional attributes to be included within the encrypted
|
|||
|
data.
|
|||
|
|
|||
|
When processing this message, the peer MUST process AT_RAND and
|
|||
|
AT_AUTN before processing other attributes. Only if these attributes
|
|||
|
are verified to be valid, the peer derives keys and verifies AT_MAC.
|
|||
|
The operation in case an error occurs is specified in Section 6.3.1.
|
|||
|
|
|||
|
9.4. EAP-Response/AKA-Challenge
|
|||
|
|
|||
|
The peer sends EAP-Response/AKA-Challenge in response to a valid
|
|||
|
EAP-Request/AKA-Challenge.
|
|||
|
|
|||
|
Sending this packet indicates that the peer has successfully
|
|||
|
authenticated the server and that the EAP exchange will be accepted
|
|||
|
by the peer's local policy. Hence, if these conditions are not met,
|
|||
|
then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer
|
|||
|
MUST send EAP-Response/AKA-Client-Error.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 49]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
The AT_MAC attribute MUST be included. In
|
|||
|
EAP-Response/AKA-Challenge, there is no message-specific data covered
|
|||
|
by the MAC, see Section 10.15.
|
|||
|
|
|||
|
The AT_RES attribute MUST be included.
|
|||
|
|
|||
|
The AT_CHECKCODE attribute MAY be included, and in certain cases
|
|||
|
specified in Section 10.13, it MUST be included.
|
|||
|
|
|||
|
The AT_RESULT_IND attribute MAY be included, if it was included in
|
|||
|
EAP-Request/AKA-Challenge. The usage of this attribute is discussed
|
|||
|
in Section 6.2.
|
|||
|
|
|||
|
Later versions of this protocol MAY make use of the AT_ENCR_DATA and
|
|||
|
AT_IV attributes in this message to include encrypted (skippable)
|
|||
|
attributes. The EAP server MUST process EAP-Response/AKA-Challenge
|
|||
|
messages that include these attributes even if the server did not
|
|||
|
implement these optional attributes.
|
|||
|
|
|||
|
9.5. EAP-Response/AKA-Authentication-Reject
|
|||
|
|
|||
|
The peer sends the EAP-Response/AKA-Authentication-Reject packet if
|
|||
|
it does not accept the AUTN parameter. This version of the protocol
|
|||
|
does not specify any attributes for this message. Future versions of
|
|||
|
the protocol MAY specify attributes for this message.
|
|||
|
|
|||
|
The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
|
|||
|
this message.
|
|||
|
|
|||
|
9.6. EAP-Response/AKA-Synchronization-Failure
|
|||
|
|
|||
|
The peer sends the EAP-Response/AKA-Synchronization-Failure, when the
|
|||
|
sequence number in the AUTN parameter is incorrect.
|
|||
|
|
|||
|
The peer MUST include the AT_AUTS attribute. Future versions of the
|
|||
|
protocol MAY specify other additional attributes for this message.
|
|||
|
|
|||
|
The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
|
|||
|
this message.
|
|||
|
|
|||
|
9.7. EAP-Request/AKA-Reauthentication
|
|||
|
|
|||
|
The server sends the EAP-Request/AKA-Reauthentication message if it
|
|||
|
wants to use fast re-authentication, and if it has received a valid
|
|||
|
fast re-authentication identity in EAP-Response/Identity or
|
|||
|
EAP-Response/AKA-Identity.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 50]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
The AT_MAC attribute MUST be included. No message-specific data is
|
|||
|
included in the MAC calculation, see Section 10.15.
|
|||
|
|
|||
|
The AT_RESULT_IND attribute MAY be included. The usage of this
|
|||
|
attribute is discussed in Section 6.2.
|
|||
|
|
|||
|
The AT_CHECKCODE attribute MAY be included, and in certain cases
|
|||
|
specified in Section 10.13, it MUST be included.
|
|||
|
|
|||
|
The AT_IV and AT_ENCR_DATA attributes MUST be included. The
|
|||
|
plaintext consists of the following nested encrypted attributes,
|
|||
|
which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the
|
|||
|
nested encrypted attributes MAY include the following attributes:
|
|||
|
AT_NEXT_REAUTH_ID and AT_PADDING.
|
|||
|
|
|||
|
9.8. EAP-Response/AKA-Reauthentication
|
|||
|
|
|||
|
The client sends the EAP-Response/AKA-Reauthentication packet in
|
|||
|
response to a valid EAP-Request/AKA-Reauthentication.
|
|||
|
|
|||
|
The AT_MAC attribute MUST be included. For
|
|||
|
EAP-Response/AKA-Reauthentication, the MAC code is calculated over
|
|||
|
the following data: EAP packet| NONCE_S. The EAP packet is
|
|||
|
represented as specified in Section 8.1. It is followed by the
|
|||
|
16-byte NONCE_S value from the server's AT_NONCE_S attribute.
|
|||
|
|
|||
|
The AT_CHECKCODE attribute MAY be included, and in certain cases
|
|||
|
specified in Section 10.13, it MUST be included.
|
|||
|
|
|||
|
The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested
|
|||
|
encrypted attributes MUST include the AT_COUNTER attribute. The
|
|||
|
AT_COUNTER_TOO_SMALL attribute MAY be included in the nested
|
|||
|
encrypted attributes, and it is included in cases specified in
|
|||
|
Section 5. The AT_PADDING attribute MAY be included.
|
|||
|
|
|||
|
The AT_RESULT_IND attribute MAY be included, if it was included in
|
|||
|
EAP-Request/AKA-Reauthentication. The usage of this attribute is
|
|||
|
discussed in Section 6.2.
|
|||
|
|
|||
|
Sending this packet without AT_COUNTER_TOO_SMALL indicates that the
|
|||
|
peer has successfully authenticated the server and that the EAP
|
|||
|
exchange will be accepted by the peer's local policy. Hence, if
|
|||
|
these conditions are not met, then the peer MUST NOT send
|
|||
|
EAP-Response/AKA-Reauthentication, but the peer MUST send
|
|||
|
EAP-Response/ AKA-Client-Error.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 51]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
9.9. EAP-Response/AKA-Client-Error
|
|||
|
|
|||
|
The peer sends EAP-Response/AKA-Client-Error in error cases, as
|
|||
|
specified in Section 6.3.1.
|
|||
|
|
|||
|
The AT_CLIENT_ERROR_CODE attribute MUST be included. The AT_MAC,
|
|||
|
AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet.
|
|||
|
|
|||
|
9.10. EAP-Request/AKA-Notification
|
|||
|
|
|||
|
The usage of this message is specified in Section 6.
|
|||
|
|
|||
|
The AT_NOTIFICATION attribute MUST be included.
|
|||
|
|
|||
|
The AT_MAC attribute MUST be included if the P bit of the
|
|||
|
AT_NOTIFICATION code is set to zero, and MUST NOT be included if the
|
|||
|
P bit is set to one. The P bit is discussed in Section 6.
|
|||
|
|
|||
|
No message-specific data is included in the MAC calculation. See
|
|||
|
Section 10.15.
|
|||
|
|
|||
|
If EAP-Request/AKA-Notification is used on a fast re-authentication
|
|||
|
exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
|
|||
|
AT_COUNTER is used for replay protection. In this case, the
|
|||
|
AT_ENCR_DATA and AT_IV attributes MUST be included, and the
|
|||
|
encapsulated plaintext attributes MUST include the AT_COUNTER
|
|||
|
attribute. The counter value included in AT_COUNTER MUST be the same
|
|||
|
as in the EAP-Request/AKA-Reauthentication packet on the same fast
|
|||
|
re-authentication exchange.
|
|||
|
|
|||
|
9.11. EAP-Response/AKA-Notification
|
|||
|
|
|||
|
The usage of this message is specified in Section 6. This packet is
|
|||
|
an acknowledgement of EAP-Request/AKA-Notification.
|
|||
|
|
|||
|
The AT_MAC attribute MUST be included in cases when the P bit of the
|
|||
|
notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification
|
|||
|
is set to zero, and MUST NOT be included in cases when the P bit is
|
|||
|
set to one. The P bit is discussed in Section 6.
|
|||
|
|
|||
|
If EAP-Request/AKA-Notification is used on a fast re-authentication
|
|||
|
exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
|
|||
|
AT_COUNTER is used for replay protection. In this case, the
|
|||
|
AT_ENCR_DATA and AT_IV attributes MUST be included, and the
|
|||
|
encapsulated plaintext attributes MUST include the AT_COUNTER
|
|||
|
attribute. The counter value included in AT_COUNTER MUST be the same
|
|||
|
as in the EAP-Request/AKA-Reauthentication packet on the same fast
|
|||
|
re-authentication exchange.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 52]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
10. Attributes
|
|||
|
|
|||
|
This section specifies the format of message attributes. The
|
|||
|
attribute type numbers are specified in Section 11.
|
|||
|
|
|||
|
10.1. Table of Attributes
|
|||
|
|
|||
|
The following table provides a guide to which attributes may be found
|
|||
|
in which kinds of messages, and in what quantity. Messages are
|
|||
|
denoted with numbers in parentheses as follows: (1) EAP-Request/
|
|||
|
AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/
|
|||
|
AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/
|
|||
|
AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP-
|
|||
|
Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9)
|
|||
|
EAP-Response/AKA-Reauthentication, (10) EAP-Response/AKA-
|
|||
|
Authentication-Reject, and (11) EAP-Response/AKA-Synchronization-
|
|||
|
Failure. The column denoted with "E" indicates whether the attribute
|
|||
|
is a nested attribute that MUST be included within AT_ENCR_DATA.
|
|||
|
|
|||
|
"0" indicates that the attribute MUST NOT be included in the message,
|
|||
|
"1" indicates that the attribute MUST be included in the message,
|
|||
|
"0-1" indicates that the attribute is sometimes included in the
|
|||
|
message, and "0*" indicates that the attribute is not included in the
|
|||
|
message in cases specified in this document, but MAY be included in
|
|||
|
the future versions of the protocol.
|
|||
|
|
|||
|
Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E
|
|||
|
AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
|
|||
|
AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
|
|||
|
AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
|
|||
|
AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N
|
|||
|
AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N
|
|||
|
AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N
|
|||
|
AT_RES 0 0 0 1 0 0 0 0 0 0 0 N
|
|||
|
AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N
|
|||
|
AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y
|
|||
|
AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y
|
|||
|
AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N
|
|||
|
AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N
|
|||
|
AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y
|
|||
|
AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N
|
|||
|
AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N
|
|||
|
AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N
|
|||
|
AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y
|
|||
|
AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y
|
|||
|
AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y
|
|||
|
AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N
|
|||
|
AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 53]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
It should be noted that attributes AT_PERMANENT_ID_REQ,
|
|||
|
AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that
|
|||
|
only one of them can be included at the same time. If one of the
|
|||
|
attributes AT_IV or AT_ENCR_DATA is included, then both of the
|
|||
|
attributes MUST be included.
|
|||
|
|
|||
|
10.2. AT_PERMANENT_ID_REQ
|
|||
|
|
|||
|
The format of the AT_PERMANENT_ID_REQ 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_PERM..._REQ | Length = 1 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1. The
|
|||
|
value field only contains two reserved bytes, which are set to zero
|
|||
|
on sending and ignored on reception.
|
|||
|
|
|||
|
10.3. AT_ANY_ID_REQ
|
|||
|
|
|||
|
The format of the AT_ANY_ID_REQ 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_ANY_ID_REQ | Length = 1 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The use of the AT_ANY_ID_REQ is defined in Section 4.1. The value
|
|||
|
field only contains two reserved bytes, which are set to zero on
|
|||
|
sending and ignored on reception.
|
|||
|
|
|||
|
10.4. AT_FULLAUTH_ID_REQ
|
|||
|
|
|||
|
The format of the AT_FULLAUTH_ID_REQ 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_FULLAUTH_...| Length = 1 | Reserved |
|
|||
|
+---------------+---------------+-------------------------------+
|
|||
|
|
|||
|
The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1. The
|
|||
|
value field only contains two reserved bytes, which are set to zero
|
|||
|
on sending and ignored on reception.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 54]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
10.5. AT_IDENTITY
|
|||
|
|
|||
|
The format of the AT_IDENTITY 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_IDENTITY | Length | Actual Identity Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
. Identity .
|
|||
|
. .
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The use of the AT_IDENTITY is defined in Section 4.1. The value
|
|||
|
field of this attribute begins with 2-byte actual identity length,
|
|||
|
which specifies the length of the identity in bytes. This field is
|
|||
|
followed by the subscriber identity of the indicated actual length.
|
|||
|
The identity is the permanent identity, a pseudonym identity or a
|
|||
|
fast re-authentication identity. The identity format is specified in
|
|||
|
Section 4.1.1. The same identity format is used in the AT_IDENTITY
|
|||
|
attribute and the EAP-Response/Identity packet, with the exception
|
|||
|
that the peer MUST NOT decorate the identity it includes in
|
|||
|
AT_IDENTITY. The identity does not include any terminating null
|
|||
|
characters. Because the length of the attribute must be a multiple
|
|||
|
of 4 bytes, the sender pads the identity with zero bytes when
|
|||
|
necessary.
|
|||
|
|
|||
|
10.6. AT_RAND
|
|||
|
|
|||
|
The format of the AT_RAND 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_RAND | Length = 5 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| RAND |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of this attribute contains two reserved bytes
|
|||
|
followed by the AKA RAND parameter, 16 bytes (128 bits). The
|
|||
|
reserved bytes are set to zero when sending and ignored on reception.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 55]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
10.7. AT_AUTN
|
|||
|
|
|||
|
The format of the AT_AUTN 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_AUTN | Length = 5 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| AUTN |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of this attribute contains two reserved bytes
|
|||
|
followed by the AKA AUTN parameter, 16 bytes (128 bits). The
|
|||
|
reserved bytes are set to zero when sending and ignored on reception.
|
|||
|
|
|||
|
10.8. AT_RES
|
|||
|
|
|||
|
The format of the AT_RES 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_RES | Length | RES Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|
|||
|
| |
|
|||
|
| RES |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of this attribute begins with the 2-byte RES Length,
|
|||
|
which identifies the exact length of the RES in bits. The RES length
|
|||
|
is followed by the AKA RES parameter. According to [TS33.105], the
|
|||
|
length of the AKA RES can vary between 32 and 128 bits. Because the
|
|||
|
length of the AT_RES attribute must be a multiple of 4 bytes, the
|
|||
|
sender pads the RES with zero bits where necessary.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 56]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
10.9. AT_AUTS
|
|||
|
|
|||
|
The format of the AT_AUTS 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_AUTS | Length = 4 | |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
|||
|
| |
|
|||
|
| AUTS |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of this attribute contains the AKA AUTS parameter,
|
|||
|
112 bits (14 bytes).
|
|||
|
|
|||
|
10.10. AT_NEXT_PSEUDONYM
|
|||
|
|
|||
|
The format of the AT_NEXT_PSEUDONYM 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_NEXT_PSEU..| Length | Actual Pseudonym Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
. Next Pseudonym .
|
|||
|
. .
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of this attribute begins with a 2-byte actual
|
|||
|
pseudonym length, which specifies the length of the following
|
|||
|
pseudonym in bytes. This field is followed by a pseudonym username
|
|||
|
that the peer can use in the next authentication. The username MUST
|
|||
|
NOT include any realm portion. The username does not include any
|
|||
|
terminating null characters. Because the length of the attribute
|
|||
|
must be a multiple of 4 bytes, the sender pads the pseudonym with
|
|||
|
zero bytes when necessary. The username encoding MUST follow the
|
|||
|
UTF-8 transformation format [RFC3629]. This attribute MUST always be
|
|||
|
encrypted by encapsulating it within the AT_ENCR_DATA attribute.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 57]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
10.11. AT_NEXT_REAUTH_ID
|
|||
|
|
|||
|
The format of the AT_NEXT_REAUTH_ID 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_NEXT_REAU..| Length | Actual Re-Auth Identity Length|
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
. Next Fast Re-Authentication Username .
|
|||
|
. .
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of this attribute begins with a 2-byte actual
|
|||
|
re-authentication identity length which specifies the length of the
|
|||
|
following fast re-authentication identity in bytes. This field is
|
|||
|
followed by a fast re-authentication identity that the peer can use
|
|||
|
in the next fast re-authentication, as described in Section 5. In
|
|||
|
environments where a realm portion is required, the fast
|
|||
|
re-authentication identity includes both a username portion and a
|
|||
|
realm name portion. The fast re-authentication identity does not
|
|||
|
include any terminating null characters. Because the length of the
|
|||
|
attribute must be a multiple of 4 bytes, the sender pads the fast
|
|||
|
re-authentication identity with zero bytes when necessary. The
|
|||
|
identity encoding MUST follow the UTF-8 transformation format
|
|||
|
[RFC3629]. This attribute MUST always be encrypted by encapsulating
|
|||
|
it within the AT_ENCR_DATA attribute.
|
|||
|
|
|||
|
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING
|
|||
|
|
|||
|
AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
|
|||
|
information between the EAP-AKA peer and server.
|
|||
|
|
|||
|
The value field of AT_IV contains two reserved bytes followed by a
|
|||
|
16-byte initialization vector required by the AT_ENCR_DATA attribute.
|
|||
|
The reserved bytes are set to zero when sending and ignored on
|
|||
|
reception. The AT_IV attribute MUST be included if and only if the
|
|||
|
AT_ENCR_DATA is included. Section 6.3 specifies the operation if a
|
|||
|
packet that does not meet this condition is encountered.
|
|||
|
|
|||
|
The sender of the AT_IV attribute chooses the initialization vector
|
|||
|
at random. The sender MUST NOT reuse the initialization vector value
|
|||
|
from previous EAP-AKA packets. The sender SHOULD use a good source
|
|||
|
of randomness to generate the initialization vector. Please see
|
|||
|
[RFC4086] for more information about generating random numbers for
|
|||
|
security applications. The format of AT_IV is shown below.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 58]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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_IV | Length = 5 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| Initialization Vector |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of the AT_ENCR_DATA attribute consists of two
|
|||
|
reserved bytes followed by cipher text bytes. The cipher text bytes
|
|||
|
are encrypted using the Advanced Encryption Standard (AES) [AES] with
|
|||
|
a 128-bit key in the Cipher Block Chaining (CBC) mode of operation,
|
|||
|
which uses the initialization vector from the AT_IV attribute. The
|
|||
|
reserved bytes are set to zero when sending and ignored on reception.
|
|||
|
Please see [CBC] for a description of the CBC mode. The format of
|
|||
|
the AT_ENCR_DATA 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_ENCR_DATA | Length | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
. Encrypted Data .
|
|||
|
. .
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The derivation of the encryption key (K_encr) is specified in
|
|||
|
Section 7.
|
|||
|
|
|||
|
The plaintext consists of nested EAP-AKA attributes.
|
|||
|
|
|||
|
The encryption algorithm requires the length of the plaintext to be a
|
|||
|
multiple of 16 bytes. The sender may need to include the AT_PADDING
|
|||
|
attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING
|
|||
|
attribute is not included if the total length of other nested
|
|||
|
attributes within the AT_ENCR_DATA attribute is a multiple of 16
|
|||
|
bytes. As usual, the Length of the Padding attribute includes the
|
|||
|
Attribute Type and Attribute Length fields. The length of the
|
|||
|
Padding attribute is 4, 8, or 12 bytes. It is chosen so that the
|
|||
|
length of the value field of the AT_ENCR_DATA attribute becomes a
|
|||
|
multiple of 16 bytes. The actual pad bytes in the value field are
|
|||
|
set to zero (00 hexadecimal) on sending. The recipient of the
|
|||
|
message MUST verify that the pad bytes are set to zero. If this
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 59]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
verification fails on the peer, then it MUST send the
|
|||
|
EAP-Response/AKA-Client-Error packet with the error code "unable to
|
|||
|
process packet" to terminate the authentication exchange. If this
|
|||
|
verification fails on the server, then the server sends the
|
|||
|
EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code
|
|||
|
that implies failure to terminate the authentication exchange. The
|
|||
|
format of the AT_PADDING 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_PADDING | Length | Padding... |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
10.13. AT_CHECKCODE
|
|||
|
|
|||
|
The AT_MAC attribute is not used in the very first EAP-AKA messages
|
|||
|
during the AKA-Identity round, because keying material has not been
|
|||
|
derived yet. The peer and the server may exchange one or more pairs
|
|||
|
of EAP-AKA messages of the Subtype AKA-Identity before keys are
|
|||
|
derived and before the AT_MAC attribute can be applied. The EAP/-
|
|||
|
AKA-Identity messages may also be used upon fast re-authentication.
|
|||
|
|
|||
|
The AT_CHECKCODE attribute MAY be used to protect the EAP/
|
|||
|
AKA-Identity messages. In full authentication, the server MAY
|
|||
|
include the AT_CHECKCODE in EAP-Request/AKA-Challenge, and the peer
|
|||
|
MAY include AT_CHECKCODE in EAP-Response/AKA-Challenge. In fast
|
|||
|
re-authentication, the server MAY include AT_CHECKCODE in
|
|||
|
EAP-Request/ AKA-Reauthentication, and the peer MAY include
|
|||
|
AT_CHECKCODE in EAP-Response/AKA-Reauthentication. The fact that the
|
|||
|
peer receives an EAP-Request with AT_CHECKCODE does not imply that
|
|||
|
the peer would have to include AT_CHECKCODE in the corresponding
|
|||
|
response. The peer MAY include AT_CHECKCODE even if the server did
|
|||
|
not include AT_CHECKCODE in the EAP request. Because the AT_MAC
|
|||
|
attribute is used in these messages, AT_CHECKCODE will be integrity
|
|||
|
protected with AT_MAC. The format of the AT_CHECKCODE attribute is
|
|||
|
shown below.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 60]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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_CHECKCODE | Length | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| Checkcode (0 or 20 bytes) |
|
|||
|
| |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The value field of AT_CHECKCODE begins with two reserved bytes, which
|
|||
|
may be followed by a 20-byte checkcode. If the checkcode is not
|
|||
|
included in AT_CHECKCODE, then the attribute indicates that no EAP/-
|
|||
|
AKA-Identity messages were exchanged. This may occur in both full
|
|||
|
authentication and fast re-authentication. The reserved bytes are
|
|||
|
set to zero when sending and ignored on reception.
|
|||
|
|
|||
|
The checkcode is a hash value, calculated with SHA1 [SHA-1], over all
|
|||
|
EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets
|
|||
|
exchanged in this authentication exchange. The packets are included
|
|||
|
in the order that they were transmitted, that is, starting with the
|
|||
|
first EAP-Request/AKA-Identity message, followed by the corresponding
|
|||
|
EAP-Response/AKA-Identity, followed by the second
|
|||
|
EAP-Request/AKA-Identity (if used), etc.
|
|||
|
|
|||
|
EAP packets are included in the hash calculation "as-is" (as they
|
|||
|
were transmitted or received). All reserved bytes, padding bytes,
|
|||
|
etc., that are specified for various attributes are included as such,
|
|||
|
and the receiver must not reset them to zero. No delimiter bytes,
|
|||
|
padding, or any other framing are included between the EAP packets
|
|||
|
when calculating the checkcode.
|
|||
|
|
|||
|
Messages are included in request/response pairs; in other words, only
|
|||
|
full "round trips" are included. Packets that are silently discarded
|
|||
|
are not included, and retransmitted packets (that have the same
|
|||
|
Identifier value) are only included once. (The base EAP protocol
|
|||
|
[RFC3748] ensures that requests and responses "match".) The EAP
|
|||
|
server must only include an EAP-Request/AKA-Identity in the
|
|||
|
calculation after it has received a corresponding response with the
|
|||
|
same Identifier value.
|
|||
|
|
|||
|
The peer must include the EAP-Request/AKA-Identity and the
|
|||
|
corresponding response in the calculation only if the peer receives a
|
|||
|
subsequent EAP-Request/AKA-Challenge or a follow-up EAP-Request/
|
|||
|
AKA-Identity with a different Identifier value than in the first
|
|||
|
EAP-Request/AKA-Identity.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 61]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
The AT_CHECKCODE attribute is optional to implement. It is specified
|
|||
|
in order to allow protection of the EAP/AKA-Identity messages and any
|
|||
|
future extensions to them. The implementation of AT_CHECKCODE is
|
|||
|
RECOMMENDED.
|
|||
|
|
|||
|
If the receiver of AT_CHECKCODE implements this attribute, then the
|
|||
|
receiver MUST check that the checkcode is correct. If the checkcode
|
|||
|
is invalid, the receiver must operate as specified in Section 6.3.
|
|||
|
|
|||
|
If the EAP/AKA-Identity messages are extended with new attributes,
|
|||
|
then AT_CHECKCODE MUST be implemented and used. More specifically,
|
|||
|
if the server includes any attributes other than AT_PERMANENT_ID_REQ,
|
|||
|
AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity
|
|||
|
packet, then the server MUST include AT_CHECKCODE in EAP-Request/
|
|||
|
AKA-Challenge or EAP-Request/AKA-Reauthentication. If the peer
|
|||
|
includes any attributes other than AT_IDENTITY in the EAP-Response/
|
|||
|
AKA-Identity message, then the peer MUST include AT_CHECKCODE in
|
|||
|
EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication.
|
|||
|
|
|||
|
If the server implements the processing of any other attribute than
|
|||
|
AT_IDENTITY for the EAP-Response/AKA-Identity message, then the
|
|||
|
server MUST implement AT_CHECKCODE. In this case, if the server
|
|||
|
receives any attribute other than AT_IDENTITY in the
|
|||
|
EAP-Response/AKA-Identity message, then the server MUST check that
|
|||
|
AT_CHECKCODE is present in EAP-Response/AKA-Challenge or
|
|||
|
EAP-Response/ AKA-Reauthentication. The operation when a mandatory
|
|||
|
attribute is missing is specified in Section 6.3.
|
|||
|
|
|||
|
Similarly, if the peer implements the processing of any attribute
|
|||
|
other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ
|
|||
|
for the EAP-Request/AKA-Identity packet, then the peer MUST implement
|
|||
|
AT_CHECKCODE. In this case, if the peer receives any attribute other
|
|||
|
than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the
|
|||
|
EAP-Request/AKA-Identity packet, then the peer MUST check that
|
|||
|
AT_CHECKCODE is present in EAP-Request/AKA-Challenge or
|
|||
|
EAP-Request/AKA-Reauthentication. The operation when a mandatory
|
|||
|
attribute is missing is specified in Section 6.3.
|
|||
|
|
|||
|
10.14. AT_RESULT_IND
|
|||
|
|
|||
|
The format of the AT_RESULT_IND 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_RESULT_...| Length = 1 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 62]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
The value field of this attribute consists of two reserved bytes,
|
|||
|
which are set to zero upon sending and ignored upon reception. This
|
|||
|
attribute is always sent unencrypted, so it MUST NOT be encapsulated
|
|||
|
within the AT_ENCR_DATA attribute.
|
|||
|
|
|||
|
10.15. AT_MAC
|
|||
|
|
|||
|
The AT_MAC attribute is used for EAP-AKA message authentication.
|
|||
|
Section 9 specifies in which messages AT_MAC MUST be included.
|
|||
|
|
|||
|
The value field of the AT_MAC attribute contains two reserved bytes
|
|||
|
followed by a keyed message authentication code (MAC). The MAC is
|
|||
|
calculated over the whole EAP packet and concatenated with optional
|
|||
|
message-specific data, with the exception that the value field of the
|
|||
|
MAC attribute is set to zero when calculating the MAC. The EAP
|
|||
|
packet includes the EAP header that begins with the Code field, the
|
|||
|
EAP-AKA header that begins with the Subtype field, and all the
|
|||
|
attributes, as specified in Section 8.1. The reserved bytes in
|
|||
|
AT_MAC are set to zero when sending and ignored on reception. The
|
|||
|
contents of the message-specific data that may be included in the MAC
|
|||
|
calculation are specified separately for each EAP-AKA message in
|
|||
|
Section 9.
|
|||
|
|
|||
|
The format of the AT_MAC 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_MAC | Length = 5 | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| MAC |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 63]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 64]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 65]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 66]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 67]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 68]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 69]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 70]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 71]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 72]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 73]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[TS23.003] 3rd Generation Partnership Project, "3GPP Technical
|
|||
|
Specification 3GPP TS 23.003 V6.8.0: "3rd
|
|||
|
Generation Parnership Project; Technical
|
|||
|
Specification Group Core Network; Numbering,
|
|||
|
addressing and identification (Release 6)"",
|
|||
|
December 2005.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 74]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
|
|||
|
Keyed-Hashing for Message Authentication",
|
|||
|
RFC 2104, February 1997.
|
|||
|
|
|||
|
[AES] National Institute of Standards and Technology,
|
|||
|
"Federal Information Processing Standards (FIPS)
|
|||
|
Publication 197, "Advanced Encryption Standard
|
|||
|
(AES)"", November 2001,
|
|||
|
http://csrc.nist.gov/publications/fips/fips197/
|
|||
|
fips-197.pdf.
|
|||
|
|
|||
|
[CBC] National Institute of Standards and Technology,
|
|||
|
"NIST Special Publication 800-38A, "Recommendation
|
|||
|
for Block Cipher Modes of Operation - Methods and
|
|||
|
Techniques"", December 2001,
|
|||
|
http://csrc.nist.gov/publications/
|
|||
|
nistpubs/800-38a/sp800-38a.pdf.
|
|||
|
|
|||
|
[SHA-1] National Institute of Standards and Technology,
|
|||
|
U.S. Department of Commerce, "Federal Information
|
|||
|
Processing Standard (FIPS) Publication 180-1,
|
|||
|
"Secure Hash Standard"", April 1995.
|
|||
|
|
|||
|
[PRF] National Institute of Standards and Technology,
|
|||
|
"Federal Information Processing Standards (FIPS)
|
|||
|
Publication 186-2 (with change notice); Digital
|
|||
|
Signature Standard (DSS)", January 2000,
|
|||
|
http://csrc.nist.gov/publications/
|
|||
|
fips/fips186-2/fips186-2-change1.pdf.
|
|||
|
|
|||
|
[TS33.105] 3rd Generation Partnership Project, "3GPP Technical
|
|||
|
Specification 3GPP TS 33.105 4.1.0: "Technical
|
|||
|
Specification Group Services and System Aspects; 3G
|
|||
|
Security; Cryptographic Algorithm Requirements
|
|||
|
(Release 4)"", June 2001.
|
|||
|
|
|||
|
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
|||
|
10646", STD 63, RFC 3629, November 2003.
|
|||
|
|
|||
|
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
|
|||
|
Writing an IANA Considerations Section in RFCs",
|
|||
|
BCP 26, RFC 2434, October 1998.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 75]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
15.2. Informative References
|
|||
|
|
|||
|
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
|
|||
|
Attributes", RFC 2548, March 1999.
|
|||
|
|
|||
|
[PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J.,
|
|||
|
Zhou, H., and S. Josefsson, "Protected EAP Protocol
|
|||
|
(PEAP) Version 2", work in progress, October 2004.
|
|||
|
|
|||
|
[PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D.,
|
|||
|
and A. Palekar, "Protected EAP Protocol (PEAP)",
|
|||
|
work in progress, February 2002.
|
|||
|
|
|||
|
[EAPKeying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
|
|||
|
Levkowetz, "Extensible Authentication Protocol
|
|||
|
(EAP) Key Management Framework", work in progress,
|
|||
|
October 2005.
|
|||
|
|
|||
|
[ServiceIdentity] Arkko, J. and P. Eronen, "Authenticated Service
|
|||
|
Information for the Extensible Authentication
|
|||
|
Protocol (EAP)", Work in Progress, October 2004.
|
|||
|
|
|||
|
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
|
|||
|
"Randomness Requirements for Security", BCP 106,
|
|||
|
RFC 4086, June 2005.
|
|||
|
|
|||
|
[RFC3344] Perkins, C., "IP Mobility Support for IPv4",
|
|||
|
RFC 3344, August 2002.
|
|||
|
|
|||
|
[EAP-SIM] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
|
|||
|
Authentication Protocol Method for Global System
|
|||
|
for Mobile Communications (GSM) Subscriber Identity
|
|||
|
Modules (EAP-SIM)", RFC 4186, January 2006.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 76]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Appendix A. Pseudo-Random Number Generator
|
|||
|
|
|||
|
The "|" character denotes concatenation, and "^" denotes
|
|||
|
exponentiation.
|
|||
|
|
|||
|
Step 1: Choose a new, secret value for the seed-key, XKEY
|
|||
|
|
|||
|
Step 2: In hexadecimal notation let
|
|||
|
t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
|
|||
|
This is the initial value for H0|H1|H2|H3|H4
|
|||
|
in the FIPS SHS [SHA-1]
|
|||
|
|
|||
|
Step 3: For j = 0 to m - 1 do
|
|||
|
3.1. XSEED_j = 0 /* no optional user input */
|
|||
|
3.2. For i = 0 to 1 do
|
|||
|
a. XVAL = (XKEY + XSEED_j) mod 2^b
|
|||
|
b. w_i = G(t, XVAL)
|
|||
|
c. XKEY = (1 + XKEY + w_i) mod 2^b
|
|||
|
3.3. x_j = w_0|w_1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 77]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Authors' Addresses
|
|||
|
|
|||
|
Jari Arkko
|
|||
|
Ericsson
|
|||
|
FIN-02420 Jorvas
|
|||
|
Finland
|
|||
|
|
|||
|
EMail: jari.Arkko@ericsson.com
|
|||
|
|
|||
|
|
|||
|
Henry Haverinen
|
|||
|
Nokia Enterprise Solutions
|
|||
|
P.O. Box 12
|
|||
|
FIN-40101 Jyvaskyla
|
|||
|
Finland
|
|||
|
|
|||
|
EMail: henry.haverinen@nokia.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 78]
|
|||
|
|
|||
|
RFC 4187 EAP-AKA Authentication January 2006
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2006).
|
|||
|
|
|||
|
This document is subject to the rights, licenses and restrictions
|
|||
|
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
|
|||
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|||
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|||
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|||
|
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
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
Intellectual Property Rights or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
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
|
|||
|
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
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights that may cover technology that may be required to implement
|
|||
|
this standard. Please address the information to the IETF at
|
|||
|
ietf-ipr@ietf.org.
|
|||
|
|
|||
|
Acknowledgement
|
|||
|
|
|||
|
Funding for the RFC Editor function is provided by the IETF
|
|||
|
Administrative Support Activity (IASA).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arkko & Haverinen Informational [Page 79]
|
|||
|
|