tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4187

 
 
 

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

Part 4 of 4, p. 53 to 79
Prev RFC Part

 


prevText      Top      Up      ToC       Page 53 
10.  Attributes

   This section specifies the format of message attributes.  The
   attribute type numbers are specified in Section 11.

10.1.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of messages, and in what quantity.  Messages are
   denoted with numbers in parentheses as follows: (1) EAP-Request/
   AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/
   AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/
   AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP-
   Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9)
   EAP-Response/AKA-Reauthentication, (10) EAP-Response/AKA-
   Authentication-Reject, and (11) EAP-Response/AKA-Synchronization-
   Failure.  The column denoted with "E" indicates whether the attribute
   is a nested attribute that MUST be included within AT_ENCR_DATA.

   "0" indicates that the attribute MUST NOT be included in the message,
   "1" indicates that the attribute MUST be included in the message,
   "0-1" indicates that the attribute is sometimes included in the
   message, and "0*" indicates that the attribute is not included in the
   message in cases specified in this document, but MAY be included in
   the future versions of the protocol.

              Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E
    AT_PERMANENT_ID_REQ 0-1  0   0   0   0   0   0   0   0   0   0   N
          AT_ANY_ID_REQ 0-1  0   0   0   0   0   0   0   0   0   0   N
     AT_FULLAUTH_ID_REQ 0-1  0   0   0   0   0   0   0   0   0   0   N
            AT_IDENTITY  0  0-1  0   0   0   0   0   0   0   0   0   N
                AT_RAND  0   0   1   0   0   0   0   0   0   0   0   N
                AT_AUTN  0   0   1   0   0   0   0   0   0   0   0   N
                 AT_RES  0   0   0   1   0   0   0   0   0   0   0   N
                AT_AUTS  0   0   0   0   0   0   0   0   0   0   1   N
      AT_NEXT_PSEUDONYM  0   0  0-1  0   0   0   0   0   0   0   0   Y
      AT_NEXT_REAUTH_ID  0   0  0-1  0   0   0   0  0-1  0   0   0   Y
                  AT_IV  0   0  0-1  0* 0-1 0-1  0   1   1   0   0   N
           AT_ENCR_DATA  0   0  0-1  0* 0-1 0-1  0   1   1   0   0   N
             AT_PADDING  0   0  0-1  0* 0-1 0-1  0  0-1 0-1  0   0   Y
           AT_CHECKCODE  0   0  0-1 0-1  0   0   0  0-1 0-1  0   0   N
          AT_RESULT_IND  0   0  0-1 0-1  0   0   0  0-1 0-1  0   0   N
                 AT_MAC  0   0   1   1  0-1 0-1  0   1   1   0   0   N
             AT_COUNTER  0   0   0   0  0-1 0-1  0   1   1   0   0   Y
   AT_COUNTER_TOO_SMALL  0   0   0   0   0   0   0   0  0-1  0   0   Y
             AT_NONCE_S  0   0   0   0   0   0   0   1   0   0   0   Y
        AT_NOTIFICATION  0   0   0   0   1   0   0   0   0   0   0   N
   AT_CLIENT_ERROR_CODE  0   0   0   0   0   0   1   0   0   0   0   N

Top      Up      ToC       Page 54 
   It should be noted that attributes AT_PERMANENT_ID_REQ,
   AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that
   only one of them can be included at the same time.  If one of the
   attributes AT_IV or AT_ENCR_DATA is included, then both of the
   attributes MUST be included.

10.2.  AT_PERMANENT_ID_REQ

   The format of the AT_PERMANENT_ID_REQ attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_PERM..._REQ | Length = 1    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1.  The
   value field only contains two reserved bytes, which are set to zero
   on sending and ignored on reception.

10.3.  AT_ANY_ID_REQ

   The format of the AT_ANY_ID_REQ attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_ANY_ID_REQ  | Length = 1    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_ANY_ID_REQ is defined in Section 4.1.  The value
   field only contains two reserved bytes, which are set to zero on
   sending and ignored on reception.

10.4.  AT_FULLAUTH_ID_REQ

   The format of the AT_FULLAUTH_ID_REQ attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_FULLAUTH_...| Length = 1    |           Reserved            |
   +---------------+---------------+-------------------------------+

   The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1.  The
   value field only contains two reserved bytes, which are set to zero
   on sending and ignored on reception.

Top      Up      ToC       Page 55 
10.5.  AT_IDENTITY

   The format of the AT_IDENTITY attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_IDENTITY   | Length        | Actual Identity Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                       Identity                                .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_IDENTITY is defined in Section 4.1.  The value
   field of this attribute begins with 2-byte actual identity length,
   which specifies the length of the identity in bytes.  This field is
   followed by the subscriber identity of the indicated actual length.
   The identity is the permanent identity, a pseudonym identity or a
   fast re-authentication identity.  The identity format is specified in
   Section 4.1.1.  The same identity format is used in the AT_IDENTITY
   attribute and the EAP-Response/Identity packet, with the exception
   that the peer MUST NOT decorate the identity it includes in
   AT_IDENTITY.  The identity does not include any terminating null
   characters.  Because the length of the attribute must be a multiple
   of 4 bytes, the sender pads the identity with zero bytes when
   necessary.

10.6.  AT_RAND

   The format of the AT_RAND attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    AT_RAND    | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                             RAND                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute contains two reserved bytes
   followed by the AKA RAND parameter, 16 bytes (128 bits).  The
   reserved bytes are set to zero when sending and ignored on reception.

Top      Up      ToC       Page 56 
10.7.  AT_AUTN

   The format of the AT_AUTN attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    AT_AUTN    | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        AUTN                                   |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute contains two reserved bytes
   followed by the AKA AUTN parameter, 16 bytes (128 bits).  The
   reserved bytes are set to zero when sending and ignored on reception.

10.8.  AT_RES

   The format of the AT_RES attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     AT_RES    |    Length     |          RES Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                                                               |
   |                             RES                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute begins with the 2-byte RES Length,
   which identifies the exact length of the RES in bits.  The RES length
   is followed by the AKA RES parameter.  According to [TS33.105], the
   length of the AKA RES can vary between 32 and 128 bits.  Because the
   length of the AT_RES attribute must be a multiple of 4 bytes, the
   sender pads the RES with zero bits where necessary.

Top      Up      ToC       Page 57 
10.9.  AT_AUTS

   The format of the AT_AUTS attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
   |    AT_AUTS    | Length = 4    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                             AUTS                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute contains the AKA AUTS parameter,
   112 bits (14 bytes).

10.10.  AT_NEXT_PSEUDONYM

   The format of the AT_NEXT_PSEUDONYM attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_NEXT_PSEU..| Length        | Actual Pseudonym Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                          Next Pseudonym                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute begins with a 2-byte actual
   pseudonym length, which specifies the length of the following
   pseudonym in bytes.  This field is followed by a pseudonym username
   that the peer can use in the next authentication.  The username MUST
   NOT include any realm portion.  The username does not include any
   terminating null characters.  Because the length of the attribute
   must be a multiple of 4 bytes, the sender pads the pseudonym with
   zero bytes when necessary.  The username encoding MUST follow the
   UTF-8 transformation format [RFC3629].  This attribute MUST always be
   encrypted by encapsulating it within the AT_ENCR_DATA attribute.

Top      Up      ToC       Page 58 
10.11.  AT_NEXT_REAUTH_ID

   The format of the AT_NEXT_REAUTH_ID attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_NEXT_REAU..| Length        | Actual Re-Auth Identity Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .              Next Fast Re-Authentication Username             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute begins with a 2-byte actual
   re-authentication identity length which specifies the length of the
   following fast re-authentication identity in bytes.  This field is
   followed by a fast re-authentication identity that the peer can use
   in the next fast re-authentication, as described in Section 5.  In
   environments where a realm portion is required, the fast
   re-authentication identity includes both a username portion and a
   realm name portion.  The fast re-authentication identity does not
   include any terminating null characters.  Because the length of the
   attribute must be a multiple of 4 bytes, the sender pads the fast
   re-authentication identity with zero bytes when necessary.  The
   identity encoding MUST follow the UTF-8 transformation format
   [RFC3629].  This attribute MUST always be encrypted by encapsulating
   it within the AT_ENCR_DATA attribute.

10.12.  AT_IV, AT_ENCR_DATA, and AT_PADDING

   AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
   information between the EAP-AKA peer and server.

   The value field of AT_IV contains two reserved bytes followed by a
   16-byte initialization vector required by the AT_ENCR_DATA attribute.
   The reserved bytes are set to zero when sending and ignored on
   reception.  The AT_IV attribute MUST be included if and only if the
   AT_ENCR_DATA is included.  Section 6.3 specifies the operation if a
   packet that does not meet this condition is encountered.

   The sender of the AT_IV attribute chooses the initialization vector
   at random.  The sender MUST NOT reuse the initialization vector value
   from previous EAP-AKA packets.  The sender SHOULD use a good source
   of randomness to generate the initialization vector.  Please see
   [RFC4086] for more information about generating random numbers for
   security applications.  The format of AT_IV is shown below.

Top      Up      ToC       Page 59 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     AT_IV     | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                 Initialization Vector                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of the AT_ENCR_DATA attribute consists of two
   reserved bytes followed by cipher text bytes.  The cipher text bytes
   are encrypted using the Advanced Encryption Standard (AES) [AES] with
   a 128-bit key in the Cipher Block Chaining (CBC) mode of operation,
   which uses the initialization vector from the AT_IV attribute.  The
   reserved bytes are set to zero when sending and ignored on reception.
   Please see [CBC] for a description of the CBC mode.  The format of
   the AT_ENCR_DATA attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_ENCR_DATA  | Length        |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                    Encrypted Data                             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The derivation of the encryption key (K_encr) is specified in
   Section 7.

   The plaintext consists of nested EAP-AKA attributes.

   The encryption algorithm requires the length of the plaintext to be a
   multiple of 16 bytes.  The sender may need to include the AT_PADDING
   attribute as the last attribute within AT_ENCR_DATA.  The AT_PADDING
   attribute is not included if the total length of other nested
   attributes within the AT_ENCR_DATA attribute is a multiple of 16
   bytes.  As usual, the Length of the Padding attribute includes the
   Attribute Type and Attribute Length fields.  The length of the
   Padding attribute is 4, 8, or 12 bytes.  It is chosen so that the
   length of the value field of the AT_ENCR_DATA attribute becomes a
   multiple of 16 bytes.  The actual pad bytes in the value field are
   set to zero (00 hexadecimal) on sending.  The recipient of the
   message MUST verify that the pad bytes are set to zero.  If this

Top      Up      ToC       Page 60 
   verification fails on the peer, then it MUST send the
   EAP-Response/AKA-Client-Error packet with the error code "unable to
   process packet" to terminate the authentication exchange.  If this
   verification fails on the server, then the server sends the
   EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code
   that implies failure to terminate the authentication exchange.  The
   format of the AT_PADDING attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AT_PADDING   | Length        | Padding...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10.13.  AT_CHECKCODE

   The AT_MAC attribute is not used in the very first EAP-AKA messages
   during the AKA-Identity round, because keying material has not been
   derived yet.  The peer and the server may exchange one or more pairs
   of EAP-AKA messages of the Subtype AKA-Identity before keys are
   derived and before the AT_MAC attribute can be applied.  The EAP/-
   AKA-Identity messages may also be used upon fast re-authentication.

   The AT_CHECKCODE attribute MAY be used to protect the EAP/
   AKA-Identity messages.  In full authentication, the server MAY
   include the AT_CHECKCODE in EAP-Request/AKA-Challenge, and the peer
   MAY include AT_CHECKCODE in EAP-Response/AKA-Challenge.  In fast
   re-authentication, the server MAY include AT_CHECKCODE in
   EAP-Request/ AKA-Reauthentication, and the peer MAY include
   AT_CHECKCODE in EAP-Response/AKA-Reauthentication.  The fact that the
   peer receives an EAP-Request with AT_CHECKCODE does not imply that
   the peer would have to include AT_CHECKCODE in the corresponding
   response.  The peer MAY include AT_CHECKCODE even if the server did
   not include AT_CHECKCODE in the EAP request.  Because the AT_MAC
   attribute is used in these messages, AT_CHECKCODE will be integrity
   protected with AT_MAC.  The format of the AT_CHECKCODE attribute is
   shown below.

Top      Up      ToC       Page 61 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_CHECKCODE  | Length        |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Checkcode (0 or 20 bytes)                 |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of AT_CHECKCODE begins with two reserved bytes, which
   may be followed by a 20-byte checkcode.  If the checkcode is not
   included in AT_CHECKCODE, then the attribute indicates that no EAP/-
   AKA-Identity messages were exchanged.  This may occur in both full
   authentication and fast re-authentication.  The reserved bytes are
   set to zero when sending and ignored on reception.

   The checkcode is a hash value, calculated with SHA1 [SHA-1], over all
   EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets
   exchanged in this authentication exchange.  The packets are included
   in the order that they were transmitted, that is, starting with the
   first EAP-Request/AKA-Identity message, followed by the corresponding
   EAP-Response/AKA-Identity, followed by the second
   EAP-Request/AKA-Identity (if used), etc.

   EAP packets are included in the hash calculation "as-is" (as they
   were transmitted or received).  All reserved bytes, padding bytes,
   etc., that are specified for various attributes are included as such,
   and the receiver must not reset them to zero.  No delimiter bytes,
   padding, or any other framing are included between the EAP packets
   when calculating the checkcode.

   Messages are included in request/response pairs; in other words, only
   full "round trips" are included.  Packets that are silently discarded
   are not included, and retransmitted packets (that have the same
   Identifier value) are only included once.  (The base EAP protocol
   [RFC3748] ensures that requests and responses "match".)  The EAP
   server must only include an EAP-Request/AKA-Identity in the
   calculation after it has received a corresponding response with the
   same Identifier value.

   The peer must include the EAP-Request/AKA-Identity and the
   corresponding response in the calculation only if the peer receives a
   subsequent EAP-Request/AKA-Challenge or a follow-up EAP-Request/
   AKA-Identity with a different Identifier value than in the first
   EAP-Request/AKA-Identity.

Top      Up      ToC       Page 62 
   The AT_CHECKCODE attribute is optional to implement.  It is specified
   in order to allow protection of the EAP/AKA-Identity messages and any
   future extensions to them.  The implementation of AT_CHECKCODE is
   RECOMMENDED.

   If the receiver of AT_CHECKCODE implements this attribute, then the
   receiver MUST check that the checkcode is correct.  If the checkcode
   is invalid, the receiver must operate as specified in Section 6.3.

   If the EAP/AKA-Identity messages are extended with new attributes,
   then AT_CHECKCODE MUST be implemented and used.  More specifically,
   if the server includes any attributes other than AT_PERMANENT_ID_REQ,
   AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity
   packet, then the server MUST include AT_CHECKCODE in EAP-Request/
   AKA-Challenge or EAP-Request/AKA-Reauthentication.  If the peer
   includes any attributes other than AT_IDENTITY in the EAP-Response/
   AKA-Identity message, then the peer MUST include AT_CHECKCODE in
   EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication.

   If the server implements the processing of any other attribute than
   AT_IDENTITY for the EAP-Response/AKA-Identity message, then the
   server MUST implement AT_CHECKCODE.  In this case, if the server
   receives any attribute other than AT_IDENTITY in the
   EAP-Response/AKA-Identity message, then the server MUST check that
   AT_CHECKCODE is present in EAP-Response/AKA-Challenge or
   EAP-Response/ AKA-Reauthentication.  The operation when a mandatory
   attribute is missing is specified in Section 6.3.

   Similarly, if the peer implements the processing of any attribute
   other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ
   for the EAP-Request/AKA-Identity packet, then the peer MUST implement
   AT_CHECKCODE.  In this case, if the peer receives any attribute other
   than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the
   EAP-Request/AKA-Identity packet, then the peer MUST check that
   AT_CHECKCODE is present in EAP-Request/AKA-Challenge or
   EAP-Request/AKA-Reauthentication.  The operation when a mandatory
   attribute is missing is specified in Section 6.3.

10.14.  AT_RESULT_IND

   The format of the AT_RESULT_IND attribute is shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  AT_RESULT_...| Length = 1    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 63 
   The value field of this attribute consists of two reserved bytes,
   which are set to zero upon sending and ignored upon reception.  This
   attribute is always sent unencrypted, so it MUST NOT be encapsulated
   within the AT_ENCR_DATA attribute.

10.15.  AT_MAC

   The AT_MAC attribute is used for EAP-AKA message authentication.
   Section 9 specifies in which messages AT_MAC MUST be included.

   The value field of the AT_MAC attribute contains two reserved bytes
   followed by a keyed message authentication code (MAC).  The MAC is
   calculated over the whole EAP packet and concatenated with optional
   message-specific data, with the exception that the value field of the
   MAC attribute is set to zero when calculating the MAC.  The EAP
   packet includes the EAP header that begins with the Code field, the
   EAP-AKA header that begins with the Subtype field, and all the
   attributes, as specified in Section 8.1.  The reserved bytes in
   AT_MAC are set to zero when sending and ignored on reception.  The
   contents of the message-specific data that may be included in the MAC
   calculation are specified separately for each EAP-AKA message in
   Section 9.

   The format of the AT_MAC attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     AT_MAC    | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           MAC                                 |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value.  (The
   HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
   truncating the output to 16 bytes.  Hence, the length of the MAC is
   16 bytes.)  The derivation of the authentication key (K_aut) used in
   the calculation of the MAC is specified in Section 7.

   When the AT_MAC attribute is included in an EAP-AKA message, the
   recipient MUST process the AT_MAC attribute before looking at any
   other attributes, except when processing EAP-Request/AKA-Challenge.
   The processing of EAP-Request/AKA-Challenge is specified in

Top      Up      ToC       Page 64 
   Section 9.3.  If the message authentication code is invalid, then the
   recipient MUST ignore all other attributes in the message and operate
   as specified in Section 6.3.

10.16.  AT_COUNTER

   The format of the AT_COUNTER attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AT_COUNTER   | Length = 1    |           Counter             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of the AT_COUNTER attribute consists of a 16-bit
   unsigned integer counter value, represented in network byte order.
   This attribute MUST always be encrypted by encapsulating it within
   the AT_ENCR_DATA attribute.

10.17.  AT_COUNTER_TOO_SMALL

   The format of the AT_COUNTER_TOO_SMALL attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AT_COUNTER...| Length = 1    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute consists of two reserved bytes,
   which are set to zero upon sending and ignored upon reception.  This
   attribute MUST always be encrypted by encapsulating it within the
   AT_ENCR_DATA attribute.

Top      Up      ToC       Page 65 
10.18.  AT_NONCE_S

   The format of the AT_NONCE_S attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_NONCE_S    | Length = 5    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                            NONCE_S                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of the AT_NONCE_S attribute contains two reserved
   bytes followed by a random number (16 bytes) that is freshly
   generated by the server for this EAP-AKA fast re-authentication.  The
   random number is used as challenge for the peer and also as a seed
   value for the new keying material.  The reserved bytes are set to
   zero upon sending and ignored upon reception.  This attribute MUST
   always be encrypted by encapsulating it within the AT_ENCR_DATA
   attribute.

   The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA
   fast re-authentication exchange.  The server SHOULD use a good source
   of randomness to generate NONCE_S.  Please see [RFC4086] for more
   information about generating random numbers for security
   applications.

10.19.  AT_NOTIFICATION

   The format of the AT_NOTIFICATION attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_NOTIFICATION| Length = 1    |S|P|  Notification Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute contains a two-byte notification
   code.  The first and second bit (S and P) of the notification code
   are interpreted as described in Section 6.

Top      Up      ToC       Page 66 
   The notification code values listed below have been reserved.  The
   descriptions below illustrate the semantics of the notifications.
   The peer implementation MAY use different wordings when presenting
   the notifications to the user.  The "requested service" depends on
   the environment where EAP-AKA is applied.

   0 - General failure after authentication.  (Implies failure, used
   after successful authentication.)

   16384 - General failure.  (Implies failure, used before
   authentication.)

   32768 - Success.  User has been successfully authenticated.  (Does
   not imply failure, used after successful authentication.)  The usage
   of this code is discussed in Section 6.2.

   1026 - User has been temporarily denied access to the requested
   service.  (Implies failure, used after successful authentication.)

   1031 - User has not subscribed to the requested service.  (Implies
   failure, used after successful authentication.)

10.20.  AT_CLIENT_ERROR_CODE

   The format of the AT_CLIENT_ERROR_CODE attribute is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_CLIENT_ERR..| Length = 1    |     Client Error Code         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute contains a two-byte client error
   code.  The following error code values have been reserved.

   0 "unable to process packet": a general error code

11.  IANA and Protocol Numbering Considerations

   IANA has assigned the EAP type number 23 for EAP-AKA authentication.

   EAP-AKA shares most of the protocol design, such as attributes and
   message Subtypes, with EAP-SIM [EAP-SIM].  EAP-AKA protocol numbers
   should be administered in the same IANA registry with EAP-SIM.  This
   document establishes the registries and lists the initial protocol
   numbers for both protocols.

Top      Up      ToC       Page 67 
   EAP-AKA and EAP-SIM messages include a Subtype field.  The Subtype is
   a new numbering space for which IANA administration is required.  The
   Subtype is an 8-bit integer.  The following Subtypes are specified in
   this document and in [EAP-SIM]:

        AKA-Challenge...................................1
        AKA-Authentication-Reject.......................2
        AKA-Synchronization-Failure.....................4
        AKA-Identity....................................5
        SIM-Start......................................10
        SIM-Challenge..................................11
        AKA-Notification and SIM-Notification..........12
        AKA-Reauthentication and SIM-Reauthentication..13
        AKA-Client-Error and SIM-Client-Error..........14

   The messages are composed of attributes, which have 8-bit attribute
   type numbers.  Attributes numbered within the range 0 through 127 are
   called non-skippable attributes, and attributes within the range of
   128 through 255 are called skippable attributes.  The EAP-AKA and
   EAP-SIM attribute type number is a new numbering space for which IANA
   administration is required.  The following attribute types are
   specified in this document in [EAP-SIM]:

        AT_RAND.........................................1
        AT_AUTN.........................................2
        AT_RES..........................................3
        AT_AUTS.........................................4
        AT_PADDING......................................6
        AT_NONCE_MT.....................................7
        AT_PERMANENT_ID_REQ............................10
        AT_MAC.........................................11
        AT_NOTIFICATION................................12
        AT_ANY_ID_REQ..................................13
        AT_IDENTITY....................................14
        AT_VERSION_LIST................................15
        AT_SELECTED_VERSION............................16
        AT_FULLAUTH_ID_REQ.............................17
        AT_COUNTER.....................................19
        AT_COUNTER_TOO_SMALL...........................20
        AT_NONCE_S.....................................21
        AT_CLIENT_ERROR_CODE...........................22
        AT_IV.........................................129
        AT_ENCR_DATA..................................130
        AT_NEXT_PSEUDONYM.............................132
        AT_NEXT_REAUTH_ID.............................133
        AT_CHECKCODE..................................134
        AT_RESULT_IND.................................135

Top      Up      ToC       Page 68 
   The AT_NOTIFICATION attribute contains a 16-bit notification code
   value.  The most significant bit of the notification code is called
   the S bit (success) and the second most significant bit is called the
   P bit (phase).  If the S bit is set to zero, then the notification
   code indicates failure; notification codes with the S bit set to one
   do not indicate failure.  If the P bit is set to zero, then the
   notification code can only be used before authentication has
   occurred.  If the P bit is set to one, then the notification code can
   only be used after authentication.  The notification code is a new
   numbering space for which IANA administration is required.  The
   following values have been specified in this document and in
   [EAP-SIM].

        General failure after authentication......................0
        User has been temporarily denied access................1026
        User has not subscribed to the requested service.......1031
        General failure.......................................16384
        Success...............................................32768

   The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in
   [EAP-SIM], contain 16-bit EAP method version numbers.  The EAP method
   version number is a new numbering space for which IANA administration
   is required.  Value 1 for "EAP-SIM Version 1" has been specified in
   [EAP-SIM].  Version numbers are not currently used in EAP-AKA.

   The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error
   code.  The client error code is a new numbering space for which IANA
   administration is required.  Values 0, 1, 2, and 3 have been
   specified in this document and in [EAP-SIM].

   All requests for value assignment from the various number spaces
   described in this document require proper documentation, according to
   the "Specification Required" policy described in [RFC2434].  Requests
   must be specified in sufficient detail so that interoperability
   between independent implementations is possible.  Possible forms of
   documentation include, but are not limited to, RFCs, the products of
   another standards body (e.g., 3GPP), or permanently and readily
   available vendor design notes.

12.  Security Considerations

   The EAP specification [RFC3748] describes the security
   vulnerabilities of EAP, which does not include its own security
   mechanisms.  This section discusses the claimed security properties
   of EAP-AKA as well as vulnerabilities and security recommendations.

Top      Up      ToC       Page 69 
12.1.  Identity Protection

   EAP-AKA includes optional Identity privacy support that protects the
   privacy of the subscriber identity against passive eavesdropping.
   This document only specifies a mechanism to deliver pseudonyms from
   the server to the peer as part of an EAP-AKA exchange.  Hence, a peer
   that has not yet performed any EAP-AKA exchanges does not typically
   have a pseudonym available.  If the peer does not have a pseudonym
   available, then the privacy mechanism cannot be used, and the
   permanent identity will have to be sent in the clear.  The terminal
   SHOULD store the pseudonym in non-volatile memory so that it can be
   maintained across reboots.  An active attacker that impersonates the
   network may use the AT_PERMANENT_ID_REQ attribute (Section 4.1.2) to
   learn the subscriber's IMSI.  However, as discussed in Section 4.1.2,
   the terminal can refuse to send the cleartext IMSI if it believes
   that the network should be able to recognize the pseudonym.

   If the peer and server cannot guarantee that the pseudonym will be
   maintained reliably, and Identity privacy is required then additional
   protection from an external security mechanism (such as Protected
   Extensible Authentication Protocol (PEAP) [PEAP]) may be used.  The
   benefits and the security considerations of using an external
   security mechanism with EAP-AKA are beyond the scope of this
   document.

12.2.  Mutual Authentication

   EAP-AKA provides mutual authentication via the 3rd generation AKA
   mechanisms [TS33.102] and [S.S0055-A].

   Note that this mutual authentication is with the EAP server.  In
   general, EAP methods do not authenticate the identity or services
   provided by the EAP authenticator (if distinct from the EAP server)
   unless they provide the so-called channel bindings property.  The
   vulnerabilities related to this have been discussed in [RFC3748],
   [EAPKeying], [ServiceIdentity].

   EAP-AKA does not provide the channel bindings property, so it only
   authenticates the EAP server.  However, ongoing work such as
   [ServiceIdentity] may provide such support as an extension to popular
   EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.

12.3.  Flooding the Authentication Centre

   The EAP-AKA server typically obtains authentication vectors from the
   Authentication Centre (AuC).  EAP-AKA introduces a new usage for the
   AuC.  The protocols between the EAP-AKA server and the AuC are out of
   the scope of this document.  However, it should be noted that a

Top      Up      ToC       Page 70 
   malicious EAP-AKA peer may generate a lot of protocol requests to
   mount a denial-of-service attack.  The EAP-AKA server implementation
   SHOULD take this into account and SHOULD take steps to limit the
   traffic that it generates towards the AuC, preventing the attacker
   from flooding the AuC and from extending the denial-of-service attack
   from EAP-AKA to other users of the AuC.

12.4.  Key Derivation

   EAP-AKA supports key derivation with 128-bit effective key strength.
   The key hierarchy is specified in Section 7.

   The Transient EAP Keys used to protect EAP-AKA packets (K_encr,
   K_aut), the Master Session Keys, and the Extended Master Session Keys
   are cryptographically separate.  An attacker cannot derive any
   non-trivial information about any of these keys based on the other
   keys.  An attacker also cannot calculate the pre-shared secret from
   AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session
   Key, or the Extended Master Session Key.

12.5.  Brute-Force and Dictionary Attacks

   The effective strength of EAP-AKA values is 128 bits, and there are
   no known, computationally feasible brute-force attacks.  Because AKA
   is not a password protocol (the pre-shared secret is not a
   passphrase, or derived from a passphrase), EAP-AKA is not vulnerable
   to dictionary attacks.

12.6.  Protection, Replay Protection, and Confidentiality

   AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to
   provide integrity, replay, and confidentiality protection for EAP-AKA
   Requests and Responses.  Integrity protection with AT_MAC includes
   the EAP header.  Integrity protection (AT_MAC) is based on a keyed
   message authentication code.  Confidentiality (AT_ENCR_DATA and
   AT_IV) is based on a block cipher.

   Because keys are not available in the beginning of the EAP methods,
   the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity
   messages.  However, the AT_CHECKCODE attribute can optionally be used
   to protect the integrity of the EAP/AKA-Identity roundtrip.

   Confidentiality protection is applied only to a part of the protocol
   fields.  The table of attributes in Section 10.1 summarizes which
   fields are confidentiality protected.  It should be noted that the
   error and notification code attributes AT_CLIENT_ERROR_CODE and
   AT_NOTIFICATION are not confidential, but they are transmitted in the
   clear.  Identity protection is discussed in Section 12.1.

Top      Up      ToC       Page 71 
   On full authentication, replay protection of the EAP exchange is
   provided by RAND and AUTN values from the underlying AKA scheme.
   Protection against replays of EAP-AKA messages is also based on the
   fact that messages that can include AT_MAC can only be sent once with
   a certain EAP-AKA Subtype, and on the fact that a different K_aut key
   will be used for calculating AT_MAC in each full authentication
   exchange.

   On fast re-authentication, a counter included in AT_COUNTER and a
   server random nonce is used to provide replay protection.  The
   AT_COUNTER attribute is also included in EAP-AKA notifications, if
   they are used after successful authentication in order to provide
   replay protection between re-authentication exchanges.

   The contents of the user identity string are implicitly integrity
   protected by including them in key derivation.

   Because EAP-AKA is not a tunneling method, EAP-Request/Notification,
   EAP-Response/Notification, EAP-Success, or EAP-Failure packets are
   not confidential, integrity protected, or replay protected.  On
   physically insecure networks, this may enable an attacker to mount
   denial-of-service attacks by spoofing these packets.  As discussed in
   Section 6.3, the peer will only accept EAP-Success after the peer
   successfully authenticates the server.  Hence, the attacker cannot
   force the peer to believe successful mutual authentication has
   occurred before the peer successfully authenticates the server or
   after the peer failed to authenticate the server.

   The security considerations of EAP-AKA result indications are covered
   in Section 12.8

   An eavesdropper will see the EAP Notification, EAP_Success and
   EAP-Failure packets sent in the clear.  With EAP-AKA, confidential
   information MUST NOT be transmitted in EAP Notification packets.

12.7.  Negotiation Attacks

   EAP-AKA does not protect the EAP-Response/Nak packet.  Because
   EAP-AKA does not protect the EAP method negotiation, EAP method
   downgrading attacks may be possible, especially if the user uses the
   same identity with EAP-AKA and other EAP methods.

   As described in Section 8, EAP-AKA allows the protocol to be extended
   by defining new attribute types.  When defining such attributes, it
   should be noted that any extra attributes included in
   EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not

Top      Up      ToC       Page 72 
   included in the MACs later on, and thus some other precautions must
   be taken to avoid modifications to them.

   EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol
   version negotiation.

12.8.  Protected Result Indications

   EAP-AKA supports optional protected success indications, and
   acknowledged failure indications.  If a failure occurs after
   successful authentication, then the EAP-AKA failure indication is
   integrity and replay protected.

   Even if an EAP-Failure packet is lost when using EAP-AKA over an
   unreliable medium, then the EAP-AKA failure indications will help
   ensure that the peer and EAP server will know the other party's
   authentication decision.  If protected success indications are used,
   then the loss of Success packet will also be addressed by the
   acknowledged, integrity, and replay protected EAP-AKA success
   indication.  If the optional success indications are not used, then
   the peer may end up believing the server completed successful
   authentication, when actually it failed.  Because access will not be
   granted in this case, protected result indications are not needed
   unless the client is not able to realize it does not have access for
   an extended period of time.

12.9.  Man-in-the-Middle Attacks

   In order to avoid man-in-the-middle attacks and session hijacking,
   user data SHOULD be integrity protected on physically insecure
   networks.  The EAP-AKA Master Session Key or keys derived from it MAY
   be used as the integrity protection keys, or, if an external security
   mechanism such as PEAP is used, then the link integrity protection
   keys MAY be derived by the external security mechanism.

   There are man-in-the-middle attacks associated with the use of any
   EAP method within a tunneled protocol.  For instance, an early
   version of PEAP [PEAP-02] was vulnerable to this attack.  This
   specification does not address these attacks.  If EAP-AKA is used
   with a tunneling protocol, there should be cryptographic binding
   provided between the protocol and EAP-AKA to prevent
   man-in-the-middle attacks through rogue authenticators being able to
   setup one-way authenticated tunnels.  For example, newer versions of
   PEAP include such cryptographic binding.  The EAP-AKA Master Session
   Key MAY be used to provide the cryptographic binding.  However, the
   mechanism that provides the binding depends on the tunneling protocol
   and is beyond the scope of this document.

Top      Up      ToC       Page 73 
12.10.  Generating Random Numbers

   An EAP-AKA implementation SHOULD use a good source of randomness to
   generate the random numbers required in the protocol.  Please see
   [RFC4086] for more information on generating random numbers for
   security applications.

13.  Security Claims

   This section provides the security claims required by [RFC3748].

   Auth.  Mechanism: EAP-AKA is based on the AKA mechanism, which is an
   authentication and key agreement mechanism based on a symmetric
   128-bit pre-shared secret.

   Ciphersuite negotiation: No

   Mutual authentication: Yes (Section 12.2)

   Integrity protection: Yes (Section 12.6)

   Replay protection: Yes (Section 12.6)

   Confidentiality: Yes, except method-specific success and failure
   indications (Section 12.1, Section 12.6)

   Key derivation: Yes

   Key strength: EAP-AKA supports key derivation with 128-bit effective
   key strength.

   Description of key hierarchy: Please see Section 7.

   Dictionary attack protection: N/A (Section 12.5)

   Fast reconnect: Yes

   Cryptographic binding: N/A

   Session independence: Yes (Section 12.4)

   Fragmentation: No

   Channel binding: No

   Indication of vulnerabilities.  Vulnerabilities are discussed in
   Section 12.

Top      Up      ToC       Page 74 
14.  Acknowledgements and Contributions

   The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of
   Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri
   Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia,
   Pasi Eronen of Nokia, Olivier Paridaens of Alcatel, and Ilkka
   Uusitalo of Ericsson for interesting discussions in this problem
   space.

   Many thanks to Yoshihiro Ohba for reviewing the document.

   This protocol has been partly developed in parallel with EAP-SIM
   [EAP-SIM], and hence this specification incorporates many ideas from
   EAP-SIM, and many contributions from the reviewer's of EAP-SIM.

   The attribute format is based on the extension format of Mobile IPv4
   [RFC3344].

15.  References

15.1.  Normative References

   [TS33.102]        3rd Generation Partnership Project, "3GPP Technical
                     Specification 3GPP TS 33.102 V5.1.0: "Technical
                     Specification Group Services and System Aspects; 3G
                     Security; Security Architecture (Release 5)"",
                     December 2002.

   [S.S0055-A]       3rd Generation Partnership Project 2, "3GPP2
                     Enhanced Cryptographic Algorithms", September 2003.

   [RFC4282]         Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
                     "The Network Access Identifier", RFC 4282, December
                     2005.

   [RFC3748]         Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
                     and H.  Levkowetz, "Extensible Authentication
                     Protocol (EAP)", RFC 3748, June 2004.

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TS23.003]        3rd Generation Partnership Project, "3GPP Technical
                     Specification 3GPP TS 23.003 V6.8.0: "3rd
                     Generation Parnership Project; Technical
                     Specification Group Core Network; Numbering,
                     addressing and identification (Release 6)"",
                     December 2005.

Top      Up      ToC       Page 75 
   [RFC2104]         Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                     Keyed-Hashing for Message Authentication",
                     RFC 2104, February 1997.

   [AES]             National Institute of  Standards and Technology,
                     "Federal Information Processing Standards (FIPS)
                     Publication 197, "Advanced Encryption Standard
                     (AES)"", November 2001,
                     http://csrc.nist.gov/publications/fips/fips197/
                     fips-197.pdf.

   [CBC]             National Institute of Standards and Technology,
                     "NIST Special Publication 800-38A, "Recommendation
                     for Block Cipher Modes of Operation - Methods and
                     Techniques"", December 2001,
                     http://csrc.nist.gov/publications/
                     nistpubs/800-38a/sp800-38a.pdf.

   [SHA-1]           National Institute of Standards and Technology,
                     U.S.  Department of Commerce, "Federal Information
                     Processing Standard (FIPS) Publication 180-1,
                     "Secure Hash Standard"", April 1995.

   [PRF]             National Institute of Standards and Technology,
                     "Federal Information Processing Standards (FIPS)
                     Publication  186-2 (with change notice); Digital
                     Signature Standard (DSS)", January 2000,
                     http://csrc.nist.gov/publications/
                     fips/fips186-2/fips186-2-change1.pdf.

   [TS33.105]        3rd Generation Partnership Project, "3GPP Technical
                     Specification 3GPP TS 33.105 4.1.0: "Technical
                     Specification Group Services and System Aspects; 3G
                     Security; Cryptographic Algorithm Requirements
                     (Release 4)"", June 2001.

   [RFC3629]         Yergeau, F., "UTF-8, a transformation format of ISO
                     10646", STD 63, RFC 3629, November 2003.

   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
                     Writing an IANA Considerations Section in RFCs",
                     BCP 26, RFC 2434, October 1998.

Top      Up      ToC       Page 76 
15.2.  Informative References

   [RFC2548]         Zorn, G., "Microsoft Vendor-specific RADIUS
                     Attributes", RFC 2548, March 1999.

   [PEAP]            Palekar, A., Simon, D., Zorn, G., Salowey, J.,
                     Zhou, H., and S. Josefsson, "Protected EAP Protocol
                     (PEAP) Version 2", work in progress, October 2004.

   [PEAP-02]         Anderson, H., Josefsson, S., Zorn, G., Simon, D.,
                     and A.  Palekar, "Protected EAP Protocol (PEAP)",
                     work in progress, February 2002.

   [EAPKeying]       Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
                     Levkowetz, "Extensible Authentication Protocol
                     (EAP) Key Management Framework", work in progress,
                     October 2005.

   [ServiceIdentity] Arkko, J. and P. Eronen, "Authenticated Service
                     Information for the Extensible Authentication
                     Protocol (EAP)", Work in Progress, October 2004.

   [RFC4086]         Eastlake, D., Schiller, J., and S. Crocker,
                     "Randomness Requirements for Security", BCP 106,
                     RFC 4086, June 2005.

   [RFC3344]         Perkins, C., "IP Mobility Support for IPv4",
                     RFC 3344, August 2002.

   [EAP-SIM]         Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
                     Authentication Protocol Method for Global System
                     for Mobile Communications (GSM) Subscriber Identity
                     Modules (EAP-SIM)", RFC 4186, January 2006.

Top      Up      ToC       Page 77 
Appendix A.  Pseudo-Random Number Generator

   The "|" character denotes concatenation, and "^" denotes
   exponentiation.

   Step 1: Choose a new, secret value for the seed-key, XKEY

   Step 2: In hexadecimal notation let
       t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
       This is the initial value for H0|H1|H2|H3|H4
       in the FIPS SHS [SHA-1]

   Step 3: For j = 0 to m - 1 do
         3.1.  XSEED_j = 0 /* no optional user input */
         3.2.  For i = 0 to 1 do
               a.  XVAL = (XKEY + XSEED_j) mod 2^b
               b.  w_i = G(t, XVAL)
               c.  XKEY = (1 + XKEY + w_i) mod 2^b
         3.3.  x_j = w_0|w_1

Top      Up      ToC       Page 78 
Authors' Addresses

   Jari Arkko
   Ericsson
   FIN-02420 Jorvas
   Finland

   EMail: jari.Arkko@ericsson.com


   Henry Haverinen
   Nokia Enterprise Solutions
   P.O. Box 12
   FIN-40101 Jyvaskyla
   Finland

   EMail: henry.haverinen@nokia.com

Top      Up      ToC       Page 79 
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).