Re: Security Architecture for DHCP

Ted Lemon <mellon@hoffman.vix.com> Mon, 21 April 1997 18:15 UTC

Received: from cnri by ietf.org id aa22111; 21 Apr 97 14:15 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17617; 21 Apr 97 14:15 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA17007; Mon, 21 Apr 1997 14:07:35 -0400
Date: Mon, 21 Apr 1997 14:07:35 -0400
Message-Id: <199704211732.KAA05947@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: Re: Security Architecture for DHCP
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

> The expense is only at set up not during processing.  Your also assuming
> all nodes are booting monday morning and I don't believe that assumption
> is valid in all cases.  The cost of all nodes booting has many issues
> besides security.  I consider this argument a red herring.  

No, the expense happens every time you check the signature on a
message.   And we have a lot of evidence that the monday morning boot
rush _does_ happen, so even if it doesn't happen in all cases, we
still need to consider it.   This argument is most definitely _not_ a
red herring.   Asymmetric key signatures are *expensive*!

> I don't agree with you.  Having the client and server learn a key and
> and distributing them is less secure than public key using private keys
> a the client and server.  I also believe key recovery is easier with
> public key.

Like I said, you can use public key as a fallback when you haven't
already got a shared private key.   But if you have a shared private
key, it's a lot quicker to use that.   Why do we need key recovery?
Am I missing something here?

> Also your mail (which I just read again) focuses too much on DHCPv4
> and not enough on the problem and choice for client/server issues
> which I would like to see addressed first in the WG before we nail
> down solutions.  I think Olafur's draft heads us in that direction.
> But ignoring DHCPv6 or IPv6 is not wise.

I am not sufficiently conversant in the DHCPv6 protocol to speak to
security issues there - that's why I left that open.  However, you've
stated that you think the DHCPv6 problem can be solved with IPsec.  If
you're right, DHCPv6 is largely irrelevant to this discussion.  Are
you now saying that IPsec will not work for DHCPv6?

> I don't think this is an either/or situtation customers will want a
> choice here and to force symetric algorithms and strategy on them as the
> only solution IMO is not a good idea and I don't support that idea.

Precisely.  What I am proposing is that they have a choice between two
authentication methods, and that it be possible for this choice to be
made automatically in cases where both methods are needed.  One method
is a very expensive asymmetric key solution that will be very
CPU-intensive, but provides good ad-hoc authentication when no shared
secret exists.  The other is a much cheaper scheme which only works
when the client and server share a secret.

Can you tell me specifically what you don't like about this proposal?

			       _MelloN_