HQY 一个和谐有爱的空间

参考：

https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol

https://tools.ietf.org/html/rfc4186

 

1.Extensible Authentication Protocol

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in wireless networks and point-to-point connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by RFC 5247.

EAP is an authentication framework for providing the transport and usage of keying material and parameters generated by EAP methods.[1] There are many methods defined by RFCs and a number of vendor specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines message formats. Each protocol that uses EAP defines a way to encapsulate EAP messages within that protocol's messages.

EAP is in wide use. For example, in IEEE 802.11 (WiFi) the WPA and WPA2 standards have adopted IEEE 802.1X with one hundred EAP Types as the official authentication mechanisms.

EAP is an authentication framework, not a specific authentication mechanism.[1] It provides some common functions and negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined. Methods defined in IETF RFCs include EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA, and EAP-AKA'. Additionally a number of vendor-specific methods and new proposals exist. Commonly used modern methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, LEAP and EAP-TTLS. Requirements for EAP methods used in wireless LAN authentication are described in RFC 4017. The list of type and packets codes used in EAP is available from the IANA EAP Registry.

The standard also describes the conditions under which the AAA key management requirements described in RFC 4962 can be satisfied.

拓展认证协议（EAP）是一个在无线网络和点对点通信中频繁使用的认证协议。

EAP是一个传输和使用EAP方法生产的关键参数的认证框架。在RFC中定义了很多方法，并且存在许多定制的方法和新的建议。EAP不是一个限制性协议，相反只定义了报文格式。每个使用EAP的协议在协议的报文中都定义了封装EAP报文的方法。

EAP被广泛使用，例如在IEEE 802.11 WPA和WPA2标准已经采用了有100个EAP类型的IEEE 802.1X 作为官方认证机制。

EAP是一个认证框架，不是一个特别的认证机制。它提供一些带有常用功能和协商的认证方法，这些方法被称为EAP方法。有大约40个不同的方法已被定义。在IETF RFCs定义的方法包括EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA, and EAP-AKA'。额外存在很多定制的方法和新的建议。常用的能在无线网络中使用的现代方法包括EAP-TLS, EAP-SIM, EAP-AKA, LEAP and EAP-TTLS.在无线局域网使用EAP方法的要求在RFC 4017中有描述。

这个标准描述的条件与RFC 4962中认证授权收费管理办法要求一样的。

 

2.EAP Subscriber Identity Module (EAP-SIM)

EAP Subscriber Identity Module (EAP-SIM) is used for authentication and session key distribution using the subscriber identity module (SIM) from the Global System for Mobile Communications (GSM).

GSM cellular networks use a subscriber identity module card to carry out user authentication. EAP-SIM use a SIM authentication algorithm between the client and an Authentication, Authorization and Accounting (AAA) server providing mutual authentication between the client and the network.

In EAP-SIM the communication between the SIM card and the Authentication Centre (AuC) replaces the need for a pre-established password between the client and the AAA server.

The A3/A8 algorithms are being run a few times, with different 128 bit challenges, so there will be more 64 bit Kc-s which will be combined/mixed to create stronger keys (Kc-s won't be used directly). The lack of mutual authentication in GSM has also been overcome.

EAP-SIM is described in RFC 4186.

EAP-SIM是在GSM下SIM卡认证和秘钥发布中使用的。

GSM移动网络 使用sim卡来携带用户认证信息。EAP-SIM使用一个在客户端和AAA服务端间的SIM认证算法，AAA在客户端和网络之间提供相互身份验证。

在EAP-SIM中SIM卡和认证中心直接的交流替代了预制密码。

A3/A8算法已经使用一段时间了，使用128比特口令，因此将有多余64比特的kc-s被用来链接、混合来生成更可靠的秘钥，kc-s不可直接使用。GSM缺乏相互认证的缺陷已经被克服了。

 

3. EAP SIM Full Authentication

截取自rfc第8页，描述了eap-sim 全认证过程。

3.1 EAP-Request/Identity

The first EAP Request issued by the authenticator is
EAP-Request/Identity. On full authentication, the peer’s response
includes either the user’s International Mobile Subscriber Identity
(IMSI) or a temporary identity (pseudonym) if identity privacy is in
effect, as specified in Section 4.2.

4.2节介绍了下identity，其中永久的identity举了个例子

For example, a permanent username
derived from the IMSI 295023820005424 would be encoded as the ASCII
string "1295023820005424" (byte values in hexadecimal notation: 31 32
39 35 30 32 33 38 32 30 30 30 35 34 32 34).

永久identity最前面加1，后面接IMSI

Pseudonym usernames and fast re-authentication identities are
generated by the EAP server. The EAP server produces pseudonym
usernames and fast re-authentication identities in an
implementation-dependent manner. Only the EAP server needs to be
able to map the pseudonym username to the permanent identity, or to
recognize a fast re-authentication identity.

另外别名和快速重新认证identity是由eap server使用独立实现的方式生成的，只有eap服务端需要映射别名到永久identity，或者识别快速重新认证identity。

 

3.2 EAP Requests/SIM/START

Following the peer’s EAP-Response/Identity packet, the peer receives
EAP Requests of Type 18 (SIM) from the EAP server 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 8.
The EAP-Request/SIM/Start packet contains the list of EAP-SIM
versions supported by the EAP server in the AT_VERSION_LIST
attribute. This packet may also include attributes for requesting
the subscriber identity, as specified in Section 4.2.
The peer responds to a 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 peer,
and the AT_SELECTED_VERSION attribute that contains the version
number selected by the peer. The version negotiation is protected by
including the version list and the selected version in the
calculation of keying material (Section 7).

3.3 EAP Requests/SIM/Challenge

After receiving the EAP Response/SIM/Start, the EAP server obtains n
GSM triplets for use in authenticating the subscriber, where n = 2 or
n = 3. From the triplets, the EAP server derives the keying
material, as specified in Section 7. The triplets may be obtained by
contacting an Authentication Centre (AuC) on the GSM network; per GSM
specifications, between 1 and 5 triplets may be obtained at a time.
Triplets may be stored in the EAP server for use at a later time, but
triplets MUST NOT be re-used, except in some error cases that are
specified in Section 10.9.
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 AT_MAC attribute is a general message authentication code
attribute that is used in many EAP-SIM messages.
On receipt of the EAP-Request/SIM/Challenge message, the peer runs
the GSM authentication algorithm and calculates a copy of the message
authentication code. The peer then verifies that the calculated MAC
equals the received MAC. If the MAC’s do not match, then the peer

sends the EAP-Response/SIM/Client-Error packet and the authentication
exchange terminates.
Since the RANDs given to a peer are accompanied by the message
authentication code AT_MAC, and since the peer’s NONCE_MT value
contributes to AT_MAC, the peer is able to verify that the EAP-SIM
message is fresh (i.e., not a replay) and that the sender possesses
valid GSM triplets for the subscriber.
If all checks out, the peer responds with the
EAP-Response/SIM/Challenge, containing the AT_MAC attribute that
covers the peer’s SRES response values (Section 9.4). The EAP server
verifies that the MAC is correct. Because protected success
indications are not used in this example, the EAP server sends the
EAP-Success packet, indicating that the authentication was
successful. (Protected success indications are discussed in
Section 6.2.) The EAP server may also include derived keying
material in the message it sends to the authenticator. The peer has
derived the same keying material, so the authenticator does not
forward the keying material to the peer along with EAP-Success.
EAP-SIM also includes a separate fast re-authentication procedure
that does not make use of the A3/A8 algorithms or the GSM
infrastructure. Fast re-authentication is based on keys derived on
full authentication. If the peer has maintained state information
for fast 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. The fast re-authentication procedure is
described in Section 5.

3.4 关于pseudonym username

3.4.1 Transmitting Pseudonyms and Fast Re-authentication Identities
to the Peer

摘抄自文档4.2.1.8.
Transmitting Pseudonyms and Fast Re-authentication Identities
to the Peer

The EAP-Request/SIM/Challenge message MAY include an encrypted
pseudonym username and/or an encrypted fast re-authentication
identity in the value field of the AT_ENCR_DATA attribute. Because
identity privacy support and fast re-authentication are optional
implementations, the peer MAY ignore the AT_ENCR_DATA attribute and
always use the permanent identity. On fast re-authentication
(discussed in Section 5), the server MAY include a new, encrypted
fast re-authentication identity in the
EAP-Request/SIM/Re-authentication message.
On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the
encrypted data in AT_ENCR_DATA. If the authentication exchange is
successful, and the encrypted data includes a pseudonym username,
then the peer may use the obtained pseudonym username on the next
full authentication. If a fast re-authentication identity is
included, then the peer MAY save it together with other fast
re-authentication state information, as discussed in Section 5, for
the next fast re-authentication. If the authentication exchange does
not complete successfully, the peer MUST ignore the received
pseudonym username and the fast re-authentication identity.

If the peer does not receive a new pseudonym username in the
EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym
username instead of the permanent username on the next full
authentication. The username portions of fast re-authentication

identities are one-time usernames, which the peer MUST NOT re-use.
When the peer uses a fast re-authentication identity in an EAP
exchange, the peer MUST discard the fast re-authentication identity
and not re-use it in another EAP authentication exchange, even if the
authentication exchange was not completed.

3.4.2 Usage of the Pseudonym by the Peer

摘抄自文档4.2.1.9.
Usage of the Pseudonym by the Peer

When the optional identity privacy support is used on full
authentication, the peer MAY use a pseudonym username received as
part of a previous full authentication sequence as the username
portion of the NAI. The peer MUST NOT modify the pseudonym username
received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer
MAY need to decorate the username in some environments by appending
or prepending the username with a string that indicates supplementary
AAA routing information.
When using a pseudonym username in an environment where a realm
portion is used, the peer concatenates the received pseudonym
username with the "@" character and an NAI realm portion. The
selection of the NAI realm is discussed above. The peer can select
the realm portion similarly, regardless of whether it uses the
permanent username or a pseudonym username.

这样看起来pseudonym username是EAP-SIM认证成功以后eap server发给peer的，peer下次连接的时候可以用pseudonym username，因为eap server将pseudonym username和permanent username做了映射及保存，可以在收到pseudonym username的时候知晓其permanent username。

3.4.3 Communicating the Peer Identity to the Server

摘抄自文档4.2.2.
Communicating the Peer Identity to the Server

The peer identity MAY be communicated to the server with the
EAP-Response/Identity message. This message MAY contain the
permanent identity, a pseudonym identity, or a fast re-authentication
identity. If the peer uses the permanent identity or a pseudonym
identity, which the server is able to map to the permanent identity,
then the authentication proceeds as discussed in the overview of
Section 3. If the peer uses a fast re-authentication identity, and
if the fast re-authentication identity matches with a valid fast

re-authentication identity maintained by the server, and if the
server agrees to use fast re-authentication, then a fast
re-authentication exchange is performed, as described in Section 5.

The peer identity can also be transmitted from the peer to the server
using EAP-SIM messages instead of the EAP-Response/Identity. In this
case, the server includes an identity-requesting attribute
(AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY
attribute, which contains the peer’s identity, in the
EAP-Response/SIM/Start message. The AT_ANY_ID_REQ attribute is a
general identity-requesting attribute, which the server uses if it
does not specify which kind of an identity the peer should return in
AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to
request either the permanent identity or a pseudonym identity. The
server uses the AT_PERMANENT_ID_REQ attribute to request that the
peer send its permanent identity.

If EAP-SIM peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-SIM identity in the EAP-
Response/Identity packet. In this case, the peer performs the
following steps.
If the peer has maintained fast re-authentication state information
and wants to use fast re-authentication, then the peer transmits the
fast re-authentication identity in EAP-Response/Identity.
Else, if the peer has a pseudonym username available, then the peer
transmits the pseudonym identity in EAP-Response/Identity.
In other cases, the peer transmits the permanent identity in
EAP-Response/Identity.

携带identity的策略是

1）如果有快速重新授权的信息并且想要使用快速重新授权，那么peer发送快速重新授权的identity。

2）如果peer有别名的 话，发送别名。

3）啥都没有的话，发送永久identity。

3.4.4 Server Operation in the Beginning of EAP-SIM Exchange

摘抄自文档 4.2.4 Server Operation in the Beginning of EAP-SIM Exchange

As discussed in Section 4.2.2.2, the server SHOULD NOT rely on an
identity string received in EAP-Response/Identity. Therefore, the
RECOMMENDED way to start an EAP-SIM exchange is to ignore any
received identity strings. The server SHOULD begin the EAP-SIM
exchange by issuing the EAP-Request/SIM/Start packet with an
identity-requesting attribute to indicate that the server wants the
peer to include an identity in the AT_IDENTITY attribute of the EAP-
Response/SIM/Start message. Three methods to request an identity
from the peer are discussed below.
If the server chooses not to ignore the contents of EAP-
Response/Identity, then the server may have already received an EAP-
SIM identity in this packet. However, if the EAP server has not
received any EAP-SIM peer identity (permanent identity, pseudonym
identity, or fast re-authentication identity) from the peer when
sending the first EAP-SIM request, or if the EAP server has received
an EAP-Response/Identity packet but the contents do not appear to be
a valid permanent identity, pseudonym identity or a re-authentication
identity, then the server MUST request an identity from the peer
using one of the methods below.

server不应该依赖于EAP-Response/Identity所携带的identity，应该发送一个带有identity-requesting attribute的EAP-Request/SIM/Start包来向peer获取在EAP-Response/SIM/Start AT_IDENTITY中的 identity

The server sends the EAP-Request/SIM/Start message with the
AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
peer to include the permanent identity in the AT_IDENTITY attribute

of the EAP-Response/SIM/Start message.
cases:
This is done in the following
o The server does not support fast re-authentication or identity
privacy.
o The server decided to process a received identity, and the server
recognizes the received identity as a pseudonym identity but the
server is not able to map the pseudonym identity to a permanent
identity.
The server issues the EAP-Request/SIM/Start packet with the
AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
peer to include a full authentication identity (pseudonym identity or
permanent identity) in the AT_IDENTITY attribute of the
EAP-Response/SIM/Start message. This is done in the following cases:
o The server does not support fast re-authentication and the server
supports identity privacy.
o The server decided to process a received identity, and the server
recognizes the received identity as a re-authentication identity
but the server is not able to map the re-authentication identity
to a permanent identity.
The server issues the EAP-Request/SIM/Start packet with the
AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
include an identity in the AT_IDENTITY attribute of the
EAP-Response/SIM/Start message, and the server does not indicate any
preferred type for the identity. This is done in other cases, such
as when the server ignores a received EAP-Response/Identity, the
server does not have any identity, or the server does not recognize
the format of a received identity.

有3种server从peer获取identity的方式，分别为

• AT_PERMANENT_ID_REQ：支持permanent identity

• AT_FULLAUTH_ID_REQ：支持permanent identity和pseudonym identity

• AT_ANY_ID_REQ：支持任意类型的identity

3.4.5 Processing of EAP-Request/SIM/Start by the Peer

原4.2.5.
Processing of EAP-Request/SIM/Start by the Peer

Upon receipt of an EAP-Request/SIM/Start message, the peer MUST
perform the following steps.
If the EAP-Request/SIM/Start does not include an identity request
attribute, then the peer responds with EAP-Response/SIM/Start without
AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and
AT_NONCE_MT attributes, because the exchange is a full authentication
exchange.

AT_PERMANENT_ID_REQ
If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the
peer does not have a pseudonym available, then the peer MUST respond
with EAP-Response/SIM/Start and include the permanent identity in

AT_IDENTITY. If the peer has a pseudonym available, then the peer
MAY refuse to send the permanent identity; hence, in this case the
peer MUST either respond with EAP-Response/SIM/Start and include the
permanent identity in AT_IDENTITY or respond with EAP-Response/SIM/
Client-Error packet with the code "unable to process packet".

AT_FULL_AUTH_ID_REQ
If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the
peer has a pseudonym available, then the peer SHOULD respond with
EAP-Response/SIM/Start and include the pseudonym identity in
AT_IDENTITY. If the peer does not have a pseudonym when it receives
this message, then the peer MUST respond with EAP-Response/SIM/Start
and include the permanent identity in AT_IDENTITY. The Peer MUST NOT
use a re-authentication identity in the AT_IDENTITY attribute.

AT_ANY_ID_REQ
If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ and if the peer
has maintained fast re-authentication state information and the peer
wants to use fast re-authentication, then the peer responds with
EAP-Response/SIM/Start and includes the fast re-authentication
identity in AT_IDENTITY. Else, if the peer has a pseudonym identity
available, then the peer responds with EAP-Response/SIM/Start and
includes the pseudonym identity in AT_IDENTITY. Else, the peer
responds with EAP-Response/SIM/Start and includes the permanent
identity in AT_IDENTITY.
An EAP-SIM exchange may include several EAP/SIM/Start rounds. The
server may issue a second EAP-Request/SIM/Start if it was not able to
recognize the identity that the peer used in the previous AT_IDENTITY
attribute. At most, three EAP/SIM/Start rounds can be used, so the
peer MUST NOT respond to more than three EAP-Request/SIM/Start
messages within an EAP exchange. The peer MUST verify that the
sequence of EAP-Request/SIM/Start packets that the peer receives
comply with the sequencing rules defined in this document. That is,
AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start; in
other words, AT_ANY_ID_REQ MUST NOT be used in the second or third
EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the
previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. The
peer operation, in cases when it receives an unexpected attribute or
an unexpected message, is specified in Section 6.3.1.

对于如下server获取identity传来的参数也有不同的回应策略：

• AT_PERMANENT_ID_REQ：有pseudonym identity并且不想回复permanent identity，回复EAP-Response/SIM/
  Client-Error，否则permanent identity

• AT_FULLAUTH_ID_REQ：有pseudonym identity回复pseudonym identity，否则permanent identit

• AT_ANY_ID_REQ：回应优先级fast re-authentication
  identity>pseudonym identity>permanent identit

另外eap-sim exchange过程不超过3轮，AT_ANY_ID_REQ只能用在第一轮；如果之前用过AT_PERMANENT_ID_REQ，那么就不能再用AT_FULLAUTH_ID_REQ

3.4.6 Attacks Against Identity Privacy

原4.2.6.
Attacks Against Identity Privacy

The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ. This is because 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 peer, in an
effort to find out the true identity of the user. If the peer does
not want to reveal its permanent identity, then the peer sends the

EAP-Response/SIM/Client-Error packet with the error code "unable to
process packet", and the authentication exchange terminates.
Basically, there are two different policies that the peer can employ
with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes
that the network is able to maintain pseudonyms robustly. Therefore,
if a conservative peer has a pseudonym username, the peer responds
with EAP-Response/SIM/Client-Error to the EAP packet with
AT_PERMANENT_ID_REQ, because the peer believes that the valid network
is able to map the pseudonym identity to the peer’s permanent
identity. (Alternatively, the conservative peer may accept
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 peer against active attacks on anonymity. On
the other hand, a "liberal" peer 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 map them to the
permanent identity.

考虑到identity隐私的攻击，对于AT_PERMANENT_ID_REQ即想要从peer获取permanent identity的报文有两种策略：

1）保守派peer认为server肯定会保存好pseudonyms identity（及与permanent identity的映射），如果peer持有pseudonyms identity，则会发送EAP-Response/SIM/Client-Error

2）开放派会接受AT_PERMANENT_ID_REQ并且回复permanent identity，这样的好处是网络有时候会丢失pseudonyms继而不能映射到permanent identity.

3.4.7 Processing of AT_IDENTITY by the Server

原4.2.7.
Processing of AT_IDENTITY by the Server（page 23）

When the server receives an EAP-Response/SIM/Start message with the
AT_IDENTITY (in response to the server’s identity requesting
attribute), the server MUST operate as follows.

 

AT_PERMANENT_ID_REQ:
If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
not contain a valid permanent identity, then the server sends
EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
failure" (16384), and the EAP exchange terminates. If the server
recognizes the permanent identity and is able to continue, then the
server proceeds with full authentication by sending EAP-Request/SIM/
Challenge.

 

AT_FULLAUTH_ID_REQ:
If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
valid permanent identity or a pseudonym identity that the server can
map to a valid permanent identity, then the server proceeds with full
authentication by sending EAP-Request/SIM/Challenge. If AT_IDENTITY
contains a pseudonym identity that the server is not able to map to a
valid permanent identity, or an identity that the server is not able
to recognize or classify, then the server sends EAP-Request/SIM/Start
with AT_PERMANENT_ID_REQ.

 

AT_ANY_ID_REQ:
If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
valid permanent identity or a pseudonym identity that the server can
map to a valid permanent identity, then the server proceeds with full
authentication by sending EAP-Request/SIM/Challenge.

If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
fast re-authentication identity and the server agrees on using
re-authentication, then the server proceeds with fast
re-authentication by sending EAP-Request/SIM/Re-authentication
(Section 5).
If the server used AT_ANY_ID_REQ, and if the peer sent an
EAP-Response/SIM/Start with only AT_IDENTITY (indicating
re-authentication), but the server is not able to map the identity to
a permanent identity, then the server sends EAP-Request/SIM/Start
with AT_FULLAUTH_ID_REQ.
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
fast re-authentication identity that the server is able to map to a
permanent identity, and if the server does not want to use fast
re-authentication, then the server sends EAP-Request/SIM/Start
without any identity requesting attributes.
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
identity that the server recognizes as a pseudonym identity but the
server is not able to map the pseudonym identity to a permanent
identity, then the server sends EAP-Request/SIM/Start with
AT_PERMANENT_ID_REQ.
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
identity that the server is not able to recognize or classify, then
the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ.

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://hqyman.cn/post/5996.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下~~