Subject: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 26 Oct 2014 22:11:25 +0000

Hi all,

This message starts the (short) DHC working group last call to advance "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-04, document as a Standards Track (Proposed Standard) RFC. The authors believe that this version is ready. We had a WGLC earlier (May 2014 for the -02 version) and there were some comments, so this is primarily to assure that those comments were addressed.

The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-04

Please send your comments by November 3rd, 2014. If you do not feel this document should advance, please state your reasons why.

There are no IPR claims reported at this time.

Tomek is the assigned shepherd for this document.

- Tomek & Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Oct 2014 20:48:58 +0000

Hi,

I am quite fine with the Client trusting the Server by leap of faith. In the other
direction, I need some way for the Client to prove to the Server that it is the
authentic owner of the claimed Client ID.

Does this new document version provide that?

Thanks - Fred
[email-masked]

---
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, October 26, 2014 3:11 PM
To: [email-masked]
Subject: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi all,

- Tomek & Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 28 Oct 2014 02:45:05 +0000

>Does this new document version provide that?

Hi, Fred,

This version has provided a certificate-based mechanism for the client to authenticated by the server. It is assuming the client has a certificate honored by the server.

Best regards,

Sheng

>This message starts the (short) DHC working group last call to advance
>"Secure DHCPv6", draft-ietf-dhc-sedhcpv6-04, document as a Standards Track
>(Proposed Standard) RFC. The authors believe that this version is ready. We
>had a WGLC earlier (May 2014 for the -02 version) and there were some
>comments, so this is primarily to assure that those comments were
>addressed.
>
>Please send your comments by November 3rd, 2014. If you do not feel this
>document should advance, please state your reasons why.
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Oct 2014 14:56:35 +0000

> -----Original Message-----
> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Monday, October 27, 2014 7:45 PM
> To: Templin, Fred L; Bernie Volz (volz); [email-masked]
> Cc: Zhangdacheng (Dacheng)
> Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014
> 

Right, I saw that but help me out here. If the client claims a DUID is the certificate
proof enough that the client is the authorized owner of the DUID?

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Wed, 29 Oct 2014 10:58:24 -0700

At Tue, 28 Oct 2014 14:56:35 +0000,

> proof enough that the client is the authorized owner of the DUID?

In my understanding it's not guaranteed by the described protocol: any
client that has a valid certificate can "steal" someone else's DUID
in a signed DHCPv6 message that will be validated.

Enforcing it could be part of the server implementation/configuration,
though.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Oct 2014 20:03:42 +0000

Hi,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Wednesday, October 29, 2014 10:58 AM
> To: Templin, Fred L
> Cc: Sheng Jiang; Bernie Volz (volz); [email-masked]
> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014
> 
> > > This version has provided a certificate-based mechanism for the client to authenticated by the server. It is assuming the client has
> a
> > > certificate honored by the server.
> >

Thanks for this useful explanation.  In my scenario, clients can trust their servers
by leap-of-faith because there is another trust basis for assuring the Client that
the server is authorized to act as a server. However, the server needs some way
of knowing that clients that pass authentication are actually authorized to receive
the resources they are asking for.

Take for example a client C1 that provides a valid certificate but includes a DUID
corresponding to client C2 in a DHCPv6 PD Request. Will the server return an
IA_PD to client C1 that includes a prefix that is intended for client C2? That is
the scenario I need to defend against.

> Enforcing it could be part of the server implementation/configuration,

Enforce by linking the client's certificate to its DUID? Something else?

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Thu, 30 Oct 2014 09:53:26 -0700

At Wed, 29 Oct 2014 20:03:42 +0000,

> the scenario I need to defend against.

Again just in my understanding, the protocol described in the sedhcpv6
draft wouldn't be able to prevent it by itself.  I suspect it's a
matter of the server implementation/operation.  In practice, the
server should maintain some relationship between the certificate's
subject (i.e., that particular client, whether it's in the form of
DUID or of an FQDN or something else) and information (address,
prefix, etc) that the server would assign to the client; otherwise,
just validating the certificate wouldn't be much useful.  I believe
your goal can be achieved by using sedhcpv6 with this setup.

> Enforce by linking the client's certificate to its DUID? Something else?

Enforce by linking the client's certificate to *some ID* of the client
(which might be the DUID or something else).  See above.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Oct 2014 19:01:27 +0000

Hi,

> Sent: Thursday, October 30, 2014 9:53 AM
> To: Templin, Fred L
> Cc: [email-masked]; Bernie Volz (volz)

OK, that sounds good but could perhaps could use some concluding discussion
at the upcoming meeting. I have a bullet on this on my presentation charts.

Thanks - Fred