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

[Ludwig Seitz <[e-mail]>]

On 26/08/2019 18:07, Jim Schaad wrote:

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

Because the AD said so ;-)

Seriously: I believe that this warrants more text, since it must be at 
least clarified that this construct assumes two pre-configured keys 
shared between AS and RS: one for encrypting the inner cnf element and 
one for integrity protecting the whole CWT.

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

Perhaps 'headache' was a hyperbole on my part, but there is definitely a 
code-complexity difference between "parsing CBOR" and "parsing CBOR, 
interrupt the parsing to decrypt stuff, continue parsing CBOR".

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

I can see this use case. That rules out my option 1. of removing this 
construct.

/Ludwig

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