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

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

   may include a realm portion.  "Username" refers to the portion of the
   peer identity that identifies the user, i.e.  the username does not
   include the realm portion.

4.1.1.2  Identity Privacy Support

   EAP-AKA includes optional identity privacy (anonymity) support that
   can be used to hide the cleartext permanent identity and thereby to
   make the subscriber's EAP exchanges untraceable to eavesdroppers.
   Because the permanent identity never changes, revealing it would help
   observers to track the user.  The permanent identity is usually based
   on the IMSI, which may further help the tracking, because the same
   identifier may be used in other contexts as well.  Identity privacy
   is based on temporary identities, or pseudonyms, which are equivalent
   to but separate from the Temporary Mobile Subscriber Identities
   (TMSI) that are used on cellular networks.  Please see Section 11.1
   for security considerations regarding identity privacy.






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


4.1.1.3  Username Types in EAP-AKA Identities

   There are three types of usernames in EAP-AKA peer identities:

   (1) Permanent usernames.  For example,
   [e-mail] might be a valid permanent identity.
   In this example, 0123456789098765 is the permanent username.

   (2) Pseudonym usernames.  For example, [e-mail] might
   be a valid pseudonym identity.  In this example, 2s7ah6n9q is the
   pseudonym username.

   (3) Fast re-authentication usernames.  For example,
   [e-mail] might be a valid fast re-authentication
   identity.  In this case, 43953754 is the fast re-authentication
   username.  Unlike permanent usernames and pseudonym usernames, fast
   re-authentication usernames are one-time identifiers, which are not
   re-used across EAP exchanges.

   The first two types of identities are only used on full
   authentication and the last one only on fast re-authentication.  When
   the optional identity privacy support is not used, the non-pseudonym
   permanent identity is used on full authentication.  The fast
   re-authentication exchange is specified in Section 5.

4.1.1.4  Username Decoration

   In some environments, the peer may need to decorate the identity by
   prepending or appending the username with a string, in order to
   indicate supplementary AAA routing information in addition to the NAI
   realm.  (The usage of a NAI realm portion is not considered to be
   decoration.) Username decoration is out of the scope of this
   document.  However, it should be noted that username decoration might
   prevent the server from recognizing a valid username.  Hence,
   although the peer MAY use username decoration in the identities the
   peer includes in EAP-Response/Identity, and the EAP server MAY accept
   a decorated peer username in this message, the peer or the EAP server
   MUST NOT decorate any other peer identities that are used in various
   EAP-AKA attributes.  Only the identity used in EAP-Response/Identity
   may be decorated.

4.1.1.5  NAI Realm Portion

   The peer MAY include a realm portion in the peer identity, as per the
   NAI format.  The use of a realm portion is not mandatory.

   If a realm is used, the realm MAY be chosen by the subscriber's home
   operator and it MAY a configurable parameter in the EAP-AKA peer



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


   implementation.  In this case, the peer is typically configured with
   the NAI realm of the home operator.  Operators MAY reserve a specific
   realm name for EAP-AKA users.  This convention makes it easy to
   recognize that the NAI identifies an AKA subscriber.  Such reserved
   NAI realm may be useful as a hint as to the first authentication
   method to use during method negotiation.  When the peer is using a
   pseudonym username instead of the permanent username, the peer
   selects the realm name portion similarly as it select the realm
   portion when using the permanent username.

   If no configured realm name is available, the peer MAY derive the
   realm name from the MCC and MNC portions of the IMSI.  A RECOMMENDED
   way to derive the realm from the IMSI using the realm 3gppnetwork.org
   will be specified in [Draft 3GPP TS 23.003].

   Some old implementations derive the realm name from the IMSI by
   concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
   of IMSI and ".owlan.org".  For example, if the IMSI is
   123456789098765, and the MNC is three digits long, then the derived
   realm name is "mnc456.mcc123.owlan.org".  As there are no DNS servers
   running at owlan.org, these realm names can only be used with
   manually configured AAA routing.  New implementations SHOULD use the
   mechanism specified in [Draft 3GPP TS 23.003] instead of owlan.org as
   soon as the 3GPP specification is finalized.

   The IMSI is a string of digits without any explicit structure, so the
   peer may not be able to determine the length of the MNC portion.  If
   the peer is not able to determine whether the MNC is two or three
   digits long, the peer MAY use a 3-digit MNC.  If the correct length
   of the MNC is two, then the MNC used in the realm name includes the
   first digit of MSIN.  Hence, when configuring AAA networks for
   operators that have 2-digit MNC's, the network SHOULD also be
   prepared for realm names with incorrect 3-digit MNC's.

4.1.1.6  Format of the Permanent Username

   The non-pseudonym permanent username SHOULD be derived from the IMSI.
   In this case, the permanent username MUST be of the format "0" |
   IMSI, where the character "|" denotes concatenation.  In other words,
   the first character of the username is the digit zero (ASCII value 30
   hexadecimal), followed by the IMSI.  The IMSI is an ASCII string that
   consists of not more than 15 decimal digits (ASCII values between 30
   and 39 hexadecimal), one character per IMSI digit, in the order as
   specified in [TS 23.003].  For example, a permanent username derived
   from the IMSI 295023820005424 would be encoded as the ASCII string
   "0295023820005424"  (byte values in hexadecimal notation: 30 32 39 35
   30 32 33 38 32 30 30 30 35 34 32 34)




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


   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".

   Alternatively, an implementation MAY choose a permanent username that
   is not based on the IMSI.  In this case the selection of the
   username, its format, and its processing is out of the scope of this
   document.  In this case, the peer implementation MUST NOT prepend any
   leading characters to the username.

4.1.1.7  Generating Pseudonyms and Fast Re-authentication Identities by
        the Server

   Pseudonym usernames and fast re-authentication identities are
   generated by the EAP server.  The EAP server produces pseudonym
   usernames and fast re-authentication identities in an
   implementation-dependent manner.  Only the EAP server needs to be
   able to map the pseudonym username to the permanent identity, or to
   recognize a fast re-authentication identity.

   EAP-AKA includes no provisions to ensure that the same EAP server
   that generated a pseudonym username will be used on the
   authentication exchange when the pseudonym username is used.  It is
   recommended that the EAP servers implement some centralized mechanism
   to allow all EAP servers of the home operator to map pseudonyms
   generated by other severs to the permanent identity.  If no such
   mechanism is available, then the EAP server failing to understand a
   pseudonym issued by another server can request the peer to send the
   permanent identity.

   When issuing a fast re-authentication identity, the EAP server may
   include a realm name in the identity to make the fast
   re-authentication request be forwarded to the same EAP server.

   When generating fast re-authentication identities, the server SHOULD
   choose a fresh new fast re-authentication identity that is different
   from the previous ones used after the same full authentication
   exchange.  A full authentication exchange and the associated fast
   re-authentication exchanges are referred to here as the same "full
   authentication context".  The fast re-authentication identity SHOULD
   include a random component.  The random component works as a full
   authentication context identifier.  A context-specific fast
   re-authentication identity can help the server to detect whether its
   fast re-authentication state information matches the peer's fast
   re-authentication state information (in other words whether the state
   information is from the same full authentication exchange).  The
   random component also makes the fast re-authentication identities



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


   unpredictable, so an attacker cannot initiate a fast
   re-authentication exchange to get the server's
   EAP-Request/AKA-Reauthentication packet.

   Transmitting pseudonyms and fast re-authentication identities from
   the server to the peer is discussed in Section 4.1.1.8.  The
   pseudonym is transmitted as a username, without an NAI realm, and the
   fast re-authentication identity is transmitted as a complete NAI,
   including a realm portion if a realm is required.  The realm is
   included in the fast re-authentication identity in order to allow the
   server to include a server-specific realm.

   Regardless of construction method, the pseudonym username MUST
   conform to the grammar specified for the username portion of an NAI.
   The fast re-authentication identity also MUST conform to the NAI
   grammar.  The EAP servers that the subscribers of an operator can use
   MUST ensure that the pseudonym usernames and the username portions
   used in fast re-authentication identities they generate are unique.

   In any case, it is necessary that permanent usernames, pseudonym
   usernames and fast re-authentication usernames are separate and
   recognizable from each other.  It is also desirable that EAP-SIM and
   EAP-AKA user names be recognizable from each other as an aid for the
   server to which method to offer.

   In general, it is the task of the EAP server and the policies of its
   administrator to ensure sufficient separation in the usernames.
   Pseudonym usernames and fast re-authentication usernames are both
   produced and used by the EAP server.  The EAP server MUST compose
   pseudonym usernames and fast re-authentication usernames so that it
   can recognize if a NAI username is an EAP-AKA pseudonym username or
   an EAP-AKA fast re-authentication username.  For instance, when the
   usernames have been derived from the IMSI, the server could use
   different leading characters in the pseudonym usernames and fast
   re-authentication usernames (e.g.  the pseudonym could begin with a
   leading "2" character).  When mapping a fast re-authentication
   identity to a permanent identity, the server SHOULD only examine the
   username portion of the fast re-authentication identity and ignore
   the realm portion of the identity.

   Because the peer may fail to save a pseudonym username sent to in an
   EAP-Request/AKA-Challenge, for example due to malfunction, the EAP
   server SHOULD maintain at least the most recently used pseudonym
   username in addition to the most recently issued pseudonym username.
   If the authentication exchange is not completed successfully, then
   the server SHOULD NOT overwrite the pseudonym username that was
   issued during the most recent successful authentication exchange.




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


4.1.1.8  Transmitting Pseudonyms and Fast Re-authentication Identities
        to the Peer

   The server transmits pseudonym usernames and fast re-authentication
   identities to the peer in cipher, using the AT_ENCR_DATA attribute.

   The EAP-Request/AKA-Challenge message MAY include an encrypted
   pseudonym username and/or an encrypted fast re-authentication
   identity in the value field of the AT_ENCR_DATA attribute.  Because
   identity privacy support and fast re-authentication are optional to
   implement, the peer MAY ignore the AT_ENCR_DATA attribute and always
   use the permanent identity.  On fast re-authentication (discussed in
   Section 5), the server MAY include a new encrypted fast
   re-authentication identity in the EAP-Request/AKA-Reauthentication
   message.

   On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the
   encrypted data in AT_ENCR_DATA and if a pseudonym username is
   included, the peer may use the obtained pseudonym username on the
   next full authentication.  If a fast re-authentication identity is
   included, then the peer MAY save it together with other fast
   re-authentication state information, as discussed in Section 5, for
   the next fast re-authentication.

   If the peer does not receive a new pseudonym username in the EAP-
   Request/AKA-Challenge message, the peer MAY use an old pseudonym
   username instead of the permanent username on next full
   authentication.  The username portions of fast re-authentication
   identities are one-time usernames, which the peer MUST NOT re-use.
   When the peer uses a fast re-authentication identity in an EAP
   exchange, the peer MUST discard the fast re-authentication identity
   and not re-use it in another EAP authentication exchange, even if the
   authentication exchange was not completed.

4.1.1.9  Usage of the Pseudonym by the Peer

   When the optional identity privacy support is used on full
   authentication, the peer MAY use a pseudonym username received as