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

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

   message it sends to the authenticator.  The peer has derived the same
   keying material, so the authenticator does not forward the keying
   material to the peer along with EAP-Success.






























Arkko & Haverinen        Expires June 21, 2005                 [Page 11]

Internet-Draft           EAP-AKA Authentication            December 2004


       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

   Figure 2 shows how the EAP server rejects the Peer due to a failed
   authentication.


















Arkko & Haverinen        Expires June 21, 2005                 [Page 12]

Internet-Draft           EAP-AKA Authentication            December 2004


       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 incorrct.          |
          |              +------------------------------------------+
          |                      EAP-Request/AKA-Notification     |
          |<------------------------------------------------------|
          | EAP-Response/AKA-Notification                         |
          |------------------------------------------------------>|
          |                                          EAP-Failure  |
          |<------------------------------------------------------|

                  Figure 2: Peer authentication fails

   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 as AKA in general produces in UMTS or
   cdma2000.









Arkko & Haverinen        Expires June 21, 2005                 [Page 13]

Internet-Draft           EAP-AKA Authentication            December 2004


        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 it is possible for the
   sequence numbers to get out of sequence.  Figure 4 shows what happens
   then.





















Arkko & Haverinen        Expires June 21, 2005                 [Page 14]

Internet-Draft           EAP-AKA Authentication            December 2004


        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.

4.  Operation

4.1  Identity Management





Arkko & Haverinen        Expires June 21, 2005                 [Page 15]

Internet-Draft           EAP-AKA Authentication            December 2004


4.1.1  Format, Generation and Usage of Peer Identities

4.1.1.1  General

   In the beginning of EAP authentication, the Authenticator or the EAP
   server usually issues the EAP-Request/Identity packet to the peer.
   The peer responds with EAP-Response/Identity, which contains the
   user's identity.  The formats of these packets are specified in
   [RFC3748].

   Subscribers of mobile networks are identified with the International
   Mobile Subscriber Identity (IMSI) [TS 23.003].  The IMSI is a string
   of not more than 15 digits.  It is composed of a three digit Mobile
   Country Code (MCC), a two or three digit Mobile Network Code (MNC)
   and a not more than 10 digit Mobile Subscriber Identification Number
   (MSIN).  MCC and MNC uniquely identify the GSM operator and help
   identify the AuC from which the authentication vectors need to be
   retrieved for this subscriber.

   Internet AAA protocols identify users with the Network Access
   Identifier (NAI) [RFC2486].  When used in a roaming environment, the
   NAI is composed of a username and a realm, separated with "@"
   (username@realm).  The username portion identifies the subscriber
   within the realm.

   This section specifies the peer identity format used in EAP-AKA.  In
   this document, the term identity or peer identity refers to the whole
   identity string that is used to identify the peer.  The peer identity