Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Ludwig Seitz <[e-mail]> 
Sent: Sunday, August 25, 2019 11:40 PM
To: Benjamin Kaduk <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06

Hi Ben,

fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 
(waiting for Mike to double-check and merge them).

As for those that are still open, comments are inline.

/Ludwig

On 13/08/2019 01:15, Benjamin Kaduk wrote:

>>>      The "COSE_Key" member MAY also be used for a COSE_Key representing a
>>>      symmetric key, provided that the CWT is encrypted so that the key is
>>>      not revealed to unintended parties.  The means of encrypting a CWT is
>>>      explained in [RFC8392].  If the CWT is not encrypted, the symmetric
>>>      key MUST be encrypted as described in Section 3.3.
>>>
>>> It's hard for me to escape the conclusion that this paragraph needs to
>>> be a dedicated section with a bit more discussion about how exactly this
>>> usage is performed and encoded.
>>>
>>
>> This mirrors the corresponding procedure in RFC 7800. Would it be OK to
>> just refer to that document
>> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
> 
> (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in
> the opposite order.)
> Well, I still wouldn't like it.  But I don't think I have grounds to block
> the document from advancing if you just refer back to JWT.
>

Göran and I have discussed this, and we agree that it is indeed 
underspecified (e.g. which key is used to encrypt this "inner" 
COSE_Encrypt0 contained in the cnf element?). Additionally I can 
personally confirm that this is a headache to implement (and I haven't 
even touched a constrained implementation).

[JLS]  I am not sure that I understand why you believe that this is underspecified.  The identification of the key used here has exactly the same characteristics as the key that would be used to encrypt the CWT itself.   The configuration is going to be "Here is a signing key plus a key encryption key" as oppose to "Here is a CWT encryption key".  I have not bothered to do an implementation of this only because I do not believe that it is a useful configuration for a constrained system.  The need to do this only arises if one believes that either a) there is a need to be able to have a third party examine the token in transit or b) there is a need to have a higher degree of security for the token, but not for protecting the symmetric key.   Despite the fact that I have not implemented this, I do not believe that it would be all that problematic to implement in general, and would be even easier to implement in a constrained system as only one format of CWT should ever be expected by a single small device so that the structure can be hard coded.

[JLS] There is a potential case for the first of those options, having different authority servers that are passing things back and forth and a desire to do validation that the correct permissions exist.  That is the client AS sends a request to the Resource AS which creates a token for the RS and the client AS wants to double check the permissions granted to the client.  But I have not heard that anybody is planning to do such an implementation yet.  So far everybody is combining the two AS roles into a single system.  If you are ever in the second case, I would argue that you are better off using asymmetric keys all the way around.

We see two alternatives here:

1.) Remove the possibility to have a separate encrypted cnf element. 
Instead mandate that the whole CWT should be encrypted if it contains a 
secret key.

+ make spec easier (to implement) and doesn't requires a long 
specification on how to handle this case

- breaks direct equivalence with RFC 7800

[JLS] Given that we are starting to see people use CWTs in places where they used to be using JWTs, I would not want to put any additional problems in the way of this progression.  If others want this construct because of the equivalence to JWT, then let's not break it.

2.) Add some dedicated section that explains how the key for this inner 
encrypted cnf element is selected and communicated to the RS.

+ The draft remains functionally equivalent to RFC 7800

- Increased draft complexity at questionable gain
- Possible implementer headaches, especially on constrained devices

There is an issue about this here:
https://github.com/cwt-cnf/i-d/issues/19

[JLS] As I said above, I don't see why this is necessary.  It is part and parcel of putting the keys that the AS is going to use on the RS 

Jim



-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]