Re: DHCP Authentication discussion at IETF...

John Carlson <johnc@cac.washington.edu> 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/1.1.8.2/17Jul96-0109PM) id AA02576; Tue, 15 Apr 1997 17:59:49 -0400
Date: Tue, 15 Apr 1997 17:59:49 -0400
Message-Id: <Pine.ULT.3.95.970415144048.25461G-100000@shiva2.cac.washington.edu>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: John Carlson <johnc@cac.washington.edu>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
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
Mime-Version: 1.0

On Fri, 11 Apr 1997, Ted Lemon wrote:

> Date: Fri, 11 Apr 1997 20:27:38 -0400
> From: Ted Lemon <mellon@hoffman.vix.com>
> Reply-To: dhcp-v4@bucknell.edu
> To: Multiple recipients of list <dhcp-v4@bucknell.edu>
> 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: johnc@cac.washington.edu 
University of Washington               BELL:     (206) 685-6204
4545 15th Ave NE                       FAX:	 (206) 685-4044 
Seattle, WA  98105