[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
    <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]