Re: DHCP Authentication discussion at IETF...
Olafur Gudmundsson <email@example.com> Mon, 21 April 1997 21:38 UTC
Received: from cnri by ietf.org id aa02423; 21 Apr 97 17:38 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa08119; 21 Apr 97 17:38 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/220.127.116.11/17Jul96-0109PM) id AA23977; Mon, 21 Apr 1997 17:33:54 -0400
Date: Mon, 21 Apr 1997 17:33:54 -0400
From: Olafur Gudmundsson <firstname.lastname@example.org>
To: Multiple recipients of list <email@example.com>
Subject: Re: DHCP Authentication discussion at IETF...
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
At 08:26 PM 4/11/97 -0400, Ted Lemon wrote: > >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. And server can authenticate packets from client. > >(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. Agreed > >(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. Yes, this would be nice, if this is a real problem. > >(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. Yes, most definitely > >(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. We can relax security requirements for limited functionality devices, if we can restrict the operations of these devices. For example, printer will not move and will never need to telnet out of local network. But we need to make sure we are actually talking to the printer not some laptop claiming to be the printer. > >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. Servers will always have to store all the keys that are still valid and I do not think that is different from storing address allocations. > > 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. Those things can not be secured unless you secure the wire, and put a input device that can read public key off bar code or magnetic card or pc card. > >(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. I agree with you here. It should be possible to detect replay atacks using MAC addresses, if you are worried about replay atacks originating on remote networks, then firewall or filtering router should be able to stop that. > > 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. > > Olafur