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

[Lishan Li <[e-mail]>]

In the before, Bernie proposed the same question. And we made the following
consensus: The Encrypted-Query and Encrypted-Response message use the same
transaction-id with the before Information-request and Reply message.

2016-11-16 2:01 GMT+08:00 神明達哉 <[e-mail]>:

> At Tue, 15 Nov 2016 15:27:46 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > > BTW this makes me notice one related issue: it doesn't seem to be
> > > possible for a server to identify the private key to decrypt the
> > > message contained in an Encrypted-message Option contained in the
> > > Encrypted-Query message unless it tries all private keys it might be
> > > used.
> > >
> > [LS]: The private key which is corresponding to the public key for
> > encryption
> > algorithm is used for decryption. After sending the Reply message, the
> > message
> > transaction-id is used as the identifier of the private key for
> decryption.
>
> Can you be more specific about this?  For example, assume the client
> tries to send a Solicit message encrypting it with a server's public
> key (and assume the server supports multiple algorithms and multiple
> key pairs).  The encrypted solicit message that the server receives
> would look like this:
>
> msg-type: Encrypted-Query
> transaction-id: some random number the client generates on building
>   the Encrypted-Query (per Section 15.1 of RFC3315 or 16.1 of
>   rfc3315bis-06).
>
[LS]: So, in this sample, the transaction-id is not some random number, but
the same content with the transaction-id in Information-request and reply
message.

> options:
>   Encrypted-message option:
>     option-code: OPTION_ENCRYPTED_MSG
>     option-len: set appropriately
>     encrypted DHCPv6 message: opaque data to be decrypted
>
> Do you mean the server can use the transaction-id included in the
> Encrypted-Query message to identify the algorithm and the private key
> to decrypt "encrypted DHCPv6 message"?  If so, specifically how?  As
> noted above the transaction-id value is chosen by the client at the
> time of generating this message and the server cannot know or
> (easily) predict it in advance.
>

Best Regards,
Lishan