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