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

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

   identity, received as part of the previous authentication sequence.



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


   A new fast re-authentication identity may be delivered as part of
   both full authentication and fast re-authentication.  The peer MUST
   NOT modify the username part of the fast re-authentication identity
   received in AT_NEXT_REAUTH_ID, except in cases when username
   decoration is required.  Even in these cases, the "root" fast
   re-authentication username must not be modified, but it may be
   appended or prepended with another string.

4.1.2  Communicating the Peer Identity to the Server

4.1.2.1  General

   The peer identity MAY be communicated to the server with the
   EAP-Response/Identity message.  This message MAY contain the
   permanent identity, a pseudonym identity, or a fast re-authentication
   identity.  If the peer uses the permanent identity or a pseudonym
   identity, which the server is able to map to the permanent identity,
   then the authentication proceeds as discussed in the overview of
   Section 3.  If the peer uses a fast re-authentication identity, and
   if the fast re-authentication identity matches with a valid fast
   re-authentication identity maintained by the server , then a fast
   re-authentication exchange is performed, as described in Section 5.

   The peer identity can also be transmitted from the peer to the server
   using EAP-AKA messages instead of EAP-Response/Identity.  In this
   case, the server includes an identity requesting attribute
   (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
   EAP-Request/AKA-Identity message, and the peer includes the
   AT_IDENTITY attribute, which contains the peer's identity, in the
   EAP-Response/AKA-Identity message.  The AT_ANY_ID_REQ attribute is a
   general identity requesting attribute, which the server uses if it
   does not specify which kind of an identity the peer should return in
   AT_IDENTITY.  The server uses the AT_FULLAUTH_ID_REQ attribute to
   request either the permanent identity or a pseudonym identity.  The
   server uses the AT_PERMANENT_ID_REQ attribute to request the peer to
   send its permanent identity.  The EAP-Request/AKA-Challenge,
   EAP-Response/AKA-Challenge, or the packets used on fast
   re-authentication may optionally include the AT_CHECKCODE attribute,
   which enables the protocol peers to ensure the integrity of the
   AKA-Identity packets.  AT_CHECKCODE is specified in Section 9.13.

   The identity format in the AT_IDENTITY attribute is the same as in
   the EAP-Response/Identity packet (except that identity decoration is
   not allowed).  The AT_IDENTITY attribute contains a permanent
   identity, a pseudonym identity or a fast re-authentication identity.

   Please note that the EAP-AKA peer and the EAP-AKA server only process
   the AT_IDENTITY attribute and entities that only pass through EAP



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


   packets do not process this attribute.  Hence, the authenticator and
   other intermediate AAA elements (such as possible AAA proxy servers)
   will continue to refer to the peer with the original identity from
   the EAP-Response/Identity packet unless the identity authenticated in
   the AT_IDENTITY attribute is communicated to them in another way
   within the AAA protocol.

4.1.2.2  Relying on EAP-Response/Identity Discouraged

   The EAP-Response/Identity packet is not method specific so in many
   implementations it may be handled by an EAP Framework.  This
   introduces an additional layer of processing between the EAP peer and
   EAP server.  The extra layer of processing may cache identity
   responses or add decorations to the identity.  A modification of the
   identity response will cause the EAP peer and EAP server to use
   different identities in the key derivation which will cause the
   protocol to fail.

   For this reason, it is RECOMMENDED that the EAP peer and server use
   the method specific identity attributes in EAP-AKA and the server is
   strongly discouraged from relying upon the EAP-Response/Identity.

   In particular, if the EAP server receives a decorated identity in
   EAP-Response/Identity, then the EAP server MUST use the
   identity-requesting attributes to request the peer to send an
   unmodified and undecorated copy of the identity in AT_IDENTITY.

4.1.3  Choice of Identity for the EAP-Response/Identity

   If EAP-AKA peer is started upon receiving an EAP-Request/Identity
   message, then the peer performs the following steps.

   If the peer has maintained fast re-authentication state information
   and if the peer wants to use fast re-authentication, then the peer
   transmits the fast re-authentication identity in
   EAP-Response/Identity.

   Else, if the peer has a pseudonym username available, then the peer
   transmits the pseudonym identity in EAP-Response/Identity.

   In other cases, the peer transmits the permanent identity in
   EAP-Response/Identity.

4.1.4  Server Operation in the Beginning of EAP-AKA Exchange

   If the EAP server has not received any EAP-AKA peer identity
   (permanent identity, pseudonym identity or fast re-authentication
   identity) from the peer when sending the first EAP-AKA request, or if



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


   the EAP server has received an EAP-Response/Identity packet but the
   contents do not appear to be a valid permanent identity, pseudonym
   identity or a re-authentication identity, then the server MUST
   request an identity from the peer using one of the methods below.

   The server sends the EAP-Request/AKA-Identity message with the
   AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
   peer to include the permanent identity in the AT_IDENTITY attribute
   of the EAP-Response/AKA-Identity message.  This is done in the
   following cases:

   o  The server does not support fast re-authentication or identity
      privacy.
   o  The server received an identity that it recognizes as a pseudonym
      identity but the server is not able to map the pseudonym identity
      to a permanent identity.

   The server issues the EAP-Request/AKA-Identity packet with the
   AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
   peer to include a full authentication identity (pseudonym identity or
   permanent identity) in the AT_IDENTITY attribute of the
   EAP-Response/AKA-Identity message.  This is done in the following
   cases:

   o  The server does not support fast re-authentication and the server
      supports identity privacy
   o  The server received an identity that it recognizes as a
      re-authentication identity but the server is not able to map the
      re-authentication identity to a permanent identity

   The server issues the EAP-Request/AKA-Identity packet with the
   AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
   include an identity in the AT_IDENTITY attribute of the
   EAP-Response/AKA-Identity message, and the server does not indicate
   any preferred type for the identity.  This is done in other cases,
   such as when the server does not have any identity, or the server
   does not recognize the format of a received identity.

4.1.5  Processing of EAP-Request/AKA-Identity by the Peer

   Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST
   perform the following steps.

   If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if
   the peer does not have a pseudonym available, then the peer MUST
   respond with EAP-Response/AKA-Identity and include the permanent
   identity in AT_IDENTITY.  If the peer has a pseudonym available, then
   the peer MAY refuse to send the permanent identity; hence in this



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


   case the peer MUST either respond with EAP-Response/AKA-Identity and
   include the permanent identity in AT_IDENTITY or respond with
   EAP-Response/AKA-Client-Error packet with code "unable to process
   packet".

   If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if
   the peer has a pseudonym available, then the peer SHOULD respond with
   EAP-Response/AKA-Identity and include the pseudonym identity in
   AT_IDENTITY.  If the peer does not have a pseudonym when it receives
   this message, then the peer MUST respond with
   EAP-Response/AKA-Identity and include the permanent identity in
   AT_IDENTITY.  The Peer MUST NOT use a fast re-authentication identity
   in the AT_IDENTITY attribute.

   If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the
   peer has maintained fast re-authentication state information and the
   peer wants to use fast re-authentication, then the peer responds with
   EAP- Response/AKA-Identity and includes the fast re-authentication
   identity in AT_IDENTITY.  Else, if the peer has a pseudonym identity
   available, then the peer responds with EAP-Response/AKA-Identity and
   includes the pseudonym identity in AT_IDENTITY.  Else, the peer
   responds with EAP-Response/AKA-Identity and includes the permanent
   identity in AT_IDENTITY.

   An EAP-AKA exchange may include several EAP/AKA-Identity rounds.  The
   server may issue a second EAP-Request/AKA-Identity, if it was not
   able to recognize the identity the peer used in the previous
   AT_IDENTITY attribute.  At most three EAP/AKA-Identity rounds can be
   used, so the peer MUST NOT respond to more than three
   EAP-Request/AKA-Identity messages within an EAP exchange.  The peer
   MUST verify that the sequence of EAP-Request/AKA-Identity packets the
   peer receives comply with the sequencing rules defined in this
   document.  That is, AT_ANY_ID_REQ can only be used in the first
   EAP-Request/AKA-Identity, in other words AT_ANY_ID_REQ MUST NOT be
   used in the second or third EAP-Request/AKA-Identity.
   AT_FULLAUTH_ID_REQ MUST NOT be used if the previous
   EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ.  The peer
   operation in cases when it receives an unexpected attribute or an
   unexpected message is specified in Section 6.3.1.

4.1.6  Attacks against Identity Privacy

   The section above specifies two possible ways the peer can operate
   upon receipt of AT_PERMANENT_ID_REQ.  This is because a received
   AT_PERMANENT_ID_REQ does not necessarily originate from the valid
   network, but an active attacker may transmit an
   EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
   to the peer, in an effort to find out the true identity of the user.



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


   If the peer does not want to reveal its permanent identity, then the
   peer sends the EAP-Response/AKA-Client-Error packet with the error
   code "unable to process packet", and the authentication exchange
   terminates.

   Basically, there are two different policies that the peer can employ
   with regard to AT_PERMANENT_ID_REQ.  A "conservative" peer assumes
   that the network is able to maintain pseudonyms robustly.  Therefore,
   if a conservative peer has a pseudonym username, the peer responds
   with EAP-Response/AKA-Client-Error to the EAP packet with
   AT_PERMANENT_ID_REQ, because the peer believes that the valid network
   is able to map the pseudonym identity to the peer's permanent
   identity.  (Alternatively, the conservative peer may accept
   AT_PERMANENT_ID_REQ in certain circumstances, for example if the
   pseudonym was received a long time ago.) The benefit of this policy
   is that it protects the peer against active attacks on anonymity.  On
   the other hand, a "liberal" peer always accepts the
   AT_PERMANENT_ID_REQ and responds with the permanent identity.  The
   benefit of this policy is that it works even if the valid network
   sometimes loses pseudonyms and is not able to map them to the
   permanent identity.

4.1.7  Processing of AT_IDENTITY by the Server

   When the server receives an EAP-Response/AKA-Identity message with
   the AT_IDENTITY (in response to the server's identity requesting
   attribute), the server MUST operate as follows.

   If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
   not contain a valid permanent identity, then the server sends an
   EAP-Request/AKA-Notification packet with AT_NOTIFICATION code 16384
   to terminate the EAP exchange.  If the server recognizes the
   permanent identity and is able to continue, then the server proceeds
   with full authentication by sending EAP-Request/AKA-Challenge.

   If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
   valid permanent identity or a pseudonym identity that the server can
   map to a valid permanent identity, then the server proceeds with full
   authentication by sending EAP-Request/AKA-Challenge.  If AT_IDENTITY
   contains a pseudonym identity that the server is not able to map to a
   valid permanent identity, or an identity that the server is not able
   to recognize or classify, then the server sends EAP-Request/
   AKA-Identity with AT_PERMANENT_ID_REQ.

   If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
   valid permanent identity or a pseudonym identity that the server can
   map to a valid permanent identity, then the server proceeds with full
   authentication by sending EAP-Request/ AKA-Challenge.



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


   If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
   fast re-aut