<DHC> 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]
