Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Mike Jones]

Thanks!

From: Richard Barnes<mailto:r...@ipv.sx>
Sent: ‎11/‎11/‎2014 3:30 PM
To: Mike Jones<mailto:michael.jo...@microsoft.com>
Cc: Brian Campbell<mailto:bcampb...@pingidentity.com>; John 
Bradley<mailto:ve7...@ve7jtb.com>; 
draft-ietf-oauth-asserti...@tools.ietf.org<mailto:draft-ietf-oauth-asserti...@tools.ietf.org>;
 Pete Resnick<mailto:presn...@qti.qualcomm.com>; oauth<mailto:oauth@ietf.org>; 
The IESG<mailto:i...@ietf.org>; 
oauth-cha...@tools.ietf.org<mailto:oauth-cha...@tools.ietf.org>
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Looks good to me, thanks.  I cleared.
--Richard

On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Richard, yours are the only discusses on draft-ietf-oauth-assertions, 
draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re all 
about the audience requirement. Brian added text addressing this in the last 
paragraph of 
https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.  Are you 
willing to clear these DISCUSSes on this basis?

If not, can we try to talk before the OAuth meeting tomorrow morning?  I’ll be 
leading the assertions drafts discussions tomorrow since Brian won’t be able to 
attend.

Thanks,
-- Mike

From: Brian Campbell 
[mailto:bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>]
Sent: Friday, October 17, 2014 8:23 AM
To: Richard Barnes
Cc: John Bradley; 
draft-ietf-oauth-asserti...@tools.ietf.org<mailto:draft-ietf-oauth-asserti...@tools.ietf.org>;
 Pete Resnick; oauth; The IESG; 
oauth-cha...@tools.ietf.org<mailto:oauth-cha...@tools.ietf.org>
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

That text works for me, Richard. Thanks.
I will go with Richard's text in the next draft, unless I hear objections.

FWIW, the mention of HoK was a result of a review and suggestions from Hannes 
some time ago.

http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt

It could be removed, to your point, but I think your proposed text is very 
clear about the scope and might help prevent confusion.


On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes 
mailto:r...@ipv.sx>> wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I think this part of sec 3 of assertions states that:


 The protocol parameters and processing rules defined in this document

   are intended to support a client presenting a bearer assertion to an

   authorization server.  The use of holder-of-key assertions are not

   precluded by this document, but additional protocol details would

   need to be specified.


As part of defining the additional protocol details for holder-of-key/PoP we 
can relax the must for audience in the profile that defines how to use those 
assertion types.

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials here?  
The entire remainder of the spec is written as if they didn't exist.  And as 
the text above notes, you can't actually use them with this specification.
If we're going to keep the mention, could we augment the text above to make it 
clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""
--Richard



John B.

On Oct 17, 2014, at 2:25 PM, Pete Resnick 
mailto:presn...@qti.qualcomm.com>> wrote:


On 10/17/14 12:09 PM, Mike Jones wrote:
This is the standard mitigation for a known set of actual attacks.  We 
shouldn’t even consider making it optional.

Do you mean you shouldn't consider making it optional for HoK? Again, making it 
clear that the MUST applies only to bearer assertions, and that future 
extensions for HoK might have different requirements, is all that is being 
asked for here.

pr


--

Pete Resnick 
<http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

Qualcomm Technologies, Inc. - +1 (858)651-4478



___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

Looks good to me, thanks.  I cleared.
--Richard

On Tue, Nov 11, 2014 at 2:33 PM, Mike Jones 
wrote:

>  Richard, yours are the only discusses on draft-ietf-oauth-assertions,
> draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re
> all about the audience requirement. Brian added text addressing this in
> the last paragraph of
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.
> Are you willing to clear these DISCUSSes on this basis?
>
>
>
> If not, can we try to talk before the OAuth meeting tomorrow morning?
> I’ll be leading the assertions drafts discussions tomorrow since Brian
> won’t be able to attend.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Friday, October 17, 2014 8:23 AM
> *To:* Richard Barnes
> *Cc:* John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete
> Resnick; oauth; The IESG; oauth-cha...@tools.ietf.org
> *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> That text works for me, Richard. Thanks.
>
> I will go with Richard's text in the next draft, unless I hear objections.
>
>
>
> FWIW, the mention of HoK was a result of a review and suggestions from
> Hannes some time ago.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt
>
>
>
> It could be removed, to your point, but I think your proposed text is very
> clear about the scope and might help prevent confusion.
>
>
>
>
>
> On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes  wrote:
>
> On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:
>
>  I think this part of sec 3 of assertions states that:
>
>
>
>  The protocol parameters and processing rules defined in this document
>
>are intended to support a client presenting a bearer assertion to an
>
>authorization server.  The use of holder-of-key assertions are not
>
>precluded by this document, but additional protocol details would
>
>need to be specified.
>
>
>
>
>
> As part of defining the additional protocol details for holder-of-key/PoP
> we can relax the must for audience in the profile that defines how to use
> those assertion types.
>
>
>
> I think we're on a path to convergence here.
>
>
>
> Given all this, is there any point to even mentioning HoK credentials
> here?  The entire remainder of the spec is written as if they didn't
> exist.  And as the text above notes, you can't actually use them with this
> specification.
>
> If we're going to keep the mention, could we augment the text above to
> make it clearer that HoK assertions are out of scope.
>
>
> """
>
> The protocol parameters and processing rules defined in this document
> are intended to support a client presenting a bearer assertion to an
> authorization server.  They are not suitable for use with holder-of-key
> assertions.  While they could be used as a baseline for a holder-of-key
>
> assertion system, there would be a need for additional mechanisms
>
> (to support proof of possession of the secret key), and possibly changes
> to the security model (e.g., to relax the requirement for an Audience).
>
> """
>
> --Richard
>
>
>
>
>
>
> John B.
>
>
>
> On Oct 17, 2014, at 2:25 PM, Pete Resnick 
> wrote:
>
>
>
>  On 10/17/14 12:09 PM, Mike Jones wrote:
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
> Do you mean you shouldn't consider making it optional for HoK? Again,
> making it clear that the MUST applies only to bearer assertions, and that
> future extensions for HoK might have different requirements, is all that is
> being asked for here.
>
> pr
>
>  --
>
> Pete Resnick <http://www.qualcomm.com/~presnick/> 
> <http://www.qualcomm.com/~presnick/>
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Mike Jones]

Richard, yours are the only discusses on draft-ietf-oauth-assertions, 
draft-ietf-oauth-saml2-bearer, and draft-ietf-oauth-jwt-bearer, and they’re all 
about the audience requirement. Brian added text addressing this in the last 
paragraph of 
https://tools.ietf.org/html/draft-ietf-oauth-assertions-18#section-3.  Are you 
willing to clear these DISCUSSes on this basis?

If not, can we try to talk before the OAuth meeting tomorrow morning?  I’ll be 
leading the assertions drafts discussions tomorrow since Brian won’t be able to 
attend.

Thanks,
-- Mike

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, October 17, 2014 8:23 AM
To: Richard Barnes
Cc: John Bradley; draft-ietf-oauth-asserti...@tools.ietf.org; Pete Resnick; 
oauth; The IESG; oauth-cha...@tools.ietf.org
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

That text works for me, Richard. Thanks.
I will go with Richard's text in the next draft, unless I hear objections.

FWIW, the mention of HoK was a result of a review and suggestions from Hannes 
some time ago.

http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt

It could be removed, to your point, but I think your proposed text is very 
clear about the scope and might help prevent confusion.


On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes 
mailto:r...@ipv.sx>> wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
I think this part of sec 3 of assertions states that:


 The protocol parameters and processing rules defined in this document

   are intended to support a client presenting a bearer assertion to an

   authorization server.  The use of holder-of-key assertions are not

   precluded by this document, but additional protocol details would

   need to be specified.


As part of defining the additional protocol details for holder-of-key/PoP we 
can relax the must for audience in the profile that defines how to use those 
assertion types.

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials here?  
The entire remainder of the spec is written as if they didn't exist.  And as 
the text above notes, you can't actually use them with this specification.
If we're going to keep the mention, could we augment the text above to make it 
clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""
--Richard



John B.

On Oct 17, 2014, at 2:25 PM, Pete Resnick 
mailto:presn...@qti.qualcomm.com>> wrote:


On 10/17/14 12:09 PM, Mike Jones wrote:
This is the standard mitigation for a known set of actual attacks.  We 
shouldn’t even consider making it optional.

Do you mean you shouldn't consider making it optional for HoK? Again, making it 
clear that the MUST applies only to bearer assertions, and that future 
extensions for HoK might have different requirements, is all that is being 
asked for here.

pr


--

Pete Resnick 
<http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

Qualcomm Technologies, Inc. - +1 (858)651-4478



___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[John Bradley]

+1
On Oct 17, 2014, at 3:23 PM, Brian Campbell  wrote:

> That text works for me, Richard. Thanks. 
> 
> I will go with Richard's text in the next draft, unless I hear objections.
> 
> 
> FWIW, the mention of HoK was a result of a review and suggestions from Hannes 
> some time ago.
> 
> http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt
> 
> It could be removed, to your point, but I think your proposed text is very 
> clear about the scope and might help prevent confusion.
> 
> 
> On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes  wrote:
> On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:
> I think this part of sec 3 of assertions states that:
> 
>  The protocol parameters and processing rules defined in this document
>are intended to support a client presenting a bearer assertion to an
>authorization server.  The use of holder-of-key assertions are not
>precluded by this document, but additional protocol details would
>need to be specified.
> 
> 
> As part of defining the additional protocol details for holder-of-key/PoP we 
> can relax the must for audience in the profile that defines how to use those 
> assertion types.
> 
> I think we're on a path to convergence here.
> 
> Given all this, is there any point to even mentioning HoK credentials here?  
> The entire remainder of the spec is written as if they didn't exist.  And as 
> the text above notes, you can't actually use them with this specification.
> 
> If we're going to keep the mention, could we augment the text above to make 
> it clearer that HoK assertions are out of scope.
> 
> """
> The protocol parameters and processing rules defined in this document
> are intended to support a client presenting a bearer assertion to an
> authorization server.  They are not suitable for use with holder-of-key
> assertions.  While they could be used as a baseline for a holder-of-key
> assertion system, there would be a need for additional mechanisms
> (to support proof of possession of the secret key), and possibly changes
> to the security model (e.g., to relax the requirement for an Audience).
> """
> 
> --Richard
> 
> 
>  
> 
> John B.
> 
> On Oct 17, 2014, at 2:25 PM, Pete Resnick  wrote:
> 
>> On 10/17/14 12:09 PM, Mike Jones wrote:
>>> 
>>> This is the standard mitigation for a known set of actual attacks.  We 
>>> shouldn’t even consider making it optional.
>>> 
>>> 
>> 
>> Do you mean you shouldn't consider making it optional for HoK? Again, making 
>> it clear that the MUST applies only to bearer assertions, and that future 
>> extensions for HoK might have different requirements, is all that is being 
>> asked for here.
>> 
>> pr
>> -- 
>> Pete Resnick 
>> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Brian Campbell]

That text works for me, Richard. Thanks.

I will go with Richard's text in the next draft, unless I hear objections.


FWIW, the mention of HoK was a result of a review and suggestions from
Hannes some time ago.

http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html
https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt

It could be removed, to your point, but I think your proposed text is very
clear about the scope and might help prevent confusion.


On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes  wrote:

> On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:
>
>> I think this part of sec 3 of assertions states that:
>>
>>  The protocol parameters and processing rules defined in this document
>>are intended to support a client presenting a bearer assertion to an
>>authorization server.  The use of holder-of-key assertions are not
>>precluded by this document, but additional protocol details would
>>need to be specified.
>>
>>
>>
>> As part of defining the additional protocol details for holder-of-key/PoP
>> we can relax the must for audience in the profile that defines how to use
>> those assertion types.
>>
>
> I think we're on a path to convergence here.
>
> Given all this, is there any point to even mentioning HoK credentials
> here?  The entire remainder of the spec is written as if they didn't
> exist.  And as the text above notes, you can't actually use them with this
> specification.
>
> If we're going to keep the mention, could we augment the text above to
> make it clearer that HoK assertions are out of scope.
>
> """
> The protocol parameters and processing rules defined in this document
> are intended to support a client presenting a bearer assertion to an
> authorization server.  They are not suitable for use with holder-of-key
> assertions.  While they could be used as a baseline for a holder-of-key
> assertion system, there would be a need for additional mechanisms
> (to support proof of possession of the secret key), and possibly changes
> to the security model (e.g., to relax the requirement for an Audience).
> """
>
> --Richard
>
>
>
>
>>
>> John B.
>>
>> On Oct 17, 2014, at 2:25 PM, Pete Resnick 
>> wrote:
>>
>>  On 10/17/14 12:09 PM, Mike Jones wrote:
>>
>> This is the standard mitigation for a known set of actual attacks.  We
>> shouldn’t even consider making it optional.
>>
>>
>> Do you mean you shouldn't consider making it optional for HoK? Again,
>> making it clear that the MUST applies only to bearer assertions, and that
>> future extensions for HoK might have different requirements, is all that is
>> being asked for here.
>>
>> pr
>>
>> --
>> Pete Resnick  
>> 
>> Qualcomm Technologies, Inc. - +1 (858)651-4478
>>
>>
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

It's a known set of actual attacks ... on bearer assertions.  There is no
corresponding attack on HoK assertions.

We shouldn't consider making it optional for bearer assertions.  For HoK,
there's no reason for it not to be optional.

On Fri, Oct 17, 2014 at 10:09 AM, Mike Jones 
wrote:

>  +1
>
>
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
> *Sent:* Friday, October 17, 2014 9:50 AM
> *To:* John Bradley
> *Cc:* draft-ietf-oauth-asserti...@tools.ietf.org; Richard Barnes;
> oauth-cha...@tools.ietf.org; The IESG; oauth
> *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
>
>
>
> I believe that if you make “aud” optional, it only helps the simplistic
> deployment scenarios where there is only one RS and one AS. The optionality
> itself will cause more confusion.  In the simplistic case, the AS and RS
> simply have to agree on a URI.
>
>
>
> In more sophisticated domains where there is more than one RS service, the
> “aud” value is expected and is useful to determining who a token is
> intended for.
>
>
>
> Finally, there is the 3rd level case where the AS and the RS are in
> separate domains (federated). In this case, we can expect inter-op to be
> required between separate vendors as a majority of cases.
>
>
>
> Making “aud” optional will greatly increase complexity in reality.  Making
> it a MUST only puts a trivial imposition on the trivial case (they have to
> provide a made up URI).
>
>
>
> We did not really discuss “aud" much on the list because it is well known
> industry practice. I would not want to suggest re-writing something that
> works well.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On Oct 17, 2014, at 9:01 AM, John Bradley  wrote:
>
>
>
>  I am good with it as is.  I think we have the flexibility to add HoK
> later.
>
>
>
> I mostly wanted to point out that it is really only in that later HoK
> profile where omitting audience is safe.
>
>
>
> If I had the power to remove the DISCUS I would.
>
>
>
> John B.
>
>
>
> On Oct 17, 2014, at 12:56 PM, Brian Campbell 
> wrote:
>
>
>
>   These drafts define the use of bearer assertions. The only mention of
> HoK style assertions is at the end of
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3
> which notes that the "rules defined in this document are intended to
> support a client presenting a bearer assertion to an authorization server.
> The use of holder-of-key assertions are not precluded by this document, but
> additional protocol details would need to be specified."
>
> The requirement of having audience is for bearer assertions only (and we
> agree need to be that way for bearer) and not intended to preclude anything
> for HoK assertions.
>
> Does that change your opinion? Is there something that could be added or
> removed or clarified to allay concerns?
>
>
>
>
>
> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>
> Holder of key JWT is still in draft and we don't have a clear way to
> present the proof to the token endpoint.
>
>
>
> Brian and I started discussing that last week as I happen to have a use
> case for a PoP JWT assertion flow in some other spec work.
>
>
>
> I think that there is enough difference between bearer and PoP that doing
> a follow on profile for SAML and JWT that can also cover the proof
> presentment mechanisms makes the most sense.
>
>
>
> I would go with restricting this to Bearer and MUST for audience,  and
> removing the audience requirement explicitly in the PoP profiles.
>
>
>
> There are people who need the bearer version 6 months ago,  I don't want
> to do anything to hold it up based on future work.
>
>
>
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML
> subject confirmation stuff is relatively clear so it is mostly defining the
> presentment mechanisms like mutual TLS and a self signed assertion. (we
> need to be careful not to conflate client authentication and token proof,
> as they are different and might both be used at the same time.
>
>
>
> John B.
>
>
>
> On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:
>
>
>
>   You guys are all arguing that having an Audience ca

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

On Fri, Oct 17, 2014 at 10:32 AM, John Bradley  wrote:

> I think this part of sec 3 of assertions states that:
>
>  The protocol parameters and processing rules defined in this document
>are intended to support a client presenting a bearer assertion to an
>authorization server.  The use of holder-of-key assertions are not
>precluded by this document, but additional protocol details would
>need to be specified.
>
>
>
> As part of defining the additional protocol details for holder-of-key/PoP
> we can relax the must for audience in the profile that defines how to use
> those assertion types.
>

I think we're on a path to convergence here.

Given all this, is there any point to even mentioning HoK credentials
here?  The entire remainder of the spec is written as if they didn't
exist.  And as the text above notes, you can't actually use them with this
specification.

If we're going to keep the mention, could we augment the text above to make
it clearer that HoK assertions are out of scope.

"""
The protocol parameters and processing rules defined in this document
are intended to support a client presenting a bearer assertion to an
authorization server.  They are not suitable for use with holder-of-key
assertions.  While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly changes
to the security model (e.g., to relax the requirement for an Audience).
"""

--Richard




>
> John B.
>
> On Oct 17, 2014, at 2:25 PM, Pete Resnick 
> wrote:
>
>  On 10/17/14 12:09 PM, Mike Jones wrote:
>
> This is the standard mitigation for a known set of actual attacks.  We
> shouldn’t even consider making it optional.
>
>
> Do you mean you shouldn't consider making it optional for HoK? Again,
> making it clear that the MUST applies only to bearer assertions, and that
> future extensions for HoK might have different requirements, is all that is
> being asked for here.
>
> pr
>
> --
> Pete Resnick  
> 
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Kathleen Moriarty]

I just caught up on the thread again and think Brian's message below may be the 
most helpful to resolve this discuss.  

It sounds like we have agreement that a MUST is preferred for bearer tokens and 
that's what this draft is about.  Would a language tweak help when HoK is 
mentioned?  The WG will have more time to figure out what is needed for that in 
the draft mentioned that is on development.

Thanks,
Kathleen 

Sent from my iPhone

> On Oct 17, 2014, at 11:56 AM, Brian Campbell  
> wrote:
> 
> These drafts define the use of bearer assertions. The only mention of HoK 
> style assertions is at the end of 
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which 
> notes that the "rules defined in this document are intended to support a 
> client presenting a bearer assertion to an authorization server.  The use of 
> holder-of-key assertions are not precluded by this document, but additional 
> protocol details would need to be specified."
> 
> The requirement of having audience is for bearer assertions only (and we 
> agree need to be that way for bearer) and not intended to preclude anything 
> for HoK assertions. 
> 
> Does that change your opinion? Is there something that could be added or 
> removed or clarified to allay concerns?
> 
> 
> 
>> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>> Holder of key JWT is still in draft and we don't have a clear way to present 
>> the proof to the token endpoint.
>> 
>> Brian and I started discussing that last week as I happen to have a use case 
>> for a PoP JWT assertion flow in some other spec work.
>> 
>> I think that there is enough difference between bearer and PoP that doing a 
>> follow on profile for SAML and JWT that can also cover the proof presentment 
>> mechanisms makes the most sense.
>> 
>> I would go with restricting this to Bearer and MUST for audience,  and 
>> removing the audience requirement explicitly in the PoP profiles.
>> 
>> There are people who need the bearer version 6 months ago,  I don't want to 
>> do anything to hold it up based on future work.
>> 
>> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML 
>> subject confirmation stuff is relatively clear so it is mostly defining the 
>> presentment mechanisms like mutual TLS and a self signed assertion. (we need 
>> to be careful not to conflate client authentication and token proof, as they 
>> are different and might both be used at the same time.
>> 
>> John B.
>> 
>>> On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:
>>> 
>>> You guys are all arguing that having an Audience can be useful.  I don't 
>>> disagree.  I disagree that it should be REQUIRED in all cases.
>>> 
>>> The Google vulnerability that Brian raised was an interesting read, but as 
>>> John points out, it only applies to Bearer Assertions.  There's no security 
>>> requirement at all for holder-of-key assertions to have an audience, since 
>>> they can't be replayed by someone who doesn't hold the key.
>>> 
>>> I could agree that an audience should be REQUIRED for bearer assertions.  
>>> Since they are vulnerable to replay, Audience protects against the 
>>> Authorization Server re-using the token.  (It would be good to say this 
>>> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
>>> Audience should be OPTIONAL.  Note that this requires that instance 
>>> documents define the difference between bearer assertions and holder-of-key 
>>> assertions, so that implementations can enforce these requirements.
>>> 
>>> So it seems like there are two solutions here:
>>> 1. Scope the document to bearer assertions only, and keep the MUST
>>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
>>> assertions, and define the difference in the instance docs.
>>> 
>>> --Richard
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
 It is also important for a non-protocol purpose. Liability.
 
 If a 3rd party uses an assertion that was not intended for it, it cannot 
 obviously hold the asserting party responsible.  
 
 Phil
 
 @independentid
 www.independentid.com
 phil.h...@oracle.com
 
 
 
> On Oct 16, 2014, at 8:43 AM, Brian Campbell  
> wrote:
> 
> Thanks for your review and feedback, Richard. Replies are inline below...
> 
>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>> Richard Barnes has entered the following ballot position for
>> draft-ietf-oauth-assertions-17: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot 

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Phil Hunt]

FWIW…I was only responding to the question of making aud optional for bearer 
tokens.

The broader point is that regardless of token type, there is always an “aud” 
value — whether explicitly declared as a claim, or implicitly implied (e.g. 
through encryption so only the audience can consume it).

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Oct 17, 2014, at 10:25 AM, Pete Resnick  wrote:

> On 10/17/14 12:09 PM, Mike Jones wrote:
>> 
>> This is the standard mitigation for a known set of actual attacks.  We 
>> shouldn’t even consider making it optional.
>> 
>> 
> 
> Do you mean you shouldn't consider making it optional for HoK? Again, making 
> it clear that the MUST applies only to bearer assertions, and that future 
> extensions for HoK might have different requirements, is all that is being 
> asked for here.
> 
> pr
> -- 
> Pete Resnick 
> Qualcomm Technologies, Inc. - +1 (858)651-4478

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[John Bradley]

I think this part of sec 3 of assertions states that:

 The protocol parameters and processing rules defined in this document
   are intended to support a client presenting a bearer assertion to an
   authorization server.  The use of holder-of-key assertions are not
   precluded by this document, but additional protocol details would
   need to be specified.


As part of defining the additional protocol details for holder-of-key/PoP we 
can relax the must for audience in the profile that defines how to use those 
assertion types.

John B.

On Oct 17, 2014, at 2:25 PM, Pete Resnick  wrote:

> On 10/17/14 12:09 PM, Mike Jones wrote:
>> 
>> This is the standard mitigation for a known set of actual attacks.  We 
>> shouldn’t even consider making it optional.
>> 
>> 
> 
> Do you mean you shouldn't consider making it optional for HoK? Again, making 
> it clear that the MUST applies only to bearer assertions, and that future 
> extensions for HoK might have different requirements, is all that is being 
> asked for here.
> 
> pr
> -- 
> Pete Resnick 
> Qualcomm Technologies, Inc. - +1 (858)651-4478

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Pete Resnick]

On 10/17/14 12:09 PM, Mike Jones wrote:


This is the standard mitigation for a known set of actual attacks.  We 
shouldn't even consider making it optional.




Do you mean you shouldn't consider making it optional for HoK? Again, 
making it clear that the MUST applies only to bearer assertions, and 
that future extensions for HoK might have different requirements, is all 
that is being asked for here.


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Mike Jones]

+1

This is the standard mitigation for a known set of actual attacks.  We 
shouldn't even consider making it optional.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, October 17, 2014 9:50 AM
To: John Bradley
Cc: draft-ietf-oauth-asserti...@tools.ietf.org; Richard Barnes; 
oauth-cha...@tools.ietf.org; The IESG; oauth
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on 
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

I believe that if you make "aud" optional, it only helps the simplistic 
deployment scenarios where there is only one RS and one AS. The optionality 
itself will cause more confusion.  In the simplistic case, the AS and RS simply 
have to agree on a URI.

In more sophisticated domains where there is more than one RS service, the 
"aud" value is expected and is useful to determining who a token is intended 
for.

Finally, there is the 3rd level case where the AS and the RS are in separate 
domains (federated). In this case, we can expect inter-op to be required 
between separate vendors as a majority of cases.

Making "aud" optional will greatly increase complexity in reality.  Making it a 
MUST only puts a trivial imposition on the trivial case (they have to provide a 
made up URI).

We did not really discuss "aud" much on the list because it is well known 
industry practice. I would not want to suggest re-writing something that works 
well.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Oct 17, 2014, at 9:01 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:


I am good with it as is.  I think we have the flexibility to add HoK later.

I mostly wanted to point out that it is really only in that later HoK profile 
where omitting audience is safe.

If I had the power to remove the DISCUS I would.

John B.

On Oct 17, 2014, at 12:56 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:


These drafts define the use of bearer assertions. The only mention of HoK style 
assertions is at the end of 
https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which 
notes that the "rules defined in this document are intended to support a client 
presenting a bearer assertion to an authorization server.  The use of 
holder-of-key assertions are not precluded by this document, but additional 
protocol details would need to be specified."
The requirement of having audience is for bearer assertions only (and we agree 
need to be that way for bearer) and not intended to preclude anything for HoK 
assertions.
Does that change your opinion? Is there something that could be added or 
removed or clarified to allay concerns?


On Thu, Oct 16, 2014 at 6:54 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
Holder of key JWT is still in draft and we don't have a clear way to present 
the proof to the token endpoint.

Brian and I started discussing that last week as I happen to have a use case 
for a PoP JWT assertion flow in some other spec work.

I think that there is enough difference between bearer and PoP that doing a 
follow on profile for SAML and JWT that can also cover the proof presentment 
mechanisms makes the most sense.

I would go with restricting this to Bearer and MUST for audience,  and removing 
the audience requirement explicitly in the PoP profiles.

There are people who need the bearer version 6 months ago,  I don't want to do 
anything to hold it up based on future work.

I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML subject 
confirmation stuff is relatively clear so it is mostly defining the presentment 
mechanisms like mutual TLS and a self signed assertion. (we need to be careful 
not to conflate client authentication and token proof, as they are different 
and might both be used at the same time.

John B.

On Oct 16, 2014, at 7:20 PM, Richard Barnes mailto:r...@ipv.sx>> 
wrote:


You guys are all arguing that having an Audience can be useful.  I don't 
disagree.  I disagree that it should be REQUIRED in all cases.
The Google vulnerability that Brian raised was an interesting read, but as John 
points out, it only applies to Bearer Assertions.  There's no security 
requirement at all for holder-of-key assertions to have an audience, since they 
can't be replayed by someone who doesn't hold the key.
I could agree that an audience should be REQUIRED for bearer assertions.  Since 
they are vulnerable to replay, Audience protects against the Authorization 
Server re-using the token.  (It would be good to say this explicitly in the 
doc, actually.)  But for holder-of-key assertions, the Audience should be 
OPTIONAL.  Note that this requires that instance documents define the 
difference between bearer assertions and holde

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Phil Hunt]

I believe that if you make “aud” optional, it only helps the simplistic 
deployment scenarios where there is only one RS and one AS. The optionality 
itself will cause more confusion.  In the simplistic case, the AS and RS simply 
have to agree on a URI.

In more sophisticated domains where there is more than one RS service, the 
“aud” value is expected and is useful to determining who a token is intended 
for.

Finally, there is the 3rd level case where the AS and the RS are in separate 
domains (federated). In this case, we can expect inter-op to be required 
between separate vendors as a majority of cases.  

Making “aud” optional will greatly increase complexity in reality.  Making it a 
MUST only puts a trivial imposition on the trivial case (they have to provide a 
made up URI).

We did not really discuss “aud" much on the list because it is well known 
industry practice. I would not want to suggest re-writing something that works 
well.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Oct 17, 2014, at 9:01 AM, John Bradley  wrote:

> I am good with it as is.  I think we have the flexibility to add HoK later.   
>  
> 
> I mostly wanted to point out that it is really only in that later HoK profile 
> where omitting audience is safe.
> 
> If I had the power to remove the DISCUS I would.
> 
> John B.
> 
> On Oct 17, 2014, at 12:56 PM, Brian Campbell  
> wrote:
> 
>> These drafts define the use of bearer assertions. The only mention of HoK 
>> style assertions is at the end of 
>> https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which 
>> notes that the "rules defined in this document are intended to support a 
>> client presenting a bearer assertion to an authorization server.  The use of 
>> holder-of-key assertions are not precluded by this document, but additional 
>> protocol details would need to be specified."
>> 
>> The requirement of having audience is for bearer assertions only (and we 
>> agree need to be that way for bearer) and not intended to preclude anything 
>> for HoK assertions. 
>> 
>> Does that change your opinion? Is there something that could be added or 
>> removed or clarified to allay concerns?
>> 
>> 
>> 
>> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
>> Holder of key JWT is still in draft and we don't have a clear way to present 
>> the proof to the token endpoint.
>> 
>> Brian and I started discussing that last week as I happen to have a use case 
>> for a PoP JWT assertion flow in some other spec work.
>> 
>> I think that there is enough difference between bearer and PoP that doing a 
>> follow on profile for SAML and JWT that can also cover the proof presentment 
>> mechanisms makes the most sense.
>> 
>> I would go with restricting this to Bearer and MUST for audience,  and 
>> removing the audience requirement explicitly in the PoP profiles.
>> 
>> There are people who need the bearer version 6 months ago,  I don't want to 
>> do anything to hold it up based on future work.
>> 
>> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML 
>> subject confirmation stuff is relatively clear so it is mostly defining the 
>> presentment mechanisms like mutual TLS and a self signed assertion. (we need 
>> to be careful not to conflate client authentication and token proof, as they 
>> are different and might both be used at the same time.
>> 
>> John B.
>> 
>> On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:
>> 
>>> You guys are all arguing that having an Audience can be useful.  I don't 
>>> disagree.  I disagree that it should be REQUIRED in all cases.
>>> 
>>> The Google vulnerability that Brian raised was an interesting read, but as 
>>> John points out, it only applies to Bearer Assertions.  There's no security 
>>> requirement at all for holder-of-key assertions to have an audience, since 
>>> they can't be replayed by someone who doesn't hold the key.
>>> 
>>> I could agree that an audience should be REQUIRED for bearer assertions.  
>>> Since they are vulnerable to replay, Audience protects against the 
>>> Authorization Server re-using the token.  (It would be good to say this 
>>> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
>>> Audience should be OPTIONAL.  Note that this requires that instance 
>>> documents define the difference between bearer assertions and holder-of-key 
>>> assertions, so that implementations can enforce these requirements.
>>> 
>>> So it seems like there are two solutions here:
>>> 1. Scope the document to bearer assertions only, and keep the MUST
>>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
>>> assertions, and define the difference in the instance docs.
>>> 
>>> --Richard
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>>> It is also important for a non-protocol purpose. Liability.
>>> 
>>> If a 3rd party uses an assertion that was not intended for it, it cannot 
>>> obviously hold 

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[John Bradley]

I am good with it as is.  I think we have the flexibility to add HoK later.

I mostly wanted to point out that it is really only in that later HoK profile 
where omitting audience is safe.

If I had the power to remove the DISCUS I would.

John B.

On Oct 17, 2014, at 12:56 PM, Brian Campbell  wrote:

> These drafts define the use of bearer assertions. The only mention of HoK 
> style assertions is at the end of 
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which 
> notes that the "rules defined in this document are intended to support a 
> client presenting a bearer assertion to an authorization server.  The use of 
> holder-of-key assertions are not precluded by this document, but additional 
> protocol details would need to be specified."
> 
> The requirement of having audience is for bearer assertions only (and we 
> agree need to be that way for bearer) and not intended to preclude anything 
> for HoK assertions. 
> 
> Does that change your opinion? Is there something that could be added or 
> removed or clarified to allay concerns?
> 
> 
> 
> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:
> Holder of key JWT is still in draft and we don't have a clear way to present 
> the proof to the token endpoint.
> 
> Brian and I started discussing that last week as I happen to have a use case 
> for a PoP JWT assertion flow in some other spec work.
> 
> I think that there is enough difference between bearer and PoP that doing a 
> follow on profile for SAML and JWT that can also cover the proof presentment 
> mechanisms makes the most sense.
> 
> I would go with restricting this to Bearer and MUST for audience,  and 
> removing the audience requirement explicitly in the PoP profiles.
> 
> There are people who need the bearer version 6 months ago,  I don't want to 
> do anything to hold it up based on future work.
> 
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML 
> subject confirmation stuff is relatively clear so it is mostly defining the 
> presentment mechanisms like mutual TLS and a self signed assertion. (we need 
> to be careful not to conflate client authentication and token proof, as they 
> are different and might both be used at the same time.
> 
> John B.
> 
> On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:
> 
>> You guys are all arguing that having an Audience can be useful.  I don't 
>> disagree.  I disagree that it should be REQUIRED in all cases.
>> 
>> The Google vulnerability that Brian raised was an interesting read, but as 
>> John points out, it only applies to Bearer Assertions.  There's no security 
>> requirement at all for holder-of-key assertions to have an audience, since 
>> they can't be replayed by someone who doesn't hold the key.
>> 
>> I could agree that an audience should be REQUIRED for bearer assertions.  
>> Since they are vulnerable to replay, Audience protects against the 
>> Authorization Server re-using the token.  (It would be good to say this 
>> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
>> Audience should be OPTIONAL.  Note that this requires that instance 
>> documents define the difference between bearer assertions and holder-of-key 
>> assertions, so that implementations can enforce these requirements.
>> 
>> So it seems like there are two solutions here:
>> 1. Scope the document to bearer assertions only, and keep the MUST
>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
>> assertions, and define the difference in the instance docs.
>> 
>> --Richard
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>> It is also important for a non-protocol purpose. Liability.
>> 
>> If a 3rd party uses an assertion that was not intended for it, it cannot 
>> obviously hold the asserting party responsible.  
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>> On Oct 16, 2014, at 8:43 AM, Brian Campbell  
>> wrote:
>> 
>>> Thanks for your review and feedback, Richard. Replies are inline below...
>>> 
>>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>>> Richard Barnes has entered the following ballot position for
>>> draft-ietf-oauth-assertions-17: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> "The assertion MUST contain an Audience that identifies 

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Brian Campbell]

These drafts define the use of bearer assertions. The only mention of HoK
style assertions is at the end of
https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which
notes that the "rules defined in this document are intended to support a
client presenting a bearer assertion to an authorization server.  The use
of holder-of-key assertions are not precluded by this document, but
additional protocol details would need to be specified."

The requirement of having audience is for bearer assertions only (and we
agree need to be that way for bearer) and not intended to preclude anything
for HoK assertions.

Does that change your opinion? Is there something that could be added or
removed or clarified to allay concerns?



On Thu, Oct 16, 2014 at 6:54 PM, John Bradley  wrote:

> Holder of key JWT is still in draft and we don't have a clear way to
> present the proof to the token endpoint.
>
> Brian and I started discussing that last week as I happen to have a use
> case for a PoP JWT assertion flow in some other spec work.
>
> I think that there is enough difference between bearer and PoP that doing
> a follow on profile for SAML and JWT that can also cover the proof
> presentment mechanisms makes the most sense.
>
> I would go with restricting this to Bearer and MUST for audience,  and
> removing the audience requirement explicitly in the PoP profiles.
>
> There are people who need the bearer version 6 months ago,  I don't want
> to do anything to hold it up based on future work.
>
> I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML
> subject confirmation stuff is relatively clear so it is mostly defining the
> presentment mechanisms like mutual TLS and a self signed assertion. (we
> need to be careful not to conflate client authentication and token proof,
> as they are different and might both be used at the same time.
>
> John B.
>
> On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:
>
> You guys are all arguing that having an Audience can be useful.  I don't
> disagree.  I disagree that it should be REQUIRED in all cases.
>
> The Google vulnerability that Brian raised was an interesting read, but as
> John points out, it only applies to Bearer Assertions.  There's no security
> requirement at all for holder-of-key assertions to have an audience, since
> they can't be replayed by someone who doesn't hold the key.
>
> I could agree that an audience should be REQUIRED for bearer assertions.
> Since they are vulnerable to replay, Audience protects against the
> Authorization Server re-using the token.  (It would be good to say this
> explicitly in the doc, actually.)  But for holder-of-key assertions, the
> Audience should be OPTIONAL.  Note that this requires that instance
> documents define the difference between bearer assertions and holder-of-key
> assertions, so that implementations can enforce these requirements.
>
> So it seems like there are two solutions here:
> 1. Scope the document to bearer assertions only, and keep the MUST
> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key
> assertions, and define the difference in the instance docs.
>
> --Richard
>
>
>
>
>
>
> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>
>> It is also important for a non-protocol purpose. Liability.
>>
>> If a 3rd party uses an assertion that was not intended for it, it cannot
>> obviously hold the asserting party responsible.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>>
>>
>>
>> On Oct 16, 2014, at 8:43 AM, Brian Campbell 
>> wrote:
>>
>> Thanks for your review and feedback, Richard. Replies are inline below...
>>
>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>>
>>> Richard Barnes has entered the following ballot position for
>>> draft-ietf-oauth-assertions-17: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> "The assertion MUST contain an Audience that identifies the Authorization
>>> Server as the intended audience.  Assertions that do not identify the
>>> Authorization Server as an intended audience MUST be rejected."
>>>
>>> Could you please identify the threat model within which this "MUST" is
>>> required?  This requirement doesn't follow from any of the threats
>>> elaborated in Section 8.
>>>
>>> The Audience is only necessary if the Issuer wishes to constrain the set
>>> of Authorization

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[John Bradley]

Holder of key JWT is still in draft and we don't have a clear way to present 
the proof to the token endpoint.

Brian and I started discussing that last week as I happen to have a use case 
for a PoP JWT assertion flow in some other spec work.

I think that there is enough difference between bearer and PoP that doing a 
follow on profile for SAML and JWT that can also cover the proof presentment 
mechanisms makes the most sense.

I would go with restricting this to Bearer and MUST for audience,  and removing 
the audience requirement explicitly in the PoP profiles.

There are people who need the bearer version 6 months ago,  I don't want to do 
anything to hold it up based on future work.

I am happy to help with a SAML PoP/HoK draft as a follow on.   The SAML subject 
confirmation stuff is relatively clear so it is mostly defining the presentment 
mechanisms like mutual TLS and a self signed assertion. (we need to be careful 
not to conflate client authentication and token proof, as they are different 
and might both be used at the same time.

John B.

On Oct 16, 2014, at 7:20 PM, Richard Barnes  wrote:

> You guys are all arguing that having an Audience can be useful.  I don't 
> disagree.  I disagree that it should be REQUIRED in all cases.
> 
> The Google vulnerability that Brian raised was an interesting read, but as 
> John points out, it only applies to Bearer Assertions.  There's no security 
> requirement at all for holder-of-key assertions to have an audience, since 
> they can't be replayed by someone who doesn't hold the key.
> 
> I could agree that an audience should be REQUIRED for bearer assertions.  
> Since they are vulnerable to replay, Audience protects against the 
> Authorization Server re-using the token.  (It would be good to say this 
> explicitly in the doc, actually.)  But for holder-of-key assertions, the 
> Audience should be OPTIONAL.  Note that this requires that instance documents 
> define the difference between bearer assertions and holder-of-key assertions, 
> so that implementations can enforce these requirements.
> 
> So it seems like there are two solutions here:
> 1. Scope the document to bearer assertions only, and keep the MUST
> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key 
> assertions, and define the difference in the instance docs.
> 
> --Richard
> 
> 
> 
> 
> 
> 
> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
> It is also important for a non-protocol purpose. Liability.
> 
> If a 3rd party uses an assertion that was not intended for it, it cannot 
> obviously hold the asserting party responsible.  
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Oct 16, 2014, at 8:43 AM, Brian Campbell  
> wrote:
> 
>> Thanks for your review and feedback, Richard. Replies are inline below...
>> 
>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>> Richard Barnes has entered the following ballot position for
>> draft-ietf-oauth-assertions-17: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> "The assertion MUST contain an Audience that identifies the Authorization
>> Server as the intended audience.  Assertions that do not identify the
>> Authorization Server as an intended audience MUST be rejected."
>> 
>> Could you please identify the threat model within which this "MUST" is
>> required?  This requirement doesn't follow from any of the threats
>> elaborated in Section 8.
>> 
>> The Audience is only necessary if the Issuer wishes to constrain the set
>> of Authorization Servers with which an assertion may be used.  So ISTM
>> that this should be "MAY contain..."
>> 
>> 
>> 
>> The audience restriction let's the issuer say specifically what relying 
>> party is allowed to consume the assertion, which ensures that the client 
>> can't use it somewhere else that it wasn't intended and that the relying 
>> party that receives the assertion can't turn around and use it to access 
>> some other service.
>> 
>> Strictly speaking, you are right that the audience is only necessary if the 
>> Issuer wishes to constrain the set of Authorization Servers with which an 
>> assertion may be used. But the Issuer really really really should make that 
>> constraint and fully understanding the implications of not doing so is 
>> difficult and unlikely. 
>> 
>> There was a vulnerability in Google apps SAML a f

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes  wrote:

> You guys are all arguing that having an Audience can be useful.  I don't
> disagree.  I disagree that it should be REQUIRED in all cases.
>
> The Google vulnerability that Brian raised was an interesting read, but as
> John points out, it only applies to Bearer Assertions.  There's no security
> requirement at all for holder-of-key assertions to have an audience, since
> they can't be replayed by someone who doesn't hold the key.
>
> I could agree that an audience should be REQUIRED for bearer assertions.
> Since they are vulnerable to replay, Audience protects against the
> Authorization Server re-using the token.  (It would be good to say this
> explicitly in the doc, actually.)  But for holder-of-key assertions, the
> Audience should be OPTIONAL.  Note that this requires that instance
> documents define the difference between bearer assertions and holder-of-key
> assertions, so that implementations can enforce these requirements.
>
> So it seems like there are two solutions here:
> 1. Scope the document to bearer assertions only, and keep the MUST
> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key
> assertions, and define the difference in the instance docs.
>

I'll also offer a third resolution:
3. Show me that the WG discussed this question and made the decision to
forbid holder-of-key assertions without an Audience parameter.

--Richard




> --Richard
>
>
>
>
>
>
> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:
>
>> It is also important for a non-protocol purpose. Liability.
>>
>> If a 3rd party uses an assertion that was not intended for it, it cannot
>> obviously hold the asserting party responsible.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>>
>>
>>
>> On Oct 16, 2014, at 8:43 AM, Brian Campbell 
>> wrote:
>>
>> Thanks for your review and feedback, Richard. Replies are inline below...
>>
>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>>
>>> Richard Barnes has entered the following ballot position for
>>> draft-ietf-oauth-assertions-17: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> "The assertion MUST contain an Audience that identifies the Authorization
>>> Server as the intended audience.  Assertions that do not identify the
>>> Authorization Server as an intended audience MUST be rejected."
>>>
>>> Could you please identify the threat model within which this "MUST" is
>>> required?  This requirement doesn't follow from any of the threats
>>> elaborated in Section 8.
>>>
>>> The Audience is only necessary if the Issuer wishes to constrain the set
>>> of Authorization Servers with which an assertion may be used.  So ISTM
>>> that this should be "MAY contain..."
>>>
>>>
>>
>> The audience restriction let's the issuer say specifically what relying
>> party is allowed to consume the assertion, which ensures that the client
>> can't use it somewhere else that it wasn't intended and that the relying
>> party that receives the assertion can't turn around and use it to access
>> some other service.
>>
>> Strictly speaking, you are right that the audience is only necessary if
>> the Issuer wishes to constrain the set of Authorization Servers with which
>> an assertion may be used. But the Issuer really really really should make
>> that constraint and fully understanding the implications of not doing so is
>> difficult and unlikely.
>>
>> There was a vulnerability in Google apps SAML a few years back that
>> demonstrates how important audience restriction is and how it can be
>> difficult for even very sophisticated providers to get it all right. I
>> haven't had time to read it again to make sure but I think that this is the
>> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
>>
>> I don't see what value allowing audience to be omitted brings other than
>> that it is academically a possibility. But requiring it (hopefully, if the
>> requirement is followed) helps reduce the possibility of a whole bunch of
>> security problems that folks likely won't foresee.
>>
>>
>>
>>> --
>>> COMMENT:
>>> --
>>>
>>> "keyed message digest" -> "Message Authentication Code"
>>>
>>> That's the proper terminology [RFC4949], especi

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

You guys are all arguing that having an Audience can be useful.  I don't
disagree.  I disagree that it should be REQUIRED in all cases.

The Google vulnerability that Brian raised was an interesting read, but as
John points out, it only applies to Bearer Assertions.  There's no security
requirement at all for holder-of-key assertions to have an audience, since
they can't be replayed by someone who doesn't hold the key.

I could agree that an audience should be REQUIRED for bearer assertions.
Since they are vulnerable to replay, Audience protects against the
Authorization Server re-using the token.  (It would be good to say this
explicitly in the doc, actually.)  But for holder-of-key assertions, the
Audience should be OPTIONAL.  Note that this requires that instance
documents define the difference between bearer assertions and holder-of-key
assertions, so that implementations can enforce these requirements.

So it seems like there are two solutions here:
1. Scope the document to bearer assertions only, and keep the MUST
2. Keep the current scope, make Audience OPTIONAL for holder-of-key
assertions, and define the difference in the instance docs.

--Richard






On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt  wrote:

> It is also important for a non-protocol purpose. Liability.
>
> If a 3rd party uses an assertion that was not intended for it, it cannot
> obviously hold the asserting party responsible.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Oct 16, 2014, at 8:43 AM, Brian Campbell 
> wrote:
>
> Thanks for your review and feedback, Richard. Replies are inline below...
>
> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
>
>> Richard Barnes has entered the following ballot position for
>> draft-ietf-oauth-assertions-17: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> "The assertion MUST contain an Audience that identifies the Authorization
>> Server as the intended audience.  Assertions that do not identify the
>> Authorization Server as an intended audience MUST be rejected."
>>
>> Could you please identify the threat model within which this "MUST" is
>> required?  This requirement doesn't follow from any of the threats
>> elaborated in Section 8.
>>
>> The Audience is only necessary if the Issuer wishes to constrain the set
>> of Authorization Servers with which an assertion may be used.  So ISTM
>> that this should be "MAY contain..."
>>
>>
>
> The audience restriction let's the issuer say specifically what relying
> party is allowed to consume the assertion, which ensures that the client
> can't use it somewhere else that it wasn't intended and that the relying
> party that receives the assertion can't turn around and use it to access
> some other service.
>
> Strictly speaking, you are right that the audience is only necessary if
> the Issuer wishes to constrain the set of Authorization Servers with which
> an assertion may be used. But the Issuer really really really should make
> that constraint and fully understanding the implications of not doing so is
> difficult and unlikely.
>
> There was a vulnerability in Google apps SAML a few years back that
> demonstrates how important audience restriction is and how it can be
> difficult for even very sophisticated providers to get it all right. I
> haven't had time to read it again to make sure but I think that this is the
> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
>
> I don't see what value allowing audience to be omitted brings other than
> that it is academically a possibility. But requiring it (hopefully, if the
> requirement is followed) helps reduce the possibility of a whole bunch of
> security problems that folks likely won't foresee.
>
>
>
>> --
>> COMMENT:
>> --
>>
>> "keyed message digest" -> "Message Authentication Code"
>>
>> That's the proper terminology [RFC4949], especially since there are MACs
>> that are not based on digests.
>>
>
> OK
>
>
>>
>> "This mechanism provides additional security properties." -- Please
>> delete this or elaborate on what security properties it provides.
>>
>
> Will delete.
>
>
>>
>> Section 8.2 should note that "Holder-of-Key Assertions" are also a
>> mitigation for this risk.
>>
>>
> OK
>
>
>
>> _

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Phil Hunt]

It is also important for a non-protocol purpose. Liability.

If a 3rd party uses an assertion that was not intended for it, it cannot 
obviously hold the asserting party responsible.  

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Oct 16, 2014, at 8:43 AM, Brian Campbell  wrote:

> Thanks for your review and feedback, Richard. Replies are inline below...
> 
> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-assertions-17: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> "The assertion MUST contain an Audience that identifies the Authorization
> Server as the intended audience.  Assertions that do not identify the
> Authorization Server as an intended audience MUST be rejected."
> 
> Could you please identify the threat model within which this "MUST" is
> required?  This requirement doesn't follow from any of the threats
> elaborated in Section 8.
> 
> The Audience is only necessary if the Issuer wishes to constrain the set
> of Authorization Servers with which an assertion may be used.  So ISTM
> that this should be "MAY contain..."
> 
> 
> 
> The audience restriction let's the issuer say specifically what relying party 
> is allowed to consume the assertion, which ensures that the client can't use 
> it somewhere else that it wasn't intended and that the relying party that 
> receives the assertion can't turn around and use it to access some other 
> service.
> 
> Strictly speaking, you are right that the audience is only necessary if the 
> Issuer wishes to constrain the set of Authorization Servers with which an 
> assertion may be used. But the Issuer really really really should make that 
> constraint and fully understanding the implications of not doing so is 
> difficult and unlikely. 
> 
> There was a vulnerability in Google apps SAML a few years back that 
> demonstrates how important audience restriction is and how it can be 
> difficult for even very sophisticated providers to get it all right. I 
> haven't had time to read it again to make sure but I think that this is the 
> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
> 
> I don't see what value allowing audience to be omitted brings other than that 
> it is academically a possibility. But requiring it (hopefully, if the 
> requirement is followed) helps reduce the possibility of a whole bunch of 
> security problems that folks likely won't foresee.
> 
>  
> --
> COMMENT:
> --
> 
> "keyed message digest" -> "Message Authentication Code"
> 
> That's the proper terminology [RFC4949], especially since there are MACs
> that are not based on digests.
> 
> OK
>  
> 
> "This mechanism provides additional security properties." -- Please
> delete this or elaborate on what security properties it provides.
> 
> Will delete.
>  
> 
> Section 8.2 should note that "Holder-of-Key Assertions" are also a
> mitigation for this risk.
> 
> 
> OK
>  
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[John Bradley]

Having an audience is an important part of keeping the assertions from being 
reused inappropriately.

I think the difference between this and PKIX is that a certificate references a 
private key so is in a sense only usable by the holder of that key.

If we were talking about holder of key /Proof of Possession JWT and SAML 
assertions then perhaps there is a corner case for not specifying an audience.

Using bearer assertions, I don't think the hypothetical flexibility gain is 
worth the inevitable security issues caused by not having an issuer, and 
people, not understanding the consequences of that.

John B.

On Oct 16, 2014, at 12:39 PM, Richard Barnes  wrote:

> On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones  
> wrote:
> Thanks for your review, Richard.  I'm replying to your DISCUSS about the 
> audience being required below...
> 
> -- Mike
> 
> > -Original Message-
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 15, 2014 8:48 PM
> > To: The IESG
> > Cc: draft-ietf-oauth-asserti...@tools.ietf.org; oauth-cha...@tools.ietf.org;
> > oauth@ietf.org
> > Subject: [OAUTH-WG] Richard Barnes' Discuss on 
> > draft-ietf-oauth-assertions-17:
> > (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-oauth-assertions-17: Discuss
> >
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this 
> > introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > "The assertion MUST contain an Audience that identifies the Authorization
> > Server as the intended audience.  Assertions that do not identify the
> > Authorization Server as an intended audience MUST be rejected."
> >
> > Could you please identify the threat model within which this "MUST" is 
> > required?
> > This requirement doesn't follow from any of the threats elaborated in 
> > Section 8.
> 
> Sure, this is to prevent a legitimate assertion intended for one 
> authorization server being captured by the attacker and sent to a different 
> authorization server.  Unless there's an audience for the authorization 
> server to check, there's no way for the authorization server to reject 
> assertions intended to be used by a different server.  Using the audience is 
> the normal way to prevent this attack.
> 
> That all assumes that the issuer of the assertion intends to limit it to a 
> specific authorization server.  That is not the case with many assertion 
> systems today, e.g., PKIX.
> 
>  
> > The Audience is only necessary if the Issuer wishes to constrain the set of
> > Authorization Servers with which an assertion may be used.  So ISTM that 
> > this
> > should be "MAY contain..."
> 
> Constraining the set to the intended server is basic to the security 
> guarantees.  If I can take a server intended for server1 and get server2 to 
> accept it, all security bets are off.
> 
> That's dramatically overstating things.  The only security bet that is off in 
> that case is that the assertion is not limited to one authorization server.  
> Which may or may not be the issuer's intent.
> 
> The only thing I could see justifying this requirement is something in the 
> overall OAuth architecture that requires authorizations to be scoped to a 
> specific authorization server.  If that exists, add a citation and I'll 
> clear.  Otherwise, this needs to be un-MUST-ed.
> 
> --Richard
> 
> 
>  
> 
> > --
> > COMMENT:
> > --
> >
> > "keyed message digest" -> "Message Authentication Code"
> >
> > That's the proper terminology [RFC4949], especially since there are MACs 
> > that
> > are not based on digests.
> >
> > "This mechanism provides additional security properties." -- Please delete 
> > this or
> > elaborate on what security properties it provides.
> >
> > Section 8.2 should note that "Holder-of-Key Assertions" are also a 
> > mitigation for
> > this risk.
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Brian Campbell]

Thanks for your review and feedback, Richard. Replies are inline below...

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes  wrote:

> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-assertions-17: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>
>
>
> --
> DISCUSS:
> --
>
> "The assertion MUST contain an Audience that identifies the Authorization
> Server as the intended audience.  Assertions that do not identify the
> Authorization Server as an intended audience MUST be rejected."
>
> Could you please identify the threat model within which this "MUST" is
> required?  This requirement doesn't follow from any of the threats
> elaborated in Section 8.
>
> The Audience is only necessary if the Issuer wishes to constrain the set
> of Authorization Servers with which an assertion may be used.  So ISTM
> that this should be "MAY contain..."
>
>

The audience restriction let's the issuer say specifically what relying
party is allowed to consume the assertion, which ensures that the client
can't use it somewhere else that it wasn't intended and that the relying
party that receives the assertion can't turn around and use it to access
some other service.

Strictly speaking, you are right that the audience is only necessary if the
Issuer wishes to constrain the set of Authorization Servers with which an
assertion may be used. But the Issuer really really really should make that
constraint and fully understanding the implications of not doing so is
difficult and unlikely.

There was a vulnerability in Google apps SAML a few years back that
demonstrates how important audience restriction is and how it can be
difficult for even very sophisticated providers to get it all right. I
haven't had time to read it again to make sure but I think that this is the
paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf

I don't see what value allowing audience to be omitted brings other than
that it is academically a possibility. But requiring it (hopefully, if the
requirement is followed) helps reduce the possibility of a whole bunch of
security problems that folks likely won't foresee.



> --
> COMMENT:
> --
>
> "keyed message digest" -> "Message Authentication Code"
>
> That's the proper terminology [RFC4949], especially since there are MACs
> that are not based on digests.
>

OK


>
> "This mechanism provides additional security properties." -- Please
> delete this or elaborate on what security properties it provides.
>

Will delete.


>
> Section 8.2 should note that "Holder-of-Key Assertions" are also a
> mitigation for this risk.
>
>
OK



> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes]

On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones 
wrote:

> Thanks for your review, Richard.  I'm replying to your DISCUSS about the
> audience being required below...
>
> -- Mike
>
> > -Original Message-
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 15, 2014 8:48 PM
> > To: The IESG
> > Cc: draft-ietf-oauth-asserti...@tools.ietf.org;
> oauth-cha...@tools.ietf.org;
> > oauth@ietf.org
> > Subject: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17:
> > (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-oauth-assertions-17: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > "The assertion MUST contain an Audience that identifies the Authorization
> > Server as the intended audience.  Assertions that do not identify the
> > Authorization Server as an intended audience MUST be rejected."
> >
> > Could you please identify the threat model within which this "MUST" is
> required?
> > This requirement doesn't follow from any of the threats elaborated in
> Section 8.
>
> Sure, this is to prevent a legitimate assertion intended for one
> authorization server being captured by the attacker and sent to a different
> authorization server.  Unless there's an audience for the authorization
> server to check, there's no way for the authorization server to reject
> assertions intended to be used by a different server.  Using the audience
> is the normal way to prevent this attack.
>

That all assumes that the issuer of the assertion intends to limit it to a
specific authorization server.  That is not the case with many assertion
systems today, e.g., PKIX.



> > The Audience is only necessary if the Issuer wishes to constrain the set
> of
> > Authorization Servers with which an assertion may be used.  So ISTM that
> this
> > should be "MAY contain..."
>
> Constraining the set to the intended server is basic to the security
> guarantees.  If I can take a server intended for server1 and get server2 to
> accept it, all security bets are off.
>

That's dramatically overstating things.  The only security bet that is off
in that case is that the assertion is not limited to one authorization
server.  Which may or may not be the issuer's intent.

The only thing I could see justifying this requirement is something in the
overall OAuth architecture that requires authorizations to be scoped to a
specific authorization server.  If that exists, add a citation and I'll
clear.  Otherwise, this needs to be un-MUST-ed.

--Richard




>
> > --
> > COMMENT:
> > --
> >
> > "keyed message digest" -> "Message Authentication Code"
> >
> > That's the proper terminology [RFC4949], especially since there are MACs
> that
> > are not based on digests.
> >
> > "This mechanism provides additional security properties." -- Please
> delete this or
> > elaborate on what security properties it provides.
> >
> > Section 8.2 should note that "Holder-of-Key Assertions" are also a
> mitigation for
> > this risk.
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Mike Jones]

Thanks for your review, Richard.  I'm replying to your DISCUSS about the 
audience being required below...

-- Mike

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes
> Sent: Wednesday, October 15, 2014 8:48 PM
> To: The IESG
> Cc: draft-ietf-oauth-asserti...@tools.ietf.org; oauth-cha...@tools.ietf.org;
> oauth@ietf.org
> Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17:
> (with DISCUSS and COMMENT)
> 
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-assertions-17: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> "The assertion MUST contain an Audience that identifies the Authorization
> Server as the intended audience.  Assertions that do not identify the
> Authorization Server as an intended audience MUST be rejected."
> 
> Could you please identify the threat model within which this "MUST" is 
> required?
> This requirement doesn't follow from any of the threats elaborated in Section 
> 8.

Sure, this is to prevent a legitimate assertion intended for one authorization 
server being captured by the attacker and sent to a different authorization 
server.  Unless there's an audience for the authorization server to check, 
there's no way for the authorization server to reject assertions intended to be 
used by a different server.  Using the audience is the normal way to prevent 
this attack.

> The Audience is only necessary if the Issuer wishes to constrain the set of
> Authorization Servers with which an assertion may be used.  So ISTM that this
> should be "MAY contain..."

Constraining the set to the intended server is basic to the security 
guarantees.  If I can take a server intended for server1 and get server2 to 
accept it, all security bets are off.

> --
> COMMENT:
> --
> 
> "keyed message digest" -> "Message Authentication Code"
> 
> That's the proper terminology [RFC4949], especially since there are MACs that
> are not based on digests.
> 
> "This mechanism provides additional security properties." -- Please delete 
> this or
> elaborate on what security properties it provides.
> 
> Section 8.2 should note that "Holder-of-Key Assertions" are also a mitigation 
> for
> this risk.
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth