Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Jun 2017 00:10:46 +0200

In your previous mail you wrote:

>  I guess there's at least one fundamental open issue to be resolved
>  before even trying to implement it:
>  https://www.ietf.org/mail-archive/web/dhcwg/current/msg18116.html

=> it is more than a fundamental issue: the idea to use RSA encryption
is simply a deadly bad one...

Regards

[email-masked]

PS: IMHO the current SeDHCPv6 protocol has no chance to go somewhere.
Perhaps we should drop it and restart from the beginning about
address assignment security, for instance using opportunistic DNSSEC
with a client embedded first relay? At least it does not need to
develop a new protocol...

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Jun 2017 11:10:52 -0700

At Tue, 06 Jun 2017 00:10:46 +0200,

> is simply a deadly bad one...

Could you explain it in more detail?  Is it just about the particular
choice of algorithm (RSA), or is it about the use of asymmetric
(public-key)-based encryption to encrypt DHCPv6 messages in the first
place?  And why is it bad?

If it's the former, (depending on the reason) we might choose a better
algorithm as the default/mandatory.

If it's the latter, we could revise the protocol so it will first
negotiate a symmetric session key using public-key based encryption
and use the session key for subsequent DHCPv6 message exchanges.  That
will be a quite substantial change from the current spec, but I guess
it's not impossible.

Or...

> PS: IMHO the current SeDHCPv6 protocol has no chance to go somewhere.

perhaps so.  But it would help if you could explain why you think so.

> develop a new protocol...

I don't know what "opportunistic DNSSEC with a client embedded
first relay" means, but as we're sort of getting stuck I see even a
drop-and-restart might be an option.

--
JINMEI, Tatuya

On Mon, Jun 5, 2017 at 3:10 PM, Francis Dupont
<[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 7 Jun 2017 20:43:05 +0200

> drop-and-restart might be an option.
This work has been in development for almost a decade. This particular
approach started in 2013. Let's not restart the work until we exhaust
all other possible alternatives.

How about the proposal Bernie made here?
https://mailarchive.ietf.org/arch/msg/dhcwg/c2bB8KdbGgsZShHtnyUgKwELa-w

Another possible approach to the problem mentioned in off-line
discussion was DTLS 1.2 (RFC6347), but Francis pointed out that it's
quite exchange heavy, compared to DHCP, which takes 1 or 2 exchanges.
Going to 3 or perhaps 4 exchanges is ok in my opinion, but if the
proposal requires more than that, we would see a lot of raised eyebrows.

Tomek

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Jun 2017 20:35:14 +0200

>  place?  And why is it bad?

=> in fact it is both because RSA is the only asymmetric algorithm
which provides an accepted encryption feature.
Now why it is bad (other than RSA has no future)? Just because it was
designed to protect something short as a key for a symmetric encryption
and *not* for a message with an unbound length.

>  algorithm as the default/mandatory.

=> as I explained I am afraid there is no alternative which went further
than conference papers...

>  will be a quite substantial change from the current spec, but I guess

=> if you go to a key agreement phase followed by symmetrical encryption
I am afraid you are reinvented something which already exists so why
not investigate current possible solutions and try to use them directly?

>  > address assignment security, for instance using opportunistic DNSSEC

=> oops? I wrote DNSSEC? I wanted to mean IPsec.

Regards

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 15:06:09 -0400

Bernie addressed the key issue.   I think Bernie's suggestion is fine, but sounds a lot like DTLS, which begs the question, why not just use DTLS?   And Francis, much as we might wish it otherwise, IPsec isn't actually a practical option as far as I can tell.  I have no idea how to use it for anything other than setting up a VPN on, e.g., Mac OS X.   If you have a resource to point to on that, I'd be interested to hear about it.

> On Jun 7, 2017, at 2:35 PM, Francis Dupont <[email-masked]> wrote:
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Jun 2017 21:08:47 +0200

>  all other possible alternatives.

=> I know it was pretty old (I was its gen-art reviewer and did thsi
review the 20130220 according to my message to gen-art...).
At this time it was not ready ("Summary: Not Ready" cut & paste
from this message) but putting some ideas from SEND which solved
a similar problem with same hard constraints made it something
reasonable.

IMHO the real issue comes from the switch from an authentication
mechanism to unauthenticated encryption. So if the name is the same
in fact it is a very different protocol, and of course to twist it
to fulfill a different goal did not work well...

>  https://mailarchive.ietf.org/arch/msg/dhcwg/c2bB8KdbGgsZShHtnyUgKwELa-w

=> IMHO anything using RSA encryption is dead.

>  proposal requires more than that, we would see a lot of raised eyebrows.

=> without RSA encryption only solutions using state and multiple
exchanges are available so instead to transform DHCP into something
different I suggest to do the opposite: start from a security protocol
and add some DHCP features into it. In the case of opportunistic
IPsec/IKE it could be more DHCP features or if we are lucky some
profiles...

Regards

PS: References are:
 RFC 4322 "Opportunistic Encryption using the Internet Key Exchange (IKE)"
 RFC 5996 "Internet Key Exchange Protocol Version 2 (IKEv2)"
 RFC 5739 "IPv6 Configuration in Internet Key Exchange Protocol
           Version 2 (IKEv2)"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 15:26:30 -0400

On Jun 7, 2017, at 3:08 PM, Francis Dupont <[email-masked]> wrote:
> In the case of opportunistic

Suppose I want to code up a DHCP client that uses IPsec on the Mac.   What API do I use?   Since encryption is now being done in the network stack, I don't have the option of not using an API.   AFAIK, no such API exists.   I'm choosing the Mac specifically because I haven't been able to find documentation for one there—I know I can do it on Linux.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 15:34:12 -0400

> Suppose I want to code up a DHCP client that uses IPsec on the Mac.   What API do I use?   Since encryption is now being done in the network stack, I don't have the option of not using an API.   AF…

Nevermind, I think I found it.

In order for this to work, I think the initial DHCPINFORM would need to include a public key, and the response would include a generated shared secret signed in the server's private key and encrypted using the client's public key.   It would also include the server's public key.   This would allow us to establish keying for the IPsec encryption.

However, I don't think this would actually work, because now we have an encrypted blob for the relay agent.   What does it do with it?

Once we have established a shared private key, I think that we would want to just use Bernie's model. Either that, or we use DTLS and wrap it in the same sort of message exchange, and the encrypted blobs are shipped around in DHCP messages pretty much the same way that we're doing in the current protocol.

But I don't have time to think about this right now... :)

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Jun 2017 21:29:06 +0200

In your previous mail you wrote:

>  Bernie addressed the key issue.   I think Bernie's suggestion is fine, but s
>  ounds a lot like DTLS, which begs the question, why not just use DTLS?   And
>   Francis, much as we might wish it otherwise, IPsec isn't actually a practic
>  al option as far as I can tell.  I have no idea how to use it for anything o
>  ther than setting up a VPN on, e.g., Mac OS X.   If you have a resource to p
>  oint to on that, I'd be interested to hear about it.

=> even if IPsec is essentially used for VPN it provides a transport mode
and not only a tunnel mode...
Now the real question is about the fact IPsec is a kernel feature, not
something you add in applications over the transport API provided by
the kernel. The world is divided between people who think it is an
advantage and people who think it is *the* problem.
Obviously I am in the first part, you in the second. Now I did a lot of
kernel programming (including IPsec kernel programming) so I am very
far to be neutral...

Regards

PS: macOS has IPsec/IKE support. At the time I worked on IPsec it used
the same code than me, today I don't know.
To configure it:
 - open System Prefences
 - open Network
 - add a new interface (or service)
 - select VPN (there was a way to use transport mode but as far as I
  remember not very direct)
 - select IKEv2 VPN type
 - enter a service name
etc
BTW I am typing this on a macOS MacBook Air...

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Jun 2017 21:50:20 +0200

In your previous mail you wrote:

>  Suppose I want to code up a DHCP client that uses IPsec on the Mac.   =
>  What API do I use?   Since encryption is now being done in the network =
>  stack, I don't have the option of not using an API.   AFAIK, no such API =
>  exists.   I'm choosing the Mac specifically because I haven't been able =
>  to find documentation for one there=E2=80=94I know I can do it on Linux.

=> PF_KEY (/usr/include/net/pfkeyv2.h). You are making some friends
(and I am afraid some are in this list) not fully happy (:-)...

Regards

PS: the real issue is more how to configure IKEv2 on macOS. As IPsec
is in the kernel applications have no API to use to get IPsec protection
for their traffic but of course this (insert color here) magic does not
come from nowhere, and again only common VPN senarios are managed
by system tools. This does not mean it is impossible to do what one
wants but it is likely not easy so to summary the color could become dark.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 17:19:15 -0400

On Jun 7, 2017, at 3:29 PM, Francis Dupont <[email-masked]> wrote:
> The world is divided between people who think it is an

Actually, the two groups of people into which the world is divided are those who think the world is divided into two groups of people, and those who do not.   :)

The point of this joke is that actually I don't have any problem with encryption being done in the kernel, but I don't see how to make it work for this use case, because we don't have end-to-end communication with the server.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Jun 2017 23:25:17 +0200

In your previous mail you wrote:

>  In order for this to work, I think the initial DHCPINFORM would need to =
>  include a public key, and the response would include a generated shared =
>  secret signed in the server's private key and encrypted using the =
>  client's public key.   It would also include the server's public key.   =

=> you are reinventing IKE or DTLS with 2 problems:
 - it is better to use a key agreement protocol than to leave one
  side to decide the key.
 - public keys or certificates are not very useful because the only
  thing the client can do is to check that things are signed by the
  owner, not that the server is authorized. BTW there are 2 possible
  solutions, one used by SEND is to communicate a certification chain,
  another is to rely on a posteriori validation (of course you can
  just give up on the authentication arguing that only encryption matters).
I am afraid you are replacing the address bootstrap mess by the security
bootstrap mess but there is a security protocol which includes address
bootstrapping, it is IKEv2 so IMHO we should try it as on the paper
it has all we need.

>  This would allow us to establish keying for the IPsec encryption.

=> too late: either IPsec bootstrapped and your traffic is protected,
or IPsec failed to bootstrap and your traffic is dropped.

>  However, I don't think this would actually work, because now we have an =
>  encrypted blob for the relay agent.   What does it do with it?

=> if it is protected by IPsec to the server the relay don't see it.
Note the relay is supposed to encapsulate/decapsulate *only* messages
between clients and the server (note I wrote "supposed").
Another thing we can do is to embed a relay in the client.
BTW it is what I proposed (and what was adopted by Ralph) for
IPv6 router mobility which had an IPsec vs DHCPv6 issue.

>  Once we have established a shared private key, I think that we would =
>  want to just use Bernie's model. Either that, or we use DTLS and wrap it =
>  in the same sort of message exchange, and the encrypted blobs are =
>  shipped around in DHCP messages pretty much the same way that we're =
>  doing in the current protocol.

=> if you use DTLS it will be something different than DHCPv6 over UDP
(it is not true for IPsec which is transparent for applications).

>  But I don't have time to think about this right now... :)

=> yes, we should postpone extensions to the DHCP protocol until
we are sure there is no simpler solution (BTW we cited IPsec and DTLS,
is there another candidate?)

Regards

PS: my macOS 10.12 sources still have a racoon code so setkey should
be able to manipulate the Security Policy Database. Note this is
ISAKMP/IKEv1 so very old (I worked on racoon2 IKEv2 more than 10 years
ago). I am trying to identify the macOS IKEv2 implementatio, it seems
it is loaded as a network extension but sources (and documentation?)
are not available.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 17:49:25 -0400

> bootstrapping, it is IKEv2 so IMHO we should try it as on the paper

Pretty much everything you said here assumes that the DHCP client has a routable address.   It's the fact that it doesn't that makes this hard.

Also, a key agreement protocol is probably not a good idea if we care about privacy.

And we already talked about how to do TOFU, and I think that applies just as well here as to the current spec.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Jun 2017 23:58:11 +0200

In your previous mail you wrote:

>  The point of this joke is that actually I don't have any problem with =
>  encryption being done in the kernel, but I don't see how to make it work =
>  for this use case, because we don't have end-to-end communication with =
>  the server.

=> the theory of IPsec operations is very simple: you have two databases:
 - the Security Association DataBase
 - the Security Policy Database.
When you have a packet you see in the SPD what to do. If the policy is
to do some IPsec processing on the packet you look for the parameters
in the SADB and if there is no SA when there should be one then you ask
IKE to create one (in fact a pair).
So the configuration consists into populating the SPD (e.g. by setkey)
and to say to IKE what to do (define peers, credentials, a zillion of
options).

Regards

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 18:26:30 -0400

> and to say to IKE what to do (define peers, credentials, a zillion of

Right.  That's what I mean.   The encrypted payload is going to the host where the relay agent is running, which doesn't have the key to decrypt the payload.   And so the packet is never delivered to the relay agent, and hence never forwarded to the DHCP server.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Jun 2017 01:02:33 +0200

In your previous mail you wrote:

>  On Jun 7, 2017, at 5:25 PM, Francis Dupont <[email-masked]> =
>  wrote:
>  > I am afraid you are replacing the address bootstrap mess by the =
>  security
>  Pretty much everything you said here assumes that the DHCP client has a =
>  routable address.

=> requiring a routable address is what I called the "address bootstrap" mess.
Note we don't need one, just to be able to send a packet to the server
and if possible not using multicast (multicast is where the embedded
relay can help). Note that IKE or DTLS works over link-local addresses
so you can protect directly client-relay.

   It's the fact that it doesn't that makes this hard.

=> yes, the info-request / stateless case is easier.

>  Also, a key agreement protocol is probably not a good idea if we care =
>  about privacy.

=> by key agreement I mean a Diffie-Hellman variant (more ECDH or X25519).
Cf Russ Housley's message.
I can't see what is the impact on privacy: it is just a parameter saying
which variant, and a public random/opaque value which can be changed for
each init (DISCOVER/SOLICIT) message.

>  And we already talked about how to do TOFU, and I think that applies =
>  just as well here as to the current spec.

=> TOFU is a server policy.

Another problem with all IKE, DTLS and reinvented similar mechanisms
is that it is not possible to protect both identities against active
attacks (cf the SIGMA conf paper) so if we want mutual authentication
we have to choose protocols which protect the client/initiator identity
(for instance to put the client public key in clear text in the first
message is not good even against passive attacks).

Regards

PS: as candidates with have  HIP, and also some EAP/PANA extensions
to do encryption (IMHO more to get ideas than to use).
PPS: before going further it seems we should first agree about what
we want...

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Jun 2017 01:22:39 +0200

In your previous mail you wrote:

>  Right.  That's what I mean.   The encrypted payload is going to the host =
>  where the relay agent is running, which doesn't have the key to decrypt =
>  the payload.   And so the packet is never delivered to the relay agent, =
>  and hence never forwarded to the DHCP server.

=> I don't understand your argument: if you send an encrypted packet
to a box without the proper security association of course it does not
work. This has nothing to do with IPsec and will happen with DTLS too
or anything secure protocol which carries DHCP messages.

As I said we are squeezed between the address bootstrap mess (this problem)
and the security bootstrap mess (the problem that current secure DHCPv6
tries and IMHO fails to solve).
So I strongly suggest to write what we want and to reduce problems to
things we know to do reusing as most as possible already existing protocols.
On the paper hop-by-hop IPsec works and for the privacy only we have
the opportunistic IPsec idea so it seems a good point to start
(and as it is transparent for DHCP is clearly out of the scope of
both the DHCP WG and this list, argh! :-).

Thanks

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 19:45:34 -0400

> or anything secure protocol which carries DHCP messages.

The relay agent can forward an encrypted payload that it receives.   It can't forward a cleartext payload from an encrypted packet it couldn't decode.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Jun 2017 02:05:00 +0200

In your previous mail you wrote:

>  The relay agent can forward an encrypted payload that it receives.   It =
>  can't forward a cleartext payload from an encrypted packet it couldn't =
>  decode.

=> we agree: a relay agent can handle an encrypted payload if this payload
is inside a DHCP message, and can't handle it if a DHCP message is in this
payload.
So if we want to support the intermediate relay case either the DHCP
protocol is modified, or the client and the first relay agent are end
points of a security association.
Note this could disqualify DTLS & co as it is unlikely we accept
to have to update relay agents.

Regards