Re: [dhcwg] questions about DHCPv6 authentication

[Christian Strauf <[e-mail]>]

Jinmei-san,

> > the key distribution is done out-of-band, as stated in section 21.4.3.
> > Therefore, no inital exchange for key distribution is necessary.
> I know that.  Perhaps I was not clear enough, but I meant the
> following process by "negotiation the key":
> (we assume both the client and the server have a shared secret.  It's
> okay)
> 
> - the client sends a solicit message with an authentication option.
> - the server chooses one particular key identified by <DHCP realm,
>   client DUID, key id>
> - the server sends an advertise message with an authentication option
>   authenticated with the selected key
> - the client extracts the realm and key ID specified by the server
>   from the advertise message.  At this point, the client can identify
>   a particular key to be used for authentication in this session.
> 
> In fact, RFC3315 says:
> 
>    If the server has selected a key for the client in a previous message
>    exchange (see section 21.4.5.1),
>              ^^^^^^^^^^^^^^^^^^^^
> and section 21.4.5.1 talks about a solicit-advertise exchange.
thanks for the clarification. I can see the implications for Stateless
DHCPv6 clients now. The problem is that RFC3315 keeps talking about using
the Authentication Option in Solicit-Advertise exchanges for an initial key
negotiation (also in 21.4). However, I don't see why the inclusion of an
Authentication Option in an Information Request option shouldn't work as an
initial key negotiation equally well. Clearly, this is not reflected in
RFC3315 a.t.m.. Paragraph 21.4.4.4 would make perfect sense even for RFC3736
style exchanges but not with the reference to section 21.4.5.1. Paragraph
21.4 should probably also be more general without direct references to
Solicit-Advertise exchanges.

> > The way I
> > understand this section is that clients must keep using the same key they've
> > been using for any previous message exchange that included an authentication
> > option. Stateless DHCPv6 clients are free to use authentication options with
> > pre-shared keys the same way that RFC3315 clients do.
> 
> Are you assuming the following procedure?
[snip]
> If so, that *may* make sense.  However, I think it's very hard to
> imply the above just from the description in RFC3315.  And in that
Yes, I agree with you that this needs clarification.

> sense, I'd first like to know if this is the real intention of the RFC
> authors.
Good suggestion. I'm very interested in this as well.

> I'd still like to hear from others, particularly from the RFC authors,
> but so far it seems to me that the authentication mechanism will need
> some clarification.  Does it make sense to write a separate draft like
> "clarifications on the DHCPv6 authentication mechanism"?
I think it does. I've heard a number of questions regarding the security of
DHCPv6 in enterprise scenarios (it was also addressed in 6NET meetings) and
I believe that such a document may be a good reference for answering these
questions and for further work on DHCPv6 authentication mechanisms (which is
necessary in my eyes because the authentication mechanisms described in
RFC3315, though being sufficient in a good number of scenarios, may be
insufficient for some scenarios where e.g. X.509 based or some other form of
authentication might be desirable). I also know of implementors who would
appreciate a clarification document.

Christian


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