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

From: Ludwig Seitz <[email-masked]>
Date: Mon, 12 Aug 2019 14:08:12 +0200

Hello Ben,

thank you for your review. Comments inline.

@co-authors: Please check if you agree with my proposed resolutions.

/Ludwig

On 30/07/2019 17:56, Benjamin Kaduk wrote:
> We should be consistent across examples about whether the use of CBOR
> diagnostic notation also requires a disclaimer about "with linebreaks
> for readability".

As far as I gather from the comments (especially from Carsten), we'd 
solve this by referencing section 6 of RFC 7049. I will consult with my 
co-authors, but I think this is the right solution.

> 
> Section 2
> 
>     Presenter
>        Party that proves possession of a private key (for asymmetric key
>        cryptography) or secret key (for symmetric key cryptography) to a
>        recipient.
> 
> nit: it might be worth either capitalizing Recipient to point to the
> following item more clearly, or specifying "recipient of a CWT" for
> parallelism with Recipient.
> (If we do the former we should capitalize Presenter in the following
> definition.  But since we don't use the capitalized terms throughout the
> text, it wouldn't be my own preference.)
> 
Ok I'll go for "recipient of a CWT"

> Section 3.2
> 
> This example key expired in 2013.  While the example will "always" be
> expired for an archival document, it might be worth making it more
> timely with respect to the publication date.  (This holds for basically
> all time values in the document's examples.)
> 
> Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
> 
> [I did not check that the example x and y coordinates are in fact points
> on P256.]

I agree this should be updated.

> 
>     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.3
> 
> Is the /HMAC256/ the conventional diagnostic notation for alg value 5
> (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
> 

I agree with Jim's suggestion to use HMAC256/256

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

> Section 3.4
> 
>       {
>        /iss/ 1 : "coaps://server.example.com",
>        /aud/ 3 : "coaps://client.example.org",
> 
> Is it in any way confusing to use client.example.org as opposed to, say,
> resource.example.org as the audience?

I agree, and issuer feels like it should be "as.example.com".

> 
>        /exp/ 4 : 1361398824,
>        /cnf/ 8 : {
>          /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
> 
> /kid/ in the 'cnf' map has key 3, not 2.
> 
Will fix.

>     Note that the use of a Key ID to identify a proof-of-possesion key
>     needs to be carefully circumscribed, as described below and in
>     Section 6.  Where the Key ID is not a cryptographic value derived
>     from the key or where all of the parties involved are not validating
>     the cryptographic derivation, it is possible to get into situations
>     where the same Key ID is being used for multiple keys.  The
> 
> I don't think this quite covers the needed properties, since we also
> need some assurance that all parties are interpreting the kid value in
> the same way. It may be possible to construct such a scenario via an
> attacker replaying a stolen token or even just inadvertent confusion by
> some party (quite plausible when we consider scenarios that involve the
> same key being described by different 'kid' values in messages with
> different recipients).  In particular, if the situation arises where an
> attacker is able to choose the 'kid' value that will be used, they could
> deliberately cause a collision with a legitimate value used by some
> other party.
> 

I will go with you suggestion (later in the discussion) to add some text 
that implementers should expect kid collisions.

>     In the world of constrained Internet of Things (IoT) devices, there
>     is frequently a restriction on the size of Key IDs, either because of
>     table constraints or a desire to keep message sizes small.  These
>     restrictions are going to protocol dependent.  For example, DTLS can
> 
> nit: "going to be" or maybe even just "are protocol dependent".
Will fix.

> 
>     use a Key ID of any size.  However, if the key is being used with
>     COSE encrypted message, then the length of the key needs to be
>     minimized and may have a limit as small as one byte.
> 
> nit: is this "length of the key" or "length of the key ID"?
Length of key ID evidently. Will fix.

> 
>     Note that the value of a Key ID is not always the same for different
>     parties.  When sending a COSE encrypted message with a shared key,
>     the Key ID may be different on both sides of the conversation, with
>     the appropriate one being included in the message based on the
>     recipient of the message.
> 
> While this recipient-dependence is probably unavoidable (as the
> requisite namespacing would use more space on the wire than is
> reasonable for many applications), it does merit some security
> considerations text, noting that such messages are context-dependant and
> could be misinterpreted if presented in a different context.
> Audience restrictions, as mentioned in Section 4, provide substantial
> protection in this regard, but are not necessarily a complete solution.
> 
If I get the gist of your discussion with Jim, the text about 
non-uniqueness of kid would resolve this.

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

> 
>     o  If an issuer is going to use the Key ID confirmation method and is
>        not going to guarantee that serial number uniqueness is going to
>        be preserved, the recipient needs to have that information
>        configured into it so that appropriate actions can be taken.
> 
> nit: this is the only place in the document that talks about "serial
> number"s.

I think that was intended to refer to key ID uniqueness. I'll 
double-check with Mike.

> Do we say what the "appropriate actions" are somewhere else in the
> document?

I agree this is disturbingly unspecific. I'll try to rephrase this.

> 
> Section 3.5
> 
>     Note that another means of proving possession of the key when it is a
>     symmetric key is to encrypt the key to the recipient.  The means of
>     obtaining a key for the recipient is likewise protocol specific.
> 
> While true, there are some subtleties here, namely that the recipient
> needs some way of knowing that it is the presenter (as opposed to some
> other party) that has actually performed that encryption.  In Kerberos
> we perform this key confirmation by using the encrypted (session) key
> for subsequent protocol exchanges, and if the presenter fails to process
> those exchanges then it is clear the presenter does not actually possess
> the key.  This document does not seem to describe the need for such
> subsequent confirmation (or, alternately, the consequences of failing to
> do so.)
> 

Yes this sounds misleading, there obviously needs to be a recipient 
nonce in there somewhere. But since the title of this section is 
"Specifics Intentionally Not Specified" I'm more inclined to rewrite 
this more non-specifically. How about:
"Note that other means of proving possession of a key exist, which could 
be used in conjunction with a CWT's confirmation key."
?

> Section 4
> 
>     A recipient might not understand the "cnf" claim.  Applications that
>     require the proof-of-possession keys communicated with it to be
>     understood and processed MUST ensure that the parts of this
>     specification that they use are implemented.
> 
> nit(?): I'm not sure I'm parsing this sentence correctly: is
> "communicated with it" referring to "CWTs that include the 'cnf' claim"?
> 

How about rephrasing this to:
"Applications that require the use of proof-of-possession in CWTs, using
the 'cnf' claim MUST ensure that the parts of this specification that 
they use are implemented."
?

>                  To avoid replay attacks when the proof-of-possession
>     tokens are sent to presenters, a security protocol, which uses
>     mechansims such as nonces or timestamps, has to be utilized.  [...]
> 
> I suspect the RFC Editor will want to reword this sentence to avoid the
> excessive parentheticals and awkward passive-voice construction.  I'll
> be bold and suggest a more dramatic rewording to preempt that: "Proof of
> possession only provides the intended security gains when the proof is
> known to be current and not subject to replay attacks; security
> protocols using mechanisms such as nonces and timestamps can be used to
> avoid this risk of replay when sending proof-of-possession tokens to
> [presenters or recipients]".  Note that I am not sure if the original
> was intended to refer to the transfer of PoP tokens to presenters (as
> written) or recipients (where risk of replay is more traditionally
> concerned).
> 

I am in favor of adapting/adopting your suggestion. The original 
sentence sounds strange indeed.

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

> Section 5
> 
> This sort of correlation can occur even for subsequent connections
> between the same two parties if observed by a passive observer (e.g., in
> the case of a mobile client that changes location).  I forget if we have
> strong enough guarantees on the use of transport-level encryption that
> would prevent such CWTs from being observed in this fashion.
> 

How about rephrasing the sentence to "... can be used as a correlation 
handle if the same key is used in multiple occasions."?

This would be more general and also cover the passive observer case.

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

>     recipient to know information about the issuer.  Likewise, there
>     needs to be agreement between the issuer and the recipient about the
>     claims being used (which is also true of CWTs in general).
> 
> We briefly discuss the presenter (in the guise of the subject) in the
> next paragraph when we talk about key IDs, but are there any other cases
> where there needs to be coordination with the presenter?  Would
> distributing a symmetric PoP key be considered to fall under this
> mantle?

Yes indeed, I believe it was left out here because it seems quite 
evident that the presenter needs to be involved when talking about 
proof-of-possession.

>     When an issuer creates a CWT containing a Key ID claim, it needs to
>     make sure that it does not issue another CWT containing the same Key
>     ID with a different content, or for a different subject, within the
>     lifetime of the CWTs, unless intentionally desired.  Failure to do so
>     may allow one party to impersonate another party, with the potential
>     to gain additional privileges.  Likewise, if PoP keys are used for
> 
> nit: "same Key ID with a different content" doesn't seem quite right, as
> the "content" of a Key ID is surely the key-ID value itself.  Perhaps
> "referring to" would be more appropriate.

What is meant here is different _other_ content, i.e. other claims such 
as the scope and audience claims. I will try to rephrase this to clarify.

> I think we should probably give the reader some indication of what
> semantics might be attributed to the "intentionally desired" case.  It
> doesn't necessarily need to be a specific example, but we could say what
> the relevant properties/attributes that might lead to such a situation
> would be.
> 
Ok I'll add an few sentences to describe the example we had in mind, 
where several CWTs are bound to the same key for the same presenter.

>     multiple different kinds of CWTs in an application and the PoP keys
>     are identified by Key IDs, care must be taken to keep the keys for
>     the different kinds of CWTs segregated so that an attacker cannot
>     cause the wrong PoP key to be used by using a valid Key ID for the
>     wrong kind of CWT.
> 
> Audience restrictions can come into play here, too, right?  In that a
> restricted audience of all the CWTs in turn limits the scope of
> administration in which this care/segregation needs to be enforced.
> 

Correct, we should add a sentence here to suggest this as one strategy 
to limit this risk.

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

> Section 7.2.1
> 
>     Change Controller:
>        For Standards Track RFCs, list the "IESG".  For others, give the
>        name of the responsible party.  Other details (e.g., postal
>        address, email address, home page URI) may also be included.
> 
> In light of the GDPR and similar regulations (and, as is done in RFC 8602), we
> may not want to keep all of these, especially postal address, given the lack of
> a clear need.
> 

Ok I'll have a look at how it is done in RFC 8602 and adapt this text 
accordingly.

>     Specification Document(s):
>        Reference to the document or documents that specify the parameter,
>        preferably including URIs that can be used to retrieve copies of
> 
> Is the reference required to be publicly accessible?  If not, is it
> required that a copy be made available to the experts and IANA?
> 

I think that at least the experts and IANA should be able to inspect a 
copy, how are they going to do their job otherwise?
Do you want us to take any textual action here or was this just a 
general remark?

> Section 7.2.2
> 
>     o  Confirmation Method Name: "Encrypted_COSE_Key"
>     o  Confirmation Method Description: Encrypted COSE_Key
>     o  JWT Confirmation Method Name: "jwe"
>     o  Confirmation Key: 2
>     o  Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
>        structure (with an optional corresponding COSE_Encrypt or
>        COSE_Encrypt0 tag)
> 
> Do we want to say something about how, in the case when the tag is
> omitted, the application protocol specification needs to indicate how to
> determine which one is in use?
> 
As a result of your subsequent discussion with Jim I am inclined to 
leave this as it is. Is that acceptable for you?

> Section 8.2
> 
> I think [JWT] needs to be normative, as we have a SHOULD-level
> requirement for the audience restriction procedures it specifies.
> 
I agree with Jim's assessment that an indirect normative reference via 
the CWT RFC is sufficient.

> I just want to check that it's intentional/desired to mix descriptive
> reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for
> the referenced RFCs.
> 
I'm more inclined to have RFC number tags (makes it easier to look them 
up without going via the bibliography), but it's mostly a matter of 
taste. Do you think we should use one or the other consistently?

> Acknowledgements, Authors
> 
> The datatracker is currently accepting XML v3 format drafts, and the RFC
> Editor's target cutover date for the end of August is quite soon, so
> feel free to consider using an XML v3 submission with UTF-8
> representations of names not well represented by the ASCII subset.
> 
It broke some older version of xml2rfc at some earlier point (the 
default one coming with Ubuntu distros), but since I got that fixed now, 
I'm inclined to give Göran his umlaut.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Aug 2019 23:59:32 +0200

On Aug 12, 2019, at 14:08, Ludwig Seitz <[email-masked]> wrote:
> 
> As far as I gather from the comments (especially from Carsten), we'd solve this by referencing section 6 of RFC 7049. I will consult with my co-authors, but I think this is the right solution.

That is not what I said.

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Aug 2019 18:15:18 -0500

> co-authors, but I think this is the right solution.

I think Carsten's followup refers to
https://mailarchive.ietf.org/arch/msg/ace/y_fPgWe-m8B2OpJChQ1qhoURuPU which
says to refer to RFC 8610 (or Appendix G thereof).  And to be clear, my
original point was just that we cannot have some examples say "with
linebreaks for readability" and some not, within the same document, but I
did not attempt to propose which variant to unify to.

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

> I agree with Jim's suggestion to use HMAC256/256

Works for me.  (This was an honest question, as opposed to those other
times when I think I know the answer already but want to leave open the
possibility of being wrong.)

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

> that implementers should expect kid collisions.

Okay.

> non-uniqueness of kid would resolve this.

Yup!

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

> be used in conjunction with a CWT's confirmation key."

That should be okay.  Would we want to also have some text encouraging use
of the CWT Confirmation Methods Registry?

> they use are implemented."

Sure, with the addition of a comma after "using the 'cnf' claim".

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

> This would be more general and also cover the passive observer case.

Works for me.

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

> evident that the presenter needs to be involved when talking about 

I guess the idea is that the coordination happens "in-band" when the CWT is
issued, so I don't see a need for text changes here, given this discussion.

> as the scope and audience claims. I will try to rephrase this to clarify.

"adjacent" or "sibling" content might work, brainstorming some ideas.

> where several CWTs are bound to the same key for the same presenter.

Thanks.

> Do you want us to take any textual action here or was this just a 

I think it is good to have some textual action to make that explicit.  Then
people submitting registration requests are less likely to be surprised...

> leave this as it is. Is that acceptable for you?

Yes!

> taste. Do you think we should use one or the other consistently?

I don't mind the current status (or all-RFC-number tags, for that matter);
I just wanted to check that the "inconsistency" was intentional.

> I'm inclined to give Göran his umlaut.

:)

Thanks,

Ben

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 13 Aug 2019 07:50:24 +0200

>> As far as I gather from the comments (especially from Carsten), we'd solve this by referencing section 6 of RFC 7049. I will consult with my co-authors, but I think this is the right solution.

Sorry,

hasty copy-paste of the wrong reference (the right one came later in 
your email: Appendix G of RFC 8610).

I blame Monday morning after the holidays ...

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 26 Aug 2019 08:39:54 +0200

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

> 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

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

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

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

> confidentiality protection when it needs to be understood by some other

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

>> 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 +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Mon, 26 Aug 2019 09:07:19 -0700

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

Hi Ben,

/Ludwig

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

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

[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 +46(0)70-349 92 51

---

From: Mike Jones <[email-masked]>
Date: Mon, 26 Aug 2019 19:32:50 +0000

Please see my review of the PR, Ludwig.

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

Hi Ben,

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 27 Aug 2019 08:52:23 +0200

On 26/08/2019 18:07, Jim Schaad 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 
>> (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.
>> 
> 
> 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 +46(0)70-349 92 51