draft-arkko-pppext-eap-aka-14.txt
来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,459 行 · 第 1/5 页
TXT
1,459 行
Arkko & Haverinen Expires May 25, 2005 [Page 11]
Internet-Draft EAP-AKA Authentication November 2004
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms, | |
| verifies AUTN and MAC, derives RES | |
| and session key | |
+-------------------------------------+ |
| EAP-Response/AKA-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server checks the given RES, |
| | and MAC and finds them correct.|
| +--------------------------------+
| EAP-Success |
|<------------------------------------------------------|
Figure 1: EAP-AKA full authentication procedure
Figure 2 shows how the EAP server rejects the Peer due to a failed
authentication.
Arkko & Haverinen Expires May 25, 2005 [Page 12]
Internet-Draft EAP-AKA Authentication November 2004
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms, | |
| possibly verifies AUTN, and sends an| |
| invalid response | |
+-------------------------------------+ |
| EAP-Response/AKA-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| +------------------------------------------+
| | Server checks the given RES and the MAC, |
| | and finds one of them incorrct. |
| +------------------------------------------+
| EAP-Request/AKA-Notification |
|<------------------------------------------------------|
| EAP-Response/AKA-Notification |
|------------------------------------------------------>|
| EAP-Failure |
|<------------------------------------------------------|
Figure 2: Peer authentication fails
Figure 3 shows the peer rejecting the AUTN of the EAP server.
The peer sends an explicit error message
(EAP-Response/AKA-Authentication-Reject) to the EAP server, as usual
in AKA when AUTN is incorrect. This allows the EAP server to produce
the same error statistics as AKA in general produces in UMTS or
cdma2000.
Arkko & Haverinen Expires May 25, 2005 [Page 13]
Internet-Draft EAP-AKA Authentication November 2004
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and a bad AUTN|
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms | |
| and discovers AUTN that can not be | |
| verified | |
+-------------------------------------+ |
| EAP-Response/AKA-Authentication-Reject |
|------------------------------------------------------>|
| EAP-Failure |
|<------------------------------------------------------|
Figure 3: Network authentication fails
The AKA uses shared secrets between the Peer and the Peer's home
operator together with a sequence number to actually perform an
authentication. In certain circumstances it is possible for the
sequence numbers to get out of sequence. Figure 4 shows what happens
then.
Arkko & Haverinen Expires May 25, 2005 [Page 14]
Internet-Draft EAP-AKA Authentication November 2004
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms | |
| and discovers AUTN that contains an | |
| inappropriate sequence number | |
+-------------------------------------+ |
| EAP-Response/AKA-Synchronization-Failure |
| (AT_AUTS) |
|------------------------------------------------------>|
| +---------------------------+
| | Perform resynchronization |
| | Using AUTS and |
| | the sent RAND |
| +---------------------------+
| |
Figure 4: Sequence number synchronization
After the resynchronization process has taken place in the server and
AAA side, the process continues by the server side sending a new
EAP-Request/AKA-Challenge message.
In addition to the full authentication scenarios described above,
EAP-AKA includes a fast re-authentication procedure, which is
specified in Section 5. Fast re-authentication is based on keys
derived on full authentication. If the peer has maintained state
information for re-authentication and wants to use fast
re-authentication, then the peer indicates this by using a specific
fast re-authentication identity instead of the permanent identity or
a pseudonym identity.
4. Operation
4.1 Identity Management
Arkko & Haverinen Expires May 25, 2005 [Page 15]
Internet-Draft EAP-AKA Authentication November 2004
4.1.1 Format, Generation and Usage of Peer Identities
4.1.1.1 General
In the beginning of EAP authentication, the Authenticator or the EAP
server usually issues the EAP-Request/Identity packet to the peer.
The peer responds with EAP-Response/Identity, which contains the
user's identity. The formats of these packets are specified in
[RFC3748].
Subscribers of mobile networks are identified with the International
Mobile Subscriber Identity (IMSI) [TS 23.003]. 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 and help identify the AuC from which the
authentication vectors need to be retrieved for this subscriber.
Internet AAA protocols identify users with the Network Access
Identifier (NAI) [RFC2486]. 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.
This section specifies the peer identity format used in EAP-AKA. In
this document, the term identity or peer identity refers to the whole
identity string that is used to identify the peer. The peer identity
may include a realm portion. "Username" refers to the portion of the
peer identity that identifies the user, i.e. the username does not
include the realm portion.
4.1.1.2 Identity Privacy Support
EAP-AKA includes optional identity privacy (anonymity) support that
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?