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_
- Security Architecture for DHCP bound
- Re: Security Architecture for DHCP Ted Lemon
- Re: Security Architecture for DHCP bound
- Re: Security Architecture for DHCP bound
- Re: Security Architecture for DHCP Ted Lemon
- Re: Security Architecture for DHCP Olafur Gudmundsson
- Re: Security Architecture for DHCP bound