Subject: [dhcwg] seDHCPv6 update and next steps ...

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Jul 2017 20:30:20 +0000

Hi:

There has been some discussion (most recently off the dhcwg mailing list) about the sedhcpv6 draft.

Previously, as discussed on the dhcwg mailing list a while back, there are some issues with the current draft (including the encryption issue; the key can't be used to encrypt more data than the size of the key). And, while some of the co-authors have communicated recently, others have been quiet and it is not clear what the level of interest for each is in continuing. This work has sadly had a long road with several turns already.

The discussion raised the question as to what the goals of this work should be. Some feel that we need to step back and first develop a "requirements document" to clearly detail what the goals of a securing DHCPv6 should be (for example, was the fairly recent push to add encryption appropriate?).

Thus, Tomek and I feel that it would be worth having an interested group meet before the IETF-99 DHC WG session (which is on Wednesday, 7/19 afternoon) to discuss this so that we could formulate a strategy. If you have interest, let us know. We propose to meet on Sunday at 14:00 (CEST) in Chez Louis (Hackathon) room - we can find a table there, or look for another place. (If there is remote participation interest, let us know and we'll see what we might be able to accommodate.)

We may also have extra time in the DHC WG session to discuss in detail there, but it could be helpful to have one or more proposals and, if we get the slides out quickly, give people some time to think about it before the WG session.

-          Bernie and Tomek

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Jul 2017 20:48:34 +0000

Hi Bernie,

Unfortunately, my plane does not arrive until ~16:00 CEST on Sunday. But, if
this work is going back to first principles I would like to express an interest in
an authentication-only mode of operation (i.e., no encryption). It would
avoid a "double-encryption" when encryption is already provided by the
link layer between the client and server (or first-hop relay) and there are
already other securing mechanisms in place between relays and servers.

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 12, 2017 1:30 PM
To: [email-masked]; [email-masked]
Subject: [dhcwg] seDHCPv6 update and next steps ...

Hi:

-          Bernie and Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Jul 2017 21:06:11 +0000

Hi Fred:

Thanks for your interest.

Could you clarify what you mean by authentication-only? As I see if in terms of authentication there is:

1.       Authenticate the server to the client

2.       Authenticate the client to the server

3.       Or both

There are also various degrees of authentication - for example, TOFU (Trust on First Use) to trusted third party (and what that might impose on certificate distribution / validation).

And, if you have a specific use model in mind (for example, if this is for AERO), having a brief summary of this and the authentication requirements would be useful.

I'd also suggest that understanding why other techniques, such as 802.1X, would not be appropriate could provide added value in understanding the requirements.

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Wednesday, July 12, 2017 4:49 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: seDHCPv6 update and next steps ...

Hi Bernie,

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, July 12, 2017 1:30 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] seDHCPv6 update and next steps ...

Hi:

-          Bernie and Tomek

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Jul 2017 21:36:30 +0000

Hi Bernie,

My scenario is very simple. The client and server are connected to the same
link, and the link already supports link-layer security (e.g., IEEE 802.1X).

The client knows that it can trust the server because the server's address
is in a list of known server addresses for the link that cannot be subverted
by an adversary and there is no opportunity for source address spoofing.

The server knows that the client is authorized to connect to the link
(e.g., due to 802.1X) but the server does not know whether the client
is authorized to use the DUID it is claiming in its DHCPv6 messages.
For example, trusted client 'A' could use trusted client 'B's DUID to
steal client 'B's service - an "insider attack".

So, what is needed from seDHCPv6 is for the client to authenticate itself
to the server so that it cannot steal the services of another client. And,
since there may be a LDRA, the DHCPv6 parameters must be available
in-the-clear so that the LDRA can snoop any IA_NA/IA_PD assignments.

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Wednesday, July 12, 2017 2:06 PM
To: Templin, Fred L <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: seDHCPv6 update and next steps ...

Hi Fred:

3.       Or both

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Wednesday, July 12, 2017 4:49 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: seDHCPv6 update and next steps ...

Hi Bernie,

Thanks - Fred

Hi:

-          Bernie and Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Jul 2017 22:30:45 +0000

Ok, thanks for your use case. We'll hopefully get more.

And,

I think this can be solved in other ways, such as via the RAAN work. Though one issue with that is we need to figure out how to provide client details (i.e., client-id) that might be needed by relays.

- Bernie (from iPad)

On Jul 12, 2017, at 5:36 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bernie,

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Wednesday, July 12, 2017 2:06 PM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: seDHCPv6 update and next steps ...

Hi Fred:

3.       Or both

-          Bernie

Hi Bernie,

Thanks - Fred

Hi:

-          Bernie and Tomek

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Jul 2017 22:38:37 +0000

Hi Bernie,

See below:

Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Wednesday, July 12, 2017 3:31 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: seDHCPv6 update and next steps ...

And,

?    Right, but with authentication-only (i.e., when the DHCPv6 messages are

?    in-the-clear) RAAN options are unnecessary - at least for this use case.

- Bernie (from iPad)

Thanks - Fred

Hi Fred:

3.       Or both

-          Bernie

Hi Bernie,

Thanks - Fred

Hi:

-          Bernie and Tomek

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 20:25:21 -0400

You mean for leasequery?   We should probably scope that out.   It's not
clear to me that there's an overlap in the use cases, though.

On Wed, Jul 12, 2017 at 6:30 PM, Bernie Volz (volz) <[email-masked]> wrote:

> I think this can be solved in other ways, such as via the RAAN work.
> Though one issue with that is we need to figure out how to provide client
> details (i.e., client-id) that might be needed by relays.
>
> - Bernie (from iPad)
>
> On Jul 12, 2017, at 5:36 PM, Templin, Fred L <[email-masked]>
> wrote:
>
> Hi Bernie,
>
>
>
> The client knows that it can trust the server because the server’s address
>
> For example, trusted client ‘A’ could use trusted client ‘B’s DUID to
>
> steal client ‘B’s service – an “insider attack”.
>
>
>
> *From:* Bernie Volz (volz) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, July 12, 2017 2:06 PM
> *To:* Templin, Fred L <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* RE: seDHCPv6 update and next steps ...
>
>
>
> Hi Fred:
>
>
>
> There are also various degrees of authentication – for example, TOFU
> (Trust on First Use) to trusted third party (and what that might impose on
> certificate distribution / validation).
>
>
>
> And, if you have a specific use model in mind (for example, if this is for
> AERO), having a brief summary of this and the authentication requirements
> would be useful.
>
>
>
> I’d also suggest that understanding why other techniques, such as 802.1X,
> would not be appropriate could provide added value in understanding the
> requirements.
>
>
>
> -          Bernie
>
>
>
> *From:* Templin, Fred L [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, July 12, 2017 4:49 PM
> *To:* Bernie Volz (volz) <[email-masked]>; draft-ietf-dhc-sedhcpv6@tools.
> ietf.org; [email-masked]
> *Subject:* RE: seDHCPv6 update and next steps ...
>
>
>
> Hi Bernie,
>
>
>
> avoid a “double-encryption” when encryption is already provided by the
>
> *From:* dhcwg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Bernie Volz (volz)
> *Sent:* Wednesday, July 12, 2017 1:30 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* [dhcwg] seDHCPv6 update and next steps ...
>
>
>
> Hi:
>
>
>
> Previously, as discussed on the dhcwg mailing list a while back, there are
> some issues with the current draft (including the encryption issue; the key
> can’t be used to encrypt more data than the size of the key). And, while
> some of the co-authors have communicated recently, others have been quiet
> and it is not clear what the level of interest for each is in continuing.
> This work has sadly had a long road with several turns already.
>
>
>
> The discussion raised the question as to what the goals of this work
> should be. Some feel that we need to step back and first develop a
> “requirements document” to clearly detail what the goals of a securing
> DHCPv6 should be (for example, was the fairly recent push to add encryption
> appropriate?).
>
>
>
> Thus, Tomek and I feel that it would be worth having an interested group
> meet before the IETF-99 DHC WG session (which is on Wednesday, 7/19
> afternoon) to discuss this so that we could formulate a strategy. If you
> have interest, let us know. We propose to meet on Sunday at 14:00 (CEST) in
> Chez Louis (Hackathon) room – we can find a table there, or look for
> another place. (If there is remote participation interest, let us know and
> we’ll see what we might be able to accommodate.)
>
>
>
> We may also have extra time in the DHC WG session to discuss in detail
> there, but it could be helpful to have one or more proposals and, if we get
> the slides out quickly, give people some time to think about it before the
> WG session.
>
>
>
> -          Bernie and Tomek
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Jul 2017 00:30:55 +0000

I mean for something to identify who made the request for the address or delegated prefix. Otherwise, the relay may not have much other than the link layer address (if it extracts it from the original client message, which would kind of nasty since it requires matching up the reply with the request). It could always encode something in the interface-identifier or some other option.

And, yes, so it might be able to match up information obtained from other sources, such as Leasequery.

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, July 12, 2017 8:25 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Templin, Fred L <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [dhcwg] seDHCPv6 update and next steps ...

You mean for leasequery?   We should probably scope that out.   It's not clear to me that there's an overlap in the use cases, though.

On Wed, Jul 12, 2017 at 6:30 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Ok, thanks for your use case. We'll hopefully get more.

And,

- Bernie (from iPad)

Thanks - Fred

Hi Fred:

3.       Or both

There are also various degrees of authentication – for example, TOFU (Trust on First Use) to trusted third party (and what that might impose on certificate distribution / validation).

I’d also suggest that understanding why other techniques, such as 802.1X, would not be appropriate could provide added value in understanding the requirements.

-          Bernie

Hi Bernie,

Thanks - Fred

Hi:

Previously, as discussed on the dhcwg mailing list a while back, there are some issues with the current draft (including the encryption issue; the key can’t be used to encrypt more data than the size of the key). And, while some of the co-authors have communicated recently, others have been quiet and it is not clear what the level of interest for each is in continuing. This work has sadly had a long road with several turns already.

The discussion raised the question as to what the goals of this work should be. Some feel that we need to step back and first develop a “requirements document” to clearly detail what the goals of a securing DHCPv6 should be (for example, was the fairly recent push to add encryption appropriate?).

Thus, Tomek and I feel that it would be worth having an interested group meet before the IETF-99 DHC WG session (which is on Wednesday, 7/19 afternoon) to discuss this so that we could formulate a strategy. If you have interest, let us know. We propose to meet on Sunday at 14:00 (CEST) in Chez Louis (Hackathon) room – we can find a table there, or look for another place. (If there is remote participation interest, let us know and we’ll see what we might be able to accommodate.)

-          Bernie and Tomek

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 20:59:47 -0400

The relay-reply should contain the client link-layer address.

On Wed, Jul 12, 2017 at 8:30 PM, Bernie Volz (volz) <[email-masked]> wrote:

> I mean for something to identify who made the request for the address or
> delegated prefix. Otherwise, the relay may not have much other than the
> link layer address (if it extracts it from the original client message,
> which would kind of nasty since it requires matching up the reply with the
> request). It could always encode something in the interface-identifier or
> some other option.
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Wednesday, July 12, 2017 8:25 PM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* Templin, Fred L <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [dhcwg] seDHCPv6 update and next steps ...
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Jul 2017 02:04:00 +0000

Yes, you are correct that if relay includes link-layer option and specifies ERO option for it to be returned, it would be there in Relay-Reply. But there may be reasons for relay to "need" Client-ID.

- Bernie (from iPad)

On Jul 12, 2017, at 9:00 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 12, 2017 at 8:30 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I mean for something to identify who made the request for the address or delegated prefix. Otherwise, the relay may not have much other than the link layer address (if it extracts it from the original client message, which would kind of nasty since it requires matching up the reply with the request). It could always encode something in the interface-identifier or some other option.

-          Bernie

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 12, 2017 8:25 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] seDHCPv6 update and next steps ...

And,

- Bernie (from iPad)

Thanks - Fred

Hi Fred:

3.       Or both

-          Bernie

Hi Bernie,

Thanks - Fred

Hi:

-          Bernie and Tomek