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

From: Jim Schaad <[email-masked]>
Date: Sun, 22 Oct 2017 17:20:53 -0700

*  I dislike the statement of what the specification claims to do.  It will
be misread by many people who are not familiar with how you are defining the
word "presenter".  If I intercept a CWT and present it to a validator, it
does not make a claim that I possess a specific POP key.   Given what a CWT
is supposed to do, I believe that a much clearer statement of functionality
would be  "This specification describes how to associate a set of claims in
a CWT with a particular proof-of-possession key."  Among other things, this
would allow a third party to "present" a CWT on behalf of another party.
(See introspection.)

*  I dislike the way that the second sentence of the introduction is
written.  Please remove the text about the presenter, that is not relevant
to the holder-of-key assertion.

*  Section 2 - Issuer " Party that creates the CWT and binds the claims with
the POP key"

* Section 2 - The definition of "presenter" in this document is odd given
that we are looking at ways that a CWT can be transferred by a third part.
A better term would be "Holder" or "Holder of Key"

* Section 3 paragraph 1 - This paragraph is written with some things taken
for granted that I am not user exist.  1) How is the issuer doing the
declaration that a presenter possesses a key, is a POP of the key a
requirement to issue the CWT that I have not yet seen?  2) Again I don't
like the use of presenter as the key usage and transfer are not necessarily
done at the same time.

* Section 3 paragraph 2 - You need to be clearer about what you mean by
identified.  My reading would be that the presenter is identified by the POP
key.  If you want to talk about claims which contain other types of naming
material, then you need to be clear that is what you are doing.

* Section 3 paragraph 2 - I would skip most of the detail on the meanings of
the different claims and just identify the number of claims and refer to the
CWT document for details on what they mean.  The current text is not clear,
and hopefully, the CWT document is much clearer on what these mean.

* General - Where are you defining the types and contents of the claims that
are being registered in this document?  I cannot find it and I expected it
to be in section 3.1

* Section 3.1 para 1 - Based on the last sentence, I think that you need to
make some type of statement about the purpose of the "cnf" claim that
embodies both a POP key and the SAML stuff that you are adding.  What are
the requirements to be here?  What are the relationships between statements?

* Section 3.1 para 2 - It is fine to say that what the set of methods that
must be present is application dependent, however without the presence of
some type of profile identification, how is an application supposed to know
if the meanings and relationships are what are expected and not from some
other profile?

* Section 3.1 para 4 - The thus in the first sentence does not follow from
the requirement.  There is nothing that says that the same key could not be
in both the COSE_Key and Encrypted_COSE_Key fields.

* Section 3.1 para 4 - I don't understand the process defined in sentence #2
and why it is done this way.  It would make more sense to me to say that it
could be a new field with an array of cnf values.  Doing the "additional to
'cnf'" would seem to cause potential problems when this CWT is grabbed by
somebody which does not understand how these two fields are related.

*  Change the examples to use CBOR diagnostic notation.

* Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and
Encrypted_COSE_Key rather than in terms of symmetric and asymmetric keys.
Then you can properly talk about public and private keys in each of the
sections and it is tied to the structure itself rather than inferred

* Section 3.4 - I would consider this to be an unusable item for doing POP
key identification in all cases where the kid is not computed in a
cryptographic manner and the method of computation is included as part of
the kid.

* Section 3.5 - Huh?  I don't know about typically for the demonstration.
It could just as easily be done by doing an encryption/decryption operation
or a key derivation operation such as in TLS for PSK.  I don't know that
this section is providing any useful information.  If you think that it is
needed then a simple statement that you are not specifying how to do POP is
sufficient.

* Section 4 paragraph 2 - I can understand a reasoning for doing audience
restrictions, but I cannot for the life of me figure out why it would be of
greater importance for POP statements than for any other set of claims.

* Section 4 para 4 - How does a signed nonce prevent a replay attack with
encrypted symmetric secrets?

* Section 4 - I am surprised there is no statement about self-signed CWT
statements esp. as that is given as an example of how additional naming
claims would be understood

* Section 5 - Need to make  a statement about the correlation information
that a CWT issuer would have as well?

---

From: Mike Jones <[email-masked]>
Date: Sat, 28 Oct 2017 02:42:46 +0000

Thanks for the detailed review, Jim.  Replies inline...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Sunday, October 22, 2017 5:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Review of draft-ietf-ace-cwt-proof-of-possession 00

*  I dislike the statement of what the specification claims to do.  It will be misread by many people who are not familiar with how you are defining the word "presenter".  If I intercept a CWT and present it to a validator, it
does not make a claim that I possess a specific POP key.   Given what a CWT
is supposed to do, I believe that a much clearer statement of functionality would be  "This specification describes how to associate a set of claims in a CWT with a particular proof-of-possession key."  Among other things, this would allow a third party to "present" a CWT on behalf of another party.
(See introspection.)

I'll look at revising this along the lines you suggest.  The existing language, of course, is a direct adaptation of that from RFC 7800.

*  I dislike the way that the second sentence of the introduction is written.  Please remove the text about the presenter, that is not relevant to the holder-of-key assertion.

OK

*  Section 2 - Issuer " Party that creates the CWT and binds the claims with the POP key"

The proposed language suggests something that's not true - that the PoP key is used to sign the CWT, or something like that.  It's the signing key that binds the claims.

* Section 2 - The definition of "presenter" in this document is odd given that we are looking at ways that a CWT can be transferred by a third part.
A better term would be "Holder" or "Holder of Key"

I'm reluctant to undergo a wholesale change of terminology when this comes directly from the already-approved RFC 7800.  (I'm of course willing to entertain clarifications.)

* Section 3 paragraph 1 - This paragraph is written with some things taken for granted that I am not user exist.  1) How is the issuer doing the declaration that a presenter possesses a key, is a POP of the key a requirement to issue the CWT that I have not yet seen?  2) Again I don't like the use of presenter as the key usage and transfer are not necessarily done at the same time.

I'll think about what you're saying, but "presenter" is one of the well-defined roles in PoP interactions.  You seem to not like the term, but it's the one in common use.

* Section 3 paragraph 2 - You need to be clearer about what you mean by identified.  My reading would be that the presenter is identified by the POP key.  If you want to talk about claims which contain other types of naming material, then you need to be clear that is what you are doing.

OK - I'll give the claims wording suggestion a shot.

* Section 3 paragraph 2 - I would skip most of the detail on the meanings of the different claims and just identify the number of claims and refer to the CWT document for details on what they mean.  The current text is not clear, and hopefully, the CWT document is much clearer on what these mean.

I'll try to strike a balance between incorporating this suggestion for additional clarity and maintaining the spirit of the RFC 7800 language.  (If we deviate very much, people will rightly ask the question "Why does this have a different meaning than the corresponding RFC 7800 text?")

* General - Where are you defining the types and contents of the claims that are being registered in this document?  I cannot find it and I expected it to be in section 3.1

I agree more needs to be done in this regard.  The current text relies too much on things that were implicit in JSON, rather than explicitly defining the CBOR types.

* Section 3.1 para 1 - Based on the last sentence, I think that you need to make some type of statement about the purpose of the "cnf" claim that embodies both a POP key and the SAML stuff that you are adding.  What are the requirements to be here?  What are the relationships between statements?

It's not adding SAML stuff.  It's making an analogy to a SAML feature.  I'll try to make this clearer.

* Section 3.1 para 2 - It is fine to say that what the set of methods that must be present is application dependent, however without the presence of some type of profile identification, how is an application supposed to know if the meanings and relationships are what are expected and not from some other profile?

The values are always processed and validated within the context of the application profile.  No identifier is needed to tell the application what its validation rules are.

* Section 3.1 para 4 - The thus in the first sentence does not follow from the requirement.  There is nothing that says that the same key could not be in both the COSE_Key and Encrypted_COSE_Key fields.

I suppose that's true but why would an application do or want both unencrypted and encrypted representations of the same content?  Requiring them to be mutually exclusive simplifies applications, it seems to me.

* Section 3.1 para 4 - I don't understand the process defined in sentence #2 and why it is done this way.  It would make more sense to me to say that it could be a new field with an array of cnf values.  Doing the "additional to 'cnf'" would seem to cause potential problems when this CWT is grabbed by somebody which does not understand how these two fields are related.

OK - I'll try to make this clearer.

-01 will do that, thanks to Ludwig!

* Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and Encrypted_COSE_Key rather than in terms of symmetric and asymmetric keys.
Then you can properly talk about public and private keys in each of the sections and it is tied to the structure itself rather than inferred

Again, unless the text is wrong or unclear, we plan to leave most descriptions parallel to those in RFC 7800.  Your suggestion would be a rewrite.

* Section 3.4 - I would consider this to be an unusable item for doing POP key identification in all cases where the kid is not computed in a cryptographic manner and the method of computation is included as part of the kid.

If the key ID doesn't match, the worst that will happen is the PoP verification will fail.  This is analogous to why it's ok for the Key ID to be in an unprotected header in COSE.

* Section 3.5 - Huh?  I don't know about typically for the demonstration.
It could just as easily be done by doing an encryption/decryption operation or a key derivation operation such as in TLS for PSK.  I don't know that this section is providing any useful information.  If you think that it is needed then a simple statement that you are not specifying how to do POP is sufficient.

If you want to supply some additional text about these other methods, that would be welcomed.

* Section 4 paragraph 2 - I can understand a reasoning for doing audience restrictions, but I cannot for the life of me figure out why it would be of greater importance for POP statements than for any other set of claims.

It's not more important, nor does it say that it is.  But in the RFC 7800 last call process, several people wanted us to add this security consideration.

* Section 4 para 4 - How does a signed nonce prevent a replay attack with encrypted symmetric secrets?

Because a different nonce would be required to be used for each CWT using the PoP key.  I'll try to clarify this.

* Section 4 - I am surprised there is no statement about self-signed CWT statements esp. as that is given as an example of how additional naming claims would be understood

What would you like the statement to say?

* Section 5 - Need to make  a statement about the correlation information that a CWT issuer would have as well?

The issuer is aware of all the audiences that it is issuing CWTs for.  Is that what you were getting after?

====

Thanks again for the thorough review, as always!  Stay tuned for -01...

				-- Mike

---

From: Jim Schaad <[email-masked]>
Date: Fri, 27 Oct 2017 20:41:11 -0700

> From: Mike Jones [mailto:[email-masked]]
> Sent: Friday, October 27, 2017 7:43 PM
> To: Jim Schaad <[email-masked]>; draft-ietf-ace-cwt-proof-of-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Review of draft-ietf-ace-cwt-proof-of-possession 00
> 
> The proposed language suggests something that's not true - that the PoP
key
> is used to sign the CWT, or something like that.  It's the signing key
that binds
> the claims.

You are right - would be better as "bind the claims to the POP Key"

> * Section 2 - The definition of "presenter" in this document is odd given
that
> we are looking at ways that a CWT can be transferred by a third part.
> I'm reluctant to undergo a wholesale change of terminology when this comes
> directly from the already-approved RFC 7800.  (I'm of course willing to
> entertain clarifications.)

I'll think about a response.

> * Section 3.1 para 4 - The thus in the first sentence does not follow from
the
> requirement.  There is nothing that says that the same key could not be in
> both the COSE_Key and Encrypted_COSE_Key fields.
> 
> I suppose that's true but why would an application do or want both
> unencrypted and encrypted representations of the same content?  Requiring
> them to be mutually exclusive simplifies applications, it seems to me.

I am not objecting to the mutual exclusivity of the field.  The rational
needs to be appropriate

> Again, unless the text is wrong or unclear, we plan to leave most
descriptions
> parallel to those in RFC 7800.  Your suggestion would be a rewrite.

In my opinion, it is poorly written and confusing as to what is being
accomplished and what the fields are.  Reordering in this way would make it
clear where currently it is not.  Copying unclear text is generally not
useful.

> * Section 3.4 - I would consider this to be an unusable item for doing POP
key
> identification in all cases where the kid is not computed in a
cryptographic
> manner and the method of computation is included as part of the kid.
> 
> If the key ID doesn't match, the worst that will happen is the PoP
verification
> will fail.  This is analogous to why it's ok for the Key ID to be in an
unprotected
> header in COSE.

In the case of COSE, if you identify the wrong key then it would not
validate.  In this case if you have two different keys that had been
presented to you with the same Key ID value and two different keys, when you
get the CWT you do not know which of two keys is the POP key and which is
not.  The cases are not analogous.

> or a key derivation operation such as in TLS for PSK.  I don't know that
this
> section is providing any useful information.  If you think that it is
needed then
> a simple statement that you are not specifying how to do POP is
sufficient.
> If you want to supply some additional text about these other methods, that

I'll try and remember to look at this.  If I don't have anything by the F2F
remind me.

> It's not more important, nor does it say that it is.  But in the RFC 7800
last call
> process, several people wanted us to add this security consideration.

I'll re-read.

> What would you like the statement to say?  

Something along the lines of it is only as good as the original trust in
that person.  Self-asserted statements are always suspect.

> The issuer is aware of all the audiences that it is issuing CWTs for.  Is
that
> what you were getting after?

No, I was thinking that a CWT issuer would know all of the
audiences/permissions that a client is asking for using the same
authentication key to the CWT even if the keys used to the servers are
different.