[go: up one dir, main page]

WO2009009972A1 - Procédé et système pour mettre en œuvre une authentification - Google Patents

Procédé et système pour mettre en œuvre une authentification Download PDF

Info

Publication number
WO2009009972A1
WO2009009972A1 PCT/CN2008/070977 CN2008070977W WO2009009972A1 WO 2009009972 A1 WO2009009972 A1 WO 2009009972A1 CN 2008070977 W CN2008070977 W CN 2008070977W WO 2009009972 A1 WO2009009972 A1 WO 2009009972A1
Authority
WO
WIPO (PCT)
Prior art keywords
dhcp
dhcp client
client
authentication
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/CN2008/070977
Other languages
English (en)
Chinese (zh)
Inventor
Amy Zhao
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 WO2009009972A1 publication Critical patent/WO2009009972A1/fr
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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the present invention relates to Internet Protocol (IP) network technology, and in particular, to a method and system for implementing authentication in a Dynamic Host Configuration Protocol (DHCP).
  • IP Internet Protocol
  • DHCP Dynamic Host Configuration Protocol
  • FIG. 1 shows the workflow of the existing DHCP. As shown in Figure 1, the following steps are included:
  • Step 101 The DHCP client sends a DHCP Discovery (DISCOVER) message to the DHCP server.
  • DISCOVER DHCP Discovery
  • Step 102 The DHCP server sends a DHCP Offer (OFFER) packet to the DHCP client.
  • Each DHCP server with a free address in the network responds to the DHCP DISCOVER message sent by the DHCP client, and sends a DHCP OFFER message to the DHCP client, and the DHCP OFFER message "Your address (yiaddr) "The domain carries the provided network IP address and some DHCP options (options) configuration parameter information associated with the IP address.
  • Step 103 The DHCP client sends a DHCP Request (REQUEST) message to the DHCP server.
  • the DHCP client selects a DHCP OFFER message from the received DHCP OFFER message sent by the multiple DHCP servers, for example, selecting the DHCP OFFER message sent by the first arriving DHCP server, and broadcasting a DHCP REQUEST message to Tell each DHCP server in the network that the DH CP client will specify which DHCP server provides the IP address.
  • Step 104 The DHCP server selected by the DHCP client sends DHCP to the DHCP client. Acknowledge (ACK) or DHCP unacknowledged (NAK).
  • ACK Acknowledge
  • NAK DHCP unacknowledged
  • the DHCP server sends a DHCP ACK packet to the DHCP client to confirm that the IP lease is valid.
  • the DHCP ACK packet also carries some configuration parameters related to the IP address, and it is necessary to ensure that the configuration parameters in this step cannot conflict with the configuration parameters mentioned in step 102.
  • the DHCP server will send a DHCP NAK 4 message to the DHCP client to notify DHCP.
  • the client IP address configuration failed.
  • the DHCP client can also send an Address Resolution Protocol (ARP) packet to the network to check whether there are other devices in the network that use the IP address. Yes, a DHCP DECLINE message is sent to the DHCP server, the configured IP address is rejected, and the D HCP DISCOVER message is resent.
  • ARP Address Resolution Protocol
  • DHCP version 4 (v4). If it is DHCPv6, except for the different types of packets, DHCP DISCOVER, DHCP OFFER, DHCP REQUEST and DHCP ACK are shown in Figure 1.
  • DHCP DISCOVER DHCP OFFER
  • DHCP REQUEST DHCP REQUEST
  • DHCP ACK DHCP ACK
  • SOLICIT request (SOLICIT)
  • ADVE RTISE, REQUEST, and REPLY messages other workflows, such as message interaction and the functions of each message, are the same as DHCPv4.
  • EAP Authentication Protocol
  • EAP is an authentication framework that can support multiple authentication modes. EAP packets can be carried by different protocols, such as authentication, authorization, and accounting (AAA).
  • AAA authentication, authorization, and accounting
  • the industry standard that carries EAP for authentication is defined in the Remote Authentication Dial In User Service (Radius) and the next-generation AAA protocol Diameter.
  • EAP mainly includes four message formats, namely request, response, success, and failure (fai lure).
  • FIG. 2 is a schematic diagram of an existing EAP message interaction manner. As shown in Figure 2, the EAP request and the EAP response are always in pairs. Moreover, the number of EAP request and EAP response pairs and the information carried by them are not fixed, and need to be determined according to the authentication method used in the actual application. .
  • a method of combining the DHCP and the EAP to implement user authentication has been proposed in the prior art.
  • the method is to carry the EAP payload by adding a new DHCP format DHCPEAP, and the EAP method is used for authentication, and after the authentication succeeds. , assign the IP address and related parameters to the client.
  • FIG. 3 is a schematic diagram of a method for implementing user authentication in DHCP through EAP. As shown in Figure 3, the following steps are included:
  • Step 301 The DHCP client sends a DHCP DISCOVER message to the network access server (N AS).
  • the DHCP Discovery (DHCP DISCOVER) message in this step carries the DHCP_AUTH_pro to option, which is used to identify that the subsequent steps will use ⁇ for authentication.
  • Step 302 The NAS sends a DHCPEAP packet to the DHCP client, where the payload carries an EAP request message.
  • Step 303 The DHCP client sends a DHCPEAP message to the NAS, and the payload carries an EAP response message.
  • Step 304 The NAS strips the EAP payload in the DHCP EAP, and carries the EAP payload in the AAA protocol, such as Radius, to the AAA server.
  • AAA protocol such as Radius
  • Step 305 The AAA server sends an authentication success packet to the NAS, such as an Access-Accept message in the Radius protocol.
  • Step 306 The NAS sends a DHCP Offer (DHCP OFFER) message to the DHCP client.
  • DHCP OFFER DHCP Offer
  • the DHCP OFFER packet carries the IP address provided by the NAS to the DHCP client and related configuration parameter information.
  • step 1 03 and step 1 04 shown in FIG. 1 The subsequent processing is the same as step 1 03 and step 1 04 shown in FIG. 1 and will not be described again.
  • the method shown in Figure 3 implements user authentication in DHCP through EAP, this method has the following drawbacks:
  • the failure message also needs to be carried by the OFFER message.
  • the "yi addr" field in the OFFER message loses its meaning.
  • the DHCP client needs to check whether the authentication succeeds or fails before it can be checked.
  • OFFER message the same problem, is the need to make major changes to the existing state machine and implementation, increasing the complexity of the implementation.
  • re-authentication refers to repeated authentication due to various needs after the first authentication.
  • the embodiment of the invention provides three methods for implementing authentication, which can implement the authentication mechanism in DHCP.
  • the embodiment of the invention simultaneously provides three systems for implementing authentication, which can be implemented in a single DHCP. Certification mechanism.
  • a method of implementing authentication comprising:
  • the network side receives the DHCP request packet from the DHCP client of the dynamic host configuration protocol, authenticates the DHCP client, and sends a response message to the DHCP client for the success or failure of the authentication.
  • a method of implementing authentication comprising:
  • the network side authenticates the DHCP client that sends the packet to the DHCP client. If the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client. If the authentication fails, the DHCP client sends a DHCP unacknowledgment message to the DHCP client.
  • a method of implementing authentication comprising:
  • the network side receives the DHCP discovery packet from the DHCP client, and the DHCP discovery packet carries the quick confirmation option information; the network side authenticates the DHCP client, and sends back the authentication success to the DHC P client.
  • the response is 4 essays.
  • a system for implementing authentication comprising: a DHCP client and a network side;
  • the DHCP client is configured to send a DHCP request message to the network side, and receive a response text of the authentication success or not sent by the network side;
  • the network side is configured to authenticate the DHCP client after receiving the DHCP request from the DHCP client, and send back a response to the DHCP client.
  • a system for implementing authentication comprising: a DHCP client and a network side;
  • the DHCP client is configured to send a message to the network side, and receive a response message that the network side sends back the authentication success or not;
  • the network side is configured to authenticate the DHCP client, and if the authentication succeeds, send a DHCP confirmation message to the DHCP client; if the authentication fails, send back D to the DHCP client.
  • a system for implementing authentication comprising: a DHCP client and a network side;
  • the DHCP client is configured to send, to the network side, a D HCP discovery message carrying the fast acknowledgment option information, and receive a response message that the network side sends back the authentication success or not; After receiving the discovery file from the DHCP client, the DHC P client is authenticated, and the response of the authentication success or not is sent back to the DHCP client.
  • the network side authenticates the DHCP client and sends it back to the DHCP client. Response message for successful authentication.
  • the authentication process is triggered. That is, the DHCP client has obtained the address information or the DHCP client does not need to obtain the address according to the selected mode. In the case of information, the authentication process is triggered, so there is no problem of resource waste due to the use of the address information selection method in the prior art and the need to modify the existing state machine corresponding to this step.
  • the network side if the authentication succeeds, the network side sends a DHCP acknowledgement message to the DHCP client. If the authentication fails, the network side sends a DHCP unacknowledged message to the DHCP client, that is, the current use.
  • the result of the DHCP protocol confirms that the packet is sent back to the authentication result information, and the original message format does not need to be changed as in the prior art, thereby reducing the complexity of the implementation.
  • Figure 1 is a schematic diagram of an existing DHCP workflow
  • FIG. 2 is a schematic diagram of an existing EAP message interaction manner
  • FIG. 3 is a schematic diagram of a method for implementing user authentication in DHCP through EAP;
  • FIG. 4 is a flow chart of a first embodiment of a method of the present invention.
  • Figure 5 is a flow chart of a second embodiment of the method of the present invention.
  • Figure 6 is a flow chart of a third embodiment of the method of the present invention.
  • Figure 7 is a flow chart of a fourth embodiment of the method of the present invention.
  • Figure 8 is a schematic view showing the structure of a first embodiment of the system of the present invention. detailed description
  • the network side receives the DHCP request message from the DHCP client, authenticates the DHCP client, and sends a response message to the DHCP client for the success or failure of the authentication.
  • the network side Before receiving the DHCP request packet from the DHCP client, the network side further includes: D
  • the HCP client obtains the address information from the network side, and the specific information includes: the DHCP client sends a DHC P-discovery message to the network side; the network side sends a DHCP-provided message to the DHCP client, and the DHCP-provided message carries the information provided to the DHCP client. IP address and configuration parameter information.
  • re-authentication can be triggered by the DHCP client or by the DHCP server.
  • the DHCP client needs to trigger re-authentication, including the following two types:
  • the DHCP client records the IP address before the restart.
  • the DHCP client sends a DHCP REQUEST to the DHCP server and carries the IP address to continue to use it. At the same time, it requests relevant configuration parameters.
  • the DHCP client does not record the IP address before the restart. This situation is the same as the first authentication. It needs to send a DHCP DISCOVER to the DHCP server.
  • the DHCP client When the DHCP client performs address update, it needs to be re-authenticated for security reasons or a means of periodic authentication.
  • the situation in which the DHCP server needs to trigger re-authentication mainly includes:
  • the DHCP server changes the policy of the accessed user for some specific reasons, or recovers the original The certification that comes.
  • the DHCP server needs to periodically request the DHCP client to re-authenticate for security reasons.
  • the DHCP client If the DHCP client triggers the re-authentication, the DHCP client will send a DHCP Request message to the network. After receiving the DHCP Request message, the network side authenticates the DHCP client.
  • the network side first sends a mandatory update message to the DHCP client. After receiving the forced update message, the DHCP client sends a DHCP request message to the network side. After receiving the DHCP request packet, the DHCP client is authenticated.
  • the network sends a response message indicating whether the authentication succeeds to the DHCP client. For example, if the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client. If the authentication fails, the DHCP client sends a DHCP acknowledgement message to the DHCP client. Text.
  • FIG. 4 is a flow chart of a first embodiment of a method of the present invention. Assume that E is adopted by the network side in this embodiment.
  • the AP authentication mode is the one-time pas sword (OTP) authentication method. Then, as shown in Figure 4, the following steps are included:
  • Step 4 01 The DHCP client sends a DHCP discovery (DHCP DI SCOVER) to the NAS.
  • DHCP DI SCOVER DHCP DI SCOVER
  • the network side is specifically divided into two parts, a NAS and an AAA server according to its actual composition.
  • the NAS is a DHCP server or a DHCP proxy
  • the NAS is an AAA client relative to the AAA server.
  • Step 402 The NAS sends a DHCP provision (DHCP OFFER) to the DHCP client.
  • DHCP OFFER a DHCP provision
  • the DHCP OFFER packet carries the IP address and related configuration parameter information provided to the DHCP client.
  • each DHCP server may respond after receiving the DHCP DISCOVER from the DHCP client, that is, send DHCP back to the DHCP client.
  • the OFFER packet therefore, in this step, the DHCP client may receive multiple DHCP OFFE R packets at the same time.
  • Step 4 0 3 The DHCP client sends a DHCP request (DHCP REQUEST) to the NAS.
  • DHCP REQUEST a DHCP request
  • the DHCP client sends a DHCP REQUEST message to the NAS to request the IP address and related configuration parameters.
  • the DHCP client receives multiple DHCP OFFER messages in step 402, in this step, the DHCP client needs to select multiple DHCP OFFERs first, and select one of the IP addresses provided by the DHCP OFFER as its own IP address. How to select a DHCP client is the same as the prior art, and is not described here.
  • Step 404 The NAS sends a DHCPEAP packet to the DHCP client.
  • the NAS sends a DHCPE AP message to the DHCP client, and carries an EAP Request message to request the ID of the DHCP client.
  • Step 405 The DHCP client sends a DHCPE AP ⁇ message to the NAS.
  • the DHCP client carries its own ID in the EAP Response, and carries the EAP Response (EAP Resp onse) in the DHCPEAP and sends it to the NAS.
  • EAP Response EAP Resp onse
  • the process of requesting IDs in steps 404 and 405 is the process specified in the EAP authentication protocol.
  • Step 406 The NAS strips the EAP Response message in the DHCPEAP and sends it to the AAA server in the existing AAA protocol.
  • an access request (Access-Request) in the existing AAA protocol Radius can be used to carry an EAP Response message.
  • Step 407 The AAA server generates an EAP Request (EAP Req uest) message carrying the challenge word information of the OTP, and carries the message to the NAS in the existing AAA protocol.
  • EAP Request EAP Req uest
  • an Access-Challenge message in the existing Radius protocol can be used to carry an EAP Request message.
  • Step 408 The NAS strips out the EAP Request message and sends it to the DHCP EAP packet to the D.
  • Step 409 The DHCP client generates a response according to the received challenge word information, and carries the message in the EAP_Response message, and sends the message to the NAS through the DHCPEAP.
  • Step 410 The NAS strips the EAP-Response message in the DHCPEAP, and carries the message to the AAA server in the existing AAA protocol.
  • Step 411 The AAA server authenticates the DHCP client according to the received challenge word response information, and sends back a response message indicating whether the authentication succeeds or not to the NAS.
  • the method for the AAA server to authenticate the DHCP client according to the challenge word response information is a prior art, and details are not described herein again.
  • the AAA server According to the authentication result, the AAA server generates an EAP-Success message indicating that the authentication is successful or an EAP-Failure message indicating that the authentication is failed, and carries the message in the existing AAA protocol, such as access-accept or access. Access-Reject is sent to the NAS in the text.
  • Step 412 The NAS sends a DHCPAC K packet indicating that the authentication succeeds or a DHCPNAK packet indicating that the authentication is successful according to the authentication result.
  • the NAS needs to further confirm whether the DHCP client can use the IP address requested in step 403. If yes, send a DHCP ACK. If not, send the DHCPNAK4 message. .
  • the embodiments of the present invention are only specific ways of implementing the solution of the present invention, but are not intended to limit the technical solutions of the present invention.
  • the EAP Request and the EAP Response message are not only allowed to be carried through the DHCPEAP packet, and other methods are also available as long as the same purpose can be achieved.
  • two separate packet types, DHCPEAPREQUEST and DHCPEAPRESPONSE can be newly defined to carry EAP Request and EAP Response messages.
  • the EAP authentication mode adopted by the network side is the OTP authentication mode. If other authentication modes are used, the EAP message interaction mode shown in FIG. 4 may be different.
  • the steps 404-405 are optional steps, which may be omitted. If the steps 404-405 are omitted, the NAS will carry the EAP-S tart message in the existing AAA protocol packet and send it to the AAA server. Steps 407 ⁇ 41 0 may need to be repeated multiple times.
  • the authentication method such as Extended Protocol Authentication EEAP - Transport Layer Security TLS (Transport Layer TLS)
  • the embodiment shown in FIG. 4 is an implementation flow when the DHCP client performs authentication for the first time.
  • the following two embodiments are used to describe the implementation process when the DHCP client performs re-authentication.
  • FIG. 5 is a flow chart of a second embodiment of the method of the present invention, in which re-authentication is triggered by a DHCP client.
  • the DHCP client needs to update the address or with the address request allocation parameter, it sends a DGCP request (DHCP REQUEST) message directly to the NA S.
  • DHCP REQUEST DGCP request
  • steps 401 and 402 in FIG. 4 are missing, that is, the process of discovering and providing an IP address, and steps 501 to 510 are the same as steps 403-412 shown in FIG. No longer.
  • FIG. 6 is a flow chart of a third embodiment of the method of the present invention.
  • the re-authentication in this embodiment is triggered by the network side, that is, in step 601, the network side sends a forced update (F0RCERENEW) message to the DHCP client; in step 602, 0? Received by the client? 0 £ ⁇ After 4 ⁇ , send a DHCP REQUEST message to the NAS.
  • steps 603 - 61 1 are the same as steps 404 - 412 shown in Figure 4, and will not be described again.
  • the embodiments shown in FIG. 5 and FIG. 6 are used to implement re-authentication, but in some special cases, for example, the DHCP client does not need or does not need to perform authentication when initially accessing the network, and only needs to perform the diagram.
  • the DHCP client needs to be authenticated for the reasons mentioned in the DHCP client re-authentication situation, or the DHCP server needs to be authenticated for the reasons mentioned in the DHCP server re-authentication situation, although the authentication in these two cases belongs to The first certification, but the certification process is performed according to the process shown in Figure 5 or Figure 6.
  • the DHCP client sends a DHCP REQUEST to the network side to trigger the network side to perform authentication.
  • Another authentication mode is provided in the embodiment of the present invention: The network side receives the DH from the DHCP client. The CP finds the packet, and the DHCP discovery packet carries the fast acknowledgment option information. The network side authenticates the DHCP client and sends a response to the DHCP client to verify the success or failure of the authentication.
  • the method for the network side to send a response message to the DHCP client for the success or failure of the authentication includes: sending a DHCP acknowledgement message to the D HCP client if the authentication succeeds; and sending the DHCP unacknowledgment to the DHCP client if the authentication fails. Message. Moreover, the DHCP acknowledgement message further carries the address information provided by the network side to the DHCP client.
  • the specific implementation is shown in Figure 7.
  • FIG. 7 is a flow chart of a fourth embodiment of the method of the present invention. Compared with the embodiment shown in FIG. 4, the difference is: in the DHCP DI SCOVER message sent by the DHCP client to the NAS, the fast acknowledgment (rap id commi t) option information is carried in the step 701; after receiving the DHCP DI SCOVER, the NAS That is, authentication is performed, and the information exchange process of steps 401 and 402 shown in FIG. 4 is no longer needed. Moreover, before the NAS sends an acknowledgement packet to the DHCP client in step 71 0, it is necessary to confirm whether the IP address can be provided for the DHCP client.
  • the fast acknowledgment (rap id commi t) option information is carried in the step 701; after receiving the DHCP DI SCOVER, the NAS That is, authentication is performed, and the information exchange process of steps 401 and 402 shown in FIG. 4 is no longer needed.
  • the NAS sends an acknowledgement packet to the DHCP client
  • the DHCP client sends a DHCP confirmation message to the DHCP client, and carries the address information provided to the DHCP client in the DHCP confirmation message.
  • the remaining steps 702 ⁇ 709 are the same as steps 404 - 411 shown in Figure 4, and will not be described again.
  • the CPv4 is replaced by DHCPv6.
  • the foregoing embodiments are equally applicable. The difference is that the packet type may be different. For example, in the embodiment in which the network side triggers re-authentication in FIG. 6, steps 601, 602, and 61 1 are changed accordingly. Re-created (Reconf i gure), Renew and Rep ly.
  • FIG. 8 is a schematic structural diagram of a first embodiment of the system of the present invention. As shown in Figure 8, the system includes: a DHCP client 801 and a network side 802:
  • the DHCP client 801 is configured to send a DHCP request message to the network side 802, and receive a response message that the network side sends back the authentication success or not.
  • the network side 802 is configured to authenticate the DH CP client 801 after receiving the DHCP request message from the DHCP client 801, and send a response message to the DHCP client 801 for the success or failure of the authentication.
  • the DHCP client 810 is further used to send the discovery message to the network side 802, and receive the address letter sent back by the network side 802.
  • the network side 802 is further configured to receive the discovery packet of the DHCP client 801 and send back the address information to the DHCP client 801.
  • the network side 802 may be further configured to send a mandatory update message to the DHCP client 801; accordingly, the DHCP client 801 receives the mandatory update report. After the text, the DHCP request message is sent to the network side 802.
  • the network side 802 After the network side 802 completes the authentication of the DHCP client 801, it sends a response message to the DHCP client 801, for example, if the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client. The DHCP unacknowledged message is sent back to the DHCP client.
  • the DHCP client can also be used to send a DHCP discovery message carrying the fast acknowledgment option information to the network side 802, and receive the response of the authentication succeeded by the network side.
  • the technical solution of the embodiment of the present invention not only solves the problem of performing authentication and re-authentication on the DHCP client, but also implements the authentication, and basically does not need to modify the existing message format, compared to the prior art. , reducing the difficulty and complexity of implementation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un procédé et un système pour mettre en œuvre une authentification. Selon l'invention, le côté réseau reçoit un message de requête DHCP ou un message de découverte DHCP prenant des informations d'option de validation rapide provenant d'un client de protocole de configuration dynamique d'hôte (DHCP), authentifie le client DHCP, et renvoie le message de réponse d'authentification réussie ou non au client DHCP, si l'authentification est réussie, alors le côté réseau renvoie un message de validation DHCP au client DHCP, et si l'authentification échoue, alors il renvoie un message de non-validation DHCP au client DHCP.
PCT/CN2008/070977 2007-07-19 2008-05-15 Procédé et système pour mettre en œuvre une authentification Ceased WO2009009972A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNA200710130456XA CN101350809A (zh) 2007-07-19 2007-07-19 一种实现认证的方法和系统
CN200710130456.X 2007-07-19

Publications (1)

Publication Number Publication Date
WO2009009972A1 true WO2009009972A1 (fr) 2009-01-22

Family

ID=40259306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070977 Ceased WO2009009972A1 (fr) 2007-07-19 2008-05-15 Procédé et système pour mettre en œuvre une authentification

Country Status (2)

Country Link
CN (1) CN101350809A (fr)
WO (1) WO2009009972A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102231725B (zh) * 2010-03-25 2014-09-10 北京星网锐捷网络技术有限公司 一种动态主机配置协议报文的认证方法、设备及系统
CN103685272B (zh) * 2011-03-03 2017-02-22 上海华为技术有限公司 一种认证方法及系统
CN105592172A (zh) * 2014-10-23 2016-05-18 中兴通讯股份有限公司 动态主机配置协议重连方法、dhcp服务器及系统
CN106254376B (zh) * 2016-09-05 2019-10-11 新华三技术有限公司 一种认证协商方法及装置
CN111064699A (zh) * 2019-10-25 2020-04-24 苏州浪潮智能科技有限公司 一种客户端的管理方法、设备以及存储介质
CN115499260B (zh) * 2022-08-29 2025-02-11 新华三技术有限公司 通信方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1450766A (zh) * 2002-04-10 2003-10-22 深圳市中兴通讯股份有限公司 一种基于动态主机配置协议的用户管理方法
CN1889577A (zh) * 2006-07-18 2007-01-03 Ut斯达康通讯有限公司 一种基于dhcp扩展属性的ip地址分配方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1450766A (zh) * 2002-04-10 2003-10-22 深圳市中兴通讯股份有限公司 一种基于动态主机配置协议的用户管理方法
CN1889577A (zh) * 2006-07-18 2007-01-03 Ut斯达康通讯有限公司 一种基于dhcp扩展属性的ip地址分配方法

Also Published As

Publication number Publication date
CN101350809A (zh) 2009-01-21

Similar Documents

Publication Publication Date Title
CN101296081A (zh) 认证、认证后分配ip地址的方法、系统、接入实体和装置
JP4896956B2 (ja) コンピュータ・システムにおける能動管理技術（ａｍｔ）のプロビジョニング
CN102427484B (zh) 基于dns来确定设备是否处于网络内部的方法和装置
TWI536854B (zh) 用於即時通訊之基於使用者之驗證
US20100223655A1 (en) Method, System, and Apparatus for DHCP Authentication
US10805298B2 (en) Result reporting for authentication, authorization and accounting protocols
US20200336494A1 (en) Authentication/authorization server, client, service providing system, access management method, and medium
WO2008138242A1 (fr) Procédé de gestion, appareil et système de connexion de session
CN100574195C (zh) 基于动态主机配置协议的安全接入方法及其系统
WO2009009972A1 (fr) Procédé et système pour mettre en œuvre une authentification
WO2013056619A1 (fr) Procédé, idp, sp et système pour la fédération d'identités
CN103944716B (zh) 用户认证的方法和装置
CN101227481A (zh) 一种基于dhcp协议的ip接入的方法及其装置
US20100107231A1 (en) Failure indication
CN102255916A (zh) 接入认证方法、设备、服务器及系统
WO2014117600A1 (fr) Procédé et système basés sur le dns et permettant une authentification de l'utilisateur et un contrôle d'accès à un nom de domaine
WO2019154017A1 (fr) Procédé et appareil d'établissement de trajets multiples
CN103067407B (zh) 用户终端接入网络的认证方法及装置
US7558845B2 (en) Modifying a DHCP configuration for one system according to a request from another system
CN101084657A (zh) 网关、网络系统以及控制访问Web服务器的方法
CN100591013C (zh) 实现认证的方法和认证系统
CN101436969B (zh) 网络接入方法、装置及系统
Komori et al. The secure DHCP system with user authentication
US12238521B2 (en) Enhanced authentication procedure for O-RAN network elements
JP2010062667A (ja) ネットワーク機器及びネットワークシステム

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: 08748583

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: 08748583

Country of ref document: EP

Kind code of ref document: A1