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

[Mike Jones <[e-mail]>]

Thanks!
________________________________
From: Richard Barnes<mailto:[e-mail]>
Sent: ‎11/‎11/‎2014 3:30 PM
To: Mike Jones<mailto:[e-mail]>
Cc: Brian Campbell<mailto:[e-mail]>; John Bradley<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Pete Resnick<mailto:[e-mail]>; oauth<mailto:[e-mail]>; The IESG<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Friday, October 17, 2014 8:23 AM
To: Richard Barnes
Cc: John Bradley; [e-mail]<mailto:[e-mail]>; Pete Resnick; oauth; The IESG; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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. - [phone]<tel:%2B1%20%28858%29651-4478>



_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth