6.  EAP-AKA Notifications

6.1.  General

   EAP-AKA does not prohibit the use of the EAP Notifications as
   specified in [RFC3748].  EAP Notifications can be used at any time in
   the EAP-AKA exchange.  It should be noted that EAP-AKA does not
   protect EAP Notifications.  EAP-AKA also specifies method-specific
   EAP-AKA notifications, which are protected in some cases.

   The EAP server can use EAP-AKA notifications to convey notifications
   and result indications (Section 6.2) to the peer.

   The server MUST use notifications in cases discussed in
   Section 6.3.2.  When the EAP server issues an
   EAP-Request/AKA-Notification packet to the peer, the peer MUST
   process the notification packet.  The peer MAY show a notification
   message to the user and the peer MUST respond to the EAP server with
   an EAP-Response/AKA-Notification packet, even if the peer did not
   recognize the notification code.

   An EAP-AKA full authentication exchange or a fast re-authentication
   exchange MUST NOT include more than one EAP-AKA notification round.

   The notification code is a 16-bit number.  The most significant bit
   is called the Success bit (S bit).  The S bit specifies whether the
   notification implies failure.  The code values with the S bit set to
   zero (code values 0...32767) are used on unsuccessful cases.  The

   receipt of a notification code from this range implies failed EAP
   exchange, so the peer can use the notification as a failure
   indication.  After receiving the EAP-Response/AKA-Notification for
   these notification codes, the server MUST send the EAP-Failure
   packet.

   The receipt of a notification code with the S bit set to one (values
   32768...65536) does not imply failure.  Notification code "Success"
   (32768) has been reserved as a general notification code to indicate
   successful authentication.

   The second most significant bit of the notification code is called
   the Phase bit (P bit).  It specifies at which phase of the EAP-AKA
   exchange the notification can be used.  If the P bit is set to zero,
   the notification can only be used after a successful EAP/AKA-
   Challenge round in full authentication or a successful EAP/AKA-
   Reauthentication round in re-authentication.  A re-authentication
   round is considered successful only if the peer has successfully
   verified AT_MAC and AT_COUNTER attributes, and does not include the
   AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.

   If the P bit is set to one, the notification can only by used before
   the EAP/AKA-Challenge round in full authentication or before the
   EAP/AKA-Reauthentication round in reauthentication.  These
   notifications can only be used to indicate various failure cases.  In
   other words, if the P bit is set to one, then the S bit MUST be set
   to zero.

   Section 9.10 and Section 9.11 specify what other attributes must be
   included in the notification packets.

   Some of the notification codes are authorization related and hence
   not usually considered as part of the responsibility of an EAP
   method.  However, they are included as part of EAP-AKA because there
   are currently no other ways to convey this information to the user in
   a localizable way, and the information is potentially useful for the
   user.  An EAP-AKA server implementation may decide never to send
   these EAP-AKA notifications.

6.2.  Result Indications

   As discussed in Section 6.3, the server and the peer use explicit
   error messages in all error cases.  If the server detects an error
   after successful authentication, the server uses an EAP-AKA
   notification to indicate failure to the peer.  In this case, the
   result indication is integrity and replay protected.

   By sending an EAP-Response/AKA-Challenge packet or an
   EAP-Response/AKA-Reauthentication packet (without
   AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
   authenticated the server and that the peer's local policy accepts the
   EAP exchange.  In other words, these packets are implicit success
   indications from the peer to the server.

   EAP-AKA also supports optional protected success indications from the
   server to the peer.  If the EAP server wants to use protected success
   indications, it includes the AT_RESULT_IND attribute in the
   EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication
   packet.  This attribute indicates that the EAP server would like to
   use result indications in both successful and unsuccessful cases.  If
   the peer also wants this, the peer includes AT_RESULT_IND in
   EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication.  The
   peer MUST NOT include AT_RESULT_IND if it did not receive
   AT_RESULT_IND from the server.  If both the peer and the server used
   AT_RESULT_IND, then the EAP exchange is not complete yet, but an
   EAP-AKA notification round will follow.  The following EAP-AKA
   notification may indicate either failure or success.

   Success indications with the AT_NOTIFICATION code "Success" (32768)
   can only be used if both the server and the peer indicate they want
   to use them with AT_RESULT_IND.  If the server did not include
   AT_RESULT_IND in the EAP-Request/AKA-Challenge or
   EAP-Request/AKA-Reauthentication packet, or if the peer did not
   include AT_RESULT_IND in the corresponding response packet, then the
   server MUST NOT use protected success indications.

   Because the server uses the AT_NOTIFICATION code "Success" (32768) to
   indicate that the EAP exchange has completed successfully, the EAP
   exchange cannot fail when the server processes the EAP-AKA response
   to this notification.  Hence, the server MUST ignore the contents of
   the EAP-AKA response it receives to the EAP-Request/AKA-Notification
   with this code.  Regardless of the contents of the EAP-AKA response,
   the server MUST send EAP-Success as the next packet.

6.3.  Error Cases

   This section specifies the operation of the peer and the server in
   error cases.  The subsections below require the EAP-AKA peer and
   server to send an error packet (EAP-Response/AKA-Client-Error,
   EAP-Response/AKA-Authentication-Reject or
   EAP-Response/AKA-Synchronization-Failure from the peer and
   EAP-Request/AKA-Notification from the server) in error cases.
   However, implementations SHOULD NOT rely upon the correct error
   reporting behavior of the peer, authenticator, or server.  It is
   possible for error messages and other messages to be lost in transit,

   or for a malicious participant to attempt to consume resources by not
   issuing error messages.  Both the peer and the EAP server SHOULD have
   a mechanism to clean up state even if an error message or EAP-Success
   is not received after a timeout period.

6.3.1.  Peer Operation

   Two special error messages have been specified for error cases that
   are related to the processing of the AKA AUTN parameter, as described
   in Section 3: (1) if the peer does not accept AUTN, the peer responds
   with EAP-Response/AKA-Authentication-Reject (Section 9.5), and the
   server issues EAP-Failure, and (2) if the peer detects that the
   sequence number in AUTN is not correct, the peer responds with
   EAP-Response/AKA-Synchronization-Failure (Section 9.6), and the
   server proceeds with a new EAP-Request/AKA-Challenge.

   In other error cases, when an EAP-AKA peer detects an error in a
   received EAP-AKA packet, the EAP-AKA peer responds with the
   EAP-Response/AKA-Client-Error packet.  In response to the
   EAP-Response/AKA-Client-Error, the EAP server MUST issue the
   EAP-Failure packet, and the authentication exchange terminates.

   By default, the peer uses the client error code 0, "unable to process
   packet".  This error code is used in the following cases:

   o  EAP exchange is not acceptable according to the peer's local
      policy.
   o  The peer is not able to parse the EAP request, i.e., the EAP
      request is malformed.
   o  The peer encountered a malformed attribute.
   o  Wrong attribute types or duplicate attributes have been included
      in the EAP request.
   o  A mandatory attribute is missing.
   o  Unrecognized non-skippable attribute.
   o  Unrecognized or unexpected EAP-AKA Subtype in the EAP request.
   o  Invalid AT_MAC.  The peer SHOULD log this event.
   o  Invalid AT_CHECKCODE.  The peer SHOULD log this event.
   o  Invalid pad bytes in AT_PADDING.
   o  The peer does not want to process AT_PERMANENT_ID_REQ.

6.3.2.  Server Operation

   If an EAP-AKA server detects an error in a received EAP-AKA response,
   the server MUST issue the EAP-Request/AKA-Notification packet with an
   AT_NOTIFICATION code that implies failure.  By default, the server
   uses one of the general failure codes ("General failure after
   authentication" (0) or "General failure" (16384)).  The choice

   between these two codes depends on the phase of the EAP-AKA exchange,
   see Section 6.  The error cases when the server issues an
   EAP-Request/AKA-Notification that implies failure include the
   following:

   o  The server is not able to parse the peer's EAP response.
   o  The server encounters a malformed attribute, a non-recognized
      non-skippable attribute, or a duplicate attribute.
   o  A mandatory attribute is missing or an invalid attribute was
      included.
   o  Unrecognized or unexpected EAP-AKA Subtype in the EAP Response.
   o  Invalid AT_MAC.  The server SHOULD log this event.
   o  Invalid AT_CHECKCODE.  The server SHOULD log this event.
   o  Invalid AT_COUNTER.

6.3.3.  EAP-Failure

   The EAP-AKA server sends EAP-Failure in three cases:

   1.  In response to an EAP-Response/AKA-Client-Error packet the server
       has received from the peer, or

   2.  In response to an EAP-Response/AKA-Authentication-Reject packet
       the server has received from the peer, or

   3.  Following an EAP-AKA notification round, when the AT_NOTIFICATION
       code implies failure.

   The EAP-AKA server MUST NOT send EAP-Failure in other cases than
   these three.  However, it should be noted that even though the
   EAP-AKA server would not send an EAP-Failure, an authorization
   decision that happens outside EAP-AKA, such as in the AAA server or
   in an intermediate AAA proxy, may result in a failed exchange.

   The peer MUST accept the EAP-Failure packet in case 1), case 2), and
   case 3) above.  The peer SHOULD silently discard the EAP-Failure
   packet in other cases.

6.3.4.  EAP-Success

   On full authentication, the server can only send EAP-Success after
   the EAP/AKA-Challenge round.  The peer MUST silently discard any
   EAP-Success packets if they are received before the peer has
   successfully authenticated the server and sent the
   EAP-Response/AKA-Challenge packet.

   If the peer did not indicate that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2) on full
   authentication, then the peer MUST accept EAP-Success after a
   successful EAP/AKA-Challenge round.

   If the peer indicated that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2), then
   the peer MUST NOT accept EAP-Success after a successful EAP/
   AKA-Challenge round.  In this case, the peer MUST only accept
   EAP-Success after receiving an EAP-AKA Notification with the
   AT_NOTIFICATION code "Success" (32768).

   On fast re-authentication, EAP-Success can only be sent after the
   EAP/AKA-Reauthentication round.  The peer MUST silently discard any
   EAP-Success packets if they are received before the peer has
   successfully authenticated the server and sent the
   EAP-Response/AKA-Reauthentication packet.

   If the peer did not indicate that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
   re-authentication, then the peer MUST accept EAP-Success after a
   successful EAP/AKA-Reauthentication round.

   If the peer indicated that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2), then
   the peer MUST NOT accept EAP-Success after a successful EAP/AKA-
   Reauthentication round.  In this case, the peer MUST only accept
   EAP-Success after receiving an EAP-AKA Notification with the
   AT_NOTIFICATION code "Success" (32768).

   If the peer receives an EAP-AKA notification (Section 6) that
   indicates failure, then the peer MUST no longer accept the
   EAP-Success packet, even if the server authentication was
   successfully completed.

7.  Key Generation

   This section specifies how keying material is generated.

   On EAP-AKA full authentication, a Master Key (MK) is derived from the
   underlying AKA values (CK and IK keys), and the identity, as follows.

   MK = SHA1(Identity|IK|CK)

   In the formula above, the "|" character denotes concatenation.
   Identity denotes the peer identity string without any terminating
   null characters.  It is the identity from the last AT_IDENTITY
   attribute sent by the peer in this exchange, or, if AT_IDENTITY was

   not used, the identity from the EAP-Response/Identity packet.  The
   identity string is included as-is, without any changes.  As discussed
   in Section 4.1.2.2, relying on EAP-Response/Identity for conveying
   the EAP-AKA peer identity is discouraged, and the server SHOULD use
   the EAP-AKA method-specific identity attributes.  The hash function
   SHA-1 is specified in [SHA-1].

   The Master Key is fed into a Pseudo-Random number Function (PRF),
   which generates separate Transient EAP Keys (TEKs) for protecting
   EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
   security and an Extended Master Session Key (EMSK) for other
   purposes.  On fast re-authentication, the same TEKs MUST be used for
   protecting EAP packets, but a new MSK and a new EMSK MUST be derived
   from the original MK and from new values exchanged in the fast
   re-authentication.

   EAP-AKA requires two TEKs for its own purposes: the authentication
   key K_aut, to be used with the AT_MAC attribute, and the encryption
   key K_encr, to be used with the AT_ENCR_DATA attribute.  The same
   K_aut and K_encr keys are used in full authentication and subsequent
   fast re-authentications.

   Key derivation is based on the random number generation specified in
   NIST Federal Information Processing Standards (FIPS) Publication
   186-2 [PRF].  The pseudo-random number generator is specified in the
   change notice 1 (2001 October 5) of [PRF] (Algorithm 1).  As
   specified in the change notice (page 74), when Algorithm 1 is used as
   a general-purpose pseudo-random number generator, the "mod q" term in
   step 3.3 is omitted.  The function G used in the algorithm is
   constructed via Secure Hash Standard as specified in Appendix 3.3 of
   the standard.  It should be noted that the function G is very similar
   to SHA-1, but the message padding is different.  Please refer to
   [PRF] for full details.  For convenience, the random number algorithm
   with the correct modification is cited in Annex A.

   160-bit XKEY and XVAL values are used, so b = 160.  On each full
   authentication, the Master Key is used as the initial secret seed-key
   XKEY.  The optional user input values (XSEED_j) in step 3.1 are set
   to zero.

   On full authentication, the resulting 320-bit random numbers x_0,
   x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized
   chunks and used as keys in the following order: K_encr (128 bits),
   K_aut (128 bits), Master Session Key (64 bytes), Extended Master
   Session Key (64 bytes).

   On fast re-authentication, the same pseudo-random number generator
   can be used to generate a new Master Session Key and a new Extended
   Master Session Key.  The seed value XKEY' is calculated as follows:

   XKEY' = SHA1(Identity|counter|NONCE_S| MK)

   In the formula above, the Identity denotes the fast re-authentication
   identity, without any terminating null characters, from the
   AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if
   EAP-Response/AKA-Identity was not used on fast re-authentication, it
   denotes the identity string from the EAP-Response/Identity packet.
   The counter denotes the counter value from the AT_COUNTER attribute
   used in the EAP-Response/AKA-Reauthentication packet.  The counter is
   used in network byte order.  NONCE_S denotes the 16-byte random
   NONCE_S value from the AT_NONCE_S attribute used in the
   EAP-Request/AKA-Reauthentication packet.  The MK is the Master Key
   derived on the preceding full authentication.

   On fast re-authentication, the pseudo-random number generator is run
   with the new seed value XKEY', and the resulting 320-bit random
   numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into
   64-byte chunks and used as the new 64-byte Master Session Key and the
   new 64-byte Extended Master Session Key.  Note that because K_encr
   and K_aut are not derived on fast re-authentication, the Master
   Session Key and the Extended Master Session key are obtained from the
   beginning of the key stream x_0, x_1, ....

   The first 32 bytes of the MSK can be used as the Pairwise Master Key
   (PMK) for IEEE 802.11i.

   When the RADIUS attributes specified in [RFC2548] are used to
   transport keying material, then the first 32 bytes of the MSK
   correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
   MS-MPPE-SEND-KEY.  In this case, only 64 bytes of keying material
   (the MSK) are used.

8.  Message Format and Protocol Extensibility

8.1.  Message Format

   As specified in [RFC3748], EAP packets begin with the Code,
   Identifiers, Length, and Type fields, which are followed by
   EAP-method-specific Type-Data.  The Code field in the EAP header is
   set to 1 for EAP requests, and to 2 for EAP Responses.  The usage of
   the Length and Identifier fields in the EAP header is also specified
   in [RFC3748].  In EAP-AKA, the Type field is set to 23.

   In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists
   of a 1-octet Subtype field, and a 2-octet reserved field.  The
   Subtype values used in EAP-AKA are defined in Section 11.  The
   formats of the EAP header and the EAP-AKA header are 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Subtype    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The rest of the Type-Data, immediately following the EAP-AKA header,
   consists of attributes that are encoded in Type, Length, Value
   format.  The figure below shows the generic format of an attribute.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Attribute Type |    Length     | Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Attribute Type

         Indicates the particular type of attribute.  The attribute type
         values are listed in Section 11.

   Length

         Indicates the length of this attribute in multiples of 4 bytes.
         The maximum length of an attribute is 1024 bytes.  The length
         includes the Attribute Type and Length bytes.

   Value

         The particular data associated with this attribute.  This field
         is always included and it is two or more bytes in length.  The
         type and length fields determine the format and length of the
         value field.

   Attributes numbered within the range 0 through 127 are called
   non-skippable attributes.  When an EAP-AKA peer encounters a
   non-skippable attribute type that the peer does not recognize, the
   peer MUST send the EAP-Response/AKA-Client-Error packet, and the
   authentication exchange terminates.  If an EAP-AKA server encounters
   a non-skippable attribute that the server does not recognize, then
   the server sends EAP-Request/AKA-Notification packet with an

   AT_NOTIFICATION code that implies general failure ("General failure
   after authentication" (0), or "General failure" (16384), depending on
   the phase of the exchange), and the authentication exchange
   terminates.

   When an attribute numbered in the range 128 through 255 is
   encountered but not recognized, that particular attribute is ignored,
   but the rest of the attributes and message data MUST still be
   processed.  The Length field of the attribute is used to skip the
   attribute value when searching for the next attribute.  These
   attributes are called skippable attributes.

   Unless otherwise specified, the order of the attributes in an EAP-AKA
   message is insignificant, and an EAP-AKA implementation should not
   assume a certain order will be used.

   Attributes can be encapsulated within other attributes.  In other
   words, the value field of an attribute type can be specified to
   contain other attributes.

8.2.  Protocol Extensibility

   EAP-AKA can be extended by specifying new attribute types.  If
   skippable attributes are used, it is possible to extend the protocol
   without breaking old implementations.  As specified in Section 10.13,
   if new attributes are specified for EAP-Request/AKA-Identity or
   EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to
   integrity protect the new attributes.

   When specifying new attributes, it should be noted that EAP-AKA does
   not support message fragmentation.  Hence, the sizes of the new
   extensions MUST be limited so that the maximum transfer unit (MTU) of
   the underlying lower layer is not exceeded.  According to [RFC3748],
   lower layers must provide an EAP MTU of 1020 bytes or greater, so any
   extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes.

   EAP-AKA packets do not include a version field.  However, should
   there be a reason to revise this protocol in the future, new
   non-skippable or skippable attributes could be specified in order to
   implement revised EAP-AKA versions in a backward-compatible manner.
   It is possible to introduce version negotiation in the
   EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by
   specifying new skippable attributes.

9.  Messages

   This section specifies the messages used in EAP-AKA.  It specifies
   when a message may be transmitted or accepted, which attributes are
   allowed in a message, which attributes are required in a message, and
   other message-specific details.  Message format is specified in
   Section 8.1.

9.1.  EAP-Request/AKA-Identity

   The EAP/AKA-Identity roundtrip MAY be used for obtaining the peer
   identity from the server.  As discussed in Section 4.1, several
   AKA-Identity rounds may be required in order to obtain a valid peer
   identity.

   The server MUST include one of the following identity requesting
   attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ.
   These three attributes are mutually exclusive, so the server MUST NOT
   include more than one of the attributes.

   If the server has previously issued an EAP-Request/AKA-Identity
   message with the AT_PERMANENT_ID_REQ attribute, and if the server has
   received a response from the peer, then the server MUST NOT issue a
   new EAP-Request/AKA-Identity packet.

   If the server has previously issued an EAP-Request/AKA-Identity
   message with the AT_FULLAUTH_ID_REQ attribute, and if the server has
   received a response from the peer, then the server MUST NOT issue a
   new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or
   AT_FULLAUTH_ID_REQ attributes.

   If the server has previously issued an EAP-Request/AKA-Identity
   message with the AT_ANY_ID_REQ attribute, and if the server has
   received a response from the peer, then the server MUST NOT issue a
   new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ.

   This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.

9.2.  EAP-Response/AKA-Identity

   The peer sends EAP-Response/AKA-Identity in response to a valid
   EAP-Request/AKA-Identity from the server.

   The peer MUST include the AT_IDENTITY attribute.  The usage of
   AT_IDENTITY is defined in Section 4.1.

   This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.

9.3.  EAP-Request/AKA-Challenge

   The server sends the EAP-Request/AKA-Challenge on full authentication
   after successfully obtaining the subscriber identity.

   The AT_RAND attribute MUST be included.

   AT_MAC MUST be included.  In EAP-Request/AKA-Challenge, there is no
   message-specific data covered by the MAC, see Section 10.15.

   The AT_RESULT_IND attribute MAY be included.  The usage of this
   attribute is discussed in Section 6.2.

   The AT_CHECKCODE attribute MAY be included, and in certain cases
   specified in Section 10.13, it MUST be included.

   The EAP-Request/AKA-Challenge packet MAY include encrypted attributes
   for identity privacy and for communicating the next re-authentication
   identity.  In this case, the AT_IV and AT_ENCR_DATA attributes are
   included (Section 10.12).

   The plaintext of the AT_ENCR_DATA value field consists of nested
   attributes.  The nested attributes MAY include AT_PADDING (as
   specified in Section 10.12).  If the server supports identity privacy
   and wants to communicate a pseudonym to the peer for the next full
   authentication, then the nested encrypted attributes include the
   AT_NEXT_PSEUDONYM attribute.  If the server supports
   re-authentication and wants to communicate a fast re-authentication
   identity to the peer, then the nested encrypted attributes include
   the AT_NEXT_REAUTH_ID attribute.  Later versions of this protocol MAY
   specify additional attributes to be included within the encrypted
   data.

   When processing this message, the peer MUST process AT_RAND and
   AT_AUTN before processing other attributes.  Only if these attributes
   are verified to be valid, the peer derives keys and verifies AT_MAC.
   The operation in case an error occurs is specified in Section 6.3.1.

9.4.  EAP-Response/AKA-Challenge

   The peer sends EAP-Response/AKA-Challenge in response to a valid
   EAP-Request/AKA-Challenge.

   Sending this packet indicates that the peer has successfully
   authenticated the server and that the EAP exchange will be accepted
   by the peer's local policy.  Hence, if these conditions are not met,
   then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer
   MUST send EAP-Response/AKA-Client-Error.

   The AT_MAC attribute MUST be included.  In
   EAP-Response/AKA-Challenge, there is no message-specific data covered
   by the MAC, see Section 10.15.

   The AT_RES attribute MUST be included.

   The AT_CHECKCODE attribute MAY be included, and in certain cases
   specified in Section 10.13, it MUST be included.

   The AT_RESULT_IND attribute MAY be included, if it was included in
   EAP-Request/AKA-Challenge.  The usage of this attribute is discussed
   in Section 6.2.

   Later versions of this protocol MAY make use of the AT_ENCR_DATA and
   AT_IV attributes in this message to include encrypted (skippable)
   attributes.  The EAP server MUST process EAP-Response/AKA-Challenge
   messages that include these attributes even if the server did not
   implement these optional attributes.

9.5.  EAP-Response/AKA-Authentication-Reject

   The peer sends the EAP-Response/AKA-Authentication-Reject packet if
   it does not accept the AUTN parameter.  This version of the protocol
   does not specify any attributes for this message.  Future versions of
   the protocol MAY specify attributes for this message.

   The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
   this message.

9.6.  EAP-Response/AKA-Synchronization-Failure

   The peer sends the EAP-Response/AKA-Synchronization-Failure, when the
   sequence number in the AUTN parameter is incorrect.

   The peer MUST include the AT_AUTS attribute.  Future versions of the
   protocol MAY specify other additional attributes for this message.

   The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
   this message.

9.7.  EAP-Request/AKA-Reauthentication

   The server sends the EAP-Request/AKA-Reauthentication message if it
   wants to use fast re-authentication, and if it has received a valid
   fast re-authentication identity in EAP-Response/Identity or
   EAP-Response/AKA-Identity.

   The AT_MAC attribute MUST be included.  No message-specific data is
   included in the MAC calculation, see Section 10.15.

   The AT_RESULT_IND attribute MAY be included.  The usage of this
   attribute is discussed in Section 6.2.

   The AT_CHECKCODE attribute MAY be included, and in certain cases
   specified in Section 10.13, it MUST be included.

   The AT_IV and AT_ENCR_DATA attributes MUST be included.  The
   plaintext consists of the following nested encrypted attributes,
   which MUST be included: AT_COUNTER and AT_NONCE_S.  In addition, the
   nested encrypted attributes MAY include the following attributes:
   AT_NEXT_REAUTH_ID and AT_PADDING.

9.8.  EAP-Response/AKA-Reauthentication

   The client sends the EAP-Response/AKA-Reauthentication packet in
   response to a valid EAP-Request/AKA-Reauthentication.

   The AT_MAC attribute MUST be included.  For
   EAP-Response/AKA-Reauthentication, the MAC code is calculated over
   the following data:  EAP packet| NONCE_S.  The EAP packet is
   represented as specified in Section 8.1.  It is followed by the
   16-byte NONCE_S value from the server's AT_NONCE_S attribute.

   The AT_CHECKCODE attribute MAY be included, and in certain cases
   specified in Section 10.13, it MUST be included.

   The AT_IV and AT_ENCR_DATA attributes MUST be included.  The nested
   encrypted attributes MUST include the AT_COUNTER attribute.  The
   AT_COUNTER_TOO_SMALL attribute MAY be included in the nested
   encrypted attributes, and it is included in cases specified in
   Section 5.  The AT_PADDING attribute MAY be included.

   The AT_RESULT_IND attribute MAY be included, if it was included in
   EAP-Request/AKA-Reauthentication.  The usage of this attribute is
   discussed in Section 6.2.

   Sending this packet without AT_COUNTER_TOO_SMALL indicates that the
   peer has successfully authenticated the server and that the EAP
   exchange will be accepted by the peer's local policy.  Hence, if
   these conditions are not met, then the peer MUST NOT send
   EAP-Response/AKA-Reauthentication, but the peer MUST send
   EAP-Response/ AKA-Client-Error.

9.9.  EAP-Response/AKA-Client-Error

   The peer sends EAP-Response/AKA-Client-Error in error cases, as
   specified in Section 6.3.1.

   The AT_CLIENT_ERROR_CODE attribute MUST be included.  The AT_MAC,
   AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet.

9.10.  EAP-Request/AKA-Notification

   The usage of this message is specified in Section 6.

   The AT_NOTIFICATION attribute MUST be included.

   The AT_MAC attribute MUST be included if the P bit of the
   AT_NOTIFICATION code is set to zero, and MUST NOT be included if the
   P bit is set to one.  The P bit is discussed in Section 6.

   No message-specific data is included in the MAC calculation.  See
   Section 10.15.

   If EAP-Request/AKA-Notification is used on a fast re-authentication
   exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
   AT_COUNTER is used for replay protection.  In this case, the
   AT_ENCR_DATA and AT_IV attributes MUST be included, and the
   encapsulated plaintext attributes MUST include the AT_COUNTER
   attribute.  The counter value included in AT_COUNTER MUST be the same
   as in the EAP-Request/AKA-Reauthentication packet on the same fast
   re-authentication exchange.

9.11.  EAP-Response/AKA-Notification

   The usage of this message is specified in Section 6.  This packet is
   an acknowledgement of EAP-Request/AKA-Notification.

   The AT_MAC attribute MUST be included in cases when the P bit of the
   notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification
   is set to zero, and MUST NOT be included in cases when the P bit is
   set to one.  The P bit is discussed in Section 6.

   If EAP-Request/AKA-Notification is used on a fast re-authentication
   exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
   AT_COUNTER is used for replay protection.  In this case, the
   AT_ENCR_DATA and AT_IV attributes MUST be included, and the
   encapsulated plaintext attributes MUST include the AT_COUNTER
   attribute.  The counter value included in AT_COUNTER MUST be the same
   as in the EAP-Request/AKA-Reauthentication packet on the same fast
   re-authentication exchange.