Re: DHCP Authentication discussion at IETF...

[Ted Lemon <[e-mail]>]

> >(1) Ensure that a client that frequently uses DHCP on a given network
> >    can easily authenticate packets supplied by the server.
> And server can authenticate packets from client. 

Yes, but in some cases it may not be necessary for the client to
authenticate itself to the server (e.g., an open network, and you
don't care who accesses it), but even in that case it's probably
desirable for the server to authenticate itself to the client.  I
tried to make this clear in my previous message, but I think I did a
poor job of it - sorry about that.

> >(3) If it is required in a particular administrative domain, a client
> >    that has previously established a relationship with that domain
> >    should be able to *quickly* prove its identity to the DHCP server.
> >    Speed is important because the server is going to have to verify a
> >    lot of identities in rapid succession on Monday morning at 9:00 AM.
> Yes, this would be nice, if this is a real problem.

Several people stood up and said it was a problem for them at the WG
session in Memphis, so I think we can consider it to be a problem.   I
have at least one user at a university site with a 10,000 node network
who would probably object to having to buy a really expensive piece of
iron just to do DHCP - I think he's running it on a SparcStation 5
right now, which is not exactly speedy.   We could say ``too bad, buy
big iron'', but why do that if we don't have to?

> We can relax security requirements for limited functionality devices, if we
> can restrict the operations of these devices. For example, printer will not
> move and
> will never need to telnet out of local network. 
> But we need to make sure we are actually talking to the printer not some
> laptop claiming to be the printer. 

Again, I think it's more important that the printer be able to be sure
that it is talking to a real server and not some laptop claiming to
be a server, although the reverse is certainly worth considering.
And I think that this sort of situation can be dealt with by requiring
the sysadmin to punch in a 64-bit or 128-bit secret on the printer
console, or to preconfigure it over a serial line prior to
installation at its final destination.

> Servers will always have to store all the keys that are still valid and I
> do not think that is different from storing address allocations. 

Yup.

> >(1) Authenticating clients that don't retain any state.
> >
> >    I don't think we can do this without doing Kerberos or something
> >    like it and requiring the operator of the machine to type in a
> >    password prior to booting.   I can't think of any cases where this
> >    would actually make sense, although I'd be interested to know if
> >    anybody else can.   Even with Kerberos, we'd still have the time
> >    synchronization problem.
> Those things can not be secured unless you secure the wire, and put a input
> device that can read public key off bar code or magnetic card or pc card.  

If you could count on the local clock, you could just have the user
type in a password at boot time and do Kerberos authentication that
way, but I still don't think it's worth it, and we probably can't
count on the local clock anyway if the client doesn't even have NVRAM.

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

Sorry, I misspoke.  What I am objecting to here is that the monday
morning traffic that we're worried about will probably involve one
signature and one signature verification for each client that boots,
which means (I think) that we don't want to do this every time a
client boots.  If we don't have to do a public key sign/verify at
INIT-REBOOT, then we're probably fine.

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

Agreed.

> In the draft there is a section on security requirements, I would like for
> people to comment on the requirements. 

I thought that was what I was doing.   :')

> 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 am not sure I know what you are suggesting here.   Are you
suggesting that in a two-step protocol (i.e., INIT-REBOOT), the client
*must* sign its DHCPREQUEST with its private key, and the server must
verify that signature?   Or are you saying that the client can sign
with the shared secret it used last time it booted, and let the
protocol get more complicated if it turns out that it's moved to a new
net since it was shut down?

I think the set of cases where public key encryption is required for
authentication should be quite small - the only cases where it should
be necessary are when a client is first set up and when a client moves
to an administrative domain in which it has never booted before.  Even
in these cases, it should be possible for the client and server to be
configured with a shared secret without using public key encryption,
both for the benefit of clients that don't have room for a public key
in NVRAM and for the benefit of client and server vendors that cannot
use encryption because they don't live in free countries, but can use
a one-way hash for authentication.

In any case, based on the discussions we have had, I think the next
step should be for you (if you are willing) to generate a new draft
that includes what you think needs to be added and what you think the
requirements are based on our discussion at IETF and our discussions
on the mailing list - I think we've gone too far since you produced
the previous draft for it to be a useful basis for discussion.   If
you don't feel like producing a new draft, I'll be happy to do one,
but I think you understand the v6 and Public Key issues better than I
do.

			       _MelloN_