Re: [dhcwg] Open Issues for Secure DHCPv6

["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.

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?

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?)

Best Regards,
Lishan