Re: Security Architecture for DHCP

[[e-mail]]

Ted,

>> 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 will not recant what Olafur stated.  I see your point on the boot as I
said.  From other mail to Olafur I now think your concerned about the
encrypt/decrypt of the message with the signature.  I have to check with
some one more expertise than I on the actual algorithm as to me it is
just a function call or overlay.  I will get back to you.  

But your saying the symetric algorithm is a lightweight scheme needed.
I have no issue with that as long as we don't state that the asymetric is not
part of our scope of work.

>> 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?

My customers are telling me they want this strong stuff.  But I see no
issue for 64bit Alphas either at this point in time.

Key recovery is a reality I must deal with to ship products except to U.S.
and Canada.  The mechanisms being defined to do this at present assume
public keys.  This is not my want but a requirement.  It is a market
requirement whether I am a crypto libertarian or not.

>> 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 think IPsec will work for DHCPv6 so I will talk to Olafur off line.  

>> 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.

I have no issue with that at all.

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

I think your requirements are fine  I assume they will be brought forth
into Olafur's draft.

Its not that I don't like it. Its that it is very DHCPv4 terminology
focused in the examples.  For example what happens with DHCPv6 with
SOLICIT is much different than DISCOVER and DHCPv6 uses multicast.
I don't think pursuing this discussion is useful.  If I thought your
"requirements" were way off I would have said so, but I do not.  

/jim