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]
|
||
|