Subject: [Ace] Review of draft-jones-ace-cwt-proof-of-possession-00

From: Jim Schaad <[email-masked]>
Date: Tue, 27 Jun 2017 00:50:19 -0700

Abstract - I am unclear how this is a profile of RFC 7800 rather than a
restatement of that document.   In what way does this qualify as a profile?

Introduction - I do not understand the second half of the first sentence in
the introduction.  It claims that the document is going to show how proof of
possession is done, however this seems to be explicitly declared as out of
scope in section 3.5.

Section 2 - Since this document is currently planned to come from the ACE
working group,  I would suggest that it would be reasonable to provide the
equivalent terminology to what is in this document. -- see actors

Section 3 - para 1 - missed  a s/JSON/CBOR/

Section 3 - para 2 - I am not sure of the following:
- Why this is included here and not a separate section
- Why the concept of an anonymous POP is not supported
- Why the concept of the issuer being inferred from the authentication key
on the CWT is not supported
- I will note that draft-ietf-ace-oauth-authz does not require either of
these fields to be present.

Section 3.1 - The first two sentences seems to be slightly contradictory -
the first says the cnf claim is used to identify the POP key.  The second
states that it may have something other than a POP key in it.

Section 3.1 - I am not a fan of MUST ignore statements at this level.  It
should be  profile statement if anything.

Section 3.1 - last paragraph - Does this mean that only one claim can be in
the cnf claim - or are some values of different levels?  For example -can I
have a COSE_Key and an Kid?  This might be considered to be multiple POP
keys.

Section 3.2 - Profiles can require that additional elements can be required
in the COSE_Key element - and example would be to require that the algorithm
identifier be present.

Section 3.2 - I do not understand why this paragraph is doing in this
section give the section title.  Why is it not in section 3.3 or in a
separate section.  I think it makes mores sense at the end of the next
section.

Section 3.3 - Why is title not symmetric with section 3.2 and the word
encrypted be absent?

Section 3.4 - This section just makes me uncomfortable.  Use a value that
was potentially chosen for collisions does not seem to be a good idea.  I
think this really needs some additional guidance about using.

Section 4 - Is there any reason to suppose that the use of asymmetric
secrets are immune from replay attacks?

Section 3.1 - para 1 -sentence #2  -  I do not understand the implication
that the POP key implies the authenticity of the token.  That statement
makes no sense to me.  This would look  like a self-signed certificate as
the authentication point. 

Jim

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Jun 2017 02:21:20 +0000

Thanks for your useful review, Jim.  Replies are inline below...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, June 27, 2017 12:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: Review of draft-jones-ace-cwt-proof-of-possession-00

The draft now says that it provides equivalent functionality to RFC 7800 rather than being a profile of it.

Introduction - I do not understand the second half of the first sentence in the introduction.  It claims that the document is going to show how proof of possession is done, however this seems to be explicitly declared as out of scope in section 3.5.

You're right.  I have deleted the second half.

Section 2 - Since this document is currently planned to come from the ACE working group,  I would suggest that it would be reasonable to provide the equivalent terminology to what is in this document. -- see actors

Maybe we can talk about specific proposed edits in Prague.

Fixed

It was here in RFC 7800.  It could be moved and given its own section but wanted to start out with a completely parallel document.

I assume you're talking about a situation in which the identity of the presenter is not known or revealed?  I assume this is related to your next comment?

- Why the concept of the issuer being inferred from the authentication key on the CWT is not supported

If this is done in practice, particularly within ACE, this could be explicitly mentioned in the future.

- I will note that draft-ietf-ace-oauth-authz does not require either of these fields to be present.

Thanks for pointing this out.  I've removed this requirement to give profiles full freedom of how to identify the presenter.

Section 3.1 - The first two sentences seems to be slightly contradictory - the first says the cnf claim is used to identify the POP key.  The second states that it may have something other than a POP key in it.

It's really about saying that "confirmation" is broader than "confirmation-by-PoP".  This draft covers the latter, but defines the "cnf" claim to enable the broader uses, as in SAML 2.0.  I'll think about how to word this more clearly.

Section 3.1 - I am not a fan of MUST ignore statements at this level.  It should be  profile statement if anything.

The "MUST be ignored" is essential for future extensibility.  Otherwise, anything new added breaks everything already deployed.

Section 3.1 - last paragraph - Does this mean that only one claim can be in the cnf claim - or are some values of different levels?  For example -can I have a COSE_Key and an Kid?  This might be considered to be multiple POP keys.

As long as the "kid" refers to the same key, you're golden.  I think it already says that somewhere, but I'll look into it further.

Section 3.2 - Profiles can require that additional elements can be required in the COSE_Key element - and example would be to require that the algorithm identifier be present.

That's fine.  The spec already says that other key elements can be included.

Section 3.2 - I do not understand why this paragraph is doing in this section give the section title.  Why is it not in section 3.3 or in a separate section.  I think it makes mores sense at the end of the next section.

Public keys are represented in the clear.  That's different than the symmetric keys in 3.3, which have to be encrypted to prevent them from being revealed.

Section 3.3 - Why is title not symmetric with section 3.2 and the word encrypted be absent?

See the previous reply

Section 3.4 - This section just makes me uncomfortable.  Use a value that was potentially chosen for collisions does not seem to be a good idea.  I think this really needs some additional guidance about using.

If both parties already have the key, using a Key ID rather than transmitting the key is an optimization that is used in practice.  What else would you like us to say about this?

Section 4 - Is there any reason to suppose that the use of asymmetric secrets are immune from replay attacks?

Is there particular Security Considerations text that you'd like to see included about this?

Section 3.1 - para 1 -sentence #2  -  I do not understand the implication that the POP key implies the authenticity of the token.  That statement makes no sense to me.  This would look  like a self-signed certificate as the authentication point.

See the SAML 2.0 comment earlier.

Jim

I plan to publish an updated version in the next day or so, after giving the authors of draft-ietf-ace-oauth-authz a chance to look it over.

                                                                Thanks again,

                                                                -- Mike