DHC Working Group Y. Zhao Internet-Draft Y. Li Intended status: Standards Track Huawei Technologies Expires: January 10, 2008 July 9, 2007 DHCP User-based Authentication draft-zhao-dhc-user-authentication-02.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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a mechanism to allow DHCP to carry user based credentials for authentication purpose. It can intercooperate with current AAA service seamlessly. Zhao & Li Expires January 10, 2008 [Page 1] Internet-Draft DHCP User-based Authentication July 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 . . . . . . . . . . . . . . . . . . 10 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Zhao & Li Expires January 10, 2008 [Page 2] Internet-Draft DHCP User-based Authentication July 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 and the other is migration from PPP session to IP session [WT-146] . In IP session, authentication is left as an open issue. For DHCP subscribers, authentication based on a username and password needs to be addressed when moving to IP session from PPP. 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].It provides the message integrity protection and replay attack protection. 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 & Li Expires January 10, 2008 [Page 3] Internet-Draft DHCP User-based Authentication July 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 authentication information from clients to AAA servers. Such an approach is applicable where NAS is acting as DHCP server as well. 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 challenge to seed the generation of the digest response. The user retrieves the challenge and calculates a digest(by default, the HMAC-MD5 digest) of the password and the challenge. The password is never sent in the clear text and no prior key distribution is required. This document defines the use of a particular technique based on the Zhao & Li Expires January 10, 2008 [Page 4] Internet-Draft DHCP User-based Authentication July 2007 HMAC protocol[RFC2104] using the MD5 hash[RFC1321]. The following is an example of message flow (Success): DHCP Client Relay/AAA Client AAA Server Server ------ ---------------- ----------- -------- | 1.Discover{username} | | | | ---------------------> | 2.Access-Request | | | | {username} | | | | ---------------------> | | | | 3.Access-Challenge | | | | {username,challenge} | | | | <---------------------- | | | | 4. Discover{challenge,username} | | | ----------------------------------->| | 6.Offer{username | 5.Offer{challenge,username} | | challenge} | <-----------------------------------| | <--------------------- | | | | | | | | 7.Request{username, | | | | challenge, digest} | | | | ---------------------> | 8.Access-Request{user- | | | | name,challenge,digest} | | | | ----------------------> | | | | 9.Access-Accept | | | | <--------------------- | | | | 10.Request | | | ----------------------------------->| | | 11.Ack | | 12.Ack | <---------------------------------- | | <--------------------- | | | | | | | Figure 2: Digest Authentication example 1. The client sends DHCPDISCOVER message with username in User- Class option. 2. Upon receiving the DHCPDISCOVER message , relay agent extracts the username, then sends Access-Request to AAA server with username. 3. AAA server responses Access-Challenge with a challenge value . 4. Relay Agent puts the challenge value in Relay Agent User-based Authentication sub-option and forwards DHCPDISCOVER message to DHCP Server. 5. Upon receiving the forwarded DHCPDISCOVER message, DHCP Server extracts the challenge value from Relay Agent User-based Authentication sub-option and responses with a DHCPOFFER by Zhao & Li Expires January 10, 2008 [Page 5] Internet-Draft DHCP User-based Authentication July 2007 inserting the challenge to the User-based Authentication option. 6. Relay Agent forwards the DHCPOFFER to the client. 7. Upon receiving DHCPOFFER, client extracts the challenge value from user-based authentication option and calculates the digest using the user's password and the challenge value, then sends the DHCPREQUEST by inserting username into User-Class option and inserting digest into User-based Authentication option. 8. Upon receiving DHCPREQUEST, Relay agent extracts the username, digest response and challenge value and sends them to AAA Server by Access-Request message. 9. AAA server calculates the digest using the same input values and method and then compares the result with the value it received from client to authenticate the user. It responses with Access- Accept Response for successful authentication. 10. Relay Agent forwards the DHCPREQUEST message to DHCP Server with the authentication result . 11. Upon receiving the DHCPREQUEST message , DHCP Server checks the authentication result and then responses with DHCPACK to confirm the IP address allocation if the authentication is successful. 12. Relay Agent forwards DHCPACK to client, then client uses the allocated IP address to access the network. 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 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 challenge value to the client is not present. 4. DHCPv4 Options 4.1. User-based Authentication Option 4.1.1. Option Format Zhao & Li Expires January 10, 2008 [Page 6] Internet-Draft DHCP User-based Authentication July 2007 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 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: Zhao & Li Expires January 10, 2008 [Page 7] Internet-Draft DHCP User-based Authentication July 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Challenge ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the User-based Authentication option in a DHCPREQUEST/ DHCPACK for a 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Challenge ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Digest Response ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Challenge a random value which is used by HMAC-MD5 Digest Response the result by using the Digest generating function HMAC-MD5. The sender computes the Digest Response 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 'Challenge' field MUST be set to the random value used to generate the Digest Response. 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. Zhao & Li Expires January 10, 2008 [Page 8] Internet-Draft DHCP User-based Authentication July 2007 This sub-option is a new sub-option for the DHCP Relay Agent Information option. 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) [RFC4282] . 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 challenge field of the User-based Authentication option and computes the digest response 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 response 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 & Li Expires January 10, 2008 [Page 9] Internet-Draft DHCP User-based Authentication July 2007 6. DHCP Relay Agent Behavior In digest authentication mechanism: 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 response and the challenge value from the User-based authentication option, the username from the user-class option, forwards 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 succeeds, relay agent forwards the DHCPREQUEST to DHCP Server and MAY insert the identification and authorization attributes into the Radius Attributes sub-option [RFC4014]. 7. DHCP Server Behavior If the received request message includes the User-based Authentication option, the DHCP Server SHOULD includes the User-based Authentication option in the response message too. 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 Zhao & Li Expires January 10, 2008 [Page 10] Internet-Draft DHCP User-based Authentication July 2007 client state machine and results in retransmission of request message. 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 and have integrity and replay protection. 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. [RFC3004] Stump, G., Droms, R., and Y. Gu, "The User Class Option for DHCP", RFC 3004, November 2000. Zhao & Li Expires January 10, 2008 [Page 11] Internet-Draft DHCP User-based Authentication July 2007 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 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. [RFC4282] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 4282, Dec 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. Authors' Addresses Yuping Zhao Huawei Technologies Phone: (+86)-25-84565469 Email: zhaoyuping@huawei.com Zhao & Li Expires January 10, 2008 [Page 12] Internet-Draft DHCP User-based Authentication July 2007 Yizhou Li Huawei Technologies Phone: (+86)-25-84565470 Email: liyizhou@huawei.com Zhao & Li Expires January 10, 2008 [Page 13] Internet-Draft DHCP User-based Authentication July 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 & Li Expires January 10, 2008 [Page 14]