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

From: Christian Strauf <[email-masked]>
Date: Tue, 20 Jul 2004 16:23:41 +0200

Jinmei-san,

here are my first comments on the I-D. My overall impression of the I-D
is very good, it seems to include all the issues raised on the DHC-ML.
All comments I have are mostly minor things like language and typos, not
essential problems with the contents.

I like the comment that you make in para 2.1 about not having a real
"session" in stateless which is essentially a contradiction to
"stateless" on one hand but on the other hand one obviously needs to
strictly separate sessions that concern content transmitted via DHCP and
sessions that concern the transmission itself. I think that your
proposed rephrasing of Section 21.4.4.4 incorporates that nicely.

I paragraph 4. you write:

"A reasonable interpretation of the phrase is probably as follows: a
DHCPv6 message is called unauthenticated when it fails the validation
test described in Section 21.4.2, it does not contain an authentication
option, or when it includes an authentication option but does not have
authentication information when necessary."

I would propose a minor rephrasing to clear the language up a little (if
I understand the above paragraph correctly, the following rewording
should work):

"A reasonable interpretation of the phrase is as follows: a DHCPv6
message is called unauthenticated if it fails the validation test
described in Section 21.4.2, if it does not contain an authentication
option, or if it includes an authentication option without the necessary
authentication information."

I also like para 5.1. very much, especially the choice of highlighted
keywords is very good. I second the idea of proposing a default policy
of discarding non-authenticated messages.

Minor typos:

para 2.:
	-It should also be noted that [RFC3315] does not define how the
         server should do when it receives
        +It should also be noted that [RFC3315] does not define what the
         server should do when it receives

para 3.:
	-3.  What If Reply Is Detected
	+3.  What If Replay Is Detected

para 5.:
	-Apparently this contradicts with the requirement in Section
         21.4.2.
	+Apparently this contradicts the requirement in Section 21.4.2.

para 5.1.:
	-Accepting an non-authenticated
	+Accepting a non-authenticated

Thank you for writing this I-D up, it summarises important DHCP
authentication issues raised on the ML very well and gives the reader a
good idea where there're gaps in the standard and where clarifications
should be made. Additionally I think that this I-D is a good basis for
any future BCP document regarding DHCPv6 deployments where
authentication mechanisms are used.

Cheers,
Christian

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Tue, 20 Jul 2004 16:55:08 +0200

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 26 Jul 2004 16:58:40 +0900

Hello,

Thanks for your positive feedback, and sorry for the delayed response.

>>>>> On Tue, 20 Jul 2004 16:23:41 +0200, 
>>>>> Christian Strauf <[email-masked]> said:

> authentication information."

OK.  I've modified the local source of the draft with the suggested
change.

> 	+Accepting a non-authenticated

Thanks, fixed in the local source.  (The second and fourth typos
should already be fixed in the published version of the draft.  I
guess your comments are for a preliminary version available at my web
page.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 26 Jul 2004 18:10:35 +0900

>>>>> On Tue, 20 Jul 2004 16:55:08 +0200, 
>>>>> Stig Venaas <[email-masked]> said:

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

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

> the security mechanism. It's relatively easy to guard against replay

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