Subject: Authentication for DHCPv6

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Jun 2001 15:36:59 -0400

I've completed the text for authentication in the DHCPv6 spec.  I've 
excerpted the relevant sections from the draft and included the text 
below.  Because authentication added a fair amount of new text, I'd like to 
start getting feedback on this text while I finish other revisions to the 
spec.  So, I would appreciate your review and any comments you might have 
on this text.

Those of you who have read the DHCPv4 authentication RFC will recognize 
much of this text.  Watch the section numbers in the text below; I've 
elided sections not of interest to the authentication spec...

- Ralph

=====

17. Authentication of DHCP messages

    Some network administrators may wish to provide authentication of
    the source and contents of DHCP messages.  For example, clients may
    be subject to denial of service attacks through the use of bogus
    DHCP servers, or may simply be misconfigured due to unintentionally
    instantiated DHCP servers.  Network administrators may wish to
    constrain the allocation of addresses to authorized hosts to avoid
    denial of service attacks in "hostile" environments where the network
    medium is not physically secured, such as wireless networks or
    college residence halls.

    Because of the risk of denial of service attacks against DHCP
    clients, the use of authentication is mandated in Reconfigure-init
    messages.  A DHCP server MUST include an authentication option in
    Reconfigure-init messages sent to clients.

    The DHCP authentication mechanism is based on the design of
    authentication for DHCP for IPv4 [8].

17.1. DHCP threat model

    The threat to DHCP is inherently an insider threat (assuming a
    properly configured network where DHCPv6 ports are blocked on
    the enterprise's perimeter gateways.)  Regardless of the gateway
    configuration, however, the potential attacks by insiders and
    outsiders are the same.

    The attack specific to a DHCP client is the possibility of the
    establishment of a "rogue" server with the intent of providing
    incorrect configuration information to the client.  The motivation
    for doing so may be to establish a "man in the middle" attack or it
    may be for a "denial of service" attack.

    There is another threat to DHCP clients from mistakenly or
    accidentally configured DHCP servers that answer DHCP client requests
    with unintentionally incorrect configuration parameters.

    The threat specific to a DHCP server is an invalid client
    masquerading as a valid client.  The motivation for this may be for
    "theft of service", or to circumvent auditing for any number of
    nefarious purposes.

    The threat common to both the client and the server is the resource
    "denial of service" (DoS) attack.  These attacks typically involve
    the exhaustion of valid addresses, or the exhaustion of CPU or
    network bandwidth, and are present anytime there is a shared
    resource.  In current practice, redundancy mitigates DoS attacks the
    best.

17.2. Summary of DHCP authentication

    Authentication of DHCP messages is accomplished through the use of
    the Authentication option.  The authentication information carried
    in the Authentication option can be used to reliably identify the
    source of a DHCP message and to confirm that the contents of the DHCP
    message have not been tampered with.

    The Authentication option provides a framework for multiple
    authentication protocols.  Two such protocols are defined here.
    Other protocols defined in the future will be specified in separate
    documents.

    The protocol field in the Authentication option identifies the
    specific protocol used to generate the authentication information
    carried in the option.  The algorithm field identifies a specific
    algorithm within the authentication protocol; for example, the
    algorithm field specifies the hash algorithm used to generate the
    message authentication code (MAC) in the authentication option.  The
    replay detection method (RDM) field specifies the type of replay
    detection used in the replay detection field.

17.3. Replay detection

    The Replay Detection Method (RDM) field determines the type of replay
    detection used in the Replay Detection field.

    If the RDM field contains 0x00, the replay detection field MUST be
    set to the value of a monotonically increasing counter.  Using a
    counter value such as the current time of day (e.g., an NTP-format
    timestamp [12]) can reduce the danger of replay attacks.  This method
    MUST be supported by all protocols.

17.4. Configuration token protocol

    If the protocol field is 0, the authentication information field
    holds a simple configuration token.  The configuration token is an
    opaque, unencoded value known to both the sender and receiver.  The
    sender inserts the configuration token in the DHCP message and the
    receiver matches the token from the message to the shared token.  If
    the configuration option is present and the token from the message
    does not match the shared token, the receiver MUST discard the
    message.

    Configuration token may be used to pass a plain-text configuration
    token and provides only weak entity authentication and no message
    authentication.  This protocol is only useful for rudimentary
    protection against inadvertently instantiated DHCP servers.

    DISCUSSION:

       The intent here is to pass a constant, non-computed token
       such as a plain-text password.  Other types of entity
       authentication using computed tokens such as Kerberos
       tickets or one-time passwords will be defined as separate
       protocols.

17.5. Delayed authentication protocol

    If the protocol field is 1, the message is using the "delayed
    authentication" mechanism.  In delayed authentication, the client
    requests authentication in its Solicit message and the server replies
    with an Advertise message that includes authentication information.
    This authentication information contains a nonce value generated by
    the source as a message authentication code (MAC) to provide message
    authentication and entity authentication.

    The use of a particular technique based on the HMAC protocol [10]
    using the MD5 hash [18] is defined here.

17.5.1. Management issues in the delayed authentication protocol

    The "delayed authentication" protocol does not attempt to address
    situations where a client may roam from one administrative domain
    to another, i.e.  interdomain roaming.  This protocol is focused on
    solving the intradomain problem where the out-of-band exchange of a
    shared secret is feasible.

17.5.2. Use of the Authentication option in the delayed authentication
    protocol

    In a Solicit message, the Authentication option carries the Protocol,
    Algorithm, RDM and Replay detection fields, but no Authentication
    information.

    In an Advertise, Request, Renew, Rebind or Confirm message, the
    Authentication option carries the Protocol, Algorithm, RDM and Replay
    detection fields and Authentication information.  The format of the
    Authentication information 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Secret ID (32 bits)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     HMAC-MD5 (128 bits)                       |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The following definitions will be used in the description of the
    authentication information for delayed authentication, algorithm 1:

    Replay Detection  - as defined by the RDM field
    K                 - a secret value shared between the source and
                        destination of the message; each secret has a
                        unique identifier (secret ID)
    secret ID         - the unique identifier for the secret value
                        used to generate the MAC for this message
    HMAC-MD5          - the MAC generating function.

    The sender computes the MAC using the HMAC generation algorithm [10]
    and the MD5 hash function  [18].  The entire DHCP message (except
    as noted below), including the DHCP message header and the options
    field, is used as input to the HMAC-MD5 computation function.  The
    'secret ID' field MUST be set to the identifier of the secret used to
    generate the MAC.

    DISCUSSION:

       Algorithm 1 specifies the use of HMAC-MD5.  Use of a
       different technique, such as HMAC-SHA, will be specified as
       a separate protocol.

       Delayed authentication requires a shared secret key for each
       client on each DHCP server with which that client may wish
       to use the DHCP protocol.  Each secret key has a unique
       identifier that can be used by a receiver to determine which
       secret was used to generate the MAC in the DHCP message.
       Therefore, delayed authentication may not scale well in an
       architecture in which a DHCP client connects to multiple
       administrative domains.

17.5.3. Message validation

    To validate an incoming message, the receiver first checks that
    the value in the replay detection field is acceptable according
    to the replay detection method specified by the RDM field.  Next,
    the receiver computes the MAC as described in [10].  The receiver
    MUST set the 'MAC' field of the authentication option to all 0s for
    computation of the MAC, and because a DHCP relay agent may alter
    the values of the 'giaddr' and 'hops' fields in the DHCP message,
    the contents of those two fields MUST also be set to zero for the
    computation of the MAC. If the MAC computed by the receiver does not
    match the MAC contained in the authentication option, the receiver
    MUST discard the DHCP message.

17.5.4. Key utilization

    Each DHCP client has a key, K. The client uses its key to encode
    any messages it sends to the server and to authenticate and verify
    any messages it receives from the server.  The client's key SHOULD
    be initially distributed to the client through some out-of-band
    mechanism, and SHOULD be stored locally on the client for use in all
    authenticated DHCP messages.  Once the client has been given its key,
    it SHOULD use that key for all transactions even if the client's
    configuration changes; e.g., if the client is assigned a new network
    address.

    Each DHCP server MUST know, or be able to obtain in a secure manner,
    the keys for all authorized clients.  If all clients use the same
    key, clients can perform both entity and message authentication for
    all messages received from servers.  However, the sharing of keys
    is strongly discouraged as it allows for unauthorized clients to
    masquerade as authorized clients by obtaining a copy of the shared
    key.  To authenticate the identity of individual clients, each client
    MUST be configured with a unique key.

17.5.5. Client considerations for delayed authentication protocol

17.5.5.1. Sending Solicit messages

    When the client sends a Solicit message and wishes to use
    authentication, it includes an Authentication option with the desired
    protocol, algorithm, RDM and replay detection field as described
    in section 17.5.  The client does not include any authentication
    information in the Authentication option.

17.5.6. Receiving Advertise messages

    The client validates any Advertise messages containing an
    Authentication option specifying the delayed authentication protocol
    using the validation test described in section 17.5.3.

    Client behavior if no Advertise messages include authentication
    information or pass the validation test is controlled by local policy
    on the client.  According to client policy, the client MAY choose to
    respond to a Advertise message that has not been authenticated.

    The decision to set local policy to accept unauthenticated messages
    should be made with care.  Accepting an unauthenticated Advertise
    message can make the client vulnerable to spoofing and other
    attacks.  If local users are not explicitly informed that the client
    has accepted an unauthenticated Advertise message, the users may
    incorrectly assume that the client has received an authenticated
    address and is not subject to DHCP attacks through unauthenticated
    messages.

    A client MUST be configurable to discard unauthenticated messages,
    and SHOULD be configured by default to discard unauthenticated
    messages.  A client MAY choose to differentiate between Advertise
    messages with no authentication information and Advertise messages
    that do not pass the validation test; for example, a client might
    accept the former and discard the latter.  If a client does accept an
    unauthenticated message, the client SHOULD inform any local users and
    SHOULD log the event.

17.5.6.1. Sending Request, Confirm, Renew, Rebind or Release messages

    If the client authenticated the Advertise message through which the
    client selected the server, the client MUST generate authentication
    information for subsequent Request, Confirm, Renew, Rebind or Release
    messages sent to the server as described in section 17.5.  When the
    client sends a subsequent message, it MUST use the same secret used
    by the server to generate the authentication information.

17.5.6.2. Receiving Reply messages

    If the client authenticated the Advertise it accepted, the client
    MUST validate the associated Reply message from the server.  The
    client MUST discard the Reply if the message fails to pass validation
    and MAY log the validation failure.  If the Reply fails to pass
    validation, the client MUST restart the DHCP configuration process by
    sending a Solicit message.  The client MAY choose to remember which
    server replied with a Reply message that failed to pass validation
    and discard subsequent messages from that server.

    If the client accepted an Advertise message that did not include
    authentication information or did not pass the validation test, the
    client MAY accept an unauthenticated Reply message from the server.

17.5.7. Server considerations for delayed authentication protocol

17.5.7.1. Receiving Solicit messages and Sending Advertise messages

    The server selects a secret for the client and includes
    authentication information in the Advertise message returned to the
    client as specified in section 17.5.  The server MUST record the
    identifier of the secret selected for the client and use that same
    secret for validating subsequent messages with the client.

17.5.7.2. Receiving Request, Confirm, Renew, Rebind or Release messages
    and Sending Reply messages

    The server uses the secret identified in the message and validates
    the message as specified in section 17.5.3.  If the message fails to
    pass validation or the server does not know the secret identified by
    the 'secret ID' field, the server MUST discard the message and MAY
    choose to log the validation failure.

    If the message passes the validation procedure, the server responds
    to the specific message as described in section 14.4.  The server
    MUST include authentication information generated using the secret
    identified in the received message as specified in section 17.5.

17.5.7.3. Sending Reconfigure-Init messages

    The server MUST include authentication information in a
    Reconfigure-Init message, generated as specified in section 17.5
    using the secret the server initially selected for the client to
    which the Reconfigure-Init message is to be sent.

18. DHCP options

    Options are used to carry additional information and parameters
    in DHCP messages.  Every option shares a common base format, as
    described in section 18.1.

    This document describes the DHCP options defined as part of the base
    DHCP specification.  Other options may be defined in the future in a
    separate document.

18.1. Format of DHCP options

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          option-code          |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          option-data                          |
      |                      (option-len octets)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       option-code   An unsigned integer identifying the specific option
                     type carried in this option.

       option-len    An unsigned integer giving the length of the data in
                     this option in octets.

       option-data   The data for the option; the format of this data
                     depends on the definition of the option.

18.9. Authentication option

    The Authentication option carries authentication information to
    authenticate the identity and contents of DHCP messages.  The use of
    the Authentication option is described in section 17.

    The format of the Authentication option 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OPTION_AUTH          |        option-length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Protocol    |   Algorithm   |      RDM      | Replay detect.|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Replay Detection (64 bits)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Replay cont.                  | Auth. Info    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |           Authentication Information                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       option-code                  OPTION_AUTH (TBD)

       option-length                Variable

       protocol                     The authentication protocol used in
                                    this authentication option

       algorithm                    The algorithm used in the
                                    authentication protocol

       RDM                          The replay detection method used in
                                    this authentication option

       Replay detection             The replay detection information for
                                    the RDM

       Authentication information   The authentication information,
                                    as specified by the protocol and
                                    algorithm used in this authentication
                                    option

24. IANA Considerations

    This document defines several new name spaces associated with DHCPv6
    and DHCPv6 options.  IANA is requested to manage the allocation of
    values from these name spaces.

    New values in each of these name spaces should be approved by the
    process of IETF Consensus [14].

24.5. Authentication option

    Section 17 defines three new name spaces associated with the
    Authentication Option (section 18.9), which are to be created and
    maintained by IANA: Protocol, Algorithm and RDM.

    Initial values assigned from the Protocol name space are 0 (for the
    configuration token Protocol in section 17.4) and 1 (for the delayed
    authentication Protocol in section 17.5).  Additional protocols may
    be defined in the future.

    The Algorithm name space is specific to individual Protocols.  That
    is, each Protocol has its own Algorithm name space.  The guidelines
    for assigning Algorithm name space values for a particular protocol
    should be specified along with the definition of a new Protocol.

    For the configuration token Protocol, the Algorithm field MUST be
    0, as described in section 17.4.  For the delayed authentication
    Protocol, the Algorithm value 1 is assigned to the HMAC-MD5
    generating function as defined in section 17.5.  Additional
    algorithms for the delayed authentication protocol may be defined in
    the future.

    The initial value of 0 from the RDM name space is assigned to the
    use of a monotonically increasing value as defined in section 17.3.
    Additional replay detection methods may be defined in the future.

References

     [8] R. Droms and W. Arbaugh.  Authentication for DHCP Messages.
         Internet Draft, Internet Engineering Task Force, January 2001.
         Work in progress.

    [10] H. Krawczyk, M. Bellare, and R. Canetti.  HMAC: Keyed-Hashing
         for Message Authentication.  Request for Comments
         (Informational) 2104, Internet Engineering Task Force,
         February 1997.

    [12] David L. Mills.  Network Time Protocol (Version 3)
         Specification, Implementation.  Request for Comments (Draft
         Standard) 1305, Internet Engineering Task Force, March 1992.

    [14] T. Narten and H. Alvestrand.  Guidelines for Writing an IANA
         Considerations Section in RFCs.  Request for Comments (Best
         Current Practice) 2434, Internet Engineering Task Force, October
         1998.

    [18] R. Rivest.  The MD5 Message-Digest Algorithm.  Request for
         Comments (Informational) 1321, Internet Engineering Task Force,
         April 1992.