draft-haverinen-pppext-eap-sim-11.txt
来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,303 行 · 第 1/5 页
TXT
1,303 行
privacy is based on temporary identities, or pseudonyms, which are
equivalent to but separate from the Temporary Mobile Subscriber
Identities (TMSI) that are used on cellular networks. Please see
Section 19.1 for security considerations regarding identity privacy.
If identity privacy is not used or if the client does not have any
pseudonyms or re-authentication identities are available, the client
transmits the permanent identity in the EAP-Response/Identity packet
or in the AT_IDENTITY attribute.
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 and AT_ENCR_DATA attributes and always transmit the permanent
identity 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 on the next full authentication.
If the client does not receive a new pseudonym in the EAP-
Request/SIM/Challenge message, the client MAY use an old pseudonym
instead of the permanent identity on next full authentication.
The EAP server produces pseudonyms in an implementation-dependent
manner. Please see [7] for examples on how to produce pseudonyms.
Only the EAP server needs to be able to map the pseudonym to the
permanent identity. Regardless of construction method, the pseudonym
MUST conform to the grammar specified for the username portion of an
NAI.
In any case, it is necessary that permanent usernames and pseudonyms
are separate and recognizable from each other. It is also desirable
that EAP SIM and EAP AKA user names be recognizable from each other
as an aid for the server to which method to offer.
In general, it is the task of the EAP server and the policies of its
administrator to ensure sufficient separation in the usernames.
Pseudonyms, for instance, are both produced and used by the EAP
server. The EAP server MUST compose pseudonyms so that it can
recognize if a NAI username is an EAP SIM pseudonym. For instance,
when the usernames have been derived from the IMSI, the pseudonym
could begin with a leading "3" character.
On the next full authentication with 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 "@"
Haverinen and Salowey Expires in six months [Page 14]
Internet Draft EAP SIM Authentication June 2003
character and the NAI realm portion. The client selects the realm
name portion similarly as it select the realm name portion when
using the permanent identity. If the EAP server successfully decodes
the pseudonym received in the EAP-Response/Identity packet to a
known client permanent identity, the authentication proceeds with
the EAP-Request/SIM/Start message as usual.
Because the client may fail to save a pseudonym sent to in an EAP-
Request/SIM/Challenge, for example due to malfunction, the EAP
server SHOULD maintain at least one old pseudonym in addition to the
most recent pseudonym.
If the EAP server requests the client to include its identity in the
EAP-Response/SIM/Start packet, as specified in Section 5.2, the
client MAY transmit the received pseudonym in the AT_IDENTITY
attribute. 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 permanent identity (non-pseudonym
identity) by including the AT_PERMANENT_ID_REQ attribute (Section 9)
in the EAP-Request/SIM/Start message. Because another EAP server may
have generated the pseudonym using a different coding scheme, the
EAP server SHOULD use AT_PERMANENT_ID_REQ also in cases when it does
not recognize the format of the client identity.
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, an extra
EAP/SIM/Start round trip is required.
A received AT_PERMANENT_ID_REQ does not necessarily originate from
the valid network, but an active attacker may transmit an EAP-
Request/SIM/Start packet with an AT_PERMANENT_ID_REQ attribute to
the client, in an effort to find out the true identity of the user.
The client MAY silently discard any EAP-Request/SIM/Start messages
that include AT_PERMANENT_ID_REQ for a while in order to wait for an
EAP-Request/SIM/Start packet without AT_PERMANENT_ID_REQ. If the
valid network sent the message, the message will be retransmitted,
so the client can reconsider replying to the message when it
receives a retransmission.
Basically, there are two different policies that the client can
employ with regard to AT_PERMANENT_ID_REQ. A "conservative" client
assumes that the network is able to maintain pseudonyms robustly.
Therefore, if a conservative client has a pseudonym, the client
silently ignores the EAP packet with AT_PERMANENT_ID_REQ, because
the client believes that the valid network is able to decode the
pseudonym. (Alternatively, the conservative client may respond to
AT_PERMANENT_ID_REQ in certain circumstances, for example if the
pseudonym was received a long time ago.) The benefit of this policy
is that it protects the client against active attacks on anonymity.
Haverinen and Salowey Expires in six months [Page 15]
Internet Draft EAP SIM Authentication June 2003
On the other hand, a "liberal" client always accepts the
AT_PERMANENT_ID_REQ and responds with the permanent identity. The
benefit of this policy is that it works even if the valid network
sometimes loses pseudonyms and is not able to decode them to the
permanent identity.
Regardless how the identity is communicated to the server, the full
authentication message sequence and the attributes are the same in
all cases. For example, AT_NONCE_MT and AT_SELECTED_VERSION are
always included in the EAP-Response/SIM/Start packet on full
authentication, even if they were already transmitted in the
previous EAP-Response/SIM/Start. AT_VERSION_LIST is also included in
every EAP-Request/SIM/Start message. The values used on the last
EAP/SIM/Start round trip are used and the previous EAP/SIM/Start
round trips is ignored. (However, all EAP/SIM/Start rounds are taken
into account when calculating the checkcode for AT_CHECKCODE.
AT_CHECKCODE is specified in Section 8.2). The NONCE_MT value and
the version negotiation attributes included in the last EAP-
Response/SIM/Start packet are used in all calculations. The EAP/SIM
client MAY use the same NONCE_MT value in both EAP-
Response/SIM/Start packets.
The value field of the AT_PERMANENT_ID_REQ does not contain any data
but the attribute is included to request the client to include the
AT_IDENTITY attribute (Section 10) with the permanent authentication
identity in the EAP-Response/SIM/Start message. In this case, the
AT_IDENTITY attribute contains the client's permanent identity in
the clear.
Please note that the EAP/SIM client and the EAP/SIM server only
process the AT_IDENTITY attribute and entities that only pass
through EAP packets do not process this attribute. 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 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.
Haverinen and Salowey Expires in six months [Page 16]
Internet Draft EAP SIM Authentication June 2003
Client Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym. |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
If the server recognizes the permanent identity, then the
authentication sequence proceeds as usual with the EAP Server
issuing the EAP-Request/SIM/Challenge message.
If the server does not recognize the permanent identity, or if the
server is not able to continue the authentication exchange with the
client after receiving the permanent identity, then the server
issues the EAP Failure packet and the authentication exchange
terminates.
The figure below illustrates the case when the EAP server fails to
decode the pseudonym included in the AT_IDENTITY attribute.
Haverinen and Salowey Expires in six months [Page 17]
Internet Draft EAP SIM Authentication June 2003
Client Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP/SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
| |
| +------------------------------+
| | Server fails to decode the |
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?