Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

[Francis Dupont <[e-mail]>]

 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

[e-mail]

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.