Re: [dhcwg] questions about DHCPv6 authentication

Christian Strauf <> Fri, 18 June 2004 09:53 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA10183; Fri, 18 Jun 2004 05:53:06 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BbFu0-0001Th-1N; Fri, 18 Jun 2004 05:43:16 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BbFmg-0007oc-G9 for; Fri, 18 Jun 2004 05:35:42 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id FAA09264 for <>; Fri, 18 Jun 2004 05:35:40 -0400 (EDT)
Received: from ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFmd-0001lK-OG for; Fri, 18 Jun 2004 05:35:39 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFkj-0001Pj-00 for; Fri, 18 Jun 2004 05:33:42 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1BbFjp-000154-00 for; Fri, 18 Jun 2004 05:32:45 -0400
Received: by (Postfix, from userid 1000) id 5343727585; Fri, 18 Jun 2004 11:32:45 +0200 (CEST)
Date: Fri, 18 Jun 2004 11:32:45 +0200
From: Christian Strauf <>
To: "JINMEI Tatuya / ?$B?@L@C#:H" <>
Subject: Re: [dhcwg] questions about DHCPv6 authentication
Message-ID: <>
References: <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.6i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


> > 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,
>              ^^^^^^^^^^^^^^^^^^^^
> and section 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 would make perfect sense even for RFC3736
style exchanges but not with the reference to section 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?
> 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.


dhcwg mailing list