Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

[神明達哉 <[e-mail]>]

At Mon, 13 Feb 2017 23:28:41 +0800,
Lishan Li <[e-mail]> wrote:

> > - general: it's still not clear to me how we use this mechanism for
> >   Reconfigure.
> >
> [LS]: According to my understanding:
> 1. The server sends the encrypted Reconfigure message to the client;

Encapsulated in an Encrypted-Response message?  If so, with setting
transaction-id to 0 (like Reconfigure itself)?  And is the client
supposed to try to decrypt it when transaction-id is 0 even if it
doesn't match any outstanding Encrypted-Query it has sent?  And in
that case which private key should the client use?  (For the last
question, see also the comment on the assumption of the number of
client certificate described in Section 6).

I think these questions and issues can be addressed relatively easily,
but I believe these should be clearly and explicitly described.

> >   The description of zero hash algorithm field seems to suggest the
> >   signature and hash algorithms are tightly related in practice.  So
> >   it may be better to define the algorithm option so that
> >   signature/hash algorithms are listed as pairs.
> >
> [LS]: Yes. In some cases, the signature and hash algorithm are tightly
> related and cannot be separate. Sorry that I don't understand that
> "it may be better to define the algorithm option so that signature/hash
> algorithms are listed as pairs", Could you please explain it more clearly?

For example, instead of listing SA-id List and HA-id List separately,
we might have unified SA-id List:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_ALGORITHM         |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          EA-id List                           .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          SA-id List                           .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(no "HA-id List" in this level)

and each entry of SA-id List has two sub fields: signature algorithm
ID and hash algorithm ID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           SA-len              |            SA-id[1]           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           HA-id[1]            |            SA-id[2]           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           HA-id[2]            | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           SA-id[n]            |            SA-id[n]           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and each pair of (SA-id[i], HA-id[i]) will be considered to specify a
specific signature method.

> > - Section 6
> >
> >    The first DHCPv6 message sent from the client to the server, such as
> >    Solicit message, MUST contain the Certificate option, Signature
> >    option and Increasing-number option for client authentication.[...]
> >    [...]  One and only one Increasing-number option SHOULD be
> >    contained,
> >
> >   Isn't there a MUST vs SHOULD conflict here?
> >
> [LS]: The increasing-number option is optional, not must be contained.
> In the before version of secure DHCPv6 without encryption, the timestamp
> option is optional. But in fact, I don't know why it is optional.

This doesn't address my question...

> > - Section 6
> >
> >    [...] In this document, it is assumed
> >    that the client uses only one certificate for the encrypted DHCPv6
> >    configuration.  So, the corresponding private key is used for
> >    decryption.
> >
> >   I'm not sure if this is okay.  And, in fact, Section 11 talks about
> >   a case where multiple key pairs (so multiple certificates) are used:
> >
> >    If the client tries more than one cert for client authentication, the
> >    server can easily get a client that implements this to enumerate its
> >    entire cert list and probably learn a lot about a client that way.
> >
> >  Perhaps this is intended to handle encrypted Reconfigure?  If that's
> >  the only reason for this limitation, I think we should address the
> >  reconfigure case in some other way and keep the general specification
> >  more flexible.
> >
> [LS]: So we deletes the description in section 11.

I don't understand how this addresses the comment...

> > - Section 9.1
> >
> >    [...]  And the client can forget the increasing number
> >    information after the transaction is finished.  The client's initial
> >    locally stored increasing number is set to zero.
> >
> >   I'm not sure if I understand it and I'm not sure if it's okay
> >   whatever it means...does this mean the server can (or always does?)
> >   reset the increasing number to 0 for messages it sends to the server
> >   at the beginning of a new DHCPv6 session?  Doesn't it lead to an
> >   easy replay attack?  Or is the assumption that the server first
> >   sends an error and the client will resend the message with an
> >   adjusted increasing number?
> >
> [LS]: For the first received increasing-number option, the client cannot
> check it and just need to change the local increasing number into the
> received number. So for this purpose, i add the above statement.
> Looking forward to your further guidance.

I'd suggest consulting Ted here, as I guess the introduction of
increasing-number option was originally his idea.

> > - Section 10.1.1
> >
> >                The mandatory encryption
> >                algorithms MUST be included.
> >
> >   Which algorithm is it?
> >
> [LS]: The mandatory encryption algorithm is RSA. How about the following
> text:
> The mandatory encryption algorithm, such as RSA, MUST be included.

I don' know why "such as".  I'd consider a particular algorithm(s)
mandatory at the time of this document, and it/they should be
explicitly defined here.

> > - Section 10.1.2
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      OPTION_CERTIFICATE       |         option-len            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |              EA-id            |            SA-id              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                                                               |
> >    .                           Certificate                         .
> >    |                                                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >   This seems to assume a single certificate (which I assume means a
> >   single public key) can be used for both encryption and signature.
> >   Is my understanding correct?  If so, can we always assume that?
> >
> [LS]: Yes, it means a single certificate and a single public key.
> If EA-id = 0 & SA-id !=0, then the public key is used for signature.
> If EA-id != 0 & SA-id =0, then the public key is used for encryption.
> If EA-id != 0 & SA-id !=0, then the public key is used for signature and
> encryption.

Ah, so if we want to use different algorithms and/or keys for
signature and encryption, we have two certificate options, each
setting EA-id or SA-id to 0?  If so, I suggest explaining it
explicitly.

> >   And, although it may be quite straightforward, I don't think this
> >   description is enough to actually calculate the tag value for a
> >   given public key.  We should provide some more specific here.
> >
> [LS]: Add some more specific text about how to compute it?
> In the before, I prepared some text about it.
>  Key Tag Calculation

I've not read the entire text, but it looked like a bit too verbose.
I'll see if I can offer some specific text.

--
JINMEI, Tatuya