RFC 4187
Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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
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.
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.
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 code11. 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.
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
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.
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
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.
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
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.
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.
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.
[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.
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.
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
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
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).