Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Nov 2015 12:44:07 -0500

Hi,

Thank you all for your work on this draft!  I just have a few questions:

1. Security considerations section says:

"All of the normal security issues, especially in relationship to
   comparing URIs and dealing with unrecognized values, that are
   discussed in JWT [JWT] also apply here."

I find that to be odd phrasing that would likely be picked up in
subsequent reviews.  Please remove the word "normal" so that all of
the security issues discusses in JWT are included.  Are there other
'normal considerations in addition to those in JWT that need to be
listed?  The phrasing reads as if that may the case and would be
better to include them all or pointers or change the phrasing.

2. Also in the security considerations section,

   "A recipient may not understand the newly introduced "cnf" claim and
   may consequently treat it as a bearer token."

What is the proper handling requirement when an unknown claim is
present?  Section 3.1 says:
  "When a recipient receives a "cnf" claim with a
   member that it does not understand, it MUST ignore that member."

Is this why it is treated as a bearer token rather than being
rejected?  Is this really the action you want to see with cnf?  Why
isn't there an error and a resend as a bearer token so that parties
understand (or have an opportunity to understand) that there were
issues?

Then the following text in the security section says:
  "While this is a
   legitimate concern, it is outside the scope of this specification,
   since demonstration the possession of the key associated with the
   "cnf" claim is not covered by this specification. For more details,

How is this outside of the scope of this draft?  cnf is defined in
this draft, so handling should be covered in this draft.  A pointer to
the POP architecture draft is not helpful as it is not defined there,
it's covered int his draft.  Should this text just be removed and
replaced with more explicit handling information int he body of this
draft?

Thanks!

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Nov 2015 13:48:13 -0500

I suggest removal of the reference to bearer tokens in this section, since that seems to suggest that this is what the RS should do in such a case. What’s really going to happen is that an RS is going to get a request with this token and it’s going to have to figure out how to deal with it. If there’s a signature (like in http-message-signing) then it’s going to need to find the key. If it can’t read the key out of the cnf claim then it won’t be able to validate the signature and won’t process the message. If that’s the case then this RS can’t accept this token. 

This has nothing to do with bearer tokens vs. PoP tokens. It’s not really any different from an RS accepting JWT bearer tokens needing to be able to parse or process the JWT bearer token to figure out what it’s good for. Right?

 — Justin

> On Nov 24, 2015, at 12:44 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Nov 2015 20:42:26 -0500

Thanks for a quick reply, Justin.

> I suggest removal of the reference to bearer tokens in this section, since that seems to suggest that this is what the RS should do in such a case. What’s really going to happen is that an RS is go…

If this is the case, handling text would be helpful in the draft.

> This has nothing to do with bearer tokens vs. PoP tokens. It’s not really any different from an RS accepting JWT bearer tokens needing to be able to parse or process the JWT bearer token to figure…

If this is the case, new text would be helpful, it's a little
confusing as-is and I would assume what you assume above too.

Hopefully, new text is a simple fix as I'd like to start IETF last
call soon on this and the architecture draft (as in this week soon).

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 02:10:06 +0000

Thanks for your review comments, Kathleen.  Responses are inline below...

> -----Original Message-----
> From: OAuth [mailto:[email-masked]] On Behalf Of Kathleen
> Moriarty
> Sent: Tuesday, November 24, 2015 9:44 AM
> To: [email-masked]
> Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession
> 
> Hi,
> 
> I find that to be odd phrasing that would likely be picked up in subsequent
> reviews.  Please remove the word "normal" so that all of the security issues
> discusses in JWT are included.  Are there other 'normal considerations in
> addition to those in JWT that need to be listed?  The phrasing reads as if that
> may the case and would be better to include them all or pointers or change
> the phrasing.

You're right.  I removed this awkward wording.

> Is this why it is treated as a bearer token rather than being rejected?  Is this
> really the action you want to see with cnf?  Why isn't there an error and a
> resend as a bearer token so that parties understand (or have an opportunity
> to understand) that there were issues?
> 
> How is this outside of the scope of this draft?  cnf is defined in this draft, so
> handling should be covered in this draft.  A pointer to the POP architecture
> draft is not helpful as it is not defined there, it's covered int his draft.  Should
> this text just be removed and replaced with more explicit handling
> information int he body of this draft?

Good catch.  JWT [RFC 7519] Section 4 says that claims that are not understood must be ignored unless otherwise specified by the application.  This allows new claims to be dynamically added without breaking existing applications.  For the same reason, I have incorporated this language about understanding claims from 7519, but having it be about understanding confirmation members.  Ultimately, what features must be implemented are always up to the application, just as with JWT claims.

> Thanks!

				Thanks again,
				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 02:10:45 +0000

Thanks Justin.  Upon rereading this section with Kathleen's and your comments in mind, I removed all the text that you were objecting to and replaced it with the new last paragraph of the security considerations section, which makes the point that ultimately, what features must be implemented are always up to the application, just as with JWT claims.

				Thanks again,
				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, November 24, 2015 10:48 AM
To: Kathleen Moriarty <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

 — Justin

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Nov 2015 21:41:19 -0500

Hi Mike,

Thanks for the quick turn-around.  Just one more comment on my comments.

> Good catch.  JWT [RFC 7519] Section 4 says that claims that are not understood must be ignored unless otherwise specified by the application.  This allows new claims to be dynamically added without…

The new text in Section 3.1 looks good.  I'm not sure why the word
"typically" appears int he new text of the security considerations
section though after reading the new text in 3.1.  Wouldn't it just be
ignored since 3.1 now says:

   "However, in the absence of such requirements,
    all confirmation members that are not understood by implementations
    MUST be ignored."

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 03:10:42 +0000

Fair question about the use of "typically".  The reason it's there is that this language in JWT [RFC 7519] Section 4 does permit applications to require that JWTs with not-understood claims be rejected, rather than ignored, even though that's not the default behavior:

   The set of claims that a JWT must contain to be considered valid is
   context dependent and is outside the scope of this specification.
   Specific applications of JWTs will require implementations to
   understand and process some claims in particular ways.  However, in
   the absence of such requirements, all claims that are not understood
   by implementations MUST be ignored.

So when not understood, "cnf" would typically be ignored, but might not be.

				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2015 6:41 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

Hi Mike,

On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones <[email-masked]> wrote:
>> understand (or have an opportunity to understand) that there were issues?
>>
>> this draft, so handling should be covered in this draft.  A pointer 
>> to the POP architecture draft is not helpful as it is not defined 
>> there, it's covered int his draft.  Should this text just be removed 
>> and replaced with more explicit handling information int he body of this draft?
>

The new text in Section 3.1 looks good.  I'm not sure why the word "typically" appears int he new text of the security considerations section though after reading the new text in 3.1.  Wouldn't it just be ignored since 3.1 now says:

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Nov 2015 22:14:10 -0500

> So when not understood, "cnf" would typically be ignored, but might not be.

I find that confusing and am now thinking this came up in a discuss as
well during the review for 7519, didn't it?  Can you elaborate int eh
security considerations section a bit more, otherwise this text
appears to be conflicting and even with what you intend, it's
confusing for implementers and will lead to issues with
interoperability.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 03:25:48 +0000

Rather than elaborating, having looked at the text we're discussing again, I'm going to counter-propose that we instead simplify - sticking only to the point that the paragraph is intending to get across.  Would it work for you to simplify the current text:

    "A recipient might not understand the cnf claim, in which case it will typically be ignored. Unless this is acceptable behavior, applications that need the proof-of-possession keys communicated with it to be understood and processed must require that the parts of this specification that they use be implemented."

to this simpler text?

    "A recipient might not understand the cnf claim.  Applications that need the proof-of-possession keys communicated with it to be understood and processed must require that the parts of this specification that they use be implemented."

The "must ignore" topic is already addressed in the second paragraph of 3.1 (and with exactly the semantics as the rest of JWT), and so doesn't have to be re-raised here, as it currently is.  Re-raising it is clearly a point of distraction.

For what it's worth, I don't remember any DISCUSSes on this topic (although it's possible that your memory is better than mine on this point).

				Best wishes,
				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2015 7:14 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

> So when not understood, "cnf" would typically be ignored, but might not be.

I find that confusing and am now thinking this came up in a discuss as well during the review for 7519, didn't it?  Can you elaborate int eh security considerations section a bit more, otherwise this text appears to be conflicting and even with what you intend, it's confusing for implementers and will lead to issues with interoperability.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Nov 2015 09:21:16 -0500

Hi Mike,

If the working group is okay with the current text, leave it.  What you proposed is exactly the same as what is there.  I'll note this point in my ballot as I think you are leaving ambiguity that is not necessary.

After getting far enough on this, I think it was Pete who discussed this with you and he gave up and remained in disagreement.

Regards,
Kathleen 

Sent from my iPhone

> On Nov 24, 2015, at 10:25 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 19:26:21 +0000

Hi Kathleen,

For what it's worth, Pete's ballot on JWT - recorded at http://datatracker.ietf.org/doc/rfc7519/ballot/#pete-resnick - consisted entirely of this comment:
	Others have said all I might say. I do not object to "joots". :-)

There were things in the JOSE specs that Pete, in the end, abstained on, but not JWT.

I think we may be talking past each other on the ambiguity that you're referring to.  Let me try again.

In normal uses of JWT, there will be a JWT library (using a JOSE library) and application-specific code that uses the resulting JWTs.  At the JWT library level, yes, stuff that's not understood will be ignored.  There's no ambiguity for JWT implementers on what to do.

But at the application level, it's entirely within the application's rights to reject a JWT that contains things that don't conform to the application's specified use of JWT, including rejecting it because things were included that it didn't expect.  It's the *application* that may choose not to ignore some not-understood or not-anticipated values - not the JWT library.  That's what the second paragraph of http://tools.ietf.org/html/rfc7519#section-4 is talking about and what the equivalent second paragraph of https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-07#section-3.1 is also about.

If you feel that that point needs further clarification in the draft, I'd rather that we do that now, than have you submit a ballot that calls out the ambiguity that you're referring to, when the situation for JWT implementers is actually unambiguous.

How would you like to proceed?

				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Wednesday, November 25, 2015 6:21 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

Hi Mike,

Regards,
Kathleen 

Sent from my iPhone

>>>> there, it's covered int his draft.  Should this text just be 
>>>> removed and replaced with more explicit handling information int he body of this draft?
>>>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 18:41:50 -0300

I prefer the new wording.

However the last part could be clearer.
>  use be implemented by recipients.

Or perhaps the blunter “Recipients only understanding bearer tokens may accept JWT containing “cnf” elements if all the other required claims are valid.  It is important for security to audience restrict tokens using the JWT “aud claim.  The “cnf” claim MUST NOT be used as a pseudo audience restriction.”

Looking at the comments, I get the feeling that some people might think that cnf may restrict what endpoints can receive the token (because of the key distribution)  it only allows endpoints that should receive the token to reject ones that come from entities who don’t possess the correct confirmation.

John B.

> On Nov 25, 2015, at 12:25 AM, Mike Jones <[email-masked]> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Nov 2015 17:12:50 -0500

Thanks, John!

> Or perhaps the blunter “Recipients only understanding bearer tokens may accept JWT containing “cnf” elements if all the other required claims are valid.  It is important for security to audience re…

More explicit text like this is is more helpful in my opinion.

Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Nov 2015 20:29:27 -0500

Mike,

> There were things in the JOSE specs that Pete, in the end, abstained on, but not JWT.

I'm not going to dig through all of the discuss comments and emails to
find this one as there was huge amounts of overlapping text in each of
the drafts and continuing this type of discussion serves no purpose.

I continued from John's message as that was more productive.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Nov 2015 06:59:31 +0000

I hadn't seen this part of the thread until now.  (I thought it was part of the voluminous thread on the PoP architecture document.)

The "may accept JWT containing “cnf” elements" language sounds like it's giving applications permission to do this.  Is that the intent of the language you proposed, or were you intending something different, John?

Also, can you expand on the "pseudo audience" idea?  In what way might a proof-of-possession be confused with an audience?

				Thanks,
				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Wednesday, November 25, 2015 2:13 PM
To: John Bradley <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

Thanks, John!

Kathleen
>>>>> subsequent reviews.  Please remove the word "normal" so that all 
>>>>> of the security issues discusses in JWT are included.  Are there 
>>>>> other 'normal considerations in addition to those in JWT that need 
>>>>> to be listed?  The phrasing reads as if that may the case and 
>>>>> would be better to include them all or pointers or change the phrasing.
>>>>
>>>>> rejected?  Is this really the action you want to see with cnf?  
>>>>> Why isn't there an error and a resend as a bearer token so that 
>>>>> parties understand (or have an opportunity to understand) that there were issues?
>>>>>
>>>>> this draft, so handling should be covered in this draft.  A 
>>>>> pointer to the POP architecture draft is not helpful as it is not 
>>>>> defined there, it's covered int his draft.  Should this text just 
>>>>> be removed and replaced with more explicit handling information int he body of this draft?
>>>>

-- 

Best regards,
Kathleen

---

From: John Bradley <[email-masked]>
Date: Thu, 26 Nov 2015 09:45:17 -0300

May should perhaps be might.   This spec can’t confer or deny the ability for implementations that don’t support this extension to process JWT containing it.

I think the concern is that some people may misunderstand what cnf is doing, and think that a recipient not supporting cnf would automatically reject it.

cnf allows recipients that support confirmation methods to reject tokens not sent by entities that possess the correct confirmation material.

It is aud that restricts what  recipients can process the assertion.

So use aud to restrict the recipients, and cnf to restrict the presenters.  

A producer SHOULD restrict the valid recipients in aud to recipients that support the cnf mechanism otherwise they will not get the get the benefit of presenter restriction at the recipients that don’t support it.

The danger is that someone using cnf will assume that the token can only be used by the entity possessing the cnf material, and that is not necessarily true.
If the token is otherwise valid (correct iss, aud and sig) , and the recipient doesn’t understand cnf then a attacker who has the token might be able to use it as a bearer token at the endpoint.

This is probably too self evident to us, as we are close to the subject.

So I think that the last paragraph of 4 is mostly OK.
I think however we need to say that the way to stop endpoints that don’t support cnf from processing tokens as bearer is to not include them in the aud.  

On another point that Kathleen raised in 3.1

I think Kathleen's reading may have led her to the conclusion that if there are no members of the cnf claim that the recipient understands then the cnf claim itself MUST be ignored.
That wouldn’t be my interpretation but looking at it again, I can see how someone might read it that way.

Do we want to say that if there are no members that the recipient understands then it SHOULD be an error, or leave it up to the protocols using cnf to determine if it should be processed as a bearer token.   

In any event we don’t want people ignoring the resulting empty cnf claim.

In most cases bearer and POP tokens will be presented differently because PoP tokens need a way to present the proof, so a missing cnf element would be a clear error.

In other cases the proof might be passive.  Token Binding or source IP.  In that case a recipient might leave it up to the producer of the token to determine if it should be bound to the presenter.    

I can see an argument for saying at the token level that a JWT containing a cnf member with no understood members is malformed.

These are two separate issues.

John B.

> On Nov 26, 2015, at 3:59 AM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 1 Dec 2015 01:21:43 +0000

Thanks for the discussion, Kathleen and John, and for working on the additional security considerations wording now in the last paragraph of http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-08#section-4 about using audience restriction in combination with proof-of-possession.

				-- Mike 

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Thursday, November 26, 2015 4:45 AM
To: Mike Jones <[email-masked]>
Cc: Kathleen Moriarty <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

John B.

> I hadn't seen this part of the thread until now.  (I thought it was 
> part of the voluminous thread on the PoP architecture document.)
> 
>>>>  The set of claims that a JWT must contain to be considered valid 
>>>> is  context dependent and is outside the scope of this specification.
>>>> the absence of such requirements, all claims that are not 
>>>> understood  by implementations MUST be ignored.
>>>> 
>>>>>> other 'normal considerations in addition to those in JWT that 
>>>>>> need to be listed?  The phrasing reads as if that may the case 
>>>>>> and would be better to include them all or pointers or change the phrasing.
>>>>> 
>>>>>>  "A recipient may not understand the newly introduced "cnf" claim 
>>>>>> and  may consequently treat it as a bearer token."
>>>>>> 
>>>>>> "When a recipient receives a "cnf" claim with a  member that it 
>>>>>> does not understand, it MUST ignore that member."
>>>>>> 
>>>>>>  legitimate concern, it is outside the scope of this 
>>>>>> specification,  since demonstration the possession of the key 
>>>>>> associated with the  "cnf" claim is not covered by this 
>>>>>> specification. For more details,
>>>>>> 
>>>>>> How is this outside of the scope of this draft?  cnf is defined 
>>>>>> in this draft, so handling should be covered in this draft.  A