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

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, November 26, 2015 4:45 AM
To: Mike Jones <[e-mail]>
Cc: Kathleen Moriarty <[e-mail]>; [e-mail]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

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 <[e-mail]> wrote:
> 
> 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:[e-mail]]
> Sent: Wednesday, November 25, 2015 2:13 PM
> To: John Bradley <[e-mail]>
> Cc: Mike Jones <[e-mail]>; [e-mail]
> Subject: Re: [OAUTH-WG] AD review of 
> draft-ietf-oauth-proof-of-possession
> 
> Thanks, John!
> 
> On Wed, Nov 25, 2015 at 4:41 PM, John Bradley <[e-mail]> wrote:
>> 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.”
> 
> More explicit text like this is is more helpful in my opinion.
> 
> Kathleen
>> 
>> 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 <[e-mail]> wrote:
>>> 
>>> 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:[e-mail]]
>>> Sent: Tuesday, November 24, 2015 7:14 PM
>>> To: Mike Jones <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [OAUTH-WG] AD review of 
>>> draft-ietf-oauth-proof-of-possession
>>> 
>>> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones <[e-mail]> wrote:
>>>> 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.
>>> 
>>> 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
>>> 
>>> 
>>>> 
>>>>                               -- Mike
>>>> 
>>>> -----Original Message-----
>>>> From: Kathleen Moriarty [mailto:[e-mail]]
>>>> Sent: Tuesday, November 24, 2015 6:41 PM
>>>> To: Mike Jones <[e-mail]>
>>>> Cc: [e-mail]
>>>> Subject: Re: [OAUTH-WG] AD review of 
>>>> draft-ietf-oauth-proof-of-possession
>>>> 
>>>> Hi Mike,
>>>> 
>>>> Thanks for the quick turn-around.  Just one more comment on my comments.
>>>> 
>>>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones <[e-mail]> wrote:
>>>>> Thanks for your review comments, Kathleen.  Responses are inline below...
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: OAuth [mailto:[e-mail]] On Behalf Of Kathleen 
>>>>>> Moriarty
>>>>>> Sent: Tuesday, November 24, 2015 9:44 AM
>>>>>> To: [e-mail]
>>>>>> Subject: [OAUTH-WG] AD review of
>>>>>> draft-ietf-oauth-proof-of-possession
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> You're right.  I removed this awkward wording.
>>>>> 
>>>>>> 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?
>>>>> 
>>>>> 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.
>>>> 
>>>> 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
>>>> 
>>>> 
>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> Best regards,
>>>>>> Kathleen
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>>                               Thanks again,
>>>>>                               -- Mike
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Best regards,
>>>> Kathleen
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Best regards,
>>> Kathleen
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen