DHC Working Group Y. Zhao Internet-Draft Huawei Technologies Co.,Ltd Intended status: Standards Track February 28, 2007 Expires: September 1, 2007 DHCP User-based Authentication draft-zhao-dhc-user-authentication-01.txt 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 September 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a mechanism to couple DHCP to an authentication, authorization and accounting (AAA) system in an access network, thus enabling users to supply user credentials for AAA via DHCP. Zhao Expires September 1, 2007 [Page 1] Internet-Draft DHCP User-based Authentication February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 3. Digest Authentication . . . . . . . . . . . . . . . . . . . . 4 4. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. User-based Authentication Option . . . . . . . . . . . . . 6 4.1.1. Option Format . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Option Format of Digest authentication . . . . . . . . 7 4.2. Relay Agent User-based authentication sub-option . . . . . 8 4.2.1. Sub-option Format . . . . . . . . . . . . . . . . . . 8 5. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 9 6. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 9 7. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Zhao Expires September 1, 2007 [Page 2] Internet-Draft DHCP User-based Authentication February 2007 1. Introduction Traditionally, DHCP has mainly been used in private domains. However, in public domain environments, DHCP will be used between a user-equipment and a DHCP Server which is inside an Access Network and possibly several routers away from the Access Router, such as NAS. Network service offered via this access network is more likely to be based on the user credentials instead of the equipment identification. There are two primary transitions in Digital Subscriber Line (DSL) technologies and protocols. One is migration from ATM to Ethernet in access network. Another is migration from PPP session to IP session [WT-146] . In IP session, authentication is left as an open issue needing resolution. For DHCP subscribers, authentication based on a username and password needs to be addressed when moving to IP session. In the DHCP-based access environment, there lacks a means of obtaining user credentials. In order to collect subscriber credentials, a user-based authentication model needs to be created. 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 a user before he or she accesses a provider network. 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. Zhao Expires September 1, 2007 [Page 3] Internet-Draft DHCP User-based Authentication February 2007 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 environments, 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, can be used as AAA triggers intercepting and conveying relevant information from clients to AAA servers. The interface between AAA server and NAS is out of the scope of this document. 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] . 3. Digest Authentication 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 text. This document defines the use of a particular technique based on the HMAC protocol[RFC2104] using the MD5 hash[RFC1321]. Zhao Expires September 1, 2007 [Page 4] Internet-Draft DHCP User-based Authentication February 2007 The following is an example of message flow (Success): Client Relay/AAA Client AAA Server DHCP Server ------ ---------------- ----------- ----------- | Discover{username}| | | | ----------------> | Challenge Request | | | | {username} | | | | --------------------> | | | | Challenge Response | | | | {username,Nonce} | | | | <-------------------- | | | | Discover{Nonce,username} | | | --------------------------------------->| | Offer{username | Offer{Nonce,username} | | Nonce} | <---------------------------------------| | <---------------- | | | | | | | | Request{username, | | | | Nonce, digest} | | | | ----------------> | Auth Request{username,| | | | Nonce,digest} | | | | --------------------> | | | | Auth Response{success}| | | | <-------------------- | | | | Request | | | --------------------------------------->| | | Ack | | Ack | <-------------------------------------- | | <---------------- | | | | | | | Figure 2: Digest Authentication example 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 responses 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 responses with a DHCP OFFER by inserting the challenge to the User-based Authentication option. Zhao Expires September 1, 2007 [Page 5] Internet-Draft DHCP User-based Authentication February 2007 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 Success Response. 10. Relay Agent forwards the DHCPREQUEST message to DHCP Server . 11. Upon receiving forwarded DHCPREQUEST message , 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 DHCPOFFER message required to return a nonce value to the client is not present. 4. DHCPv4 Options 4.1. User-based Authentication Option 4.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 3: User-based Authentication Option Format Zhao Expires September 1, 2007 [Page 6] Internet-Draft DHCP User-based Authentication February 2007 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. Digest Authentication = 1 Algorithm defines the specific algorithm within the technique identified by the protocol field. HMAC-MD5 = 1 (specific to Digest Authentication) User-based Authentication Information The authentication information, as specified by the protocol and algorithm used in this user-authentication option 4.1.2. Option Format of Digest authentication The format of the User-based Authentication option 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-based Authentication option 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-based Authentication option in a DHCPREQUEST/ DHCPACK for a digest authentication is: Zhao Expires September 1, 2007 [Page 7] Internet-Draft DHCP User-based Authentication February 2007 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. 4.2. Relay Agent User-based authentication sub-option 4.2.1. Sub-option Format In digest authentication mechanism, NAS uses this sub-option to carry the challenge value to DHCP server. This sub-option is a new sub-option for the DHCP Relay Agent Information option. Zhao Expires September 1, 2007 [Page 8] Internet-Draft DHCP User-based Authentication February 2007 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 | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: User-based authentication sub-option Format Code TBD length The sub-option length. data This field contains a random challenge value 5. DHCP Client Behavior The username and password are provided by the user at the beginning of the DHCP. The DHCP client SHOULD inserts the username in the User-Class option[RFC3004]. The username SHOULD be in the form of a Network Access Identifier (NAI) [RFC2486] . 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 and computes the digest using HMAC-MD5, with password and challenge value as input parameters, else the client SHOULD ignore the DHCPOFFER. 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. 6. DHCP Relay Agent Behavior In digest authentication mechanism: Zhao Expires September 1, 2007 [Page 9] Internet-Draft DHCP User-based Authentication February 2007 o If the relay agent, acting as AAA client at the same time, receives DHCPDISCOVER message with user-based authentication option, it SHOULD get a challenge value from AAA server or generates the challenge value by itself. o The relay agent forwards the challenge value to 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 , acting as an AAA client at the same time, extracts the digest password and the challenge value from the User-based authentication option, the username from the user-class option, supplies the user-name/the digest password/challenge value information to AAA server for authentication and receives the authentication result from AAA server o If authentication succeed, relay agent forwards the DHCPREQUEST to DHCP Server and MAY insert the identification and authorization attributes into the Radius Attributes sub-option [RFC4014]. If authentication failed, relay agent SHOULD not forward the Request to DHCP Server. 7. 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 digest authentication mechanism: o Upon receiving a relayed DHCPDISCOVER message with user-based authentication option and user-based authentication sub-option, 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. 8. Security Considerations In 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. Zhao Expires September 1, 2007 [Page 10] Internet-Draft DHCP User-based Authentication February 2007 The transport of the user credentials 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. 9. IANA Considerations IANA is requested to allocate DHCPv4 option code and DHCPv4 Relay agent sub-option for this purpose. 10. Acknowledgements We would like to thank Pavan Kurapati, bharat_joshi, Kostur, Andre, Eliot Lear and Markus Kai Richard Stenberg for their comments to this draft. 11. References 11.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 Zhao Expires September 1, 2007 [Page 11] Internet-Draft DHCP User-based Authentication February 2007 Messages", RFC 3118, June 2001. [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option", RFC 4014, February 2005. [WT-146] DSL Forum, "Internet Protocol (IP) Sessions", WT-146 (work in progress), April 2007. 11.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. Author's Address Yuping Zhao Huawei Technologies Co.,Ltd Huihong Mansion,No.91 Baixia Rd. Nanjing, Jiangsu 210001 P.R.China Phone: +86(25)84565476 Email: zhaoyuping@huawei.com Zhao Expires September 1, 2007 [Page 12] Internet-Draft DHCP User-based Authentication February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Zhao Expires September 1, 2007 [Page 13]