draft-haverinen-pppext-eap-sim-11.txt
来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,303 行 · 第 1/5 页
TXT
1,303 行
SIM
Subscriber Identity Module. The SIM is an application
traditionally resident on smart cards distributed by GSM
operators.
3. Overview
Figure 1 shows an overview of the EAP/SIM full authentication
procedure. This version of EAP/SIM exchange uses three roundtrips to
authenticate the user and generate keying material. In this
document, the term EAP Server refers to the network element that
terminates the EAP protocol. The Authenticator typically
communicates with the user's EAP server using an AAA protocol. The
AAA communications is not shown in the figure.
The first EAP Request issued by the Authenticator is EAP-
Request/Identity. The client's response includes either the user's
International Mobile Subscriber Identity (IMSI) or a temporary
identity (pseudonym), as specified in Section 5.3.
Following the client's EAP-Response/Identity packet, the client
receives EAP Requests of type 18 (SIM) from the Authenticator and
sends the corresponding EAP Responses. The EAP packets that are of
the Type SIM also have a Subtype field. On full authentication, the
first EAP-Request/SIM packet is of the Subtype 10 (Start). EAP SIM
packets encapsulate parameters in attributes, encoded in a Type,
Length, Value format. The packet format and the use of attributes
are specified in Section 7.
The EAP-Request/SIM/Start packet contains the list of EAP/SIM
version supported by the Authenticator in the AT_VERSION_LIST
attribute. This packet may also include attributes for requesting
the subscriber identity, as specified in Section 5.3.
Haverinen and Salowey Expires in six months [Page 5]
Internet Draft EAP SIM Authentication June 2003
The client responds to EAP-Request/SIM/Start with the EAP-
Response/SIM/Start packet, which includes the AT_NONCE_MT attribute
that contains a random number NONCE_MT, chosen by the client, and
the AT_SELECTED_VERSION attribute that contains the version number
selected by the client. The version negotiation is protected by
including the version list and the selected version in the
calculation of keying material (Section 17). The client MUST NOT
reuse the NONCE_MT value from previous sessions but the client MUST
choose it freshly for each EAP/SIM authentication exchange. The
client SHOULD use a good source of randomness to generate NONCE_MT.
In this document, we assume that the EAP server is implemented on
the AAA server and has an interface to the GSM network, so it
operates as a gateway between the Internet AAA network and the GSM
authentication infrastructure. After receiving the EAP
Response/SIM/Start, the EAP server obtains n GSM triplets from the
user's home operator's Authentication Centre (AuC) on the GSM
network, where n = 1, n = 2 or n = 3. From the triplets, the EAP
server derives the keying material, as specified in Section 17.
The next EAP Request the EAP Server issues is of the type SIM and
subtype Challenge (11). It contains the RAND challenges and a
message authentication code attribute AT_MAC to cover the
challenges.
The EAP server MUST NOT reuse the RAND values (triplets) from
previous successful sessions but the server MUST obtain fresh RANDs
for each EAP/SIM authentication exchange. However, if client
authentication fails, the server MAY reuse the RANDs in the next
authentication attempt.
On receipt of the EAP-Request/SIM/Challenge message, the client runs
the GSM authentication algorithm and calculates a copy of the
message authentication code. The client then verifies that the
calculated MAC equals the received MAC. If the MAC's do not match,
then the client silently ignores the EAP packet and does not send
any authentication values to the network. Eventually, if another
EAP-Request/SIM/Challenge packet with a valid AT_MAC is not
received, the connection establishment will time out.
Since the RAND's given to a client are accompanied with the message
authentication code AT_MAC, and since the client's NONCE_MT value
contributes to AT_MAC, the client is able to verify that the EAP SIM
message is fresh (not a replay) and that the sender possesses valid
GSM triplets for the subscriber.
If all checks out, the client responds with the EAP-
Response/SIM/Challenge, containing the AT_MAC attribute that covers
the client's SRES response values (Section 12). The EAP server
verifies that the MAC is correct and sends the EAP-Success packet,
indicating that the authentication was successful. The EAP server
may also include derived keying material in the message it sends to
the Authenticator.
Haverinen and Salowey Expires in six months [Page 6]
Internet Draft EAP SIM Authentication June 2003
The EAP-Request/SIM/Challenge, EAP-Response/SIM/Challenge, or the
packets used on re-authentication may optionally include the
AT_CHECKCODE attribute, which enables the protocol peers to ensure
the integrity of the EAP-Request/SIM/Start and EAP-
Response/SIM/Start packets. AT_CHECKCODE is specified in Section
8.2.
Client Authenticator
| |
| EAP-Request/Identity |
|<---------------------------------------------------------|
| |
| EAP-Response/Identity |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Start |
| (AT_VERSION_LIST) |
|<---------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_NONCE_MT, AT_SELECTED_VERSION) |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Challenge |
| (AT_RAND, AT_MAC) |
|<---------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs GSM algorithms, | |
| verifies AT_MAC and derives | |
| session keys | |
+-------------------------------------+ |
| |
| EAP-Response/SIM/Challenge |
| (AT_MAC) |
|--------------------------------------------------------->|
| |
| |
| EAP-Success |
|<---------------------------------------------------------|
| |
Figure 1 EAP/SIM full authentication procedure
EAP SIM also includes a separate re-authentication procedure, which
does not make use of the A3/A8 algorithms or the GSM infrastructure.
Re-authentication is based on keys derived on full authentication.
4. Version Negotiation
EAP/SIM includes version negotiation so as to allow future
developments in the protocol. The version negotiation is performed
on full authentication and it uses two attributes, AT_VERSION_LIST
Haverinen and Salowey Expires in six months [Page 7]
Internet Draft EAP SIM Authentication June 2003
(Section 9), which the server includes in EAP-Request/SIM/Start, and
AT_SELECTED_VERSION (Section 10), which the client includes in EAP-
Response/SIM/Start.
AT_VERSION_LIST includes the EAP/SIM versions supported by the
server. The server MUST only include versions that it implements and
that are allowed in its security policy. The versions are listed in
the order of preference, most preferred versions first. At least one
version number MUST be included. The version number for the protocol
described in this document is one (0x0001).
If AT_VERSION_LIST does not include a version that is implemented by
the client and allowed in the client's security policy, then the
client MUST silently ignore the EAP-Request/SIM/Start packet. If a
suitable version is included, then the client includes the
AT_SELECTED_VERSION attribute, containing the selected version, in
the EAP-Response/SIM/Start packet. The client MUST only indicate a
version that is included in AT_VERSION_LIST. If several versions are
acceptable, then the client SHOULD choose the version that occurs
first in the version list.
The version number list of AT_VERSION_LIST and the selected version
of AT_SELECTED_VERSION are included in the key derivation procedure
(Section 17). If an attacker modifies either one of these
attributes, then the client and the server will derive different
keying material. Because K_aut keys are different, the server and
client will calculate different AT_MAC values. Hence, the client
will detect that AT_MAC is incorrect and discard the EAP-
Request/SIM/Challenge packet. The authentication procedure will time
out.
5. Identity Management
5.1. User identity in EAP-Response/Identity
In the beginning of EAP authentication, the Authenticator issues the
EAP-Request/Identity packet to the client. The client responds with
EAP-Response/Identity, which contains the user's identity. The
formats of these packets are specified in [1].
GSM subscribers are identified with the International Mobile
Subscriber Identity (IMSI) [4]. The IMSI is composed of a three
digit Mobile Country Code (MCC), a two or three digit Mobile Network
Code (MNC) and a not more than 10 digit Mobile Subscriber
Identification Number (MSIN). In other words, the IMSI is a string
of not more than 15 digits. MCC and MNC uniquely identify the GSM
operator.
Internet AAA protocols identify users with the Network Access
Identifier (NAI) [5]. When used in a roaming environment, the NAI is
composed of a username and a realm, separated with "@"
(username@realm). The username portion identifies the subscriber
within the realm. The AAA nodes use the realm portion of the NAI to
Haverinen and Salowey Expires in six months [Page 8]
Internet Draft EAP SIM Authentication June 2003
route AAA requests to the correct AAA server. The realm name used in
this protocol MAY be chosen by the operator and it MAY a
configurable parameter in the EAP/SIM client implementation. In this
case, the client is typically configured with the NAI realm of the
home operator. Operators MAY reserve a specific realm name for
EAP/SIM users. This convention makes it easy to recognize that the
NAI identifies a GSM subscriber. Such reserved NAI realm may be
useful as a hint as to the first authentication method to use during
method negotiation.
There are three types of NAI username portions in EAP/SIM: non-
pseudonym permanent usernames, pseudonym usernames and re-
authentication usernames. The first two are only used on full
authentication and the last one only on re-authentication. When the
optional identity privacy support is not used, the non-pseudonym
permanent username is used.
The non-pseudonym permanent username MAY be derived from the IMSI.
In this case, the permanent username MUST be of the format "1imsi".
In other words, the first character of the username is the digit one
(ASCII value 0x31), followed by the IMSI. The IMSI is an ASCII
string that consists of not more than 15 decimal digits (ASCII
values between 0x30 and 0x39) as specified in [4].
The EAP server MAY use the leading "1" as a hint to try EAP/SIM as
the first authentication method during method negotiation, rather
than for example EAP/AKA. The EAP/SIM server MAY propose EAP/SIM
even if the leading character was not "1".
Alternatively, an implementation MAY choose a permanent username
that is not based on the IMSI. In this case the selection of the
username, its format, and its processing is a local matter. In this
case, the client implementation MUST NOT prepend any leading
characters to the username.
When the optional identity privacy support is used on full
authentication, the client MAY use the pseudonym received as part of
the previous full authentication sequence as the username portion of
the NAI, as specified in Section 5.3. The client MUST NOT modify the
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?