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

[Ludwig Seitz <[e-mail]>]

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

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

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


>>>      The following example CWT Claims Set of a CWT (using CBOR diagnostic
>>>      notation, with linebreaks for readability) illustrates the use of an
>>>      encrypted symmetric key as the "Encrypted_COSE_Key" member value:
>>>
>>>     {
>>>      /iss/ 1 : "coaps://server.example.com",
>>>      /sub/ 2 : "24400320",
>>>      /aud/ 3: "s6BhdRkqt3",
>>>      /exp/ 4 : 1311281970,
>>>      /iat/ 5 : 1311280970,
>>>      /cnf/ 8 : {
>>>      /COSE_Encrypt0/ 2 : [
>>>
>>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
>>>
>>> [I did not validate the COSE_Encrypt0 output]
>>>
>>
>> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
>> is not. We'd have to define it or write an explanatory comment.
> 
> Maybe I'm confused about how the diagnostic notation works, but the
> top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
> iss/sub/aud/etc. in the preceding notation.  If the rules are different for
> map keys whose corresponding values are themselves structured data types,
> then I should just unconfuse myself and we can move on with things...
> 
>

Issue created here https://github.com/cwt-cnf/i-d/issues/20
Will fix.


>>
>>>      o  A recipient can decide not to use a CWT based on a created Key ID
>>>         if it does not fit the recipient's requirements.
>>>
>>> I'm not sure I understand the semantics being described here.  Are we
>>> saying that the issuer might give a presenter a CWT, and by the time the
>>> presenter presents the CWT to the recipient, the recipient says "this is
>>> no good" and denies the transaction in question, forcing the presenter
>>> to go back to the issuer and try again?  (How do we know that the issuer
>>> would make any different choices the second time around?)
>>
>> This risk always exists. In a constrained device world, the recipient
>> may already have cleared out the key referenced by the key ID, which
>> would force it to reject a CWT using this as proof-of-possession.
>>
>> I'm not sure how to give good guidance in this case. The error message
>> delivered by the recipient rejecting the CWT might be helpful I suppose.
>> Do you think this merits some text?
> 
> It's not entirely clear to me that we need to add more text here, but if we
> did, it would focus on what "decide not to use" means at a protocol level,
> and perhaps how the CWT might not "fit the recipient's requirements" (e.g.,
> the key id having fallen out of cache as you describe).

Issue created here: https://github.com/cwt-cnf/i-d/issues/21
Will fix.

>>
>>>      from changing any elements conveyed within the CWT payload.  Special
>>>      care has to be applied when carrying symmetric keys inside the CWT
>>>      since those not only require integrity protection but also
>>>      confidentiality protection.
>>>
>>> Do we want to reiterate the common mechanisms for providing
>>> confidentiality protection here, or just leave the existing text earlier
>>> in the document to cover it?
>>>
>> Doesn't it say a few sentences before: "it is
>>      necessary to apply data origin authentication and integrity
>>      protection (via a keyed message digest or a digital signature)." ?
>>
>> I would consider this to be enough.
> 
> That doesn't cover the *confidentiality* protection, specifically.  (So it
> seems the answer to my original question is still unclear, at least to me.)
> 

Issue created here: https://github.com/cwt-cnf/i-d/issues/22
Will fix.

> 
>>> Section 6
>>>
>>>      ensure correct processing.  The recipient needs to be able to use
>>>      credentials to verify the authenticity, integrity, and potentially
>>>      the confidentiality of the CWT and its content.  This requires the
>>>
>>> Just from a rhetorical point of view, can you help me understand how
>>> credentials would be used to verify the confidentiality of a CWT?  It
>>> seems like this depends on either (or both of) how the CWT is
>>> transmitted or how it is prepared, and I am not sure how the recipient's
>>> credentials come into play.
>>>
>>
>> This text is referring to the issuer's credentials (e.g. the
>> Authorization Server issuing the CWT), that the recipient needs to
>> verify the CWT. Do you want us to clarify this sentence?
> 
> Note that I was specifically asking about "potentially the
> confidentiality"; I don't understand the intended workflow for verification
> of confidentiality (and thus which credentials are involved).  I don't
> really see how a credential held solely by the issuer could proide
> confidentiality protection when it needs to be understood by some other
> protocol participant.

Issue created here: https://github.com/cwt-cnf/i-d/issues/23
Will fix.


>>> Section 7
>>>
>>>      Criteria that should be applied by the Designated Experts include
>>>      determining whether the proposed registration duplicates existing
>>>      functionality, determining whether it is likely to be of general
>>>      applicability or whether it is useful only for a single application,
>>>      and evaluating the security properties of the item being registered
>>>      and whether the registration makes sense.
>>>
>>> I know we've been using (variations of) this text for a while, but it
>>> seems to me that it could be more clear than it currently is -- is
>>> duplication of functionality grounds for denial of registration?  What
>>> about general vs. specific applicability?  The latter seems more clearly
>>> applicable for determining which range from which to allocate, since
>>> that has impact on the encoding size.  Can the experts insist on updates
>>> to the security considerations text of a specification prior to granting
>>> approval, or are they limited to denying registration of values with
>>> poor security properties or insufficient documentation thereof?
>>>
>>
>> I'm too unfamiliar with the designated expert system to provide a good
>> answer on this one. Can one of my co-authors chip in here?
>>
Issue created here: https://github.com/cwt-cnf/i-d/issues/25
Will fix.


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