Re: [dhcwg] Open Issues for Secure DHCPv6

[Lishan Li <[e-mail]>]

Dear Bernie,

Thanks a lot for your nice reply. Please see in line.

Best Regards,
Lishan

2016-04-28 21:48 GMT+08:00 Bernie Volz (volz) <[e-mail]>:

> Hi:
>
>
>
> A few comments below (BV>). For those questions I did not have a comment
> on, it means I’m not yet sure what to say.
>
>
>
> -          Bernie
>
>
>
> *From:* dhcwg [mailto:[e-mail]] *On Behalf Of *Lishan Li
> *Sent:* Tuesday, April 26, 2016 8:15 AM
> *To:* dhcwg <[e-mail]>
> *Subject:* [dhcwg] Open Issues for Secure DHCPv6
>
>
>
> Dear All,
>
>
>
> After the discussion with Ted and Jinmei, there are still some open
> issues. Regarding these open issues, could you please give us you
> suggestions? Looking forward to your guidance! The following are the
> current open issues:
>
>
>
> 1. A single DHCPv6 server selection for authentication at the beginning.
>
> If the two servers share one common certificate with the same public key,
> then the client should be able to send an encrypted request to both
> servers, and both the servers can decrypt the encrypted request and letting
> client select one of them in a compatible way to the original DHCPv6.
>
> So in this way, there is no need to contain the Server Identifier option
> in the Encrypted-Query message. The disadvantage is that the extra
> decryption cost is caused for the DHCPv6 server not for it.
>
>
>
> BV> How about adding the server-identifier option when it is in the client
> message (i.e. Request, Renew, Decline, Release). That way, once a server is
> selected the other servers can ignore without needing to decrypt? That
> reduces the load a bit.
>
[LS]: Thanks for your valuable suggestion.  In this way, only after server
selection process, the server identifier option is contained to avoid the
extra decryption for the servers not for it.

>
>
2. Regarding timestamp, what about a strictly-increasing serial number
> (with rollover)?
>
> The advantage of a strictly increasing number is that the server can just
> discard messages from the client with lower numbers, and the client can do
> the same.  The disadvantage is that the strictly-increasing number has to
> be committed to stable storage on the client.
>
>
>
> BV> This seems a bit tricky. What happens if the stable storage is lost? A
> time based value (when possible – i.e., client has time) seems like a
> better option to me? For clients that don’t have the current time (i.e.,
> need DHCP to get the time), perhaps the timestamp is optional to
> accommodate them – this does mean there is the replay risk (at least until
> a time is available). I prefer we use existing techniques for this and I
> think they are generally time based?
>
[LS]: Generally, the timestamp is used to defend against replay attack. I
also prefer the existing techniques for this.

>
>
> 3. For the DHCPv6 client, how about a bare key not a certificate?
>
> If the client uses certificate for authentication. The client has to
> generate a key and then submit it to a certificate authority to be signed.
> It would make sense for two different companies to trust all certs signed
> by the same authority. For the client which is no longer authorized, they
> still have a key signed by the authority.   How do we stop that one client
> from authenticating? The answer is that we have to have a record of every
> client that is authorized to use the network.
>
>
>
> There are two ways to do client authentication: first, we can have the
> certificate authority remember all of the clients, and maintain a
> certificate revocation list (CRL) for clients whose certificates should no
> longer grant access to the network. Second, we can simply keep a list of
> all the client keys that are granted access to the network, and the DHCP
> server can check that list before granting access.
>
>
>
> The first one is more easy, so we think a bare key is enough not a
> certificate.
>
>
>
> 4. Whether we should mention opportunistic security in secure DHCPv6?
>
>
>
> 5. For the clients which has multiple certs, whether the transaction-id
> can work as the identifier of the client's public key for encryption, and
> server's  private key for decryption?
>
>
>
> BV> I’m not sure I understand this one.
>
>
>
> 6. The format of Encrypted-Query and Encrypted-Response messages.
>
> For the encrypted-query and encrypted-response messages, in the current
> version, the payload is a series of options, which may cause unnecessary
> attack. So according to Ted's suggestion, It is better that the payload is
> encrypted message with some fixed field. But DHCPv6 message's format are a
> series of options. If the encrypted-query and encrypted-response use the
> above format, are they still DHCPv6 messages?
>
>
>
> BV> I really prefer we keep it as a series of options. I don’t see that
> fixed fields help anything (especially if fields are variable length, why
> are they any easier to parse than options?). Options are easy enough to
> parse.
>
>
>
> I don’t see this as “are these DHCPv6 messages” or not argument – the
> Relay-Forw/Relay-Reply messages use a combination of fixed fields and
> options and we consider these as DHCPv6 messages.
>
>
>
> Perhaps if you can provide an example of how these messages would be
> formatted with the fixed fields, we could better evaluate as to whether
> this may make sense or not. (For example, perhaps you want to add some
> “identifier” into the messages to address issue #5 above?)
>
[LS]: If the encrypted message contains a series of options, then a client
may send additional options and a server may also do it. So this way may
create an unnecessary attack surface.
Compared with a series of options, I think fixed fields may be better.

Best Regards,
Lishan