Re: [Ace] Review of draft-selander-ace-cose-ecdhe-02

[Göran Selander <[e-mail]>]

Hi Jim,

Thanks very much for good comments, replies inline.


On 2016-08-04 00:37, "Ace on behalf of Jim Schaad" <[e-mail]
on behalf of [e-mail]> wrote:

>This may be a bit scatterbrained as I did this review in several sessions
>and the thoughts might not be consistent.
>
>1.  In section #1, I would put in the fact that the derived key would only
>be used for a period of time, after which a new ECDH key exchange would be
>run again.

Agree.

>
>2.  It is not clear, but based on how the value of kid_ev is defined, it
>might be reasonable to state that there is an expectation that generally U
>will be a client and V a server.

Correct, but there is also the desire to use the context for client and
server switching roles, and more generally sender and listener in a group.
This relates to your comments on OSCOAP.

>
>3.  I would like to see the PSK half of the world setup so that it is not
>required that the same key/kid pair be used in both directions.  Using a
>different key in each direction makes things cleaner for some issues.
>Both
>cases of the same and different pairs should be permitted.

OK.

>
>4.  I see no reason to say that what one is negotiating is a hash
>function.
>What you are negotiating is a "Key Agreement w/ KDF" algorithm.  I don't
>see
>that you are using the hash function by itself anywhere.

For simplicity changed to negotiation of KDF, OK?

>
>5.  In section 2, you should give a reason for including or not including
>the nonces in the protocol.  Since they are optional when would they be
>useful?

It is explained in [RFC5869] which is referenced but we can add that.

>
>6. In section 2, do you expect that TCA is restricted to CEK or would MAC
>algorithms be usable as well?

Changed to "AEAD or MAC".

>
>7.  In section 2, I missed where the replay parameter was included in the
>COSE_Header - it seems to be in the key for party U and non-existant for
>party V.  The closest that one comes it the use of the message_1 signature
>as AAD.

Yes, replay is mainly an issue for party V.

>
>8.  In figure 3, I would prefer to see two different traffic keys being
>derived.  It is not an issue in Figure 2 as that just says keying
>material.
>Using different keying material in each direction prevents reflection
>attacks.

I think we are just copying TLS 1.3 terminology here. “traffic_secret_0”
is the “base key” used to derive the different client and server keys you
request.

>
>9.  In section 2.1, you talk about authentication methods but do not
>discuss
>authorization methods.  Does this need to be built into message_1 or are
>there other methods that will be functional here.  May need to refer to
>how
>some of them might work since this will also potentially affect how the
>distribution of the keys in advance works.  For example, if an OAUTH token
>is published to a well-known location that contains both authorization and
>authentication information.

Good catch. There is a story for how EDHOC works with ACE but we forgot to
mention it here and make the reference: See figure 1 of
https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile-00

>
>10.  In section 3.1, I am not sure that you really want to have only a
>single algorithm in this specification.  I would make it more generation
>in
>terms of how a COSE_Key is built and then have a statement elsewhere
>rather
>than spread throughout the document about what algorithms are mandatory to
>support.

Yes, this was just to be concrete. Good proposal.

>
>11.  In section 3.4.2 - I think that you need to have a more comprehensive
>external_AAD structure that what is here.  I am not sure that you should
>not
>AAD information from the CoAP header as well in all of the messages.

This should be the entire message_1.

>
>12. Stupid question - Can you do a PSK in one direction and a signature in
>the other?

I’d like to pass that question on to CFRG.

>
>13. Not sure that it matters, but you have the COSE_KDF_Context structure
>wrong everywhere.  The partyU and partyV fields are not optional.

Yes, we are re-considering the identities used. Also relates to your
comment on OSCOAP.

>
>14.  Section 3.5, I don't believe in uniquely identified kids on any
>device
>unless that device is going to enforce that as a true statement.  That
>means
>that it will not allow for a key to be registered with it unless the kid
>is
>unique.    There is nothing wrong with doing an exhaustive search of all
>of
>the keys with the same kid as long as the number of them is not too large.

We strive for allowing a) short identifiers if there is a naming authority
and b) sufficiently long random identifiers if a) is not possible. If
possible we would like to avoid exhaustive search, although that would be
doable.

>
>15.  Section 3.5.3:  If you are sending along a certificate, it is not
>clear
>to me that you need to have a kid as well.  The certificate is where you
>are
>going to get the key from not the kid.

Agree.

>
>16. Section 4.1 - kid_eu - Does this really need to be a counter on a per
>party V basis or can it just be a counter based on the use of the
>credential
>that is being used to do the authentication?

Yes, the latter is fine. We are considering this also in OSCOAP.

> 
>
>17.  Section 5 - what happens if N_U or N_V is longer than the size of the
>hash function.  

Good catch. This construct was intended to simply incorporate arbitrarily
small nonces, as is encouraged in section 3.1 of [RFC5869].


>Also, what do you mean by the size of the hash function?  Is
>this the barrel size or the output size?

Output size.  

>
>18.  Identity of the Parties:  There is a question on what the identity
>structure that is being used to grant access is for ACE.  For those who
>have
>been in the IETF long enough, one answer would be to move back to the
>world
>of SPKI (Simple Public Key Infrastructure) where the key is the entity
>that
>is used for identifying an entity and not some other piece of information
>like a text string or an address.  Doing a security analysis, one might
>find
>that one wishes to do a binding of the identity information into the key
>derivation process.  If keys are the marker of identity, then this is
>would
>be including the keys as part of the context information thus tying the
>signature and key into the resulting key.  The requirement to include
>identity information is probably needed more if access control is being
>based on a name rather than a key however.  In this case it is likely more
>important that the binding processes is included in the KDF context in
>some
>manner.

So far in EDHOC and OSCOAP the identity has been associated to the key,
mainly for reasons of optimization. As mentioned above we are
reconsidering this, for reasons of generality.

>
>19.  Use of the signature/MAC for chaining of items:  I did a fast review
>of
>how the fields of message_1 and message_2 are used in the final KDF
>processing.  From what I saw, there are only a couple of things that are
>not
>directly re-used as part of the context.  These are: 1) the exact encoding
>of the messages, 2) the list of key agreement algorithms, 3) the list of
>TCA
>algorithms, 4) kid_eu and kid_ev, and 5) the protected attributes in each
>of
>the messages.
>Exact encoding can be addressed by using the same encoding rules that are
>in
>COSE - that is use of a minimal encoding size along with a stricter
>statement bout checking the grammar in the processing rules.
>I am not worried about the two lists of algorithms as message_1 is
>authenticated and the rules should state that the returned values in
>message_2 are checked against the original list.  The final pair of
>algorithms are either directly (TCA) or indirectly (Key agreement)
>included
>in the computing of the traffic keys.
>The KIDs might want to be included, and doing so would allow for
>generation
>of different traffic keys in each direction.
>The protected attributes should potentially be included in the computation
>along with the keys to provide tying the identity and signatures together
>in
>a tighter binding.  I don't know that there is an attack that can be
>launched here, but this would make it that much more difficult.

Seems prudent, we will consider this in the next version.

Thanks
Göran