Re: [dhcwg] Open Issues for Secure DHCPv6

[Lishan Li <[e-mail]>]

Dear Bernie,

The Encrypted-Query and Encrypted-Response messages are restricted to only
these options. So based on the consideration, we consider the fixed fields
for the encrypted message. However, the server identifier option is not
must contained. And the length of the encrypted-message option is not
fixed. So I think that a series of options may be better.
If the encrypted messages contain a series of options and another option
appears, I think the encrypted message must be dropped.

Thanks,
Lishan

2016-05-08 19:34 GMT+08:00 Bernie Volz (volz) <[e-mail]>:

> Lishan:
>
> If that's the case (haven't yet read lastest sedhcpv6 draft) ...
>
> So if you restrict these messages to have only these options (and at most
> a single instance - or receiver only looks at first instance) there is no
> attack vector? If another option appears, drop the message?
>
> - Bernie (from iPad)
>
> On May 8, 2016, at 6:16 AM, Lishan Li <[e-mail]> wrote:
>
> Dear Bernie,
>
> The options that may be contained in the Encrypted-Query and
> Encrypted-Response messages are only two options: server identifier option
> and encrypted-message option. The server identifier option is not must
> contained in the Encrypted-Query message until the server is selected. Only
> the encrypted-message option must be contained. In addition, the
> encrypted-message option does not have the fixed length.
> So, it is better to contain a series of options, not flexed fields.
> Looking forward to your further guidance.
>
> Best Regards,
> Lishan
>
> 2016-05-07 23:25 GMT+08:00 Bernie Volz (volz) <[e-mail]>:
>
>> Hi:
>>
>>
>>
>> Regarding 6. The format of Encrypted-Query and Encrypted-Response
>> messages.
>>
>>
>>
>> Please provide details on how this message would be formatted.
>>
>>
>>
>> Given that with 4-byte option headers (assuming 0 length), a fairly large
>> packet (such as 65K) could have about 16K options in it so would take that
>> many iterations to process and discard. For more reasonable length packets,
>> this probably is much less of an issue (100s of iterations).
>>
>>
>>
>> While we generally avoid option ordering, perhaps an alternative to a
>> fixed header (especially if some of the fields aren’t fixed length) is to
>> specify that those options “required” for validation are “first”. That
>> would make it very easy for a server (or client) to quickly discard a
>> packet when it cannot be properly “validated”. This might provide the
>> benefit you’re looking for but avoid the need for the fixed length header
>> (especially if it isn’t “fixed” length).
>>
>>
>>
>> -          Bernie
>>
>>
>>
>>
>>
>> *From:* Lishan Li [mailto:[e-mail]]
>> *Sent:* Saturday, May 07, 2016 11:05 AM
>> *To:* Bernie Volz (volz) <[e-mail]>
>> *Cc:* dhcwg <[e-mail]>
>> *Subject:* Re: [dhcwg] Open Issues for Secure DHCPv6
>>
>>
>>
>> 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
>>
>
>