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