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

Jim Schaad <ietf@augustcellars.com> Wed, 03 August 2016 22:37 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC2712D8C8 for <ace@ietfa.amsl.com>; Wed, 3 Aug 2016 15:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rEViNOP-f1x for <ace@ietfa.amsl.com>; Wed, 3 Aug 2016 15:37:23 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074C512D8CD for <ace@ietf.org>; Wed, 3 Aug 2016 15:37:23 -0700 (PDT)
Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 Aug 2016 15:48:59 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-selander-ace-cose-ecdhe@tools.ietf.org, ace@ietf.org
Date: Wed, 03 Aug 2016 15:37:17 -0700
Message-ID: <04da01d1edd7$9898fe50$c9cafaf0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdHtPoYq0jj2+v67TYSluvCIdfOugg==
Content-Language: en-us
X-Originating-IP: [24.21.96.37]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/vYgb5q-SvdEPBHGvy2D2uVFZFQU>
Subject: [Ace] Review of draft-selander-ace-cose-ecdhe-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2016 22:37:29 -0000

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