WO2007112624A1 - Procédé d'authentification, procédé de négociation du type d'authentification, et dispositif de fourniture d'accès au réseau - Google Patents

Procédé d'authentification, procédé de négociation du type d'authentification, et dispositif de fourniture d'accès au réseau Download PDF

Info

Publication number
WO2007112624A1
WO2007112624A1 PCT/CN2006/003409 CN2006003409W WO2007112624A1 WO 2007112624 A1 WO2007112624 A1 WO 2007112624A1 CN 2006003409 W CN2006003409 W CN 2006003409W WO 2007112624 A1 WO2007112624 A1 WO 2007112624A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
domain
user
authentication type
network
Prior art date
Application number
PCT/CN2006/003409
Other languages
English (en)
French (fr)
Inventor
Yijiong Zhang
Tao Han
Kaijun Xia
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 WO2007112624A1 publication Critical patent/WO2007112624A1/zh

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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved

Definitions

  • the present invention relates to the field of network management technologies, and in particular, to an authentication method, an authentication type negotiation method, and a network access service device.
  • the PPP protocol (Point to Point Protocol) is a protocol of the data link layer in the TCP/IP protocol (Transmission Control Protocol/Internet Protocol), providing a standard way. A network of multiple network layer protocols is transmitted on a point-to-point link.
  • the protocol includes various NCP protocol groups (Network Control Protocol), LCP protocol suite (Link Control Protocol), and authentication protocol. Family (Authent ication Protocol) and so on.
  • the NCP protocol family includes the IPCP protocol (Internet Protocol Control Protocol) and the IPX Control Protocol (IPX Control Protocol).
  • the authentication protocol family includes the CHAP protocol (Chal lenge Handshake Authent icat ion Protocol). Protocol) and PAP protocol (Password Authent icating Protocol).
  • the LCP protocol is mainly used to establish, tear down, and monitor PPP data links.
  • the NCP protocol is mainly used to negotiate the format and type of data packets transmitted on the link.
  • the authentication protocol is mainly used to provide network security assurance.
  • both ends of the PPP link In order to establish communication on the point-to-point link, both ends of the PPP link must send LCP packets for testing and configuration of the data link. After the link is established, it may also need to perform end-authentication. Then, the PPP sends an NCP packet to select and configure one or more network layer protocols. After the selected network layer protocol is successfully configured, packets sent by each network layer can be transmitted on the link. The link remains connected until there is a clear LCP or NCP packet disconnected, or some external event occurs, such as a timer timeout or network administrator intervention.
  • AAA server Authentication
  • MSCHAP1 protocol Microsoft CHAP vers ion 1 , Microsoft CHAP protocol version 1
  • MSCHAP2 protocol Microsoft CHAP vers ion 2, Microsoft CHAP protocol version 2
  • the existing solution 1 is based on physical location, such as slot, subcard, port, VLAN (Virtual Local Area Network) or PVC (Permanent Virtual Connection) of the user access device.
  • Configure the point-to-point authentication scheme to match the type of authentication supported by the AAA server.
  • All users accessing the interface use the authentication scheme configured on the interface to negotiate with the user during the LCP phase of the PPP negotiation process.
  • the type of authentication that is configured by the user on the interface is the authentication type configured on the interface. For example, if the authentication type configured on the interface is PAP, the authentication type negotiated by the user on the interface in the LCP phase is PAP.
  • the user dial-up process is as follows: Take the PPP over Ethernet (PPP over Ethernet) user as an example. If the CHAP authentication type is configured on the interface, the process is as follows:
  • the PPP negotiation includes the following steps:
  • the PPPoE server sends a Chal lenge message to the authentication client to provide a 128 lb Chal lenge;
  • the client After receiving the Chal lenge ⁇ message, the client sends the Response and response message to the PPPoE server after the password and Chal lenge are MD5 algorithm.
  • the PPPoE server sends an Access-Request (Authentication Request message) containing Chal lenge, Chal lenge- Pas sword and user name to the AAA server, and is authenticated by the AAA server.
  • the AAA server determines whether the user is legitimate according to the user information, and then responds
  • Access-Accept/Access-Reject (Authentication/Failure) to the PPPoE server; if the authentication is successful, it carries the negotiation parameters and the user's related business attributes to authorize the user;
  • the PPPoE server returns the authentication result (Success/Failure) to the client;
  • NCP such as IPCP
  • the PPPoE server initiates an accounting start request to the AAA server; (9) the AAA server responds to the charging start request message;
  • the user is authenticated at this time and has obtained legal rights to perform network services normally.
  • the network user (such as the PPPoE user terminal in FIG. 1) is connected to the network access server (NAS, Network Access Server) (such as the PPPoE server in FIG. 1), and implements the AAA server through the network intrusion service device.
  • NAS Network Access Server
  • Network connections Network users belong to different network operators and belong to different domains.
  • the network operator does not need a real network access service device, and only needs to rent it to the network service provider that actually owns the device.
  • multiple network operators may lease the same interface of the same network service provider's device.
  • the authentication types supported by the AAA servers used by different operators are different, if some do not support PAP, CHAP, or do not support MSCHAP1 and MSCHAP 2, the authentication protocol used by the network user and the AAA server for authentication may occur.
  • the inconsistent authentication types are supported, which leads to a large number of unrecognized authentication messages arriving at the AAA server, which increases the burden on the AAA server.
  • the networking diagram of the two operators renting the same interface is shown in Figure 2.
  • Carrier A and Carrier B use AAA server 1 and AAA server 2 respectively.
  • the authentication types supported by the two user authentication servers are PAP and CHAP.
  • the PPP mandatory authentication scheme configured on the interface is MSCHAP1 or MSCHAP2
  • the network users userl doml and user2 dom2 belonging to the carrier A and the operator B have accounts on the respective AAA servers.
  • the authentication packets sent from the network access service device to the AAA server cannot be verified, and the user cannot perform network services.
  • the interface is configured with a point-to-point authentication scheme. For PAP or CHAP, then at most one user user lQdoml and user2Mom2 can verify success.
  • the MA server can correctly identify the authentication request packet sent by the network access service device, and then the network user can pass the authentication request.
  • the AAA server cannot correctly identify the authentication request packet sent by the network access service device.
  • the main purpose of the embodiments of the present invention is to provide an authentication method, an authentication method, and a network intrusion service device.
  • the problem that the authentication request message sent by the access server to the AAA server is inconsistent with the authentication type supported by the AAA server is solved, thereby reducing the burden on the AAA server.
  • the embodiment of the present invention provides an authentication method, where the method includes: the network access service device and the network user perform LCP negotiation of the link control protocol, obtain the authentication type of the LCP negotiation, and learn the user's domain according to the user information provided by the network user. If the authentication type of the LCP negotiation is different from the authentication type configured in the domain where the network user is located, the LCP renegotiation is performed according to the authentication type configured in the domain where the network user is located. The network access service device re-negotiates according to the LCP. The authentication type configured in the domain where the user is located sends an authentication request packet.
  • the embodiment of the present invention further provides an authentication type negotiation method, where the method includes: the network access service device and the network user perform LCP negotiation to obtain an authentication type of the LCP negotiation; and learn the user's domain according to the user information provided by the network user. If the authentication type of the LCP negotiation is different from the authentication type configured in the domain where the network user is located, the LCP renegotiation is performed according to the authentication type configured in the domain where the network user is located. The final authentication type of the LCP negotiation is the domain configuration of the network user. Type of certification.
  • the embodiment of the present invention further provides a network access service device, which includes an LCP negotiation unit, which is used to negotiate the type of authentication used by the network user.
  • the authentication type storage unit is configured to store the authentication type configured in the domain where the network user is involved.
  • the comparison control unit is configured to control the LCP negotiation unit according to the authentication type configured in the domain where the network user is located, when the authentication type negotiated by the LCP negotiation unit is different from the authentication type configured in the domain of the network user in the authentication type storage unit. Perform LCP renegotiation.
  • the embodiment of the present invention performs LCP re-negotiation according to the authentication type configured in the domain where the network user is located, and then the network access service device re-negotiates according to the LCP.
  • the authentication type sends an authentication request packet to the authentication device. Therefore, the authentication request message map sent by the network access service device to the authentication device is consistent with the authentication type supported by the authentication device. In other words, the authentication device does not receive a large number of authentications that are inconsistent with the authentication types supported by the authentication device. The message is requested, thereby reducing the burden on the authentication device.
  • Figure 1 is a schematic flow chart of an existing user dial-up Internet access
  • Figure 2 is a schematic diagram of the networking of the existing two operators renting the same interface
  • FIG. 3 is a schematic flowchart of a preferred embodiment of an authentication method according to the present invention.
  • FIG. 4 is a schematic structural diagram of a preferred embodiment of a network access service device according to the present invention.
  • Authentication devices such as AAA servers are owned by their respective carriers. Different network operators use different domains, so users in the same domain use the same authentication devices. Furthermore, users in the same domain have the same authentication method, charging method, DNS (Domain Name Server) IP address, default service attribute, and the IP address and service port number of the AAA server corresponding to the domain, and so on.
  • DNS Domain Name Server
  • the policy of allowing users to be online even when the system loses billing capability is the same.
  • the user in the domain dials up to the Internet, and authenticates to the corresponding AAA server according to the IP address and service port number of the AAA server corresponding to the domain.
  • the preferred embodiment of the present invention will be described in detail below by taking a point-to-point mandatory authentication as an example.
  • the AAA server in the following embodiments corresponds to the authentication device of the present invention.
  • FIG. 3 is a schematic flowchart of a preferred embodiment of the authentication method of the present invention.
  • Step 310 The network user dials up to the Internet and performs LCP negotiation with the network access server.
  • the point-to-point authentication type is configured on the client dial-up software of the network user, and the authentication type is adaptive (auto), that is, when the user dials the Internet, the network user and the network access server are exchanged.
  • the authentication type of the negotiation is based on the authentication type specified by the client.
  • Step 320 The network access server compares the authentication type determined in the LCP negotiation phase with the point-to-point mandatory authentication type configured in the domain where the user is located, and determines whether the two are the same. If the network access service device and the user perform the LCP negotiation successfully (that is, after step 310), the user sends the information (such as the user name, password, etc.) to the network. Into the service equipment, so the net! ⁇ Into the service device, you can know which domain the user belongs to. If the two are the same, step 340 is performed; if the two are different, step 330 is performed.
  • the authentication type in the domain where the network user is involved is pre-configured in the network access service device, and the authentication type configured in each domain is consistent with the authentication type supported by the AAA server corresponding to the domain.
  • the authentication type of each of the three domains in the network access service device is a point-to-point mandatory authentication type, and the authentication type configured in each domain is the AAA server corresponding to the domain (that is, the user in the domain needs to be authenticated).
  • the AAA server supports the same authentication type.
  • the authentication type determined by the negotiation is not necessarily the authentication type configured in the domain where the network user is located, for example, the negotiated authentication type is The authentication type configured on the client dial-up software used by the network user.
  • the authentication type may not be the same as the authentication type configured in the domain where the network user is located.
  • Step 330 The network access server delivers the point-to-point mandatory authentication type configured in the domain where the network user is located, and performs LCP renegotiation according to the point-to-point mandatory authentication type configured in the domain. Specifically, the LCP renegotiation is performed by exchanging configuration packets.
  • the authentication type of the negotiation is the point-to-point authentication type configured in the domain where the network user is located. In other words, LCP renegotiation is performed according to the point-to-point mandatory authentication type configured in the domain where the network user is located. After the re-negotiation is successful, the point-to-point mandatory authentication type is returned. ,
  • Step 340 The network access service device sends an authentication request report according to the type of authentication negotiated by the LCP.
  • the text goes to the AAA server corresponding to the domain.
  • the final authentication type negotiated in the LCP phase is the same as the authentication type configured in the domain where the user is located, that is, the point-to-point mandatory authentication type, and the network access service device sends the authentication accordingly.
  • Request packets to the AAA server for authentication The authentication type configured in the domain is consistent with the authentication type supported by the AAA server corresponding to the domain. Therefore, the AAA server can identify the authentication request packet sent by the network access server, and the user may be able to pass the AAA server. Verification, smooth development of network business.
  • the authentication type in the domain does not match, the authentication type of the LCP phase negotiation and the authentication type of the domain where the network user is located are the same, and the authentication request packet type of the AAA server corresponding to the domain is sent to the AAA server.
  • the supported authentication types are the same. Therefore, the AAA server does not receive a large number of authentication request messages that are unrecognizable due to the mismatch of the authentication types, thereby reducing the burden on the AAA server.
  • the network access device can finally negotiate the authentication type into the authentication type in the domain where the network user is located through the IP re-negotiation process, and therefore, even the AAA server used by different network operators Different types of authentication are supported, and network service providers can also assign the same interface to these network operators. As a result, service providers are provided with greater flexibility, and it is not practical to assign different interfaces to each operator in a large-capacity BRAS (Broadband Remote Acces s Server).
  • BRAS Broadband Remote Acces s Server
  • the operator 1 uses the domain A
  • the carrier 1 authenticates the user in the domain A through the first AAA server.
  • the authentication type supported by the first AAA server is PAP
  • the carrier 2 uses the domain B
  • the carrier 1 uses the domain.
  • the user in B authenticates through the second AAA server, and the authentication type CHAP supported by the second AAA server.
  • the network service provider allocates the first interface of the network access service device that it owns to the operator 1 and the operator 2, and configures the authentication type in the domain A as the PAP and the configuration domain in the network access service device.
  • the authentication type in B is CHAP.
  • the user 1 is the user in the i or A, that is, the user belonging to the network to which the operator 1 belongs; the user 2 is the user in the domain B, that is, the user belonging to the network to which the operator 2 belongs.
  • the technical solution provided by the embodiment of the present invention is performed. Specifically, first, the user 1 and the network device enter the service device to perform the initial LCP negotiation. After the negotiation succeeds, the user 1 sends the authentication information such as the user name to the network intrusion service device, and further, the network access service device. It is known that user 1 belongs to domain A, and according to the pre-configured information, the authentication type configured in domain A is PAP. Then, the network access service device compares the authentication type negotiated with the initial LCP of the user 1 with the PAP authentication type (that is, the authentication type configured in the domain A where the user 1 is located), and if yes, sends an authentication request to the first AAA server.
  • the PAP authentication type that is, the authentication type configured in the domain A where the user 1 is located
  • the network access service device sends a PAP authentication type, and then renegotiates with user 1. If the authentication type after the renegotiation is successful is the PAP authentication type, the authentication request packet is sent to the first AAA server. It can be seen that, in the case of the user 1, the type of the authentication request packet sent by the network access service device to the first AAA server is the PAP authentication type supported by the first AAA server by using the technical solution provided by the embodiment of the present invention. The match is.
  • the user 2 and the network access service device perform the initial LCP negotiation. After the negotiation succeeds, the user 2 sends the authentication information such as the user name to the network access service device, and then, the network access.
  • the service device knows that the user 2 belongs to the domain B, and according to the pre-configured information, the authentication type configured in the domain B is CHAP.
  • the network access service device compares the authentication type negotiated with the initial LCP of the user 2 with the CHAP authentication type (that is, the authentication type configured in the domain B where the user 1 is located), and if yes, sends an authentication request to the first AAA server.
  • the network access service device sends a CHAP authentication type, and then renegotiates with user 2. If the authentication type after the renegotiation is successful is the CHAP authentication type, the authentication request packet is sent to the first AAA server accordingly. It can be seen that, in the case of the user 2, the authentication request packet type sent by the network access service device to the second AAA server is the CHAP authentication type supported by the second AAA server by using the technical solution provided by the embodiment of the present invention. The match is.
  • the network access service device does not send to the network access service device.
  • the authentication request packet type of an AAA server is inconsistent with the authentication type supported by the AAA server. In other words, users in domain A and users in domain B can successfully authenticate to their respective AAA servers through the first interface.
  • the technical solutions provided by the embodiments of the present invention can allocate the same interface to the multiple operators, and improve the utilization rate of the network access service devices.
  • the network operator does not need to tell the user the type of authentication supported by the AAA server in advance, so that the network user can finally use the correct authentication type for authentication, thereby avoiding certain network security risks.
  • the operator needs to switch the user-authenticated AAA server, and does not need to notify the user to adjust according to the authentication type supported by the new server, it is only necessary to modify the authentication type configured in the corresponding domain in the network intrusion service device, so Strong flexibility.
  • the present invention also discloses a network access service device.
  • FIG. 4 it is a schematic structural diagram of a network access service configuration according to a preferred embodiment of the present invention.
  • a network user and an AAA server that communicate with the network intrusion service device are exemplarily shown in FIG. 4, and the following works in conjunction with the device.
  • the principle further explains its internal structure.
  • the authentication type configured in the domain where the network user is located is the same as the authentication type supported by the AAA server corresponding to the domain.
  • the LCP negotiation unit 44 of the network access server performs LCP negotiation to determine the authentication type. Further, the LCP negotiation unit 44 informs the comparison sub-unit 421 in the comparison control unit 42 of the negotiation authentication type, and the comparison sub-unit 421 also acquires the authentication type configured in the domain where the network user is located from the authentication type storage unit 41, and compares the above two types of authentication. Types of.
  • the control sub-unit 422 notifies the authentication requesting unit 43 to send an authentication request message to the AAA server according to the authentication type of the current negotiation; if the comparison result is different, the B' J will be under the authentication type information configured in the domain where the network user is located. It is sent to the LCP negotiation unit 44, and the LCP negotiation unit is informed to perform renegotiation accordingly.
  • the LCP negotiation unit 44 is configured according to the domain in which the network user is located. After the authracization type is renegotiated, the comparison is performed by the comparison subunit 421, and so on, until the comparison result of the comparison subunit 422 is the same, the renegotiation is stopped. Further, the control subunit requests a message.
  • the authentication type finally negotiated is the authentication type configured in the domain where the network user is located, and further, the authentication request unit 43 is based on the network.
  • the authentication type configured in the domain of the user sends an authentication request packet to the AAA server.
  • the authentication is a point-to-point mandatory authentication.
  • the authentication type configured in the domain where the network user is located is the same as the authentication type supported by the AAA server corresponding to the domain, so that the authentication request message sent by the authentication requesting unit 43 according to the authentication type configured in the domain where the network user is located can be
  • the authentication request packet sent by the AAA server is the same as the authentication type supported by the AAA server. Therefore, the AAA server does not receive a large number of authentication request messages that cannot be identified due to the mismatch of authentication types, thereby reducing the burden on the AAA server.
  • the network access service device in this embodiment may also allocate the same interface to the network operators in different situations supported by the AAA servers used by different network operators. This gives the service provider greater flexibility.
  • the network access service device described in this embodiment can not only accurately implement user authentication, but also the network operator does not need to tell the user the type of authentication supported by the AAA server in advance, thereby avoiding certain network security risks. Moreover, if the operator needs to switch the user-authenticated AAA server, and does not have to notify the user to adjust according to the authentication type supported by the new server, it is only necessary to modify the authentication type configured in the corresponding domain in the network access service device, so Strong flexibility.
  • the above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope of the present invention. All should be covered by the scope of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种认证方法、 认证类型的协商方法及网^ 入服务设备 本申请要求于 2006 年 4 月 4 日提交中国专利局、 申请号为 200610034898. X, 发明名称为 "一种点到点协议强制认证方法和装置" 的 中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术械
本发明涉及网络管理技术领域， 尤其是一种认证方法、 一种认证类型 的协商方法以及一种网络接入服务设备。
背景技术
PPP协议 ( Point to Point Protocol , 点到点协议）是 TCP/IP协议 ( Transmis s ion Control Protocol/Internet Protocol , 传输控制协议 / 互联网协议）中数据链路层的协议， 提供一种标准的方式在点对点的链路 上传输多个网络层协议的数据包， ΡΡΡ协议包括各种 NCP协议族 ( Network Control Protocol , 网洛控制协议）、 LCP协议族（Link Control Protocol , 链路控制协议） 以及验证协议族 ( Authent ication Protocol )等。 其中， NCP协议族包括 IPCP协议（ Internet Protocol Control Protocol , 网络 协议控制协议）和 IPXCP ( IPX Control Protocol , IPX控制协议）等； 验 证协议族包括 CHAP协议 ( Chal lenge Handshake Authent icat ion Protocol , 挑战握手验证协议）和 PAP协议 ( Password Authent icat ion Protocol , 密码验证协议）等。
其中， LCP协议主要用来建立、 拆除和监控 PPP数据链路； NCP协议主 要用来协商链路上传输的数据包的格式和类型； 验证协议主要用来提供网 络安全的保证。
为了在点对点的链路上建立通信， PPP链路的两端必须发送 LCP数据包 进行数据链路的测试和配置， 等链路建立起来之后， 还可能需要进行端的 验证。 然后， PPP发送 NCP数据包选择并配置一个或多个网络层协议， 当所 选择的网络层协议配置成功之后，每个网络层发送的数据包就可以在链路 上传送了。 链路一直保持连接状态， 直到有明确的 LCP或者 NCP数据包断开 链路， 或某些外来的事件发生， 如定时器超时或者网络管理员干涉。
在验证阶段， 由于运营商采用 AAA服务器（Authenticat ion Authorizat ion and Account ing, 认证、 授权和计费)所支持的认证类型 存在差异， 例如， 有些 AAA I务器不支持 PAP协议，又有一些 AAA服务器不支 持 CHAP协议， 还有一些 AAA服务器不支持 MSCHAP1协议（Microsoft CHAP vers ion 1 ,微软 CHAP协议版本 1 )或MSCHAP2协议（ Microsoft CHAP vers ion 2, 微软 CHAP协议版本 2 )等等。 所以， 只有在对端采用的验证协议跟 AAA 服务器所支持的认证类型相一致的情况下， 才有可能通过验证； 否则， 就 会出现在 AAA服务器上存在该帐号而实际未通过验证的现象。
针对上述情形， 现有的解决方案一是基于物理位置， 如用户接入设备 的槽位、 子卡、 端口、 VLAN ( Virtual Local Area Network, 虚拟局域网） 或 PVC ( Permanent Virtual Connection, 永久虚连接）来配置点到点认 证方案， 使之与 AAA服务器所支持的认证类型相一致。 为了减少配置工作 量可将同一物理端口下一些 VLAN或 PVC，组成一个逻辑接口一起进行配置。 所有通过该接口接入的用户， 在 PPP协商过程的 LCP阶段， 设备使用该接口 下配置的认证方案与用户进行协商。 通过该接口上来的用户在 LCP阶段协 商的认证类型就是接口所配置的认证类型， 例如接口下配置的认证类型是 PAP, 则通过该接口上来的用户在 LCP阶段协商的认证类型就是 PAP。
如图 1所示的用户拨号上网流程示意图，取 PPPoE( PPP over Ethernet , 以太网承载 PPP协议）用户为例， 假设在接口下配置了 CHAP认证类型， 则 具体过程如下：
首先， 进行 PPPoE协商；
其次， 进行 PPP协商， 具体包括下述步驟：
( 1 )用户端和 PPPoE服务器之间进行点到点的 LCP协商， 建立链路层 通信， 同时协商使用 CHAP认证方式；
( 2 ) PPPoE服务器发送 Chal lenge (挑战）报文给认证用户端，提供一 个 128bi t的 Chal lenge;
( 3 )用户端收到 Chal lenge^艮文后，将密码和 Chal lenge做 MD5算法后， 发送 Response (响应） 艮文给 PPPoE月艮务器；
( 4 ) PPPoE服务器发送含 Chal lenge, Chal lenge- Pas sword和用户名 的 Access-Request (认证请求报文）到 AAA服务器， 由 AAA服务器进行认证。 (5) AAA服务器根据用户信息判断用户是否合法， 然后回应
Access-Accept/Access-Reject (认证成功 /失败） 艮文到 PPPoE月良务器； 如果认证成功， 携带协商参数， 以及用户的相关业务属性给用户授 权；
如果认证失败， 则流程到此结束；
(6) PPPoE服务器将认证结果（Success/Failure)返回给用户端；
(7)用户进行 NCP (如 IPCP)协商， 通过 PPPoE服务器获取到规划的 IP地址等参数；
(8)认证如果成功， PPPoE服务器发起计费开始请求给 AAA服务器； (9) AAA服务器回应计费开始请求报文；
用户此时通过认证，并且获得了合法的权限，可以正常开展网络业务。 目前， 网络用户 （如图 1中的 PPPoE用户终端）与网^ I姿入服务设备 (NAS, Network Access Server) (如图 1中的 PPPoE服务器）相连， 通过 网 矣入服务设备实现与 AAA服务器的网络连接。 网络用户属于不同的网 络运营商， 进而属于不同的域。 在目前的网络运营管理系统中， 网络运营 商不需要真正的网络接入服务设备， 只需要向真正拥有该设备的网络服务 供应商租用即可。 进而， 多个网络运营商可能租用同一个网络服务供应商 的设备的同一个接口。 但是， 由于不同运营商采用的 AAA服务器所支持的 认证类型存在差异，如有的不支持 PAP， CHAP,或者不支持 MSCHAP1、 MSCHAP 2 , 因此可能出现网络用户采用的验证协议与进行验证的 AAA服务器所支 持的认证类型不一致的现象， 进而导致大量无法识别的验证 4艮文到达 AAA 服务器， 加重了 AAA服务器的负担。
例如图 2所示两个运营商租用同一接口的组网示意图。运营商 A和运营 商 B分别采用 AAA服务器 1和 AAA服务器 2 , 这两台用户认证服务器所支持的 认证类型分别为 PAP和 CHAP。 按照现有的技术方案一， 如果接口下配置的 PPP强制认证方案为MSCHAP1或者MSCHAP2 , 那么分属于运营商 A和运营商 B 的网絡用户 userl doml和 user2 dom2虽然在各自的 AAA服务器上有账号， 但是自网络接入服务设备发到 AAA服务器上的验证报文均不能验证通过， 从而导致用户无法开展网络业务； 如果接口下配置的点到点强制认证方案 为 PAP或者 CHAP, 那么用户 user lQdoml和 user2Mom2最多只有一个用户能 够验证成功。
总而言之， 只有在 LCP阶段协商好的认证类型与 AAA服务器所支持的 认证类型相一致的情况下， MA服务器才能正确识别网络接入服务设备发 送过来的认证请求报文， 进而网络用户才有可能通过验证； 否则 AAA服务 器就无法正确识别网絡接入服务设备发送过来的认证请求报文，这些无法 正确识别的认证请求报文加重了 AAA服务器的负担。
发明内容
本发明实施例的主要目的在于提供一种认证方法、认证类型的协商方 法及网 矣入服务设备。 解决了接入服务器发给 AAA服务器的认证请求报 文与 AAA服务器所支持的认证类型不一致的问题，从而减轻了 AAA服务器的 负担。
本发明实施例提供了一种认证方法， 所述方法包括： 网络接入服务设 备和网络用户进行链路控制协议 LCP协商， 获得 LCP协商的认证类型； 根据 网絡用户提供的用户信息获知用户所在域内配置的认证类型； 如果上述 LCP协商的认证类型和网络用户所在域内配置的认证类型不同， 则根据网 络用户所在域内配置的认证类型进行 LCP重协商； 网络接入服务设备根据 LCP重协商成功的网络用户所在域内配置的认证类型发送认证请求报文。
本发明实施例还提供了一种认证类型的协商方法， 所述方法包括： 网 络接入服务设备和网络用户进行 LCP协商， 获得 LCP协商的认证类型； 根据 网络用户提供的用户信息获知用户所在域内配置的认证类型； 如果上述 LCP协商的认证类型和网络用户所在域内配置的认证类型不同， 则根据网 络用户所在域内配置的认证类型进行 LCP重协商； LCP协商的最终认证类型 为网络用户所在域内配置的认证类型。
本发明实施例还提供了一种网络接入服务设备， 包括 LCP协商单元， 用以同网络用户协商使用的认证类型； 认证类型存储单元， 用以存储所涉 及的网络用户所在域内配置的认证类型； 比较控制单元， 用以在 LCP协商 单元协商的认证类型与认证类型存储单元中网络用户所在域内配置的认 证类型不同时， 控制 LCP协商单元根据网络用户所在域内配置的认证类型 进行 LCP重协商。
以上本发明实施例的技术方案可以看出， 本发明实施例通过在网络接 类型不同条件下，根据网络用户所在域内配置的认证类型进行 LCP重协商， 进而网络接入服务设备根据 LCP重协商的认证类型发送认证请求报文到认 证设备。 由此， 使得网络接入服务设备发送给认证设备的认证请求报文图 与认证设备所支持的认证类型一致， 换而言之， 认证设备不会收到大量与 其所支持的认证类型不一致的认证请求报文， 从而减轻了认证设备的负 担。
附图说明
图 1为现有用户拨号上网的流程示意图；
图 2为现有两个运营商租用同一接口的组网示意图；
图 3为本发明认证方法优选实施例的流程示意图；
图 4为本发明网络接入服务设备的优选实施例结构示意图。
具体实施方式
认证设备（如 AAA服务器）属于各自运营商所有， 不同网络运营商使 用不同的域， 因此同一个域内的用户所使用的认证设备相同。 进而， 同一 个域内的用户具有相同的认证方法、计费方法、 DNS ( Domain Name Server , 域名服务器） IP地址、 缺省业务属性、 以及该域对应的 AAA服务器的 IP地 址和服务端口号等等， 甚至当系统失去计费能力时是否允许用户在线的策 略都是相同的。 域内的用户拨号上网， 根据域所对应的 AAA服务器的 IP地 址和服务端口号到相应的 AAA服务器上去认证。
下面以一种点到点强制认证为例详细介绍本发明的优选实施例。 以下 各实施例中的 AAA服务器对应于本发明的认证设备。
请参阅图 3, 其为本发明认证方法优选实施例的流程示意图。
步驟 310: 网絡用户拨号上网，与网络接入服务器进行 LCP协商。例如， 在网络用户的客户端拨号软件上配置点到点认证类型， 网 入服务设备 接口下配置认证类型为自适应 （auto ) , 即当用户拨号上网时， 网络用户 和网络接入服务器通过交换配置报文， 进行 LCP协商， 建立链路并确定认 证类型。 由于网^ 入服务设备接口下配置认证类型为自适应， 因此本次 协商的认证类型一般以客户端指定的认证类型为准。
步骤 320: 网络接入服务器将 LCP协商阶段确定的认证类型和该用户 所在域内配置的点到点强制认证类型比较， 判断两者是否相同。 需要补充 说明， 根据现有认证流程可知， 在网络接入服务设备和用户进行 LCP协商 成功后（即执行步骤 310后） ， 用户会将自己的信息（如用户名、 密码等） 发送给网络接入服务设备， 因此网！^矣入服务设备就可以知道该用户属于 哪个域了。 如果二者相同则执行步骤 340; 如果二者不同则执行步骤 330。
优选地， 在网络接入服务设备中预先配置其所涉及的网络用户所在域 内的认证类型， 每个域内配置的认证类型与该域对应的 AAA服务器所支持 的认证类型相一致。 例如， 假设网絡接入服务设备的某一接口被租用给三 个网络运营商， 这三个网络运营商使用的域不同， 每个网络运营商采用的 AAA服务器也不同，但是同一个域内的用户都需要到同一台 AAA服务器进行 认证。 于是， 就可以在网络接入服务设备中配置这三个域内各自的认证类 型为点到点强制认证类型， 每个域内配置的认证类型与该域对应的 AAA服 务器（即域内用户需要去认证的那台 AAA服务器）所支持的认证类型相同。
由于在步骤 310中配置接口下的认证类型为自适应， 因此在与网络用 户进行初次 LCP协商时 , 协商确定的认证类型不一定是该网络用户所在域 内配置的认证类型， 例如协商的认证类型是网络用户使用的客户端拨号软 件上配置的认证类型， 而该认证类型实际和网络用户所在域内配置的认证 类型可能并不相同。
步骤 330: 网络接入服务器将网络用户所在域内配置的点到点强制认 证类型下发， 根据该域内配置的点到点强制认证类型进行 LCP重协商。 具 体而言， 通过交换配置报文， 进行 LCP重协商， 协商的认证类型为网络用 户所在域内配置的点到点强制认证类型。 换而言之， 根据该网络用户所在 域内配置的点到点强制认证类型进行 LCP重协商。 重协商成功后， 再返回 的点到点强制认证类型。 ，
步骤 340: 网絡接入服务设备根据 LCP协商的认证类型发送认证请求报 文到该域对应的 AAA l务器。 通过前述步驟 310至 330的操作后， 此时 LCP阶 段协商的最终认证类型和该用户所在域内配置的认证类型相同， 即都是点 到点强制认证类型， 进而网络接入服务设备据此发送认证请求报文到 AAA 服务器进行认证处理。 由于在域内配置的认证类型与该域对应的 AAA服务 器所支持的认证类型相一致， 因此， AAA服务器能够识別网络接入服务器 发送过来的认证请求报文， 进而用户有可能能够通过 AAA服务器的验证， 顺利开展网络业务。 域内的认证类型不匹配情况下，通过重协商实现 LCP阶段协商的认证类型 和网络用户所在域内的认证类型相同， 进而据此发给该域对应的 AAA服务 器的认证请求报文类型和该 AAA服务器所支持的认证类型一致。于是， AAA 服务器就不会接收到大量由于认证类型不匹配导致无法识别的认证请求 报文， 从而减轻了 AAA服务器的负担。
进一步， 在本发明实施例公开的技术方案中， 由于网络接入设备可以 通过 I P 重协商过程将认证类型最终协商为网络用户所在域内的认证类 型，因此，即使不同网络运营商采用的 AAA服务器所支持的认证类型不同， 网络服务供应商也可以为这些网络运营商分配同一个接口。 由此， 给服务 供应商提供了较大的灵活性， 而且在大容量的 BRAS ( Broadband Remote Acces s Server , 宽带远程接入服务器） 中， 给每个运营商分配不同的接 口也是不现实的。
例如， 运营商 1使用域 A, 运营商 1对域 A内的用户通过第一 AAA服 务器进行验证， 第一 AAA服务器所支持的认证类型是 PAP; 运营商 2使用 域 B， 运营商 1对域 B内的用户通过第二 AAA服务器进行验证， 第二 AAA 服务器所支持的认证类型 CHAP。网络服务供应商将其拥有的一台网络接入 服务设备的第一接口分配给运营商 1和运营商 2使用， 并在网络接入服务 设备中配置域 A内的认证类型为 PAP, 配置域 B内的认证类型为 CHAP。
^设用户 1是 i或 A内的用户， 即属于运营商 1所属网络的用户； 用户 2是域 B内的用户， 即属于运营商 2所属网络的用户。
如果用户 1拨号上网， 则根据上述本发明实施例提供的技术方案进行 处理， 具体而言， 首先用户 1和网^ #入服务设备进行初次 LCP协商， 协 商成功后， 用户 1会向网 矣入服务设备发送自己的用户名等认证信息， 进而， 网络接入服务设备就知道用户 1属于域 A, 而根据预先配置的信息 可知， 域 A内配置的认证类型为 PAP。 于是， 网络接入服务设备将与用户 1初次 LCP协商的认证类型与 PAP认证类型 （即用户 1所在域 A内配置的 认证类型）比较是否一致， 如果一致则向第一 AAA服务器发送认证请求报 文； 如果不一致， 网络接入服务设备下发 PAP认证类型， 据此与用户 1进 行重协商。 如果重协商成功后的认证类型是 PAP认证类型， 则据此向第一 AAA服务器发送认证请求报文。 由此可见， 就用户 1而言， 通过本发明实 施例提供的技术方案， 网络接入服务设备向第一 AAA服务器发送的认证请 求报文类型就是第一 AAA服务器所支持的 PAP认证类型， 两者是匹配的。
同理， 如果用户 2拨号上网， 首先用户 2和网络接入服务设备进行初 次 LCP协商， 协商成功后， 用户 2会向网络接入服务设备发送自己的用户 名等认证信息， 进而， 网络接入服务设备就知道用户 2属于域 B, 而根据 预先配置的信息可知， 域 B内配置的认证类型为 CHAP。 于是， 网络接入服 务设备将与用户 2初次 LCP协商的认证类型与 CHAP认证类型 （即用户 1 所在域 B内配置的认证类型）比较是否一致， 如果一致则向第一 AAA服务 器发送认证请求报文； 如果不一致， 网络接入服务设备下发 CHAP认证类 型， 据此与用户 2进行重协商。 如果重协商成功后的认证类型是 CHAP认 证类型， 则据此向第一 AAA服务器发送认证请求报文。 由此可见， 就用户 2而言，通过本发明实施例提供的技术方案，网络接入服务设备向第二 AAA 服务器发送的认证请求报文类型就是第二 AAA服务器所支持的 CHAP认证 类型， 两者是匹配的。
由此可见， 虽然域 A内的用户 1和域 B内的用户 2都通过网絡接入服 务设备的第一接口连接到对应的 AAA服务器去认证， 但是并不会出现网络 接入服务设备发送到某个 AAA服务器的认证请求报文类型与该 AAA服务 器所支持的认证类型不一致的现象。 换而言之， 域 A内的用户和域 B内的 用户都可以通过第一接口顺利的到各自对应的 AAA月 务器上去认证。
综上所述， 即使多个运营商对应域内使用的 AAA服务器所支持的认证 类型不同， 采用本发明实施例提供的技术方案， 可以为上述多个运营商分 配同一个接口， 提高了网^ 入服务设备的利用率。
更进一步， 由于重协商过程的存在， 使得网络运营商不必预先告诉用 户 AAA服务器所支持的认证类型， 就可以使网络用户最终采用正确的认证 类型进行认证， 因此避免了一定的网络安全隐患。 另外， 如果运营商需要 切换用户认证的 AAA服务器， 不必通知用户根据新的服务器所支持的认证 类型进行调整， 只需在网 妾入服务设备中修改相应域内配置的认证类型 即可， 因此具有较强的灵活性。 需要说明， 虽然上述优选实施例包括 LCP 协商 （重协商） 阶段和认证两个阶段， 但是本领域技术人员应该意识到， 根据网络用户所在域内配置的认证类型进行 LCP重协商是本发明实施例的 实质所在， 这一实质内容可以单独或结合其他相关技术使用， 并不仅仅局 限于作为发送认证请求报文的依据。
基于与上述认证方法的同一发明构思， 本发明还公开了一种网络接入 服务设备， 请参阅图 4 , 其为本发明网络接入服务设 ^尤选实施例的结构 示意图。 为了更全面的揭示本实施例所示的网络接入服务设备内部结构， 还在图 4中示例性的给出与网 矣入服务设备相互通信的网络用户和 AAA 服务器， 下面结合该装置的工作原理对其内部结构做进一步说明。 对于前 文已经详述过的相同或相应技术特征， 本实施例筒要概括。 证类型， 网络用户所在域内配置的认证类型与该域对应的 AAA服务器所支 持的认证类型相同。当网络用户通过拨号上网后，与网络接入服务器的 LCP 协商单元 44进行 LCP协商， 确定认证类型。 进而， LCP协商单元 44将协商认 证类型告知比较控制单元 42中的比较子单元 421 , 比较子单元 421还从认证 类型存储单元 41中获取该网络用户所在域内配置的认证类型， 比较上述两 种认证类型。
如果比较结果相同， 则控制子单元 422通知认证请求单元 43根据本次 协商的认证类型向 AAA服务器发送认证请求报文； 如果比较结果不同， 贝' J 将网络用户所在域内配置的认证类型信息下发给 LCP协商单元 44， 并告知 LCP协商单元据此进行重协商。 LCP协商单元 44根据网络用户所在域内配置 的认证类型进行重协商后， 再通过比较子单元 421进行比较， 依次类推， 直到比较子单元 422的比较结果为相同时停止重协商。 进而， 控制子单元 请求报文。 由此可以看出， 无论 LCP协商单元 44是否需要根据控制子单元 422的指示进行重协商， 最终协商的认证类型都是网络用户所在域内配置 的认证类型， 进而， 认证请求单元 43都是根据网络用户所在域内配置的认 证类型向 AAA服务器发送认证请求报文。 所述认证为点到点强制认证。
正是由于网络用户所在域内配置的认证类型和该域对应的 AAA月良务器 所支持的认证类型相同，使得认证请求单元 43根据网络用户所在域内配置 的认证类型发送的认证请求报文能够被 AAA服务器所识别， 即网 矣入服 务设备发送给 AAA服务器的认证请求报文与 AAA服务器所支持的认证类型 一致。 因此， AAA服务器就不会接收到大量由于认证类型不匹配导致无法 识别的认证请求报文， 从而减轻了 AAA服务器的负担。
此外， 使用本实施例所述的网絡接入服务设备， 在不同网络运营商采 用的 AAA服务器所支持的认证类型不同情况下， 也可以为这些网络运营商 分配同一个接口。 由此， 给服务供应商提供了较大的灵活性。
另外， 采用本实施例所述的网络接入服务设备， 不但可以准确的实现 用户通过认证， 而且网絡运营商不必预先告诉用户 AAA服务器所支持的认 证类型， 从而避免了一定的网络安全隐患。 而且， 如果运营商需要切换用 户认证的 AAA服务器， 不必通知用户根据新的服务器所支持的认证类型进 行调整， 只需在网络接入服务设备中修改相应域内配置的认证类型即可， 因此具有较强的灵活性。 以上所述， 仅为本发明较佳的具体实施方式, 但 本发明的保护范围并不局限于此，任何熟悉该技术的人员在本发明所揭露 的技术范围内， 可轻易想到的变化或替换， 都应涵盖在本发明的保护范围 之内。

Claims

权 利 要 求
1、 一种认证方法， 其特征在于， 所述方法包括：
网络接入服务设备和网络用户进行链路控制协议 LCP协商， 获得 LCP协 商的认证类型；
根据网絡用户提供的用户信息获知用户所在域内配置的认证类型； 如果上述 LCP协商的认证类型和网络用户所在域内配置的认证类型不 同， 则根据网络用户所在域内配置的认证类型进行 LCP重协商；
网络接入服务设备才艮据 LCP重协商成功的网络用户所在域内配置的认 证类型发送认证请求报文。
1、 根据权利要求 1 所述的认证方法， 其特征在于， 所述方法还包括， 在网络接入服务设备中预先存储其所涉及的各域内配置的认证类型信息。
3、 根据权利要求 2 所述的认证方法， 其特征在于， 所述根据网络用 户提供的用户信息获知用户所在域内配置的 i人证类型具体过程包括：
根据网络用户提供的用户信息获知该用户所在域；
在所述存储的认证类型信息中查到该用户所在域内配置的认证类型。
4、 根据权利要求 1所述的认证方法， 其特征在于， 网络用户所在域内 配置的认证类型与该域对应的 AAA服务器所支持的认证类型相同，
所述发送认证请求报文具体为： 发送认证请求报文至网络用户所在域 对应的 AAA服务器。
5、 根据权利要求 1至 4中任意一项所述的认证方法， 其特征在于， 所 述 LCP重协商的具体过程包括：
网 ^^入服务设备下发网络用户所在域内配置的认证类型；
根据上述域内配置的认证类型与网络用户进行 LCP重协商。
6、 根据权利要求 1至 4中任意一项所述的认证方法， 其特征在于， 所 述认证为点到点强制认证。
7、 一种认证类型的协商方法， 其特征在于， 所述方法包括： 网络接入服务设备和网络用户进行 LCP协商， 获得 LCP协商的认证类 型；
根据网络用户提供的用户信息获知用户所在域内配置的认证类型； 如果上述 LCP协商的认证类型和网络用户所在域内配置的认证类型不 同 , 则根据网络用户所在域内配置的认证类型进行 LCP重协商；
LCP协商的最终认证类型为网络用户所在域内配置的认证类型。
8、 根据权利要求 7所述的协商方法， 其特征在于， 所述 LCP重协商的 步骤具体为：
网络接入服务设备下发网络用户所在域内配置的认证类型； 才艮据所述域内配置的认证类型与网络用户进行 LCP重协商。
9、 一种网絡接入服务设备， 其特征在于包括：
LCP协商单元， 用以同网络用户协商使用的认证类型；
认证类型存储单元， 用以存储所涉及的网絡用户所在域内配置的认证 类型； 单元中网络用户所在域内配置的认证类型不同时， 控制 LCP协商单元根据 网絡用户所在域内配置的认证类型进行 LCP重协商。
10、 根据权利要求 9所述的网络接入设备， 其特征在于： 所述网 入服务设备还包括：
认证请求单元， 用以根据 LCP协商单元协商的最终认证类型发送认证 请求报文， 所述最终认证类型与网络用户所在域内配置的认证类型相同。
11、 如权利要求 10所述的网络接入设备， 其特征在于： 所述认证请求 报文的目的地址为网络用户所在域对应的 AAA服务器，网络用户所在域内 配置的认证类型与该域对应的 AAA服务器所支持的认证类型相同。
12、 根据权利要求 9所述的网络接入服务设备， 其特征在于， 所述比 较控制单元具体包括信息比较子单元和控制子单元， 其中 元中网络用户所在域内配置的认证类型进行比较；
控制子单元， 用以在比较子单元的比较结果为不同时， 将认证类型存 储单元中网络用户所在域内配置的认证类型信息下发给所述的 LCP协商单 元， 并告知 LCP协商单元据此进行重协商。
13、 如权利要求 9至 12所述的网络接入设备， 其特征在于： 所述认证 为点到点强制认证。
PCT/CN2006/003409 2006-04-04 2006-12-14 Procédé d'authentification, procédé de négociation du type d'authentification, et dispositif de fourniture d'accès au réseau WO2007112624A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB200610034898XA CN100546305C (zh) 2006-04-04 2006-04-04 一种点到点协议强制认证方法和装置
CN200610034898.X 2006-04-04

Publications (1)

Publication Number Publication Date
WO2007112624A1 true WO2007112624A1 (fr) 2007-10-11

Family

ID=37298277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/003409 WO2007112624A1 (fr) 2006-04-04 2006-12-14 Procédé d'authentification, procédé de négociation du type d'authentification, et dispositif de fourniture d'accès au réseau

Country Status (2)

Country Link
CN (1) CN100546305C (zh)
WO (1) WO2007112624A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102739657A (zh) * 2012-06-15 2012-10-17 中兴通讯股份有限公司 一种对接TACACS+服务器的enable认证方法及系统
CN113206827B (zh) * 2021-03-29 2022-10-21 北京华三通信技术有限公司 报文处理方法及装置
CN114051244A (zh) * 2021-11-10 2022-02-15 杭州萤石软件有限公司 一种终端侧设备与网络侧设备之间的认证方法、系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003234795A (ja) * 2002-02-08 2003-08-22 Fujitsu Access Ltd プロトコル変換通信方法及び該変換機能を備えた中継装置
JP2003244188A (ja) * 2002-02-21 2003-08-29 Nippon Telegr & Teleph Corp <Ntt> トンネル通信方法
CN1486013A (zh) * 2002-09-23 2004-03-31 华为技术有限公司 一种对网络接入用户进行认证的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003234795A (ja) * 2002-02-08 2003-08-22 Fujitsu Access Ltd プロトコル変換通信方法及び該変換機能を備えた中継装置
JP2003244188A (ja) * 2002-02-21 2003-08-29 Nippon Telegr & Teleph Corp <Ntt> トンネル通信方法
CN1486013A (zh) * 2002-09-23 2004-03-31 华为技术有限公司 一种对网络接入用户进行认证的方法

Also Published As

Publication number Publication date
CN100546305C (zh) 2009-09-30
CN1859415A (zh) 2006-11-08

Similar Documents

Publication Publication Date Title
US7624181B2 (en) Techniques for authenticating a subscriber for an access network using DHCP
JP4291213B2 (ja) 認証方法、認証システム、認証代行サーバ、ネットワークアクセス認証サーバ、プログラム、及び記録媒体
US8484695B2 (en) System and method for providing access control
KR101093902B1 (ko) 사용자가 ｉｐ 망에 접속시 로컬 관리 도메인에서 사용자를 위한 접속 인증을 관리하는 방법 및 시스템
WO2006063511A1 (fr) Procede permettant de realiser une authentification synchrone parmi differents dispositifs de commande d&#39;authentification
CN101127600A (zh) 一种用户接入认证的方法
KR101162290B1 (ko) 서비스에 액세스를 위해 가상 네트워크에 액세스를 가능하게 하는 클라이언트에 대한 승인 방법 및 시스템
WO2018191854A1 (zh) 接入固定网络的方法和接入网关网元
WO2008034319A1 (fr) Procédé, système et dispositif d&#39;authentification destinés à un dispositif de réseau
CN108738019B (zh) 融合网络中的用户认证方法及装置
CN101867476A (zh) 一种3g虚拟私有拨号网用户安全认证方法及其装置
WO2016192608A2 (zh) 身份认证方法、身份认证系统和相关设备
WO2014101449A1 (zh) 一种无线局域网中接入节点的控制方法及通信系统
US20090113522A1 (en) Method for Translating an Authentication Protocol
WO2014176964A1 (zh) 一种通信管理方法及通信系统
EP2894904B1 (en) Wlan user fixed network access method and system
WO2012051868A1 (zh) 防火墙策略分发方法、客户端、接入服务器及系统
WO2013056619A1 (zh) 一种身份联合的方法、IdP、SP及系统
WO2012034413A1 (zh) 一种双栈用户管理方法及宽带接入服务器
KR20040102045A (ko) 자동 구성 특성을 지닌 정보 라우팅 장치
WO2009082950A1 (fr) Procédé, dispositif et système de distribution de clés
WO2007112624A1 (fr) Procédé d&#39;authentification, procédé de négociation du type d&#39;authentification, et dispositif de fourniture d&#39;accès au réseau
WO2011147334A1 (zh) 提供虚拟私有网业务的方法、设备和系统
WO2013034056A1 (zh) 一种位置信息处理方法和系统
Huawei Technologies Co., Ltd. WAN Fundamentals

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06828325

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06828325

Country of ref document: EP

Kind code of ref document: A1