WO2004102883A1 - A kind of method to realize user authentication - Google Patents

A kind of method to realize user authentication Download PDF

Info

Publication number
WO2004102883A1
WO2004102883A1 PCT/CN2004/000497 CN2004000497W WO2004102883A1 WO 2004102883 A1 WO2004102883 A1 WO 2004102883A1 CN 2004000497 W CN2004000497 W CN 2004000497W WO 2004102883 A1 WO2004102883 A1 WO 2004102883A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
eap
uim
client
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2004/000497
Other languages
English (en)
French (fr)
Inventor
Jianghai Gao
Yang Shao
Dianfu Chen
Zhuo Li
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of WO2004102883A1 publication Critical patent/WO2004102883A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications

Definitions

  • the present invention relates to authentication technology between a user and a network, and in particular, it includes at least
  • the RFC2284 document defines an extended authentication protocol for the point-to-point (PPP) protocol, namely the extended authentication (EAP) protocol.
  • This protocol can be extended on the basis of the EAP protocol to support other authentication mechanisms and provide end-to-end authentication methods.
  • the intermediate device does not need to adopt a specific authentication mechanism. In detail, when the authentication is performed between the authentication client and the authentication server, the authentication mechanism carried by both parties on the EAP protocol can be adopted, and no intermediate device is required to support it.
  • the EAP authentication protocol is defined differently according to different bearer types.
  • the EAP authentication protocol is carried on the PPP protocol, called EAPoPPP; the EAP authentication protocol is carried on the Remote Access Dial-In User Service (RADIUS) protocol, called EAPoRadius; the EAP authentication protocol is used on the 802.1x protocol, called EAPoL.
  • EAPoPPP PPP protocol
  • EAP authentication protocol is carried on the Remote Access Dial-In User Service (RADIUS) protocol, called EAPoRadius
  • EAP authentication protocol is used on the 802.1x protocol, called EAPoL.
  • the EAP authentication protocol message includes four fields: a code, a code, an identifier, a length, a data, and a type.
  • the Data field includes two types: Type and TypeData. Each field is transmitted from left to right during transmission.
  • the Code field occupies one byte and is used to identify the type of the EAP packet. As shown in Table 1, this domain has four types of values, where 1 represents the Request domain, 2 represents the Response domain, 3 represents the Success domain, and 4 represents the Failure domain. Type value meaning
  • the Identifier field occupies one byte and is used to match the Request message and the Response message.
  • the Length field occupies two bytes and is used to indicate the length of the EAP packet. It includes four fields: Code, Identifier, Length, and Data.
  • the Data field occupies zero or more bytes. This field uses a format related to the Code field type value.
  • Type field occupies one byte and mainly defines various authentication mechanisms. The Type field appears only in Request and Response messages. In RFC 2284, Type can be six types: Identity, Notification, Nak :, MD5 (MD5 -Challenge), One-Time Password, and Smart Card (Generic Token Card). .
  • the type value is 1 for Identity; the type value is 2 for Notification; the type value is 3 for Nak; the type value is 4 for MD5-Challenge; the type value is 5 for One-Time Password; the type value is 6 means Generic Token Card.
  • the type values of 1, 2, 4, 5, and 6 are applicable to Requset and Respone, and the type value of 3 is only applicable to Response messages.
  • Identity is used to query the identity of the user. Each Request request of the Identity type must correspond to a Response response of the Identity type.
  • Notification is used by the device to send a displayable message to the client.
  • the client should display this message to the user, and if it cannot display it, log it. Every A Notification request message must correspond to a Notification response message.
  • Nak is only applicable to Response packets.
  • a Nak-type Response message should be sent.
  • MD5-Challenge is similar to MD5 in CHAP protocol.
  • the MD5-Challenge type Request request message includes a Challenge message.
  • Each MD5-Challenge type Request request message must correspond to a MD5-Challenge type or Nak type Response response message.
  • One-Time Password type Request request contains one OTP Challenge request request.
  • One One-Time Password type response message must correspond to one One-Time Password type or ak type.
  • the Generic Token Card type is defined to require users to enter various Token Card information.
  • the Generic Token Card type Request request message contains an ASCII text message, and the corresponding Generic Token Card type Response response message contains the relevant Token Card information required for authentication. This information is usually read by the user from the Token Card device and entered in ACSII text.
  • TypeData this field occupies zero or more bytes, and is related to the type value of the Type field Format.
  • the client and the authentication point are the mobile switching center (MSC) / visit location register (VLR) and medium access register (HLR) / authentication center (AC) on the network side.
  • MSC mobile switching center
  • VLR visit location register
  • HLR medium access register
  • AC authentication center
  • SSD shared secret data
  • A-key is stored in the terminal and HLR / AC, which is used to update the SSD.
  • the authentication result is calculated by using the parameters such as SSD, random number, electronic serial number (ESN), and mobile station identification number (MIN) through the cellular authentication and voice encryption (CAVE) algorithm, and the MSC / VLR or HLR /
  • the AC compares whether the authentication results are consistent. If they are not consistent, the system will initiate an SSD update. After the SSD update is successful, that is, the SSDs on the terminal side and the network side remain consistent. The next time the user accesses, the authentication result calculated by the user terminal using the SSD should be Consistent with the authentication results calculated in HLR / AC, authentication can be successful.
  • an object of the present invention is to provide a method for implementing user authentication, so as to implement user authentication in a multi-mode network including at least an IS95 / CDMA2000 lx network, and Low cost and easy maintenance.
  • a method for implementing user authentication is applied to a multi-mode network including at least an IS95 / CDMA2000 lx network, and the method includes:
  • the authentication point is a non-IS95 / CDMA2000 lx network in a multi-mode network;
  • the client uses the user information in the UIM as the user identity, and performs EAP-UIM authentication with the authentication point.
  • the EAP protocol described in step A is set to a message code (Code), an identifier (Identifier), a length (Length), and data (Data), and the Data further includes a type (Type) and a data type (TypeData).
  • the Type is set to seven types including Identity, Notification Nak, MD5-Challenge, One-Time Password, Generic Token Card, and UIM.
  • the values from 1 to 6 correspond to the set Type.
  • the Type is UIM, and the value can be any value greater than 6.
  • the TypeData is set to include three fields: Type, Length, and Data.
  • the Type, Length, and Data values are greater than or equal to 1 and less than or equal to 255, and the Type, Length, and Data values are not equal.
  • the step B further includes:
  • the client sends the user identity to the authentication point.
  • the authentication point generates a random number for authenticating the client according to the user identity, and calculates a corresponding first authentication number according to the random number and the shared secret data (SSD) contained in the authentication point to form an authentication set.
  • SSD shared secret data
  • the client calculates a corresponding second authentication number according to the random number and the SSD of the client.
  • the authentication point compares whether the first authentication number is consistent with the second authentication number. If they are the same, the authentication succeeds; otherwise, the authentication fails.
  • Step B1 further includes:
  • the authentication point sends a client request user identity (EAP-Request / Identity) message to the client, asking the client to send its own identity;
  • EAP-Request / Identity client request user identity
  • the client sends the user identity to the authentication point through an identity response (EAP-Response / Identity).
  • the authentication point After receiving the EAP-Response / Identity message, the authentication point sends an EAP-Request / UIM / Start message to the client to start EAP-UIM authentication.
  • EAP-Request / UIM / Start After receiving the EAP-Request / UIM / Start message, the client sends an EAP-UIM authentication protocol start response (EAP-Response / UIM / Start) message to the authentication point.
  • EAP-UIM authentication protocol start response EAP-Response / UIM / Start
  • Step B14 further includes:
  • the authentication point After receiving the EAP-Response / UIM / Start message, the authentication point sends an EAP-UIM authentication protocol authentication request (EAP-Request / UIM / Challenge) message to the client, and sends the random number obtained from the authentication server to the client. end.
  • EAP-UIM authentication protocol authentication request EAP-Request / UIM / Challenge
  • Step B3 further includes: the client sends the second authentication number calculated by itself to the authentication point through an EAP-UIM authentication protocol authentication response (EAP-Response / UIM / Challenge) message.
  • EAP-UIM authentication protocol authentication response EAP-Response / UIM / Challenge
  • the method further includes:
  • step E Update the SSDs in the client and the authentication server to ensure that the SSDs at both ends are equal, and then return to step B for execution.
  • the invention implements the IS95 / CDMA2000 lx network to authenticate users using the IS95 / CDMA2000 lx network by expanding the EAP authentication protocol. This method can reduce cost investment, authentication security, and convenient maintenance. 4 / ⁇ 0 0 Brief description of the drawings
  • FIG. 1 is a schematic diagram of an EAP protocol message format in the prior art
  • FIG. 2 is a schematic flowchart of implementing the method of the present invention
  • FIG. 3 is a schematic flowchart of a specific embodiment of performing first authentication according to the present invention.
  • FIG. 4 is a schematic flowchart of a specific embodiment for performing an authentication according to the present invention. Mode of Carrying Out the Invention
  • the core content of the present invention is:
  • a user identity recognition module (UIM) in an IS95 / CDMA2000 lx network is used to authenticate non-IS95 / CDMA2000 lx network users.
  • UIM is not only used in CDMA IS95 and CDMA 2000 lx networks, but also in other networks, such as WLAN networks and CDMA EVDO networks. When it is used in these networks, an authentication protocol is needed to carry its authentication mechanism.
  • the networking structure for implementing the present invention includes a client, an authentication point, and an authentication server.
  • the authentication server indicates that the network can terminate the communication between the EAP protocol and the authentication point through the AAA protocol, such as the communication through the Radius protocol.
  • the authentication server can communicate with the CDMA network and can obtain the authentication set from the HLR of the CDMA network; the authentication point and the authentication server can communicate through the existing AAA communication protocol, such as the Radius protocol;
  • the client Refers to the terminal that contains the UIM module. It includes two cases. One is that the terminal and the UIM module are not separated, that is, the case where the machine card is not separated. The other is that the terminal and the UIM module are separated. Communication through the relevant interface, that is, the normal machine-card separation state.
  • the method for implementing the present invention includes the following steps:
  • Step 201 preset an EAP protocol supporting the client and the authentication point to use UIM for authentication
  • Step 202 The client uses the user information in the UIM as the user identity, and starts EAP-UIM authentication with the authentication point.
  • Step 203 The authentication point generates a random number for authenticating the user terminal according to the user identity, and calculates a corresponding first authentication number according to the random number and the SSD contained in the authentication point to form an authentication set.
  • Step 204 The client calculates a corresponding second authentication number according to the random number and the SSD of the client.
  • Step 205 The authentication point compares whether the first authentication number and the second authentication number are consistent. If they are the same, the authentication succeeds; otherwise, the authentication fails.
  • the invention is extended on the EAP authentication protocol to generate a new authentication protocol EAP-UIM.
  • the authentication protocol format of the present invention includes four parts: Code, Identifier, Length, and Data, where Data includes two types: Type and TypeData, which is the same as the prior art. However, the Type parameter and TypeData parameter are different from the prior art.
  • TYPE field of the EAP protocol in the prior art, and the value can be a value greater than 6, which can be applied to Requset and Respone messages. For example, if the TYPE field is defined as 31, it indicates that the packet type adopts the EAP-UIM protocol.
  • the TYPE-DATA field includes three types: Type and Lengths Value.
  • the TYPE field is used to indicate the message type of the EAP-UIM protocol. As shown in Table 3, three types of values are specified in this embodiment; the Length field is used to describe the length of the EAP-UIM message, and specifically includes the length of the Type, Length, and Data fields; the Value field uses the type value of the Type field Related formats. Value
  • the method of using UIM to authenticate users is the same as the method of user authentication in CDMA IS95 / CDMA 2000 lx networks in the prior art.
  • the first authentication fails in the first authentication, mainly due to the user terminal side and the network side. Due to inconsistent SSDs, after an authentication failure, an SSD update operation needs to be performed to make the SSDs at both ends consistent.
  • Step 301 The authentication point sends a client request user identity (EAP-Request / Identity) message to the client, and requires the client to send its own identity;
  • EAP-Request / Identity client request user identity
  • Step 302 The client obtains the identity information stored in the UIM, uses the identity information as the user identity, and sends the user identity to the authentication point in response to a user identity (EAP-Response / Identity) message.
  • EAP-Response / Identity user identity
  • Step 303 After receiving the EAP-Response Identity message, the authentication point sends an EAP-UIM authentication protocol start request (EAP-Request / UIM / Start) message to the client to start the EAP-UIM authentication protocol process.
  • EAP-Request / UIM / Start EAP-UIM authentication protocol start request
  • the authentication point uses the extended protocol request to obtain the user identity.
  • the TYPE and TYPEDATE parameters in the extended protocol will also be used to transmit the EAP-UIM authentication information between the client and the authentication point.
  • Step 304 After receiving the EAP-Request / UIM / Start message, the client returns an EAP-UIM authentication protocol start response (EAP-Response / UIM / Start) message to the authentication point; step 305 '.
  • the authentication point receives After EAP-Response / UIM / Start, it passes the authentication service
  • the W server exchanges to obtain an authentication set of a random number (rand) and its corresponding second authentication number (AUTH2), and then sends an EAP-UIM authentication protocol authentication request (EAP-Request / UIM / Challenge) report to the client.
  • the document contains a random number.
  • the process by which the authentication server obtains an authentication set is as follows: a random number is generated according to the user identity, and the corresponding second authentication number is calculated according to the SSD stored on the network side;
  • Step 306 After receiving the EAP-Request / UIM / Challenge message, the client encrypts the SSD stored in Rand and UIM to obtain the first authentication number (AUTH1), and then updates the response message through the EAP-UIM authentication protocol.
  • the text (EAP-Response UIM / Challenge) is sent to the authentication point, and the message carries AUTH1;
  • Step 307 After receiving the EAP-Response / UIM / Challenge message, the authentication point will compare the authentication server with AUTH1 and the AUTH2 saved by itself. If they are the same, the authentication point will notify the authentication point of success, otherwise, the authentication will fail and then authenticate. Click to determine whether the Update process is required. If necessary, start the Update process, update the SSD, and perform step 308; otherwise, the authentication fails and the process exits.
  • Step 308 The authentication point obtains an SSD authentication random number (RANDSSD) and its corresponding authentication number.
  • the authentication number is calculated according to the network side and the RANDSSD, and then the authentication point sends an EAP-UIM authentication protocol update response to the client.
  • Text (EAP-Request / UIM / Update) message which contains an SSD authentication random number (RANDSSD);
  • Step 309 After receiving the EAP-Request UIM / Update message, the client calculates the corresponding authentication number according to the RANDSSD and the SSD saved by the client, and sends an EAP-UIM authentication protocol authentication response (EAP-Respnse) to the authentication point. / UIM / Challenge) packet, which contains the authentication number calculated by the client;
  • EAP-Respnse EAP-UIM authentication protocol authentication response
  • Step 310 After receiving the EAP-Respnse / UIM / Challenge message, the authentication point determines whether the authentication numbers calculated by the network side and the client are the same. If they are the same, the client returns a EAP-UTM authentication protocol authentication request (EAP-Request / UIM / Challenge), otherwise, the SSD update fails;
  • Step 311 After receiving the EAP-Request / UIM / Challenge, the client updates its SSD, and sends the calculated SSD to the authentication point through an EAP-Response / UIM / Update message.
  • Step 312 After receiving the EAP-Response / UIM / Update, the authentication point updates the SSD on the network side to determine whether the SSD is updated. If the update is completed, the Update process is ended, and an EAP-Request / UIM / Challenge message is sent to the client. Re-certify;
  • Step 313 After receiving the EAP-Request / UIM / Challenge message, the client returns an EAP-Response / UIM / Challenge message to the authentication point.
  • Step 314 After the authentication point judges that the authentication is successful according to the EAP-Response / UIM / Challenge, it sends an EAP-Success message to the client;
  • the certification process for non-first certification is as follows:
  • Step 401 The authentication point sends an EAP-Request / Identity message to the client, requesting the client to send its own identity;
  • Step 402 After receiving the EAP-Request / Identity message, the client uses the identity information stored in the UIM as the user identity, and sends the user identity to the authentication point through the EAP-Response / Identity message;
  • Step 403 After receiving the EAP-Response / Identity message, the authentication point sends an EAP-Request / UIM / Start message to the client to start the EAP-UIM authentication protocol.
  • Step 405 After the authentication point receives the EAP-Response / UIM / Start message, it sends a message from the authentication server.
  • the Rand obtained by the server and the corresponding second authentication number (AUTH2), and then sends the Rand to the client through the EAP-Request / UIM / Challenge message; the second authentication number is based on the random number and saved on the network side. Calculated by the SSD;
  • Step 406 After receiving the EAP-Request / UIM / Challenge message, the client encrypts the password stored in Rand and UIM to obtain AUTH1, and the client sends the EAP-Response / UIM / Challenge message to the authentication point. Where the message carries AUTH1;
  • Step 407 After receiving the EAP-Response / UIM / Challenge message, the authentication point sends the received message to the authentication server through the AAA communication protocol with the authentication server.
  • the authentication server compares AUTH1 with AUTH2 stored by itself. If they are consistent, the authentication point is notified of success, and then the authentication point sends an EAP-Success message to the client to notify the client of successful authentication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Description

一种实现用户认证的方法 技术领域
本发明涉及用户与网络间的认证技术， 特别是指至少包括
IS95/CDMA2000 lx网络的多模网络中， 利用 IS95/CDMA2000 lx网络 对多模网络中的非 IS95/CDMA2000 lx网絡进行用户认证的方法。 发明背景
RFC2284文档中定义了一种点对点 （PPP )协议的扩展认证协议， 即扩展认证（EAP )协议。 该协议可以在 EAP协议基础上进行扩充， 承 载其他的认证机制， 并且提供端到端的认证方式， 中间设备不需要采用 具体的认证机制。 详细的说， 就是在认证客户端和认证服务器之间进行 认证时，可以采取双方承载在 EAP协议之上的认证机制， 不需要中间设 备来支持。 根据不同的承载类型， EAP认证协议定义不同。 比如， EAP 认证协议承载在 PPP协议上， 称为 EAPoPPP; EAP认证协议承载在远 端接入拨号用户服务（RADIUS )协议上， 称为 EAPoRadius; EAP认证 协议用在 802. lx协议上， 称为 EAPoL。
如图 1 所示， EAP 认证协议报文包括报文代码 （Code )、 标识符 ( Identifier )、 长度（Length ) 、 数据 ( Data ) 、 类型（Type )四个域。 其中 Data域又包括类型 （Type )和数据类型 （TypeData )两部分， 传输 时各域从左到右依次传输。
Code域占一个字节， 用于标识 EAP报文的类型。 如表 1所示， 该 域有四种取值， 取 1表示请求（ Request )域， 取 2表示回应（ Response ) 域， 取 3表示成功 （Success )域， 取 4表示失败 ( Failure )域。 类型值 含义
1 Request
2 Response
3 Success
4 Failure
Figure imgf000004_0001
Identifier域占一个字节 , 用来匹配 Request报文和 Response报文。 Length域占两个字节， 用于表示 EAP报文的长度， 其包括 Code、 Identifier、 Length和 Data四个域。
Data域占用零个或多个字节， 该域采用与 Code域类型值相关的格 式。
Type域占一个字节，主要定义了各种认证机制。 Type域只在 Request 和 Response报文中出现。 在 RFC 2284中， Type可以为标识（ Identity ), 通知（ Notification )、 拒绝 （Nak：)、 MD5 ( MD5 -Challenge ), 一次 性密码（ One-Time Password )、 智能卡（ Generic Token Card )六种类型。
参见表 2 所示， 类型值取为 1 表示 Identity; 类型值为 2 表示 Notification; 类型值为 3表示 Nak; 类型值为 4表示 MD5-Challenge; 类型值为 5表示 One-Time Password; 类型值为 6表示 Generic Token Card。 并且， 类型值 1、 2、 4、 5、 6适用于 Requset和 Respone 4艮文， 类型值 3只适用于 Response报文。
Identity用于查询用户的身份， 每一个 Identity类型的 Request请求 才艮文必须对应一个 Identity类型的 Response响应 艮文。
Notification用于由设备端向客户端发送一条可显示的消息。 客户端 应该将这条消息显示给用户， 如果无法显示， 则记入日志。 每一个 Notification类型的 Request请求艮文必须对应一个 Notification类型的 Response响应才艮文。
Nak仅适用于 Response响应报文。 当 Request请求报文中期望的认 证机制不被接受时， 应该发送 Nak类型的 Response响应报文。
MD5-Challenge与 CHAP协议中的 MD5类似。 MD5-Challenge类型 的 Request请求报文中包含了 Challenge 消息。每一个 MD5 -Challenge类 型的 Request请求报文必须对应一个 MD5-Challenge类型或者 Nak类型 的 Response响应报文。
One-Time Password 类型的 Request 请求 艮文包含一个 OTP Challenge每一个 One-Time Password类型的 Request请求^ =艮文必须对应 一个 One-Time Password类型或者 ak类型的 Response响应报文。
Generic Token Card类型是为要求用户输入各种 Token Card信息而 定义的。 Generic Token Card类型的 Request请求报文中包含一条 ASCII 文本消息， 对应的 Generic Token Card类型的 Response响应报文中包含 认证所必需的相关 Token Card.信息。通常这些信息由用户从 Token Card 设备读取并以 ACSII文本进行输入。
Figure imgf000005_0001
表 2
TypeData,该域占用零个或多个字节，采用与 Type域的类型值相关 的格式。
对于 CDMA IS95/CDMA 2000 lx网络中的用户，客户端与认证点之 间是网络侧的移动交换中心（MSC ) /拜访位置寄存器（ VLR )和介质访 问寄存器（ HLR ) /鉴权中心（ AC )共同完成认证。共享秘密数据 ( SSD ) 作为认证输入参数之一保存在终端和 HLR/AC中，在终端和 HLR/AC中 保存相同的（密码） A-key, 专用于更新 SSD。 当需要认证时， 以 SSD、 随机数、 电子串号（ESN )、 移动台识别号（MIN )等参数通过蜂窝认证 和语音加密（ CAVE )算法计算出认证结果， 并由 MSC/VLR或 HLR/AC 比较认证结果是否一致， 如果不一致， 系统将会发起 SSD更新， 在 SSD 更新成功之后， 即终端侧和网络侧的 SSD保持一致， 下次接入时， 用户 终端使用 SSD计算出的认证结果应与 HLR/AC中计算出来的认证结果 一致， 认证才能成功。
目前， 随着市场经济以及科学技术的发展， 越来越多的运营商需要 同时经营多种网络。 比如， 具有 IS95/CDMA2000 lx网络的运营商想继 续将自己的业务扩展到 CDMA2000 lxDO网络， WLAN 网络的运营商 也想将业务扩展到 CDMA2000 lxDO网络。而在 CDMA2000 lxDO网络 中， 要建立专门的 AN认证、 授权和计费服务器（AAA )进行认证。 这 种认证方式， 对于同时拥有多种码分多址（CDMA ) 网络的用户， 需要 在 HLR和 AN AAA两个地方开户， 认证方式不统一， 维护不方便， 不 利于统一运营；而且，还需要再组建 AN AAA的全国专用网络进行认证， 建网成本高。 发明内容
有鉴于此， 本发明的目的是提 ^一种实现用户认证的方法， 使其在 至少包括 IS95/CDMA2000 lx网络的多模网络中实现对用户的认证， 且 成本低、 维护方便。
一种实现用户认证的方法， 应用于至少包括 IS95/CDMA2000 lx网 络的多模网絡中， 该方法包括：
A. 预先设置支持客户端与认证点使用用户身份标识模块（ UIM ) 进行认证的 EAP协议， 所述认证点为多模网络中的非 IS95/CDMA2000 lx网络；
B. 客户端利用 UIM中的用户信息作为用户身份标识， 与所述认证 点进行 EAP-UIM认证。
步骤 A中所述 EAP协议设置为报文代码（ Code )、标识符（ Identifier )、 长度（Length ) 、 数据（Data ) ， 所述 Data又进一步包括类型（ Type ) 和数据类型 （TypeData )。
所述 Type设置为包括 Identity、 Notification Nak、 MD5 -Challenge、 One-Time Password、 Generic Token Card、 UIM七种类型。
利用 1 ~ 6取值分别与设置的 Type类型相对应， Type类型为 UIM, 取值为大于 6的任意值。
所述 TypeData设置为包括 Type、 Length和 Data三个域。
所述的 Type、 Length和 Data大于等于 1小于等于 255的值，且 Type、 Length和 Data取值不相等。
所述步骤 B进一步包括：
Bl、 客户端将用户身份标识发送至认证点；
B2、 认证点根据用户身份标识产生一个对客户端进行认证的随机 数， 并且根据该随机数及认证点含有的共享秘密数据 ( SSD )计算出对 应的第一鉴权数， 形成一个鉴权集；
B3、客户端根据所述随机数及客户端的 SSD计算出对应的第二鉴权 数； B4、 认证点比较笫一鉴权数与第二鉴权数是否一致， 如果一致， 则 认证成功， 否则， 认证失败。
步骤 B1进一步包括：
B11、 认证点向客户 端发送客户 端请求用户 身份标识 ( EAP-Request/Identity )报文， 要求客户端送上自己的身份标识；
B12、客户端将用户身份标识通过标识回应（ EAP-Response/Identity ) 寺艮文发送给认证点；
B13 > 认证点收到 EAP-Response/Identity才艮文后， 向客户端发送 EAP-UIM认证协议开始请求（EAP-Request/UIM/Start )报文， 开始进 行 EAP-UIM认证；
B14, 客户端收到 EAP-Request/UIM/Start才艮文后， 给认证点发送 EAP-UIM认证协议开始回应 （ EAP-Response/UIM/Start )报文。
步骤 B14进一步包括：
认证点收到 EAP-Response/UIM/Start 4艮文后， 向客户端发送 EAP-UIM认证协议认证请求（EAP-Request/UIM/Challenge )报文， 把 从认证服务器获得的随机数发送给客户端。
步骤 B3 进一步包括： 客户端将自身计算出的第二鉴权数通过 EAP-UIM认证协议认证回应（ EAP-Response/UIM/Challenge )报文发送 给认证点。
在认证失败后， 该方法进一步包括：
E. 更新客户端与认证服务器中的 SSD， 保证两端 SSD相等， 然后 再返回步骤 B执行。
本发明通过扩展 EAP认证协议，实现利用 IS95/CDMA2000 lx网络 对非 IS95/CDMA2000 lx网络对用户进行认证， 该方法可以减少成本投 资、 认证安全、 维护方便。 4 / ϋ 0 0 附图简要说明
图 1 现有技术中 ΕΑΡ协议报文格式示意图；
图 2为实现本发明方法的流程示意图；
图 3为本发明进行首次认证的具体实施例的流程示意图；
图 4为本发明进行一次认证的具体实施例的流程示意图。 实施本发明的方式
本发明的核心内容是： 通过进一步扩展 ΕΑΡ 认证协议， 利用 IS95/CDMA2000 lx 网络中的用户身份识别模块 （ UIM ) 对非 IS95/CDMA2000 lx网络用户进行认证。 UIM不仅用在 CDMA IS95和 CDMA 2000 lx网络中，还可以用在其他网络中，如 WLAN网络、 CDMA EVDO网络中。 当其用在这些网络中时， 需要有一种认证协议能够承载 它的认证机制。
实现本发明的组网结构包括客户端、 认证点和认证服务器。 认证服 务器表示在网络侧能够终结 EAP协议和认证点之间通过 AAA协议进行 通讯， 如通过 Radius协议进行通讯。 并且， 认证服务器能够与 CDMA 网络之间进行通讯， 能够从 CDMA网络的 HLR中获取鉴权集； 认证点 和认证服务器之间可以通过现有的 AAA通讯协议， 如 Radius协议， 进 行通讯； 客户端是指包含了 UIM模块的终端， 其包括两种情况， 一种是 终端和 UIM模块不分离， 即通常的机卡不分离的情况； 另一种是指终端 和 UIM模块分离， 两者之间通过相关接口进行通讯， 即通常的机卡分离 状态。
参见图 2所示， 实现本发明的方法包括以下步骤：
步骤 201:预先设置支持客户端与认证点使用 UIM进行认证的 EAP 协议； 步骤 202: 客户端利用 UIM中的用户信息作为用户身份标识， 与认 证点开始进行 EAP-UIM认证；
步驟 203: 认证点根据用户身份标识产生一个对用户终端进行认证 的随机数，并且根据该随机数及认证点含有的 SSD计算出对应的第一鉴 权数， 形成一个鉴权集；
步骤 204: 客户端根据所述随机数及客户端的 SSD计算出对应的第 二鉴权数；
步骤 205: 认证点比较第一鉴权数与第二鉴权数是否一致， 如果一 致， 则认证成功， 否则， 认证失败。
下面结合附图和具体实施例详细说明本发明的技术方案。
本发明是在 EAP 认证协议上进行扩展， 生成一种新的认证协议 EAP-UIM。 本发明的认证协议格式包括 Code、 Identifier, Length 、 Data 四部分， 其中， Data包括 Type和 TypeData两部分， 这与现有技术相 同。 但是其中 Type参数和 TypeData参数与现有技术不同。
进一步的说， 就是在现有技术中 EAP协议的 TYPE域中， 进一步增 加一种新类型 UIM,其值可以为大于 6的值，该类型可以适用于 Requset 和 Respone报文。 比如， 定义 TYPE域为 31 , 表示采用 EAP-UIM协议 的报文类型。
TYPE-DATA域包括 Type 、 Lengths Value三部分。 TYPE域用于 表示 EAP-UIM协议的报文类型， 该域可以在 1到 255之间任意取值。 参见表 3 所示， 本实施例中规定为三种类型值； Length域用于说明 EAP-UIM报文的长度， 具体包括 Type、 Length和 Data域的长度； Value 域采用与 Type域的类型值相关的格式。 取值
11 Start
12 Challenge
13 Update 表 3
利用 UIM 来对用户进行认证的方式， 与现有技术中 CDMA IS95/CDMA 2000 lx网络中用户进行认证的方式一样， 首次认证中第一 次认证会出现失败，这主要由于用户终端侧与网络侧中的 SSD不一致导 致， 所以在认证失败后， 需要进行 SSD更新操作， 以使两端的 SSD— 致。
参见图 3所示， 用户进行首次认证的具体过程如下：
步骤 301 : 认证点向客户端发送客户端请求用户身份标识 ( EAP-Request/Identity )报文， 要求客户端送上自己的身份标识；
步驟 302: 客户端获取 UIM里保存的身份信息， 将该身份信息作为 用户身份标识， 并通过回应用户身份标识（ EAP-Response/Identity )报文 将所述用户身份标识发送给认证点；
步骤 303: 认证点收到 EAP-Response Identity报文后， 向客户端发 送 EAP-UIM认证协议开始请求（EAP-Request/UIM/Start )报文， 开始 进行 EAP-UIM认证协议的过程； 这里， 认证点采用扩展后的协议请求 得到用户标识， 以下步骤中， 也将采用扩展后的协议中的 TYPE、 TYPEDATE参数来传送客户端与认证点之间 EAP-UIM认证信息。
步骤 304: 客户端收到 EAP-Request/UIM/Start报文后， 给认证点回 一个 EAP-UIM认证协议开始回应 （ EAP-Response/UIM/Start )报文； 步骤 305'. 认证点收到 EAP-Response/UIM/Start后， 通过与认证服 W 务器交换得到一个随机数 ( rand )及其对应的第二鉴权数 ( AUTH2 )的 鉴权集， 然后向客户端发送 EAP-UIM 认证协议认证请求 ( EAP-Request/UIM/Challenge )报文， 其中含有随机数； 这里， 认证服 务器得到一个鉴权集的过程是这样： 根据用户身份标识产生一个随机 数， 并根据网络侧保存的 SSD进行计算得出对应的第二鉴权数；
步骤 306:客户端收到 EAP-Request/UIM/Challenge报文后，将 Rand 和 UIM里保存的 SSD进行加密后， 得到第一鉴权数 ( AUTH1 )， 再通 过 EAP-UIM认证协议更新回应报文（ EAP-Response UIM/Challenge )发 送给认证点， 报文中携带 AUTH1;
步驟 307: 认证点收到 EAP-Response/UIM/Challenge报文后， 将接 认证月 务器对 AUTH1和自己保存的 AUTH2进行比较， 如果一致， 则 通知认证点成功，否则 ,认证失败，然后认证点判断是否需要进行 Update 流程， 如果需要， 则开始进行 Update流程， 更新 SSD, 执行步骤 308， 否则， 认证失败， 跳出；
步驟 308: 认证点获取 SSD认证随机数 ( RANDSSD )及其对应的 鉴权数， 该鉴权数为根据网络侧和 RANDSSD计算出， 然后认证点向客 户端发送 EAP-UIM认证协议更新回应 ^艮文（ EAP-Request/UIM/Update ) 报文， 其中含有 SSD认证随机数（ RANDSSD );
步骤 309: 客户端在收到 EAP-Request UIM/Update报文后， 根据 RANDSSD和客户端保存的 SSD计算得出对应的鉴权数，向认证点发送 EAP-UIM认证协议认证回应 （ EAP-Respnse/UIM/Challenge )报文， 其 中含有客户端计算得出鉴权数；
步骤 310: 认证点收到 EAP-Respnse/UIM/Challenge报文后， 判断网 络侧与客户端计算出的鉴权数是否一致， 如果一致， 则给客户端回一个 EAP-UTM认证协议认证请求（ EAP-Request/UIM/Challenge 艮文，否则， SSD更新失败；
步骤 311: 客户端收到 EAP-Request/UIM/Challenge后， 更新自身的 SSD,将计算出的 SSD通过 EAP-Response/UIM/Update报文发送给认证 点；
步骤 312: 认证点收到 EAP-Response/UIM/Update后， 更新网络侧 的 SSD, 判断 SSD是否更新完毕， 如果更新完毕， 结束 Update流程， 向客户端发送 EAP-Request/UIM/Challenge报文， 重新进行认证；
步骤 313: 客户端收到 EAP-Request/UIM/Challenge报文后， 给认证 点回一个 EAP-Response/UIM/Challenge报文；
步骤 314: 认证点根据 EAP-Response/UIM/Challenge判断认证成功 后， 给客户端发送 EAP-Success报文；
在首次认证进行 SSD更新后，由于已确保了客户端和认证点的 SSD 一致， 所以之后的认证过程就只有认证流程。 参见图 4所示， 非首次认 证的认证过程如下：
步驟 401: 认证点向客户端发送 EAP-Request/Identity报文， 要求客 户端送上自己的身份标识；
步骤 402:客户端收到 EAP-Request/Identity报文后，将 UIM里保存 的身份信息作为用户身份标识， 并通过 EAP-Response/Identity报文将用 户身份标识发送给认证点；
步骤 403: 认证点收到 EAP-Response/Identity报文后， 向客户端发 送 EAP-Request/UIM/Start报文， 开始进行 EAP-UIM认证协议的过程； 步骤 404: 客户端收到 EAP-Request/UIM/Start报文后， 给认证点回 一个 EAP-Response/UIM/Start 艮文；
步骤 405: 认证点收到 EAP-Response/UIM/Start报文后， 从认证服 务器处获得的 Rand 及对应的第二鉴权数 （AUTH2 ) , 然后通过 EAP-Request/UIM/Challenge报文将 Rand发送给客户端； 这里第二鉴权 数是根据随机数及网络侧保存的 SSD进行计算获得；
步骤 406:客户端收到 EAP-Request/UIM/Challenge报文后，将 Rand 和 UIM 里保存的密码进行加密后， 得到 AUTH1 , 客户端再通过 EAP-Response/UIM/Challenge 报文发送给认证点， 其中报文中携带 AUTH1 ;
步骤 407: 认证点收到 EAP-Response/UIM/Challenge报文后， 将接 收到的报文通过和认证服务器之间的 AAA通讯协议发送至认证服务器， 认证服务器对 AUTH1和自己保存的 AUTH2进行比较， 如果一致， 则 通知认证点成功， 然后认证点再向客户端发送 EAP-Success报文， 通知 客户端认证成功。
以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡 在本发明的精神和原则之内， 所作的任何修改、 等同替换、 改进等， 均 应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种实现用户认证的方法， 应用于至少包括 IS95/CDMA2000 lx 网络的多模网络中， 其特征在于， 该方法包括以下步骤：
A. 预先设置支持客户端与认证点使用用户身份标识模块（ UIM ) 进行认证的扩展认证 （EAP ) 协议， 所述认证点为多模网络中的非 IS95/CDMA2000 lx网络；
B. 客户端利用 UIM中的用户信息作为用户身份标识， 与所述认证 点进行 EAP-UIM认证。
2、 根据权利要求 1所述的方法， 其特征在于， 步骤 A中所述 EAP 协议设置为报文代码 ( Code ), 标识符（ Identifier )、 长度 ( Length ) 、 数据 （Data ) , 所述 Data 又进一步包括类型 （Type ) 和数据类型
( TypeData )。
3、 根据权利要求 2所述的方法， 其特征在于， 所述 Type设置为包 括标识 （Identity ) , 通知 （Notification ) , 拒绝 （Nak )、 MD5 挑战
( MD5-Challenge )、一次性密码 ( One-Time Password )、智能卡（ Generic Token Card )、 用户身份标识模块（UIM )七种类型。
4、 根据权利要求 3所述的方法， 其特征在于， 利用 1 ~ 6取值分别 与设置的 Type类型相对应， Type类型为 UIM,取值为大于 6的任意值。
5、 根据权利要求 2所述的方法， 其特征在于， 所述 TypeData设置 为包括 Type、 Length和 Data三个域。
6、根据权利要求 5所述的方法， 其特征在于， 所述的 Type、 Length 和 Data大于等于 1小于等于 255的值， 且 Type、 Length和 Data取值不 相等。
7、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 B进一步 包括：
Bl、 客户端将用户身份标识发送至认证点；
B2、 认证点根据用户身份标识产生一个对客户端进行认证的随机 数， 并且根据该随机数及认证点含有的共享秘密数据 ( SSD )计算出对 应的第一鉴权数， 形成一个鉴权集；
B3、客户端根据所述随机数及客户端的 SSD计算出对应的第二鉴权 数；
B4、 认证点比较第一鉴权数与第二鉴权数是否一致， 如果一致， 则 认证成功， 否则， 认证失败。
8、根据权利要求 7所述的方法，其特征在于， 步骤 B1进一步包括： B11、 认证点向客户 端发送客户端请求用户 身份标识
( EAP-Request/Identity )报文， 要求客户端送上自己 身份标识；
B12、客户端将用户身份标识通过标识回应（ EAP-Response/Identity ) 报文发送给认证点；
B13、 认证点收到 EAP-Response/Identity 报文后， 向客户端发送
EAP-UIM认证协议开始请求 （EAP-Request UIM/Start )报文， 开始进 行 EAP-UIM认证；
B14、 客户端收到 EAP-Request/UIM/Start报文后， 给认证点发送
EAP-UIM认证协议开始回应 （ EAP-Response UIM/Start )报文。
9、 根据权利要求 8所述的方法， 其特征在于， 步骤 B14进一步包 括：
认证点收到 EAP-Response/UIM/Start 艮文后， 向客户端发送 EAP-UIM认证协议认证请求（EAP-Request/UIM/Challenge )报文， 把 从认证服务器获得的随机数发送给客户端。
10、 根据权利要求 7所述的方法， 其特征在于， 步骤 B3进一步包 括： 客户端将自身计算出的第二鉴权数通过 EAP-UIM认证协议认证回 应 （ EAP-Response/UIM/Challenge )报文发送给认证点。
11、 根据权利要求 7所述的方法， 其特征在于， 在认证失败后， 该 方法进一步包括：
E. 更新客户端与认证服务器中的 SSD, 保证两端 SSD相等， 然后 再返回步骤 B执行。
PCT/CN2004/000497 2003-05-16 2004-05-17 A kind of method to realize user authentication Ceased WO2004102883A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN03131038.9 2003-05-16
CNA031310389A CN1549494A (zh) 2003-05-16 2003-05-16 一种实现用户认证的方法

Publications (1)

Publication Number Publication Date
WO2004102883A1 true WO2004102883A1 (en) 2004-11-25

Family

ID=33438173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2004/000497 Ceased WO2004102883A1 (en) 2003-05-16 2004-05-17 A kind of method to realize user authentication

Country Status (2)

Country Link
CN (1) CN1549494A (zh)
WO (1) WO2004102883A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2433882A1 (de) 2010-09-22 2012-03-28 TGW Mechanics GmbH Verfahren zum Einlagern von Waren sowie Vorrichtung dazu

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100770928B1 (ko) * 2005-07-02 2007-10-26 삼성전자주식회사 통신 시스템에서 인증 시스템 및 방법
CN101110673B (zh) * 2006-07-17 2011-02-02 华为技术有限公司 利用一次eap过程执行多次认证的方法和装置
CN100423609C (zh) * 2006-08-01 2008-10-01 中国移动通信集团公司 一种接入移动通信装置的方法
CN101203030B (zh) * 2006-12-13 2010-10-06 联想(北京)有限公司 一种利用移动终端多模协议栈进行鉴权的装置和方法
CN101431508B (zh) * 2007-11-06 2012-05-23 华为技术有限公司 一种网络认证方法、系统及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1001641A2 (en) * 1998-11-09 2000-05-17 Lucent Technologies Inc. Secure method for generating cryptographic function outputs
KR20020047589A (ko) * 2000-12-13 2002-06-22 이계철 무선통신 단말기를 이용한 출입 통제 방법
CN1486029A (zh) * 2002-09-23 2004-03-31 华为技术有限公司 基于远程认证的网络中实现eap认证的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1001641A2 (en) * 1998-11-09 2000-05-17 Lucent Technologies Inc. Secure method for generating cryptographic function outputs
KR20020047589A (ko) * 2000-12-13 2002-06-22 이계철 무선통신 단말기를 이용한 출입 통제 방법
CN1486029A (zh) * 2002-09-23 2004-03-31 华为技术有限公司 基于远程认证的网络中实现eap认证的方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2433882A1 (de) 2010-09-22 2012-03-28 TGW Mechanics GmbH Verfahren zum Einlagern von Waren sowie Vorrichtung dazu

Also Published As

Publication number Publication date
CN1549494A (zh) 2004-11-24

Similar Documents

Publication Publication Date Title
US11895157B2 (en) Network security management method, and apparatus
CN100539521C (zh) 一种实现无线局域网鉴权的方法
JP5199405B2 (ja) 通信システムにおける認証
CA2490131C (en) Key generation in a communication system
US8094821B2 (en) Key generation in a communication system
WO2011017924A1 (zh) 无线局域网的认证方法、系统、服务器和终端
WO2004102875A1 (en) A method for performing authentication of high rapidity packet data
CN109391937A (zh) 公钥的获取方法、设备及系统
CN1327648C (zh) 一种实现高速率分组数据业务认证的方法
WO2004102883A1 (en) A kind of method to realize user authentication
CN101203030B (zh) 一种利用移动终端多模协议栈进行鉴权的装置和方法
CN101160784A (zh) 一种密钥更新协商方法及装置
CN119652537A (zh) 一种网络设备认证方法、装置、设备及介质
HK1072849B (zh) 一种实现高速率分组数据业务认证的方法
HK1085027B (zh) 通信系統中的認證

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase