Re: Security Architecture for DHCP

[Olafur Gudmundsson <[e-mail]>]

At 02:05 PM 4/21/97 -0400, Ted Lemon wrote:
>
>> 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*!
Not correct, Public Key signatures are only on the initial authentication
messages. After that it is what ever the server and client agree to. 
Signature generation is expensive, verification is cheaper for some systems 
more expensive for others.

In my draft I stated that Security Association Lease should be longer but not
much longer than the Address lease. 
After thinking this over, I have come to the conclusion that I can relax
this requirement, it makes the protocol more complicated, but it addresses
the monday morning issue. 


Your suggestion last week of allowing the client to petition the server to 
use last Security Association is a good one, but it makes the protocol more
complicated. I can amend the protocol to add this initial step and fall
back on
the 4 step protocol if server declines. Now the protocol is now either 2
step or 6 step.  Client will still have to generate signature for the first
step. 
Server will still have to verify that signature. 

>
>> 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?
Lets leave Key recovery out this. It can be done in both cases. 

>
>> 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?
IPsec will not be able to do the Security Association work for DCHP in either
v4 or v6. DHCP will have to have its own protocol for that. 
My protocol is specified at  level where it will be able to work with both
v4 and v6. 
>
>> 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.

You can not get something for nothing, in the near future all kinds of
servers will have to perform many and complicated Public Key operations to
perform IPsec and
enter security associations. Think about the impact on mail servers for
large mailing lists. 
The question you are asking should be phrased as following: 
"What is the cheapest operations we can perform to meet the security
requirements?"

This brings us to a fundamental question what are DHCP security
requirements ? 

In the draft there is a section on security requirements, I would like for
people to comment on the requirements. 
>
>Can you tell me specifically what you don't like about this proposal?
I think your proposal is a good one, and I will try to work out the details
if people think it is important to save 
>
>			       _MelloN_
>
>