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 may be 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-SIM peer encounters a
non-skippable attribute that the peer does not recognize, the peer
MUST send the EAP-Response/SIM/Client-Error packet, which terminates
the authentication exchange. If an EAP-SIM server encounters a
non-skippable attribute that the server does not recognize, then the
server sends the EAP-Request/SIM/Notification packet with an
AT_NOTIFICATION code, which implies general failure ("General failure
after authentication" (0), or "General failure" (16384), depending on
the phase of the exchange), which terminates the authentication
exchange.
Attributes within the range of 128 through 255 are called skippable
attributes. When a skippable attribute is encountered and is not
recognized, it is ignored. 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 in searching for the next attribute.
Unless otherwise specified, the order of the attributes in an EAP-SIM
message is insignificant and an EAP-SIM implementation should not
assume a certain order to 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-SIM can be extended by specifying new attribute types. If
skippable attributes are used, it is possible to extend the protocol
without breaking old implementations.
However, any new attributes added to the EAP-Request/SIM/Start or
EAP-Response/SIM/Start packets would not be integrity-protected.
Therefore, these messages MUST NOT be extended in the current version
of EAP-SIM. If the list of supported EAP-SIM versions in the
AT_VERSION_LIST does not include versions other than 1, then the
server MUST NOT include attributes other than those specified in this
document in the EAP-Request/SIM/Start message. Note that future
versions of this protocol might specify new attributes for
EAP-Request/SIM/Start and still support version 1 of the protocol.
In this case, the server might send an EAP-Request/SIM/Start message
that includes new attributes and indicates support for protocol
version 1 and other versions in the AT_VERSION_LIST attribute. If
the peer selects version 1, then the peer MUST ignore any other
attributes included in EAP-Request/SIM/Start, other than those
specified in this document. If the selected EAP-SIM version in
peer’s AT_SELECTED_VERSION is 1, then the peer MUST NOT include other
attributes aside from those specified in this document in the
EAP-Response/SIM/Start message.
When specifying new attributes, it should be noted that EAP-SIM 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-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes.
Because EAP-SIM supports version negotiation, new versions of the
protocol can also be specified by using a new version number.
9. Messages
This section specifies the messages used in EAP-SIM. 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. The general message format is
specified in Section 8.1.
9.1. EAP-Request/SIM/Start
In full authentication the first SIM-specific EAP Request is
EAP-Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two
purposes. In full authentication this packet is used to request the
peer to send the AT_NONCE_MT attribute to the server. In addition,
as specified in Section 4.2, the Start round trip may be used by the
server for obtaining the peer identity. As discussed in Section 4.2,
several Start rounds may be required to obtain a valid peer identity.
The server MUST always include the AT_VERSION_LIST attribute.
The server MAY include one of the following identity-requesting
attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or
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 received a response from the peer, it MUST NOT
issue a new EAP-Request/SIM/Start packet if it has previously issued
an EAP-Request/SIM/Start message either without any identity
requesting attributes or with the AT_PERMANENT_ID_REQ attribute.
If the server has received a response from the peer, it MUST NOT
issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or
AT_FULLAUTH_ID_REQ attributes if it has previously issued an
EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute.
If the server has received a response from the peer, it MUST NOT
issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ
attribute if the server has previously issued an
EAP-Request/SIM/Start message with the AT_ANY_ID_REQ attribute.
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
9.2. EAP-Response/SIM/Start
The peer sends EAP-Response/SIM/Start in response to a valid
EAP-Request/SIM/Start from the server.
If and only if the server’s EAP-Request/SIM/Start includes one of the
identity-requesting attributes, then the peer MUST include the
AT_IDENTITY attribute. The usage of AT_IDENTITY is defined in
Section 4.2.
The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY
with a fast re-authentication identity is present for fast
re-authentication. AT_NONCE_MT MUST be included in all other cases
(full authentication).
The AT_SELECTED_VERSION attribute MUST NOT be included if the
AT_IDENTITY attribute with a fast re-authentication identity is
present for fast re-authentication. In all other cases,
AT_SELECTED_VERSION MUST be included (full authentication). This
attribute is used in version negotiation, as specified in
Section 4.1.
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
9.3. EAP-Request/SIM/Challenge
The server sends the EAP-Request/SIM/Challenge after receiving a
valid EAP-Response/SIM/Start that contains AT_NONCE_MT and
AT_SELECTED_VERSION, and after successfully obtaining the subscriber
identity.
The AT_RAND attribute MUST be included.
The AT_RESULT_IND attribute MAY be included. The usage of this
attribute is discussed in Section 6.2.
The AT_MAC attribute MUST be included. For
EAP-Request/SIM/Challenge, the MAC code is calculated over the
following data:
EAP packet| NONCE_MT
The EAP packet is represented as specified in Section 8.1. It is
followed by the 16-byte NONCE_MT value from the peer’s AT_NONCE_MT
attribute.
The EAP-Request/SIM/Challenge packet MAY include encrypted attributes
for identity privacy and for communicating the next fast
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.
When processing this message, the peer MUST process AT_RAND before
processing other attributes. Only if AT_RAND is 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/SIM/Challenge
The peer sends EAP-Response/SIM/Challenge in response to a valid
EAP-Request/SIM/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/SIM/Challenge, but the peer
MUST send EAP-Response/SIM/Client-Error.
The AT_MAC attribute MUST be included. For EAP-
Response/SIM/Challenge, the MAC code is calculated over the following
data:
EAP packet| n*SRES
The EAP packet is represented as specified in Section 8.1. The EAP
packet bytes are immediately followed by the two or three SRES values
concatenated, denoted above with the notation n*SRES. The SRES
values are used in the same order as the corresponding RAND
challenges in the server’s AT_RAND attribute.
The AT_RESULT_IND attribute MAY be included if it was included in
EAP-Request/SIM/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/SIM/Challenge
messages that include these attributes even if the server did not
implement these optional attributes.
9.5. EAP-Request/SIM/Re-authentication
The server sends the EAP-Request/SIM/Re-authentication 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/SIM/Start.
AT_MAC MUST be included. No message-specific data is included in the
MAC calculation. See Section 10.14.
The AT_RESULT_IND attribute MAY be included. The usage of this
attribute is discussed in Section 6.2.
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.6. EAP-Response/SIM/Re-authentication
The client sends the EAP-Response/SIM/Re-authentication packet in
response to a valid EAP-Request/SIM/Re-authentication.
The AT_MAC attribute MUST be included. For
EAP-Response/SIM/Re-authentication, 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_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/SIM/Re-authentication. 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/SIM/Re-authentication, but the peer MUST send
EAP-Response/SIM/Client-Error.
9.7. EAP-Response/SIM/Client-Error
The peer sends EAP-Response/SIM/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.8. EAP-Request/SIM/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
notification code in AT_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.
No message-specific data is included in the MAC calculation. See
Section 10.14.
If EAP-Request/SIM/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/SIM/Re-authentication packet on the same fast
re-authentication exchange.
9.9. EAP-Response/SIM/Notification
The usage of this message is specified in Section 6. This packet is
an acknowledgement of EAP-Request/SIM/Notification.
The AT_MAC attribute MUST be included in cases when the P bit of the
notification code in AT_NOTIFICATION of EAP-Request/SIM/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.
No message-specific data is included in the MAC calculation, see
Section 10.14.
If EAP-Request/SIM/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/SIM/Re-authentication 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 the IANA considerations
section of the EAP-AKA specification [EAP-AKA].
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/SIM/Start, (2) EAP-Response/SIM/Start, (3)
EAP-Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5)
EAP-Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7)
EAP-Response/SIM/Client-Error, (8) EAP-Request/SIM/Re-authentication,
and (9) EAP-Response/SIM/Re-authentication. The column denoted with
"Encr" indicates whether the attribute is a nested attribute that
MUST be included within AT_ENCR_DATA, and the column denoted with
"Skip" indicates whether the attribute is a skippable attribute.
"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
future versions of the protocol.
Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip
AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N
AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N
AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N
AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N
AT_RAND 0 0 1 0 0 0 0 0 0 N N
AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y
AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y
AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 N Y
AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 N Y
AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 Y N
AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 N Y
AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N
AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 Y N
AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N
AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N
AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N
AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N N
It should be noted that attributes AT_PERMANENT_ID_REQ,
AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive; only
one of them can be included at the same time. If one of the
attributes AT_IV and AT_ENCR_DATA is included, then both of the
attributes MUST be included.
10.2. AT_VERSION_LIST
The format of the AT_VERSION_LIST 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_VERSION_L..| Length | Actual Version List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 | Supported Version 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is used in version negotiation, as specified in
Section 4.1. The attribute contains the version numbers supported by
the EAP-SIM server. The server MUST only include versions that it
implements and that are allowed in its security policy. The server
SHOULD list the versions in the order of preference, with the most
preferred versions listed first. At least one version number MUST be
included. The version number for the protocol described in this
document is one (0001 hexadecimal).
The value field of this attribute begins with 2-byte Actual Version
List Length, which specifies the length of the Version List in bytes,
not including the Actual Version List Length attribute length. This
field is followed by the list of the versions supported by the
server, which each have a length of 2 bytes. For example, if there
is only one supported version, then the Actual Version List Length is
2. Because the length of the attribute must be a multiple of 4
bytes, the sender pads the value field with zero bytes when
necessary.
10.3. AT_SELECTED_VERSION
The format of the AT_SELECTED_VERSION 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_SELECTED...| Length = 1 | Selected Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is used in version negotiation, as specified in
Section 4.1. The value field of this attribute contains a two-byte
version number, which indicates the EAP-SIM version that the peer
wants to use.
10.4. AT_NONCE_MT
The format of the AT_NONCE_MT 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_MT | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NONCE_MT |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the NONCE_MT attribute contains two reserved bytes
followed by a random number freshly generated by the peer (16 bytes
long) for this EAP-SIM authentication exchange. The random number is
used as a seed value for the new keying material. The reserved bytes
are set to zero upon sending and ignored upon reception.
The peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM
authentication exchange. If an EAP-SIM exchange includes several
EAP/SIM/Start rounds, then the peer SHOULD use the same NONCE_MT
value in all EAP-Response/SIM/Start packets. The peer SHOULD use a
good source of randomness to generate NONCE_MT. Please see [RFC4086]
for more information about generating random numbers for security
applications.
10.5. 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.2. The
value field contains only two reserved bytes, which are set to zero
on sending and ignored on reception.
10.6. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+