Subject: [dhcwg] DHCPv6 Client Authentication question

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Aug 2014 18:57:27 +0000

I have a requirement for DHCPv6 servers to be able to authenticate
clients on links where a rogue client may try to impersonate a real
one. I have read RFC3315, Section 21 several times but I am still
not understanding whether "Delayed Authentication" gives me what I
am looking for. For example, I would like Clients to be able to use
a two-message Solicit/Reply exchange instead of a four-message
Solicit/Advertise/Request/Reply exchange, but I'm not sure that
can be securely accommodated by Delayed Authentication.

That said, I have seen ""Secure DHCPv6 with Public Key":

http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

and it looks like it could fit the bill although a bit heavier in
weight than what I was hoping for.

So, the question is whether my requirement can be satisfied by the
base RFC3315 mechanisms alone, or must I use the new Secure DHCPv6
mechanisms mentioned above?

Thanks - Fred
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Aug 2014 22:28:46 +0200

In your previous mail you wrote:

=> the only relationship between "Delayed Authentication" and
real authentication is in its name... (:-)

>  mechanisms mentioned above?

=> the second (Secure DHCPv6) of course.

Regards

[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 Aug 2014 21:48:59 +0000

Thanks Francis,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 20, 2014 1:29 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [dhcwg] DHCPv6 Client Authentication question
> 

Is it just me, or are the RFC3315 DHCPv6 authentication mechanisms
a bit sketchy? Is anyone using them in actual practice?

Thanks - Fred
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2014 16:36:26 +0200

In your previous mail you wrote:

>  a bit sketchy?

=> my recommendation as a multiple implementor of DHCPv6 was (and still
is) to explain to someone who ask for support of this what this really
does. Note I've never seen such request to go further...

>  Is anyone using them in actual practice?

=> I've heart it is supported and used so someone found an use case.
I suggest to look for a DHCPv6 implementation with support of this,
and to ask implementors (or to wait as they should be in this list :-).

Regards

PS: securing ND or DHCPv6 is a very hard problem. We have a solution
for ND (SeND) so we should get one for DHCPv6. Unfortunately it will
likely share SeND complexity, deployment costs and lack of public
market (public == not military or similar).
For your application, the cost of the current secure DHCPv6 proposal
comes mainly from the intra-exchange constraint (vs inter-exchange,
think about DTLS for instance where security contexts spend over
far more than one packet).

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Aug 2014 16:38:59 +0000

Hi Francis,

Thanks for your responses. I have a case where securing IPv6 ND
and DHCPv6 is made a bit easier because IPv6 hosts have a trust
basis for trusting their default routers and DHCPv6 clients have
a trust basis for trusting their DHCPv6 servers. IPv6 nodes can
then come to trust one another by leveraging these shared trust
anchors.

With this in mind, I feel I may need just a bit more additional
security which I think can be provided by DHCPv6 auth as long as
it is widely implemented and known to work. Can implementers who
watch this list comment?

Thanks - Fred

> Sent: Thursday, August 21, 2014 7:36 AM
> To: Templin, Fred L
> Cc: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Aug 2014 10:51:07 -0700

At Thu, 21 Aug 2014 16:38:59 +0000,

> it is widely implemented and known to work. Can implementers who

Is this about the DHCPv6 authentication defined in RFC3315 or the one
defined in draft-ietf-dhc-sedhcpv6-03?  And comment on what?  About
whether it's widely implemented and known to work?

At least for dhc-sedhcpv6 I don't know of any implementation.

I know there are several different implementations of the original
DHCPv6 authentication.  For example, the WIDE-DHCPv6 server and client
implementation (http://sourceforge.net/projects/wide-dhcpv6/) supports
the delayed authentication protocol.  There were even interoperability
tests among different implementations (many years ago, if my memory
serves correctly), so to that
extent they are "known to work".  But I don't know of any production
level deployment of the protocol; I actually suspect there's none.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Aug 2014 17:56:14 +0000

Hi,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Thursday, August 21, 2014 10:51 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]

This is very helpful input, and answers many of my questions in
a single pass.

If anyone else knows of production deployment of RFC3315 DHCP
auth I would appreciate hearing about it.

Thanks - Fred