DHCP Authentication discussion at IETF...

Ted Lemon <mellon@hoffman.vix.com> Sat, 12 April 1997 00:45 UTC

Received: from cnri by ietf.org id aa23688; 11 Apr 97 20:45 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa23473; 11 Apr 97 20:45 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA20989; Fri, 11 Apr 1997 20:27:02 -0400
Date: Fri, 11 Apr 1997 20:27:02 -0400
Message-Id: <199704120008.RAA02142@andare.fugue.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Ted Lemon <mellon@hoffman.vix.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: DHCP Authentication discussion at IETF...
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

Having had some time to digest the results of our discussion about
DHCP Authentication on Wednesday, I've come up with my notion of a set
of requirements for that the authentication protocol needs to be able
to do, and also what it doesn't need to be able to do.   I'd be
interested in people's comments on this.

What I think we need to be able to do:

(1) Ensure that a client that frequently uses DHCP on a given network
    can easily authenticate packets supplied by the server.

(2) Ensure that it is possible, where appropriate, for a client that
    has never established a relationship with a particular
    administrative domain to prove its identity to the DHCP server in
    that domain and subsequently verify the server's identity.

(3) If it is required in a particular administrative domain, a client
    that has previously established a relationship with that domain
    should be able to *quickly* prove its identity to the DHCP server.
    Speed is important because the server is going to have to verify a
    lot of identities in rapid succession on Monday morning at 9:00 AM.

(4) If it is required in a particular domain, a client that has no
    pre-established relationship with that domain should be able to
    authenticate itself to DHCP servers in that domain.

(5) Support authentication with clients that can retain minimal state. 
    Clients that I have in mind are things like printers and X
    terminals.   Any state that these clients save has to go in NVRAM,
    which is usually a tight resource.   Fortunately, a characteristic
    that I believe these devices all share is that they do not roam
    from network to network very much.   The amount of state that
    these devices need to retain in order to do authentication should
    be pretty small - along the lines of the 01 authentication draft.

Problems I think we *might* want to solve:

(1) Requiring authentication of DHCPDISCOVER packets.

    One good reason for authenticating DHCPDISCOVER packets is that it
    gives us a key with which we can differentiate between clients and
    possibly supply them with different parameters or allocate
    addresses from different pools. 

    However, in the case of authentication of known clients, we can
    probably cache the key the client used last time and use this
    to pick an address.   In the (I think) unlikely event that the
    client is no longer using the same key, we can always send a
    DHCPNAK and next time do the allocation with the new key.   This
    will also work the first time the client boots, at which time we
    may not know what key it's going to use - we just guess, and if it
    turns out we're wrong, we cache the key, send a DHCPNAK, and start
    again.

    Caching key/client identifier pairs may require a fairly noticable
    change to the DHCP server, but the uses I've described will too,
    so I don't think it's unreasonable to say that you have to do one
    to do the other.

    Another reason to authenticate DHCPDISCOVER packets is to prevent
    a denial of service attack where a client repeatedly sends
    DHCPDISCOVER packets with different client identifiers.   If the
    server reserves addresses offered to clients, and a client is able
    to exhaust the entire address pool before its first reservation
    has expired, it can theoretically prevent the DHCP server from
    allocating addresses to legitimate clients.

    However, A DHCP server is not *required* to reserve any resources
    in response to a DHCPDISCOVER packet.   We should probably state
    that a server that does authentication SHOULD NOT reserve a lease
    that it offers in response to an unauthenticated DHCPOFFER, but
    should arrange to put that lease at the tail end of the list of
    available leases for that subnet, so that in the normal scheme of
    things, the lease will still be available when the authenticated
    DHCPREQUEST arrives.

Problems I think we do not need to solve:

(1) Authenticating clients that don't retain any state.

    I don't think we can do this without doing Kerberos or something
    like it and requiring the operator of the machine to type in a
    password prior to booting.   I can't think of any cases where this
    would actually make sense, although I'd be interested to know if
    anybody else can.   Even with Kerberos, we'd still have the time
    synchronization problem.

(2) Replay detection.

    First, a general observation on replay attacks: In general, if a
    client or server sends a particular DHCP packet, the response to
    that packet will always be the same.  Only in cases where there is
    congestion and contention over DHCP leases, or a change in
    configuration, is there any likelihood that, for example, the
    response to a DHCPDISCOVER will be a DHCPOFFER with a different
    address than was offered previously. 

    Consider the following replay attacks:

    - Replay of DHCPDISCOVER packets:
       All such a replay attack does is to make the server do work.
       Figuring out that a replay attack is occurring actually causes the
       server to do *more* work, making the attack more effective.

    - Replay of DHCPOFFER packets:
       There is some risk of a denial of service here - if an adversary
       can get a client to repeatedly accept an offer that it knows will
       not be honored when the client enters the REQUESTING state, then
       the adversary can prevent the client from booting.   However, it
       would require rather unusual circumstances for this attack to be
       possible, as mentioned earlier.

    - Replay of DHCPREQUEST packets:
       Such an attack could be used to continue to extend a lease
       after the legitimate client no longer needs it.   However, it
       would take a very patient adversary indeed to make this work as
       a denial of service attack, since the average client probably
       renews its lease before it expires most of the time - only when
       a client visits the network and then leaves, never to return,
       is this likely to be a major problem.   Because of the amount
       of time it would take to actually create a problem using this
       attack, it should be easily solved administratively.

    - Replay of DHCPACK packets:
       This could theoretically be used to convince a client that its
       lease has been extended when it has not.   This is still a
       pretty feeble denial of service attack, though - chances are
       that if the client asks to have its lease extended, the
       server's response will be pretty much the same as the replayed
       response.

       Probably the biggest risk of this attack is that the replayed
       DHCPACK message might contain stale configuration data.   If the
       IP address of the router on a particular subnet has changed, an
       adversary might be able to convince some clients that it hasn't.
       If the old address has been put into the allocation pool, this
       could be a big problem.

    - Replay of DHCPNAK packets:
       This could be a handy attack: capture a DHCPNAK packet for a
       particular client when it tries to reboot on network A after
       having previously booted on network B.   Then, next time it tries
       to boot, replay the NAK.   Keep doing this until they figure out
       where you're plugged into the network.   We can make this attack
       harder by stating that an authenticating client MUST compare the
       NAKed address to the REQUESTed address, and discard the NAK if
       they differ.   I'm not sure if RFC2131 says this explicitely.
       The adversary can still use this replay attack when the client is
       booting on network B and gets the same address it had before,
       but this should be pretty easy for an administrator to track
       down.

    I don't want to downplay the seriousness of these attacks.
    In particular, in the right combination of circumstances, a
    replayed DHCPACK could seriously compromise the security of a
    credulous client.   However, I think that all of these attacks are
    more easily addressed with a sensible security policy than with a
    heavyweight protocol - indeed, even with Olafur's protocol, 
    there's no real way to prevent replay attacks on the client, since
    it doesn't have a reliable time source of its own.  So perhaps as
    part of the eventual standard, or as an accompaniment to it, we
    should define a set of security policies that must be followed in
    order to prevent the serious compromise I described earlier and
    mitigate the denial-of-service attacks.