Re: DHCP Authentication discussion at IETF...
John Carlson <email@example.com> Tue, 15 April 1997 22:05 UTC
Received: from cnri by ietf.org id aa12695; 15 Apr 97 18:05 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa21529; 15 Apr 97 18:05 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/220.127.116.11/17Jul96-0109PM) id AA02576; Tue, 15 Apr 1997 17:59:49 -0400
Date: Tue, 15 Apr 1997 17:59:49 -0400
From: John Carlson <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
On Fri, 11 Apr 1997, Ted Lemon wrote: > Date: Fri, 11 Apr 1997 20:27:38 -0400 > From: Ted Lemon <firstname.lastname@example.org> > Reply-To: email@example.com > To: Multiple recipients of list <firstname.lastname@example.org> > Subject: DHCP Authentication discussion at IETF... > > > 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. > <stuff deleted> > > 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. Ted, Prudent changes of the value of the transaction id field by the client should reduce, if not eliminate, replay attacks. No? johnc ------------------------------------------------------------------------------- John D. Carlson Networks and Distributed Computing EMAIL: email@example.com University of Washington BELL: (206) 685-6204 4545 15th Ave NE FAX: (206) 685-4044 Seattle, WA 98105