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

From: Jim Schaad <[email-masked]>
Date: Wed, 3 Aug 2016 15:37:17 -0700

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.

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.

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.

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.

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?

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

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.

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.

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.

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.

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.

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

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

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.

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.

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? 

17.  Section 5 - what happens if N_U or N_V is longer than the size of the
hash function.  Also, what do you mean by the size of the hash function?  Is
this the barrel size or the 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.

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.

Jim

---

From: Göran Selander <[email-masked]>
Date: Wed, 31 Aug 2016 13:44:34 +0000

Hi Jim,

Thanks very much for good comments, replies inline.

On 2016-08-04 00:37, "Ace on behalf of Jim Schaad" <[email-masked]

>be used for a period of time, after which a new ECDH key exchange would be

Agree.

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

>cases of the same and different pairs should be permitted.

OK.

>that you are using the hash function by itself anywhere.

For simplicity changed to negotiation of KDF, OK?

>the nonces in the protocol.  Since they are optional when would they be

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

>algorithms be usable as well?

Changed to "AEAD or MAC".

>party V.  The closest that one comes it the use of the message_1 signature

Yes, replay is mainly an issue for party V.

>Using different keying material in each direction prevents reflection

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.

>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

>than spread throughout the document about what algorithms are mandatory to

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

>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

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

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

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

>going to get the key from not the kid.

Agree.

>that is being used to do the authentication?

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

>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

Output size.  

>important that the binding processes is included in the KDF context in

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.

>launched here, but this would make it that much more difficult.

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

Thanks
Göran