Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00

One concern I have is regarding per-client state on the server. I would
like to avoid that if possible.

In 2.1 in the draft it's suggested for 21.4.5.x that:

The server MUST record the identifier of the key selected for the
client so that it can validate further Information-request
messages from the client if the client reuses the same key for the
future exchanges.

I must confess I haven't looked much at DHCP authentication, but I think
it's nice to prevent per-client state for "stateless" (RFC3736) DHCP
servers if possible.

Wouldn't it be possible to pass some sort of key id to the client,
which the client can include in future exchanges? The server could
perhaps have a fixed mapping between key id's and keys, and based
on the id, the server knows which key to use. I'm not sure if you
see what I mean, but my idea is if possible to keep the necessary
state in the clients rather than the servers. Might this be
possible? Or would there be security problems?

Using assymetric crypto one could easily have just one fixed key
for all messages sent by the client. But I guess that might make
the server vulnerable to DoS attacks.

For stateless I think it's generally enough to authenticate the DHCP
server. In most cases I don't think it's important to guard against
replay, or to authenticate the client. That could perhaps simplify
the security mechanism. It's relatively easy to guard against replay
anyway though.

Stig

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg