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

From: Göran Selander <[email-masked]>
Date: Mon, 31 Oct 2016 16:14:42 +0000

Hi Jim,

Coming back to your previous review, inline below are some comments on how
we took your comments into account. (Some were not applicable with the
change of base protocol.)

Further comments are welcome!

Göran

On 2016-08-31 15:44, "Göran Selander" <[email-masked]> wrote:

>Hi Jim,
>
>Thanks very much for good comments, replies inline.
>
>
>On 2016-08-04 00:37, "Ace on behalf of Jim Schaad" <[email-masked]
>on behalf of [email-masked]> 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.

Put into the security considerations

>
>>
>>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.

NA

>
>>
>>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.

We did only different key in each direction as prescribed by the new
protocol.

>
>>
>>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?

We did go for negotiation of "Key Agreement w/ KDF" algorithm

>
>>
>>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.

Nonces are now prescribed by the protocol.

>
>>
>>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".

Considering the use cases, we decided to restrict to AEAD.
>
>>
>>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.

NA 

>
>>
>>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.

NA

>
>>
>>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

Done

>
>>
>>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.

We actually only have one mandatory algorithm, so we didn’t change this.

>
>>
>>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.

Done

>
>>
>>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.

We have not considered this case.

>
>>
>>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.

Done

>
>>
>>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.

We only use kid for symmetric pre-established keys, so we assume that the
process for establishing those keys will cater for the allocation of
unique kids.

>
>>
>>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.

Done.

>
>>
>>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.

NA

>
>> 
>>
>>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].

NA

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

NA
>
>>
>>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.

Does the use of the new protocol elements ID_U, ID_V answer your question?

>
>>
>>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.

We rewrote the KDF context, do you miss anything in the new version?

Göran

>Thanks
>Göran