Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
Some replies inline but the gist is that I disagree.
On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones michael.jo...@microsoft.com
wrote:
Part of the reasoning for using a structured confirmation claim, rather
than flattening the confirmation claim into the top-level JWT claims set,
is that a JWT may carry more than one conformation key or key descriptor,
as was mentioned in Prague. For instance, imagine that an application is
conveying an application-level confirmation key using the “cnf” claim and
for instance a token binding key using a second instance of the
confirmation structure, say using the “tokbnd” claim. With the current
structured approach, you’d have:
{…
“cnf”:{“jwk”: …},
“tokbnd”:{“jwk”: …}
}
That presumes token binding will use the same confirmation methods. But I'd
imagine that the Token Binding ID would somehow be used to signal
confirmation. So I'd be surprised if it ends up looking like that. The jwe
member of the cnf claim defiantly wouldn't apply.
It also presumes that you'd want cnf and tokbnd in the same JWT, which
doesn't really make sense to me. This draft wants to establish a registry
for JWT Confirmation Methods but a token binding confirmation would be a
different claim?
If one were to flatten the structure, however, unique claim names would
have to be produced for the cross-product of each conformation element and
each confirmation claim. So you’d end up defining and registering these
claims in the top-level JWT Claims registry:
cnf_jwk
cnf_jwe
cnf_kid
tokbnd_jwk
tokbnd_jwe
tokbnd_kid
If you add other kind of confirmation keys, things would continue to get
even sillier.
Again that presumes token binding will use the same confirmation methods,
which I think it unlikely.
I suspect it'd be more like cjwk, cjwe, ckid, and ctbd.
And a cnf with nested structure would need a tbd or tokbnd member defined
and registered.
The code will be simpler if you can have a single shared routine for
handling confirmation structures rather a separate for handling cnf_jwk,
cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe,
tokbnd_kid, etc.
You can still have a shared routine for handling things that are the same.
But with a nested structure you have to dig into the nesting.
Another reason the structure makes things conceptually simpler is that
then you can always use the name “kid” to hold a key ID, no matter the
context, rather than having to use *name-your-prefix*_kid. The same
holds true for other elements.
I personally don't find that convincing. It depends on how someone thinks
about it.
I’m sorry this wasn’t clear in Prague. I know it was mentioned in the
context of carrying multiple confirmation keys in a JWT, but it went by
pretty fast.
It was an informal discussion that was largely about something else.
Based on the discussion in Prague, I believe that we should add language
to the spec saying that applications can define new claim names other than
“cnf” to use to represent application-specific confirmation structures that
have the same syntax as those using the “cnf” name. Would that do the
trick for you?
That's not at all what I'm driving at.
If you believe that there's need for multiple confirmation structures with
the exact same syntax and meaning, I suppose that would be a useful
addition. But if you really believe that, the structure itself should
probably be adjusted to allow for multiples. I'm skeptical that it'll ever
be needed.
By the way, I’m as much in favor of compactness as anyone. Heck – I was
one of the folks who foisted the short claim names like “iss” on the
world! But I really do believe that in this case, having structure makes
things more readable and more flexible, especially since there will be
cases where there are multiple confirmation structures in the same JWT.
I can see both sides of readability. I don't see the flexibility.
And once you prefix the names, you lose most of the space savings anyway.
Depends on how you prefix them or otherwise name things. You've chosen long
prefixes to make your point but it wouldn't have to be that way.
Best
wishes,
-- Mike
*From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
Campbell
*Sent:* Thursday, July 30, 2015 11:29 AM
*To:* Nat Sakimura sakim...@gmail.com
*Cc:* oauth oauth@ietf.org
*Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:
confirmation model in proof-of-possession-02)
Using individual claims for the different confirmation types would convey
the same information with a reduced message size, likely simpler
implementation, and avoid the need to establish a new registry.
Seems like a no-brainer to me but maybe I'm
Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
To really support that case where an initial AS/issuer wants to bind to two
presenters, shouldn't the confirmation structure itself allow for multiple
confirmation methods (i.e. be or allow for an array)? I don't actually
think that is needed but the flexibility that's being argued for here would
suggest that rather than renaming a nested structure that only allows for a
single occurrence of each kind of confirmation method.
On Thu, Jul 30, 2015 at 3:14 PM, John Bradley ve7...@ve7jtb.com wrote:
I agree, flattening would be a bad direction.
In Prague I was indicating that there may be more than one presenter for
an assertion. The first presenter may be the OAuth client who presents it
to a RS.
That RS itself may also present that token as a client in token exchange
to get a new access token for another resource.
The initial AS may want to bind that token to two presenters. The second
AS doing the token exchange also probably only wants to know about the
proof key for the RS so that it doesn’t mistakenly give the first client a
token to directly access a backend API.
Trying to find a generic pattern for that is a bit of a trick though.
I think that a single cnf element is enough for most use cases, however
having cnf and cnf_rs or some other element using the cnf structure is
probably the best we can do at this point.
John B.
On Jul 30, 2015, at 5:17 PM, Mike Jones michael.jo...@microsoft.com
wrote:
Part of the reasoning for using a structured confirmation claim, rather
than flattening the confirmation claim into the top-level JWT claims set,
is that a JWT may carry more than one conformation key or key descriptor,
as was mentioned in Prague. For instance, imagine that an application is
conveying an application-level confirmation key using the “cnf” claim and
for instance a token binding key using a second instance of the
confirmation structure, say using the “tokbnd” claim. With the current
structured approach, you’d have:
{…
“cnf”:{“jwk”: …},
“tokbnd”:{“jwk”: …}
}
If one were to flatten the structure, however, unique claim names would
have to be produced for the cross-product of each conformation element and
each confirmation claim. So you’d end up defining and registering these
claims in the top-level JWT Claims registry:
cnf_jwk
cnf_jwe
cnf_kid
tokbnd_jwk
tokbnd_jwe
tokbnd_kid
If you add other kind of confirmation keys, things would continue to get
even sillier.
The code will be simpler if you can have a single shared routine for
handling confirmation structures rather a separate for handling cnf_jwk,
cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe,
tokbnd_kid, etc.
Another reason the structure makes things conceptually simpler is that
then you can always use the name “kid” to hold a key ID, no matter the
context, rather than having to use *name-your-prefix*_kid. The same
holds true for other elements.
I’m sorry this wasn’t clear in Prague. I know it was mentioned in the
context of carrying multiple confirmation keys in a JWT, but it went by
pretty fast.
Based on the discussion in Prague, I believe that we should add language
to the spec saying that applications can define new claim names other than
“cnf” to use to represent application-specific confirmation structures that
have the same syntax as those using the “cnf” name. Would that do the
trick for you?
By the way, I’m as much in favor of compactness as anyone. Heck – I was
one of the folks who foisted the short claim names like “iss” on the
world! But I really do believe that in this case, having structure makes
things more readable and more flexible, especially since there will be
cases where there are multiple confirmation structures in the same JWT.
And once you prefix the names, you lose most of the space savings anyway.
Best
wishes,
-- Mike
*From:* OAuth [mailto:oauth-boun...@ietf.org oauth-boun...@ietf.org] *On
Behalf Of *Brian Campbell
*Sent:* Thursday, July 30, 2015 11:29 AM
*To:* Nat Sakimura sakim...@gmail.com
*Cc:* oauth oauth@ietf.org
*Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:
confirmation model in proof-of-possession-02)
Using individual claims for the different confirmation types would convey
the same information with a reduced message size, likely simpler
implementation, and avoid the need to establish a new registry.
Seems like a no-brainer to me but maybe I'm overlooking something?
There hasn't been much discussion that I'm aware of. Nat seemed in favor
of it (the +1 below). Mike was dismissive of it at the Dallas meeting but
didn't provide any reasoning (that I understood anyway).
On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura sakim...@gmail.com wrote
[OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)
Using individual claims for the different confirmation types would convey the same information with a reduced message size, likely simpler implementation, and avoid the need to establish a new registry. Seems like a no-brainer to me but maybe I'm overlooking something? There hasn't been much discussion that I'm aware of. Nat seemed in favor of it (the +1 below). Mike was dismissive of it at the Dallas meeting but didn't provide any reasoning (that I understood anyway). On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura sakim...@gmail.com wrote: +1 =nat via iPhone 2015/03/23 11:07、Brian Campbell bcampb...@pingidentity.com のメッセージ: This is mostly about section 3.4 https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3.4 but also the whole draft. If cnf is intended to analogous to the SAML 2.0 SubjectConfirmation element, it should probably contain an array value rather than an object value. SAML allows not just for multiple methods of confirming but for multiple instances of the same method. IIRC, only one confirmation needs to be confirmable. I'm not sure the extra complexity is worth it though. I've rarely, if ever, seen SAML assertions that make use of it. If the intent is just to allow for different kinds of confirmation, couldn't the structure be pared down and simplified and just have individual claims for the different confirmation types? Like cjwk and ckid or similar that have the jwk or kid value respectively as the member value. ___ 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] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)
I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell bcampb...@pingidentity.com wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Meeting Minutes
My sense of the consensus in the room is as Justin describes it. On Sat, Jul 25, 2015 at 9:14 AM, Justin Richer jric...@mit.edu wrote: Consensus: For use of existing params defined in OAuth, while allowing some to be optional when not needed. That was not the consensus as I understood it in the room. The consensus was the first portion, as originally noted. The second portion was Mike’s requested amendment, and it (and other aspects like the value of token_type) were brought up as details that the editors would work on and come back to the list. — Justin On Jul 25, 2015, at 7:07 AM, Mike Jones michael.jo...@microsoft.com wrote: Good notes. Please apply the following fixes to them... To the list of new OAuth RFCs since the last meeting please also add: draft-ietf-oauth-json-web-token draft-ietf-oauth-saml2-bearer draft-ietf-oauth-jwt-bearer Please change: Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always the same token. to: Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always an access token. Please change: Consensus: For use of existing params defined in OAuth. to: Consensus: For use of existing params defined in OAuth, while allowing some to be optional when not needed. Please change: Mike: Microsoft oauth2 server have a 'resource' param to indicate the audience. to: Mike: Microsoft oauth2 server has a 'resource' param to indicate the resource that the access token will be used to access. whitely used - widely used We need to go on with out lives - We need to go on with our lives ready to a shepherd write-up - ready for a shepherd write-up Finally, I would add a note saying: Some additional drafts are planned, including draft-jones-amr-values and draft-ietf-oauth-discovery Thanks -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, July 23, 2015 7:19 AM To: oauth@ietf.org Subject: [OAUTH-WG] Meeting Minutes Here are the notes from our meeting yesterday: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fproceedings%2f93%2fminutes%2fminutes-93-oauthdata=01%7c01%7cMichael.Jones%40microsoft.com%7ccb085108ecb0454b33c008d293699b85%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=5GiVy2SivZk6GWeoXtabbQG1q3r1%2bL%2fnM4o2BmH5Kv8%3d Thanks to Erik for taking notes. Please let me know if something is missing or incorrect within the next 2 weeks. Ciao Hannes ___ 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] Authentication Method Reference Values Specification
There's a method of authentication that is gaining in popularity which I'd propose adding a method for. It is typically used as a second factor where after a primary auth, like username and password, a push notification is sent to the user's phone and they acknowledge it from the device. We have the PingID product https://www.pingidentity.com/en/products/pingid.html that does it and Entrust http://www.entrust.com/resource/entrust-identityguard-mobile-push-authentication-for-vpn-and-web-access and Duo https://www.duosecurity.com/product/methods/duo-mobile, among others I'm sure, offer something similar. It's commonly called mobile push authentication so maybe mpa could be the amr value. But, as Nat pointed out, the really interesting characteristic is that it's a second factor that utilizes only a secondary channel - so perhaps sca for second channel authentication would be a more appropriate general amr name. Thoughts are welcome. But I believe it's becoming prevalent enough that it deserves its own amr value in this doc. On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones michael.jo...@microsoft.com wrote: I agree that an obvious good thing to do is to add spec references to the field definitions. I need to investigate use cases for amr_values. I think this came from developers who actually wanted this for a particular purpose but I’ll have to get back to the WG on that. It’s defined here, rather than in another spec, because it’s highly related to the “amr” values. -- Mike *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura *Sent:* Thursday, July 23, 2015 6:22 PM *To:* William Denniss *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values Specification So, allow me a naive question. I supppose there are good random otp, as well as pretty bad otp etc. Would it be useful to say just otp. Would it not be better to have at least a field that references a spec that specifies the security requirement for that mechanism? 2015-07-23 12:05 GMT+02:00 William Denniss wdenn...@google.com: Thanks for drafting this Mike. I'm in favor of having this registry. In addition to the specific values, I propose we add some generic ones too (trying to follow your naming scheme): rba: risk-based auth upt: user presence test My fear of making things too specific is that RPs may get lost in the weeds trying to work out what things they should care about and how. As an IdP we like to guide RPs through these kinds of decisions, and prefer to pass a more high level indication of what happened (such as these two values). If someone wanted to have best of both worlds, then both could be asserted, e.g. upt fpt to indicate that the user presence was tested, using a fingerprint test. Regarding the proposed wia value. I don't know what it is, and the spec doesn't help me find out, can a reference be added? I also wonder if it could be genericized to avoid being vendor specific values – but mostly I just want to understand what it is. Almost all the other values are self-explanatory, perhaps pop could use a reference as well (or maybe just a longer explanation). I don't see the immediate value of amr_values, can you elaborate with some places where this would be applied? Separately, I wonder if an extension to OIDC should be included in this doc, which is otherwise a fairly clean registry spec that could be used more broadly. On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell bcampb...@pingidentity.com wrote: So maybe a naive question but why does this draft define amr_values while also suggesting that it's fragile and that acr acr_values is preferable? Seems contradictory. And I doubt I'm the only one that will find it confusing. On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones michael.jo...@microsoft.com wrote: The key part of this is establishing a registry. That can only be done in an RFC. John, I encourage you to submit text beefing up the arguments about why using “acr” is preferable. The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationshipdata=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=6%2blPSyG0xfBMg0jxKaQt1lAcW6GV3%2fje4dmkE%2bb7Q8o%3d is a start at that. -- Mike *From:* John Bradley [mailto:ve7...@ve7jtb.com] *Sent:* Thursday, July 23, 2015 9:30 AM *To:* Justin Richer *Cc:* Mike Jones; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values Specification I don’t personally have a problem with people defining values for AMR and creating a IANA registry
Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86
PCKE prevents a bad app from using the code when there's a collision in the custom scheme used for the redirect URI. However the same app could immediately issue a new authorization request with it's own PCKE parameters and (mostly) transparently get back a code that it can use. Having some user interaction via the browser helps mitigate that. 6.4 says that tokens SHOULD NOT be issued to such [non-confidential] clients without user consent or interaction so it's not strictly required. Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NOT and NOT RECOMMENDED are effectively synonymous On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura sakim...@gmail.com wrote: Prompting is not necessarily is a good thing. It is very context specific, so please do not make it required. Nat 2015-07-24 16:38 GMT+09:00 John Bradley ve7...@ve7jtb.com: Hi Antonio, Thanks for the feedback. I agree that for non confidential clients, the user needs to be prompted. It might be fair to just confirm the grants rather than resetting them from defaults. I know some people are doing that, but I suspect that not everyone is. Good stuff. People should chime in with other things we need to consider. Thanks John B. On Jul 24, 2015, at 9:00 AM, Antonio Sanso asa...@adobe.com wrote: hi, nice to see some work on this topic by the way! Couple of comments below inline On Jul 24, 2015, at 7:51 AM, John Bradley ve7...@ve7jtb.com wrote: Thanks for the review Erik, We will go through it in detail and get back to you. I am working with a couple of governments on how a eID app could use the self issued profile of OpenID Connect to issue tokens. There are also other out of band authentication apps that people use that need to be considered. I think that the callback / redirect_uri can work if a custom scheme URI or a app claimed https: URI is used. Is there any example of “popular” custom scheme. One I have seen is urn:ietf:wg:oauth:2.0:oob Another common redirect_uri for native app I have seen is http://localhost One more comment. I strongly suggest for mobile app to have a really strict consent screen policy. Aka the authorization server MUST show the consent screen at every usage and not remember the fact that the app has been already authorized. Just my 2 cents :) regards antonio I agree that sniffing the URI in a web view creates a very confusing user experience at the moment. It works better on Android than iOS 8 but is not smooth in many cases. I personally use a out of band mobile authenticator for my enterprise login that has exactly that problem, and requires me to manually switch back to the calling app. Regards John B. On Jul 24, 2015, at 12:59 AM, Erik Wahlström e...@wahlstromstekniska.se wrote: Hi, Thanks for a great document! I volunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go: In national mobile eID deployments an app is issued by gov or other organisation in a country. The app acts as the users authentication method and it works with an IDP, the IDP can be anywhere if its an PKI token or at the place that issued the credential if it’s something else. When an SP start developing an native app for there services and want’s to use the national eID solution in combination with OAuth we might run into trouble here. The flow is like follows for a service provider called FooBar: FooBar’s app starts browser-view. FooBar’s SAML service provider functionality redirects the user to an national SAML IDP. The IDP prompts user for a username and then starts an mobile eID token on the same phone. Users is asked if they want’s to authenticate to FooBar and enters PIN. User are then redirected back with an assertion. The FooBar's service provider verifies the assertion and mint’s OAuth2 token(s) and redirects the user back to the app with the help of the redirect URL. So the phone first displays an app, then foobar.com http://example.com/ in browser-view, then idp.com http://nationalidp.com/ in *browser-view*, then mobile eID token, then idp.com http://nationalidp.com/ in the *system browser* and back to foobar.com http://example.com/ and the app that the user wanted to use. The problem with browser-views is that the mobile eID token will start idp.com when user has authenticated and then the user is not back in the apps browser-view, but in system browser instead. The system browser is sharing the session with the browser-view and redirect the user to the native app. The user experience will be a bit strange then because there the correct page is not loaded and the browser-view should be closed and the app should start parsing out the authorization code instead. So I think draft should mention something about this scenario and that app developers should handle this scenario in the app. The grant did not really come back from the browser-view as expected but from the system
Re: [OAUTH-WG] Authentication Method Reference Values Specification
So maybe a naive question but why does this draft define amr_values while also suggesting that it's fragile and that acr acr_values is preferable? Seems contradictory. And I doubt I'm the only one that will find it confusing. On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones michael.jo...@microsoft.com wrote: The key part of this is establishing a registry. That can only be done in an RFC. John, I encourage you to submit text beefing up the arguments about why using “acr” is preferable. The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship is a start at that. -- Mike *From:* John Bradley [mailto:ve7...@ve7jtb.com] *Sent:* Thursday, July 23, 2015 9:30 AM *To:* Justin Richer *Cc:* Mike Jones; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values Specification I don’t personally have a problem with people defining values for AMR and creating a IANA registry. That exists for ACR. I am on record as not supporting clients requesting amr as it ai a bad idea and the spec mentions that at the same time it defines a new request parameter for it. It is probably not something I will put any real effort into fighting, if people insist on it. I will continue to recommend only using ACR in the request. John B. On Jul 23, 2015, at 9:21 AM, Justin Richer jric...@mit.edu wrote: Useful work, but shouldn’t this be defined in the OIDF, where the “amr parameter is defined? — Justin On Jul 22, 2015, at 7:48 PM, Mike Jones michael.jo...@microsoft.com wrote: Phil Hunt and I have posted a new draft that defines some values used with the “amr” (Authentication Methods References) claim and establishes a registry for Authentication Method Reference values. These values include commonly used authentication methods like “pwd” (password) and “otp” (one time password). It also defines a parameter for requesting that specific authentication methods be used in the authentication. The specification is available at: ·https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 An HTML formatted version is also available at: ·http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=1429 and as @selfissued https://twitter.com/selfissued. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] potential issues in draft-ietf-oauth-signed-http-request?
I think I said, at the last meeting, that I would review draft-ietf-oauth-signed-http-request, which was maybe foolish of me, but I thought I should be timely and send something before the meeting tomorrow. Even though the document isn't on the agenda. Let me first say that I honestly don't know if this HTTP signing is the right approach or not for presenting some kind of 'better than bearer' access tokens to the RS. As such, I don't intend my reading/review of the document as either an endorsement of it or opposition to it. That said, I did notice a couple of potential security or interoperability issues that I wanted to raise. Following the description of calculating the query parameter list and hash https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01#section-3.2 and validating the query parameter list and hash https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01#section-4.1 (text of both copied below) it seems like different query strings could result in the same hash value. For example, The query string ?foo=bar%3Dbar= processed in order shown there would have a names list of [foo, bar] and parameters of foo=bar= bar= and the hash would be of foo=bar=bar= While the different query string ?foo=bar=bar%3D processed in the same order, left to right, would have the same names list of [foo, bar] and parameters of foo= bar=bar= and the hash would be of foo=bar=bar= It's a made up example but seems to show that different content in the query string can sometimes be manipulated to produce the same hash. I don't have an exploit in mind but the bad guys are smarter than me. And it's probably just generally the kind of thing a security related protocol shouldn't allow for. Or am I misunderstanding something? Seems like encoding and delimitation need to be explicitly handled in whatever way the query parameters are dealt with. There's already a [[]] in there that hints at the possibility. The text also says repeated parameter names are processed separately with no special handling but, for that to work, doesn't it require that the client and server process repeated parameters in the same order? I think the header list and hash likely has similar issues as it's basically the same approach. As I look at the text again, shouldn't the 4.x sections talk about the server or resource server rather than the client? 3.2 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01#section-3.2. Calculating the query parameter list and hash To generate the query parameter list and hash, the client creates two data objects: an ordered list of strings to hold the query parameter names and a string buffer to hold the data to be hashed. The client iterates through all query parameters in whatever order it chooses and for each query parameter it does the following: 1. Adds the name of the query parameter to the end of the list. 2. Encodes the name and value of the query parameter as name=value and appends it to the string buffer. [[Separated by an ampersand? Alternatively we could have this also pulled into an ordered list and post-process the concatenation, but that might be too deep into the weeds. ]] Repeated parameter names are processed separately with no special handling. Parameters MAY be skipped by the client if they are not required (or desired) to be covered by the signature. The client then calculates the HMAC hash over the resulting string buffer. The list and the hash result are added as the value of the p member. 4.1 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01#section-4.1. Validating the query parameter list and hash The client has at its disposal a map that indexes the query parameter names to the values given. The client creates a string buffer for calculating the hash. The client then iterates through the list portion of the p parameter. For each item in the list (in the order of the list) it does the following: 1. Fetch the value of the parameter from the HTTP request parameter map. If a parameter is found in the list of signed parameters but not in the map, the validation fails. 2. Encode the parameter as name=value and concatenate it to the end of the string buffer. [[same separator issue as above.]] The client calculates the hash of the string buffer and base64url encodes it. The client compares that string to the string passed in as the hash. If the two match, the hash validates, and all named parameters and their values are considered covered by the signature. There MAY be additional query parameters that are not listed in the list and are therefore not covered by the signature. The client MUST decide whether or not to accept a request with these uncovered parameters. ___ OAuth mailing list OAuth@ietf.org
Re: [OAUTH-WG] Token introspection for public clients?
Any good access token implementation should make such scanning totally infeasible (via sufficient entropy in the token, if it's a reference, or cryptographic protections, if it's self contained). Authentication/authorization at the introspection endpoint, in my view anyway, is more about privacy and preventing certain types of information disclosure (maybe a client seeing info in an encrypted token or opaque reference token). We implemented introspection type functionality in our initial OAuth product support well before the WG introspection document existed. It's got basically similar concepts but just with a different syntax and endpoint. The original release of it required authentication but we later relaxed that requirement based on deployment feedback. So that's a data-point based on experience that's maybe worth considering. Though I realize the document is probably too far along in the process for changes at this point. On Mon, Jul 20, 2015 at 9:34 AM, William Denniss wdenn...@google.com wrote: Even if the primary target is the protected resource, is there a reason to exclude use by clients? The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that. On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer jric...@mit.edu wrote: Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense. Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage. — Justin On Jul 20, 2015, at 12:03 AM, William Denniss wdenn...@google.com wrote: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer jric...@mit.edu wrote: In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS-AS introduction. And I think this is all actually a moot point because *clients* shouldn’t be doing the introspection in the first place — the whole spec is there to support *resource servers* introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result
Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens
Though you want to be careful with that as the asymmetric algs in JWE don't provide authentication of the sender. On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura n-sakim...@nri.co.jp wrote: Hi Malla, Just to add one more thing: If you just want to “sign” for the sake of integrity protection, you really do not need to do it as all the algs in JWE are integrity protected. -- Nat Sakimura n-sakim...@nri.co.jp Nomura Research Institute, Ltd. PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system. *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley *Sent:* Friday, July 17, 2015 7:45 AM *To:* Malla Simhachalam mallasimhacha...@gmail.com *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens https://tools.ietf.org/html/rfc7519#section-11.2 It is in the JWT spec. You can do it both ways however you really need a good reason not to sign then encrypt, and then after you have a good reason you should still sign then encrypt because you probably have not considered everything, There are probably some edge cases that are exceptions to the rule, but they are rare. John B. On Jul 16, 2015, at 11:33 PM, Malla Simhachalam mallasimhacha...@gmail.com wrote: Hi, I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=1 for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other? Thanks for help. Malla ___ 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] I-D Action: draft-ietf-oauth-spop-14.txt
I think -15 does address the inconsistency. On Fri, Jul 10, 2015 at 9:36 AM, John Bradley ve7...@ve7jtb.com wrote: Yes I believe I I addressed these comments as part of Barry’s discuss points. They were comments on the changes that Barry introduced that caused a inconsistency. I resolved that in 15. I think it is good to go. On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: John, The updates were included in the version I approved for posting that also addressed Barry's discuss points, correct? Are we good with the current version to move forward: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ Thank you, Kathleen On Thu, Jul 9, 2015 at 2:46 PM, John Bradley ve7...@ve7jtb.com wrote: I have made some edits to make it consistent. They are checked into the butbucket repo nat and I use, but we can’t update the official draft during the freeze before the IETF meeting. https://bitbucket.org/Nat/oauth-spop On Jul 9, 2015, at 3:19 PM, Brian Campbell bcampb...@pingidentity.com wrote: I agree with William that it's a little confusing. I get that there's a desire to discourage using plain but perhaps the language (especially the MUST NOT in 7.2) should be lightened up just a bit? On Wed, Jul 8, 2015 at 8:22 PM, William Denniss wdenn...@google.com wrote: Following up the discussion on today's NAPPS call, I understand why plain is not presented as the recommended approach in the spec (though it still has some value over not doing PKCE at all, in that it mitigates against the current known attack where a rogue app registers the same custom URI scheme as another), but I feel that after all the back and forth the picture is a little confusing. In particular, 4.2 and 4.4.1 include some examples where plain is supported: 4.2 Clients SHOULD use the S256 transformation. The plain transformation is for compatibility with existing deployments and for constrained environments that can't use the S256 transformation. 4.4.1. If the client is capable of using S256, it MUST use S256, as S256 is Mandatory To Implement (MTI) on the server. Clients are permitted to use plain only if they cannot support S256 for some technical reason and knows that the server supports plain. But then 7.2 is very vocal that it MUST NOT be used for new implementations: 7.2 Because of this, plain SHOULD NOT be used, and exists only for compatibility with deployed implementations where the request path is already protected. The plain method MUST NOT be used in new implementations. What if those new implementations are constrained, as indicated in 4.2 and 4.4.1? Also, while S256 is clearly indicated as MTI, little is said about plain, although it's alluded to that it's not MTI in 4.4.1 (and knows that the server supports plain). Should we be more explicit upfront that plain is optional for servers to support, if that's the intention? On Tue, Jul 7, 2015 at 10:51 PM, William Denniss wdenn...@google.com wrote: t_m works for me, I just think we should have some indication that it's the name of the transform. Will you also update where it is referenced in the description below Figure 2? On Tue, Jul 7, 2015 at 6:28 PM, John Bradley ve7...@ve7jtb.com wrote: Thanks, I fixed my finger dyslexia for the next draft. I changed it to t_m rather than “t” I think that is clearer. If I were to do it the other way XML2RFC would have double quotes in the text version. John B. On Jul 7, 2015, at 9:38 PM, William Denniss wdenn...@google.com wrote: In version 14, there's a typo on this line (deso) in Section 7.2: `plain method deso not protect` Also, in the 1.1 Protocol Flow diagram, regarding the text: `+ t(code_verifier), t` I wonder if it makes more sense to represent as `+ t(code_verifier), t` (note the quotes on the second 't') given that it's a string representation of the method that's being sent? On Mon, Jul 6, 2015 at 4:05 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename: draft-ietf-oauth-spop-14.txt Pages : 20 Date: 2015-07-06 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced pixy). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt
I agree with William that it's a little confusing. I get that there's a desire to discourage using plain but perhaps the language (especially the MUST NOT in 7.2) should be lightened up just a bit? On Wed, Jul 8, 2015 at 8:22 PM, William Denniss wdenn...@google.com wrote: Following up the discussion on today's NAPPS call, I understand why plain is not presented as the recommended approach in the spec (though it still has some value over not doing PKCE at all, in that it mitigates against the current known attack where a rogue app registers the same custom URI scheme as another), but I feel that after all the back and forth the picture is a little confusing. In particular, 4.2 and 4.4.1 include some examples where plain is supported: 4.2 Clients SHOULD use the S256 transformation. The plain transformation is for compatibility with existing deployments and for constrained environments that can't use the S256 transformation. 4.4.1. If the client is capable of using S256, it MUST use S256, as S256 is Mandatory To Implement (MTI) on the server. Clients are permitted to use plain only if they cannot support S256 for some technical reason and knows that the server supports plain. But then 7.2 is very vocal that it MUST NOT be used for new implementations: 7.2 Because of this, plain SHOULD NOT be used, and exists only for compatibility with deployed implementations where the request path is already protected. The plain method MUST NOT be used in new implementations. What if those new implementations are constrained, as indicated in 4.2 and 4.4.1? Also, while S256 is clearly indicated as MTI, little is said about plain, although it's alluded to that it's not MTI in 4.4.1 (and knows that the server supports plain). Should we be more explicit upfront that plain is optional for servers to support, if that's the intention? On Tue, Jul 7, 2015 at 10:51 PM, William Denniss wdenn...@google.com wrote: t_m works for me, I just think we should have some indication that it's the name of the transform. Will you also update where it is referenced in the description below Figure 2? On Tue, Jul 7, 2015 at 6:28 PM, John Bradley ve7...@ve7jtb.com wrote: Thanks, I fixed my finger dyslexia for the next draft. I changed it to t_m rather than “t” I think that is clearer. If I were to do it the other way XML2RFC would have double quotes in the text version. John B. On Jul 7, 2015, at 9:38 PM, William Denniss wdenn...@google.com wrote: In version 14, there's a typo on this line (deso) in Section 7.2: `plain method deso not protect` Also, in the 1.1 Protocol Flow diagram, regarding the text: `+ t(code_verifier), t` I wonder if it makes more sense to represent as `+ t(code_verifier), t` (note the quotes on the second 't') given that it's a string representation of the method that's being sent? On Mon, Jul 6, 2015 at 4:05 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename: draft-ietf-oauth-spop-14.txt Pages : 20 Date: 2015-07-06 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced pixy). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-spop-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
There is a lot in common, yes. Fundamentally we're working to address the same needs, which should lead to some commonality. But I was also trying to be conciliatory in the work I did and make a good faith effort at establishing some commonality from which collaborative work could move forward. In retrospect I should probably have just outright opposed the adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying to work with you would be more effective than working against you. At the time you seemed amenable to that and even proposed co-editing with. Hannes followed that indicating support for adding other co-authors (he didn't say it but kind of implied perhaps Justin and/or Phil based on prior related work). Since that time, however, there's been little willingness to consider changes to the draft (other than very trivial items). And Tony was added as a co-author, which to me (and I suspect many others) signals a complete lack of willingness to actually collaborate towards a solution that's acceptable to more than one contingent. There are differences in the drafts too. I won't list them all here but did want to call out that, contrary to what you said, the request in my draft is made up of regular old HTTP form-urlencoded POST parameters. Which is a simplification and efficiently improvement that seems to be preferred. On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones michael.jo...@microsoft.com wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:* Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases, and it’s still not OAuth-y at all. It requires a specially-formed security assertion on the way in, which the client must understand and generate. I still can’t take an arbitrary token I’ve been handed
Re: [OAUTH-WG] Token Chaining Use Case
Agree Sergey. That line of thinking is largely why https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes normal OAuth client authentication. On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 08/07/15 01:41, Mike Jones wrote: [...] That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
Probably goes without saying but I'm generally in agreement with Justin here. On Wed, Jul 8, 2015 at 5:40 AM, Justin Richer jric...@mit.edu wrote: The HTTP *request* should be able to be covered by a JWT signature, and that should be applicable to any interaction with the token endpoint. I’m aware that Nat’s draft is talking about the authorization endpoint, but the same logic could be applied here at the token endpoint. It could actually even be easier there because we could simply specify that the Content-Type of the input POST is application/jwt and the payload of said JWT simply contains all the parameters to the token endpoint. Orthogonal functionality that meshes well together. Brian’s draft puts everything as a parameter, including the input token (which can be arbitrary — the requester doesn’t need to know what’s in the tokens at all). This could easily be turned wholesale into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters are in a JWT that’s passed as an input parameter alongside other things that are outside the JWT. I don’t think that works particularly well, and I think there’s a better, simpler solution that solves all of these use cases and then some. — Justin On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases
Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)
Regarding the comment on Section 2, I had originally argued for the inclusion of ASCII(xxx) as I felt it was important to avoid potential ambiguity that was in the draft at the time (it wasn't 100% clear to me at the time if the code_verifier was to be base64url decoded as input into the hash or if the ASCII bytes were to be used). However, other content (particularly §4.1 https://tools.ietf.org/html/draft-ietf-oauth-spop-14#section-4.1) has since changed and removed the potential for the ambiguity I thought might be there. Which is a long way of explaining that I'm okay with Barry's proposed change to Section 2, and occurrences of ASCII(...) throughout, despite it undoing something I'd previously requested. On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura sakim...@gmail.com wrote: Thanks Barry, These are the issues that I wanted to discuss with John before making change. -- Section 6.2 -- John has partly addressed your IANA comment already. I needed to check if there was any reason for just doing partly. -- Section 7.2 -- is probably just my oversight. I will deal with it. -- Section 2 -- : I agree with you and I wanted to confirm it with John and other people to commit the change. Cheers, Nat 2015-07-07 11:49 GMT+09:00 Barry Leiba barryle...@computer.org: Barry Leiba has entered the following ballot position for draft-ietf-oauth-spop-14: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ -- COMMENT: -- Version -14 resolves my DISCUSS (and also some of my non-blocking comments). Thanks very much for considering these and working with me on them! = My comment about the IANA Considerations remains. While it's non-blocking, I still hope you will accept the change I suggest: -- Section 6.2 -- I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert review, and make the mailing list something that the designated expert(s) keep track of. Also, please give more instructions to the DEs about what they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should apply?). For the first, here's a text change that I suggest we move toward for this sort of thing: OLD most of Section 6.2 NEW Additional code_challenge_method types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts. The DEs will ensure there is at least a two-week review of the request on the oauth-ext-rev...@ietf.org mailing list, and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published. Discussion on the oauth-ext-rev...@ietf.org mailing list should use an appropriate subject, such as Request for PKCE code_challenge_method: example). The Designated Expert(s) should consider the discussion on the mailing list, as well as these other things when evaluating registration requests. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. END = -- Section 7.2 -- I find the first first paragraph confusingly worded, and after discussion with the author I suggest this: NEW Clients MUST NOT downgrade to plain after trying the S256 method. Because servers are required to support S256, an error when S256 is presented can only mean that the server does not support PKCE at all. Otherwise, such an error could be indicative of a MITM attacker trying a downgrade attack. END = Finally, there is this comment, which is not a big deal and you should proceed as you think best: -- Section 2 -- There is no real distinction between STRING and ASCII(STRING), because STRING is already defined to be ASCII. Using ASCII(xxx) only adds clutter, and a suggest removing it. So, for example, that would result in changes such as this: OLD BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge NEW
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token. On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case
Re: [OAUTH-WG] JWT Token on-behalf of Use case
A natural usage of act-as or impersonation http://www.oxforddictionaries.com/us/definition/american_english/impersonate would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and on-behalf-of contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, *with* * on-behalf-of semantics, principal A still has its own identity* * separate from B and it is explicitly understood that while B may have* * delegated its rights to A, any actions taken are being taken by A and* * not B. In a sense, A is an agent for B.* On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. *When principal A* * impersonates principal B, then in so far as any entity receiving* * Claims is concerned, they are actually dealing with B. *It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Monday, July 6, 2015 11:29 AM *To:* Mike Jones michael.jo...@microsoft.com *Cc:* oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Monday, July 06, 2015 8:13 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft. His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation. I think Brian is closer in explaining it. In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations. I think many times it is how WIF implemented it that people copied. It may be better to have new terms that are clear such as impersonation and composite. The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics. There are plusses and minuses to both options. Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability. There are also issues around how this would work with proof of possession security tokens, both as input and output. Perhaps we can make some progress on this in Prague. John B. On Jul 6, 2015, at 11:04 AM, Brian Campbell bcampb...@pingidentity.com wrote: Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar
Re: [OAUTH-WG] JWT Token on-behalf of Use case
That doesn't even make sense. On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin tony...@microsoft.com wrote: What is written in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and the text that describes the Windows Kerberos support for Protocol Transition and Constrained Delegation are in alignment not sure what make you think they are not. If you are trying to describe different features than Windows Kerberos Protocol Transition/Constrained Delegation that then I would agree that the text may not be correct but then again it would not be describing the Windows Kerberos Protocol Transition/Constrained Delegation. The way you have the text describes different set use case then what the feature of https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 describes. *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] *Sent:* Monday, July 6, 2015 2:33 PM *To:* Anthony Nadalin tony...@microsoft.com *Cc:* Mike Jones michael.jo...@microsoft.com; oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case A natural usage of act-as or impersonation http://www.oxforddictionaries.com/us/definition/american_english/impersonate would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and on-behalf-of contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, *with* * on-behalf-of semantics, principal A still has its own identity* * separate from B and it is explicitly understood that while B may have* * delegated its rights to A, any actions taken are being taken by A and* * not B. In a sense, A is an agent for B.* On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. *When principal A* * impersonates principal B, then in so far as any entity receiving* * Claims is concerned, they are actually dealing with B. *It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Monday, July 6, 2015 11:29 AM *To:* Mike Jones michael.jo...@microsoft.com *Cc:* oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head
Re: [OAUTH-WG] JWT Token on-behalf of Use case
One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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 ___ 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] HTTPS JWKS style key rotation for SAML/XML-DSig
This document https://goo.gl/6uWxT7[0] was something done during the course of some work a few months ago - it briefly proposes how a JWK Key ID can be used within an XML Signature to convey to the recipient what key was used to sign the XML and thusly what key to use to verify the signature. It's not rocket surgery but maybe a useful thing to codify, which might help with migration and coexistence of older and newer protocols. Anyway, no action required or even suggested here. I just wanted to put the idea out there and the mailing lists of a few of these (sorta) related WGs seemed as good a place as any. [0] https://goo.gl/6uWxT7 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Disable JWK use parameter for octet sequence keys?
IMHO use is less useful for JWKs of type oct but not to the point of disallowing it. Your question is probably better suited for the JOSE WG list though, rather than OAUTH. On Sun, Apr 19, 2015 at 4:01 AM, Vladimir Dzhuvinov vladi...@connect2id.com wrote: A developer working with the Nimbus jose+jwt library raised the question whether setting of the public use [1] parameter should be disabled for JWKs of type oct. This appears to make sense, even though the JWA spec [2] doesn't mention it. Is this correct? Thanks, Vladimir [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-40#section-4.2 [2] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-6.4 ___ 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] New header Fragment-Scope to prevent assertions leakage through redirects
I'm hardly speaking with any authority here but my hope/expectation is that using Origin Only for the Referrer Policy would provide enough info in the referer (the origin) so as to not break search engines flows or other analytics that are using data from the referer header. The referring domain is provided, which is useful data, but without there query or path that often leaks sensitive data or tokens. https://w3c.github.io/webappsec/specs/referrer-policy/ or http://www.w3.org/TR/referrer-policy/ is the work in progress on Referrer Policy. On Fri, Apr 10, 2015 at 5:37 PM, isciurus isciu...@gmail.com wrote: I would also be interested to know about the possible response headers for referrer (a draft?). Last time we brainstormed the problem with Brad Hill we thought it could break something with search engines flow and referrer policy. I have tried to document the response headers that can help stop leaking referrer. On Fri, Apr 10, 2015 at 4:08 PM, John Bradley ve7...@ve7jtb.com wrote: Thanks, I have tried to document the response headers that can help stop leaking referrer. Being able to do the same thing to stop fragment leaking would be a good thing. If the W3C adds that then I would add it to our recommendations. In the Interim without browser support we may need to look at other methods to pass tokens to clients in the browser. I am certainly interested in tracking your proposal. John B. On Apr 10, 2015, at 4:00 PM, isciurus isciu...@gmail.com wrote: Hi, One of the recent drafts https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html was brought to my attention. Regarding the part 2.2. Security Compromise: The Authorization Server As Open Redirector: The legitimate OAuth Authorization response will include an access token in the URI fragment. Most web browsers will append the fragment to the URI sent in the location header of a 302 response if no fragment is included in the location URI. This browser behaviour with a url fragment reattaching is indeed used widely in attacks on OAuth (for example, one of the recent on the bitcoin exchange http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html) and I am also aware of one attack on OpenID 2 implementation leaking a valid signature using the same technique. We are trying to propose a browser-level protection from sensitive url fragment data reattach on cross-domain redirects: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html A new header in the AS response would also block fragment reattach in the following scenario: https://AUTHORIZATION_SERVER/authorize?response_type=token https://authorization_server/authorize?response_type=token client_id=good-clientscope=VALID_SCOPE redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize %3Fresponse_type%3Dcode %26client_id%3Dattacker-client-id %26scope%3DINVALID_SCOPE %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com But it would additionally block exploitation of vulnerable clients which have open redirects on their domains and don't whitelist their redirect_uri: https://AUTHORIZATION_SERVER/authorize?response_type=token https://authorization_server/authorize?response_type=token client_id=good-clientscope=VALID_SCOPE redirect_uri=https%3A%2F%2good-client.com%Fopen_redirect %3Furl%3Dhttps%253A%252F%252Fattacker.com This can improve the situation with already deployed clients in large scale. Let me know if this proposal is interesting to the OAuth WG. Thanks, Andrey ___ 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] Token Chaining Use Case
This kind of token exchange might involve exchanges other than swapping an AT for another AT (and downscoping it). It might be an AT for a structured JWT specifically targeted at one of the the particular services that the original RS needs to call. Or an AT might be exchanged for a SAML assertion to use with legacy SOAP serveries. A good general token exchange mechanism enables lots of variations of cases like the one Justin mentioned. And more. In fact, I think downscoping might be a minority use case where what token exchange is often need for is translating tokens from what you have into what the resource you need to call can deal with. There need to be ways for the caller to tell the AS about the token it's asking for - by type or by the address/identifier of where it'll be used. There needs to be ways for the caller to authenticate to the AS. And there needs to be some way of expressing this delegation thing (though I'm still not totally convinced it couldn't be just the token is about the user/principal and the caller/client of the exchange is who is being delegated to). I realize few (approaching zero) people have or are going to read it but I have endeavored to cover all these things in the http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an early draft so not without it some rough edges but can provide some guidance on what is needed and offers some protocol syntax for expressing it. I believe Justin's use case would be covered by it (defining a specific token type URI for an OAuth access token issued by the AS in question might be needed) as are many others. On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer jric...@mit.edu wrote: As requested after last night’s informal meeting, here is the token chaining use case that I want to see represented in the token swap draft. [ Client ] - [ A ] - [ B ] - [ C ] An OAuth client gets an access token AT1, just like it always would, with scopes [A, B, C] in order to call service A, which requires all three scopes. Service A (an RS) accepts this token since it has its scope, and then needs to call service B in turn, which requires scopes [B, C]. It could just re-send the token it got in, AT1, but that would give the downstream RS the ability to call services with scope [ A ] and it should not be allowed to do that. To limit exposure, service A calls a token swap at the AS to create AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting a downscoped token based on AT1. Service A then acts as an OAuth client to call service B, now acting as an RS to service A’s client, and can fulfill the request. And it’s turtles all the way down: Service B can also call service C, and now B acts as a client, requesting AT3 with scope [ C ] based on AT2, and sending AT3 to service C. This prevents C from being able to call B or A, both of which would have been available if AT1 had been passed around. Note that service A or the Client can also request a downscoped token with [ C ] to call service C directly as well, and C doesn’t have to care how it got there. In other words, it lets the client software be very, very dumb. It doesn’t have to do any special processing, doesn’t have to know what’s in the token, it just follows the recipe of “I got a token, I get another token based on this to call someone else”. It’s also analogous to the refresh token flow, but with access tokens going in and out. I’ve deployed this setup several times in different service deployments. Even though there is a performance hit in the additional round trips (as Phil brought up in another thread), in these cases the desire to have the tokens hold least privilege access rights (smallest set of scopes per service) outweighed any performance hit (which was shown to be rather small in practice). What I want is for the token swap draft to define or use a mechanism that allows us to do this. I think we can do that pretty easily by adjusting the token swap syntax and language, and explicitly calling out the semantic processing portion (the current core of the document) for what it is: a way for a token issuer to communicate to a token service specific actions. At a high level, the spec would be something like: 1. How to swap a token at an AS 1. Send a request to the token endpoint with a new grant type, and a token (of any type/format/flavor) on the way in 2. Get back a new token in a token response 2. Communicating act as / on behalf of semantics via a JWT assertion 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as semantics 2. What to do (as an AS/RS) with a JWT with act-as semantics 3. How to create a JWT with on-behalf-of semeantics 4. What to do with a JWT with on-behalf-of-semantics 5. How to possibly represent these semantics with something other than a JWT Section 2 uses the syntax from section 1. Other applications, like the one I laid out above, can use the
Re: [OAUTH-WG] trouble reading the start of sec 3 proof-of-possession-02
Yeah, sorry, I misspoke (this stuff isn't easy). The presenter doesn't confirm. The presenter presents the token along with something that proves possession, which allows the recipient to confirm. My original grip with both texts is that they seem to suggests that the presenter makes the declaration in the token, which isn't true except for the special case of issuer=presenter. In trying to clarify that, I made a different mistake. I'm sure the draft authors will have no problem stating it clearly, concisely and accurately though :) On Wed, Mar 25, 2015 at 10:34 AM, Justin Richer jric...@mit.edu wrote: Agree that this language isn’t clear. The presenter doesn’t confirm the claim either, the presenter never even looks for it (unless the presenter is the issuer, which is a special and hopefully rare case). That’s why the key is delivered to the presenter in parallel with the token. It’s the RS that confirms the claim (in OAuth PoP), or whoever’s processing the key-protected call downstream (in something that isn’t OAuth). — Justin On Mar 25, 2015, at 9:37 AM, Brian Campbell bcampb...@pingidentity.com wrote: There's similar wording in sec 3.3 https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3.3 too that seems to suggest that the presenter is the one that makes the claim. I think the presenter confirms the claim when it presents. It's the issuer that makes/asserts/declares the claim. No? In this case, the presenter of a JWT declares that it possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter by including a cnf (confirmation) claim in the JWT whose value is a JSON object, with the JSON object containing a kid (key ID) member identifying the key. On Sun, Mar 22, 2015 at 8:42 PM, Brian Campbell bcampb...@pingidentity.com wrote: My brain hurt trying to parse the first sentence/paragraph from section 3 https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3: The presenter of a JWT declares that it possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter by including a cnf (confirmation) claim in the JWT whose value is a JSON object, with the JSON object containing a jwk (JSON Web Key) or kid (key ID) member identifying the key. The issuer includes the cnf claim and makes the declaration not the presenter. Sure, the presenter may be the issuer but that's a special case. Isn't it more accurate to say that it is the issuer who declares that the presenter can confirm itself by some cryptographic proof-of-possession of the key identified by the cnf claim? Or something more like that... ___ 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] JWT Destination Claim
FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A Though the way I worded it probably shows my bias. On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones michael.jo...@microsoft.com wrote: Thanks for posting this, Brian. To get it down on the list, I’ll repeat my comment made in person that just as “aud” used to be single-valued and ended up being multi-valued, I suspect some applications would require the same thing of “dst” – at least when “aud” and “dst” are different. And even if “dst” becomes multi-valued, it’s OK for particular applications to require that it be single-valued in their usage. -- Mike *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Wednesday, March 25, 2015 2:08 PM *To:* oauth *Subject:* [OAUTH-WG] JWT Destination Claim Here are the slides that I rushed though at the end of the Dallas meeting: https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf And the -00 draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 In an informal discussion earlier this week John B. suggested that some additional thinking and/or clarification is needed with regard to what parts of the URI to include and check. Particularly with respect to query and fragment. And he's probably right. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JWT Destination Claim
Here are the slides that I rushed though at the end of the Dallas meeting: https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf And the -00 draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 In an informal discussion earlier this week John B. suggested that some additional thinking and/or clarification is needed with regard to what parts of the URI to include and check. Particularly with respect to query and fragment. And he's probably right. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Destination Claim
Tony, thanks as always for your thoughtful, well reasoned, and helpful comments. I'm well aware of the potential for confusion, which is why I endeavored to address the differences between aud and dst with text in the draft. I do appreciate your permission to use it ourselves and I'll be sure to let the engineers that have already deployed it know that they have your blessing. As I said on Monday, it struck me as something that would have value well beyond our own usage and that was why I wanted to start a conversation about standardization. You're stance on that has been made pretty clear, thanks. On Wed, Mar 25, 2015 at 6:57 PM, Anthony Nadalin tony...@microsoft.com wrote: There some folks out there that are using AUD to mean DST. Adding DST is confusing, if you want to use it that's fine but don't see a need to standardize every claim that someone comes up with Sent from my Windows Phone -- From: Brian Campbell bcampb...@pingidentity.com Sent: 3/25/2015 2:19 PM To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Destination Claim FWIW, I did have that as an open issue in the draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A Though the way I worded it probably shows my bias. On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones michael.jo...@microsoft.com wrote: Thanks for posting this, Brian. To get it down on the list, I’ll repeat my comment made in person that just as “aud” used to be single-valued and ended up being multi-valued, I suspect some applications would require the same thing of “dst” – at least when “aud” and “dst” are different. And even if “dst” becomes multi-valued, it’s OK for particular applications to require that it be single-valued in their usage. -- Mike *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Wednesday, March 25, 2015 2:08 PM *To:* oauth *Subject:* [OAUTH-WG] JWT Destination Claim Here are the slides that I rushed though at the end of the Dallas meeting: https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf And the -00 draft: http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00 In an informal discussion earlier this week John B. suggested that some additional thinking and/or clarification is needed with regard to what parts of the URI to include and check. Particularly with respect to query and fragment. And he's probably right. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Token Swap (token chaining)
And here's the somewhat different take on token exchange that I mentioned yesterday: https://tools.ietf.org/html/draft-campbell-oauth-sts-01 A little more background, context, and discussion about it can be seen following the thread on the Call for Adoption of OAuth 2.0 Token Exchange as an OAuth WG Item: https://www.ietf.org/mail-archive/web/oauth/current/msg13236.html https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html ... etc ... https://www.ietf.org/mail-archive/web/oauth/current/msg13311.html ... etc. On Mon, Mar 23, 2015 at 2:40 PM, Justin Richer jric...@mit.edu wrote: As mentioned in today’s IETF meeting, here are the two drafts dealing with generic token swap: https://tools.ietf.org/html/draft-hunt-oauth-chain-01 https://tools.ietf.org/html/draft-richer-oauth-chain-00 ___ 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] The use of sub in POP-02
+1 The JWT may well be about the sub but presented by some software component that should be independently identified. On Mon, Mar 23, 2015 at 2:25 AM, Nat Sakimura sakim...@gmail.com wrote: Re: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3 I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice. For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. So my proposal is to use a claim like azp instead of sub to identify the presenter. Less overload would cause less confusion later, IMHO. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ 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] proof-of-possession-02 cnf via key thumbprint?
Do folks in the WG think there'd be utility in having a way to identity the finger/thumbprint of a key in the cnf claim. A presenter might, for example, present the JWT along with a public JWK and some proof-of-possession of that JWK. And the JWK would be bound to the JWT via the thumbprint, which is more space efficient (with respect to the JWT anyway) than the full JWK. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?
When the JWT is itself encrypted as a JWE, would it not be reasonable to have a symmetric key be represented in the cnf claim with the jwk member as an unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be more explicitly allowed or disallowed? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint?
Yes, kid could do it. It just seemed less than idea and that, for confirmation, it might be useful to explicitly say this is the thumbprint of the key that'll confirm this JWT rather than here's something that points to a key for confirmation and in some cases it might be a thumbprint. But I just wanted to ask the question to gauge interest. And it seems there's not much. It could be added later too, if more need for it arises. On Mon, Mar 23, 2015 at 1:55 PM, Nat Sakimura sakim...@gmail.com wrote: ok, this is a full circle to my original comment Would not kid do? 2015年3月23日(月) 13:52 Brian Campbell bcampb...@pingidentity.com: I wasn't necessarily suggesting to drop the kid one. On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura sakim...@gmail.com wrote: +1 for dropping kid in favor of thumbprint. 2015年3月23日(月) 12:56 Brian Campbell bcampb...@pingidentity.com: Yeah, it could be done with kid. But that would require a bit more out-of-band understanding between the parties to know that the kid is, in fact, a thumbprint. Seems like it'd be better to outright support a thumbprint rather than overloading kid, if thumbprint representation of the key for confirmation is desirable. And yes, a thumbprint does have some nice properties. But I am also very sympathetic to the too many ways is not good for interop point. That's kind of why I asked what others thought of it rather than just making a suggestion. I'm not sure one way or the other myself. On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura sakim...@gmail.com wrote: Would not kid do? Right, thumbprint has more semantics and has nice properties, but having too many ways is not good for interop. Nat 2015-03-23 15:40 GMT+09:00 Brian Campbell bcampb...@pingidentity.com : Do folks in the WG think there'd be utility in having a way to identity the finger/thumbprint of a key in the cnf claim. A presenter might, for example, present the JWT along with a public JWK and some proof-of-possession of that JWK. And the JWK would be bound to the JWT via the thumbprint, which is more space efficient (with respect to the JWT anyway) than the full JWK. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Lunch (pre-)Meeting Monday
Looks like we are heading to the bbq grill at the hotel, if you're (Hannes) late and still want to join us. On Mar 22, 2015 6:10 PM, Derek Atkins de...@ihtfp.com wrote: Hi, Hannes and I would like to have a lunch meeting before the OAUTH meeting to chat about various ongoing WG activities. If you're available and interested meet us at IETF Regstration at 11:30 and we'll find a place. I expect we'll leave by 11:35 so please be prompt. -derek and hannes -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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] proof-of-possession-02 cnf via key thumbprint?
Yeah, it could be done with kid. But that would require a bit more out-of-band understanding between the parties to know that the kid is, in fact, a thumbprint. Seems like it'd be better to outright support a thumbprint rather than overloading kid, if thumbprint representation of the key for confirmation is desirable. And yes, a thumbprint does have some nice properties. But I am also very sympathetic to the too many ways is not good for interop point. That's kind of why I asked what others thought of it rather than just making a suggestion. I'm not sure one way or the other myself. On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura sakim...@gmail.com wrote: Would not kid do? Right, thumbprint has more semantics and has nice properties, but having too many ways is not good for interop. Nat 2015-03-23 15:40 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: Do folks in the WG think there'd be utility in having a way to identity the finger/thumbprint of a key in the cnf claim. A presenter might, for example, present the JWT along with a public JWK and some proof-of-possession of that JWK. And the JWK would be bound to the JWT via the thumbprint, which is more space efficient (with respect to the JWT anyway) than the full JWK. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proof-of-possession-02 cnf via key thumbprint?
I wasn't necessarily suggesting to drop the kid one. On Mon, Mar 23, 2015 at 1:00 PM, Nat Sakimura sakim...@gmail.com wrote: +1 for dropping kid in favor of thumbprint. 2015年3月23日(月) 12:56 Brian Campbell bcampb...@pingidentity.com: Yeah, it could be done with kid. But that would require a bit more out-of-band understanding between the parties to know that the kid is, in fact, a thumbprint. Seems like it'd be better to outright support a thumbprint rather than overloading kid, if thumbprint representation of the key for confirmation is desirable. And yes, a thumbprint does have some nice properties. But I am also very sympathetic to the too many ways is not good for interop point. That's kind of why I asked what others thought of it rather than just making a suggestion. I'm not sure one way or the other myself. On Mon, Mar 23, 2015 at 2:11 AM, Nat Sakimura sakim...@gmail.com wrote: Would not kid do? Right, thumbprint has more semantics and has nice properties, but having too many ways is not good for interop. Nat 2015-03-23 15:40 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: Do folks in the WG think there'd be utility in having a way to identity the finger/thumbprint of a key in the cnf claim. A presenter might, for example, present the JWT along with a public JWK and some proof-of-possession of that JWK. And the JWK would be bound to the JWT via the thumbprint, which is more space efficient (with respect to the JWT anyway) than the full JWK. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] similar to a certificate? intro of proof-of-possession-02
It says, The asymmetric key mechanism described above is conceptually similar to a certificate. near the end of https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-1 That kinda jumped out at me. I mean, I kinda see the point but it also seems like a pretty broad statement and potentially one that could be interpreted in unfavorable or unintended ways. Perhaps it should be left out? Otherwise maybe elaborate a bit on what is and what isn't similar to a certificate? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] 2119 abuse at the end of section 3 proof-of-possession-02
At the end of section 3 https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3 it says, 'At least one of the sub and iss claims MUST be present in the JWT, and in some use cases, both MUST be present.' Admittedly I've misused RFC 2119 keywords a few times myself, so I say this aware of my own hypocrisy, but shouldn't the second MUST in that sentience be a little must? I don't think some use cases is enough to know when it applies. Maybe even spitting it up into two sentences? Something like, 'At least one of the sub and iss claims MUST be present in the JWT. Some use cases may require that both be present.' ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt
I can't comment with any authority on product road-map (that's above my pay-grade) but I can speculate that we probably would support S256 eventually. On Wed, Feb 18, 2015 at 10:33 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Thanks Brian for pointing me to Section 4.4.1 and to the MTI for S256. While this is good from a security point of view I am wondering whether anyone is actually compliant to the specification. Neither PingIdentity nor DT implements the S256 transform, if I understood that correctly. Are you guys going planning to update your implementations? Ciao Hannes On 02/18/2015 05:45 PM, Brian Campbell wrote: There's a bit of MTI talk tucked into https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that perhaps needs to be expanded and/or placed somewhere else. On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net wrote: Thanks for the info, Torsten. Your feedback raises an interesting question, namely what functionality the parties have to implement to claim conformance to the specification. Quickly scanning through the specification didn't tell me whether it is OK to just implement the plain mode or whether both modes are mandatory-to-implement. We have to say something about this. Ciao Hannes On 02/18/2015 02:16 PM, tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: Hi Hannes, our implementation supports the plain mode only. We just verified compliance of our implementation with the current spec. As the only deviation, we do not enforce the minimum length of 43 characters of the code verifier. kind regards, Torsten. Am 17.02.2015 17:48, schrieb Hannes Tschofenig: Hi Torsten, does this mean that your implementation is not compliant with the current version anymore or that you haven't had time to verify whether there are differences to the earlier version? Ciao Hannes On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote: Deutsche Telekom also implemented an early version of the draft last year. Am 30.01.2015 um 18:50 schrieb Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com: On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net wrote: 1) What implementations of the spec are you aware of? We have an AS side implementation of an earlier draft that was released in June of last year: http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844 ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org mailto:OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-spop-10
On Wed, Feb 18, 2015 at 7:38 AM, John Bradley ve7...@ve7jtb.com wrote: I don’t remember precisely , but I may be the one responsible for the for the 2^(-128) value for code. The archives have a more precise memory http://www.ietf.org/mail-archive/web/oauth/current/msg03844.html ;) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-spop-10
I tend to agree with Torsten here - similar sentiments were (maybe not well) expressed a few weeks ago: http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html On Wed, Feb 18, 2015 at 6:36 AM, tors...@lodderstedt.net wrote: Hi Nat, as far as I understand, the length of at least 32 octets is justified for S256 only. So limiting the MUST to S256 would be ok (from my perspective). I consider a general MUST (which also applies to plain) a to strong requirement. kind regards, Torsten. Am 18.02.2015 10:50, schrieb Nat Sakimura: Is there anyone who has problems changing it to a MUST? On 2015年2月18日(水) at 18:48 Hannes Tschofenig hannes.tschofe...@gmx.net wrote: I think that the controlled environment is a risky idea. I believe we should definitely go for a MUST. On 02/18/2015 10:26 AM, Nat Sakimura wrote: Hi Hannes, The reason I have put SHOULD there instead of MUST is that there may be a valid reason not to in a controlled environment, and it does not interfere the interoperability. The deployment may opt to use other control than entropy, and SHOULD allows it while MUST does not. Having said that, if the WG is OK with a MUST there, I am fine with incorporating the proposed change. Cheers, Nat On Wed, 18 Feb 2015 09:43:30 +0100 Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Nat, thanks for the quick response. I was hoping to see a statement like The code verifier MUST have enough entropy to make it impractical to guess the value. in the text rather than the SHOULD. Given all the other statements in the draft I am not sure what the should actually means. Under what conditions would an implementer not provide enough entropy to make guessing impractical? Ciao Hannes On 02/18/2015 05:13 AM, Nat Sakimura wrote: Hi Hannes, I hereby confirm that I have submit the draft in full conformance with the provisions of BCP 78 and BCP 79. Re: Security Consideration (7.1) and section 4.1 The first part of the 7.1 is a non-normative prose explaining that the implementers got to make sure that the code verifier is hard to guessed or modeled. In a way, this is laying out the basic security property requirment on the code verifier. Then, it goes onto the implementation guideance that one need to use a cryptographic random number generator instead of relying on a rand() in some language that are not cryptographically random to generate 32-octet sequence. The same text is in 4.1 as well. We did not copy code verifier SHOULD have enough entropy to make it impractical to guess the value here because that looked needlessly repeating, but if you want, I have no objection in adding it to 7.1. Alternatively, in 7.1, after explaining the rationale, we can just point to 4.1 for the control and implementation guidance. Re: 32-octet We chose it because we are using SHA256 in generating the code challange. Having more entropy does not help us here, while having less octets increases the risk. Best, Nat On Tue, 17 Feb 2015 17:56:33 +0100 Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Nat, John, Naveen, thanks a lot for your work on the document. I still need responses to this mail to complete the shepherd writeup: http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html I definitely need the IPR confirmation. It would also be helpful to have someone who implemented the specification as it currently is. I asked Brian and Thorsten for clarification regarding their statements that they implemented earlier versions of the spec. As a final remark I still believe that the text regarding the randomness is still a bit inconsistent. Here are two examples: 1) In the Security Consideration you write that The security model relies on the fact that the code verifier is not learned or guessed by the attacker. It is vitally important to adhere to this principle. 2) In Section 4.1 you, however, write: NOTE: code verifier SHOULD have enough entropy to make it impractical to guess the value. It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence. There is clearly a long way from a SHOULD have enough entropy to the text in the security consideration section where you ask for 32 bytes entropy. It is also not clear why you ask for 32 bytes of entropy in particular. Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt
To clarify what I said there: 22-chars (128 bits) seems like way more than enough for a lower limit when using the plain challenge method. When using the S256 challenge method, exactly 43 char (256 bits) should probably always be used. On Thu, Feb 5, 2015 at 11:09 AM, Brian Campbell bcampb...@pingidentity.com wrote: 22-chars (128 bits) as a lower limit seems just fine for this case. ccm works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:49 AM, John Bradley ve7...@ve7jtb.com wrote: Inline On Feb 4, 2015, at 10:43 PM, Manger, James james.h.man...@team.telstra.com wrote: Title : Proof Key for Code Exchange by OAuth Public Clients Filename: draft-ietf-oauth-spop-09.txt https://tools.ietf.org/html/draft-ietf-oauth-spop-09 Some nits on this draft: 1. 42 chars. The lower limit of 42 chars for code_verifier: is not mentioned in prose (just the upper limit); is too high (128-bits=22-chars is sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, not 42). In my editors draft I fixed the 43 octet base64url encoding of 32bytes. I originally had 43 but it got changed at some point Is there working group feedback on making the lower limit clear in the prose and if so what should it be? 22-chars (128 bits) or 43 char (256 bits)? 2. Quotes around code_verifier and code_challenge in prose are okay, though not really necessary as the underscore is enough to distinguish them as technical labels. Quotes around these terms in formula is bad as it looks like the formula applies to the 13 or 14 chars of the label. The quoting is also used inconsistently. Suggestion: remove all quotes around code_verifier and code_challenge in prose and formula. For example, change ASCII(code_verifier) to ASCII(code_verifier). I am going to leave this for a later formatting cleanup at the moment, I need to find a good style compromise that works with rfcmarkup. 3. Two ways to check code_verifier are given in appendix B, whereas only one of these is mentioned in section 4.6. SHA256(verifier) === B64-DECODE(challenge) B64-ENCODE(SHA256(verifier)) === challenge I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the 1st from appendix B). It is simpler to mention only one. It also means base64url-decoding is never done, and doesn't need to be mentioned in the spec. Yes when I added the example I realized that the normative text was the more complicated way to do the comparison. I will go back and refactor the main text to talk about the simpler comparison and drop the base64url-decode references. 4. Expand MTI to mandatory to implement. Done in editors draft. P.S. Suggesting code challenge method names not exceed 8 chars to be compact is a bit perverse given the field holding these values has the long name code_challenge_method ;) On the topic of the parameter name code_challange_method, James has a point in that it is a bit long. We could shorten it to ccm. If we want to change the name sooner is better than later. It is that balance between compactness and clear parameter names for developers, that we keep running into. I don't know that encouraging longer parameter values is the best direction. Feedback please John B. -- James Manger ___ 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] I-D Action: draft-ietf-oauth-spop-09.txt
22-chars (128 bits) as a lower limit seems just fine for this case. ccm works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:49 AM, John Bradley ve7...@ve7jtb.com wrote: Inline On Feb 4, 2015, at 10:43 PM, Manger, James james.h.man...@team.telstra.com wrote: Title : Proof Key for Code Exchange by OAuth Public Clients Filename: draft-ietf-oauth-spop-09.txt https://tools.ietf.org/html/draft-ietf-oauth-spop-09 Some nits on this draft: 1. 42 chars. The lower limit of 42 chars for code_verifier: is not mentioned in prose (just the upper limit); is too high (128-bits=22-chars is sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, not 42). In my editors draft I fixed the 43 octet base64url encoding of 32bytes. I originally had 43 but it got changed at some point Is there working group feedback on making the lower limit clear in the prose and if so what should it be? 22-chars (128 bits) or 43 char (256 bits)? 2. Quotes around code_verifier and code_challenge in prose are okay, though not really necessary as the underscore is enough to distinguish them as technical labels. Quotes around these terms in formula is bad as it looks like the formula applies to the 13 or 14 chars of the label. The quoting is also used inconsistently. Suggestion: remove all quotes around code_verifier and code_challenge in prose and formula. For example, change ASCII(code_verifier) to ASCII(code_verifier). I am going to leave this for a later formatting cleanup at the moment, I need to find a good style compromise that works with rfcmarkup. 3. Two ways to check code_verifier are given in appendix B, whereas only one of these is mentioned in section 4.6. SHA256(verifier) === B64-DECODE(challenge) B64-ENCODE(SHA256(verifier)) === challenge I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the 1st from appendix B). It is simpler to mention only one. It also means base64url-decoding is never done, and doesn't need to be mentioned in the spec. Yes when I added the example I realized that the normative text was the more complicated way to do the comparison. I will go back and refactor the main text to talk about the simpler comparison and drop the base64url-decode references. 4. Expand MTI to mandatory to implement. Done in editors draft. P.S. Suggesting code challenge method names not exceed 8 chars to be compact is a bit perverse given the field holding these values has the long name code_challenge_method ;) On the topic of the parameter name code_challange_method, James has a point in that it is a bit long. We could shorten it to ccm. If we want to change the name sooner is better than later. It is that balance between compactness and clear parameter names for developers, that we keep running into. I don't know that encouraging longer parameter values is the best direction. Feedback please John B. -- James Manger ___ 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] PKCE/SPOP
I went thought appendix B and reproduced the same calculations. Which is nice. One little nit - to be consitent with the notation defined in §2, the appendix B should have BASE64URL(SHA256(ASCII(code_verifier))) == code_challenge rather than Base64url(SHA256(ASCII(code_verifier ))) == code_challenge On Sun, Feb 1, 2015 at 5:07 PM, John Bradley ve7...@ve7jtb.com wrote: https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt I made some edits to the copy in bitbucket. I changed the reference for unreserved URI characters to RFC3986. The Base64 spec we were pointing to is slightly different. The change allows someone in the future to define a new code_challenge_method that would allow a JWT to be valid. We unintentionally precluded the use of the “.” in code_challenge and code_verifier. I also added an appendix B to show the steps of S256 in a way someone could use as a test vector. Appendix B is a first cut at it so give me feedback, and I can push it to the document tracker later in the week. John B. ___ 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] PKCE: SHA256(WAT?)
But, while it may be clear to you, what I'm saying here is that it's not clear to a reader/implementer. Somehow the conversion from a character string to an octet string needs to be clearly and unambiguously stated. It doesn't have to be the text I suggested but it's not sufficient as it is now. Something like this might work, if you don't want to touch the parts in 4.2 and 4.6: SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING. An octet sequence using the url and filename safe Alphabet [...], with length less than 128 characters. is ambiguous. Octets and characters are intermixed with no mention of encoding. But they're not interchangeable. On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura sakim...@gmail.com wrote: I do not think we need ASCII(). It is quite clear without it, I suppose. In 4.1, I would rather do like: code_verifier = high entropy cryptographic random octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. Nat 2015-01-30 22:51 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: That's definitely an improvement (to me anyway). Checking that the rest of the document uses those notations appropriately, I think, yields a few other changes. And probably begs for the ASCII(STRING) denotes the octets of the ASCII representation of STRING notation/function, or something like it, to be put back in. Those changes might look like the following: In 4.1.: OLD: code_verifier = high entropy cryptographic random ASCII [RFC0020] octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. NEW (maybe): code_verifier = high entropy cryptographically strong random STRING using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. In 4.2.: OLD: S256 code_challenge = BASE64URL(SHA256(code_verifier)) NEW (maybe): S256 code_challenge = BASE64URL(SHA256(ASCII(code_verifier))) In 4.6.: OLD: SHA256(code_verifier ) == BASE64URL-DECODE(code_challenge). NEW (maybe): SHA256(ASCII(code_verifier)) == BASE64URL-DECODE(code_challenge). On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=nat) n...@sakimura.org wrote: I take your point, Brian. In our most recent manuscript, STRING is defined inside ASCII(STRING) as STRING is a sequence of zero or more ASCII characters but it is kind of circular, and we do not seem to use ASCII(). What about re-writing the section like below? STRING denotes a sequence of zero or more ASCII [RFC0020] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC0020 characters. OCTETS denotes a sequence of zero or more octets. BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 3 http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#Terminology producing a ASCII[RFC0020] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC0020 STRING. BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Section 3 http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#Terminology, producing a sequence of octets. SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC6234 of OCTETS. On Jan 30, 2015, at 08:15, Brian Campbell bcampb...@pingidentity.com wrote: In §2 [1] we've got SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING. But, in the little cow town where I come from anyway, you hash bits/octets not character strings (BTW, STRING isn't defined anywhere but it's kind of implied that it's a string of characters). Should it say something more like SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING.? I know it's kind of pedantic but I find it kind of confusing because the code_verifier uses the url and filename safe alphabet, which has me second guessing if SHA256(STRING) actually means a hash of the octet produced by base64url decoding the string. Maybe it's just me but, when reading the text, I find the transform process to be much more confusing than I think it needs to be. Removing and clarifying some things will help. I hate to suggest this but maybe an example showing the computation steps on both ends would be helpful? Also UTF8(STRING) and ASCII(STRING) notations are defined in §2 but not used anywhere. And §2 also says, BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Section 3, producing a UTF-8 sequence of octets. But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3629] reference, I think, could be removed. [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 Nat Sakimura n...@sakimura.org -- Nat
Re: [OAUTH-WG] PKCE: SHA256(WAT?)
https://bitbucket.org/Nat/oauth-spop/commits/af9ce76988cd32b334e21c71289721a3bf1c4ff1 looks good to me. Thanks John. On Fri, Jan 30, 2015 at 1:47 PM, John Bradley ve7...@ve7jtb.com wrote: OK try that one. On Jan 30, 2015, at 5:15 PM, Brian Campbell bcampb...@pingidentity.com wrote: I agree with Mike here. Though PKCE only needs the ASCII(STRING) one. On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones michael.jo...@microsoft.com wrote: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-1.1 uses this notation: UTF8(STRING) denotes the octets of the UTF-8 [RFC3629 http://tools.ietf.org/html/rfc3629] representation of STRING, where STRING is a sequence of zero or more Unicode [UNICODE http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#ref-UNICODE] characters. ASCII(STRING) denotes the octets of the ASCII [RFC20 http://tools.ietf.org/html/rfc20] representation of STRING, where STRING is a sequence of zero or more ASCII characters. This is unambiguous and has already been vetted by the IESG and SecDir, so I would use exactly this wording. OCTETS(STRING) is ambiguous, since for the same string there are many possible representations as octets, including ASCII, UTF-8, UTF-16, UTF-32, and EBCDIC. -- Mike *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley *Sent:* Friday, January 30, 2015 11:33 AM *To:* Brian Campbell *Cc:* oauth; Naveen Agarwal *Subject:* Re: [OAUTH-WG] PKCE: SHA256(WAT?) Have a look at the latest version I added OCTETS(STRING) to show the conversion. ASCII(STRING) seemed more confusing by drawing character encoding back in. I was tempted to call it a octet array without the terminating NULL of STRING but didn’t want to introduce array. Let me know what you think. On Jan 30, 2015, at 1:56 PM, Brian Campbell bcampb...@pingidentity.com wrote: But, while it may be clear to you, what I'm saying here is that it's not clear to a reader/implementer. Somehow the conversion from a character string to an octet string needs to be clearly and unambiguously stated. It doesn't have to be the text I suggested but it's not sufficient as it is now. Something like this might work, if you don't want to touch the parts in 4.2 and 4.6: SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING. An octet sequence using the url and filename safe Alphabet [...], with length less than 128 characters. is ambiguous. Octets and characters are intermixed with no mention of encoding. But they're not interchangeable. On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura sakim...@gmail.com wrote: I do not think we need ASCII(). It is quite clear without it, I suppose. In 4.1, I would rather do like: code_verifier = high entropy cryptographic random octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. Nat 2015-01-30 22:51 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: That's definitely an improvement (to me anyway). Checking that the rest of the document uses those notations appropriately, I think, yields a few other changes. And probably begs for the ASCII(STRING) denotes the octets of the ASCII representation of STRING notation/function, or something like it, to be put back in. Those changes might look like the following: In 4.1.: OLD: code_verifier = high entropy cryptographic random ASCII [RFC0020] octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. NEW (maybe): code_verifier = high entropy cryptographically strong random STRING using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. In 4.2.: OLD: S256 code_challenge = BASE64URL(SHA256(code_verifier)) NEW (maybe): S256 code_challenge = BASE64URL(SHA256(ASCII(code_verifier))) In 4.6.: OLD: SHA256(code_verifier ) == BASE64URL-DECODE(code_challenge). NEW (maybe): SHA256(ASCII(code_verifier)) == BASE64URL-DECODE(code_challenge). On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=nat) n...@sakimura.org wrote: I take your point, Brian. In our most recent manuscript, STRING is defined inside ASCII(STRING) as STRING is a sequence of zero or more ASCII characters but it is kind of circular, and we do not seem to use ASCII(). What about re-writing the section like below? STRING denotes a sequence of zero or more ASCII [RFC0020] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC0020 characters. OCTETS denotes a sequence of zero or more octets. BASE64URL(OCTETS) denotes
Re: [OAUTH-WG] PKCE: SHA256(WAT?)
That's definitely an improvement (to me anyway). Checking that the rest of the document uses those notations appropriately, I think, yields a few other changes. And probably begs for the ASCII(STRING) denotes the octets of the ASCII representation of STRING notation/function, or something like it, to be put back in. Those changes might look like the following: In 4.1.: OLD: code_verifier = high entropy cryptographic random ASCII [RFC0020] octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. NEW (maybe): code_verifier = high entropy cryptographically strong random STRING using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. In 4.2.: OLD: S256 code_challenge = BASE64URL(SHA256(code_verifier)) NEW (maybe): S256 code_challenge = BASE64URL(SHA256(ASCII(code_verifier))) In 4.6.: OLD: SHA256(code_verifier ) == BASE64URL-DECODE(code_challenge). NEW (maybe): SHA256(ASCII(code_verifier)) == BASE64URL-DECODE(code_challenge). On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=nat) n...@sakimura.org wrote: I take your point, Brian. In our most recent manuscript, STRING is defined inside ASCII(STRING) as STRING is a sequence of zero or more ASCII characters but it is kind of circular, and we do not seem to use ASCII(). What about re-writing the section like below? STRING denotes a sequence of zero or more ASCII [RFC0020] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC0020 characters. OCTETS denotes a sequence of zero or more octets. BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 3 http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#Terminology producing a ASCII[RFC0020] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC0020 STRING. BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Section 3 http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#Terminology, producing a sequence of octets. SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi#RFC6234 of OCTETS. On Jan 30, 2015, at 08:15, Brian Campbell bcampb...@pingidentity.com wrote: In §2 [1] we've got SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING. But, in the little cow town where I come from anyway, you hash bits/octets not character strings (BTW, STRING isn't defined anywhere but it's kind of implied that it's a string of characters). Should it say something more like SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING.? I know it's kind of pedantic but I find it kind of confusing because the code_verifier uses the url and filename safe alphabet, which has me second guessing if SHA256(STRING) actually means a hash of the octet produced by base64url decoding the string. Maybe it's just me but, when reading the text, I find the transform process to be much more confusing than I think it needs to be. Removing and clarifying some things will help. I hate to suggest this but maybe an example showing the computation steps on both ends would be helpful? Also UTF8(STRING) and ASCII(STRING) notations are defined in §2 but not used anywhere. And §2 also says, BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Section 3, producing a UTF-8 sequence of octets. But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3629] reference, I think, could be removed. [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 Nat Sakimura n...@sakimura.org ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Misplaced Resource Owner in PKCE
In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization request going to the Resource Owner and goes on to say that 'the resource owner responds as usual, but records t(code_verifier) and the transformation method.' That's not what the resource owner does. I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in §1.1 seems, at best, to be more abstract and complicated than it needs to be and is bordering on being just kinda wrong. The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that... [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 1.1 https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1. Protocol Flow ++ +---+ ||--(A)-- Authorization Request ---| | ||+ t(code_verifier), t | Resource| || | Owner | ||-(B)--- Authorization Grant -| | || +---+ | Client | || +---+ ||--(C)--- Access Token Request ---| | || + code_verifier | Authorization | || | Server| ||-(D)-- Access Token -| | ++ +---+ Figure 2: Abstract Protocol Flow This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 1. A. The client creates and records a secret named the code_verifier, and derives a transformed version t(code_verifier) (referred to as the code_challenge) which is sent in the OAuth 2.0 Authorization Request, along with the transformation method t. B. The resource owner responds as usual, but records t(code_verifier) and the transformation method. C. The client then sends the code to the Access Token Request as usual, but includes the code_verifier secret generated at (A). D. The authorization server transforms code_verifier and compares it to t(code_verifier) from (B). Access is denied if they are not equal. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
Works for me. The text below needs to be fixed up to match too. On Thu, Jan 29, 2015 at 3:14 PM, John Bradley ve7...@ve7jtb.com wrote: How about ++ +---+ ||--(A)-- Authorization Request ---| | ||+ t(code_verifier), t | Authorization | || |Endpoint | ||-(B)- Authorization Code Grant --| | || +---+ | Client | || +---+ ||--(C)--- Access Token Request ---| | || + code_verifier |Token | || | Endpoint| ||-(D)-- Access Token -| | ++ +--- On Jan 29, 2015, at 7:01 PM, Brian Campbell bcampb...@pingidentity.com wrote: In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization request going to the Resource Owner and goes on to say that 'the resource owner responds as usual, but records t(code_verifier) and the transformation method.' That's not what the resource owner does. I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in §1.1 seems, at best, to be more abstract and complicated than it needs to be and is bordering on being just kinda wrong. The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that... [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 1.1 https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1. Protocol Flow ++ +---+ ||--(A)-- Authorization Request ---| | ||+ t(code_verifier), t | Resource| || | Owner | ||-(B)--- Authorization Grant -| | || +---+ | Client | || +---+ ||--(C)--- Access Token Request ---| | || + code_verifier | Authorization | || | Server| ||-(D)-- Access Token -| | ++ +---+ Figure 2: Abstract Protocol Flow This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 1. A. The client creates and records a secret named the code_verifier, and derives a transformed version t(code_verifier) (referred to as the code_challenge) which is sent in the OAuth 2.0 Authorization Request, along with the transformation method t. B. The resource owner responds as usual, but records t(code_verifier) and the transformation method. C. The client then sends the code to the Access Token Request as usual, but includes the code_verifier secret generated at (A). D. The authorization server transforms code_verifier and compares it to t(code_verifier) from (B). Access is denied if they are not equal. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
Good by me. On Thu, Jan 29, 2015 at 3:35 PM, John Bradley ve7...@ve7jtb.com wrote: ++ +---+ ||--(A)-- Authorization Request ---| | ||+ t(code_verifier), t | Authorization | || |Endpoint | ||-(B) Authorization Code -| | || +---+ | Client | Authz Server || +---+ ||--(C)--- Access Token Request ---| | || + code_verifier |Token | || | Endpoint| ||-(D)-- Access Token -| | ++ +---+ Figure 2: Abstract Protocol Flow Sakimura, et al. Expires August 2, 2015 [Page 4] Internet-Draft oauth_pkce January 2015 This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 1. A. The client creates and records a secret named the code_verifier, and derives a transformed version t(code_verifier) (referred to as the code_challenge) which is sent in the OAuth 2.0 Authorization Request, along with the transformation method t. B. The Authorization Endpoint responds as usual, but records t(code_verifier) and the transformation method. C. The client then sends the code in the Access Token Request as usual, but includes the code_verifier secret generated at (A). D. The authorization server transforms code_verifier and compares it to t(code_verifier) from (B). Access is denied if they are not equal. On Jan 29, 2015, at 7:16 PM, Brian Campbell bcampb...@pingidentity.com wrote: Works for me. The text below needs to be fixed up to match too. On Thu, Jan 29, 2015 at 3:14 PM, John Bradley ve7...@ve7jtb.com wrote: How about ++ +---+ ||--(A)-- Authorization Request ---| | ||+ t(code_verifier), t | Authorization | || |Endpoint | ||-(B)- Authorization Code Grant --| | || +---+ | Client | || +---+ ||--(C)--- Access Token Request ---| | || + code_verifier |Token | || | Endpoint| ||-(D)-- Access Token -| | ++ +--- On Jan 29, 2015, at 7:01 PM, Brian Campbell bcampb...@pingidentity.com wrote: In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization request going to the Resource Owner and goes on to say that 'the resource owner responds as usual, but records t(code_verifier) and the transformation method.' That's not what the resource owner does. I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in §1.1 seems, at best, to be more abstract and complicated than it needs to be and is bordering on being just kinda wrong. The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that... [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 1.1 https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1. Protocol Flow ++ +---+ ||--(A)-- Authorization Request ---| | ||+ t(code_verifier), t | Resource| || | Owner | ||-(B)--- Authorization Grant -| | || +---+ | Client | || +---+ ||--(C)--- Access Token Request ---| | || + code_verifier | Authorization
Re: [OAUTH-WG] Meeting Minutes
My question was not really about the status of draft-bradley-oauth-stateless-client-id but rather about draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless client id that Bradley described in his draft. And draft-ietf-oauth-dyn-reg-management still has text that says, 'The value of the client_id MUST NOT change from the initial registration response.' which makes it incompatible with the concepts described in draft-bradley-oauth-stateless-client-id. On Thu, Nov 13, 2014 at 8:05 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, here is a draft version of the meeting minutes: http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth Thanks to Brian Rosen for taking notes. Comments are welcome! 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] crosspost.... SASL OAUTH
Given the state of things, maybe the MAC Token specification [I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted? On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills wmills_92...@yahoo.com wrote: There's a draft it would be great to get more eyes on in the Kitten WG draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-17 Nearing it's 5th and hopefully final WGLC, so any more eyes and comments on it would be welcome. Thanks, -bill ___ 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] bike-shedding the SPOP into
In the into, I'd suggest changing, The code verifier is created for every authorization request... to A unique code verifier is created for every authorization request... ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Adding machine readable errors to SPOP?
I struggle to see the value in adding more fine grained machine readable error messages for this. Do we really want clients to try and negotiate the code_challenge_method using browser redirects? Especially in light of the fact that we'll likely also be discouraging AS's from redirecting on some error conditions when there's no user interaction. On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura sakim...@gmail.com wrote: As discussed at F2F today at IETF 91 OAuth WG, there has been some request to have a more fine grained machine readable error messages. Currently, it only returns the error defined in RFC6749 and any more details is supposed to be returned in error_descripton and error_uri. So, I came up with the following proposal. If WG agrees, I would put text embodying it into the draft-04. Otherwise, I would like to go as is. You have to speak out to put it in. (I am sending out -03, which we meant to send before submit freeze, without it..) nError response to authorization request lReturns invalid_request with additional error param spop_error with the following values: ▪S256_unsupported ▪none_unsupported ▪invalid_code_challenge Clients MUST NOT accept the downgrade request through this as it may be a downgrade attack by a MITM. nError response to token request lReturns invalid_request with additional error param spop_error with the following values: ▪invalid _code_verifier ▪verifier_challenge_mismatch nAuthorization server should return more descriptive information on lerror_description lerror_uri ___ 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] Meeting Minutes
I'd guess people wouldn't try to deploy those two options together because it's clearly prohibited. On Fri, Nov 14, 2014 at 9:47 AM, Justin Richer jric...@mit.edu wrote: Brian is right, it's still a MUST NOT. We could relax that to a SHOULD NOT to allow for the (still largely theoretical) structured client_id construct to change over time. The reason it's how it is right now is that most systems use the client_id value as a key into things and funny expect it to change, as was discussed at several meetings and on the list already. Current implementations of this spec don't use structured client_id values. But as this is now tagged as experimental, we could also just publish it as is and see if anybody actually tried to deploy those two options together. -- Justin / Sent from my phone / Original message From: Brian Campbell bcampb...@pingidentity.com Date:11/14/2014 4:26 AM (GMT-10:00) To: Hannes Tschofenig hannes.tschofe...@gmx.net Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Meeting Minutes My question was not really about the status of draft-bradley-oauth-stateless-client-id but rather about draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless client id that Bradley described in his draft. And draft-ietf-oauth-dyn-reg-management still has text that says, 'The value of the client_id MUST NOT change from the initial registration response.' which makes it incompatible with the concepts described in draft-bradley-oauth-stateless-client-id. On Thu, Nov 13, 2014 at 8:05 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, here is a draft version of the meeting minutes: http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth Thanks to Brian Rosen for taking notes. Comments are welcome! 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] draft-ietf-oauth-spop naming
I agree that changing the name could avoid a lot of unnecessary confusion (and said as much in Sept https://www.ietf.org/mail-archive/web/oauth/current/msg13361.html). On Wed, Nov 12, 2014 at 9:46 AM, Bill Mills wmills_92...@yahoo.com wrote: Any progress on naming on this thing? Didn't see any reply to my previous comment, but that might have been because I replied to the -02 publication notice and it might have gotten filtered. Similarly, the question of extending the error registry to allow the server tofeed back a failure if the server's required hash method isn't sent. Also may need a way to advertise what hash method is required. Regards, -bill ___ 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: draft-ietf-oauth-jwt-bearer draft errors
Forwarding this to the WG. There is a word missing in the sentence noted below as well as in the similar sentence in the SAML draft. However, I believe it should be to the client rather than about the client. What is the most appropriate way to handle a minor fix like this at this stage? A note to the RFC editor? Or should I push new drafts? https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11#section-7 https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-22#section-7 -- Forwarded message -- From: Benjamin Trofatter trofat...@google.com Date: Sat, Nov 8, 2014 at 8:11 PM Subject: draft-ietf-oauth-jwt-bearer draft errors To: m...@microsoft.com, brian.d.campb...@gmail.com, cmortim...@salesforce.com Hi, I was reading your draft and noticed a couple of typos. In 7 Privacy paragraph 1, the last sentence reads: In cases where it is desirable to prevent disclosure of certain information the client, the JWT should be be encrypted to the authorization server. I'm guessing this ought to say something like: In cases where it is desirable to prevent disclosure of certain information about the client, the JWT should be encrypted to the authorization server. Hope this helps, Ben *___* Ben Trofatter // Software Engineer // trofatter@g oogle.com // (650) 279-0512 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: draft-ietf-oauth-jwt-bearer draft errors
Sure thing, new drafts have just been posted. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-23 On Wed, Nov 12, 2014 at 12:08 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: Hi Brian, If you could make a quick update, that would be easier to prevent it from getting lost. The shepherd and I will recheck the draft and then I'll move it forward. Thanks for all of your work on this! Kathleen On Wed, Nov 12, 2014 at 12:05 PM, Brian Campbell bcampb...@pingidentity.com wrote: Forwarding this to the WG. There is a word missing in the sentence noted below as well as in the similar sentence in the SAML draft. However, I believe it should be to the client rather than about the client. What is the most appropriate way to handle a minor fix like this at this stage? A note to the RFC editor? Or should I push new drafts? https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11#section-7 https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-22#section-7 -- Forwarded message -- From: Benjamin Trofatter trofat...@google.com Date: Sat, Nov 8, 2014 at 8:11 PM Subject: draft-ietf-oauth-jwt-bearer draft errors To: m...@microsoft.com, brian.d.campb...@gmail.com, cmortim...@salesforce.com Hi, I was reading your draft and noticed a couple of typos. In 7 Privacy paragraph 1, the last sentence reads: In cases where it is desirable to prevent disclosure of certain information the client, the JWT should be be encrypted to the authorization server. I'm guessing this ought to say something like: In cases where it is desirable to prevent disclosure of certain information about the client, the JWT should be encrypted to the authorization server. Hope this helps, Ben ___ Ben Trofatter // Software Engineer // trofat...@google.com // (650) 279-0512 ___ 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
[OAUTH-WG] New Assertion Drafts Published
New versions of all three OAuth assertion documents (listed below) have been published with changes incorporating feedback received during IESG Evaluation. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ http://tools.ietf.org/html/draft-ietf-oauth-assertions-18 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-22 https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: EncryptedAssertion in draft-ietf-oauth-saml2-bearer-21
I received the below over the weekend and, although oauth@ietf.org is cc'd, it didn't post to the list - I assume because sampo-i...@zxidp.org isn't subscribed. I thought I should send to the WG list so folks are aware. I don't believe EncryptedAssertion should be supported, for three main reasons. 1) It is very late in the document process, which is currently in IESG review. It's too late, really, for a change like this. 2) It adds complexly that's not necessarily needed as the Subject and/or individual attributes of a SAML Assertion can be encrypted to the authorization server 3) It greatly increases the risk that usage of this profile be vulnerable to attacks such as those described in http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/ whereas having the encrypted parts appear under a signature (and not attempting decryption if the signature validation fails) mitigates the risk -- Forwarded message -- From: sampo-i...@zxidp.org Date: Sat, Oct 18, 2014 at 4:05 PM Subject: EncryptedAssertion in draft-ietf-oauth-saml2-bearer-21 To: brian.d.campb...@gmail.com Cc: oauth@ietf.org, sampo-i...@zxidp.org Seems sec 3, list item 10 (p.8) mentions that encryption per SAML2 is allowed, but I think it would be helpful to call out that specifically EncryptedAssertion is allowed. Mentioning EncryptedAssertion as valid possibility in secs 2.2 and 2.3 would also help. The Privacy Considerations section should mention use of EncryptedAssertion to protect against eavesdropping by intermediaries that handle assertions (e.g. OAUTH Client which gets it from STS and passes it to AS). Cheers, --Sampo ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SPOP - code verifier requirements
In the default case, aren't the challenge and verifier just an arbitrary string value? One that would be application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other parameter value? If the client uses unreserved characters then no additional encoding is needed but Im not sure I see any reason to restrict it. If a transform is used, I'd think that the transform defines how the octets are represented as strings. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SPOP - code verifier requirements
That all makes sense. And yeah, our AS side implementation just does a string compare. I'd just really like to keep that compliant as the spec gets updated. But being tighter about what the client can send doesn't change anything there. If the concern is about people using a good source of entropy, then something to that effect should probably be said directly. On Mon, Oct 20, 2014 at 2:54 PM, John Bradley ve7...@ve7jtb.com wrote: Part of the issue is that we want people to use a good source of entropy for this. PRNG on the device seems like the most likely thing. Those generally give you a an array of bytes. Yes you could use anything to make them URL safe but that happens to be precisely what base64url is intended for. So while it is true that they could come up with some other way to do it, likely that is the result of doing something stupid around generating the values like using a fixed string with a counter. In the default mode the AS is just doing a string compare so what the client uses to encode the string the string is probably not relevant to the server. Saying that the client MUST send a URL safe value vs letting it be encoded by the http lib is I think important for interoperability. For the SHA256 version we are adding base64url encoding for both the hash and the string seem the best choice as well. John B. On Oct 20, 2014, at 5:25 PM, Nat Sakimura sakim...@gmail.com wrote: So, for the default case, the intent was to use just the unreserved chars, i.e., code_verifier = code_challenge = 16*128unreserved unreserved= ALPHA / DIGIT / - / . / _ / ~ In sha256 case, I would expect the transform to conform to the constraint: i.e., define such a transform so that the end result expressed in code_verifier and code_challenge would be expressed in unreserved. Nat 2014-10-20 15:13 GMT-05:00 Brian Campbell bcampb...@pingidentity.com: In the default case, aren't the challenge and verifier just an arbitrary string value? One that would be application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other parameter value? If the client uses unreserved characters then no additional encoding is needed but Im not sure I see any reason to restrict it. If a transform is used, I'd think that the transform defines how the octets are represented as strings. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ 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)
These drafts define the use of bearer assertions. The only mention of HoK style assertions is at the end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which notes that the rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need to be specified. The requirement of having audience is for bearer assertions only (and we agree need to be that way for bearer) and not intended to preclude anything for HoK assertions. Does that change your opinion? Is there something that could be added or removed or clarified to allay concerns? On Thu, Oct 16, 2014 at 6:54 PM, John Bradley ve7...@ve7jtb.com wrote: Holder of key JWT is still in draft and we don't have a clear way to present the proof to the token endpoint. Brian and I started discussing that last week as I happen to have a use case for a PoP JWT assertion flow in some other spec work. I think that there is enough difference between bearer and PoP that doing a follow on profile for SAML and JWT that can also cover the proof presentment mechanisms makes the most sense. I would go with restricting this to Bearer and MUST for audience, and removing the audience requirement explicitly in the PoP profiles. There are people who need the bearer version 6 months ago, I don't want to do anything to hold it up based on future work. I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML subject confirmation stuff is relatively clear so it is mostly defining the presentment mechanisms like mutual TLS and a self signed assertion. (we need to be careful not to conflate client authentication and token proof, as they are different and might both be used at the same time. John B. On Oct 16, 2014, at 7:20 PM, Richard Barnes r...@ipv.sx wrote: You guys are all arguing that having an Audience can be useful. I don't disagree. I disagree that it should be REQUIRED in all cases. The Google vulnerability that Brian raised was an interesting read, but as John points out, it only applies to Bearer Assertions. There's no security requirement at all for holder-of-key assertions to have an audience, since they can't be replayed by someone who doesn't hold the key. I could agree that an audience should be REQUIRED for bearer assertions. Since they are vulnerable to replay, Audience protects against the Authorization Server re-using the token. (It would be good to say this explicitly in the doc, actually.) But for holder-of-key assertions, the Audience should be OPTIONAL. Note that this requires that instance documents define the difference between bearer assertions and 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 phil.h...@oracle.com 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 bcampb...@pingidentity.com wrote: Thanks for your review and feedback, Richard. Replies are inline below... On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes r...@ipv.sx 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
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes r...@ipv.sx wrote: On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell bcampb...@pingidentity.com 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 r...@ipv.sx 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 Audience 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. I'll add the suggested text. 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? It was discussed but it's not simple for reasons I've tried to articulate many times. Note that the specific profiling or usage of these specs can constrain or dictate the values of this and other the things that needing out of band negotiation and can be more in the spirit of the Internet to the extent that they define dynamic exchange/discovery/registration/etc. of required information. But these little documents need to fit into such larger contexts not try and define them. --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-saml2-bearer-21: (with DISCUSS)
Touché... ;) On Thu, Oct 16, 2014 at 4:36 PM, Richard Barnes r...@ipv.sx wrote: That's what you get for duplicating all the text :) On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell bcampb...@pingidentity.com 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 r...@ipv.sx 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 Audience 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 Audience 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-assertions-17: (with DISCUSS and COMMENT)
That text works for me, Richard. Thanks. I will go with Richard's text in the next draft, unless I hear objections. FWIW, the mention of HoK was a result of a review and suggestions from Hannes some time ago. http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-04.txt It could be removed, to your point, but I think your proposed text is very clear about the scope and might help prevent confusion. On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes r...@ipv.sx wrote: On Fri, Oct 17, 2014 at 10:32 AM, John Bradley ve7...@ve7jtb.com wrote: I think this part of sec 3 of assertions states that: The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need to be specified. As part of defining the additional protocol details for holder-of-key/PoP we can relax the must for audience in the profile that defines how to use those assertion types. I think we're on a path to convergence here. Given all this, is there any point to even mentioning HoK credentials here? The entire remainder of the spec is written as if they didn't exist. And as the text above notes, you can't actually use them with this specification. If we're going to keep the mention, could we augment the text above to make it clearer that HoK assertions are out of scope. The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. They are not suitable for use with holder-of-key assertions. While they could be used as a baseline for a holder-of-key assertion system, there would be a need for additional mechanisms (to support proof of possession of the secret key), and possibly changes to the security model (e.g., to relax the requirement for an Audience). --Richard John B. On Oct 17, 2014, at 2:25 PM, Pete Resnick presn...@qti.qualcomm.com wrote: On 10/17/14 12:09 PM, Mike Jones wrote: This is the standard mitigation for a known set of actual attacks. We shouldn’t even consider making it optional. Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Secdir Review of draft-ietf-oauth-jwt-bearer-10
I agree with mike that any additional guidance on when you'd want to use an assertion for client authentication vs. when you would want to use one for an authorization grant would belong in the generic assertions specification draft-ietf-oauth-assertions. I'm struggling with what guidance to give about it, however. Maybe I'm just too close to things but it seems almost definitional - one is for client auth and the other is an authz grant. Radia (or really anyone), is there some specific text you can propose? On Mon, Oct 6, 2014 at 1:54 AM, Mike Jones michael.jo...@microsoft.com wrote: Thanks for your review, Radia. I've added the working group to the thread so that they're aware of your comments. From: Radia Perlman [mailto:radiaperl...@gmail.com] Some background guidance on when you would want to use a token for client authentication vs. when you would want to use one for an authorization grant would be useful. In practice, the distinction between the two is subtle. It is common for a token to contain the caller’s identity as well as group memberships and perhaps roles. I suspect the reality is that the client has to figure out which protocol slot the server wants to get the token in and provide it there, where service designers make the decision more or less arbitrarily. This guidance really belongs in the generic assertions specification draft-ietf-oauth-assertions. I'll plan on reviewing that spec with the other editors and the working group to see whether the guidance provided there needs to be improved. ___ 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)
Stephen, I'm working on updating these drafts and as I look again at the text that's in §5. Interoperability Considerations and the requirement in §3 Assertion Format and Processing Requirements to compare these values using the Simple String Comparison (absent an application profile specifying otherwise) I'm not sure what to say or where based on your suggestion below. Is there something specific you can suggest (and where to put it)? Thanks, Brian On Thu, Oct 16, 2014 at 3:20 PM, Brian Campbell bcampb...@pingidentity.com wrote: On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell stephen.farr...@cs.tcd.ie 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] 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 presn...@qti.qualcomm.com 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 SubjectConfirmation element MUST contain a SubjectConfirmationData element, unless the Assertion has a suitable NotOnOrAfter attribute on the Conditions element, in which case the SubjectConfirmationData 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 Conditions element, the SubjectConfirmation element MUST contain a SubjectConfirmationData element. OK Subpoint 6: OLD The authorization server MUST verify that the NotOnOrAfter
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 presn...@qti.qualcomm.com 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-21difftype=--htmlsubmit=Go%21url2=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] 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 stephen.farr...@cs.tcd.ie 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] 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 bcampb...@pingidentity.com 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 ted.le...@nominum.com On Thu, Oct 16, 2014 at 7:42 AM, Ted Lemon ted.le...@nominum.com wrote: On Oct 16, 2014, at 8:37 AM, Brian Campbell bcampb...@pingidentity.com 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
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 r...@ipv.sx 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] 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 stephen.farr...@cs.tcd.ie 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 additional clarification, if you
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 stephen.farr...@cs.tcd.ie 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] 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 r...@ipv.sx 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 Audience 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] 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 r...@ipv.sx 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 Audience 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 Audience 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 No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell stephen.farr...@cs.tcd.ie 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] 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 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! 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)
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] Secdir review of draft-ietf-oauth-saml2-bearer-21
Thanks for your review and feedback, Vincent. I'm adding the working group to the thread so they’re aware of the comments. Replies are inline below... From: Vincent Roca vincent.r...@inria.fr Date: Tue, Oct 14, 2014 at 9:10 AM Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21 To: IESG i...@ietf.org, sec...@ietf.org, draft-ietf-oauth-saml2-bea...@tools.ietf.org Cc: Vincent Roca vincent.r...@inria.fr Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. IMHO, the document is *almost ready*. I just have minor comments: SAML and OAUTH are already covered by extensive, detailed security and privacy considerations sections. I agree with the authors there is no need to duplicate text in the present document. However I have two comments: 1- it is mentioned that replay attack protection is not mandatory, but there is no justification. On the opposite, protection against replay attacks is mentioned at several places in [OASIS.saml-sec-consider-2.0-os] (e.g., 6.1.2, 6.4.5, 6.5.2, 6.5.6, 7.1.1.4). I don’t know to what extent the situation differs, but I’m curious to know why it is so. In the SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants the client is not passive (like a web browser in the case of many SAML profiles/bindings) but rather an active client which either creates the assertion itself or obtains it from a trusted 3rd party system like a security token service. In that sense, it's most analogous to 6.1.2 of OASIS.saml-sec-consider-2.0-os which discusses replay in the context of the SOAP binding and says there is little vulnerability to replay attacks and that the best way to prevent replay attacks is to prevent the message capture in the first place going on to say that TLS does this for point to point communication. The general Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, which the SAML document is a concrete profile of, discusses replay some in section 8.2 ( https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-8.2 ) and says similar things. In my own personal view, I think tracking assertion ids and rejecting those that have been seen before does more harm to interoperability and deployment at scale than good in mitigating a threat that's already reasonably mitigated by other means. Others have wanted to have the option in the documents, however, which is (as I recall) where the optionality of it comes from. 2- [OASIS.saml-sec-consider-2.0-os] reference does not include any URL. It’s probably worth to add it. http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf Perhaps you can help me with the tool usage here? In the source XML I've got ?rfc include=' http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-consider-2.0-os.xml' ? in the references and http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-consider-2.0-os.xml has that URL via format type=PDF target= http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf/ but the URL doesn't show up in the rendered document. The situation is the same for all the SAML references, FWIW. ___ 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-assertions-17: (with COMMENT)
Thanks for your review and feedback, Pete. Replies are inline below... On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick presn...@qti.qualcomm.com wrote: Pete Resnick 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: -- 3 - 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. 4.1 - grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. That MUST is unnecessary. It's just definitional from 6749, 4.5 (which, as it happens, doesn't use 2119 language for this). s/MUST/will Makes sense. assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents. The serialization MUST be encoded for transport within HTTP forms. It is RECOMMENDED that base64url be used. The MUST seems weird here. Are you saying that the profile could not possibly have a serialization for an assertion that did not require further encoding? But the RECOMMENDED seems downright wrong: Either an implementer *needs* to know the encoding independently of the profile, and therefore this needs to be a MUST, or the profile is going to describe the encoding, which could be base64url or could be something else, and the implementation will do whatever the profile says. If you really want to say something here, I suggest replacing the last two sentences with: If the assertion is going to be transported within HTTP forms, the profile document needs to describe what (if any) encoding will be needed to do so. The base64url encoding is widely implemented and therefore suggested. In reading it again, I agree with you that it's weird and not appropriate here. In fact the JWT profile itself does not require any further encoding. Barring any objection, I suggest that the last two sentences just be removed. So it would just be, assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents. 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 that's supposed to be obeying that MUST, and for what reason) They are both supposed to obey it - the client shouldn't ask for more and the server will reject the request, if it does. Is will more appropriate than MUST here? Or maybe a non 2119 should? If the scope parameter and/or value are omitted, the scope MUST be treated as equal to the scope originally granted to the authorized accessor. The Authorization Server MUST limit the scope of the issued access token to be equal or lesser than the scope originally granted to the authorized accessor. In the first sentence, is this
Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)
Fair point. I'll add some text saying that in the next revision. On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba barryle...@computer.org 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Repeating the note about acceptable algorithms in the JWT spec sounds fine. On Sat, Oct 11, 2014 at 1:54 PM, Mike Jones michael.jo...@microsoft.com wrote: From: Richard Barnes [mailto:r...@ipv.sx] Sent: Friday, October 10, 2014 2:37 PM To: Mike Jones Cc: The IESG; oauth-cha...@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones michael.jo...@microsoft.com wrote: Thanks for your review, Richard. My responses are inline below... -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, October 01, 2014 7:57 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web- token-27: (with DISCUSS and COMMENT) Richard Barnes has entered the following ballot position for draft-ietf-oauth-json-web-token-27: 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-json-web-token/ -- DISCUSS: -- Section 7. In order to prevent confusion between secured and Unsecured JWTs, the validation steps here need to call for the application to specify which is required. Per my response on your JWS comments, this is already handed in a more general way in the JWS validation steps. Specifically, the last paragraph of Section 5.2 is: Finally, note that it is an application decision which algorithms are acceptable in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD reject the JWS. I've cleared this DISCUSS in the interest of having this fight over in JWS thread. But I also added the following COMMENT: It would be good for this document to pass on the note from JWS about selecting which algorithms are acceptable, and in particular, whether unsecured JWTs are acceptable. Thanks for clearing the DISCUSS. I'm fine repeating the note about acceptable algorithms in the JWT spec, assuming others are. I would therefore request that you likewise withdraw this DISCUSS on that basis. -- Mike ___ 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] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG)
Okay, I see 'Changed expires_at to client_secret_expires_at and issued_at to client_id_issued_at for greater clarity.' in the document history for -11 (full 'management' was in the draft back then). But to me, it doesn't improve clarity. And it seems limiting. But I seem to be in the minority of people that think that or care. And I'm not sure I even care. So I'll drop it. On Fri, Sep 12, 2014 at 8:08 AM, Richer, Justin P. jric...@mitre.org wrote: It used to be simply expires_at but after discussion on the list it was changed to client_secret_expires_at, since the client's secret is the most likely part to expire and need to be refreshed. Of course this refresh makes the most sense if you're implementing the management spec where you can actually do something other than re-register, but it's still handy for the client to know that its server-issued credentials won't be good anymore at a certain point. Since the JWKS is provided by the client and not by the server, the server doesn't really need to tell the client when it expires. The parameter is not passed back if there is no client_secret, such as a public or implicit client. There's text in the security considerations about expiring those kinds of clients* but after discussion on the list it was decided that it's too specific to a server policy to try to signal. Plus, nobody seems to do that today. Client secrets *do* expire in some setups, but client IDs don't, in my personal experience. -- Justin * And I just noticed that this paragraph still mentions the delete action, so we need to clean that part up in the next revision. On Sep 11, 2014, at 6:19 PM, Brian Campbell bcampb...@pingidentity.com wrote: Why does expiration only apply to the client secret[1]? If there's a need for the AS to set an expiration, isn't it broader than that and apply to the whole client or the client id? If there's a need to signal an expiration time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) might also need to be expired? And what about strictly implicit clients or other public clients, is there no case that an AS would want to expire them? I realize I've asked this before (more than once) but I've never gotten an answer. To me, whats in this draft that's on its way to the IESG is awkward and/or incomplete. I believe that either the client_secret_expires_at should be removed from draft-ietf-oauth-dyn-reg or it should be changed to something that isn't specific to the client secret - something like client_expires_at or client_id_expires_at. [1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1 On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, I have just sent the Dynamic Client Registration document to the IESG. The final shepherd write-up for the document can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ Ciao Hannes ___ 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
[OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG)
Why does expiration only apply to the client secret[1]? If there's a need for the AS to set an expiration, isn't it broader than that and apply to the whole client or the client id? If there's a need to signal an expiration time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) might also need to be expired? And what about strictly implicit clients or other public clients, is there no case that an AS would want to expire them? I realize I've asked this before (more than once) but I've never gotten an answer. To me, whats in this draft that's on its way to the IESG is awkward and/or incomplete. I believe that either the client_secret_expires_at should be removed from draft-ietf-oauth-dyn-reg or it should be changed to something that isn't specific to the client secret - something like client_expires_at or client_id_expires_at. [1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1 On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, I have just sent the Dynamic Client Registration document to the IESG. The final shepherd write-up for the document can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ Ciao Hannes ___ 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] alternative term to plaintext for the none alg (was Re: Review of: draft-ietf-oauth-json-web-token)
cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. I agree that plaintext” is not the most intuitive wording choice and that unsecured might better convey what's going on with the none JWS algorithm. Mike mentioned that, if this change is made in JWT, there are parallel changes in JWS. But note that there are also such changes in JWA (more than in JWS actually). On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones michael.jo...@microsoft.com wrote: -Original Message- From: Warren Kumari [mailto:war...@kumari.net] Sent: Monday, September 01, 2014 3:40 PM To: sec...@ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org Subject: Review of: draft-ietf-oauth-json-web-token I'm a little confused by something in the Terminology section (Section 2): Plaintext JWT A JWT whose Claims are not integrity protected or encrypted. The term plaintext to me means something like is readable without decrypting / much decoding (something like, if you cat the file to a terminal, you will see the information). Integrity protecting a string doesn't make it not easily readable. If this document / JOSE uses plaintext differently (and a quick skim didn't find anything about this) it might be good to clarify. Section 6 *does* discuss plaintext JWTs, but doesn't really clarify the (IMO) unusual meaning of the term plaintext here. I’ve discussed this with the other document editors and we agree with you that “plaintext” is not the most intuitive wording choice in this context. Possible alternative terms are “Unsecured JWT” or “Unsigned JWT”. I think that “Unsecured JWT” is probably the preferred term, since JWTs that are JWEs are also unsigned, but they are secured. Working group – are you OK with this possible terminology change? (Note that the parallel change “Plaintext JWS” - “Unsecured JWS” would also be made in the JWS spec.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
On #1, I know some have pushed for having the transformation options so I don't know if dropping it will work. But, if not removed entirely, the transformation stuff could definitely be deemphasized in favor of what will be the most common case of the client sending a random string value on the authorization request and then sending the same value on the token request. On #2, there are already implementations and deployments of this so I'd request that the parameter names not be changed. On #3, I agree that the title is confusing/misleading. Perhaps, Request Correlation for the OAuth Authorization Code Grant or something like that? On #4, on one hand you are right. On the other hand, this is the OAuth WG and this draft is addressing a very specific security issue in OAuth deployments. Having it be OAuth-centric seems right given the circumstances. On Thu, Aug 28, 2014 at 11:03 PM, Manger, James james.h.man...@team.telstra.com wrote: Couple of comments on draft-ietf-oauth-spop-00: The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server. 1. The spec defines the bearer token version of linking the requests: pick a random value and send it in both requests. The spec repeatedly hints that other transformations are possible (and even mentions one in a note), but it doesn't define enough to make these other ones interoperable. I suggest just specifying the bearer version and dropping all the other text. If we want another transform standardized later then we write another spec (which can use its own field names). 2. Linking requests is orthogonal to whether or not the requests include a field called code. I suggest changing the labels code_challenge and code_verifier to drop the code reference. Perhaps replace both with session_id (sid for short?). 3. The spec is titled Symmetric Proof of Possession ... but defines a bearer mechanism, which you cannot really classify as proof-of-possession. Suggestion: change the title. 4. The text is totally OAuth-centric, though the mechanism is not really limited to this case. It would be much nicer to describe the mechanism more generically (eg app running on a user's computer wanting to link two requests made to a server over different channels). The abstract (and the start of the introduction) should be comprehensible without having to know what the phrase OAuth 2.0 public client means. There would still be some OAuth-specific sections describing how the mechanism applies to the code flow (and to register a field in the IANA OAuth registry). -- James Manger ___ 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] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense. And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of Request by JWS ver.1.0 for OAuth 2.0 as an OAuth Working Group Item
Yes (sorry I'm a little late with this one) On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the Request by JWS ver.1.0 for OAuth 2.0 (draft-sakimura-oauth-requrl-05.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. 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] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
I am very much in favor of the WG pursuing the general concept of an OAuth Token Exchange. However, I don't believe this document, in its current form anyway, is the necessarily the most appropriate starting point as a WG work item. I wrote up an I-D, which I'd ask to be considered as alternative or additional input into the process: https://datatracker.ietf.org/doc/draft-campbell-oauth-sts/ I don't intend this to be confrontational or this is better than that kind of thing. Producing a draft just seemed like the most straightforward way to document some initial thoughts on it. I'm more than open to collaborating on it going forward. On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the OAuth 2.0 Token Exchange (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- [image: Ping Identity logo] https://www.pingidentity.com/ Brian Campbell Distinquished Engineer @ bcampb...@pingidentity.com [image: phone] +1 720.317.2061 Connect with us… [image: twitter logo] https://twitter.com/pingidentity [image: youtube logo] https://www.youtube.com/user/PingIdentityTV [image: LinkedIn logo] https://www.linkedin.com/company/21870 [image: Facebook logo] https://www.facebook.com/pingidentitypage [image: Google+ logo] https://plus.google.com/u/0/114266977739397708540 [image: slideshare logo] http://www.slideshare.net/PingIdentity [image: flipboard logo] http://flip.it/vjBF7 [image: rss feed icon] https://www.pingidentity.com/blogs/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
Absolutely agree that some examples are needed. There's a [[ TODO ]] in there for it. I just hadn't gotten to it yet and wanted to get the I-D up before the Aug 10 date that Hannes put out there. The example you outlined is a good start, I think. Yes, code and refresh tokens would/could be valid tokens. A previously issued access token might also be. JWT SAML too. The last paragraph of http://tools.ietf.org/html/draft-campbell-oauth-sts-00#section-1 attempts to state that the scope of the doc is only the framework for exchange and that the syntax, semantics and security characteristics of the tokens themselves (both those presented to the are explicitly out of scope. What constitutes a valid token will depend on the deployment or additional profiling. So how might sending an act_as token to the token endpoint as part of the request impact the result. - in general I was thinking it'd result in an azp claim or something like that in the returned token. Do you see the act_as interacting with PoP to limit who can present the resulting token. - Quite possibly. Though, honestly, I don't yet have a complete concept of how PoP works in conjunction with all this. Is act_as simply duplicating the authentication portion of the current assertion profile? - there is potential for duplication in some cases, yes. But the motivation for act_as was to give additional flexibility by allowing an additional party to be represented. Also to try and align with draft-jones-oauth-token-exchange http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ to the extent possible. I had toyed with the idea of only having one inbound token for the subject and having the client (relying on client authentication) be the actor. Then maybe a flag to indicate if delegation vs impersonation is deserted in the returned token. But it seemed like there was a need (things you'd said among others) for more than two parties to be represented. There's some refinement to be done for sure though. Not having concrete answers at this point is not a problem, but we do need to think all of this through. - agree I think this document is also useful input. - thanks ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Standardized error responses from protected resource endpoints
Take a look at RFC 6750 The OAuth 2.0 Authorization Framework: Bearer
Token Usage - particularly section 3:
http://tools.ietf.org/html/rfc6750#section-3 which describes using the
WWW-Authenticate response header field in response to a request with
an invalid/insufficient/missing/etc token.
On Tue, Jul 29, 2014 at 8:10 PM, Takahiko Kawasaki daru...@gmail.com wrote:
Hello,
I have a question. Is there any standardized specification about
error responses from protected resource endpoints?
RFC 6749, 7.2. Error Response says the specifics of such error
responses are beyond the scope of this specification, but I'm
wondering if OAuth WG has done something for that.
From error responses, I'd like to know information about:
(1) Usability (active or expired? (or not exist?))
(2) Refreshability (associated usable refresh token exists?)
(3) Sufficiency (usable but lacking necessary permissions?)
For example, I'm expecting an error response like below with
400 Bad Request or 403 Forbidden.
{
error:...,
error_description:...,
error_uri:...,
usable: true,
refreshable: true,
sufficient: false
}
Best Regards,
Takahiko Kawasaki
___
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] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
Will the minutes of the meeting be made available? Those might provide a little more context to those of us who were unable to attend. On Wed, Jul 30, 2014 at 10:14 AM, John Bradley ve7...@ve7jtb.com wrote: Interesting point. I defer to your greater hum experience:) On Jul 30, 2014, at 10:32 AM, Anthony Nadalin tony...@microsoft.com wrote: John this is for the people that did not hum at the face to face and not just for the people not at the face to face. Sent from my Windows Phone From: John Bradley Sent: 7/30/2014 7:20 AM To: Sergey Beryozkin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item No worries. Some of the people in the F2F piling on with discussion derailed Hannes original question. during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the OAuth Token Introspection (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. People not in the room commenting and asking questions is expected. People who expressed opinions in the room should avoid double counting by making it clear they hummed in the room, as our AD may not know everyone's face and name. I don't know how I became the process monitor. Normally I am the trouble maker. I believe what passed for consensus in the room was that this ork is in scope for the WG and this document can serve as a starting point, but that there are things that need to be added. I think Phil would like a use case document to flesh out peoples understanding. Others who have been working on this longer are hesitant that doing a use case document without adopting Justin's document as a starting point, will stall the process. We can however adopt Justin's doc and in parallel add a use case section as part of the doc or as a separate doc. So if you were not in the F2F hum you need to express an opinion on if draft-richer-oauth-introspection-06.txt should be adopted by the WG item. John B. (PS I was in the room and hummed in favour of adopting this as a work item) On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi John On 30/07/14 14:59, John Bradley wrote: No, that those of us who we're fallowing the instructions not to comment if our hum was recorded in the room, should not hold back given the nature of the thread has changed. It was also an indication to the char that the original intent of the thread to judge consensus is impacted by some people who previously hummed piling on the thread. I think I understand, thanks for the clarifications, though it appears to be more subtle to me that various OAuth2 technical ambiguities :-) I am more than fine with discussion. It probably should have been a different thread though. Thanks, sorry for the noise anyway Sergey John B. Sent from my iPhone On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 30/07/14 14:42, John Bradley wrote: This request for only those not at the F2F to add to the hum has gone a bit off the rails. Meaning you see too much feedback, is it bad, even if some of it may be off topic ? For those not in the room there was discussion that the draft needed a method to deal with: - Multiple AS - Supporting the PoP specs - stopping clients or other interceptors of the token from introspecting it. Justin stated that his implementation already had a number of those features. I offered to help get those into the spec as part of my support for making this a WG item. Yes if AS and RS are monolithic and there is only one software vendor, then this is not needed. Why not ? What is wrong with standardizing an introspection process which even RS AS from the same vendor may want to use as opposed to every vendor inventing its own protocol ? This is why I thought focusing on the RS to 3rd party only diverts from the idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing on the RS-to-AS communication, which may not have been considered, Cheers, Sergey On the other hand there is evidence that is not the
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the rough consensus of the industry at large is that a4c is not wanted or needed. On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura sakim...@gmail.com wrote: And here is a quote from Ian's blog. And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down. (Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html 2014-07-23 16:53 GMT-04:00 John Bradley ve7...@ve7jtb.com: I thought I did post this to the list. I guess I hit the wrong reply on my phone. John B. Sent from my iPhone On Jul 23, 2014, at 4:50 PM, tors...@lodderstedt.net wrote: we are two, at least :-) Why didn't you post this on the list? When will be be arriving? Am 23.07.2014 16:39, schrieb John Bradley: Ian Glazer mentioned this in his keynote at CIS yesterday. His advice was please stop, we are creating confusion and uncertainty. We are becoming our own wort enemy. ( my view though Ian may share it) Returning just an id_ token from the token endpoint has little real value. Something really useful to do would be sorting out channel_id so we can do PoP for id tokens to make them and other cookies secure in the front channel. I think that is a better use of time. I may be in the minority opinion on that, it won't be the first time. John B. Sent from my iPhone On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: You are right from a theoretical perspective. Practically this was caused by editorial decisions during the creation of the RFC. As far as I remember, there was a definition of the (one) token endpoint response in early versions. No one every considered to NOT respond with an access token from the token endpoint. So one might call it an implicit assumption. I'm worried that people get totally confused if an exception is introduced now given the broad adoption of OAuth based on this assumption. regards, Torsten. Am 23.07.2014 um 15:41 schrieb Thomas Broyer t.bro...@gmail.com: Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each grant type references Section 5.1, and access token request is only defined in the context of the defined grant types. Section 2.2 doesn't talk about the request or response format. Le 23 juil. 2014 21:32, Nat Sakimura sakim...@gmail.com a écrit : Is it? Apart from the implicit grant that does not use token endpoint, all other grant references section 5.1 for the response, i.e., all shares the same response. 2014-07-23 15:18 GMT-04:00 Thomas Broyer t.bro...@gmail.com: I hadn't realized the JSON response that requires the access_token field is defined per grant_type, so I'd be OK to extend the semantics as in the current draft. That was actually my main concern: that the token endpoint mandates access_token; but its actually not the case. Le 23 juil. 2014 20:46, Nat Sakimura sakim...@gmail.com a écrit : I agree with John that overloading response_type @ authz endpoint is a bad idea. It completely changes the semantics of this parameter. NOTE: what I was proposing was not this parameter, but a new parameter response_type @ token endpoint. I also think overloading grant_type is a bad idea since it changes its semantics. I quote the definition here again: grant credential representing the resource owner's authorization grant_type type of grant sent to the token endpoint to obtain the access token It is not about controlling what is to be returned from the token endpoint, but the hint to the token endpoint describing the type of credential the endpoint has received. It seems the control of what is being returned from token endpoint is just a side effect. I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in as much as text is the king for a spec., we probably should not change the semantics of it as Torsten points out. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the response would be the best way to go. This is what I have described previously. Defining a new endpoint to send code to get ID Token and forbidding the use of it against token endpoint would not change the semantics of any existing parameter or endpoint, which is good. However, I doubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after all? Defining a new endpoint for just avoiding the access token for userinfo endpoint seems way too much the heavy wait way and it breaks
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
There is a lot of spin being applied, yes. But not from Ian. On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin tony...@microsoft.com wrote: I’m sure it was spun in a way that could be true since there was no technical value to Ian’s statement and I’m sure that folks had not read or understand the usage. *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Thursday, July 24, 2014 6:53 AM *To:* Nat Sakimura *Cc:* oauth@ietf.org list *Subject:* Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the rough consensus of the industry at large is that a4c is not wanted or needed. On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura sakim...@gmail.com wrote: And here is a quote from Ian's blog. And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down. (Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html 2014-07-23 16:53 GMT-04:00 John Bradley ve7...@ve7jtb.com: I thought I did post this to the list. I guess I hit the wrong reply on my phone. John B. Sent from my iPhone On Jul 23, 2014, at 4:50 PM, tors...@lodderstedt.net wrote: we are two, at least :-) Why didn't you post this on the list? When will be be arriving? Am 23.07.2014 16:39, schrieb John Bradley: Ian Glazer mentioned this in his keynote at CIS yesterday. His advice was please stop, we are creating confusion and uncertainty. We are becoming our own wort enemy. ( my view though Ian may share it) Returning just an id_ token from the token endpoint has little real value. Something really useful to do would be sorting out channel_id so we can do PoP for id tokens to make them and other cookies secure in the front channel. I think that is a better use of time. I may be in the minority opinion on that, it won't be the first time. John B. Sent from my iPhone On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: You are right from a theoretical perspective. Practically this was caused by editorial decisions during the creation of the RFC. As far as I remember, there was a definition of the (one) token endpoint response in early versions. No one every considered to NOT respond with an access token from the token endpoint. So one might call it an implicit assumption. I'm worried that people get totally confused if an exception is introduced now given the broad adoption of OAuth based on this assumption. regards, Torsten. Am 23.07.2014 um 15:41 schrieb Thomas Broyer t.bro...@gmail.com: Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each grant type references Section 5.1, and access token request is only defined in the context of the defined grant types. Section 2.2 doesn't talk about the request or response format. Le 23 juil. 2014 21:32, Nat Sakimura sakim...@gmail.com a écrit : Is it? Apart from the implicit grant that does not use token endpoint, all other grant references section 5.1 for the response, i.e., all shares the same response. 2014-07-23 15:18 GMT-04:00 Thomas Broyer t.bro...@gmail.com: I hadn't realized the JSON response that requires the access_token field is defined per grant_type, so I'd be OK to extend the semantics as in the current draft. That was actually my main concern: that the token endpoint mandates access_token; but its actually not the case. Le 23 juil. 2014 20:46, Nat Sakimura sakim...@gmail.com a écrit : I agree with John that overloading response_type @ authz endpoint is a bad idea. It completely changes the semantics of this parameter. NOTE: what I was proposing was not this parameter, but a new parameter response_type @ token endpoint. I also think overloading grant_type is a bad idea since it changes its semantics. I quote the definition here again: grant credential representing the resource owner's authorization grant_type type of grant sent to the token endpoint to obtain the access token It is not about controlling what is to be returned from the token endpoint, but the hint to the token endpoint describing the type of credential the endpoint has received. It seems the control of what is being returned from token endpoint is just a side effect. I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in as much as text is the king for a spec., we probably should not change the semantics of it as Torsten points out. If it is ok to change
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
I'm sorry to miss what will likely be a very engaging meeting today. The premise that some developers are using OAuth in a insecure way to do authentication is something we can probably all agree on. It doesn't necessarily follow from that premise, however, that the solution is yet another spec which either duplicates some subset of OpenID Connect (in a different SDO) or forks how to do SSO/authentication using OAuth. On Thu, Jul 24, 2014 at 7:25 AM, John Bradley ve7...@ve7jtb.com wrote: I am not against discussion in the WG. I happen to agree with Phil's fundamental premise that some developers are using OAuth in a insecure way to do authentication. That raises the question of how to best educate them, and or address technical barriers. It is on the second point that people's opinions seem to divide. Some people thing that if we have a OAuth flow that eliminates the access token (primarily to avoid asking for consent as I understand it) and just return a id_token from the token endpoint that can be done in a spec short enough to het people to read. The subtext of this is that the Connect specification is too large that it scare people, and they don't find the spec in the first place because it is not a RFC. An other common possession is that if you don't want to prompt the user for consent then don't ask for scopes. Twisting the OAuth spec to not return an access token is not OAuth, yes you could use a different endpoint rather than the token endpoint, but that is not OAuth. Connect was careful not to break the OAuth spec.As long as you are willing to take a access token with no scopes (the client needs to understand that there are no attributes one way or another anyway or it will break) then you don't need to change OAuth. You can publish a profile of connect that satisfies the use case. I think Mike has largely done that but it might be better being less stingy on references back to the larger spec. The questions are do we modify OAuth to not return an access token, and if so how, and if we do is it still OAuth. The other largely separable question is do we create confusion in the market and slow the the adoption of identity federation on top of OAuth, or find a way to make this look like a positive alignment of interests around a subset of Connect. There are a number of options. 1: We can do a profile in the OIDF and publish it as a IETF document. Perhaps the cleanest from an IPR point of view. 2:We can do a profile in the OAuth WG referencing connect. 3:We can do a AD sponsored profile that is not in the OAuth WG. 4:We can do a small spec in OAuth to add response_type to the token endpoint. in combination with 1, 2, or 3 I agree that stoping developers doing insecure things needs to be addressed somehow. I am not personally convinced that Oauth without access tokens is sensible. Looking forward to the meeting:) John B. On Jul 24, 2014, at 6:52 AM, Brian Campbell bcampb...@pingidentity.com wrote: I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the rough consensus of the industry at large is that a4c is not wanted or needed. On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura sakim...@gmail.com wrote: And here is a quote from Ian's blog. And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down. (Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html 2014-07-23 16:53 GMT-04:00 John Bradley ve7...@ve7jtb.com: I thought I did post this to the list. I guess I hit the wrong reply on my phone. John B. Sent from my iPhone On Jul 23, 2014, at 4:50 PM, tors...@lodderstedt.net wrote: we are two, at least :-) Why didn't you post this on the list? When will be be arriving? Am 23.07.2014 16:39, schrieb John Bradley: Ian Glazer mentioned this in his keynote at CIS yesterday. His advice was please stop, we are creating confusion and uncertainty. We are becoming our own wort enemy. ( my view though Ian may share it) Returning just an id_ token from the token endpoint has little real value. Something really useful to do would be sorting out channel_id so we can do PoP for id tokens to make them and other cookies secure in the front channel. I think that is a better use of time. I may be in the minority opinion on that, it won't be the first time. John B. Sent from my iPhone On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: You are right from a theoretical perspective. Practically this was caused by editorial decisions during
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
The situations are rather different. On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin tony...@microsoft.com wrote: OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) but that is OK to do *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Thursday, July 24, 2014 10:22 AM *To:* John Bradley *Cc:* oauth@ietf.org list *Subject:* Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt I'm sorry to miss what will likely be a very engaging meeting today. The premise that some developers are using OAuth in a insecure way to do authentication is something we can probably all agree on. It doesn't necessarily follow from that premise, however, that the solution is yet another spec which either duplicates some subset of OpenID Connect (in a different SDO) or forks how to do SSO/authentication using OAuth. On Thu, Jul 24, 2014 at 7:25 AM, John Bradley ve7...@ve7jtb.com wrote: I am not against discussion in the WG. I happen to agree with Phil's fundamental premise that some developers are using OAuth in a insecure way to do authentication. That raises the question of how to best educate them, and or address technical barriers. It is on the second point that people's opinions seem to divide. Some people thing that if we have a OAuth flow that eliminates the access token (primarily to avoid asking for consent as I understand it) and just return a id_token from the token endpoint that can be done in a spec short enough to het people to read. The subtext of this is that the Connect specification is too large that it scare people, and they don't find the spec in the first place because it is not a RFC. An other common possession is that if you don't want to prompt the user for consent then don't ask for scopes. Twisting the OAuth spec to not return an access token is not OAuth, yes you could use a different endpoint rather than the token endpoint, but that is not OAuth. Connect was careful not to break the OAuth spec.As long as you are willing to take a access token with no scopes (the client needs to understand that there are no attributes one way or another anyway or it will break) then you don't need to change OAuth. You can publish a profile of connect that satisfies the use case. I think Mike has largely done that but it might be better being less stingy on references back to the larger spec. The questions are do we modify OAuth to not return an access token, and if so how, and if we do is it still OAuth. The other largely separable question is do we create confusion in the market and slow the the adoption of identity federation on top of OAuth, or find a way to make this look like a positive alignment of interests around a subset of Connect. There are a number of options. 1: We can do a profile in the OIDF and publish it as a IETF document. Perhaps the cleanest from an IPR point of view. 2:We can do a profile in the OAuth WG referencing connect. 3:We can do a AD sponsored profile that is not in the OAuth WG. 4:We can do a small spec in OAuth to add response_type to the token endpoint. in combination with 1, 2, or 3 I agree that stoping developers doing insecure things needs to be addressed somehow. I am not personally convinced that Oauth without access tokens is sensible. Looking forward to the meeting:) John B. On Jul 24, 2014, at 6:52 AM, Brian Campbell bcampb...@pingidentity.com wrote: I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the rough consensus of the industry at large is that a4c is not wanted or needed. On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura sakim...@gmail.com wrote: And here is a quote from Ian's blog. And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down. (Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html 2014-07-23 16:53 GMT-04:00 John Bradley ve7...@ve7jtb.com: I thought I did post this to the list. I guess I hit the wrong reply on my phone. John B. Sent from my iPhone On Jul 23, 2014, at 4:50 PM, tors...@lodderstedt.net wrote: we are two, at least :-) Why didn't you post this on the list? When will be be arriving? Am 23.07.2014 16:39, schrieb John Bradley: Ian Glazer mentioned this in his keynote at CIS yesterday. His advice was please stop, we are creating confusion and uncertainty. We are becoming our own wort enemy. ( my view though Ian may share it) Returning just an id_
