📄 draft-haverinen-pppext-eap-sim-05.txt
字号:
| EAP-Response/SIM/Start |
| (Includes AT_IDENTITY and AT_NONCE_MT) |
|------------------------------------------------------>|
| |
If the AT_IDENTITY attribute contains a valid cleartext identity or
a pseudonym identity that the EAP server is able to decode to the
cleartext identity, then the authentication sequence proceeds as
usual with the EAP Server issuing the EAP-Request/SIM/Challenge
message. The operation in the case when the AT_IDENTITY attribute
contains a pseudonym that the EAP server fails to decode is
specified in Section 5.
5. Identity Privacy Support
In the very first connection to an EAP server, the client always
transmits the cleartext identity (IMSI) in the EAP-Response/Identity
packet or in the AT_IDENTITY attribute. In subsequent connections,
the optional identity privacy (anonymity) support can be used to
hide the IMSI and to make the connections unlinkable to a passive
eavesdropper.
The EAP-Request/SIM/Challenge message MAY include an encrypted
pseudonym in the value field of the AT_ENCR_DATA attribute. The
AT_IV and AT_MAC attributes are also used to transport the pseudonym
to the client, as described in Section 11. Because the identity
privacy support is optional to implement, the client MAY ignore the
AT_IV, AT_ENCR_DATA, and AT_MAC attributes and always transmit the
Haverinen Expires in six months [Page 6]
Internet Draft EAP SIM Authentication June 2002
IMSI in the EAP-Response/Identity packet and in the AT_IDENTITY
attribute.
On receipt of the EAP-Request/SIM/Challenge, the client verifies the
AT_MAC attribute before looking at the AT_ENCR_DATA attribute. If
the AT_MAC is invalid, then the client MUST silently discard the EAP
packet. If the AT_MAC attribute is valid, then the client MAY
decrypt the encrypted data in AT_ENCR_DATA and use the obtained
pseudonym used in the next authentication.
The EAP server produces pseudonyms in an implementation-dependent
manner. Please see [4] for examples on how to produce pseudonyms.
Only the EAP server needs to be able to map the pseudonym to the
cleartext identity. Regardless of construction method, the pseudonym
MUST conform to the grammar specified for the username portion of an
NAI. The EAP SIM server MAY produce pseudonyms that begin with a
leading "1" character in order to be able to use the leading
character as a hint in EAP method negotiation during next
authentication.
On the next connection to the EAP server, the client MAY transmit
the received pseudonym in the first EAP-Response/Identity packet.
The client concatenates the received pseudonym with the "@"
character and the NAI realm portion. The client MUST use the same
realm portion that it used in the connection when it received the
pseudonym. If the EAP server successfully decodes the pseudonym
received in the EAP-Response/Identity packet to a known client
identity (IMSI), the authentication proceeds with the EAP-
Request/SIM/Start message as usual.
If the EAP server requests the client to include the AT_IDENTITY
attribute in the EAP-Response/SIM/Start packet, as specified in
Section 4, the client MAY transmit the received pseudonym in the
AT_IDENTITY packet. If the EAP server successfully decodes the
pseudonym to a known identity, then the authentication proceeds with
the EAP-Request/SIM/Challenge packet as usual.
If the EAP server fails to decode the pseudonym to a known identity,
then the EAP server requests the regular IMSI (non-pseudonym
identity) by including the AT_PERMANENT_IDENTITY_REQ attribute
(Section 9) in the EAP-Request/SIM/Start message.
The EAP server issues the EAP-Request/SIM/Start message also in the
case when it received the undecodable pseudonym in AT_IDENTITY
included the EAP-Response/SIM/Start packet. In this case, there are
two EAP/SIM/Start round trips. The authentication sequence proceeds
similarly in both cases. For example, AT_NONCE_MT is always included
in the EAP-Response/SIM/Start packet, even if it was already
transmitted in the previous EAP-Response/SIM/Start. The first
EAP/SIM/Start round trip is ignored. The NONCE_MT value included in
the second EAP-Response/SIM/Start packet is used in all
calculations. The EAP/SIM client MAY use the same NONCE_MT value in
both EAP-Response/SIM/Start packets.
Haverinen Expires in six months [Page 7]
Internet Draft EAP SIM Authentication June 2002
The value field of the AT_PERMANENT_IDENTITY_REQ does not contain
any data but the attribute is included to request the client to
include the AT_PERMANENT_IDENTITY attribute (Section 10) in the EAP-
Response/SIM/Start message. The AT_PERMANENT_IDENTITY attribute
contains the client's identity in the clear.
Please note that the EAP/SIM client and the EAP/SIM server only
process the AT_PERMANENT_IDENTITY_REQ and AT_PERMANENT_IDENTITY
attributes and entities that only pass through EAP packets do not
process these attributes. Hence, if the EAP server is not co-located
in the authenticator, then the authenticator and other intermediate
AAA elements (such as possible AAA proxy servers) will continue to
refer to the client with the original pseudonym identity from the
EAP-Response/Identity packet regardless if the decoding fails in the
EAP server.
The figure below illustrates the case when the EAP server fails to
decode the pseudonym included in the EAP-Response/Identity packet.
Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym. |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (Includes AT_PERMANENT_IDENTITY_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (Includes AT_PERMANENT_IDENTITY and AT_NONCE_MT) |
|------------------------------------------------------>|
| |
After the EAP-Response/SIM/Start message, the authentication
sequence proceeds as usual with the EAP Server issuing the EAP-
Request/SIM/Challenge message.
The figure below illustrates the case when the EAP server fails to
decode the pseudonym included in the AT_IDENTITY attribute.
Haverinen Expires in six months [Page 8]
Internet Draft EAP SIM Authentication June 2002
Client Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP/SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (Includes AT_IDENTITY_REQ) |
|<------------------------------------------------------|
| |
| |
|EAP-Response/SIM/Start |
|(Includes a pseudonym AT_IDENTITY and AT_NONCE_MT) |
|------------------------------------------------------>|
| |
| |
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (Includes AT_PERMANENT_IDENTITY_REQ) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (Includes AT_PERMANENT_IDENTITY and AT_NONCE_MT) |
|------------------------------------------------------>|
| |
After the latter EAP-Response/SIM/Start message, the authentication
sequence proceeds as usual with the EAP Server issuing the EAP-
Request/SIM/Challenge message.
If the client believes that the server should be able to decode the
pseudonym identity, the client MAY refuse to send a clear text
identity. In this case, the client silently ignores the EAP-
Request/SIM/Start packet that contains AT_PERMANENT_IDENTITY_REQ.
This is necessary in some environments to prevent Man-in-the-Middle
attackers from claiming to be servers that do not recognize the
pseudonym, in an effort to find out the true identity of the user.
6. Message Format
The Type-Data of the EAP/SIM packets begins with a 1-octet Subtype
field, which is followed by a 2-octet reserved field. The rest of
the Type-Data consists of attributes that are encoded in Type,
Length, Value format. The figure below shows the generic format of
an attribute.
Haverinen Expires in six months [Page 9]
Internet Draft EAP SIM Authentication June 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
Indicates the particular type of attribute. The attribute type
values are listed in Section 16.
Length
Indicates the length of this attribute in multiples of four
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.
When an attribute numbered within the range 0 through 127 is
encountered but not recognized, the EAP/SIM message containing that
attribute MUST be silently discarded. These attributes are called
non-skippable attributes.
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 in searching for the next attribute. These
attributes are called skippable attributes.
EAP/SIM packets do not include a version field. However, should
there be reason to revise this protocol in the future, new non-
skippable or skippable attributes could be specified in order to
implement revised EAP/SIM versions in a backward-compatible manner.
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.
Haverinen Expires in six months [Page 10]
Internet Draft EAP SIM Authentication June 2002
7. Message Integrity and Privacy Protection
This section specifies EAP/SIM attributes for attribute encryption
and EAP/SIM message integrity protection.
Because the K_encr and K_int keys derived from the RAND challenges
(as specified in Section 15) are required to process the integrity
protection and encryption attributes, these attributes can only be
used in the EAP-Request/SIM/Challenge message and any EAP/SIM
messages sent after EAP-Requets/SIM/Challenge. For example, these
attributes cannot be used in EAP-Request/SIM/Start.
7.1. AT_MAC Attribute
The AT_MAC attribute can be used for EAP/SIM message integrity
protection. Whenever AT_ENCR_DATA (Section 7.2) is included in an
EAP message, it MUST be followed (not necessarily immediately) by an
AT_MAC attribute. Messages that do not meet this condition MUST be
silently discarded.
The value field of the AT_MAC attribute contains two reserved bytes
followed by a message authentication code (MAC). The MAC is
calculated over the whole EAP packet with the exception that the
value field of the MAC attribute is set to zero when calculating the
MAC. The reserved bytes are set to zero when sending and ignored on
reception. 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 [11] 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 integrity protection key (K_int)
used in the calculation of the MAC is specified in Section 15.
7.2. AT_IV and AT_ENCR_DATA Attributes
AT_IV and AT_ENCR_DATA attributes can be optionally used to transmit
encrypted information between the EAP/SIM client 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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -