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

[神明達哉 <[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).
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.

--
JINMEI, Tatuya