tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4187

 Errata 
Informational
Pages: 79
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-eap

Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)

Part 1 of 4, p. 1 to 14
None       Next RFC Part

Updated by:    5448


Top       ToC       Page 1 
Network Working Group                                           J. Arkko
Request for Comments: 4187                                      Ericsson
Category: Informational                                     H. Haverinen
                                                                   Nokia
                                                            January 2006


      Extensible Authentication Protocol Method for 3rd Generation
               Authentication and Key Agreement (EAP-AKA)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

IESG Note

   The EAP-AKA protocol was developed by 3GPP.  The documentation of
   EAP-AKA is provided as information to the Internet community.  While
   the EAP WG has verified that EAP-AKA is compatible with EAP as
   defined in RFC 3748, no other review has been done, including
   validation of the security claims.  The IETF has also not reviewed
   the security of the underlying UMTS AKA algorithms.

Abstract

   This document specifies an Extensible Authentication Protocol (EAP)
   mechanism for authentication and session key distribution that uses
   the Authentication and Key Agreement (AKA) mechanism.  AKA is used in
   the 3rd generation mobile networks Universal Mobile
   Telecommunications System (UMTS) and CDMA2000.  AKA is based on
   symmetric keys, and typically runs in a Subscriber Identity Module,
   which is a UMTS Subscriber Identity Module, USIM, or a (Removable)
   User Identity Module, (R)UIM, similar to a smart card.

   EAP-AKA includes optional identity privacy support, optional result
   indications, and an optional fast re-authentication procedure.

Top       Page 2 
Table of Contents

   1. Introduction and Motivation .....................................4
   2. Terms and Conventions Used in This Document .....................5
   3. Protocol Overview ...............................................9
   4. Operation ......................................................15
      4.1. Identity Management .......................................15
           4.1.1. Format, Generation, and Usage of Peer Identities ...15
           4.1.2. Communicating the Peer Identity to the Server ......21
           4.1.3. Choice of Identity for the EAP-Response/Identity ...23
           4.1.4. Server Operation in the Beginning of
                  EAP-AKA Exchange ...................................23
           4.1.5. Processing of EAP-Request/AKA-Identity by
                  the Peer ...........................................24
           4.1.6. Attacks against Identity Privacy ...................25
           4.1.7. Processing of AT_IDENTITY by the Server ............26
      4.2. Message Sequence Examples (Informative) ...................27
           4.2.1. Usage of AT_ANY_ID_REQ .............................27
           4.2.2. Fall Back on Full Authentication ...................28
           4.2.3. Requesting the Permanent Identity 1 ................29
           4.2.4. Requesting the Permanent Identity 2 ................30
           4.2.5. Three EAP/AKA-Identity Round Trips .................30
   5. Fast Re-Authentication .........................................32
      5.1. General ...................................................32
      5.2. Comparison to AKA .........................................33
      5.3. Fast Re-Authentication Identity ...........................33
      5.4. Fast Re-Authentication Procedure ..........................35
      5.5. Fast Re-Authentication Procedure when Counter is
           Too Small .................................................37
   6. EAP-AKA Notifications ..........................................38
      6.1. General ...................................................38
      6.2. Result Indications ........................................39
      6.3. Error Cases ...............................................40
           6.3.1. Peer Operation .....................................41
           6.3.2. Server Operation ...................................41
           6.3.3. EAP-Failure ........................................42
           6.3.4. EAP-Success ........................................42
   7. Key Generation .................................................43
   8. Message Format and Protocol Extensibility ......................45
      8.1. Message Format ............................................45
      8.2. Protocol Extensibility ....................................47
   9. Messages .......................................................48
      9.1. EAP-Request/AKA-Identity ..................................48
      9.2. EAP-Response/AKA-Identity .................................48
      9.3. EAP-Request/AKA-Challenge .................................49
      9.4. EAP-Response/AKA-Challenge ................................49
      9.5. EAP-Response/AKA-Authentication-Reject ....................50
      9.6. EAP-Response/AKA-Synchronization-Failure ..................50

Top      ToC       Page 3 
      9.7. EAP-Request/AKA-Reauthentication ..........................50
      9.8. EAP-Response/AKA-Reauthentication .........................51
      9.9. EAP-Response/AKA-Client-Error .............................52
      9.10. EAP-Request/AKA-Notification .............................52
      9.11. EAP-Response/AKA-Notification ............................52
   10. Attributes ....................................................53
      10.1. Table of Attributes ......................................53
      10.2. AT_PERMANENT_ID_REQ ......................................54
      10.3. AT_ANY_ID_REQ ............................................54
      10.4. AT_FULLAUTH_ID_REQ .......................................54
      10.5. AT_IDENTITY ..............................................55
      10.6. AT_RAND ..................................................55
      10.7. AT_AUTN ..................................................56
      10.8. AT_RES ...................................................56
      10.9. AT_AUTS ..................................................57
      10.10. AT_NEXT_PSEUDONYM .......................................57
      10.11. AT_NEXT_REAUTH_ID .......................................58
      10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................58
      10.13. AT_CHECKCODE ............................................60
      10.14. AT_RESULT_IND ...........................................62
      10.15. AT_MAC ..................................................63
      10.16. AT_COUNTER ..............................................64
      10.17. AT_COUNTER_TOO_SMALL ....................................64
      10.18. AT_NONCE_S ..............................................65
      10.19. AT_NOTIFICATION .........................................65
      10.20. AT_CLIENT_ERROR_CODE ....................................66
   11. IANA and Protocol Numbering Considerations ....................66
   12. Security Considerations .......................................68
      12.1. Identity Protection ......................................69
      12.2. Mutual Authentication ....................................69
      12.3. Flooding the Authentication Centre .......................69
      12.4. Key Derivation ...........................................70
      12.5. Brute-Force and Dictionary Attacks .......................70
      12.6. Protection, Replay Protection, and Confidentiality .......70
      12.7. Negotiation Attacks ......................................71
      12.8. Protected Result Indications .............................72
      12.9. Man-in-the-Middle Attacks ................................72
      12.10. Generating Random Numbers ...............................73
   13. Security Claims ...............................................73
   14. Acknowledgements and Contributions ............................74
   15. References ....................................................74
      15.1. Normative References .....................................74
      15.2. Informative References ...................................76
   Appendix A.  Pseudo-Random Number Generator .......................77

Top      ToC       Page 4 
1.  Introduction and Motivation

   This document specifies an Extensible Authentication Protocol (EAP)
   mechanism for authentication and session key distribution that uses
   the 3rd generation Authentication and Key Agreement mechanism,
   specified for Universal Mobile Telecommunications System (UMTS) in
   [TS33.102] and for CDMA2000 in [S.S0055-A].  UMTS and CDMA2000 are
   global 3rd generation mobile network standards that use the same AKA
   mechanism.

   2nd generation mobile networks and 3rd generation mobile networks use
   different authentication and key agreement mechanisms.  The Global
   System for Mobile communications (GSM) is a 2nd generation mobile
   network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism
   that is based on the GSM authentication and key agreement primitives.

   AKA is based on challenge-response mechanisms and symmetric
   cryptography.  AKA typically runs in a UMTS Subscriber Identity
   Module (USIM) or a CDMA2000 (Removable) User Identity Module
   ((R)UIM).  In this document, both modules are referred to as identity
   modules.  Compared to the 2nd generation mechanisms such as GSM AKA,
   the 3rd generation AKA provides substantially longer key lengths and
   mutual authentication.

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

   o  The use of the AKA also as a secure PPP authentication method in
      devices that already contain an identity module.
   o  The use of the 3rd generation mobile network authentication
      infrastructure in the context of wireless LANs
   o  Relying on AKA and the existing infrastructure in a seamless way
      with any other technology that can use EAP.

   AKA works in the following manner:

   o  The identity module and the home environment have agreed on a
      secret key beforehand.  (The "home environment" refers to the home
      operator's authentication network infrastructure.)
   o  The actual authentication process starts by having the home
      environment produce an authentication vector, based on the secret
      key and a sequence number.  The authentication vector contains a
      random part RAND, an authenticator part AUTN used for
      authenticating the network to the identity module, an expected
      result part XRES, a 128-bit session key for integrity check IK,
      and a 128-bit session key for encryption CK.

Top      ToC       Page 5 
   o  The RAND and the AUTN are delivered to the identity module.
   o  The identity module verifies the AUTN, again based on the secret
      key and the sequence number.  If this process is successful (the
      AUTN is valid and the sequence number used to generate AUTN is
      within the correct range), the identity module produces an
      authentication result RES and sends it to the home environment.
   o  The home environment verifies the correct result from the identity
      module.  If the result is correct, IK and CK can be used to
      protect further communications between the identity module and the
      home environment.

   When verifying AUTN, the identity module may detect that the sequence
   number the network uses is not within the correct range.  In this
   case, the identity module calculates a sequence number
   synchronization parameter AUTS and sends it to the network.  AKA
   authentication may then be retried with a new authentication vector
   generated using the synchronized sequence number.

   For a specification of the AKA mechanisms and how the cryptographic
   values AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for
   UMTS and [S.S0055-A] for CDMA2000.

   In EAP-AKA, the EAP server node obtains the authentication vectors,
   compares RES and XRES, and uses CK and IK in key derivation.

   In the 3rd generation mobile networks, AKA is used for both radio
   network authentication and IP multimedia service authentication
   purposes.  Different user identities and formats are used for these;
   the radio network uses the International Mobile Subscriber Identifier
   (IMSI), whereas the IP multimedia service uses the Network Access
   Identifier (NAI) [RFC4282].

2.  Terms and Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The terms and abbreviations "authenticator", "backend authentication
   server", "EAP server", "peer", "Silently Discard", "Master Session
   Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
   are to be interpreted as described in [RFC3748].

   This document frequently uses the following terms and abbreviations.
   The AKA parameters are specified in detail in [TS33.102] for UMTS and
   [S.S0055-A] for CDMA2000.

Top      ToC       Page 6 
   AAA protocol

         Authentication, Authorization and Accounting protocol

   AKA

         Authentication and Key Agreement

   AuC

         Authentication Centre.  The mobile network element that can
         authenticate subscribers in the mobile networks.

   AUTN

         AKA parameter.  AUTN is an authentication value generated by
         the AuC, which, together with the RAND, authenticates the
         server to the peer, 128 bits.

   AUTS

         AKA parameter.  A value generated by the peer upon
         experiencing a synchronization failure, 112 bits.

   EAP

         Extensible Authentication Protocol [RFC3748]

   Fast Re-Authentication

         An EAP-AKA authentication exchange that is based on keys
         derived upon a preceding full authentication exchange.  The
         3rd Generation AKA is not used in the fast re-authentication
         procedure.

   Fast Re-Authentication Identity

         A fast re-authentication identity of the peer, including an
         NAI realm portion in environments where a realm is used.
         Used on re-authentication only.

   Fast Re-Authentication Username

         The username portion of fast re-authentication identity,
         i.e., not including any realm portions.

Top      ToC       Page 7 
   Full Authentication

         An EAP-AKA authentication exchange that is based on the
         3rd Generation AKA procedure.

   GSM

         Global System for Mobile communications.

   NAI

         Network Access Identifier [RFC4282]

   Identity Module

         Identity module is used in this document to refer to the
         part of the mobile device that contains authentication and
         key agreement primitives.  The identity module may be an
         integral part of the mobile device or it may be an application
         on a smart card distributed by a mobile operator.  USIM and
         (R)UIM are identity modules.

   Nonce

         A value that is used at most once or that is never repeated
         within the same cryptographic context.  In general, a nonce can
         be predictable (e.g., a counter) or unpredictable (e.g., a
         random value).  Because some cryptographic properties may
         depend on the randomness of the nonce, attention should be paid
         to whether a nonce is required to be random or not.  In this
         document, the term nonce is only used to denote random nonces,
         and it is not used to denote counters.

   Permanent Identity

         The permanent identity of the peer, including an NAI realm
         portion in environments where a realm is used.  The permanent
         identity is usually based on the IMSI.  Used on full
         authentication only.

   Permanent Username

         The username portion of permanent identity, i.e., not including
         any realm portions.

Top      ToC       Page 8 
   Pseudonym Identity

         A pseudonym identity of the peer, including an NAI realm
         portion in environments where a realm is used.  Used on full
         authentication only.

   Pseudonym Username

         The username portion of pseudonym identity, i.e., not including
         any realm portions.

   RAND

         An AKA parameter.  Random number generated by the AuC,
         128 bits.

   RES

         Authentication result from the peer, which, together with
         the RAND, authenticates the peer to the server,
         128 bits.

   (R)UIM

         CDMA2000 (Removable) User Identity Module.  (R)UIM is an
         application that is resident on devices such as smart cards,
         which may be fixed in the terminal or distributed by CDMA2000
         operators (when removable).

   SQN

         An AKA parameter.  Sequence number used in the authentication
         process, 48 bits.

   SIM

         Subscriber Identity Module.  The SIM is traditionally a smart
         card distributed by a GSM operator.

   SRES

         The authentication result parameter in GSM, corresponds to
         the RES parameter in 3G AKA, 32 bits.

Top      ToC       Page 9 
   UAK

         UIM Authentication Key, used in CDMA2000 AKA.  Both the
         identity module and the network can optionally generate the UAK
         during the AKA computation in CDMA2000.  UAK is not used in
         this version of EAP-AKA.

   UIM

         Please see (R)UIM.

   USIM

         UMTS Subscriber Identity Module.  USIM is an application that
         is resident on devices such as smart cards distributed by UMTS
         operators.

3.  Protocol Overview

   Figure 1 shows the basic, successful full authentication exchange in
   EAP-AKA, when optional result indications are not used.  The
   authenticator typically communicates with an EAP server that is
   located on a backend authentication server using an AAA protocol.
   The authenticator shown in the figure is often simply relaying EAP
   messages to and from the EAP server, but these backend AAA
   communications are not shown.  At the minimum, EAP-AKA uses two
   roundtrips to authenticate and authorize the peer and generate
   session keys.  As in other EAP schemes, an identity request/response
   message pair is usually exchanged first.  On full authentication, the
   peer's identity response includes either the user's International
   Mobile Subscriber Identity (IMSI), or a temporary identity
   (pseudonym) if identity privacy is in effect, as specified in
   Section 4.1.  (As specified in [RFC3748], the initial identity
   request is not required, and MAY be bypassed in cases where the
   network can presume the identity, such as when using leased lines,
   dedicated dial-ups, etc.  Please see Section 4.1.2 for specification
   of how to obtain the identity via EAP AKA messages.)

   After obtaining the subscriber identity, the EAP server obtains an
   authentication vector (RAND, AUTN, RES, CK, IK) for use in
   authenticating the subscriber.  From the vector, the EAP server
   derives the keying material, as specified in Section 6.4.  The vector
   may be obtained by contacting an Authentication Centre (AuC) on the
   mobile network; for example, per UMTS specifications, several vectors
   may be obtained at a time.  Vectors may be stored in the EAP server
   for use at a later time, but they may not be reused.

Top      ToC       Page 10 
   In CDMA2000, the vector may include a sixth value called the User
   Identity Module Authentication Key (UAK).  This key is not used in
   EAP-AKA.

   Next, the EAP server starts the actual AKA protocol by sending an
   EAP-Request/AKA-Challenge message.  EAP-AKA packets encapsulate
   parameters in attributes, encoded in a Type, Length, Value format.
   The packet format and the use of attributes are specified in
   Section 8.  The EAP-Request/AKA-Challenge message contains a RAND
   random number (AT_RAND), a network authentication token (AT_AUTN),
   and a message authentication code (AT_MAC).  The EAP-Request/
   AKA-Challenge message MAY optionally contain encrypted data, which is
   used for identity privacy and fast re-authentication support, as
   described in Section 4.1.  The AT_MAC attribute contains a message
   authentication code covering the EAP packet.  The encrypted data is
   not shown in the figures of this section.

   The peer runs the AKA algorithm (typically using an identity module)
   and verifies the AUTN.  If this is successful, the peer is talking to
   a legitimate EAP server and proceeds to send the EAP-Response/
   AKA-Challenge.  This message contains a result parameter that allows
   the EAP server, in turn, to authenticate the peer, and the AT_MAC
   attribute to integrity protect the EAP message.

   The EAP server verifies that the RES and the MAC in the EAP-Response/
   AKA-Challenge packet are correct.  Because protected success
   indications are not used in this example, the EAP server sends the
   EAP-Success packet, indicating that the authentication was
   successful.  (Protected success indications are discussed in
   Section 6.2.)  The EAP server may also include derived keying
   material in the message it sends to the authenticator.  The peer has
   derived the same keying material, so the authenticator does not
   forward the keying material to the peer along with EAP-Success.

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

              Figure 1: EAP-AKA full authentication procedure

Top      ToC       Page 12 
   Figure 2 shows how the EAP server rejects the Peer due to a failed
   authentication.

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

                    Figure 2: Peer authentication fails

Top      ToC       Page 13 
   Figure 3 shows the peer rejecting the AUTN of the EAP server.

   The peer sends an explicit error message (EAP-Response/
   AKA-Authentication-Reject) to the EAP server, as usual in AKA when
   AUTN is incorrect.  This allows the EAP server to produce the same
   error statistics that AKA generally produces in UMTS or CDMA2000.

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

                  Figure 3: Network authentication fails

   The AKA uses shared secrets between the Peer and the Peer's home
   operator, together with a sequence number, to actually perform an
   authentication.  In certain circumstances, shown in Figure 4, it is
   possible for the sequence numbers to get out of sequence.

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

                 Figure 4: Sequence number synchronization

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

   In addition to the full authentication scenarios described above,
   EAP-AKA includes a fast re-authentication procedure, which is
   specified in Section 5.  Fast re-authentication is based on keys
   derived on full authentication.  If the peer has maintained state
   information for re-authentication and wants to use fast
   re-authentication, then the peer indicates this by using a specific
   fast re-authentication identity instead of the permanent identity or
   a pseudonym identity.


Next RFC Part