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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Hannes Tschofenig <[e-mail]>
> Sent: Wednesday, May 23, 2018 12:55 PM
> 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
> 
> Hi Jim,
> 
> A few remarks below.
> 
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: 09 May 2018 05:51
> 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.
> 
> [Hannes] As mentioned by Mike already, this was the result of a draft
> merger. The text initially came from an OAuth document (since this work
had
> its history in the OAuth WG).
> 
> 2.  Is the last sentence in section 1 necessary?  Are you actually
defining any
> strings that could be case-sensitive?
> 
> [Hannes] I think we could get rid of that sentence.
> 
> 3.  Terminology: In the definition of Issuer please make 'its' clearer.
It is not
> clear whose claims are being bound.
> 
> [Hannes] How about:
> 
>    Issuer
>       Party that creates the CWT and binds the claims to the proof-of-
>       possession key.

It's better - 'binds claims about the subject' might be clearer

> 
> 
> 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.
> 
> [Hannes] It is a strange term but we used it also in the OAuth JWT PoP
> document and hence it wouldn't make sense to change it now.

If you really cannot change the term, then it might make sense to add some
description of other terminology that others might be familiar with.

> 
> 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.
> 
> [Hannes] Same comment as above. I prefer to be in alignment with the
> OAuth work here. I am wondering whether we should also copy the figures
> from Section 1 of https://tools.ietf.org/html/rfc7800 to make the
> architecture clearer.
> 
> 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.
> 
> [Hannes] Mike provided his perspective on this issue already. CWT is
similar
> to JWT a somewhat flexible building block. What claims should, must or may
> be included in a given deployment depends a bit on the use case. Not
> including the subject claim may be useful for privacy purposes, for
example.
> In other cases you definitely want to convey that information.

I completely agree with your last sentence.  The sub would be omitted
because of privacy or not needed.  However having the subject be present and
the subject not being the presenter seems to be a very strange concept.
Here is a token issued by A where the subject is B and the key is held by C.

> 
> 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.
> 
> [Hannes] I am not sure that this is always the case in an IoT deployment.
For
> example, imagine if a technician accesses some industrial device then I
want
> to have the information about the person accessing those devices in my
> audit trail.

I could easily be wrong about the subject claim not being absent more often
that not.  However that still does not mean it would normally be about the
issuer rather than an anonymous subject.

> 
> 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.
> 
> [Hannes] In many deployments they may well not be present. That's
> completely fine. Fewer claims can sometimes be better.
> 
> 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.
> 
> [Hannes] How does this sound:
> 
> 
> Section 3.1.  Confirmation Claim
> 
> 
> FROM:
> 
>    The "cnf" claim is used in the JWT to contain members used to
>    identify the proof-of-possession key.  Other members of the "cnf"
>    object may be defined because a proof-of-possession key may not be
>    the only means of confirming the authenticity of the token.  This is
>    analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
>    SubjectConfirmation element in which a number of different subject
>    confirmation methods can be included (including proof-of-possession
>    key information).
> 
> TO:
> 
> The "cnf" claim in the JWT is used to carry confirmation methods, some of
> them use proof-of-possession keys while others do not. This design is
> analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation
> element in which a number of different subject confirmation methods can
> be included (including proof-of-possession key information).

s/JWT/CWT/

otherwise it looks better.

> 
> 
> 
> 
> 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.
> 
> [Hannes] I believe this part would be clarified with my wording change to
> Section 3.1 as proposed in #9.

I'd want to see an updated version to know if that is true.

> 
> 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.
> 
> [Hannes] Mike provided a detailed response to this item already.
> 
> 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.
> 
> [Hannes] I believe we should not place such a restriction in there. A
profile
> should place restrictions on the number of allowed "cnf" claims there.
> Changing the names of the claims, as a proposed alternative to get around
> this limit, appears a bit problematic since we have to register them in
the
> IANA registry.
> Hence, my proposal is to change the text
> 
> FROM:
> 
>   The "cnf" claim value MUST represent only a single proof-of-
>    possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK
>    Set URL) confirmation values defined below may be present.  Note that
>    if an application needs to represent multiple proof-of-possession
>    keys in the same JWT, one way for it to achieve this is to use other
>    claim names, in addition to "cnf", to hold the additional proof-of-
>    possession key information.
> 
> TO:
> 
>   The "cnf" claim value may contain one or multiple proof-of-
>    possession keys. Hence, more than one "jwk", "jwe", and/or "jku" (JWK
>    Set URL) confirmation values  may be present in a CWT.  A profile may
> impose
>    further restrictions on the number of PoP keys that are present and
>    also whether all or a only a subset of them needs to be utilized by in
>    a given application domain.

That would be my preference.  I don't know how often it would be used but it
seems to be a better idea for some longer term CWTs

Jim

> 
> 
> ~~~snip  ~~~
> 
> I will respond to the other questions in a second email; ran out of time.
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.