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

[Ted Lemon <[e-mail]>]

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

On Wed, Jul 12, 2017 at 8:30 PM, Bernie Volz (volz) <[e-mail]> 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.
>
>
>
> And, yes, so it might be able to match up information obtained from other
> sources, such as Leasequery.
>
>
>
> -          Bernie
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Wednesday, July 12, 2017 8:25 PM
> *To:* Bernie Volz (volz) <[e-mail]>
> *Cc:* Templin, Fred L <[e-mail]>; [e-mail];
> [e-mail]
> *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) <[e-mail]>
> wrote:
>
> Ok, thanks for your use case. We'll hopefully get more.
>
>
>
> 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.
>
>
>
> 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 <[e-mail]>
> wrote:
>
> 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:[e-mail] <[e-mail]>]
> *Sent:* Wednesday, July 12, 2017 2:06 PM
> *To:* Templin, Fred L <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* RE: seDHCPv6 update and next steps ...
>
>
>
> 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:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, July 12, 2017 4:49 PM
> *To:* Bernie Volz (volz) <[e-mail]>; draft-ietf-dhc-sedhcpv6@tools.
> ietf.org; [e-mail]
> *Subject:* RE: seDHCPv6 update and next steps ...
>
>
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Bernie Volz (volz)
> *Sent:* Wednesday, July 12, 2017 1:30 PM
> *To:* [e-mail]; [e-mail]
> *Subject:* [dhcwg] seDHCPv6 update and next steps ...
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>