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] 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 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
[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
