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

[Lishan Li <[e-mail]>]

Dear Ted, Jinmei,

Thanks a lot for your guidance and help to complete the draft. I have
summarized the discussion content. Looking forward to your further guidance.

1. Algorithm negotiation method
Before version:
Through the Reply message, the server informs the client of the encryption,
signature, hash algorithms list; And then the client selects one
encryption,
signature, hash algorithm from the algorithms list for the future
communication.

The disadvantage:
The Reply message contains the algorithms list. So, the Reply message
contains multiple certificate options, signature options. For different
encryption algorithms, the certificate is different. And for the different
hash and signature algorithms, the signature is also different.

So, we made the following update:
+-------------------+                           +--------------------+
|DHCPv6 Client|                            |DHCPv6 Server|
+-------------------+                           +--------------------+
      |            Information-request           |

      |-------------------------------------------->|
      |             Algorithm option               |
      |           Option Request option       |
      |                                                     |
      |                    Reply                        |
      |<-------------------------------------------|
      |             Certificate option              |
      |             Signature option               |
      |          Increasing-number option   |
      |         Server Identifier option         |

(1) Define a new option: Algorithm option which contains the encryption,
signature, hash algorithms list.
Firstly, the client informs the server of the algorithms lists, and then
the server selects the algorithms from the lists. In this way, just only
one certificate, signature is contained.
(2) Delete the AlgorithmNotSupported error status code;
The algorithm option must contain the mandatory algorithms, so there is
no case that the server does not support the informed algorithms.


2. For server: The Identifier of the private key for decryption
Before version:
The server may have multiple public/private key pairs for multiple clients.
The transaction ID is used as the identifier of the private key for
decryption.
Firstly, the server informs the client of the certificate in the Reply
message and record the relationship of the key pair and the transaction ID.

The disadvantage:
The Encrypted-Query and Encrypted-Response messages must use the same
transaction-id of the Information-request and Reply message. And the
multiple clients may be using the same transaction-id.

So, we made the following update:
Add the Encryption Key Tag option to identify the used public/private
key pair. The Encrypted-Query message contains the Encryption Key Tag
option. The Encryption Key Tag option is calculated by the public key,
as the fingerprint of the public key.
For the calculation method, Jinmei thinks that it should be defined in
our document. In this way, the server can first calculate all the
key tag of the key pair locally. And then the server compares the
received key tag with it to find the corresponding private key for
decryption. In this way, the calculation method is also needed to
complete.
And my opinion is that: For the first Encrypted-Query
message, the server can try all the possible private keys and then
establishes the relationship of the Key Tag and the key pair.

3. For client: The identifier of the private key for decryption
Before version: Not Define the identifier of the private key;

Lishan's option: The client only uses one public/private key pair
with the DHCPv6 server. So there is no need to define a new
identifier;
Jinmei's opinion: This is based on the fact that: The
client only communicates with only one DHCPv6 server for configuration.
And there is no such restriction in the base protocol(RFC 3315 and bis)

Update: Add the description that: During the DHCPv6 configuration process,
the client MUST only use one certificate to establish the encrypted
communicate with the DHCPv6 server.

4. error status code
Before version: 1. If the server receives the solicit message without
the certificate option, the server sends the encrypted UnspecFail
error status code to the client.
2. If the server receives the Encrypted-Query message and decryption
fails, then sends the encrypted DecryptionFail error status code to
the client.

Issue: For the above two cases, the server cannot know the public
key of the client, there is no way to send the encrypted Reply
message to the client.

Update: The server just drops the message without sending the
error status code to them.


Best Regards,
Lishan

2016-12-02 21:55 GMT+08:00 Ted Lemon <[e-mail]>:

> Can I ask, where are you guys on this?   There's been so much
> discussion that I've lost the thread.   Is anybody producing a summary
> of issues?
>
> On Fri, Dec 2, 2016 at 1:34 AM, Lishan Li <[e-mail]> wrote:
> > 2016-12-02 3:44 GMT+08:00 神明達哉 <[e-mail]>:
> >>
> >> At Thu, 1 Dec 2016 19:46:06 +0800,
> >> Lishan Li <[e-mail]> wrote:
> >>
> >> > > This didn't answer my question.  Could you first answer the
> question?
> >> > > If there's no such restriction in the base protocol, we cannot
> assume
> >> > > it and can't assume it in designing sedhcpv6.
> >> > >
> >> > [LS]: I just think that it is a default fact. Could you please give an
> >> > example that the client communicates with two DHCPv6 servers
> >> > for the address configuration in the same time?
> >>
> >> I don't have an example; I already noted it would be unlikely in
> >> practice.  My point is that unless the restriction is specified in the
> >> protocol we can't design a new protocol implicitly assuming that
> >> restriction.  Otherwise someone may deploy the service with violating
> >> the assumption, and we cannot blame them as it's invalid.  We should
> >> either:
> >> 1. design the protocol (=sedhcpv6) so it can work without the
> >>   assumption, or
> >> 2. explicitly state it's a restriction that this protocol assumes
> >>
> >> BTW, on thinking about the reconfigure case more, I realized that
> >> including a key tag option for the client public key in the Encrypted
> >> Reply is probably a bad idea, as it could be used for client-tracking.
> >> So, in the end, option #2 above may be the least bad option anyway.
> >> The assumed restriction wouldn't be that restrictive in practice, and
> >> the client can still try all possible key pairs (if it uses multiple
> >> pairs) in the rare corner cases.
> >
> > [LS]: Agree. Then in this version, we adds the assumption description
> > clearly.
> >
> > Best Regards,
> > Lishan
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> >
>