Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

[Lishan Li <[e-mail]>]

Another problem is that: how the client identify which public/private key
pair is used for DHCPv6 configuration process when the client have multiple
key pairs. In most cases, the client communicate with only one DHCPv6
server. Then, the client only uses one public/private key pair for the
DHCPv6 configuration process. So there is no need to define the mechanism.
Could you please check whether my understanding correct?

Best Regards,
Lishan

2016-11-25 14:29 GMT+08:00 Lishan Li <[e-mail]>:

> 2016-11-24 3:39 GMT+08:00 神明達哉 <[e-mail]>:
>
>> At Wed, 23 Nov 2016 16:28:54 +0800,
>> Lishan Li <[e-mail]> wrote:
>>
>> > > - Introduce a new DHCPv6 option named "encryption key tag option".
>> > >   Its value is calculated from public key data (it's essentially a
>> > >   fingerprint of a specific public key).
>> > > - Encryption Query messages MUST include the encryption key tag
>> > >   option.  The option data MUST be calculated for the public key that
>> > >   the client uses to encrypt the encapsulated DHCPv6 message.
>> > >
>> > [LS]: I agreed. I have two questions:
>> > 1. How does the client calculate the key tag? Maybe the hash
>> > function can be used for the calculation.
>>
>> Anything that would generate reasonably different values for different
>> keys (but it doesn't have to be guaranteed) is fine.  A simple
>> "checksum" like the RRSIG key tag would probably suffice; using a
>> commonly known modern hash is also fine.
>>
> [LS]: So it is mostly a implementation problem and don't need to specify
> it. Because for the algorithm agility, we defines the algorithm negotiation
> mechanism between the client and server. So I the key tag generation
> algorithm may also need negotiation mechanism. And then, the generation
> algorithm should also be defined in our document.
> Looking forward to your guidance.
>
> > 2. For the first received Encrypted-Query message, how does the
>> > server identifies the corresponding private key through the acknowledged
>> > key tag?
>> > one way is that: The server tries all the possible private key
>> > and record the relation of key tag and the corresponding private key.
>> > Another method is that: The server calculates the key tags of all the
>> > private key and then finds the corresponding private key.
>> > Looking forward to your further guidance.
>>
>> IMO this can be left to implementations.  But I expect most server
>> implementations will calculate the tag value when it generates a key
>> pair and maintain it with the key pair.  Note that if the server
>> implementator and administrator don't care about the efficiency it
>> could even calculate the tag value for its all public keys and compare
>> it to the value specified in the "encryption key tag option".  Or it
>> could even skip using the key tag and try all possible keys.  It's
>> inefficient but will still work.
>>
> [LS]: Thanks a lot for your explanation. So we don't need to specify
> this implementation problem in our document.
>
> Best Regards,
> Lishan
>