Y. Xu W. Hao J. Xie Internet Draft Huawei Technologies Expires: December 2021 June 4, 2021 Account based authentication for DHCP draft-xu-dhc-authen-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 December 4, 2021. Abstract This document describes the mutual authentication between DHCP server and DHCP client based on account information to mitigate the security risk caused by rogue DHCP server, and the problem of illegal DHCP client exhausting DHCP server address. Conventions used in this document 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 RFC-2119 [1]. Xu, et al Expires December 4, 2021 [Page 1] Internet-Draft Account based dhcp authen June 2021 This document uses the terms "DHCP server" (or "server") and "DHCP client" (or "client") as defined in RFC-2131 [2]. The term "DHCP relay agent" refers to a "BOOTP relay agent" as defined in RFC-2131 [2]. Table of Contents 1. Introduction ................................................ 3 2. Format of new options........................................ 3 2.1. User Name Option........................................ 3 2.2. Authentication Information Option....................... 3 2.2.1. Algorithm ......................................... 4 3. Two Keys .................................................... 5 3.1. Account key ............................................ 5 3.2. Share key .............................................. 5 4. Client side processing....................................... 5 4.1. INIT state ............................................. 5 4.2. INIT-REBOOT state....................................... 6 4.3. RENEWING state ......................................... 6 4.4. REBINDING state......................................... 6 4.5. DHCPINFORM message...................................... 6 4.6. DHCPRELEASE message..................................... 6 4.7. General considerations.................................. 6 5. Server considerations........................................ 7 5.1. General considerations.................................. 7 5.2. After receiving a DHCPDISCOVER message.................. 7 5.3. After receiving a DHCPREQUEST message................... 7 5.4. After receiving a DHCPINFORM message.................... 7 6. Security Considerations...................................... 7 7. IANA Considerations ......................................... 8 8. Acknowledgments ............................................. 8 8.1. Normative References.................................... 9 8.2. Informative References.................................. 9 Author's Addresses ............................................. 9 Copyright, Disclaimer, and Additional IPR Provisions........... 10 Xu, et al Expires December 4, 2021 [Page 2] Internet-Draft Account based dhcp authen June 2021 1. Introduction This document describes the mutual authentication between DHCP server and DHCP client based on account information like username instead of Secret ID that is described in [RFC 3118] section5.2 to mitigate the security risk caused by rogue DHCP server and the problem of exhausting DHCP server address caused by illegal DHCP client. Compared with [RFC 3118], by leveraging username or other account information for authentication, the following advantages could be achieved: 1. Facilitate to manage the DHCP Client accounts on the DHCP server. 2. Better integrate the authentication process between DHCP server and authentication server using the protocol of Radius, Active Directory, and etc. 2. Format of new options 2.1. User Name Option The following diagram defines the format of the user name option: 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 | User Name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User Name Option code: user name option. length: Length of the 'User Name' field in octets; variable. User Name: the user name of the DHCP Client. 2.2. Authentication Information Option Compared with [RFC 3118], the Secret ID is removed in the option and the format of this option will be changed into the following: Xu, et al Expires December 4, 2021 [Page 3] Internet-Draft Account based dhcp authen June 2021 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 | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSV | RDM | Replay Detection(64bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Detection cont. ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... | Authentication Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Information Option Code: authentication Information option. Length: The length field includes the lengths of the algorithm, the RSV, the RDM, the Replay Detection, the Replay Detection cont, the Authentication information fields in octets. Algorithm: The Algorithm field defines the algorithm used to generate the authentication information. RSV: Four bits are reserved for future use. These bits SHOULD be set to zero and MUST NOT be used when the option is processed. RDM: The Replay Detection Method field defines the method used to generate the Replay Detection Data. Replay Detection: The Replay Detection field contains a value used to detect replayed messages, which are interpreted according to the RDM. Four bits. Authentication Information: The Authentication Information field is usually a digest of the data in the DHCP packet and is computed using the HASH method that is specified through the Algorithm field. 2.2.1. Algorithm Algorithm 1 is assigned to the HMAC protocol by using the SHA-256 [3] hash function. All implementations MUST support Algorithm 1, the HMAC-SHA256[3] algorithm. New separate algorithm number could be specified for the future use of a different HASH technique. Xu, et al Expires December 4, 2021 [Page 4] Internet-Draft Account based dhcp authen June 2021 3. Two Keys 3.1. Account key For the interaction between the DHCP server and the fixed DHCP client, the key used is configured based on the user name on the DHCP server, and the DHCP client configures the same user name and key. This key is used to calculate authentication information for all messages of DHCP client no matter the message is unicast, broadcast or multicast, while for the DHCP server only the unicast message to the client needs to be authenticated based on the key. 3.2. Share key For the non-unicast messages sent by DHCP server to non-specific clients, the shared key is used. DHCP server and DHCP client MUST configure the same share key. 4. Client side processing Similar to the authentication behavior defined in [RFC 3118], the authentication behavior of a DHCP client based on account information is described as below: 4.1. INIT state When in INIT state, the client uses Account authentication as follows: 1. The client MUST include the User Name option and Authentication Information option in its DHCPDISCOVER message along with a client identifier option [5] to identify itself uniquely to the server. 2. The client MUST perform the Message validation described in [RFC3118] on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation, the client chooses one of the offered DHCP server. If no DHCPOFFER messages include authentication information or pass the validation test, the processing of the client is the same as that of not receiving DHCPOFFER. 3. The client replies with a DHCPREQUEST message that MUST include the user name option and authentication information option. 4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY Xu, et al Expires December 4, 2021 [Page 5] Internet-Draft Account based dhcp authen June 2021 log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. If the client accepted a DHCPOFFER message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server. 4.2. INIT-REBOOT state When in INIT-REBOOT state, the client MUST include the user name option and authentication information option in its DHCPREQUEST message. 4.3. RENEWING state When in RENEWING state, the client MUST include the user name option and authentication information option in its DHCPREQUEST message. 4.4. REBINDING state When in REBINDING state, the client MUST include the user name option and authentication information option in its DHCPREQUEST message. 4.5. DHCPINFORM message The client MUST include the user name option and authentication information option in its DHCPREQUEST message. 4.6. DHCPRELEASE message The client MUST include the user name option and authentication information option in its DHCPREQUEST message. 4.7. General considerations Both the user name option and authentication information option must be carried in all the messages sent by the DHCP client to the server. If there is only a user name without a password or only a password without a user name, the user name option and authentication information option are not carried, and the received message is not verified. When the client receives a broadcast or multicast message, the client uses server share key as specified in section 3 to compute Xu, et al Expires December 4, 2021 [Page 6] Internet-Draft Account based dhcp authen June 2021 authentication information. If no share key is configured locally in the client side, the authentication phase should be skipped. 5. Server considerations Similar to the authentication behavior defined in [RFC 3118], the authentication behavior of a DHCP server based on account information is described as below: 5.1. General considerations 1. Each DHCP server maintains a list of account keys for each DHCP client. 2. The unicast message sent by the DHCP server to a specific client uses the account key of the client. If there is no account key, there is no need to encapsulate the authentication information option. If it is a broadcast and multicast message sent to a non- specific client, the server's share key should be used. If there is no share key, there is no need to further encapsulate the authentication information option. 5.2. After receiving a DHCPDISCOVER message When the server receives a DHCP DISCOVER message from the client, firstly it finds the corresponding key according to the user name option, then computes the authentication information based on the key, and finally get the validation result for the message. If the message is legal, it will respond to DHCPOFFER message and use the same key to computes authentication information. 5.3. After receiving a DHCPREQUEST message Compared with [RFC 3118] message validation process, the only difference is that the server should validate the message based on user name instead of secret ID. 5.4. After receiving a DHCPINFORM message If the message fails to pass validation or the server did not get the key corresponding to the user name, the server MUST discard the message and MAY choose to log the validation failure. 6. Security Considerations No additional security Considerations are introduced here besides the corresponding description that is defined in [RFC 3118], it only Xu, et al Expires December 4, 2021 [Page 7] Internet-Draft Account based dhcp authen June 2021 provides an alternative DHCP authentication method to alleviate the security risk of server counterfeiting, illegal client attack and exhaustion of server address could be alleviated. 7. IANA Considerations Two new number spaces for the Authentication information option's 'Algorithm' and 'Replay Detection Method' fields need to be newly introduced. 8. Acknowledgments The authors wish to acknowledge the important contributions of Zengke Wei and Jian Wang. Xu, et al Expires December 4, 2021 [Page 8] Internet-Draft Account based dhcp authen June 2021 References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 8.2. Informative References [3] R. Droms, W. Arbaugh, “Authentication for DHCP Messages”, RFC 3118, June 2001 [4] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002. [5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,January 2001. [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Author's Addresses Yibin Xu Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: xuyibin@huawei.com Weiguo Hao Xu, et al Expires December 4, 2021 [Page 9] Internet-Draft Account based dhcp authen June 2021 Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: haoweiguo@huawei.com Jianping Xie Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: xiejianping@huawei.com Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Xu, et al Expires December 4, 2021 [Page 10]