WDIFF

draft-arkko-pppext-eap-aka-04.txt --> draft-arkko-pppext-eap-aka-05.txt

J. Arkko
Internet Draft Ericsson
Document: draft-arkko-pppext-eap-aka-04.txt draft-arkko-pppext-eap-aka-05.txt H. Haverinen
Expires: December 2002 March 2003 Nokia
June
October 2002

EAP AKA Authentication

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and session key distribution using the
UMTS AKA authentication mechanism. AKA is based on symmetric keys,
and runs typically in a UMTS Subscriber Identity Module, a smart
card like device. AKA provides also backward compatibility to GSM
authentication, making it possible to use EAP AKA for authenticating
both GSM and UMTS subscribers.

EAP AKA includes optional identity privacy support and an optional
re-authentication procedure.

Table of Contents

Status of this Memo................................................1
Abstract...........................................................1
1. Introduction and Motivation.....................................2
2. Conventions used in this document...............................3 document...............................4
3. Protocol Overview...............................................5
4. Obtaining Subscriber Identity via EAP AKA Messages.............10
5. Identity Privacy Support.......................................11

Arkko and Haverinen Expires in six months [Page 1]

EAP AKA Authentication June October 2002

4. User identity in EAP-Response/Identity.........................10
5. Obtaining Subscriber Identity via EAP AKA Messages.............12
6. Message Format.................................................14 Identity Privacy Support.......................................14
7. Re-authentication..............................................20
8. Message Format.................................................25
9. Message Integrity Authentication and Privacy Protection.......................16
7.1. Encryption..........................26
9.1. AT_MAC Attribute.............................................16
7.2. AT_IV and Attribute.............................................26
9.2. AT_IV, AT_ENCR_DATA Attributes............................16
8. Messages.......................................................17
8.1. EAP-Response/Identity........................................18
8.2. EAP-Request/AKA-Challenge....................................19
8.3. EAP-Response/AKA-Challenge...................................22
8.4. EAP-Response/AKA-Authentication-Reject.......................24
8.5. EAP-Response/AKA-Synchronization-Failure.....................24
8.6. EAP-Request/AKA-Identity.....................................25
8.7. EAP-Response/AKA-Identity....................................26
9. Key Derivation.................................................28 and AT_PADDING Attributes................27
10. Messages......................................................28
10.1. EAP-Request/AKA-Challenge...................................28
10.2. EAP-Response/AKA-Challenge..................................32
10.3. EAP-Response/AKA-Authentication-Reject......................33
10.4. EAP-Response/AKA-Synchronization-Failure....................34
10.5. EAP-Request/AKA-Identity....................................35
10.6. EAP-Response/AKA-Identity...................................36
10.7. EAP-Request/AKA-Reauthentication............................37
10.8. EAP-Response/AKA-Reauthentication...........................40
11. Unsuccessful Cases............................................42
12. Key Derivation................................................42
13. Interoperability with GSM.....................................29
11. GSM.....................................44
14. IANA and Protocol Numbering Considerations....................30
12. Considerations....................45
15. Security Considerations.......................................31
13. Considerations.......................................45
16. Intellectual Property Right Notices...........................31 Notices...........................46
Acknowledgements and Contributions................................31 Contributions................................46
Authors' Addresses................................................31 Addresses................................................46
Annex A. Key Derivation for IEEE 802.11...........................47
Annex B. Pseudo-Random Number Generator...........................48

1. Introduction and Motivation

This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and session key distribution using the
UMTS AKA authentication mechanism [1]. The Universal Mobile
Telecommunications System (UMTS) is a global third generation mobile
network standard.

AKA is based on challenge-response mechanisms and symmetric
cryptography. AKA typically runs in a UMTS Subscriber Identity
Module (USIM), a smart card like device. However, the applicability
of AKA is not limited to client devices with smart cards, but the
AKA mechanisms could also be implemented in host software, for
example. AKA also provides backward compatibility to the GSM
authentication mechanism [2]. Compared to the GSM mechanism, AKA
provides substantially longer key lengths and the authentication of
the server side as well as the client side.

The introduction of AKA inside EAP allows several new applications.
These include the following:

Arkko and Haverinen Expires in six months [Page 2]

EAP AKA Authentication October 2002

- The use of the AKA also as a secure PPP authentication method in
devices that already contain an USIM.

- The use of the third generation mobile network authentication
infrastructure in the context of wireless LANs and IEEE 801.1x
technology through EAP over Wireless [3, 4].

- Relying on AKA and the existing infrastructure in a seamless way
with any other technology that can use EAP.

Arkko and Haverinen Expires in six months [Page 2]

EAP AKA Authentication June 2002

AKA works in the following manner:

- The USIM and the home environment have agreed on a secret key
beforehand.

- 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 USIM, an expected result part
XRES, a session key for integrity check IK, and a session key for
encryption CK.

- The RAND and the AUTN are delivered to the USIM.

- The USIM 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 USIM produces an authentication result, RES
and sends this to the home environment.

- The home environment verifies the correct result from the USIM. If
the result is correct, IK and CK can be used to protect further
communications between the USIM and the home environment.

When verifying AUTN, the USIM may detect that the sequence number
the network uses is not within the correct range. In this case, the
USIM 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 reference [1].

It is also possible that the home environment delegates the actual
authentication task to an intermediate node. In this case the
authentication vector or parts of it are delivered to the
intermediate node, enabling it to perform the comparison between RES
and XRES, and possibly also use CK and IK. Such delivery MUST be
done in a secure manner. In EAP AKA, the EAP server node is such an
intermediate node.

Arkko and Haverinen Expires in six months [Page 3]

EAP AKA Authentication October 2002

In the third generation mobile networks, AKA is used both for 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) [5].

2. Conventions used in this document

The following terms will be used through this document:

Arkko and Haverinen Expires in six months [Page 3]

EAP AKA Authentication June 2002

AAA protocol

Authentication, Authorization and Accounting protocol

AAA server

The AAA server is responsible for storing shared secrets and
other credential information necessary for the authentication of
users. Cf. EAP server

AKA

Authentication and Key Agreement

AuC

Authentication Centre. The mobile network element that can
authenticate subscribers either in GSM or in UMTS networks.

Authenticator

The entity that terminates the protocol carrying EAP used by the
client, such as a Network Access Server (NAS) terminating the PPP
link. The EAP server may be co-located in the Authenticator. In
this case, the Authenticator may actually authenticate the user
based on information received from the AAA server.

EAP

Extensible Authentication Protocol [6].

EAP server

The network element that terminates the EAP protocol. Typically,
the EAP server functionality is implemented in a AAA server.

GSM

Global System for Mobile communications.

Arkko and Haverinen Expires in six months [Page 4]

EAP AKA Authentication October 2002

NAI

Network Access Identifier [5].

AUTN

Authentication value generated by the AuC which together with the
RAND authenticates the server to the client, 128 bits [1].

Arkko and Haverinen Expires in six months [Page 4]

EAP AKA Authentication June 2002

AUTS

A value generated by the client upon experiencing a
synchronization failure, 112 bits.

RAND

Random number generated by the AuC, 128 bits [1].

RES

Authentication result from the client, which together with the
RAND authenticates the client to the server, 128 bits [1].

SQN

Sequence number used in the authentication process, 48 bits [1].

SIM

Subscriber Identity Module. The SIM is an application
traditionally resident on smart cards distributed by GSM
operators.SRES

The authentication result parameter in GSM, corresponds to the
RES parameter in UMTS aka, 32 bits.

USIM

UMTS Subscriber Identity Module. USIM is an application that is
resident e.g. on smart cards distributed by UMTS operators.

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 RFC 2119 [7]

3. Protocol Overview

In this document, the term EAP Server refers to the network element
that terminates the EAP protocol. Usually the EAP server is separate
from the authenticator device, which is the network element closest
to the client, such as a Network Access Server (NAS) or an IEEE
802.1X bridge. Alternatively, the EAP server functionality may be
co-located in the authenticator although typically, the the EAP

Arkko and Haverinen Expires in six months [Page 5]

EAP AKA Authentication October 2002

server functionality is implemented on a separate AAA server with
whom the authenticator communicates using an AAA protocol. (The
exact AAA communications are outside the scope of this document,
however.)

The below message flow shows the basic successful full
authentication case with the EAP AKA. The EAP AKA uses two
roundtrips to authorize the user and generate session keys. As in
other EAP schemes, first an identity request/response message pair
is exchanged. (As

Arkko and Haverinen Expires in six months [Page 5]

EAP AKA Authentication June 2002 specified in [6], the initial identity request is
not required, and MAY be bypassed in cases where the authenticator
can presume the identity, such as when using leased lines, dedicated
dial-ups, etc. Please see also Section 4 5 for specification how to
obtain the identity via EAP AKA messages.)

Next, the EAP server starts the actual AKA protocol by sending an
EAP-Request/AKA-Challenge message. This 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 random number (RAND)
(AT_RAND) and an authorization vector (AUTN). (AT_AUTN), and a message
authentication code AT_MAC. The EAP-
Request/AKA-Challenge EAP-Request/AKA-Challenge message
MAY optionally contain encrypted data, which is used for IMSI
privacy support, as described in Section 5. 6. 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 client runs the AKA algorithm (perhaps inside an USIM) and
verifies the AUTN. If this is successful, the client 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 verify that the client is a legitimate one. one,
and the AT_MAC attribute to integrity protect the EAP message.

Arkko and Haverinen Expires in six months [Page 6]

EAP AKA Authentication October 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server runs UMTS algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| |
| EAP-Request/AKA-Challenge |
| (RAND, AUTN) (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs UMTS algorithms on USIM,| |
| verifies AUTN, AUTN and MAC, derives RES | |
| and session key | |
+-------------------------------------+ |
| |
| EAP-Response/AKA-Challenge |
| (RES) (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| |
| +------------------------------+ +--------------------------------+
| | Server checks the given RES, |
| | and MAC and finds it correct. | them correct.|
| +------------------------------+ +--------------------------------+
| |
| EAP-Success |
|<------------------------------------------------------|

Arkko and Haverinen Expires in six months [Page 6]

EAP AKA Authentication June 2002

When EAP AKA is run in the GSM compatible mode, the message flow is
otherwise identical to the message flow below except that the AUTN
AT_AUTN attribute is not included in EAP-Request/AKA-Challenge packet.
packet and AT_MAC attribute is not included in any attribute.

The second message flow shows how the EAP server rejects the Client
due to failed authentication. The same flow is also used in the GSM
compatible mode, except that the AUTN parameter is AT_AUTN attribute and AT_MAC
attribute are not included used in the EAP-Request/AKA-Challenge packet. messages.

Arkko and Haverinen Expires in six months [Page 7]

EAP AKA Authentication October 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server runs UMTS algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| |
| EAP-Request/AKA-Challenge |
| (RAND, AUTN) (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs UMTS algorithms on USIM,| |
| possibly verifies AUTN, and sends an| |
| invalid response | |
+-------------------------------------+ |
| |
| EAP-Response/AKA-Challenge |
| (RES) (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| |
| +------------------------------+ +------------------------------------------+
| | Server checks the given RES, RES and the MAC, |
| | and finds it incorrect. one of them incorrct. |
| +------------------------------+ +------------------------------------------+
| |
| EAP-Failure |
|<------------------------------------------------------|

The next message flow shows the client rejecting the AUTN of the EAP
server. This flow is not used in the GSM compatible mode.

The client sends an explicit error message (EAP-Response/AKA-
Authentication-Reject) to the Authenticator, as usual in AKA when
AUTN is incorrect. This allows the EAP server to produce the same
error statistics as AKA in general produces in UMTS. Please note

Arkko and Haverinen Expires in six months [Page 7]

EAP AKA Authentication June 2002
that this behavior is different from other EAP/AKA error cases, such
as when encountering an incorrect AT_MAC attribute, when the client
silently discards the EAP/AKA message.

Arkko and Haverinen Expires in six months [Page 8]

EAP AKA Authentication October 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server runs UMTS algorithms, |
| | generates RAND and a bad AUTN|
| +------------------------------+
| |
| EAP-Request/AKA-Challenge |
| (RAND, AUTN) (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs UMTS algorithms on USIM | |
| and discovers AUTN that can not be | |
| verified | |
+-------------------------------------+ |
| |
| EAP-Response/AKA-Authentication-Reject |
|------------------------------------------------------>|
| |
| |
| EAP-Failure |
|<------------------------------------------------------|

Networks that are not UMTS aware use the GSM compatible version of
this protocol even for UMTS subscribers. In this case, the AUTN
parameter is not included in the EAP-Request/AKA-Challenge packet.
If a UMTS capable client does not want to accept the use of the GSM
compatible mode, the client can reject the authentication with the
EAP-Response/Nak message [6], as shown in the following figure:

Arkko and Haverinen Expires in six months [Page 8]

EAP AKA Authentication June 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server runs GSM algorithms, |
| | generates RAND |
| +------------------------------+
| |
| by
silently ignoring any EAP-Request/AKA-Challenge |
| (RAND) |
|<------------------------------------------------------|
| |
+-------------------------------------+ |
| Client does packets that do not accept
include the GSM | |
| compatible version of this protocol.| |
+-------------------------------------+ |
| |
| EAP-Response/Nak |
|------------------------------------------------------>|
| |
| |
| EAP-Failure |
|<------------------------------------------------------| AUTN parameter.

The AKA uses shared secrets between the Client and the Client's home
operator together with a sequence number to actually perform an
authentication. In certain circumstances it is possible for the
sequence numbers to get out of sequence. Here�s what happens then:

Arkko and Haverinen Expires in six months [Page 9]

EAP AKA Authentication June October 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server runs UMTS algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| |
| EAP-Request/AKA-Challenge |
| (RAND, AUTN) (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs UMTS algorithms on USIM | |
| and discovers AUTN that contains an | |
| inappropriate sequence number | |
+-------------------------------------+ |
| |
| EAP-Response/AKA-Synchronization-Failure |
| (AUTS) (AT_AUTS) |
|------------------------------------------------------>|
| |
| +---------------------------+
| | Perform resynchronization |
| | Using AUTS and |
| | the sent RAND |
| +---------------------------+
| |

After the resynchronization process takes place in the server and
AAA side, the process continues by the server side sending a new
EAP-Request/AKA-Challenge message.

4. Obtaining Subscriber Identity via EAP AKA Messages

It may be useful

In addition to obtain the full authentication scenarios described above,
EAP AKA includes a re-authentication procedure, which is specified
in Section 7.

4. User identity of in EAP-Response/Identity

In the subscriber through
means other than beginning of EAP Request/Identity. This can eliminate authentication, the need
for an identity request when using EAP method negotiation. If this
was not possible then it might not be possible Authenticator issues the
EAP-Request/Identity packet to negotiate EAP/AKA
as the second method since it is not client. The client responds with
EAP-Response/Identity, which contains the user's identity. The
formats of these packets are specified how to deal in [6].

UMTS and GSM subscribers are identified with a
new EAP Request/Identity.

If the EAP server does not have any identity (IMSI International
Mobile Subscriber Identity (IMSI) [12]. The IMSI is composed of a
three digit Mobile Country Code (MCC), a two or pseudonym)
available when sending the first EAP/AKA request (usually EAP-
Request/AKA-Challenge), then the EAP server issues the EAP-
Request/AKA-Identity as the first message three digit Mobile
Network Code (MNC) and includes the
AT_IDENTITY_REQ attribute (Section 8.6). This attribute does a not
contain any data. It requests the client to include the AT_IDENTITY more than 10 digit Mobile Subscriber

Arkko and Haverinen Expires in six months [Page 10]

EAP AKA Authentication June October 2002

attribute (specified in Section 8.7) in

Identification Number (MSIN). In other words, the EAP-Response/AKA-
Identity. The AT_IDENTITY attribute contains IMSI is a string
of not more than 15 digits. MCC and MNC uniquely identify the current identity
operator.

Internet AAA protocols identify users with the Network Access
Identifier (NAI) [5]. 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 (IMSI or pseudonym).
within the realm. The AAA nodes use the realm portion of pseudonyms for
anonymity is specified the NAI to
route AAA requests to the correct AAA server. The realm name used in Section 5.

This case is illustrated
this protocol MAY be chosen by the operator and it MAY a
configurable parameter in the figure below.

If the AT_IDENTITY attribute contains a valid cleartext identity or
a pseudonym identity that client implementation. In this
case, the EAP server client is able to decode to the
cleartext identity, then the authentication sequence proceeds as
usual typically configured with the EAP Server issuing the EAP-Request/AKA-Challenge
message. The operation in the case when NAI realm of the AT_IDENTITY attribute
contains
home operator. Operators MAY reserve a pseudonym specific realm name for
EAP/AKA users. This convention makes it easy to recognize that the EAP server fails
NAI identifies a subscriber that uses EAP/AKA. Such reserved NAI
realm may be useful as a hint as to decode is
specified in Section 5.

5. Identity Privacy Support

In the very first connection authentication method
to an EAP server, the client always
transmits the cleartext identity (IMSI) use during method negotiation.

There are three types of NAI username portions in EAP/AKA: non-
pseudonym permanent usernames that are based on the EAP-Response/Identity
packet or in IMSI, pseudonym
usernames and re-authentication usernames. The first two are only
used on full authentication and the AT_IDENTITY attribute. In subsequent connections, last one only on re-
authentication. When the optional identity IMSI privacy support can be used to hide the
identity and to make is not used,
the connections unlinkable to a passive
eavesdropper. non-pseudonym permanent username is used. The EAP-Request/AKA-Challenge message MAY include an encrypted
pseudonym in the value field non-pseudonym
permanent username is of the AT_ENCR_DATA attribute. The
AT_IV and AT_MAC attributes are also used to transport format "0imsi". In other words, the pseudonym
to
first character of the client, username is the digit zero (ASCII value
0x30), followed by the IMSI. The IMSI is an ASCII string that
consists of not more than 15 decimal digits (ASCII values between
0x30 and 0x39) as described specified in Section 8.2. Because [12]

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 for example EAP/SIM. The EAP/AKA server MAY propose EAP/AKA
even if the leading character was not "0".

When the optional identity privacy support is optional to implement, used on full
authentication, the client MAY ignore use the
AT_IV, AT_ENCR_DATA, and AT_MAC attributes and always transmit pseudonym received as part of
the
cleartext identity previous full authentication sequence as the username portion of
the NAI, as specified in Section 6. The client MUST NOT modify the EAP-Response/Identity packet and
pseudonym received in AT_NEXT_PSEUDONYM. For example, the
AT_IDENTITY attribute. client
MUST NOT append any leading characters in the pseudonym.

On receipt re-authentication, the client uses the re-authentication identity
received as part of the EAP-Request/AKA-Challenge, previous authentication sequence as the NAI.
A new re-authentication identity may be delivered as part of both
full authentication and re-authentication. The client verifies MUST NOT
modify the
AT_AUTN attribute before looking at re-authentication identity received in AT_NEXT_REAUTH_ID.
For example, the AT_ENCR_DATA or AT_MAC
attributes. If client MUST NOT append any leading characters in
the AUTN re-authentication identity.

If no configured realm name is invalid, then available, the client MUST ignore MAY derive the
realm name from the MCC and MNC portions of the IMSI. In this case,
the realm name is obtained by concatenating "mnc", the MNC digits of

Arkko and Haverinen Expires in six months [Page 11]

EAP AKA Authentication June October 2002

AT_IV, AT_ENCR_DATA and AT_MAC attributes. If AUTN is valid, then
the client MAY derive

IMSI, ".mcc", the K_encr MCC digits of IMSI and K_int keys as described in
Section 9 ".owlan.org". For example,
if the IMSI is 123456789098765, and verify the AT_MAC attribute. MNC is three digits long,
then the derived realm name is "mnc456.mcc123.owlan.org".
If the AT_MAC attribute client is valid, then not able to determine whether the MNC is two or
three digits long, the client MAY decrypt the encrypted data and use the
pseudonym in the next authentication. a 3-digit MNC. If the MAC correct
length of the MNC is invalid, two, then the encrypted data MUST be ignored and the whole EAP packet MAY be
silently ignored.

The EAP server produces pseudonyms MNC used in an implementation-dependent
manner. Please see [8] the realm name will
include the first digit of MSIN. Hence, when configuring AAA
networks for examples on how to produce pseudonyms.
Only operators that have 2-digit MNC's, the network SHOULD
also be prepared for realm names with incorrect 3-digit MNC's.

5. Obtaining Subscriber Identity via EAP server needs to AKA Messages

It may be able to map the pseudonym useful to obtain the
cleartext identity. Regardless identity of construction method, the pseudonym
MUST conform to subscriber through
means other than EAP Request/Identity. This can eliminate the grammar specified need
for the username portion of an
NAI. The identity request when using EAP AKA server MAY produce pseudonyms that begin with a
leading "0" character in order to method negotiation. If this
was not possible then it might not be able possible to use the leading
character negotiate EAP/AKA
as a hint in EAP method negotiation during next
authentication.

On the next connection to the second method since it is not specified how to deal with a
new EAP server, the client MAY transmit
the received pseudonym in the first EAP-Response/Identity packet.
The client concatenates Request/Identity.

If the received EAP server does not have any identity (IMSI, pseudonym with the "@"
character and the NAI realm portion. The client MUST use the same
realm portion that it used in the connection or re-
authentication username) available when it received sending the
pseudonym.

If first EAP/AKA
request, then the EAP server issues may issue the EAP-Request/AKA-Identity
packet and includes the AT_ANY_ID_REQ attribute (specified in
Section 10.5). This attribute does not contain any data.

The AT_ANY_ID_REQ attribute requests the client to include the
AT_IDENTITY attribute (specified in Section 10.6) in the EAP-
Response/AKA-Identity packet, as specified packet. The identity format in Section 4, the client
MAY transmit a pseudonym AT_IDENTITY
attribute is the same as in the AT_IDENTITY EAP-Response/Identity packet. The
AT_IDENTITY attribute contains an IMSI-based permanent identity, a
pseudonym identity or a re-authentication identity. If the EAP server successfully decodes
does not support re-authentication, it uses the pseudonym AT_FULLAUTH_ID_REQ
attribute instead of the AT_ANY_ID_REQ attribute to directly request
for a known identity, then
the full authentication proceeds with identity (either the EAP-Request/AKA-Challenge
packet as usual. permanent identity or
a pseudonym identity). If the EAP server fails to decode the pseudonym to a known client
name, then uses the EAP server requests AT_FULLAUTH_ID_REQ
attribute, the cleartext client MUST NOT use a re-authentication identity (non-
pseudonym identity) by issuing in
the EAP-Request/AKA-Identity packet
to AT_IDENTITY attribute.

The use of pseudonyms for anonymity is specified in Section 6. The
use of re-authentication identities is specified in Section 7.

This case for full authentication is illustrated in the client. figure
below. In this case, AT_IDENTITY contains either the EAP request packet includes
AT_PERMANENT_IDENTITY_REQ to request the client to send its non- permanent
identity or a pseudonym identity. The client responds with same sequence is also used in
case the EAP-Response/AKA-
Identity, which includes the client's identity in the clear in the
AT_PERMANENT_IDENTITY attribute.

The EAP server issues the EAP-Request/AKA-Identity message also in
the case when it received the undecodable pseudonym in AT_IDENTITY
included the EAP-Response/AKA-Identity. In this case, there are two
EAP/AKA-Identity round trips. The authentication sequence proceeds
similarly in both cases.

Please note that the EAP/AKA client and the EAP/AKA server only
process the AKA-Identity packets and entities that only pass through
EAP packets do not process these packets. Hence, if uses the EAP server
is not co-located AT_FULLAUTH_ID_REQ in the authenticator, then the authenticator and
other intermediate AAA elements (such as possible AAA proxy servers)
will continue to refer to the client with the original pseudonym EAP-Request/AKA-
Identity

Arkko and Haverinen Expires in six months [Page 12]

EAP AKA Authentication June October 2002

identity from the EAP-Response/Identity packet regardless if the
decoding fails in the EAP server.

The figure below illustrates the case when an undecodable pseudonym
is received in EAP-Response/Identity.

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to decode the does not have any |
| | Pseudonym. Subscriber identity available|
| | When starting EAP/AKA |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (Includes AT_PERMANENT_IDENTITY_REQ) (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/AKA-Identity |
| (Includes cleartext identity in AT_PERMANENT_IDENTITY)| (AT_IDENTITY) |
|------------------------------------------------------>|
| |

After receiving the EAP-Response/AKA-Identity packet,

If the EAP server
issues client wants to perform full authentication, it includes the EAP-Request/AKA-Challenge and
permanent identity or a pseudonym identity in the authentication proceeds
as usual. AT_IDENTITY
attribute. The figure below illustrates the case when client may use these identities in response to either
AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ. If the EAP server fails uses the
AT_ANY_ID_REQ and the client wants to
decode perform re-authentication,
then the pseudonym included client includes a re-authentication identity in the
AT_IDENTITY attribute.

Arkko

If the client uses its full authentication identity and Haverinen Expires in six months [Page 13]

EAP AKA the
AT_IDENTITY attribute contains a valid permanent identity or a valid
pseudonym identity that the EAP server is able to decode to the
permanent identity, then the full authentication sequence proceeds
as usual with the EAP Server issuing the EAP-Request/AKA-Challenge
message.

On re-authentication, if the AT_IDENTITY attribute contains a valid
re-authentication identity and the server agrees on using re-
authentication, then the server proceeds with the re-authentication
sequence and issues the EAP-Request/AKA-Reauthentication packet, as
specified in Section 7. If the server does not recognize the re-
authentication identity, then the server issues a second EAP-
Request/AKA-Identity message and includes the AT_FULLAUTH_ID_REQ
attribute. In this case, a second EAP/AKA-Identity round trip is
required. The messages used on the first roundtrip are ignored. This
is illustrated below.

Arkko and Haverinen Expires in six months [Page 13]

EAP AKA Authentication June October 2002

Client Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP/AKA |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (Includes AT_IDENTITY_REQ) (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| |
|EAP-Response/AKA-Identity
|
|(Includes a pseudonym AT_IDENTITY) EAP-Response/AKA-Identity |
|------------------------------------------------------>|
| (AT_IDENTITY containing a re-authentication identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to decode the does not recognize |
| | Pseudonym in AT_IDENTITY The re-authentication |
| | Identity |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (Includes AT_PERMANENT_IDENTITY_REQ) (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/AKA-Identity |
| (Includes AT_PERMANENT_IDENTITY) (AT_IDENTITY with a full-auth. Identity) |
|------------------------------------------------------>|
| |

After the latter EAP-Response/AKA-Identity message, the
authentication sequence proceeds as usual with the EAP Server
issuing the EAP-Request/AKA-Challenge message.

If the client believes that the server should be able to decode recognizes the
pseudonym re-authentication identity, the client MAY refuse but still
wants to send a clear text
identity. fall back on full authentication, the server may issue the
EAP-Request/AKA-Challenge packet. In this case, the client silently ignores the EAP-
Request/AKA-Identity packet that contains AT_PERMANENT_IDENTITY_REQ.
This full
authentication procedure proceeds as usual.

An extra EAP/AKA-Identity round trip is necessary in some environments to prevent Man-in-the-Middle
attackers from claiming to be servers that do not recognize the
pseudonym, also required in an effort to find out cases when
the true AT_IDENTITY attribute contains a pseudonym identity of the user.

Because the keys that are used to protect the pseudonym are derived
from EAP
server fails to decode. The operation in this case is specified in
Section 6.

6. Identity Privacy Support

EAP/AKA includes optional identity privacy (anonymity) support that
can be used to hide the AKA cipher key (CK) cleartext IMSI and to make the AKA integrity key (IK), subscriber's
connections unlinkable to eavesdroppers. Identity privacy is based
on temporary identities, or pseudonyms, which are equivalent to but
separate from the Temporary Mobile Subscriber Identities (TMSI) that
are used on cellular networks.

If identity privacy support is not available when EAP AKA is used in or if the GSM compatible mode.

6. Message Format

The Type-Data of client does not have any
pseudonyms or re-authentication identities are available, the EAP AKA packets begins with a 1-octet Subtype
field, which is followed by a 2-octet reserved field. The rest of client

Arkko and Haverinen Expires in six months [Page 14]

EAP AKA Authentication June October 2002

transmits the Type-Data consists of attributes that are encoded permanent identity (based on IMSI) in Type,
Length, Value format. The figure below shows the generic format of
an EAP-
Response/Identity packet or in the AT_IDENTITY 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 EAP-Request/AKA-Challenge message MAY include an encrypted
pseudonym in the particular type value field of the AT_ENCR_DATA attribute. The attribute type
values
AT_IV and AT_MAC attributes are listed also used to transport the pseudonym
to the client, as described in Section 11.

Length

Indicates 10.1. Because the length of this attribute in multiples of 4 bytes.
The maximum length of an attribute identity
privacy support is 1024 bytes. The length
includes optional to implement, the Attribute Type client MAY ignore the
AT_IV and Length bytes.

Value

The particular data associated with this attribute. This field is
always included AT_ENCR_DATA attributes and it may be two or more bytes always transmit the IMSI-based
permanent identity in length. The
type and length fields determine the format EAP-Response/Identity packet and length in the
AT_IDENTITY attribute.

On receipt of the
value field.

When an EAP-Request/AKA-Challenge, the client verifies the
AT_MAC attribute numbered within before looking at the range 0 through 127 AT_ENCR_DATA attribute. If
the AT_MAC is
encountered but not recognized, invalid, then the EAP/AKA message containing that
attribute client MUST be silently discarded. These attributes are called
non-skippable attributes.

When an attribute numbered in discard the range 128 through 255 is
encountered but not recognized that particular EAP
packet. If the AT_MAC attribute is ignored,
but valid, then the rest of client MAY
decrypt the attributes and message encrypted data MUST still be
processed. The Length field of the attribute is used to skip the
attribute value in searching for AT_ENCR_DATA and use the obtained
pseudonym on the next attribute. These
attributes are called skippable attributes.

EAP/AKA packets do full authentication.

If the client does not include receive a version field. However, should
there be 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 pseudonym in a backward-compatible manner.

Unless otherwise specified, the order EAP-
Request/AKA-Challenge message, the client MAY use an old pseudonym
instead of the attributes permanent identity on next full authentication.

The EAP server produces pseudonyms in an implementation-dependent
manner. Please see [8] for examples on how to produce pseudonyms.
Only the EAP
AKA message is insignificant, and server needs to be able to map the pseudonym to the
permanent identity. Regardless of construction method, the pseudonym
MUST conform to the grammar specified for the username portion of an
NAI. The EAP AKA implementation should
not assume server MAY produce pseudonyms that begin with a certain
leading "0" character in order to be used.

Attributes can be encapsulated within other attributes. In other
words, able to use the value field of leading
character as a hint in EAP method negotiation during next
authentication.

On the next full authentication with the EAP server, the client MAY
transmit the received pseudonym in the first EAP-Response/Identity
packet. The client concatenates the received pseudonym with the "@"
character and the NAI realm portion. The client selects the realm
name portion similarly as it select the realm name portion when
using the permanent identity. If the EAP server successfully decodes
the pseudonym received in the EAP-Response/Identity packet to a
known client identity (IMSI), the authentication proceeds with the
EAP-Request/AKA-Challenge message as usual.

Because the client may fail to save a pseudonym sent to in an attribute type can be EAP-
Request/AKA-Challenge, for example due to malfunction, the EAP
server SHOULD maintain at least one old pseudonym in addition to the
most recent pseudonym.

If the EAP server requests the client to include its identity in the
EAP-Response/AKA-Identity packet, as specified in Section 5, the
client MAY transmit the received pseudonym in the AT_IDENTITY
attribute. If the EAP server successfully decodes the pseudonym to
contain other attributes. a
known identity, then the authentication proceeds with the EAP-
Request/AKA-Challenge packet as usual.

Arkko and Haverinen Expires in six months [Page 15]

EAP AKA Authentication June October 2002

7. Message Integrity and Privacy Protection

This section specifies EAP/AKA attributes for attribute encryption
and EAP/AKA message integrity protection.

Encryption and integrity protection are based on the AKA session
keys CK and IK. Because

If the CK and IK keys are derived from EAP server fails to decode the RAND
challenge, these attributes can only be used in pseudonym to a known identity,
then the EAP-Request/AKA-
Challenge message and any EAP/AKA messages sent after EAP-
Requets/AKA-Challenge. For example, these attributes cannot be used
in EAP-Request/AKA-Identity, because EAP server requests the RAND challenge has not yet
been transmitted at that point. As there is no key derivation
specification for permanent identity (non-pseudonym
identity) by including the GSM mode, AT_PERMANENT_ID_REQ attribute encryption and message
integrity protection are not available (Section
10.5) in the GSM mode.

7.1. AT_MAC Attribute EAP-Request/AKA-Challenge message.

The AT_MAC attribute can optionally be used for EAP/AKA EAP server issues the EAP-Request/AKA-Identity message
integrity protection. Whenever AT_ENCR_DATA (Section 7.2) is
included also in an EAP message,
the case when it MUST be followed (not necessarily
immediately) by an AT_MAC attribute. Messages that do not meet this
condition MUST be silently discarded.

The value field of received the AT_MAC attribute contains two reserved bytes
followed by undecodable pseudonym in AT_IDENTITY
included the EAP-Response/AKA-Identity packet. In this case, a message authentication code (MAC). The MAC
second EAP/AKA-Identity round trip is
calculated over required.

A received AT_PERMANENT_ID_REQ does not necessarily originate from
the whole EAP valid network, but an active attacker may transmit an EAP-
Request/AKA-Identity packet with the exception that the
value field of the MAC an AT_PERMANENT_ID_REQ attribute is set to zero when calculating
the
MAC. The reserved bytes are set client, in an effort to zero when sending and ignored on
reception. The format find out the true identity 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 [9] 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 user.
On receipt of EAP-Request/AKA-Identity that includes
AT_PERMANENT_ID_REQ, the MAC is
16 bytes.) The integrity protection key (K_int) used in client MAY delay the
calculation processing of the MAC is derived from the AKA integrity key (IK)
and cipher key (CK), as specified
message for a while in Section 9.

7.2. AT_IV and AT_ENCR_DATA Attributes

AT_IV and AT_ENCR_DATA attributes can be optionally used order to transmit
encrypted information between the EAP/AKA client and server.

Arkko and Haverinen Expires in six months [Page 16] wait for another EAP AKA Authentication June 2002

The value field of AT_IV contains two reserved bytes followed by a
16-byte initialization vector required by message
that does not include the AT_ENCR_DATA AT_PERMANENT_ID_REQ attribute. The reserved bytes

Basically, there are set two different policies that the client can
employ with regard to zero when sending and
ignored on reception. The AT_IV attribute MUST be included if and
only if AT_PERMANENT_ID_REQ. A "conservative" client
assumes that the AT_ENCR_DATA network is included. Messages that do not meet this
condition MUST be silently discarded.

The sender of able to maintain pseudonyms robustly.
Therefore, if a conservative client has a pseudonym, the AT_IV attribute chooses client
silently ignores the initialization vector
by random. The sender MUST NOT reuse EAP packet with AT_PERMANENT_ID_REQ, because
the initialization vector value
from previous EAP AKA packets but client believes that the sender MUST choose it freshly valid network is able to decode the
pseudonym. (Alternatively, the conservative client may respond to
AT_PERMANENT_ID_REQ in certain circumstances, for each AT_IV attribute. The sends SHOULD use example if the
pseudonym was received a good source long time ago.) The benefit of
randomness to generate this policy
is that it protects the initialization vector. client against active attacks on anonymity.
On the other hand, a "liberal" client always accepts the
AT_PERMANENT_ID_REQ and responds with the IMSI-based permanent
identity. The format benefit of
AT_IV this policy 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_IV | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Vector |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ that it works even if the
valid network sometimes loses pseudonyms and is not able to decode
them to the permanent identity.

The value field of the AT_ENCR_DATA AT_PERMANENT_ID_REQ does not contain any data
but the attribute consists of two
reserved bytes followed by bytes encrypted using is included to request the Advanced
Encryption Standard (AES) [10] client to include the
AT_IDENTITY attribute (Section 10.6) with the permanent
authentication identity in the Cipher Block Chaining (CBC)
mode of operation, using EAP-Response/AKA-Identity message. In
this case, the initialization vector from AT_IDENTITY attribute contains the AT_IV
attribute. The reserved bytes are set to zero when sending and
ignored on reception. client's permanent
identity in the clear.

Please see [11] for a description of note that the CBC
mode. The format of EAP/AKA client and 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 encryption key (K_encr) is derived EAP/AKA server only
process the AT_IDENTITY attribute and entities that only pass
through EAP packets do not process this attribute. Hence, if the EAP
server is derived from not co-located in the AKA
integrity key (IK) authenticator, then the
authenticator and cipher key (CK), other intermediate AAA elements (such as specified possible
AAA proxy servers) will continue to refer to the client with the
original identity from the EAP-Response/Identity packet regardless
if the decoding fails in Section 9. the EAP server.

The plaintext consists of nested EAP/AKA attributes.

8. Messages figure below illustrates the case when the EAP server fails to
decode the pseudonym included in the EAP-Response/Identity packet.

Arkko and Haverinen Expires in six months [Page 17] 16]

EAP AKA Authentication June October 2002

8.1. EAP-Response/Identity

In the beginning of EAP authentication, the

Client Authenticator issues the
| |
| EAP-Request/Identity packet |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to decode the client. The client responds |
| | Pseudonym. |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with
EAP-Response/Identity, which contains permanent identity) |
|------------------------------------------------------>|
| |

After the user's identity. The
formats of these packets are specified in [6].

The EAP AKA mechanism uses EAP-Response/AKA-Identity message, the NAI format [5] authentication
sequence proceeds as usual with the identity.
In order to facilitate EAP Server issuing the use of EAP-
Request/AKA-Challenge message.

The figure below illustrates the existing cellular roaming
infrastructure, case when the subscriber's IMSI is used as EAP server fails to
decode the client
identifier. When used pseudonym included in a roaming environment, the NAI is composed
of a username AT_IDENTITY attribute.

Arkko and a realm, separated with "@" (username@realm). The
username portion identifies the subscriber within the realm.

There are two types of NAI username portions Haverinen Expires in six months [Page 17]

EAP AKA: non-
pseudonym permanent usernames and pseudonym usernames. When identity
privacy is AKA Authentication October 2002

Client Authenticator
| |
| +------------------------------+
| | Server does not used, 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 non-pseudonym permanent username is used.
The non-pseudonym |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent username is of the format "0imsi". identity) |
|------------------------------------------------------>|
| |

In
other words, the first character of worst case, there are three EAP/AKA-Identity round trips
before the username is server has obtained an acceptable identity: on the digit zero
(ASCII value 0x30), followed by first
round, the IMSI. client sends its re-authentication identity in
AT_IDENTITY. The IMSI is an ASCII
string that consists of not more than 15 decimal digits (ASCII
values between 0x30 and 0x39) as specified in [13].

The EAP server MAY use the leading "0" as a hint fails to try EAP/AKA as
the first accept it and request a full
authentication method during method negotiation, rather
than for example EAP/SIM. The EAP/AKA server MAY propose EAP/AKA
even if the leading character was not "0".

When the optional identity privacy support is used, the client MAY
use the pseudonym received as part of the previous authentication
sequence as the username portion of the NAI, as specified in Section
5. with a second EAP-Request/AKA-Identity. The
client MUST NOT modify the responds with a pseudonym received in
AT_PSEUDONYM. For example, the client MUST NOT append any leading
characters identity in the pseudonym. AT_IDENTITY. The AAA network routes AAA requests to the correct AAA server using
the realm part of the NAI. The realm part MAY be decided by
fails to decode the
operator pseudonym and it MAY be has to issue a configurable parameter in third EAP-
Request/AKA-Identity, including AT_PERMANENT_ID_REQ. Finally, the EAP/AKA
client implementation. In this case,
server accepts the client is typically
configured client's EAP-Response/AKA-Identity with the NAI realm of the home operator.
Because cellular roaming can be used
AT_IDENTITY attribute and proceeds with EAP AKA, the AAA request
can be routed to an AAA server full authentication. This is
illustrated in the visited network instead of the
server indicated figure below.

Arkko and Haverinen Expires in the NAI realm. Network operators that wish to
apply this approach must make the necessary arrangements before this
special routing can be enabled. Operators MAY reserve a specific
realm portion of NAI for six months [Page 18]

EAP AKA users. This convention makes it
easy to recognize that the NAI identifies a UMTS or GSM subscriber.
Such reserved NAI realm may be useful as Authentication October 2002

Client 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 re-authentication identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not accept |
| | The re-authentication |
| | Identity |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
| |
|EAP-Response/AKA-Identity |
|(AT_IDENTITY with a hint as pseudonym identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to decode the first
authentication method to use during method negotiation.

If no configured realm name is available |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |

After the client, last EAP-Response/AKA-Identity message, the client
MAY derive full
authentication sequence proceeds as usual with the realm name EAP Server
issuing the EAP-Request/AKA-Challenge message.

Because the keys that are used to protect the pseudonym are derived
from the IMSI. The IMSI is composed of a
three digit Mobile Country Code (MCC), a two or three digit Mobile
Network Code (MNC) AKA cipher key (CK) and a the AKA integrity key (IK), the
identity privacy support is not more than 10 digit Mobile Subscriber available when EAP AKA is used in
the GSM compatible mode.

Arkko and Haverinen Expires in six months [Page 18] 19]

EAP AKA Authentication June October 2002

Identification Number (MSIN).

7. Re-authentication

In other words, some environments, EAP authentication may be performed
frequently. Because the IMSI is a string
of not more than 15 digits. MCC and MNC uniquely identify EAP AKA full authentication procedure makes
use of the
operator. A NAI realm name can be derived UMTS AKA algorithms, and it therefore requires fresh
authentication vectors from the IMSI by
concatenating "mnc", Authentication Centre, the MNC digits full
authentication procedure is not very well suitable for frequent use.
Therefore, EAP AKA includes a more inexpensive re-authentication
procedure that does not make use of IMSI, ".mcc", the MCC digits
of IMSI UMTS AKA algorithms and ".owlan.org". For example, if does
not need new vectors from the IMSI Authentication Centre.

Re-authentication is
123456789098765, optional to implement for both the EAP AKA
server and client. On each EAP authentication, either one of the MNC
entities may also fall back on full authentication if they do not
want to use re-authentication.

Re-authentication is three digits long, then based on the keys derived
realm name is "mnc456.mcc123.owlan.org".

If on the client is not able preceding full
authentication. The same K_aut and K_encr keys as in full
authentication are used to determine whether protect EAP AKA packets and attributes,
and the MNC original XKEY seed value from full authentication is two or
three digits long, used to
generate fresh application specific keys, as specified in Section
12.

On re-authentication, the client MAY use a 3-digit MNC. If protects against replays with an
unsigned 16-bit counter, included in the correct
length of AT_COUNTER attribute. On
full authentication, both the MNC is two, then server and the MNC used in client initialize the realm name will
include
counter to one. The counter value of at least one is used on the
first digit of MSIN. Hence, when configuring AAA
networks for operators that have 2-digit MNC's, re-authentication. On subsequent re-authentications, the network SHOULD
also
counter MUST be prepared for realm names with incorrect 3-digit MNC's.

8.2. EAP-Request/AKA-Challenge

The format greater than on any of the EAP-Request/AKA-Challenge packet previous re-
authentications. For example, on the second re-authentication,
counter value is shown two or greater etc. The AT_COUNTER attribute is
encrypted.

The server includes an encrypted server nonce (AT_NONCE_S) in the
re-authentication request. The AT_MAC attribute in the client's
response is calculated over NONCE_S to provide a challenge/response
authentication scheme. The NONCE_S also contributes to the new
application specific keys.

As discussed in Section 6, in some environments the client may
assume that the network can reliably store pseudonyms and therefore
the client may fail to respond to the AT_PERMANENT_ID_REQ attribute.
The network SHOULD store pseudonyms on a reliable database. Because
one of the objectives of the re-authentication procedure is to
reduce load on the network, the re-authentication procedure does not
require the EAP server to contact a reliable database. Therefore,
the re-authentication procedure makes use of separate re-
authentication user identities. Pseudonyms and the permanent IMSI-
based identity are reserved for full authentication only. The
network does not need to store re-authentication identities as
carefully as pseudonyms. If a re-authentication identity is lost and
the network does not recognize it, the EAP server can fall back on
full authentication.

Arkko and Haverinen Expires in six months [Page 20]

EAP AKA Authentication October 2002

If the EAP server supports 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 re-authentication. The client
MAY ignore this attribute, in which case it will use full
authentication next time. If the client wants to use re-
authentication, it uses this re-authentication identity on next
authentication. Even if the client has a re-authentication identity,
the client MAY discard the re-authentication identity and use a
pseudonym or the IMSI-based permanent identity instead, in which
case full authentication will be performed.

The re-authentication identity received in AT_NEXT_REAUTH_ID
contains both the username portion and the realm portion of the
Network Access Identifier. The EAP Server can choose an appropriate
realm part in order to have the AAA infrastructure route subsequent
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 re-authentication in the AAA server that performed the
full authentication.

The client MAY use the re-authentication identity in the EAP-
Response/Identity packet or, in response to server's AT_ANY_ID_REQ
attribute, the client MAY use the re-authentication identity in the
AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet.

Even if the client uses a re-authentication identity, the server may
want to fall back on full authentication, for example because the
server does not recognize the re-authentication identity or does not
want to use re-authentication. If the server was able to decode the
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 client's
identity from the 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. (As specified in
Sections 5 and 6, the server MAY use AT_ANY_ID_REQ,
AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ attributes if it does not
know the client's identity.)

Both the client and the server SHOULD have an upper limit for the
number of subsequent re-authentications allowed before a full
authentication needs to be performed. Because a 16-bit counter is
used in re-authentication, the theoretical maximum number of re-
authentications is reached when the counter value reaches 0xFFFF.

In order to use re-authentication, the client and the server need to
store the following values: original XKEY, K_aut, K_encr, latest
counter value and the next re-authentication identity.

The following figure illustrates the re-authentication procedure.
Encrypted attributes are denoted with '*'. The client uses its re-

Arkko and Haverinen Expires in six months [Page 21]

EAP AKA Authentication October 2002

authentication identity in the EAP-Response/Identity packet. As
discussed above, an alternative way to communicate the re-
authentication identity to the server is for the client 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 the client to send its identity by
including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-
Identity packet.

If the server recognizes the re-authentication identity and agrees
on using re-authentication, then the server sends the EAP-
Request/AKA-Reauthentication packet to the client. 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 re-authentication identity.

Re-authentication identities are one-time identities. If the client
does not receive a new re-authentication identity, it MUST use
either the permanent identity or a pseudonym identity on the next
authentication to initiate full authentication.

The client verifies that the counter value is fresh (greater than
any previously used value). The client also verifies that AT_MAC is
correct. The client MAY save the next re-authentication identity
from the encrypted AT_NEXT_REAUTH_ID for next time. If all checks
are successful, the client 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 re-
authentication has succeeded and the server sends the EAP-Success
packet to the client.

Arkko and Haverinen Expires in six months [Page 22]

EAP AKA Authentication October 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a 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) |
|<------------------------------------------------------|
| |
| |
+-----------------------------------------------+ |
| Client verifies AT_MAC and the freshness of | |
| the counter. Client 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 |
|<------------------------------------------------------|
| |

If the client 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 the following figure. Encrypted attributes are
denoted with '*'.

Arkko and Haverinen Expires in six months [Page 23]

EAP AKA Authentication October 2002

Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a 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 client has included AT_COUNTER_TOO_SMALL|
| +----------------------------------------------+
| |
| EAP-Request/AKA-Challenge |
|<------------------------------------------------------|
| |
+---------------------------------------------------------------+
| Normal full authentication follows. |
+---------------------------------------------------------------+
| |

In the figure above, the first three messages are similar to the
basic re-authentication case. When the client detects that the
counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
attribute in EAP-Response/AKA-Reauthentication. This attribute
doesn't contain any data but it is a request for the server to
initiate full authentication. In this case, the client 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 as in the EAP-
Request/AKA-Reauthentication packet. If not, the server silently
discards the EAP-Response/AKA-Reauthentication packet. If all checks
on the packet are successful, the server transmits a EAP-
Request/AKA-Challenge packet and the full authentication procedure
is performed as usual. Since the server already knows the subscriber
identity, it MUST NOT use the EAP-Request/AKA-Identity packet to
request the subscriber identity.

Arkko and Haverinen Expires in six months [Page 24]

EAP AKA Authentication October 2002

8. Message Format

The Type-Data of the EAP AKA packets begins with a 1-octet Subtype
field, which is followed by a 2-octet reserved field. The rest of
the Type-Data consists of attributes that are encoded in Type,
Length, Value format. The figure below shows the generic format of
an attribute.

Attribute Type

Indicates the particular type of attribute. The attribute type
values are listed in Section 14.

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 may be two or more bytes in length. The
type and length fields determine the format and length of the
value field.

When an attribute numbered within the range 0 through 127 is
encountered but not recognized, the EAP/AKA message containing that
attribute MUST be silently discarded. These attributes are called
non-skippable attributes.

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 in searching for the next attribute. These
attributes are called skippable attributes.

EAP/AKA packets do not include a version field. However, should
there be 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.

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 to be used.

Arkko and Haverinen Expires in six months [Page 25]

EAP AKA Authentication October 2002

Attributes can be encapsulated within other attributes. In other
words, the value field of an attribute type can be specified to
contain other attributes.

9. Message Authentication and Encryption

This section specifies EAP/AKA attributes for attribute encryption
and EAP/AKA message authentication.

Encryption and integrity protection are based on the AKA session
keys CK and IK. Because the CK and IK keys are derived from the RAND
challenge, these attributes can only be used in the EAP-Request/AKA-
Challenge message and any EAP/AKA messages sent after EAP-
Request/AKA-Challenge. For example, these attributes cannot be used
in EAP-Request/AKA-Identity, because the RAND challenge has not yet
been transmitted at that point. As there is no key derivation
specification for the GSM mode, attribute encryption and message
integrity protection are not available in the GSM mode.

9.1. AT_MAC Attribute

The AT_MAC attribute can optionally be used for EAP/AKA message
integrity protection. Whenever AT_ENCR_DATA (Section 9.2) is
included in an EAP message, it MUST be followed (not necessarily
immediately) by an AT_MAC attribute. Messages that do not meet this
condition MUST be silently discarded.

The value field of the AT_MAC attribute contains two reserved bytes
followed by a message authentication code (MAC). The MAC is
calculated over the whole EAP packet, 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
reserved bytes are set to zero when sending and ignored on
reception.

The contents of the message-specific data, if present, are specified
separately for each EAP/AKA message. The message-specific data is
included in order to protect data that is not transmitted with the
EAP packet.

The format of the AT_MAC attribute is shown below.

Arkko and Haverinen Expires in six months [Page 26]

EAP AKA Authentication October 2002

The MAC algorithm is HMAC-SHA1-128 [9] 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 message authentication key (K_aut) used in
the calculation of the MAC is derived from the AKA integrity key
(IK) and cipher key (CK), as specified in Section Error!
Reference source not found..

9.2. AT_IV, AT_ENCR_DATA and AT_PADDING Attributes

AT_IV and AT_ENCR_DATA attributes can be optionally used to transmit
encrypted information between the EAP/AKA client 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. Messages that do not meet this
condition MUST be silently discarded.

The sender of the AT_IV attribute chooses the initialization vector
by random. The sender MUST NOT reuse the initialization vector value
from previous EAP AKA packets but the sender MUST choose it freshly
for each AT_IV attribute. The sends SHOULD use a good source of
randomness to generate the initialization vector. The format of
AT_IV is shown below.

The value field of the AT_ENCR_DATA attribute consists of two
reserved bytes followed by bytes encrypted using the Advanced
Encryption Standard (AES) [10] in the Cipher Block Chaining (CBC)
mode of operation, using the initialization vector from the AT_IV
attribute. The reserved bytes are set to zero when sending and
ignored on reception. Please see [11] for a description of the CBC
mode. The format of the AT_ENCR_DATA attribute is shown below.

Arkko and Haverinen Expires in six months [Page 27]

EAP AKA Authentication October 2002

The encryption key (K_encr) is derived is derived from the AKA
integrity key (IK) and cipher key (CK), as specified in Section
Error! Reference source not found..
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 (0x00) on sending. The recipient of the message MUST
verify that the pad bytes are set to zero, and silently drop the
message if this verification fails. 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. Messages

AT_NEXT_PSEUDONYMEAP-Request/AKA-Challenge

The format of the EAP-Request/AKA-Challenge packet is shown below.

Arkko and Haverinen Expires in six months [Page 28]

EAP AKA Authentication October 2002

The semantics of the fields is described below:

Code

1 for Request

Identifier

See [6]

Arkko and Haverinen Expires in six months [Page 29]

EAP AKA Authentication October 2002

Length

The length of the EAP Request packet.

Type

Subtype

1 for AKA-Challenge

Reserved

Set to zero when sending, ignored on reception.

AT_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. The AT_RAND attribute MUST be present in EAP-
Request/AKA-Challenge.

AT_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. The AT_AUTN attribute MUST NOT be included in the GSM
compatible mode of this protocol; otherwise it MUST be included.

AT_IV

See Section 9.2.

AT_ENCR_DATA

See Section 9.2. The nested attributes that are included in the
plaintext of AT_ENCR_DATA are described below.

AT_MAC

AT_MAC MUST NOT be included in GSM compatible mode; otherwise it
MUST be included. In EAP-Request/AKA-Challenge, there is no
message-specific data covered by the MAC. See Section 9.1.

In the EAP-Request/AKA-Challege message, the AT_IV, AT_ENCR_DATA and
AT_MAC attributes are used for IMSI privacy and for communicating
the next re-authentication identity. The plaintext of the
AT_ENCR_DATA value field consists of nested attributes, which are
shown below. Later versions of this protocol MAY specify additional
attributes to be included within the encrypted data.

Arkko and Haverinen Expires in six months [Page 30]

EAP AKA Authentication October 2002

AT_NEXT_PSEUDONYM

This attribute is optional. The value field of this attribute
begins with 2-byte actual pseudonym length, which specifies the
length of the pseudonym in bytes. This field is followed by a
pseudonym user name, of the indicated actual length, that the
client can use in the next authentication, as described in
Section 6. The user name 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.

AT_NEXT_REAUTH_ID

The AT_NEXT_REAUTH_ID attribute is optional to include. The value
field of this attribute begins with 2-byte actual re-
authentication identity length, which specifies the length of the
re-authentication identity in bytes. This field is followed by a
re-authentication identity, of the indicated actual length, that
the client can use in the next re-authentication, as described in
Section 7. The re-authentication identity includes both a
username portion and a realm name portion. The 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 re-authentication identity with zero
bytes when necessary.

AT_PADDING

AT_PADDING is optional to include. See Section 9.2.

Arkko and Haverinen Expires in six months [Page 31]

EAP AKA Authentication October 2002

10.2. EAP-Response/AKA-Challenge

The format of the EAP-Response/AKA-Challenge packet is shown below.

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. AT_MAC, AT_ENCR_DATA and AT_IV attributes are not shown
in the figure below. If present, they are processed as in EAP-
Request/AKA-Challenge packet. The EAP server MUST process EAP-
Response/AKA-Challenge messages that include these attributes even
if the server did not implement these optional attributes.

The semantics of the fields is described below:

Code

2 for Response

Identifier

See [6]

Length

The length of the EAP Response packet.

Type

Arkko and Haverinen Expires in six months [Page 32]

EAP AKA Authentication October 2002

Subtype

1 for AKA-Challenge

Reserved

Set to zero when sending, ignored on reception.

AT_RES

This attribute MUST be included in EAP-Response/AKA-Challenge.
The value field of this attribute begins with the 2-byte RES
Length, which is identifies the exact length of the RES (or SRES)
in bits. The RES length is followed by the UMTS AKA RES or GSM
SRES parameter. According to the specification [13] the length of
the AKA RES can vary between 32 and 128 bits. The GSM SRES
parameter is always 32 bits long. 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.

AT_MAC

AT_MAC MUST NOT be included in GSM compatible mode; otherwise it
MUST be included. In EAP-Response/AKA-Challenge, there is no
message-specific data covered by the MAC. See Section 9.1.

10.3. EAP-Response/AKA-Authentication-Reject

The format of the EAP-Response/AKA-Authentication-Reject packet is
shown below.

The semantics of the fields is described below:

Code

2 for Response

Identifier

See [6]

Length

The length of the EAP Response packet.

Arkko and Haverinen Expires in six months [Page 33]

EAP AKA Authentication October 2002

Type

Subtype

2 for AKA-Authentication-Reject

Reserved

Set to zero on sending, ignored on reception.

10.4. EAP-Response/AKA-Synchronization-Failure

The format of the EAP-Response/AKA-Synchronization-Failure packet is
shown below.

The semantics of the fields is described below:

Code

2 for Response

Identifier

See [6]

Length

The length of the EAP Response packet, 20.

Type

Subtype

4 for AKA-Synchronization-Failure

Arkko and Haverinen Expires in six months [Page 34]

EAP AKA Authentication October 2002

AT_AUTS

This attribute MUST be included in EAP-Response/AKA-
Synchronization-Failure. The value field of this attribute
contains the AKA AUTS parameter, 112 bits (14 bytes).

10.5. EAP-Request/AKA-Identity

The format of the EAP-Request/AKA-Identity packet is shown below.

The semantics of the fields is described below:

Code

1 for Request

Identifier

See [6]

Length

The length of the EAP Request packet.

Type

Subtype

5 for AKA-Identity

Reserved

Set to zero on sending, ignored on reception.

AT_PERMANENT_ID_REQ

The AT_PERMANENT_ID_REQ attribute is optional to include and it
is included in the cases defined in Section 6. It MUST NOT be

Arkko and Haverinen Expires Haverinen Expires in six months [Page 35]

EAP AKA Authentication October 2002

included if AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ is included. The
value field only contains two reserved bytes, which are set to
zero on sending and ignored on reception.

AT_FULLAUTH_ID_REQ

The AT_FULLAUTH_ID_REQ attribute is optional to include and it is
included in the cases defined in Section 5. It MUST NOT be
included if AT_ANY_ID_REQ or AT_PERMANENT_ID_REQ is included. The
value field only contains two reserved bytes, which are set to
zero on sending and ignored on reception.

AT_ANY_ID_REQ

The AT_ANY_ID_REQ attribute is optional and it is included in six months [Page 19]

EAP AKA Authentication June 2002 the
cases defined in Section 5. It MUST NOT be included if
AT_PERMANENT_ID_REQ or AT_FULLAUTH_ID_REQ is included. The value
field only contains two reserved bytes, which are set to zero on
sending and ignored on reception.

10.6. EAP-Response/AKA-Identity

The format of the EAP-Response/AKA-Identity packet is shown below.

The semantics of the fields is described below:

Code

2 for Request Response

Identifier

See [6]

Arkko and Haverinen Expires in six months [Page 20]

EAP AKA Authentication June 2002

Length

The length of the EAP Request Response packet.

Type

TBD

Subtype

1 for AKA-Challenge

Reserved

Set to zero when sending, ignored on reception.

AT_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

Arkko and Haverinen Expires in six months [Page 36]

EAP AKA Authentication October 2002

Type

Subtype

5 for AKA-Identity

Reserved

Set to zero when sending and on sending, ignored on reception.

AT_IDENTITY

The AT_RAND AT_IDENTITY attribute MUST be present is optional to include and it is
included in EAP-
Request/AKA-Challenge.

AT_AUTN cases defined in Section 5 and 6. The value field of
this attribute contains two reserved bytes begins with 2-byte actual identity length, which
specifies the length of the identity in bytes. This field is
followed by the AKA AUTN parameter, 16 bytes (128 bits). subscriber identity of the indicated actual
length, in the same Network Access Identifier format that is used
in EAP-Response/Identity, i.e. including the NAI realm portion.
The
reserved bytes are set to zero when sending and ignored on
reception. identity is the permanent IMSI-based identity, a pseudonym
identity or a re-authentication identity. The AT_AUTN attribute MUST NOT be included identity format is
specified in the GSM
compatible mode of this protocol; otherwise it MUST be included.

AT_IV

See Section 7.2.

AT_ENCR_DATA

See Section 7.2. 4. The nested attributes that are included in identity does not include any
terminating null characters. Because the
plaintext length of AT_ENCR_DATA are described below.

AT_MAC

See Section 7.1.

In the EAP-Request/AKA-Challege message, attribute
must be a multiple of 4 bytes, the AT_IV, AT_ENCR_DATA and
AT_MAC attributes are used for IMSI privacy. sender pads the identity with
zero bytes when necessary.

10.7. EAP-Request/AKA-Reauthentication

The plaintext format of the
AT_ENCR_DATA value field consists of nested attributes, which are EAP-Request/AKA-Reauthentication packet is shown
below. Later versions of this protocol MAY specify additional
attributes to be included within the encrypted data.

Arkko and Haverinen Expires in six months [Page 21] 37]

EAP AKA Authentication June October 2002

AT_PSEUDONYM

This attribute is optional.

Code

1 for Request

Identifier

See [6].

Length

The value field of this attribute
begins with 2-byte actual pseudonym length, which specifies the length of the pseudonym EAP packet.

Type

Subtype

Reserved

Set to zero when sending, ignored on reception.

Arkko and Haverinen Expires in bytes. This field six months [Page 38]

EAP AKA Authentication October 2002

AT_IV

The AT_IV attribute is followed by a
pseudonym username, of the indicated actual length, that the
client can use in the next authentication, as described in MUST be included. See Section 5. 9.2.

AT_ENCR_DATA

The username does not include any terminating null
characters. Because the length of the AT_ENCR_DATA attribute must MUST be a
multiple of 4 bytes, the sender pads the pseudonym with zero
bytes when necessary.

AT_PADDING included. See Section 9.2. 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 consists 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 as described below.

AT_MAC

AT_MAC MUST be included. No message-specific data is chosen so that included in
the length MAC calculation. See Section 9.1.

The AT_IV and AT_ENCR_DATA attributes are used for communicating
encrypted attributes. The plaintext of the AT_ENCR_DATA value field
consists of the
AT_ENCR_DATA nested attributes, which are shown below.

AT_COUNTER

The AT_COUNTER attribute becomes a multiple of 16 bytes. MUST be included. The actual
pad bytes in the value field are set to zero (0x00) on sending.
The recipient
consists of the message a 16-bit unsigned integer counter value, represented
in network byte order.

AT_NONCE_S

The AT_NONCE_S attribute MUST verify that the pad be included. The value field
contains two reserved bytes are
set to zero, followed by a random number generated

Arkko and silently drop the message if this verification
fails.

8.3. EAP-Response/AKA-Challenge

The format of the EAP-Response/AKA-Challenge packet is shown below.

As specified Haverinen Expires in Section 7, EAP-Response/AKA-Challenge MAY include
the AT_MAC attribute to integrity protect the six months [Page 39]

EAP packet. Later
versions of this protocol MAY make use of AKA Authentication October 2002

by the AT_ENCR_DATA and AT_IV
attributes in server (16 bytes) freshly for this message to include encrypted (skippable)
attributes. AT_MAC, AT_ENCR_DATA and AT_IV attributes are not shown

Arkko EAP/AKA re-
authentication. The random number is used as challenge for the
client and Haverinen Expires in six months [Page 22]

EAP AKA Authentication June 2002

in also a seed value for the figure below. If present, they new keying material. The
reserved bytes are processed as set to zero upon sending and ignored upon
reception.

AT_NEXT_REAUTH_ID

The AT_NEXT_REAUTH_ID attribute is optional to include. The
attribute is described in EAP-
Request/AKA-Challenge packet. Section 10.1.

AT_PADDING

The EAP server MUST process EAP-
Response/AKA-Challenge messages that include these attributes even
if the server did not implement these AT_PADDING attribute is optional attributes. to include. See section 9.2

10.8. EAP-Response/AKA-Reauthentication

The format of the EAP-Response/AKA-Reauthentication packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RES AT_IV | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Vector |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_ENCR_DATA | RES Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Encrypted Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MAC | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | RES
| |
| MAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The semantics of the fields is described below:

Code

2 for Response

Arkko and Haverinen Expires in six months [Page 40]

EAP AKA Authentication October 2002

Identifier

See [6] [6].

Length

The length of the EAP Response packet.

Type

TBD

Subtype

1 for AKA-Challenge

Reserved

Set to zero when sending, ignored on reception.

AT_RES

This

AT_IV

The AT_IV attribute is MUST be included in EAP-Response/AKA-Challenge. included. See Section 9.2.

AT_ENCR_DATA

The value field of this AT_ENCR_DATA attribute begins with MUST be included. See Section 9.2. The
plaintext consists of nested attributes as described below.

AT_MAC

For EAP-Response/AKA-Reauthentication, the 2-byte RES
Length, which MAC code is identifies the exact length of calculated
over the RES (or SRES)
in bits. following data:

EAP packet| NONCE_S

The RES length EAP packet is represented as specified in Section 9.1. It is
followed by the UMTS AKA RES or GSM
SRES parameter. According to the specification [14] the length of
the AKA RES can vary between 32 16-byte NONCE_S value from the client's
AT_NONCE_S attribute.

The AT_IV and 128 bits. AT_ENCR_DATA attributes are used for communicating
encrypted attributes. The GSM SRES plaintext of the AT_ENCR_DATA value field
consists of nested attributes, which are shown below.

Arkko and Haverinen Expires in six months [Page 23] 41]

EAP AKA Authentication June October 2002

parameter is always 32 bits long. 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.

8.4. EAP-Response/AKA-Authentication-Reject

The format of the EAP-Response/AKA-Authentication-Reject packet is
shown below.

AT_COUNTER

The semantics AT_COUNTER attribute MUST be included. The format of the fields this
attribute is described below:

Code

2 for Response

Identifier

See [6]

Length specified in Section 10.7.

AT_COUNTER_TOO_SMALL

The length AT_COUNTER_TOO_SMALL attribute is optional to include, and it
is included in cases specified in Section 7.

AT_PADDING

The AT_PADDING attribute is optional to include. See section 9.2

11. Unsuccessful Cases

In general, if an EAP/AKA client or server implementation detects an
error in a received EAP/AKA packet, the EAP/AKA implementation
silently ignores the EAP packet, does not change its state and does
not send any EAP messages to its peer. Examples of such errors,
specified in detail elsewhere in this document, are an invalid
AT_MAC value, a mandatory attribute is missing, illegal attributes
included and an unrecognized non-skippable attribute. If no valid
packets are received, the authentication exchange will eventually
time out.

As normally in EAP, the EAP Response packet.

Type

TBD

Subtype

2 for AKA-Authentication-Reject

Reserved

Set server sends the EAP-Failure packet to zero on sending, ignored
the client when the authentication procedure fails on reception.

8.5. EAP-Response/AKA-Synchronization-Failure

The format of the EAP-Response/AKA-Synchronization-Failure packet EAP
Server. In EAP/AKA, this may occur for example if the EAP server is
not able to obtain authentication vectors for the subscriber or the
authentication exchange times out.

12. Key Derivation

This section specifies how EAP AKA keying material is
shown below. derived from
the IK and CK keys. Because IK and CK are not available in the GSM
mode, this key derivation specification can only be applied in the
UMTS AKA mode.

Arkko and Haverinen Expires in six months [Page 24] 42]

EAP AKA Authentication June October 2002

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

EAP AKA requires two keys for its own purposes, a message
authentication key K_aut and an encryption key K_encr, to be used
with the AT_MAC and AT_ENCR_DATA attributes. The same K_aut and
K_encr keys are used in full authentication and subsequent re-
authentications. In addition, it is possible to derive additional
application specific key material, such as a master key to be used
with IEEE 802.11i.

Key derivation is based on the pseudo-random number generator
specified in NIST Federal Information Processing Standards
Publication 186-2 [14]. The pseudo-random number generator is
specified in the change notice 1 2 3 4 5 6 7 8 9 0 (2001 October 5)of [14] (Algorithm
1). As specified in the change notice (page 74), when Algorithm 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| AT_AUTS | Length = 4 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| AUTS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ is
used as a general-purpose random number generator, the "mod q" term
in step 3.2 is omitted. The semantics function G used in the algorithm is
constructed via Secure Hash Standard as specified in Appendix 3.3 of
the fields standard. For convenience, the pseudo-random number algorithm
with the correct modification is described below:

Code

2 for Response

Identifier

See [6]

Length cited in Annex B.

160-bit XKEY and XVAL values are used, so b = 160. The length of initial
secret seed value XKEY is computed from the EAP Response packet, 20.

Type

TBD

Subtype

4 for AKA-Synchronization-Failure

AT_AUTS

This AKA integrity key IK and
cipher key CK with the following formula:

XKEY = SHA1(Identity|IK|CK)

In the formula above, the "|" character denotes concatenation.
Identity denotes the user identity string without any terminating
null characters. It is the identity from the AT_IDENTITY attribute MUST be included
from the last EAP-Response/AKA-Identity packet, or, if AT_IDENTITY
was not used, the identity from the EAP-Response/Identity packet.

The optional user input values (XSEED_j) in EAP-Response/AKA-
Synchronization-Failure. Step 3.1 are set to
zero.

The value field of this attribute
contains 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 AKA AUTS parameter, 112 bits (14 bytes).

8.6. EAP-Request/AKA-Identity following order: K_encr (128 bits), K_aut (128 bits),
EAP application specific keys. The format number of pseudo-random number
generator iterations (m) depends on the EAP-Request/AKA-Identity packet is shown below.

On re-authentication, the same pseudo-random number generator can be
used to generate new application specific keys. The seed value XKEY�
is calculated as follows:

In the formula above, the Identity denotes the re-authentication
user 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 re-authentication, the
identity string from the EAP-Response/Identity packet. The counter
denotes the counter value from AT_COUNTER attribute used in the EAP-

Arkko and Haverinen Expires in six months [Page 25] 43]

EAP AKA Authentication June October 2002

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_PERM..._REQ | Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Response/AKA-Reauthentication packet. The semantics of counter is used in network
byte order. NONCE_S denotes the fields 16-byte NONCE_S value from the
AT_NONCE_S attribute used in the EAP-Request/AKA-Reauthentication
packet. The original XKEY is described below:

Code

1 for Request

Identifier

See [6]

Length the XKEY value from the preceding full
authentication. The length of 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 suitable-sized
chunks and used as new application specific keys.

For example, the EAP Request packet.

Type

TBD

Subtype

5 application specific material can be used for AKA-Identity

Reserved

Set to zero on sending, ignored
packet security between the client and the authenticator. Because
the required keying material depends on reception.

AT_PERMANENT_IDENTITY_REQ the EAP application and the
EAP key derivation standardization has not been finalized yet, rules
of key derivation cannot be given here. ). However, please see Annex
A for a specification of how keys for IEEE 802.11 are derived.

13. Interoperability with GSM

The AT_PERMANENT_IDENTITY_REQ attribute EAP AKA protocol is optional able to authenticate both UMTS and it GSM
users, if the subscriber's operator's network is
included in UMTS aware. This is
because the cases defined in Section 5. It MUST NOT home network will be
included if AT_IDENTITY_REQ is included. The value field only
contains two reserved bytes, which are set able to zero on sending and
ignored on reception.

AT_IDENTITY_REQ

The AT_IDENTITY_REQ attribute determine from the
subscriber records whether the subscriber is optional equipped with a UMTS
USIM or a GSM SIM. A UMTS aware home network will hence always use
UMTS AKA with UMTS subscribers and it GSM authentication with GSM
subscribers. With GSM subscribers, the EAP AKA protocol is included always
used in the cases defined in Section 4. GSM compatible mode.

It MUST NOT be included if
AT_PERMANENT_IDENTITY_REQ is included. The value field only
contains two reserved bytes, which are set not possible to zero on sending and
ignored on reception.

8.7. EAP-Response/AKA-Identity

The format of use a GSM AuC to authenticate UMTS
subscribers. (Note that if the EAP-Response/AKA-Identity packet home network doesn't support an
authentication method it should not distribute SIMs for that
method.)

However, it is shown below.

Arkko and Haverinen Expires in six months [Page 26]

EAP AKA Authentication June 2002

The semantics of possible that the fields is described below:

Code

2 for Response

Identifier

See [6]

Length

The length of node actually terminating EAP and
the node that stores the authentication keys (AuC) are separate, and
support different authentication types. If the node terminating EAP Response packet.

Type

TBD

Subtype

5 for AKA-Identity

Reserved

Set to zero on sending, ignored on reception.

AT_PERMANENT_IDENTITY

This attribute
is optional and it GSM-only but AuC is included in EAP-
Response/AKA-Identity in cases specified in UMTS-aware, then authentication can still be
achieved using the GSM compatible version of EAP AKA. This
authentication will be weaker, since the GSM compatible mode does
not provide for mutual authentication. Section 5. It MUST
NOT 6.8.1.1 in [1]
specifies how the GSM SRES parameter and the Kc key can be included if AT_IDENTITY is included. The value field
calculated on the USIM and the AuC. If a UMTS terminal does not want
to accept the GSM compatible version of this attribute begins with 2-byte actual identity length, protocol, then it can
reject GSM authentication by silently ignoring the GSM mode EAP-
Request/AKA-Challenge packet.

In conclusion, the following table shows which variant of the EAP
AKA protocol should be run under different conditions:

SIM EAP node AuC EAP AKA mode
----------------------------------------------------
GSM (any) (any) GSM
UMTS (any) GSM (illegal)
UMTS GSM GSM+UMTS GSM
UMTS GSM+UMTS GSM+UMTS UMTS

Arkko and Haverinen Expires in six months [Page 27] 44]

EAP AKA Authentication June October 2002

specifies the length of the identity in bytes. This field is
followed by

14. IANA and Protocol Numbering Considerations

The realm name "owlan.org" has been reserved for NAI realm names
generated from the non-pseudonym permanent Network Access Identifier
username portion of IMSI.

IANA has assigned the indicated actual length. number 23 for EAP AKA authentication.

EAP AKA messages include a Subtype field. The EAP/AKA
username format is specified in Section 8.1. following Subtypes are
specified:

AKA-Challenge...................................1
AKA-Authentication-Reject.......................2
AKA-Synchronization-Failure.....................4
AKA-Identity....................................5
AKA-Reauthentication...........................13

The username does
not include any terminating null characters. Because the length Subtype-specific data is composed of the attributes, which have
attribute must be a multiple of 4 bytes, the sender pads
the identity with zero bytes when necessary.

AT_IDENTITY type numbers. The AT_IDENTITY following attribute is optional and it is included in cases
defined in Section 4. It MUST NOT be included if
AT_PERMANENT_IDENTITY is included. The types are specified:

AT_RAND.........................................1
AT_AUTN.........................................2
AT_RES..........................................3
AT_AUTS.........................................4
AT_PADDING......................................6
AT_PERMANENT_ID_REQ............................10
AT_MAC.........................................11
AT_ANY_ID_REQ..................................13
AT_IDENTITY....................................14
AT_FULLAUTH_ID_REQ.............................17
AT_COUNTER.....................................19
AT_COUNTER_TOO_SMALL...........................20
AT_NONCE_S.....................................21

AT_IV.........................................129
AT_ENCR_DATA..................................130
AT_NEXT_PSEUDONYM.............................132
AT_NEXT_REAUTH_ID.............................133

All requests for value field of this
attribute begins with 2-byte actual identity length, which
specifies the length of assignment from the identity various number spaces
described in bytes. This field is
followed by the Network Access Identifier username portion of this document require proper documentation, according
to the
indicated actual length. The username format is "Specification Required" policy described in [15]. Requests
must be specified in
Section 8.1. The username sufficient detail so that interoperability
between independent implementations is either the non-pseudonym permanent
username or a pseudonym username. The username does not include
any terminating null characters. Because the length possible. Possible forms of
documentation include, but are not limited to, RFCs, the
attribute must be a multiple products of 4 bytes, the sender pads
another standards body (e.g. 3GPP), or permanently and readily
available vendor design notes.

15. Security Considerations

Implementations running the
identity with zero bytes when necessary.

9. Key Derivation

This section specifies how EAP AKA keying material is derived from protocol will rely on the IK and CK keys. Because IK
security of the AKA scheme, and CK are not available in the GSM
mode, this key derivation specification can only be applied secrecy of the symmetric keys
stored in the
UMTS AKA mode. USIM and the AuC.

Arkko and Haverinen Expires in six months [Page 45]

EAP AKA requires two keys for its own purposes, an integrity
protection key K_int Authentication October 2002

16. Intellectual Property Right Notices

On IPR related issues, Nokia and an encryption key K_encr, Ericsson refer to be used with the AT_MAC their
respective statements on patent licensing. Please see
http://www.ietf.org/ietf/IPR/NOKIA and AT_ENCR_DATA attributes. In addition, it is possible
to derive additional key material, such as a master key
http://www.ietf.org/ietf/IPR/ERICSSON-General

Acknowledgements and Contributions

The authors wish to be used
with IEEE 802.11i.

Key derivation is based on the random number generation specified 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
and Olivier Paridaens of Alcatel for interesting discussions in
NIST Federal Information Processing Standards Publication 186-2
[15]. this
problem space.

The random number generator is specified in the change notice
1 (2001 October 5)of [15] (Algorithm 1). As specified in the change
notice (page 74), when Algorithm 1 is used as a general-purpose
random number generator, the "mod q" term in step 3.3 identiy privacy support is omitted.
The function G used in based on the algorithm is constructed via Secure Hash
Standard as specified in Appendix 3.3 identity privacy support
of the standard.

160-bit XKEY and XVAL values are used, so b = 160. [8]. The initial
secret seed value XKEY attribute format is computed from the AKA integrity key IK and
cipher key CK with based on the following formula:

XKEY = SHA1(IK|CK)

The notation IK|CK denotes IK concatenated with CK.

The optional user input values (XSEED_j) are set to zero. extension format of
Mobile IPv4 [16].

Authors' Addresses

Jari Arkko
Ericsson
02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com

Henry Haverinen
Nokia Mobile Phones
P.O. Box 88
33721 Tampere Phone: +358 50 594 4899
Finland E-mail: henry.haverinen@nokia.com

Arkko and Haverinen Expires in six months [Page 28] 46]

EAP AKA Authentication June October 2002

The resulting 160-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_int (128 bits),
EAP application specific keys. The number of random number generator
iterations (m) depends on the amount of required keying material.

Even if K_encr or K_int were not used in the particular
authentication sequence, they are derived and the EAP application
specific material begins after K_int.

For example, the EAP application specific material can be used

Annex A. Key Derivation for
packet security between the client and the authenticator. Because
the required keying material depends on the EAP application and the
EAP key derivation standardization has not been finalized yet, exact
rules of key derivation cannot be given here. IEEE 802.11

As a guideline, the
EAP specified in Section 12, application specific keys resulting from the key expansion
scheme is used in the following order:

any master session keys required,
any encryption keys required,
any integrity protection keys required,
any initialization vectors required

If separate keys or IV's are required for each direction, then the
downlink material (to protect traffic to user) is taken before the
uplink keying material (to protect traffic from user).

10. Interoperability can
be derived with GSM the pseudo-random function.

The key hierarchy in IEEE 802.11i currently assumes that EAP AKA protocol methods
produce a 256-bit Pairwise Master Key (PMK). When a Pairwise Master
Key is able to authenticate both UMTS and GSM
users, if the subscriber's operator's network required, it is UMTS aware. This the first EAP application specific key that
is
because derived. On full authentication, the home network will be able to determine PMK immediately follows
K_aut in the key stream resulting from the
subscriber records whether key expansion scheme. On
re-authentication, the subscriber PMK is equipped with a UMTS
USIM or a GSM SIM. A UMTS aware home network will hence always use
UMTS AKA with UMTS subscribers and GSM authentication with GSM
subscribers. With GSM subscribers, the EAP AKA protocol first new application specific key
that is always
used in derived.

For pre 802.11i networks, the GSM compatible mode.

It is not possible to use a GSM AuC signature key used to authenticate UMTS
subscribers. (Note that if the home network doesn't support an
authentication method it should not distribute SIMs for that
method.)

However, it is possible that the node actually terminating EAP and
the node that stores the authentication
broadcast keys (AuC) are separate, and
support different authentication types. If the node terminating EAP
is GSM-only but AuC in IEEE 802.1x is UMTS-aware, then authentication can still be
achieved using selected as the GSM compatible version first 256 bits of
the EAP AKA. This
authentication will be weaker, since application specific keys immediately after K_aut. (On re-
authentication, the GSM compatible mode does
not provide for mutual authentication. Section 6.8.1.1 in [1]
specifies how first 256 application specific key bits are used
as the GSM SRES parameter and signature key.) The next 256 bits are used as the Kc WEP
session key. The full 256-bit key can is not usually used during WEP
encryption, unused bits at then end should be
calculated on ignored by the USIM and
implementation. When the AuC. If a UMTS terminal does not want keys are transmitted from the authenticator
to accept the GSM compatible version of this protocol, then it can access point using the RADIUS protocol the session key is
placed in an MS-MPPE-RECV-KEY attribute and the signature key is
placed in an MS-MPPE-SEND-KEY attribute. These attributes are
defined in RFC 2548.

Arkko and Haverinen Expires in six months [Page 29] 47]

EAP AKA Authentication June October 2002

reject the authentication with the EAP-Response/AKA-GSM-
Authentication-Reject packet.

In conclusion, the following table shows which variant of the EAP
AKA protocol should be run under different conditions:

SIM EAP node AuC EAP AKA mode
----------------------------------------------------
GSM (any) (any) GSM
UMTS (any) GSM (illegal)
UMTS GSM GSM+UMTS GSM
UMTS GSM+UMTS GSM+UMTS UMTS

11. IANA and Protocol Numbering Considerations

Annex B. Pseudo-Random Number Generator

The realm name "owlan.org" has been reserved for NAI realm names
generated from the IMSI.

IANA has assigned the number 23 for EAP AKA authentication.

EAP AKA messages include "|" character denotes concatenation, and "^" denotes involution.

Step 1: Choose a Subtype field. The following Subtypes are
specified:

AKA-Challenge...................................1
AKA-Authentication-Reject.......................2
AKA-Synchronization-Failure.....................4
AKA-Identity....................................5

The Subtype-specific data is composed of attributes, which have
attribute type numbers. The following attribute types are specified:

AT_IV.........................................129
AT_ENCR_DATA..................................130
AT_MAC........................................131
AT_PSEUDONYM..................................132

All requests for new, secret value assignment from for the various number spaces
described in this document require proper documentation, according
to seed-key, XKEY

Step 2: In hexadecimal notation let
t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
This is the "Specification Required" policy described in [16]. Requests
must be specified initial value for H0|H1|H2|H3|H4
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 FIPS SHS [12]

Step 3: For j = 0 to m � 1 do
3.1 XSEED_j = 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 and Haverinen Expires in six months [Page 30] 48]

EAP AKA Authentication June October 2002

another standards body (e.g. 3GPP), or permanently and readily
available vendor design notes.

12. Security Considerations

Implementations running the EAP AKA protocol will rely on the
security of the AKA scheme, and the secrecy of the symmetric keys
stored in the USIM and the AuC.

13. Intellectual Property Right Notices

On IPR related issues, Nokia and Ericsson refer to the their
respective statements on patent licensing. Please see
http://www.ietf.org/ietf/IPR/NOKIA and
http://www.ietf.org/ietf/IPR/ERICSSON-General

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
and Olivier Paridaens of Alcatel for interesting discussions in this
problem space.

The identiy privacy support is based on the identity privacy support
of [8]. The attribute format is based on the extension format of
Mobile IPv4 [17].

Authors' Addresses

Jari Arkko
Ericsson
02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com

Henry Haverinen
Nokia Mobile Phones
P.O. Box 88
33721 Tampere Phone: +358 50 594 4899
Finland E-mail: henry.haverinen@nokia.com

References

[1] 3GPP Technical Specification 3GPP TS 33.102 V3.6.0: "Technical
Specification Group Services and System Aspects; 3G Security;
Security Architecture (Release 1999)", 3rd Generation
Partnership Project, November 2000. (NORMATIVE)

[2] GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital
cellular telecommunication system (Phase 2); Security related
network functions", European Telecommunications Standards,
Institute, August 1997. (NORMATIVE)

Arkko and Haverinen Expires in six months [Page 31]

EAP AKA Authentication June 2002

[3] IEEE P802.1X/D11, "Standards for Local Area and Metropolitan
Area Networks: Standard for Port Based Network Access
Control", March 2001. (INFORMATIVE)

[4] IEEE Draft 802.11eS/D1, "Draft Supplement to STANDARD FOR
Telecommunications and Information Exchange between Systems -
LAN/MAN Specific Requirements - Part 11: Wireless Medium
Access Control (MAC) and physical layer (PHY) specifications:
Specification for Enhanced Security", March 2001.
(INFORMATIVE)

[5] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999. (NORMATIVE)

[6] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998. (NORMATIVE)

[7] S. Bradner, "Key words for use in RFCs to indicate Requirement
Levels", RFC 2119, March 1997. (NORMATIVE)

[8] J. Carlson, B. Aboba, H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt,
July 2001 (work-in-progress). (INFORMATIVE)

[9] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC2104, February 1997. (NORMATIVE)

[10] Federal Information Processing Standard (FIPS) draft standard,
"Advanced Encryption Standard (AES)",
http://csrc.nist.gov/publications/drafts/dfips-AES.pdf,
September 2001. (NORMATIVE)

[11] US National Bureau of Standards, "DES Modes of Operation",
Federal Information Processing Standard (FIPS) Publication 81,
December 1980. (NORMATIVE)

[12] Federal Information Processing Standard (FIPS) Publication
180-1, "Secure Hash Standard," National Institute of Standards
and Technology, U.S. Department of Commerce, April 17, 1995.
(NORMATIVE)

[13] GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital
cellular telecommunication system (Phase 2); Numbering,

Arkko and Haverinen Expires in six months [Page 49]

EAP AKA Authentication October 2002

addressing and identification", European Telecommunications
Standards Institute, April 1997. (NORMATIVE)

[14]

[13] 3GPP Technical Specification 3GPP TS 33.105 V3.5.0: "Technical
Specification Group Services and System Aspects; 3G Security;
Cryptographic Algorithm Requirements (Release 1999)",
3rdGeneration Partnership Project, October 2000 (NORMATIVE)

Arkko and Haverinen Expires in six months [Page 32]

EAP AKA Authentication June 2002

[15]

[14] Federal Information Processing Standards (FIPS) Publication
186-2 (with change notice), "Digital Signature Standard
(DSS)", National Institute of Standards and Technology,
January 27, 2000, (NORMATIVE)
Available on-line at:
http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf

[16]

[15] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
(NORMATIVE)

[17]

[16] C. Perkins (editor), "IP Mobility Support", RFC 2002, October
1996. (INFORMATIVE)

Arkko and Haverinen Expires in six months [Page 33] 50]

----