draft-arkko-pppext-eap-aka-14.txt

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,459 行 · 第 1/5 页

   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 [TS 33.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 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) [RFC2486].

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 [TS 33.102] for UMTS
   and [S.S0055-A] for cdma2000.

   AAA protocol




Arkko & Haverinen         Expires May 25, 2005                  [Page 6]

Internet-Draft           EAP-AKA Authentication            November 2004


         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,
         ie. not including any realm portions.

   Full authentication

         An EAP-AKA authentication exchange that is based on the



Arkko & Haverinen         Expires May 25, 2005                  [Page 7]

Internet-Draft           EAP-AKA Authentication            November 2004


         3rd Generation AKA procedure.

   GSM

         Global System for Mobile communications.

   NAI

         Network Access Identifier
   [RFC2486]

   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 can 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). Since 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, ie. not including
         any realm portions.

   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.



Arkko & Haverinen         Expires May 25, 2005                  [Page 8]

Internet-Draft           EAP-AKA Authentication            November 2004


   Pseudonym Username

         The username portion of pseudonym identity, ie. 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 e.g. on 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.

   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




Arkko & Haverinen         Expires May 25, 2005                  [Page 9]

Internet-Draft           EAP-AKA Authentication            November 2004


   USIM

         UMTS Subscriber Identity Module. USIM is an application that
         is resident e.g. on 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 back end 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 also Section 4.1.2 for specification 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.

   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
   7.  The EAP-Request/AKA-Challenge message contains a RAND random
   number (AT_RAND) and 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



Arkko & Haverinen         Expires May 25, 2005                 [Page 10]

Internet-Draft           EAP-AKA Authentication            November 2004


   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.