DHC Working Group Amy. Zhao Internet-Draft Huawei Technologies Co.,Ltd Expires: March 26, 2007 September 22, 2006 DHCP User-based Authentication draft-zhao-dhc-user-authentication-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an authentication mechanism to provide an authentication for a user in an access network by means of dhcp. The authentication mechanism described here couples DHCP to an authentication, authorization and accounting system (AAA), thus enabling users to supply user credentials for AAA via DHCP. Zhao Expires March 26, 2007 [Page 1] Internet-Draft DHCP User-based Authentication September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 5 3. Basic Authentication . . . . . . . . . . . . . . . . . . . . . 6 4. Digest Authentication . . . . . . . . . . . . . . . . . . . . 8 5. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. User-based Authentication Option . . . . . . . . . . . . . 11 5.1.1. Option Format . . . . . . . . . . . . . . . . . . . . 11 5.1.2. Digest authentication Format . . . . . . . . . . . . . 12 5.2. Relay Agent User-based authentication sub-option . . . . . 13 5.2.1. Sub-option Format . . . . . . . . . . . . . . . . . . 13 5.2.2. digest authentication format . . . . . . . . . . . . . 14 6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 16 7. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 17 8. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Zhao Expires March 26, 2007 [Page 2] Internet-Draft DHCP User-based Authentication September 2006 1. Introduction Traditionally ,DHCP has mainly been used in private domains. Howerver, in public domain environments, the DHCP protocol will be used between a user-equipment and a DHCP Server which is inside the Access Network and possibly several routers away from the Access Router, such as NAS. Network service offered via this access network mainly need user identification instead of equipment identification, therefore, the DHCP required a user-based authenticaiton. An authentication mechanism for DHCPv4 protocol messages was developed in [RFC3118].This allows DHCP clients and servers to authenticate each other. Our purpose differs in that we want to authenticate and authorize a user before he accesses a provider network, to apply policy to customize this access connection to account for the service. As [I-D.dhcv4-treat-analysis] pointed out that [RFC3118] is concerned specifically with DHCP clients and servers authenticating themselves to each other if required by an administrative domain. This is not the same thing as authenticating users for establishing their Identity, access rights, permissions, or other matters relating to what they can view or do once connected to the network. Only one mechanism is not sufficient and a well-secured network needs both. Consider the following architecture: +--------+ AAA Protocol | AAA | +---------------------+ Server | | +--------+ | | +--------+ +-------+-------+ +--------+ | DHCP | DHCP | NAS/DHCP Relay| DHCP | DHCP | | Client |---------| /AAA Client |--------------| Server | +--------+ +---------------+ +--------+ Figure 1: Referenced Architecture In some access network enviornments, a Network Access Server(NAS) enabling authenticated network access acts as a DHCP relay agent to forward requests and responses between the access client and a DHCP server within the network. We proposes in this document that the NAS, acting as a DHCP relay agent and a AAA client, be used as AAA triggers intercepting and conveying relevant information from clients to AAA servers. Zhao Expires March 26, 2007 [Page 3] Internet-Draft DHCP User-based Authentication September 2006 The interface between AAA server and NAS is out of the scope of this document. Zhao Expires March 26, 2007 [Page 4] Internet-Draft DHCP User-based Authentication September 2006 2. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Definitions for terms and acronyms used in this document are defined in [RFC2131] . Zhao Expires March 26, 2007 [Page 5] Internet-Draft DHCP User-based Authentication September 2006 3. Basic Authentication In basic authentication, DHCP client inserts the username and password in clear text into the DHCP request message. The NAS, acting as DHCP relay agent and AAA client at the same time, extracts the username/password information from request message, and sends this information to AAA server for user authentication. If authenticated successfully, NAS relays the request message to DHCP Server. The following is an example of message flow (Success): Client Relay/AAA Client AAA Server DHCP Server ------ ---------------- ----------- ----------- | Discover{username | | | | password} | Auth Request{username | | | ----------------> | Password} | | | | --------------------> | | | | Auth Response{success}| | | | <-------------------- | | | | Discover | | | --------------------------------------->| | | Offer | | Offer | <---------------------------------------| | <---------------- | | | | Request | | | | ----------------> | Request | | | --------------------------------------->| | | Ack | | Ack | <-------------------------------------- | | <---------------- | | | | | | | Figure 2: Basic Authentication example 1. The client sends DHCPDISCOVER message by inserting the username into User-Class option and the password into User-base Authentication option. 2. Upon receiving the DHCPDISCOVER message,Relay agent extracts the username and password, then supplies the username/password information to AAA Server by sending Auth Request message. 3. AAA server response with Auth Success Response. 4. Relay Agent forwards the DHCPDISCOVER message to DHCP Server by inserting the authentication result into Relay agent user-based authentication sub-option. Zhao Expires March 26, 2007 [Page 6] Internet-Draft DHCP User-based Authentication September 2006 5. Upon receiveing forwarded DHCPDISCOVER message with successful authentication result in Relay agent user-based authentication sub-option, DHCP Server reponses with DHCP OFFER. The mechanism is not considered to be a secure method of user authentication, as the user name and password are passed over the network as cleartext. Zhao Expires March 26, 2007 [Page 7] Internet-Draft DHCP User-based Authentication September 2006 4. Digest Authentication In digest authentication, user's password is not sent in clear-text. The digest authentication is based on a simple challenge-response paradigm and uses a server-specified nonce to seed the generation of the digest value. The user retrieves the nonce and calculates a digest(by default, the HMAC-MD5 digest) of the password, the retrieved nonce value. In this way, the password is never sent in the clear.. This document defines the use of a particular technique based on the HMAC protocol[RFC2104] using the MD5 hash[RFC1321]. The following is an example of message flow (Success): Client Relay/AAA Client AAA Server DHCP Server ------ ---------------- ----------- ----------- | Discover{username}| | | | ----------------> | Challenge Request | | | | {usename} | | | | --------------------> | | | | Challenge Response | | | | {username,Nonce} | | | | <-------------------- | | | | Discover{Nonce,username} | | | --------------------------------------->| | Offer{username | Offer{Nonce,username} | | Nonce} | <---------------------------------------| | <---------------- | | | | Request{username, | | | | Nonce,encrypted | | | | password} | Auth Request{username,| | | ----------------> | Nonce,encrypted | | | | password} | | | | --------------------> | | | | Auth Response{success}| | | | <-------------------- | | | | Request | | | --------------------------------------->| | | Ack | | Ack | <-------------------------------------- | | <---------------- | | | | | | | Figure 3: Digest Authentication example Zhao Expires March 26, 2007 [Page 8] Internet-Draft DHCP User-based Authentication September 2006 1. The client sends DHCP DISCOVER message by inserting the username into User-Class option. 2. Upon receiving the DHCPDISCOVER message , relay agent extracts the username, then sends challenge request to AAA server with username. 3. AAA server response Challenge Response with a challenge value . 4. Relay Agent forwards the DHCPDISCOVER message to DHCP Server by inserting the retrieved challenge value into Relay Agent User- based Authentication sub-option. 5. Upon receiving the forwarded DHCP DISCOVER message, DHCP Server extracts the challenge value from Relay Agent User-based Authentication sub-option and reponses with a DHCP OFFER by inserting the challenge to the User-based Authentication option. 6. Relay Agent forwards the DHCP OFFER to the client. 7. Upon receiving the forwarded DHCP OFFER, client extracts the challenge value from user-based authentication option and calculates the digest with the user's password and the challenge value, then sends the DHCPREQUEST by inserting username into User-Class option and digest password into User-based Authentication option. 8. Upon receiving DHCPREQUEST, Relay agent extracts the username, digest password and challenge value ,then supplies the username/ digest password/challenge value information to AAA Server by sending Auth Request message. 9. AAA server response with Auth Succes Response. 10. Relay Agent forwards the DHCPREQUEST message to DHCP Server by inserting the authentication result into Relay agent user-based authentication sub-option. 11. Upon receiving forwarded DHCPREQUEST message with successful authentication in Relay agent user-based authentication sub- option, DHCP Server responses with DHCP ACK. Rapid commit, defined by[RFC4039] , specifies how a two-message exchange between client and server can dramatically decrease the elapsed time for address assignment, a feature becoming significant as more and more highly mobile devices desire an abbreviated address assignment phase for short duration communications. Therefore, the User-based Digest Authentication simply cannot be used as the Zhao Expires March 26, 2007 [Page 9] Internet-Draft DHCP User-based Authentication September 2006 DHCPOFFER message required to return a nonce value to the client is not present. The Digest authentication mechanism described here is a replacement for Basic authentication and nothing more. It is not as secure as Kerberos, and not as secure as any client-side private-key mechanism. Nevertheless it is better than nothing, and better than Basic authentication. Zhao Expires March 26, 2007 [Page 10] Internet-Draft DHCP User-based Authentication September 2006 5. DHCPv4 Options 5.1. User-based Authentication Option 5.1.1. Option Format The format of the DHCPv4 User-based Authentication option is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length | Protocol | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | User-based Authentication Information | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: User-based Authentication Option Format Code TBD length contains the length of the protocol,algorithm and user-based authentication Information fields in octets. Protocol defines the particular technique for user-authentication used in the option. Basic Authentication = 0 Digest Authentication = 1 Algorithm defines the specific algorithm within the technique identified by the protocol field. HMAC-MD5 = 1 (specific to Digest Authentication) Zhao Expires March 26, 2007 [Page 11] Internet-Draft DHCP User-based Authentication September 2006 User-based Authentication Information The authentication information, as specified by the protocol and algorithm used in this user-authentication option 5.1.2. Digest authentication Format The format of the user-authentication request in a DHCPDISCOVER message for digest authentication is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 1| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the user-authentication information in a DHCPOFFER for digest authentication is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 1| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the user-authentication information in a DHCPREQUEST/ DHCPACK for a digest authentication is: Zhao Expires March 26, 2007 [Page 12] Internet-Draft DHCP User-based Authentication September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 1| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Digest ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nonce a random value which is used by HMAC-MD5 Digest the result by using the Digest generating function HMAC-MD5. The sender computes the Digest using the HMAC[RFC2104] generation algorithm and the MD5[RFC1321] hash function. The password including is used as input to the HMAC-MD5 computation function. The 'nonce' field MUST be set to the random value used to generate the Digest. Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate algorithm. 5.2. Relay Agent User-based authentication sub-option 5.2.1. Sub-option Format In digest authentication mechanism, NAS uses this suboption to carry the challenge value or the authentication result to DHCP server. This sub-option is a new suboption for the DHCP Relay Agent Information option. Zhao Expires March 26, 2007 [Page 13] Internet-Draft DHCP User-based Authentication September 2006 The format of the relay agent user-based sub-option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length | type | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: User-based authentication sub-option Format Code TBD length the suboption length. type define the type of the data field 0 ----- authentication result 1 ----- random challenge value data if type =1, this field contains the authentication result 0 ----- FAILURE 1 ----- SUCCESS if type =2, this field contains a random challenge value 5.2.2. digest authentication format The format of the Relay Agent user-authentication information in a DHCPOFFER for digest authentication is: Zhao Expires March 26, 2007 [Page 14] Internet-Draft DHCP User-based Authentication September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 1| challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ challenge ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the user-authentication information in a DHCPREQUEST for digest authentication is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 0| result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhao Expires March 26, 2007 [Page 15] Internet-Draft DHCP User-based Authentication September 2006 6. DHCP Client Behavior The username and password are provided by the user at the beginning of the DHCP. The DHCP client SHOUD inserts the username in the User-Class option[RFC3004]. The username SHOULD be in the form of a Network Access Identifier (NAI) [RFC2486] . In basic authentication mechanism: o The client MUST include the User-based Authentication option in its request message by setting the Protocol field to 0 ,algorithm field to 0 and User-based Authentication information fields to the password,which is provided by user. o If the received response message does not include the User-based Authentication option, the DHCP client SHOULD ignore the received message. In digest authentication mechanism: o The client MUST include the User-based Authentication option in its DHCPDISCOVER message by setting protocol field to 1 . o If the client receives a DHCPOFFER message including the User- based Authentication option, it extracts the challenge value from the nonce field of the User-based Authentication option, else the client SHOULD ignore the DHCPOFFER. o The client compute the digest using HMAC-MD5, with password and challenge value as input parameters. o The client replies with a DHCPREQUEST that MUST include User-based Authentication information by setting the digest field to the computed digest value . o If the client receives a DHCPACK message without the User-based Authentication option, it SHOULD ignore the DHCPACK. Zhao Expires March 26, 2007 [Page 16] Internet-Draft DHCP User-based Authentication September 2006 7. DHCP Relay Agent Behavior In basic authentication mechanism. o The relay agent extracts the password from the User-based Authentication option and the user-name from user-class option. o The relay agent, acting as an AAA client at the same time, supplies the user-name/password information to AAA server for authentication and receives the authentication result from AAA server. o The relay agent forwards the authentication result to DHCP server by insert the result into the relay agent user-based authentication sub-option. In digest authentication mechanism: o The relay agent,acting as AAA client at the same time, gets a challenge value from AAA server or generates the challenge value by itself. o The relay agent forwards the challenge value to DHCP server to the DHCP server by inserting the challenge value into the relay agent user-based authentication sub-option of DHCPDISCOVER . o Upon receiving DHCPREQUEST, the relay agent extracts the digest password and the challenge value from the User-based authentication option, the username from the user-class option. o The relay agent, acting as an AAA client at the same time, supplies the user-name/the digest password/challenge value information to AAA server for authentication and receives the authentication result from AAA server o The relay agent forwards the authentication result to DHCP server by inserting the result into the relay agent user-based authentication sub-option Zhao Expires March 26, 2007 [Page 17] Internet-Draft DHCP User-based Authentication September 2006 8. DHCP Server Behavior If the received request message is included the User-based Authentication option, the DHCP Server SHOULD includes the User-based Authentication option in the response message. In basic authentication mechanism: o If the authentication result in the relay agent user-based authentication sub-option is SUCCESS, The DHCP Server handles the request message from the DHCP client according to [RFC2131] o Otherwise, the DHCP Server replies with DHCPNAK for DHCPREQUEST. In digest authentication mechanism: o Upon receiving a relayed DHCPDISCOVER message, DHCP server extracts the challenge value from the relay agent user-based authentication sub-option . o The DHCP server replies with a DHCPOFFER message by inserting the challenge value into the user-based Authentication option. o Upon receiving a relayed DHCPREQUEST message * If previous received DHCPDISCOVER includes a User-based Authentication option, and the received DHCPREQUEST message does not include a User-based Authentication option, DHCP Server SHOULD ignore the DHCPREQUEST message. * If the authentication result in the relay agent user-based authentication sub-option is FAILURE, DHCP server replies with DHCPNAK. Zhao Expires March 26, 2007 [Page 18] Internet-Draft DHCP User-based Authentication September 2006 9. Security Considerations In basic authentication mechanism and digest authentication mechanism, there is a delay between request and response message.If the delay is too long ,it will affect the client state machine and results in retransmission of request message. The transport of the user-based authentication between the AAA infrastructure and the NAS is subject to the standard RADIUS and Diameter security consideration. No new security consideration are imposed by the usage of this document. The security mechanisms provided by [RFC2865] and [RFC3588] are applicable and provide adequate security for this purpose. The communication between the NAS/DHCP relay agent and the DHCP server must be authenticated, integrity and replay protected. Zhao Expires March 26, 2007 [Page 19] Internet-Draft DHCP User-based Authentication September 2006 10. IANA Considerations IANA is requested to allocate DHCPv4 option code and DHCPv4 Relay agent sub-option for this purpose. Zhao Expires March 26, 2007 [Page 20] Internet-Draft DHCP User-based Authentication September 2006 11. Acknowledgements Zhao Expires March 26, 2007 [Page 21] Internet-Draft DHCP User-based Authentication September 2006 12. References 12.1. Normative References [RFC1321] Rivest, R., "HMAC: The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC3004] Stump, G., Droms, R., and Y. Gu, "The User Class Option for DHCP", RFC 3004, November 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 12.2. Informative References [I-D.dhcv4-treat-analysis] Hibbs, R., Smith, C., Volz, B., and M. Zohar, "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", draft-ietf-dhc-v4-threat-analysis-03 (work in progress), June 2006. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 4039, March 2005. Zhao Expires March 26, 2007 [Page 22] Internet-Draft DHCP User-based Authentication September 2006 Author's Address Yuping Zhao Huawei Technologies Co.,Ltd Huihong Mansion,No.91 Baixia Rd. Nanjing, Jiangsu 210001 P.R.China Phone: +86(25)84565403 Email: zhaoyuping@huawei.com Zhao Expires March 26, 2007 [Page 23] Internet-Draft DHCP User-based Authentication September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhao Expires March 26, 2007 [Page 24]