Re: Security Architecture for DHCP

[[e-mail]]

Ted,

>Jim, there is some disagreement as to whether public key, by itself,
>will be a good choice for the DHCP authentication protocol.  The
>reason is that public key signatures are fairly expensive to compute,
>and since we have to do it for every packet, this limits the number of
>transactions per second that a general purpose computer is likely to
>be able to support.  This gets to be a big problem on Monday morning
>at 9:00 AM when 10,000 or more nodes try to boot at once.

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.  

>My personal belief is that private, shared secrets should be used in
>the default case, with public key as a fallback for cases where the
>server and the client are not yet known to each other.

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.

>Did you by any chance have a chance to read the message I posted last
>week on what I thought the requirements for DHCP authentication were?

Yes and I just read it again.  I am giving Olafur my input.  Right now
it is just input just like yours.  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 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.

/jim


			       _MelloN_