DHCP Authentication discussion at IETF...
Ted Lemon <firstname.lastname@example.org> 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/188.8.131.52/17Jul96-0109PM) id AA20989; Fri, 11 Apr 1997 20:27:02 -0400
Date: Fri, 11 Apr 1997 20:27:02 -0400
From: Ted Lemon <email@example.com>
To: Multiple recipients of list <firstname.lastname@example.org>
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.