Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
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)
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-saml2-bearer-21: (with DISCUSS)
That's what you get for duplicating all the text :) On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell wrote: > Basically the same response to the basically same question as from > http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html > > On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-oauth-saml2-bearer-21: 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-saml2-bearer/ >> >> >> >> -- >> DISCUSS: >> -- >> >> As with draft-ietf-oauth-assertions, the requirement for an >> element seems entirely unnecessary. Holding this DISCUSS point pending >> that discussion and its reflection in this document. >> >> "Assertions that do not identify the Authorization Server as an intended >> audience MUST be rejected." -- What does it mean for an assertion to >> "identify the Authorization Server"? Does the specified need >> to match the entire URL of the relevant OAuth endpoint? Just the origin? >> Just the domain? Does the URL need to be canonicalized? >> >> >> >> >> ___ >> 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-jwt-bearer-10: (with DISCUSS and COMMENT)
On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell wrote: > Thanks for your review and feedback on this one too, Richard. Replies are > inline below... > > On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-oauth-jwt-bearer-10: 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-jwt-bearer/ >> >> >> >> -- >> DISCUSS: >> -- >> >> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim >> seems entirely unnecessary. Holding this DISCUSS point pending that >> discussion >> and its reflection in this document. >> >> "Assertions that do not identify the Authorization Server as an intended >> audience MUST be rejected." -- What does it mean for an assertion to >> "identify >> the Authorization Server"? Does the specified need to match >> the >> entire URL of the relevant OAuth endpoint? Just the origin? Just the >> domain? >> Does the URL need to be canonicalized? >> >> > > No c14n, as it says, "... compare the audience values using the Simple > String Comparison method defined in Section 6.2.1 of RFC 3986." > > Basically the AS is at liberty to determine how it identifies itself. Some > guidance on using the token endpoint is provided but it's ultimately up to > the AS (or the larger deployment in which the AS exists). The acceptable > value is one of a few bits of information that must be exchanged for this > profile, which is discussed in the Interoperability Considerations > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 > Sigh. "Negotiate it out of band" is a terrible, non-scalable, not-in-the-spirit-of-the-Internet answer. But I guess I might clear on this if you could add something like the following: "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings to be used as the Audience for a given Authorization Server must be configured out-of-band by the Authorization Server and the Issuer of the assertion." But is there seriously no answer that the WG could agree on? This seems like it should be a pretty simple question. Was it even discussed? --Richard > Some more explanation/discussion of it is in the middle(ish) of this reply > to a similar comment from Stephen Farrell > http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html > > > >> -- >> COMMENT: >> -- >> >> "keyed message digest" -> "MAC" >> > > Yep. > > >> >> Both this and the SAML document could save a lot of bits by just being >> subsections of the -assertions document. >> > > The structure and relationship of the documents was decided on by the WG > nearly three years ago. There is some duplication but it's believed to be > more approachable this way - particularly for those implementing just one > assertion type. > ___ 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)
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] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Alright, I'll add RS256 and http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 as mandatory to implement in the next revision of draft-ietf-oauth-jwt-bearer and draft-ietf-oauth-saml2-bearer respectively. Thanks for the pointers, Stephen. On Thu, Oct 16, 2014 at 3:57 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > > > On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> Hiya in return and inline below... >> >> On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell < >> stephen.farr...@cs.tcd.ie> wrote: >> >>> >>> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the >>> JOSE one has only H256 as required. >>> >>> Doesn't that seem like one is unacceptably old and the other >>> is not great for this purpose? >>> >> >> Admittedly, I was a little worried you'd say that :) >> >> >>> >>> My suggestion would be to add rsa-sha256 as MTI for these, as an >>> addition to whatever JOSE and SAML make MTI. But I'd be happy to >>> clear if you made any modern signature alg MTI. >>> >>> >> Honestly, in my view, an MIT on these doesn't make a whole lot of sense >> as I think what's actually implemented/supported will be dictated by the >> larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is >> that an MIT in these specs would likely be ignored and/or not influence >> implementers/deployers. So my preference would be to leave MTI out of these. >> >> But if you're not swayed by that line of thinking, and I'm guessing >> you're not, rsa-sha256 is probably the most appropriate choice. Could you >> give some guidance and/or point to examples of where and how to say that >> appropriately in the documents? Thanks! >> > > I'm going to back Stephen up on this one. It best that we do point out > the right thing to do, even if it's not always followed. Some will expect > implementations to be complaint to the standard and that will hopefully > drive implementations to better choices for algorithms. We have too many > issues of deployed code and applications using things they should not > (SSLv3). > > >> >> >>> Cheers, >>> S. >>> >>> PS: Stuff below is fine. >>> >>> >> Great, thank you. >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > > Best regards, > Kathleen > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell wrote: > Hiya in return and inline below... > > On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell < > stephen.farr...@cs.tcd.ie> wrote: > >> >> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the >> JOSE one has only H256 as required. >> >> Doesn't that seem like one is unacceptably old and the other >> is not great for this purpose? >> > > Admittedly, I was a little worried you'd say that :) > > >> >> My suggestion would be to add rsa-sha256 as MTI for these, as an >> addition to whatever JOSE and SAML make MTI. But I'd be happy to >> clear if you made any modern signature alg MTI. >> >> > Honestly, in my view, an MIT on these doesn't make a whole lot of sense as > I think what's actually implemented/supported will be dictated by the > larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is > that an MIT in these specs would likely be ignored and/or not influence > implementers/deployers. So my preference would be to leave MTI out of these. > > But if you're not swayed by that line of thinking, and I'm guessing you're > not, rsa-sha256 is probably the most appropriate choice. Could you give > some guidance and/or point to examples of where and how to say that > appropriately in the documents? Thanks! > I'm going to back Stephen up on this one. It best that we do point out the right thing to do, even if it's not always followed. Some will expect implementations to be complaint to the standard and that will hopefully drive implementations to better choices for algorithms. We have too many issues of deployed code and applications using things they should not (SSLv3). > > >> Cheers, >> S. >> >> PS: Stuff below is fine. >> >> > Great, thank you. > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
On 16/10/14 22:39, Brian Campbell wrote: > Hiya in return and inline below... > > On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell > wrote: > >> >> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the >> JOSE one has only H256 as required. >> >> Doesn't that seem like one is unacceptably old and the other >> is not great for this purpose? >> > > Admittedly, I was a little worried you'd say that :) I'm glad we're not surprising one another:-) > > >> >> My suggestion would be to add rsa-sha256 as MTI for these, as an >> addition to whatever JOSE and SAML make MTI. But I'd be happy to >> clear if you made any modern signature alg MTI. >> >> > Honestly, in my view, an MIT on these doesn't make a whole lot of sense as > I think what's actually implemented/supported will be dictated by the > larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is > that an MIT in these specs would likely be ignored and/or not influence > implementers/deployers. So my preference would be to leave MTI out of these. > > But if you're not swayed by that line of thinking, and I'm guessing you're > not, rsa-sha256 is probably the most appropriate choice. Could you give > some guidance and/or point to examples of where and how to say that > appropriately in the documents? Thanks! Sure, I'd say probably best is for the jwt one to say that RS256 MUST be supported and for the saml one say that [1] MUST be supported. (Check [2] for rsa-sha256 for some text) A sentence in each is all's needed. Cheers, S. [1] http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [2] http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130411/ > > > >> Cheers, >> S. >> >> PS: Stuff below is fine. >> >> > Great, thank you. > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Hiya in return and inline below... On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell wrote: > > Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the > JOSE one has only H256 as required. > > Doesn't that seem like one is unacceptably old and the other > is not great for this purpose? > Admittedly, I was a little worried you'd say that :) > > My suggestion would be to add rsa-sha256 as MTI for these, as an > addition to whatever JOSE and SAML make MTI. But I'd be happy to > clear if you made any modern signature alg MTI. > > Honestly, in my view, an MIT on these doesn't make a whole lot of sense as I think what's actually implemented/supported will be dictated by the larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is that an MIT in these specs would likely be ignored and/or not influence implementers/deployers. So my preference would be to leave MTI out of these. But if you're not swayed by that line of thinking, and I'm guessing you're not, rsa-sha256 is probably the most appropriate choice. Could you give some guidance and/or point to examples of where and how to say that appropriately in the documents? Thanks! > Cheers, > S. > > PS: Stuff below is fine. > > Great, thank you. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call
a deployment-related question that I have around this topic: it seems that authentication using OAuth 2.0 is possible today for confidential clients using the code flow, with a registered redirect_uri, not consuming/storing/using refresh_tokens, and assuming that there's an API that returns user identity info in JSON format and the claim that uniquely identifies the user is known by the client. The usage/presence of the short-lived code in this scenario/flow guarantees that the user has just authenticated, and the audience issue is covered by the fact that the code (thus the access_token in the token endpoint response) are bound to the confidential client, all as per standard OAuth 2.0 semantics. 2 questions about that: - is this right or am I overlooking some security/semantics issues here - if right, would it make sense to acknowledge that or is that muddying the waters even more (the current text does seem to only implicitly acknowledge this) There may be value in acknowledging this because the majority of OAuth 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON response anyhow [1] thus achieving login semantics with plain OAuth 2.0 and a bit of common practice wrt. the user info API. Thanks for the excellent write-up! Hans. PS: I've been asked this concrete question about Spotify's OAuth 2.0 support and in fact I'm able to configure Spotify as an IDP to my OIDC client with a minor workaround to abstain from expecting an id_token in the token endpoint response, but calling the Spotify specific user info endpoint like it was a standards-compliant OpenID Connect endpoint. (the client has a per-OP configurable unique user id claim name anyhow). On 10/16/14, 7:27 PM, Richer, Justin P. wrote: Ah yes, good catch! If only someone would put up a webpage describing the difference between authorization and authentication and why people need to stop confusing the two. Oh wait... On Oct 16, 2014, at 1:06 PM, Hans Zandbelt wrote: About the write-up: at the end of the metaphor section it says: "These recipes each add a number of items, such as a common profile API, to OAuth to create an authorization protocol." whereas I believe that should read "to create an authentication protocol" Hans. On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: Participants: * Brian Campbell * John Bradley * Derek Atkins * Phil Hunt * William Kim * Josh Mandel * Hannes Tschofenig Notes: Justin distributed a draft writeup and explained the reasoning behind it. The intended purpose is to put the write-up (after enough review) on oauth.net. See attachments. Justin solicited feedback from the conference call participants and from the working group. One discussion item was specifically related to the concept of audience restrictions, which comes in two flavours: (a) restriction of the access token regarding the resource server and (b) restriction of the id token regarding the client. Obviously, it is necessary to have both of these audience restrictions in place and to actually check them. The group then went into a discussion about the use of pseudonyms in authentication and the problems deployments ran into when they used pseudonyms together with a wide range of attributes that identified users nevertheless. Phil suggested to produce a write-up about this topic. Finally, the group started a discussion about potential actions for the OAuth working groups. Two activities were mentioned, namely to produce an IETF draft of the write-up Justin has prepared as a "formal" response to the problems with authentication using OAuth and, as a second topic, potential re-chartering of the OAuth working group to work on some solutions in this area. Hannes suggested to postpone these discussions and to first finish the write-up Justin had distributed. Ciao Hannes & Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandb...@pingidentity.com | Ping Identity ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandb...@pingidentity.com | Ping Identity ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell wrote: > > > Some stuff needs to be exchanged out-of-band for this to work. > > Entity/issuer/audience identifiers are part of that. This need is > discussed > > in the Interoperability Considerations at > > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > > So I think it'd be good to explicitly call out that these > mappings are basically required and that they can be fraught > (e.g. if someone uses wildcards badly, which they do). > OK, I will add something to that effect in the next revisions. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)
Basically the same response to the basically same question as from http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: 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-saml2-bearer/ > > > > -- > DISCUSS: > -- > > As with draft-ietf-oauth-assertions, the requirement for an > element seems entirely unnecessary. Holding this DISCUSS point pending > that discussion and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify the Authorization Server"? Does the specified need > to match the entire URL of the relevant OAuth endpoint? Just the origin? > Just the domain? Does the URL need to be canonicalized? > > > > > ___ > 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] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Hiya, On 16/10/14 21:06, Brian Campbell wrote: > Thanks for your review and feedback on this one too, Stephen. Replies are > inline below... > > On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell > wrote: > >> Stephen Farrell 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: >> -- >> >> >> Putting one discuss here rather than one on each of the other >> docs. We can fix that as appropriate after we chat. Where are >> the MTI signature and mac algs for these specified? If those >> can be tracked back via the SAML and jose docs that's fine, >> but I'm not sure if they are. >> >> > > I believe they can be. > > JOSE Implementation Requirements for JWS are in the table in JWA §3.1 > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-3.1 > > And there's §5 SAML and XML Signature Syntax and Processing > http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the JOSE one has only H256 as required. Doesn't that seem like one is unacceptably old and the other is not great for this purpose? My suggestion would be to add rsa-sha256 as MTI for these, as an addition to whatever JOSE and SAML make MTI. But I'd be happy to clear if you made any modern signature alg MTI. Cheers, S. PS: Stuff below is fine. > > > > >> -- >> COMMENT: >> -- >> >> >> - general: What prevents/detects conflicts between the oauth >> scope parameter and the saml or jwt equivalent? Are there >> other bits of replicated data that could be the basis for a >> vulnerability? >> >> (The comment below applies for both saml and jwt so >> putting it here.) >> > > Scope is not represented inside the assertion (JWT or SAML) so there's no > potential for conflict. > > >> >> - The no replay protection issue was debated in the >> WG wasn't it? (I think I recall it, not sure.) Seems like a >> bad plan to me to not require at least implementation of >> replay protection in the AS so that it can be turned on. Can >> you point me at where that was discussed on the list? >> >> > I described my recollection and justification of the optionality of one > particular type of replay protection in a message yesterday: > http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html > > It's worth mentioning that there are different ideas of what replay is and > what to protect against. The one particular type mentioned above is pretty > narrow - checking to see if the same token is used again at the same > relying party. > > There are other kinds of more sinister replay which are prevented by > properly audience restricting the assertions. 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 where > 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. > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Hiya, Mostly fine just a couple of notes. On 16/10/14 20:28, Brian Campbell wrote: > Thanks for your review and feedback, Stephen. Replies are inline below... > > On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-saml2-bearer-21: No Objection >> >> 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-saml2-bearer/ >> >> >> >> -- >> COMMENT: >> -- >> >> >> - intro para2: might be nice (no more) to add some refs to >> other protocols that use SAML. >> > > > OK > > > >> - 2.2: What are "padding bits" in 4648? I don't recall such. >> (But may be misremembering.) >> > > > FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) > so, trusting in him, I just took the text without question. > > But I believe it means and is basically just restating what is said near > the middle/end of §4 in 4648, "When fewer than 24 input bits are available > in an input group, bits with value zero are added (on the right) to form an > integral number of 6-bit groups." - > https://tools.ietf.org/html/rfc4648#section-4 > > Are you saying Peter is wrong? ;) Heh. > > > - section 3, list item 2: This doesn't quite say that the >> token endpoint URL MUST (in the absence of another profile) be >> in an Audience element. Why not? The text seems to me to allow >> for the AS to map the token endpoint URL to any value in an >> Audience element that the AS finds ok. I suspect that might be >> unwise, but it at least needs to be clear. Is that the text >> being ambiguous or me being paranoid/wrong? > > > > You are not wrong. But it's intentionally that way to allow for how this > will actually be used and deployed (and currently is). It accommodates how > SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as > well as providing the token endpoint URL as a means of identifying the AS > as an audience for deployments that wouldn't otherwise have a SAML 2.0 > entity id to use. > > This profile is just a small piece of a bigger picture and, as such, needs > to fit into the larger picture. Oftentimes it will be deployed as a > complement to existing SAML deployments where trust has already been > established and keys and identifiers have already been exchanged, in which > case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that > context should be used as the audience. But I couldn't presume that would > always be the case so needed to provide some guidance for what to use as > the audience in the absence of a larger SAML deployment. OAuth doesn't have > any kind of discovery or metadata, only endpoints to identify an AS, and > this draft isn't going to address that. So the token endpoint is really the > only option. > > I understand the desire to have something neat and tidy here but it's just > not feasible to do so and reconcile with the way this kind of software is > actually deployed and used. > > Some stuff needs to be exchanged out-of-band for this to work. > Entity/issuer/audience identifiers are part of that. This need is discussed > in the Interoperability Considerations at > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught (e.g. if someone uses wildcards badly, which they do). Cheers, S. > > > >> Same point seems >> to apply elsewhere too: >>= in item 3.A where it says "typically identifies" but >>does not say how. >> > > Could be an email, a username, a guid, a distinguished name, a certificate, > a persistent pseudonymous id, a transient pseudonymous id, etc. > > Like all cross domain identity systems, part of the deployment is > determining how identities will be conveyed. Nailing that down any more is > way beyond the scope of this draft. It's also mentioned in the > Interoperability Considerations. > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > > >>= in item 5 "or an acceptable alias" >> > > To give the AS some flexibility in what it accepts as identifying itself. > > > >> >> - section 3, item 7: How might an AS know that "the Assertion >> was issued with the intention that the client act autonomously >> on behalf of the subject"? >> >> > Item 7 is intended to provide a way to single that to the AS - and it's > really about if the user dir
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
Thanks for your review and feedback on this one too, Richard. Replies are inline below... On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: 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-jwt-bearer/ > > > > -- > DISCUSS: > -- > > As with draft-ietf-oauth-assertions, the requirement for an "aud" claim > seems entirely unnecessary. Holding this DISCUSS point pending that > discussion > and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify > the Authorization Server"? Does the specified need to match > the > entire URL of the relevant OAuth endpoint? Just the origin? Just the > domain? > Does the URL need to be canonicalized? > > No c14n, as it says, "... compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986." Basically the AS is at liberty to determine how it identifies itself. Some guidance on using the token endpoint is provided but it's ultimately up to the AS (or the larger deployment in which the AS exists). The acceptable value is one of a few bits of information that must be exchanged for this profile, which is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 Some more explanation/discussion of it is in the middle(ish) of this reply to a similar comment from Stephen Farrell http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html > -- > COMMENT: > -- > > "keyed message digest" -> "MAC" > Yep. > > Both this and the SAML document could save a lot of bits by just being > subsections of the -assertions document. > The structure and relationship of the documents was decided on by the WG nearly three years ago. There is some duplication but it's believed to be more approachable this way - particularly for those implementing just one assertion type. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Thanks for your review and feedback on this one too, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell wrote: > Stephen Farrell 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: > -- > > > Putting one discuss here rather than one on each of the other > docs. We can fix that as appropriate after we chat. Where are > the MTI signature and mac algs for these specified? If those > can be tracked back via the SAML and jose docs that's fine, > but I'm not sure if they are. > > I believe they can be. JOSE Implementation Requirements for JWS are in the table in JWA §3.1 https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-3.1 And there's §5 SAML and XML Signature Syntax and Processing http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf > -- > COMMENT: > -- > > > - general: What prevents/detects conflicts between the oauth > scope parameter and the saml or jwt equivalent? Are there > other bits of replicated data that could be the basis for a > vulnerability? > > (The comment below applies for both saml and jwt so > putting it here.) > Scope is not represented inside the assertion (JWT or SAML) so there's no potential for conflict. > > - The no replay protection issue was debated in the > WG wasn't it? (I think I recall it, not sure.) Seems like a > bad plan to me to not require at least implementation of > replay protection in the AS so that it can be turned on. Can > you point me at where that was discussed on the list? > > I described my recollection and justification of the optionality of one particular type of replay protection in a message yesterday: http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html It's worth mentioning that there are different ideas of what replay is and what to protect against. The one particular type mentioned above is pretty narrow - checking to see if the same token is used again at the same relying party. There are other kinds of more sinister replay which are prevented by properly audience restricting the assertions. 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 where 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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call
Those interested in helping edit the text directly can follow along on this GitHub fork: https://github.com/jricher/oauth.net/tree/authentication Once a reasonable number of eyes have seen that page, we'll get it published onto oauth.net. Aaron Parecki has offered to add a "Draft" banner to the article page, inviting comments and edits via GitHub. -- Justin On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig wrote: > Participants: > > * Brian Campbell > * John Bradley > * Derek Atkins > * Phil Hunt > * William Kim > * Josh Mandel > * Hannes Tschofenig > > > Notes: > > Justin distributed a draft writeup and explained the reasoning behind > it. The intended purpose is to put the write-up (after enough review) on > oauth.net. See attachments. Justin solicited feedback from the > conference call participants and from the working group. > > One discussion item was specifically related to the concept of audience > restrictions, which comes in two flavours: (a) restriction of the access > token regarding the resource server and (b) restriction of the id token > regarding the client. Obviously, it is necessary to have both of these > audience restrictions in place and to actually check them. > > The group then went into a discussion about the use of pseudonyms in > authentication and the problems deployments ran into when they used > pseudonyms together with a wide range of attributes that identified > users nevertheless. Phil suggested to produce a write-up about this topic. > > Finally, the group started a discussion about potential actions for the > OAuth working groups. Two activities were mentioned, namely to produce > an IETF draft of the write-up Justin has prepared as a "formal" response > to the problems with authentication using OAuth and, as a second topic, > potential re-chartering of the OAuth working group to work on some > solutions in this area. Hannes suggested to postpone these discussions > and to first finish the write-up Justin had distributed. > > Ciao > Hannes & Derek > 2.html> 2.pdf>___ > 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] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Thanks for your review and feedback, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > 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-saml2-bearer/ > > > > -- > COMMENT: > -- > > > - intro para2: might be nice (no more) to add some refs to > other protocols that use SAML. > OK > - 2.2: What are "padding bits" in 4648? I don't recall such. > (But may be misremembering.) > FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) so, trusting in him, I just took the text without question. But I believe it means and is basically just restating what is said near the middle/end of §4 in 4648, "When fewer than 24 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 6-bit groups." - https://tools.ietf.org/html/rfc4648#section-4 Are you saying Peter is wrong? ;) - section 3, list item 2: This doesn't quite say that the > token endpoint URL MUST (in the absence of another profile) be > in an Audience element. Why not? The text seems to me to allow > for the AS to map the token endpoint URL to any value in an > Audience element that the AS finds ok. I suspect that might be > unwise, but it at least needs to be clear. Is that the text > being ambiguous or me being paranoid/wrong? You are not wrong. But it's intentionally that way to allow for how this will actually be used and deployed (and currently is). It accommodates how SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as well as providing the token endpoint URL as a means of identifying the AS as an audience for deployments that wouldn't otherwise have a SAML 2.0 entity id to use. This profile is just a small piece of a bigger picture and, as such, needs to fit into the larger picture. Oftentimes it will be deployed as a complement to existing SAML deployments where trust has already been established and keys and identifiers have already been exchanged, in which case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that context should be used as the audience. But I couldn't presume that would always be the case so needed to provide some guidance for what to use as the audience in the absence of a larger SAML deployment. OAuth doesn't have any kind of discovery or metadata, only endpoints to identify an AS, and this draft isn't going to address that. So the token endpoint is really the only option. I understand the desire to have something neat and tidy here but it's just not feasible to do so and reconcile with the way this kind of software is actually deployed and used. Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > Same point seems > to apply elsewhere too: >= in item 3.A where it says "typically identifies" but >does not say how. > Could be an email, a username, a guid, a distinguished name, a certificate, a persistent pseudonymous id, a transient pseudonymous id, etc. Like all cross domain identity systems, part of the deployment is determining how identities will be conveyed. Nailing that down any more is way beyond the scope of this draft. It's also mentioned in the Interoperability Considerations. https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 >= in item 5 "or an acceptable alias" > To give the AS some flexibility in what it accepts as identifying itself. > > - section 3, item 7: How might an AS know that "the Assertion > was issued with the intention that the client act autonomously > on behalf of the subject"? > > Item 7 is intended to provide a way to single that to the AS - and it's really about if the user directly authenticated or not. The issuer of the assertion will know (usually) if the user authenticated directly or if the assertion is being issued about the subject based on some other trust relationship with the client. The same section was discussed in Pete Resnick's review, near the end of http://www.ietf.org/mail-archive/web/oauth/current/msg13599.html with the suggestion of saying "directly authenticated" in the first sentence to be more clear about it. But I'm open to ad
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Ah fair enough, forgot that. S. On 16/10/14 14:10, Brian Campbell wrote: > A JWT, by it's very definition, is a set of base64url pieces concatenated > together with dot "." characters (which is also URL safe). So no additional > encoding or serialization of the JWT is needed. > > On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-jwt-bearer-10: No Objection >> >> 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-jwt-bearer/ >> >> >> >> -- >> COMMENT: >> -- >> >> >> - 2.1, assertion parameter: How come this one does not talk >> about base64url whereas the saml one does? >> >> >> ___ >> 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] Notes from 2nd "OAuth & Authentication" Conference Call
Same here -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Thursday, October 16, 2014 10:17 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call For what it's worth, I was on the call too - until I and Brian left to join the telechat for the OAuth assertions drafts. -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, October 16, 2014 9:55 AM To: oauth@ietf.org Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Participants: * Brian Campbell * John Bradley * Derek Atkins * Phil Hunt * William Kim * Josh Mandel * Hannes Tschofenig Notes: Justin distributed a draft writeup and explained the reasoning behind it. The intended purpose is to put the write-up (after enough review) on oauth.net. See attachments. Justin solicited feedback from the conference call participants and from the working group. One discussion item was specifically related to the concept of audience restrictions, which comes in two flavours: (a) restriction of the access token regarding the resource server and (b) restriction of the id token regarding the client. Obviously, it is necessary to have both of these audience restrictions in place and to actually check them. The group then went into a discussion about the use of pseudonyms in authentication and the problems deployments ran into when they used pseudonyms together with a wide range of attributes that identified users nevertheless. Phil suggested to produce a write-up about this topic. Finally, the group started a discussion about potential actions for the OAuth working groups. Two activities were mentioned, namely to produce an IETF draft of the write-up Justin has prepared as a "formal" response to the problems with authentication using OAuth and, as a second topic, potential re-chartering of the OAuth working group to work on some solutions in this area. Hannes suggested to postpone these discussions and to first finish the write-up Justin had distributed. Ciao Hannes & Derek ___ 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] Notes from 2nd "OAuth & Authentication" Conference Call
Ah yes, good catch! If only someone would put up a webpage describing the difference between authorization and authentication and why people need to stop confusing the two. Oh wait... On Oct 16, 2014, at 1:06 PM, Hans Zandbelt wrote: > About the write-up: at the end of the metaphor section it says: > "These recipes each add a number of items, such as a common profile API, to > OAuth to create an authorization protocol." > > whereas I believe that should read "to create an authentication protocol" > > Hans. > > On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >> Participants: >> >> * Brian Campbell >> * John Bradley >> * Derek Atkins >> * Phil Hunt >> * William Kim >> * Josh Mandel >> * Hannes Tschofenig >> >> >> Notes: >> >> Justin distributed a draft writeup and explained the reasoning behind >> it. The intended purpose is to put the write-up (after enough review) on >> oauth.net. See attachments. Justin solicited feedback from the >> conference call participants and from the working group. >> >> One discussion item was specifically related to the concept of audience >> restrictions, which comes in two flavours: (a) restriction of the access >> token regarding the resource server and (b) restriction of the id token >> regarding the client. Obviously, it is necessary to have both of these >> audience restrictions in place and to actually check them. >> >> The group then went into a discussion about the use of pseudonyms in >> authentication and the problems deployments ran into when they used >> pseudonyms together with a wide range of attributes that identified >> users nevertheless. Phil suggested to produce a write-up about this topic. >> >> Finally, the group started a discussion about potential actions for the >> OAuth working groups. Two activities were mentioned, namely to produce >> an IETF draft of the write-up Justin has prepared as a "formal" response >> to the problems with authentication using OAuth and, as a second topic, >> potential re-chartering of the OAuth working group to work on some >> solutions in this area. Hannes suggested to postpone these discussions >> and to first finish the write-up Justin had distributed. >> >> Ciao >> Hannes & Derek >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity > > ___ > 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] Notes from 2nd "OAuth & Authentication" Conference Call
For what it's worth, I was on the call too - until I and Brian left to join the telechat for the OAuth assertions drafts. -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, October 16, 2014 9:55 AM To: oauth@ietf.org Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Participants: * Brian Campbell * John Bradley * Derek Atkins * Phil Hunt * William Kim * Josh Mandel * Hannes Tschofenig Notes: Justin distributed a draft writeup and explained the reasoning behind it. The intended purpose is to put the write-up (after enough review) on oauth.net. See attachments. Justin solicited feedback from the conference call participants and from the working group. One discussion item was specifically related to the concept of audience restrictions, which comes in two flavours: (a) restriction of the access token regarding the resource server and (b) restriction of the id token regarding the client. Obviously, it is necessary to have both of these audience restrictions in place and to actually check them. The group then went into a discussion about the use of pseudonyms in authentication and the problems deployments ran into when they used pseudonyms together with a wide range of attributes that identified users nevertheless. Phil suggested to produce a write-up about this topic. Finally, the group started a discussion about potential actions for the OAuth working groups. Two activities were mentioned, namely to produce an IETF draft of the write-up Justin has prepared as a "formal" response to the problems with authentication using OAuth and, as a second topic, potential re-chartering of the OAuth working group to work on some solutions in this area. Hannes suggested to postpone these discussions and to first finish the write-up Justin had distributed. Ciao Hannes & Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call
About the write-up: at the end of the metaphor section it says: "These recipes each add a number of items, such as a common profile API, to OAuth to create an authorization protocol." whereas I believe that should read "to create an authentication protocol" Hans. On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: Participants: * Brian Campbell * John Bradley * Derek Atkins * Phil Hunt * William Kim * Josh Mandel * Hannes Tschofenig Notes: Justin distributed a draft writeup and explained the reasoning behind it. The intended purpose is to put the write-up (after enough review) on oauth.net. See attachments. Justin solicited feedback from the conference call participants and from the working group. One discussion item was specifically related to the concept of audience restrictions, which comes in two flavours: (a) restriction of the access token regarding the resource server and (b) restriction of the id token regarding the client. Obviously, it is necessary to have both of these audience restrictions in place and to actually check them. The group then went into a discussion about the use of pseudonyms in authentication and the problems deployments ran into when they used pseudonyms together with a wide range of attributes that identified users nevertheless. Phil suggested to produce a write-up about this topic. Finally, the group started a discussion about potential actions for the OAuth working groups. Two activities were mentioned, namely to produce an IETF draft of the write-up Justin has prepared as a "formal" response to the problems with authentication using OAuth and, as a second topic, potential re-chartering of the OAuth working group to work on some solutions in this area. Hannes suggested to postpone these discussions and to first finish the write-up Justin had distributed. Ciao Hannes & Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandb...@pingidentity.com | Ping Identity ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
On 10/16/14 7:56 AM, Brian Campbell wrote: Thanks for your review and feedback on this one too, Pete. Replies are inline below... On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick mailto:presn...@qti.qualcomm.com>> wrote: 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. Apologies for any haphazardness. No worries. As you've discovered, throughout the organization we're pretty bad about consistent use of it, so if you use other RFCs for examples, you get weird results. I'm very happy to see that you're trying to get this right. But the second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than one SAML Assertion. If you simply can't, it's just s/MUST contain/contains.) It's intended to be both definitional and restrictive - that it contains an assertion but not more than one. The Response document in SAML Web SSO allows for multiple assertions and it has turned out to be quite a pain to deal with in practice while not adding any real value. While it's not entirely clear how one might try and stick more than one assertion in this parameter given the serialization, I still wanted to explicitly preclude it. Ah, good. Then some sort of MUST is appropriate. Given that explanation of the intent, would you suggest an alternative wording of that sentence? Or is it okay as is? I think it's OK as is, but would be better if you had the requirement on the right thing: The value of the "assertion" parameter contains a single SAML 2.0 Assertion. It MUST NOT contain more than one SAML 2.0 assertion. That makes it clear that you're not simply saying "Put the SAML 2.0 Assertion in here." You're saying, "Don't try to squeeze in more than one." The base64url encoding MUST is fine, because you don't want people sticking in raw XML, but the SHOULD NOTs for line wrapping and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT), and therefore this SHOULD NOT really isn't about interoperability so much as neatness (in which case they SHOULD NOTs are not appropriate)? Yes, the base64 decoder still has to be prepared to deal with line wrapping and padding. In my experience most decoders are very capable of it. And stripping the white-space and "="s prior to decoding is easy enough for those using a decoder that can't. The SHOULD NOT is about neatness but also in a way about interop in that it's intended to help avoid common implementation problems that can arise with urlencoding the parameter value (either not encoding or double encoding, etc.). Base64url without line wraps and padding dosn't need urlencoding and doesn't change if urlencoding is applied. That was the thinking behind the SHOULD NOTs there. As I try and articulate the reasoning, it does feel like maybe it should have been a MUST NOT. I guess I was looking to channel Postel a bit in being somewhat liberal in what is accepted with padding/no padding and line wraps/no line wraps while using the SHOULD NOTs to suggest that clients be conservative in what they send. Thoughts about what to do with it, given that reasoning? I agree with your gut: If implementations are going to bump into other implementations that fail to encode properly or double encode when encountering line wraps and padding, then you should say MUST NOT. You might even want to say, "Due to some poor implementations, you MUST NOT use line wrapping or padding when you create these things, but you MUST decode them if you receive them". 3 - Subpoint 2: Just for clarification, I like the non-passive sentence better: "The Authorization Server MUST reject any assertion that does not contain its own identity as the intended audience." Yes, on seeing it written that way, I also like it better. Just to make sure I'm on the same page. The sentence you suggest would replace the second to last sentence in #2 that currently says, "Assertions that do not identify [...] MUST be rejected."? Correct. Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not conflicting? Can you not have an authenticated subject with an autonomously acting client? Perhaps I've misused the words but, yes, that's the idea. An autonomously acting client is meant to describe a client that's acting without the user being present. The act of direct user authentication with the assertion issuer seems like the way to differentiate between the user being present for things and the client doing things "in the background" for the user. Both are valid use cases. Item 7 is looking to provide the AS with some clue as to which is happening. Ah, so what you mean by "the Assertion issuer authenti
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
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)
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] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Thanks for your review, Benoit. Replies are inline below... > -Original Message- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, October 16, 2014 5:34 AM > To: The IESG > Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-saml2-bea...@tools.ietf.org; > oauth@ietf.org > Subject: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2- > bearer-21: (with COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > 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-saml2-bearer/ > > > > -- > COMMENT: > -- > > I cleared my DISCUSS on the basis that RFC 6755 will be moved to an > informative > reference in response to this process issue: IDnits complains of a normative > reference to Informational document RFC 6755, which was not noted in the Last > Call announcement. Yes, I agree with this becoming informational. For what it's worth, I just made this change to the related JWT draft. > Editorial Nits: > > S2.2: The paragraph before the actual example uses terminology inconsistent > with RFC 6749: > > s/authorization code grant/authorization grant/ Per my reply on October 6 to Tom Taylor's review which made the same comment, actually, RFC 6749 uses both terms. Authorization Grant is the generic term. Authorization Code Grant (defined in Section 4.1 of 6749) is a specific kind of authorization grant. The text is correct as-is. > ___ > 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)
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)
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)
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
[OAUTH-WG] Fwd: Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS)
I realized that I'd accidentally replied only to Ted in this thread (email is hard!). So I wanted to send our discussion to the original cc list so it'd be more on the record and also because I believe this discussion is related to, and may help inform, some other comments that came in this morning. -- Forwarded message -- From: Brian Campbell Date: Thu, Oct 16, 2014 at 8:34 AM Subject: Re: [OAUTH-WG] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS) To: Ted Lemon On Thu, Oct 16, 2014 at 7:42 AM, Ted Lemon wrote: > On Oct 16, 2014, at 8:37 AM, Brian Campbell > wrote: > > It's a good question Ted, thanks for your review. The concern is > mitigated by the requirement in §5.2 (third bullet > https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-5.2) > which requires that these bearer assertions be audience restricted. > Assertions with audience restrictions can only be used at the specific > relying party(s) to whom they were addressed. > > > > So I think the concern is addressed in processing rules of the draft. > But do you think it should also be mentioned in the security considerations? > > Hm, interesting. I didn't connect that, because I assumed that while a > bearer assertion could be issued for a particular relying party, other > assertions might be issued for other relying parties using the same token. > This could be either because of some policy on the client, or because the > end-user just types in the same token in several places, as is > unfortunately common practice with user passwords. > > So I guess I think a bit more discussion is warranted, but it may be that > my concern is based on a misunderstanding of how bearer assertions are > generated, in which case the discussion may not be necessary. So I guess > the question is, am I misunderstanding something here that makes this > concern not an issue? > > Typically an assertion will be issued for use at a specific relying party in a specific context (like one of these profiles or for web single sign-on) . And it will be time limited to something on the order of minutes or maybe hours but not longer. The assertion is the token. It carries information about the user and how they authenticated (how is not dictated here but the assertion can describe it to the relying party) with the assertion issuer. But it's not something that the user would ever type in or even see or be aware of in most cases. 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 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. Is this helping your understanding or just confusing matters? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)
Ted Lemon has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection 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/ -- COMMENT: -- Brian Campbell has explained what's going on sufficiently that I think my DISCUSS no longer applies. Thanks, Brian! ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Thanks, Benoit. I'll double check this before the draft progresses. Thanks, Kathleen Sent from my iPhone > On Oct 16, 2014, at 8:33 AM, "Benoit Claise" wrote: > > Benoit Claise has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > 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-saml2-bearer/ > > > > -- > COMMENT: > -- > > I cleared my DISCUSS on the basis that RFC 6755 will be moved to an > informative reference in response to this process issue: IDnits complains > of a normative reference to Informational document RFC 6755, which was > not noted in the Last Call announcement. > > > Editorial Nits: > > S2.2: The paragraph before the actual example uses terminology > inconsistent with RFC 6749: > > s/authorization code grant/authorization grant/ > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
A JWT, by it's very definition, is a set of base64url pieces concatenated together with dot "." characters (which is also URL safe). So no additional encoding or serialization of the JWT is needed. On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: No Objection > > 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-jwt-bearer/ > > > > -- > COMMENT: > -- > > > - 2.1, assertion parameter: How come this one does not talk > about base64url whereas the saml one does? > > > ___ > 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-WG] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS)
Ted Lemon 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: -- This has probably already been considered and addressed by the working group, but coming into this as a neophyte it seems like a glaring omission that the security considerations of bearer assertions are not discussed here. Isn't it the case that the use of bearer assertions requires a trust relationship between the client and relying party such that the client can be assured that the relying party will not misuse the assertion to authenticate with some other entity? I realize that this sort of assertion will likely only be used in cases where the assertion only works to authenticate to a specific relying party, but I think this bears mentioning in the security considerations. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Likewise, I will not repeat stuff here but will apply appropriate changes from your comments on draft-ietf-oauth-saml2-bearer as they apply here to draft-ietf-oauth-jwt-bearer. On Tue, Oct 14, 2014 at 8:05 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: No Objection > > 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-jwt-bearer/ > > > > -- > COMMENT: > -- > > I'm not going to repeat stuff that is identical to > draft-ietf-oauth-saml2-bearer (and I did find that using > < > https://www.ietf.org/rfcdiff?url1=draft-ietf-oauth-saml2-bearer-21&difftype=--html&submit=Go%21&url2=draft-ietf-oauth-jwt-bearer-10 > > > was very helpful). Please refer to my comments on that document. > > > ___ > 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] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Thanks for your review and feedback on this one too, Pete. Replies are inline below... On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > 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-saml2-bearer/ > > > > -- > COMMENT: > -- > > 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. > Apologies for any haphazardness. This particular document was born out of my first I-D and, while I was and still am a little green on this stuff, I've endeavored to use 2119 language appropriately but it's not always easy for mere mortals such as myself. The "MUST be" that you mention below, for example, always felt somewhat silly to me too but I was trying to follow from the examples in RFC 6749 -> see grant_type in http://tools.ietf.org/html/rfc6749#section-4.1.3 for one such example. > The first "MUST be" is obviously silly and should simply be "is". OK > But the > second one buries what *might* be a proper and important use of MUST (you > MUST NOT try to stick in two SAML Assertions) with a simple definitional > one. (And that assumes that it's even plausible to try to use more than > one SAML Assertion. If you simply can't, it's just s/MUST > contain/contains.) It's intended to be both definitional and restrictive - that it contains an assertion but not more than one. The Response document in SAML Web SSO allows for multiple assertions and it has turned out to be quite a pain to deal with in practice while not adding any real value. While it's not entirely clear how one might try and stick more than one assertion in this parameter given the serialization, I still wanted to explicitly preclude it. Given that explanation of the intent, would you suggest an alternative wording of that sentence? Or is it okay as is? > The base64url encoding MUST is fine, because you don't > want people sticking in raw XML, but the SHOULD NOTs for line wrapping > and pad I am curious about: Isn't a parser going to have to check for > line wrapping and pad anyway and undo it (because it's not a MUST NOT), > and therefore this SHOULD NOT really isn't about interoperability so much > as neatness (in which case they SHOULD NOTs are not appropriate)? > Yes, the base64 decoder still has to be prepared to deal with line wrapping and padding. In my experience most decoders are very capable of it. And stripping the white-space and "="s prior to decoding is easy enough for those using a decoder that can't. The SHOULD NOT is about neatness but also in a way about interop in that it's intended to help avoid common implementation problems that can arise with urlencoding the parameter value (either not encoding or double encoding, etc.). Base64url without line wraps and padding dosn't need urlencoding and doesn't change if urlencoding is applied. That was the thinking behind the SHOULD NOTs there. As I try and articulate the reasoning, it does feel like maybe it should have been a MUST NOT. I guess I was looking to channel Postel a bit in being somewhat liberal in what is accepted with padding/no padding and line wraps/no line wraps while using the SHOULD NOTs to suggest that clients be conservative in what they send. Thoughts about what to do with it, given that reasoning? > > 3 - Subpoint 2: Just for clarification, I like the non-passive sentence > better: "The Authorization Server MUST reject any assertion that does not > contain its own identity as the intended audience." > Yes, on seeing it written that way, I also like it better. Just to make sure I'm on the same page. The sentence you suggest would replace the second to last sentence in #2 that currently says, "Assertions that do not identify [...] MUST be rejected."? > > Subpoint 5: > OLD > The element MUST contain a > element, unless the Assertion has a > suitable NotOnOrAfter attribute on the element, in > which case the element MAY be omitted. > > That one's sure to get misquoted somewhere and confuse someone. Instead: > NEW > If the Assertion does not have a suitable NonOnOrAfter attribute > on the element, the element > MUST contain a element. > OK > > Subpoint 6: > OLD > The authorization server MUST verify that the NotOnOrAfter > instant has not passed, subject to allowable clock skew between > systems.
[OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection 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-saml2-bearer/ -- COMMENT: -- I cleared my DISCUSS on the basis that RFC 6755 will be moved to an informative reference in response to this process issue: IDnits complains of a normative reference to Informational document RFC 6755, which was not noted in the Last Call announcement. Editorial Nits: S2.2: The paragraph before the actual example uses terminology inconsistent with RFC 6749: s/authorization code grant/authorization grant/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] (no subject)
ghostcharme...@gmail.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Digest, Vol 72, Issue 31
ghostcharme...@gmail.com On Oct 16, 2014 4:21 AM, wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > >1. Re: Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) (Brian Campbell) >2. Re: Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) (Pete Resnick) >3. Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: > (with DISCUSS and COMMENT) (Richard Barnes) >4. Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: > (with DISCUSS) (Richard Barnes) >5. Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: > (with DISCUSS and COMMENT) (Richard Barnes) >6. Stephen Farrell's No Objection on > draft-ietf-oauth-saml2-bearer-21: (with COMMENT) (Stephen Farrell) > > > -- > > Message: 1 > Date: Wed, 15 Oct 2014 17:35:19 -0600 > From: Brian Campbell > To: Barry Leiba > Cc: "draft-ietf-oauth-asserti...@tools.ietf.org" > , Pete Resnick > , oauth , > "oauth-cha...@tools.ietf.org" , The > IESG > > Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) > Message-ID: > < > ca+k3ectrryk-ow_saqvckgh3hinbs_igiu8tbt4ipkasxaq...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Fair point. I'll add some text saying that in the next revision. > > On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba > wrote: > > > > >>>Assertions used in the protocol exchanges defined by this > >>>specification MUST always be protected against tampering using a > >>>digital signature or a keyed message digest applied by the issuer. > >>> > >>> Why is that? Aren't you using assertions over a protected channel (as > >>> required by the spec) and therefore not need to sign the assertions? > >>> Indeed, why would a self-issued Bearer Assertion need to be signed at > >>> all? Does that even make sense? > >>> > >>> > >> Yes, assertions are sent over a protected channel, which does provide > >> integrity protection for the transport form client to AS and also gives > >> server authentication. But it doesn't provide client authentication, > which > >> is kind of the point of the Client Authentication part of this draft. > And > >> for authorization the signing or MACing is what authenticates the > issuer of > >> the assertion - sometimes the issuer is the client but often the issuer > >> will be a 3rd party system. > >> > >> I do agree with you in one specific case that, if the client is trusted > >> to be the assertion issuer and the client is properly authenticated, > then > >> an unsigned assertion could be reasonably used as an authorization > grant. > >> But it's a fairly rare and very specific case. And one that can be > >> accommodated in other ways. So it's not worth introducing the complexity > >> and potential security problems that having the signature be option > would > >> bring. > >> > > > > In other words, the assertion must be protected against tampering *by the > > party that presents the assertion*. That is a significant point, and you > > should say it. > > > > Barry > > > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/oauth/attachments/20141015/27bf1330/attachment.html > > > > -- > > Message: 2 > Date: Wed, 15 Oct 2014 21:30:26 -0500 > From: Pete Resnick > To: Brian Campbell > Cc: "draft-ietf-oauth-asserti...@tools.ietf.org" > , > "oauth-cha...@tools.ietf.org" , The > IESG > , oauth > Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) > Message-ID: <543f2dc2.1050...@qti.qualcomm.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On 10/15/14 6:06 PM, Brian Campbell wrote: > > Thanks for your review and feedback, Pete. Replies are inline below... > > Thanks for addressing the comments, including Barry's followup. Just on > the questions: > > > On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick > > mailto:presn...@qti.qualcomm.com>> wrote: > > > > scope > > [...] > >As such, the > > requested scope MUST be equal or lesser than the scope > > originally > > granted to the authorized accessor. > > > > s/MUST/will (unless you explain whether it's the server or the client > >
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: No Objection 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-jwt-bearer/ -- COMMENT: -- - 2.1, assertion parameter: How come this one does not talk about base64url whereas the saml one does? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Stephen Farrell 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: -- Putting one discuss here rather than one on each of the other docs. We can fix that as appropriate after we chat. Where are the MTI signature and mac algs for these specified? If those can be tracked back via the SAML and jose docs that's fine, but I'm not sure if they are. -- COMMENT: -- - general: What prevents/detects conflicts between the oauth scope parameter and the saml or jwt equivalent? Are there other bits of replicated data that could be the basis for a vulnerability? (The comment below applies for both saml and jwt so putting it here.) - The no replay protection issue was debated in the WG wasn't it? (I think I recall it, not sure.) Seems like a bad plan to me to not require at least implementation of replay protection in the AS so that it can be turned on. Can you point me at where that was discussed on the list? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection 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-saml2-bearer/ -- COMMENT: -- - intro para2: might be nice (no more) to add some refs to other protocols that use SAML. - 2.2: What are "padding bits" in 4648? I don't recall such. (But may be misremembering.) - section 3, list item 2: This doesn't quite say that the token endpoint URL MUST (in the absence of another profile) be in an Audience element. Why not? The text seems to me to allow for the AS to map the token endpoint URL to any value in an Audience element that the AS finds ok. I suspect that might be unwise, but it at least needs to be clear. Is that the text being ambiguous or me being paranoid/wrong? Same point seems to apply elsewhere too: = in item 3.A where it says "typically identifies" but does not say how. = in item 5 "or an acceptable alias" - section 3, item 7: How might an AS know that "the Assertion was issued with the intention that the client act autonomously on behalf of the subject"? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
