[OAUTH-WG] Last Call: draft-ietf-oauth-v2-threatmodel-06.txt (OAuth 2.0 Threat Model and Security Considerations) to Informational RFC
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Threat Model and Security Considerations' draft-ietf-oauth-v2-threatmodel-06.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ballot/ No IPR declarations have been submitted directly on this I-D. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT)
Pete, can you now please clear this DISCUSS? The W3C review period concluded yesterday and no issues have been brought to my attention. Thank you, -- Mike -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, June 18, 2012 12:47 PM To: Mike Jones Cc: Pete Resnick; Mark Nottingham; oauth@ietf.org Subject: Re: FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT) Hi Mike, As you noted this is under way. When I mailed tlr I asked for two weeks from the 13th, which co-incides with the end of the IETF LC caused by the IPR declaration, so it should be fine. Cheers, S. On 06/18/2012 07:08 PM, Mike Jones wrote: Hi Stephen, Pete is holding his DISCUSS on Bearer open until the current text on the URI query parameter http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3 receives W3C review. Can you try to have that review happen this week, hopefully finishing sometime next week? I'm cc:'ing Mark in his role as W3C liaison. Thanks again, -- Mike -Original Message- From: Pete Resnick [mailto:presn...@qualcomm.com] Sent: Tuesday, June 12, 2012 1:40 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-v2-bea...@tools.ietf.org Subject: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT) Pete Resnick has entered the following ballot position for draft-ietf-oauth-v2-bearer-20: 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. -- DISCUSS: -- Mark Nottingham's Applications Area review http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.ht ml identified the issue of URI query parameters in section 2.3: URI query parameters are normally locally scoped. In this document, a query parameter (access_token) is being defined as applying to all URIs. This is (relatively) novel. A few people in the HTTP community (including Mark) have expressed concerns. (See also http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04932.htm l and http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04933.htm l from the apps-discuss archive.) This issue should probably be further reviewed by W3C folks. I'm holding the DISCUSS as per Stephen to make sure we get that review. -- COMMENT: -- In section 2.3, the new last paragraph starts: This method is included to document current use; its use is NOT RECOMMENDED... NOT RECOMMENDED is not defined by 2119, and the language is redundant with the previous paragraph and potentially confusing. I suggest replacing it with simply: This method is included to document current use; as indicated in the previous paragraph, the use of this method is not recommended... BTW: The SHOULD NOT unless... in the previous paragraph is itself redundant. I think you mean MUST NOT unless SHOULD NOT *means* MUST NOT unless you understand what you're doing. Mark Nottingham's Applications Area review http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.ht ml has a couple of comments that I think deserve further reply: * Section 1: Introduction The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the OAuth specification than this document. As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows. If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title. I agree that the title would be better simply as HTTP Bearer Tokens, and then explain in the Abstract and Intro that the motivation and intended use of these Bearer Tokens is the OAuth 2.0 specification. A possibly useful side effect of this change might be that you can make OAuth 2.0 an informative (as against a normative) reference, and that these things could be reused for other purposes in the future. Not a huge deal, but I (like Mark) was unconvinced that the reference to OAuth in the title
Re: [OAUTH-WG] Report an authentication issue
Hi Nat, Starting from a standalone use case would be good. My impression (I may be wrong) is that your requirement is to be able to (1) Log the user identifier of the person who is accessing the resource at the resource server for the audit etc. purposes. acl yes ... that *and* to authenticate the user in the first place. So again, my access_token will actually look like the Connect id_token. I would even prefer to use the id_token, except that it violate the spirit of Connect to pass the id_token to the RS (e.g. it was only meant for consumption by the client). My problem space can be distilled to something very simple. - We come from a SOAP API world where we use WS-Trust to secure the SOAP API calls. WS-Trust makes it very simple for a WS-* client to collect the user's primary credentials, exchange it for a (SAML) bearer token via the STS, and embed that bearer token in SOAP-based API calls to the WS-* server. This is most definitely *authentication* - We are moving to a RESTful API world. I just want to be able to do the same thing as above. How do I enable my REST-based client to collect the user's password, exchange it for a (JWT) bearer token via the STS, and embed that bearer token in RESTful API calls to the REST-based server, such that the REST-based server can *authenticate* the client? (2) Do the holder of the key so that the RS is sure that the person accessing with the access token is really the person. acl that would be nice, but most of my users will be using passwords in the beginning, so this is not an option. I'm using the literal definition of bearer token here, taken straight out of the OAuth bearer token spec, e.g. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). (3) In addition, the RS may not be able to talk to AS directly. [Well, this is one of my use case anyways.] acl Right ... this is why I am now looking at structured JWTs. (4) In some cases, the client may not be able to communicate with AS directly at the time of RS access. [ditto] acl Right again, we have disaster scenarios to think about where the AS might not be reachable. but this is a use case for next steps. Trying to walk before we fly here :-) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Report an authentication issue
Hi John, It may be semantics, but in my use cases, the AS is not authorizing anything. It's 1) authenticating the user, and 2) issuing a structured JWT access_token which contains claims about the user (again, just like the id_token, but as you said, aud=RS). The video client on the iPhone/Android uses this as a bearer token, and includes it an a request to the video server. The video server uses the claims in the JWT access_token to authenticate the user, and then makes its own authorization decisions (e.g. maps user id to app-centric roles, etc.) If you still feel this is within the spirit of OAuth, then great :-) My concern is still that one of our customer's will read your blog and fire back at us ... but John says OAuth is not for authentication ;) This is why I would like to explore the idea of putting out an informational draft profiling OAuth for authentication, since everybody seems to at least agree that it can be profiled to do so. Tx! adam From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Thursday, June 28, 2012 3:48 PM To: Lewis Adam-CAL022 Cc: Nat Sakimura; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue Adam, This is getting tangled up in semantics. The AS authenticates the user and Authorizes the client (native App) to access the protected resource (video server) via issuing it a access token, or a authorization code that it can trade at a token endpoint for a refresh_token and access_token. At that point the client has no notion of who the user is unless a openID Connect id_token was also sent. I suspect that the video player app may not care who the person, only what it can access. The App then uses its access token to prove that it was delegated access to the server by some person (Resource owner in OAuth speak). In your STS example you call this Authentication, but in OAuth it is Authorization. The client is the one being authenticated to the resource via the token. The User is Authenticated to the AS. The same trust chain exists it just uses different terms. That token can be structured like the id_token is, but there is an important difference. The access token's audience is the resource server and the id_token's audience is the client. That is one of the reasons they are separate. This looks like a relatively strait forward OAuth use case to me, you can probably also use opaque tokens with a AS STS and some caching logic at the RS if you want to keep the token size down. John B. On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote: Hi Nat, Starting from a standalone use case would be good. My impression (I may be wrong) is that your requirement is to be able to (1) Log the user identifier of the person who is accessing the resource at the resource server for the audit etc. purposes. acl yes ... that *and* to authenticate the user in the first place. So again, my access_token will actually look like the Connect id_token. I would even prefer to use the id_token, except that it violate the spirit of Connect to pass the id_token to the RS (e.g. it was only meant for consumption by the client). My problem space can be distilled to something very simple. - We come from a SOAP API world where we use WS-Trust to secure the SOAP API calls. WS-Trust makes it very simple for a WS-* client to collect the user's primary credentials, exchange it for a (SAML) bearer token via the STS, and embed that bearer token in SOAP-based API calls to the WS-* server. This is most definitely *authentication* - We are moving to a RESTful API world. I just want to be able to do the same thing as above. How do I enable my REST-based client to collect the user's password, exchange it for a (JWT) bearer token via the STS, and embed that bearer token in RESTful API calls to the REST-based server, such that the REST-based server can *authenticate* the client? (2) Do the holder of the key so that the RS is sure that the person accessing with the access token is really the person. acl that would be nice, but most of my users will be using passwords in the beginning, so this is not an option. I'm using the literal definition of bearer token here, taken straight out of the OAuth bearer token spec, e.g. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). (3) In addition, the RS may not be able to talk to AS directly. [Well, this is one of my use case anyways.] acl Right ... this is why I am now looking at structured JWTs. (4) In some cases, the client may not be able to communicate with AS directly at the time of RS access. [ditto] acl Right again, we have disaster scenarios to think about where the AS might not be reachable. but this is a use case for next steps. Trying to walk before we fly here :-) ___ OAuth mailing list
Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
Hi Hannes, Near the end of §1 of your draft -04 you discuss client authentication with the Resource Server by saying that the client authentication concerns steps (E) and (F) in figure 1. However, my reading of §2.3 of the core OAuth Framework[1] was that only client authentication to the AS was in scope for the spec. Following from that, my assumption and intent with the assertion spec was that client assertion authentication is only defined for a client authenticating to the token endpoint of an AS. §3 of the -03 of the assertions doc[2] even says, This specification provides a model for using assertions for authentication of an OAuth client during interactions with an Authorization Server. Was there something in the -03 draft (or the core spec for that matter) that suggested it was intended for client to RS authentication? I don't think specifying that (other than in defining how an access token is presented like draft-ietf-oauth-v2-bearer does) that would be appropriate. Maybe some clarification is needed? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-2.3 [2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-3 On Sun, Jun 24, 2012 at 7:42 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Brian, thanks for your response. I have tried to put additional text into version -04 of the draft to address my earlier comments. The most recent version of the updated document is there: https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.txt Here is the XML: https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.xml It took me a little while to make these changes, as you can imagine. I hope I was able to improve the quality and clarity of the document. I still have to respond to your second mail about the relaxed usage of the RFC 2119 language. Will do that asap. Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Report an authentication issue
Hi Adam, I am working on an additional security concern around Authentication for the spec. The OAuth spec is about protecting the Protected Resource in your case a video server. That is exactly what OAuth is intended to do. The reason the term authorization is used is that the client can be a 3rd party web service, a native app, or a JavaScript client in a user Agent. In the case of the user granting a 3rd party service access to the video server via the same OAuth mechanism you probably would not say that the video server is authenticating the user as the user may well not be present. The protected resource is validating that the 3rd party service has been delegated access by the user (resource owner) via the authorization server. In the case where you have a client that by design is running on a device that is controlled by a single person and the person is authenticating themselves to the authorization server and granting the app access to the resource, you have crated a greatly constrained profile that is effectively the same as Authentication of the device holder to the resource. You are however doing that by using a authorization mechanism and leveraging the constraints of your profile. There are however places you can get into trouble if you don't have the correct profile and environment. The Authentication that openID Connect, Facebook and others are doing is Authentication of the user to the client. You see this in a native App like foursquare. In that case I use Facebook's Authorization server (same apples to twitter) to identify myself to the app and give it access to push notifications. I Authorize the App to access the Facebook graph API so it can get my name and other information, so In some sense I have Authenticated to it, and am logged in. That is all well and good. The problem comes in when the App passes the access token back to it's own servers and they assume that I am logged into the app and can let it post location information and get location history. This all works perfectly fine, on the face of it. The problem is that I also grant other clients access to my Facebook graph API and they have valid access tokens to get my information. Any one of those sites that have access_tokens for my account can pass that to foursquare over the API they have for their client and get my information at foursquare. (I believe forsquare is now using a proprietary Facebook API to validate that the token was issued to it's client_id to stop this attack now.) All public clients are susceptible to this not just Apps. The OAuth model works for you because you are using it the correct way to protect the resource. Once you start using OAuth in ways not anticipated by the core spec, you need to consider the new attack surface. Authenticating to the client is NOT safe with all of the flows unless additional security mechanisms are in place like the openID Connect id_token, or facebooks introspection endpoint, or facebooks's signed_request. There are ways that OAuth can be used safely for Authentication to the client but it requires profiling and extension. My concern is that inexperienced people not use OAuth to create simple SSO flows with public clients, that are insecure for that purpose. So Adam the bottom line is you are good to go because you are using OAuth as it is intended to be used. You can call it Authentication if you like, but that authentication is based on a constrained profile of OAuth and tokens. It is a subset of the general Authorization mechanism. While using JWT tokens brought to you by OpenID Connect may work as access tokens, I don't see needing id_tokens or user_info endpoints. There may be other applications that you develop in the future that might need them. I hope that helps. John B. On 2012-06-28, at 6:34 PM, Lewis Adam-CAL022 wrote: Hi John, It may be semantics, but in my use cases, the AS is not “authorizing” anything. It’s 1) authenticating the user, and 2) issuing a structured JWT access_token which contains claims about the user (again, just like the id_token, but as you said, aud=RS). The video client on the iPhone/Android uses this as a bearer token, and includes it an a request to the video server. The video server uses the claims in the JWT access_token to authenticate the user, and then makes its own authorization decisions (e.g. maps user id to app-centric roles, etc.) If you still feel this is within the spirit of OAuth, then great :-) My concern is still that one of our customer’s will read your blog and fire back at us … “but John says OAuth is not for authentication” ;) This is why I would like to explore the idea of putting out an informational draft profiling OAuth for authentication, since everybody seems to at least agree that it can be profiled to do so. Tx! adam From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Thursday, June 28,
[OAUTH-WG] [oauth][RFC 5849] A question in example about the api
Hi I have a question in the example for section 1.2 in the OAuth 1.0 RFC 5849. The example in the API calling to access the protected resource. Where it reads: With a set of token credentials, the client is now ready to request the private photo: GET /photos?file=vacation.jpgsize=original HTTP/1.1 Host: photos.example.net Authorization: OAuth realm=Photos, oauth_consumer_key=dpf43f3p2l4k3l03, oauth_token=nnch734d00sl2jdk, oauth_signature_method=HMAC-SHA1, oauth_timestamp=137131202, oauth_nonce=chapoH, oauth_signature=MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D I don't know how does the client know the parameter value vacation.jpg in the API http://photos.example.net/photos;. The question is, how does the client can get the name(s) of protected resource? The use Jane gave it or the server gave? Best regards, J. Lu ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
