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

>>>>> On Tue, 20 Jul 2004 16:55:08 +0200, 
>>>>> Stig Venaas <Stig.Venaas@uninett.no> said:

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

This might be implementation-dependent, but I guess it will work if we
do not have to worry about replay attacks; it is obvious we need
per-client/server state to implement replay detection.

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

I'm not sure why you mention the asymmetric crypto case, but the
current authentication mechanism defined for DHCPv6 does not use
asymmetric crypto.

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

On the one hand, I see and tend to agree that it's nice to prevent
per-client state for "stateless" DHCP.

On the other hand, we should be very careful when we are going to
justify something that could introduce weaker security.  While the
current main usage for stateless DHCP is client independent, the
specification leaves the possibility for per-client configuration
(otherwise, we could have prohibited including the client identifier
option in Information-request in the first place).  Regarding replay
attacks, the client might want to minimize the possibility of
receiving a replayed reply to Information-request that contains a very
small lifetime in the lifetime option.

Perhaps a possible compromise would be something like this:

- loosen the "MUST record the per-client state" to SHOULD
- allow (using MAY) the server to not record the state when replay
  attacks can be ignored and it is acceptable that Information-request
  is always non-authenticated

What do you think?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

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