Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad <[e-mail]>]

I have removed items where the proposed solution is probably sufficient.

> -----Original Message-----
> From: Mike Jones <[e-mail]>
> Sent: Sunday, May 20, 2018 4:34 AM
> To: Jim Schaad <[e-mail]>; draft-ietf-ace-cwt-proof-of-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> Thanks for your useful comments, Jim.  Replies are inline below.
> 
> -----Original Message-----
> From: Jim Schaad <[e-mail]>
> Sent: Wednesday, May 9, 2018 6:51 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> I'll pull out the list of comments that I wrote a month ago but didn't
start that
> computer up recently.
> 
> 1.  Are all of the authors necessary?  As a chair I need to justify a
count of
> more than 5 to the IESG.
> 
> The authors are the union of the set of authors of draft-jones-ace-cwt-
> proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both
> contained independently developed and largely parallel treatments of the
> CWT PoP confirmation subject.  Ludwig was the primary author of this text
in
> the second, so he should definitely be retained as an editor.  I'll leave
it up to
> the other authors of draft-ietf-ace-oauth-authz-04 to self-identify
whether
> they materially contributed to the CWT PoP confirmation text or not.
Maybe
> we can delete those who don't self-identify as contributors.
> 
> 4.  Terminology: I still think this is 'Presenter' is a very strange term
to use for
> this definition.  I would really like to see it be made something that
makes
> sense and then say the term is the same as this in JWT.  The term has a
> model of use with it that I do not believe can be sustained even for the
ACE
> Oauth case but really not in other cases.
> 
> This is the standard term for this role in the industry.  For instance,
Section
> 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version
1.0"
> http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key-
> cd-01.pdf defines "Presenter" with an equivalent meaning.
> 
> Also, for this reason, this is the same terminology used for this role in
RFC
> 7800.  It is used pervasively throughout both this document and RFC 7800 -
> including in the diagrams in the introduction of RFC 7800.  I believe we
would
> be doing a disservice to readers and implementers if we were to use a
> different term from that in RFC 7800 (and SAML) when the meaning is
> identical.
> 
> 5.  Terminology: Recipient matches presenter, and it matches the OAuth
> model
> and not a trust model world.   Relying party or service provider make far
> more sense to me.
> 
> Same response as to 4.  We owe it to readers and implementers to keep the
> terminology consistent with RFC 7800 and industry practice.
> 
> 6.  Under what circumstances would a 'sub' claim be present and it is not
the
> presenter?  I can see that a holder of the key may be implicitly (or
> anonymously) named, but putting something in the subject field which is
not
> identifying the presenter is something that I would reject without a good
> presentation of why in the document.
> 
> Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which
is
> in the hands of the RFC Editor), it's dependent upon the profiling
> specification how the "sub" claim is used.  In some cases the subject
and/or
> presenter will be identified with some combination of "iss" and/or "sub".
In
> other profiles, different representations will be appropriate, such as the
use
> of the "subject_type" value in the RISC example in
> https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4.
> 
> Remember that in both JWT and CWT, the inclusion of *all* claims is left
up
> to the profile.  The same is true of RFC 7800 and this spec (other than
the use
> of the "cnf" claim).  We shouldn't tie the hands of profiles in a way that
> prevents them from using the representation of the presenter that is most
> natural for their use case.

I think you have done a good job of arguing my case that this is something
that should be removed.  If it is appropriate to a specific profile then
that should be stated in that profile and not in the general document.

> 
> 7.  I would disagree with the claim that if the 'sub' claim is missing
then it
> would normally be the issuer.  For the world of IoT, I would expect that
the
> subject would not be present because there is no need to identify the
> subject to the recipient.  I.e. it is an anonymous subject.
> 
> I'm fine adding language saying that in some use cases, such IoT use
cases,
> explicit identification of the presenter may not be necessary because in
> some cases, the recipient already implicitly has this information.  And I
can
> drop the "normally" language about "iss" and instead tone it down to talk
> about "in some use cases".

Again - this seems like a statement that should be made in a profile and not
in this document.  If you have some cases where this is true then it would
make sense to at least point to them because this seems to be completely
unsupported as a general rule.  One also has problems about why self-signed
statements should not be very explicitly stated as such given that the type
of trust to be placed in this may be significantly different.

> 
> 8.  It is not clear to me that either of the sub and iss claims would
normally be
> present.  They might be present but neither is needed.  The subject can be
> anonymous and the issuer is identified by the key used to validate the
> security on the CWT.
> 
> Per my response to 7, I can replace the "normally" language with "in some
> use cases" language, so the spec isn't presuming what "normal" usage is.
> This should be up to the profiles.

While that is better, it makes more sense to me to change this into text
which says.  If this claim is not present it means X, if it is present it
means Y.  Making this paragraph be two, one each for iss and sub and then
describe what is being explicit and what is being implicit means that it is
clear what is being done with each of these.

> 
> 9.  In section 3.1 the first two sentences appear to be contradictory.
> Members are used to identify the POP key.  Other things than a POP key can
> be used than a POP key.  If they are used to identify the POP key- why
would
> they not deal with the POP key?  I think that you should do a separation
and
> define the 'cnf' file which can hold any number of confirmation methods
and
> then have a section on defining some POP cnf method field holders.
> 
> Good point.  I can revise the text to be clear that confirmation is more
> general than confirmation via PoP key and that the conformation members
> defined and registered by this spec enable confirmation using a PoP key.
> 
> 10.  In section 3.1 P1 - I am not sure why you have something here about
> confirming the authenticity of the token as oppose to confirming the
identity
> of the presenter.  Why would that type of information be placed here where
> it is not useful.
> 
> In SAML, there are plenty of non-PoP confirmation methods and RFC 7800
> (and this spec) was designed to enable a similar range of conformation
> methods to be registered and used.  For instance, SAML has an IP Address
> confirmation method.  (Yes, I understand that's of dubious value, but it's
an
> easy to understand example.)  I can update the language to say that PoP
> keys confirm the identity of the presenter, whereas other confirmation
> methods may confirm other properties.

So the paragraph should read something along the lines of:

The "cnf" claim is used in the CWT to contain the data required to confirm
that the CWT is associated to a subject.  This document defines a method and
set of data that allows for the confirmation to be done by a
proof-of-possession key.  Other documents may define other methods and the
associated data members.  The "cnf" claim is analogous to the SAML 2.0
SubjectConformation element where one or more different subject confirmation
methods can be placed.

> 
> 11.  In section 3.1 P2 - We are back to the same argument that existed for
a
> CWT in general.  Not knowing that a CWT is for a specific application
means
> that it can be used in a different application and checking that the first
> application would have done is ignored by the second one because it will
> ignore fields it does not understand.
> 
> This language is parallel to the language about understanding claims in
JWT,
> CWT, and RFC 7800, by design.  In particular, the "MUST ignore not
> understood claims" language is the key to non-breaking extensibility.
> Profiles can and will specify claim sets and validation rules for
particular CWTs,
> just as they do for particular JWTs.  See the ID Token requirements in
> http://openid.net/specs/openid-connect-core-1_0.html#IDToken and the
> corresponding validation rules in http://openid.net/specs/openid-connect-
> core-1_0.html#IDTokenValidation for an example of such a profile for JWTs.
> Profiles for CWT and CWT PoP will be similarly specific.

That is great if you want to use OR rules - this token can be used if A or B
is true.  This does not work at all if you want to use AND rules - this
token can only be used if A and B are true.  

However that is orthogonal to the issue that I have raised.  You say that
any token which has a sufficient set of fields is good for my application.
Not all profiles are designed so that as long as level 1 is fine and a
subset of level 2 that a token can be used to authorize at level 1.

> 
> 12. I am unclear why there should be a restriction on the number of POP
keys
> that can be in a 'cnf' object.  If there are multiple keys, then any or
all of them
> are of equal value in doing the confirmation.  Just like there can be
multiple
> confirmation methods and an application could choose to use any one of
> them.
> 
> You're right that this could have been specified in a way that allows
multiple
> keys in a "cnf" object but it is intended to simplify things for
implementers
> and increase interoperability to by having just one.  Also, note that if
multiple
> kinds of conformation keys are desired by a profile, the second sentence
of
> paragraph 4 of https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-
> possession-02#section-3.1 already recommends how to achieve this.


> 14.  I have real problems w/ the use of a KID for POP identification.  It
may
> identify the wrong key or, if used for granting access, may have problems
w/
> identity collisions.  These need to be spelt out someplace to help people
> tracking down questions of why can't I verify w/ this CWT, I know it's
right.
> 
> The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key
ID is
> sent that doesn't correspond to the right PoP key, failures may occur.  I
view
> that as usage bug - not a protocol problem.  If keys aren't consistently
known
> and identified by both parties, there are lots of things that can go
wrong, and
> this is only one such instance.  That said, I can try to say something
about the
> need for keys to be consistently and known by both parties, if you think
that
> would help.

My problem is that if there are two different people with the same Key ID,
either intentionally or unintentionally, then using the key ID to identify
the key may allow the other person to masquerade as the first person.  I am
unworried about the instance of a failure to get a key based on a key id.
That is not the problem you are proposing to address.

> 
> 15.  The content of 'kid' is application specific.  Where is an
application going
> to define this such that it will work more generally.  The application in
the
> case of the ACE working group boils down to the world (minus a few
things).
> 
> Sure - its content is application-specific, but per my answer to 14, what
> matters is that keys are consistently identified between both
participants.
> Provided that's true, then it really doesn't matter whether a Key ID value
is (a
> binary encoding of) "Jim's Key" or (a binary encoding of) "e762dcc3-bc8a-
> 4125-844f-e5578695c834".

No, if the trust is   CWT -> KeyID -> Key then there is a step in the middle
that has not be trusted.  CWT->Key is an atomic trust operation as it is
cryptographically validated.

> 
> 17. section 4 - this implies that POP cannot be replayed via asymmetric
keys.
> Why would this be the case?
> 
> I'm a little confused by this comment because paragraph 4 explicitly
states
> that "Proof of possession via encrypted symmetric secrets is subject to
> replay attacks".  So yes, they can be replayed, so I don't understand what
> you're commenting about or what additional explanation you'd like to see.
> 

The conclusion that I drew from this is that - you say symmetric keys have
replay attacks, but you don't say anything about asymmetric key having the
same attacks so they must not.

> 20.  Are keys big enough that it should be considered to move kid to the 2
> byte range of identifiers?
> 
> I don't see any need to do this because the "cnf" identifier space is
distinct
> from the CWT identifier space.  I really can't envision a scenario in
which
> there will ever be 64 "cnf" values (32 single-byte positive integers and
32
> single-byte negative integers).  It's a fair question, but as it see it,
doing so
> would just add a byte for no practical reason.

I don't know that this is the correct metric to be using.  A single
confirmation method could register multiple keys to be used.  After all POP
is registering 3

> 
> Jim
> 
> Thanks again for your thorough review!
> 
> 				-- Mike