Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Benjamin Kaduk]

I want to double-check that I'm understanding you correctly.

The idea is that there's ambiguity about how a CWT 'cnf' claim would get
represented as "equivalent" JWT, and that it may not even be possible for
some 'cnf' values?  I'm not entirely sure what the path forward even looks
like, and thus am inclined to believe that I should request an IESG hold on
the publication of draft-ietf-ace-cwt-proof-of-possession.

Is that right?

Thanks,

Ben

On Mon, Jan 20, 2020 at 01:12:08PM -0800, Jim Schaad wrote:
> I started doing testing of my code and I have started to run into some 
> massive problems with the confirmation claim.The COSE version of the POP 
> key registrations cause a problem because of the way the registration 
> template in the document is written.  It currently says:
> 
>  
> 
> JWT Confirmation Method Name:
> 
>  
> 
> Claim Name of the equivalent JWT confirmation method value, as
> 
> registered in [IANA.JWT.Claims 
> 
>  ].  CWT claims should normally have
> 
> a corresponding JWT claim.  If a corresponding JWT claim would not
> 
> make sense, the Designated Experts can choose to accept
> 
> registrations for which the JWT Claim Name is listed as "N/A".
> 
>  
> 
> The issue here is the word “equivalent”.  There are two possible 
> interpretations of this:  That this is a similar item in terms of how things 
> are used, but there is no way to encode this item into a JWT.  Or, that this 
> is how one should encode this item in a JWT.  The first interpretation 
> implies that even though one would like to pass a COSE_Key confirmation in a 
> JWT there is no way to do this.  (Yes, one can potentially convert the COSE 
> Key into a JOSE Key but that is not always going to succeed as some keys in 
> one system may not be representable in the other system.) The second 
> interpretation says that you just encode the COSE_Key as JSON and put it into 
> the map with the ”jwk” key and you are happy.  Which of course will not work.
> 
>  
> 
> I had misled myself in the message below as I had missed reading the JWT 
> Confirmation Method Name field in the registration templates.   If you look 
> at the text below, it is hard to know if “COSE_Key” is to be used in a JSON 
> structure (which I had originally assumed) or if “jwk” is supposed to be used 
> in a JSON structure.
> 
>  
> 
>o  Confirmation Method Name: "COSE_Key"
>o  Confirmation Method Description: COSE_Key Representing Public Key
>o  JWT Confirmation Method Name: "jwk"
>o  Confirmation Key: 1
>o  Confirmation Value Type(s): COSE_Key structure
>o  Change Controller: IESG
>o  Specification Document(s): Section 3.2 
> 
>   of [[ this document ]]
> 
>  
> 
> At a minimum we should probably clarify the language on this.  And I need to 
> look at the COSE documents and decode if there needs to be some text on 
> encoding in a JSON environment or not.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> From: Ace  On Behalf Of Jim Schaad
> Sent: Sunday, January 19, 2020 3:35 PM
> To: 'Brian Campbell' ; 'Seitz Ludwig' 
> 
> Cc: 'Roman Danyliw' ; oauth-ext-rev...@ietf.org; 'Daniel 
> Migault' ; drafts-lastc...@iana.org; 'Ludwig 
> Seitz' ; 'Benjamin Kaduk' ; ace@ietf.org
> Subject: Re: [Ace] Requested review for IANA registration in 
> draft-ietf-ace-oauth-params
> 
>  
> 
> I have managed to merge most of my code that deals with the confirmation 
> claim and I have ended up with a single problem when dealing with 
> confirmations.  If this is going to get fixed, it needs to get fixed in 
> draft-ietf-ace-cwt-proof-of-possession prior to this document finishing 
> processing the EDIT process in the RFC editor.
> 
>  
> 
> All of the items that can appear in a confirmation claim are unique except 
> for the ‘kid’ claim method.  This field is defined as being a text field for 
> JWT (RFC 7800), but it is defined as being a binary field for CWT.  It is a 
> text field when defined in RFC 7800.  I do not anticipate any issues for the 
> definition of a thumbprint as COSE is using a very different format for the 
> definition of thumbprints which will led to a different naming convention.
> 
>  
> 
> Jim
> 
>  
> 
>  
> 
>  
> 
> From: Brian Campbell   > 
> Sent: Monday, January 13, 2020 10:01 AM
> To: Seitz Ludwig   >
> Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de> >; Roman 
> Danyliw mailto:r...@cert.org> >; oauth-ext-rev...@ietf.org 
>  ; Daniel Migault 
> mailto:daniel.miga...@ericsson.com> >; Jim 
> Schaad mailto:i...@augustcellars.com> >; Benjamin 
> Kaduk mailto:ka...@mit.edu> >; ace@ietf.org 
>  ; drafts-lastc...@iana.org 
>  
> Subject: Re: [Ace] Requested review for IANA registration in 
> 

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Benjamin Kaduk]

Thanks for putting the effort in, Brian.

IANA, do you need to assign a new expert to reviewi the JWT Claims
registration request from this document, or are the experts expected to be
self-organizing here?

Thanks,

Ben

On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote:
> Apologies, I forgot to reply-all at some earlier point and dropped the
> mailing lists and other cc's off the thread. Added back now.
> 
> And also apologies because I think I need to recuse myself from the DE
> responsibility on the JWT registry request here. I've spent more time than
> I'd like to admit or really have to spare on it and am still struggling to
> understand.
> 
> I appreciate you pointing out the authz-info endpoint in ACE but I still
> don't follow how "rs_cnf" in an access token would really work in practice.
> The client sends the token to the RS's authz-info endpoint on an insecure
> connection or one that has the server auth with potentially different key
> and the RS stores the access token for later use. Then on resource access
> the RS looks up the access token (with respect to the cnf key in it) based
> on the key the client used in establishing a new mutually authentication
> connection to the RS. For the RS to choose a key for server it will use
> during the handshake (and as far as I know the server key is the first in
> the authn process of the handshake) based on the "rs_cnf" in the access
> token, it needs to remember and associate that client and the access token
> with something else (IP address?) that will be available during the
> handshake. It doesn't fit together for me in a way that seems likely to
> work or be interoperable but, like I said, I'm really struggling to
> understand.
> 
> On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig 
> wrote:
> 
> > Hi Brian,
> >
> >
> >
> > Comments inline.
> >
> >
> >
> > /Ludwig
> >
> >
> >
> > *From:* Brian Campbell 
> > *Sent:* den 13 januari 2020 21:22
> > *To:* Seitz Ludwig 
> > *Subject:* Re: [Ace] Requested review for IANA registration in
> > draft-ietf-ace-oauth-params
> >
> >
> >
> > Thanks for the response and updates Ludwig,
> >
> >
> >
> > Please bear with me while I try to wrap my head around some things.
> >
> >
> >
> > The JWT registration request for the "rs_cnf" claim points to Sec 3.3
> > 
> > saying it is "a hint [in the access token] to the RS about which key it
> > should use to authenticate towards the client".  But doesn't the client
> > have to go through the DTLS/TLS handshake with the RS (which is presumably
> > when it authenticates to the client) before it presents the access token?
> > I'm not seeing how this would work as seems the RS won't see the hint until
> > after it needs it.
> >
> >
> >
> >
> >
> > [LS] Not in the ACE flow. We use the access token to establish keys at the
> > RS both for the client and the RS. We have therefore defined a new
> > ACE-OAuth endpoint (authz-info) at the RS. The client can POST access
> > tokens to this endpoint without prior authentication.
> >
> > At that point, the RS only validates the signature/MAC by the AS.
> >
> >
> >
> > Later at the time of access, the corresponding token is linked to the
> > access request via the pop-mechanism and the client/access specific parts
> > are validated (e.g. scope, subject).
> >
> >
> >
> > Hope that clarifies things a bit.
> >
> >
> >
> > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig 
> > wrote:
> >
> > Hello again Brian,
> >
> >
> >
> > Thank you for reviewing this! Indeed the handling of JWT/JSON interactions
> > was handled sloppily here. I will soon issue a draft update that specifies
> > that the JSON-based interactions should use the syntax from RFC7800 while
> > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession.
> >
> >
> >
> > This correction goes for all the use of “cnf”, “req_cnf” and “rs_cnf”.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Ludwig
> >
> >
> >
> > *From:* Ace  *On Behalf Of *Brian Campbell
> > *Sent:* den 10 januari 2020 22:12
> > *To:* Ludwig Seitz 
> > *Cc:* Roman Danyliw ; jwt-reg-rev...@ietf.org; Jim Schaad <
> > i...@augustcellars.com>; The IESG ; ace@ietf.org;
> > drafts-lastc...@iana.org; Benjamin Kaduk 
> > *Subject:* Re: [Ace] Requested review for IANA registration in
> > draft-ietf-ace-oauth-params
> >
> >
> >
> > That  "rs_cnf" claim registration request in 9.1 points to 3.3 which says
> > it has 'the same syntax and semantics as defined in for the "rs_cnf"
> > parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" values
> > 'follow the syntax of the "cnf" claim from section 3.1 of
> > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments I've
> > made today, I don't follow what that would mean for the value of the claim
> > when it's a JWT. And that seems like something that's important to
> > understand for the purpose of a JWT claims registry request.
> >
> >
> >
> >
> >
> > On Sat, Dec 21, 2019 at 

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Jim Schaad]

I started doing testing of my code and I have started to run into some massive 
problems with the confirmation claim.The COSE version of the POP key 
registrations cause a problem because of the way the registration template in 
the document is written.  It currently says:

 

JWT Confirmation Method Name:

 

Claim Name of the equivalent JWT confirmation method value, as

registered in [IANA.JWT.Claims 

 ].  CWT claims should normally have

a corresponding JWT claim.  If a corresponding JWT claim would not

make sense, the Designated Experts can choose to accept

registrations for which the JWT Claim Name is listed as "N/A".

 

The issue here is the word “equivalent”.  There are two possible 
interpretations of this:  That this is a similar item in terms of how things 
are used, but there is no way to encode this item into a JWT.  Or, that this is 
how one should encode this item in a JWT.  The first interpretation implies 
that even though one would like to pass a COSE_Key confirmation in a JWT there 
is no way to do this.  (Yes, one can potentially convert the COSE Key into a 
JOSE Key but that is not always going to succeed as some keys in one system may 
not be representable in the other system.) The second interpretation says that 
you just encode the COSE_Key as JSON and put it into the map with the ”jwk” key 
and you are happy.  Which of course will not work.

 

I had misled myself in the message below as I had missed reading the JWT 
Confirmation Method Name field in the registration templates.   If you look at 
the text below, it is hard to know if “COSE_Key” is to be used in a JSON 
structure (which I had originally assumed) or if “jwk” is supposed to be used 
in a JSON structure.

 

   o  Confirmation Method Name: "COSE_Key"
   o  Confirmation Method Description: COSE_Key Representing Public Key
   o  JWT Confirmation Method Name: "jwk"
   o  Confirmation Key: 1
   o  Confirmation Value Type(s): COSE_Key structure
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.2 

  of [[ this document ]]

 

At a minimum we should probably clarify the language on this.  And I need to 
look at the COSE documents and decode if there needs to be some text on 
encoding in a JSON environment or not.

 

Jim

 

 

From: Ace  On Behalf Of Jim Schaad
Sent: Sunday, January 19, 2020 3:35 PM
To: 'Brian Campbell' ; 'Seitz Ludwig' 

Cc: 'Roman Danyliw' ; oauth-ext-rev...@ietf.org; 'Daniel 
Migault' ; drafts-lastc...@iana.org; 'Ludwig 
Seitz' ; 'Benjamin Kaduk' ; ace@ietf.org
Subject: Re: [Ace] Requested review for IANA registration in 
draft-ietf-ace-oauth-params

 

I have managed to merge most of my code that deals with the confirmation claim 
and I have ended up with a single problem when dealing with confirmations.  If 
this is going to get fixed, it needs to get fixed in 
draft-ietf-ace-cwt-proof-of-possession prior to this document finishing 
processing the EDIT process in the RFC editor.

 

All of the items that can appear in a confirmation claim are unique except for 
the ‘kid’ claim method.  This field is defined as being a text field for JWT 
(RFC 7800), but it is defined as being a binary field for CWT.  It is a text 
field when defined in RFC 7800.  I do not anticipate any issues for the 
definition of a thumbprint as COSE is using a very different format for the 
definition of thumbprints which will led to a different naming convention.

 

Jim

 

 

 

From: Brian Campbell mailto:bcampb...@pingidentity.com> > 
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig mailto:ludwig.se...@combitech.se> >
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de> >; Roman 
Danyliw mailto:r...@cert.org> >; oauth-ext-rev...@ietf.org 
 ; Daniel Migault 
mailto:daniel.miga...@ericsson.com> >; Jim Schaad 
mailto:i...@augustcellars.com> >; Benjamin Kaduk 
mailto:ka...@mit.edu> >; ace@ietf.org  ; 
drafts-lastc...@iana.org  
Subject: Re: [Ace] Requested review for IANA registration in 
draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig mailto:ludwig.se...@combitech.se> > wrote:

[snip] 

 

From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Brian Campbell

 

[snip]

   

So in -09 the "cnf" Introspection Response Parameter was the following the 
syntax of the "cnf" claim from PoP Key Semantics for CWTs 
[ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of 
PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] 
reference. I think I understand that the two PoP key semantics documents are 
conceptually the same or similar. But I don't know that the syntax is the same? 
Figure 5 

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Brian Campbell]

Apologies, I forgot to reply-all at some earlier point and dropped the
mailing lists and other cc's off the thread. Added back now.

And also apologies because I think I need to recuse myself from the DE
responsibility on the JWT registry request here. I've spent more time than
I'd like to admit or really have to spare on it and am still struggling to
understand.

I appreciate you pointing out the authz-info endpoint in ACE but I still
don't follow how "rs_cnf" in an access token would really work in practice.
The client sends the token to the RS's authz-info endpoint on an insecure
connection or one that has the server auth with potentially different key
and the RS stores the access token for later use. Then on resource access
the RS looks up the access token (with respect to the cnf key in it) based
on the key the client used in establishing a new mutually authentication
connection to the RS. For the RS to choose a key for server it will use
during the handshake (and as far as I know the server key is the first in
the authn process of the handshake) based on the "rs_cnf" in the access
token, it needs to remember and associate that client and the access token
with something else (IP address?) that will be available during the
handshake. It doesn't fit together for me in a way that seems likely to
work or be interoperable but, like I said, I'm really struggling to
understand.

On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig 
wrote:

> Hi Brian,
>
>
>
> Comments inline.
>
>
>
> /Ludwig
>
>
>
> *From:* Brian Campbell 
> *Sent:* den 13 januari 2020 21:22
> *To:* Seitz Ludwig 
> *Subject:* Re: [Ace] Requested review for IANA registration in
> draft-ietf-ace-oauth-params
>
>
>
> Thanks for the response and updates Ludwig,
>
>
>
> Please bear with me while I try to wrap my head around some things.
>
>
>
> The JWT registration request for the "rs_cnf" claim points to Sec 3.3
> 
> saying it is "a hint [in the access token] to the RS about which key it
> should use to authenticate towards the client".  But doesn't the client
> have to go through the DTLS/TLS handshake with the RS (which is presumably
> when it authenticates to the client) before it presents the access token?
> I'm not seeing how this would work as seems the RS won't see the hint until
> after it needs it.
>
>
>
>
>
> [LS] Not in the ACE flow. We use the access token to establish keys at the
> RS both for the client and the RS. We have therefore defined a new
> ACE-OAuth endpoint (authz-info) at the RS. The client can POST access
> tokens to this endpoint without prior authentication.
>
> At that point, the RS only validates the signature/MAC by the AS.
>
>
>
> Later at the time of access, the corresponding token is linked to the
> access request via the pop-mechanism and the client/access specific parts
> are validated (e.g. scope, subject).
>
>
>
> Hope that clarifies things a bit.
>
>
>
> On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig 
> wrote:
>
> Hello again Brian,
>
>
>
> Thank you for reviewing this! Indeed the handling of JWT/JSON interactions
> was handled sloppily here. I will soon issue a draft update that specifies
> that the JSON-based interactions should use the syntax from RFC7800 while
> the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession.
>
>
>
> This correction goes for all the use of “cnf”, “req_cnf” and “rs_cnf”.
>
>
>
> Regards,
>
>
>
> Ludwig
>
>
>
> *From:* Ace  *On Behalf Of *Brian Campbell
> *Sent:* den 10 januari 2020 22:12
> *To:* Ludwig Seitz 
> *Cc:* Roman Danyliw ; jwt-reg-rev...@ietf.org; Jim Schaad <
> i...@augustcellars.com>; The IESG ; ace@ietf.org;
> drafts-lastc...@iana.org; Benjamin Kaduk 
> *Subject:* Re: [Ace] Requested review for IANA registration in
> draft-ietf-ace-oauth-params
>
>
>
> That  "rs_cnf" claim registration request in 9.1 points to 3.3 which says
> it has 'the same syntax and semantics as defined in for the "rs_cnf"
> parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" values
> 'follow the syntax of the "cnf" claim from section 3.1 of
> [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments I've
> made today, I don't follow what that would mean for the value of the claim
> when it's a JWT. And that seems like something that's important to
> understand for the purpose of a JWT claims registry request.
>
>
>
>
>
> On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz  wrote:
>
> Hello JWT registry reviewers,
>
> the IESG-designated experts for the JWT claims registry have asked me to
> send a review request to you about the "rs_cnf" claim registered here:
>
> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1
>
> Thank you in advance for you review comments.
>
> Regards,
>
> Ludwig
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential