Re: [OAUTH-WG] Text for Native Applications
This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0. If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. skylar On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: > >> Well, "rely" is a strong-term. I know of various teams who do this. I >> don't know of any teams that put a heavy reliance on it. > > It might validly be just one element of a defense-in-depth strategy. > > Regards, > > Dave > > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
+1 Skylar Woodward schrieb: This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0. If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. skylar On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: > >> Well, "rely" is a strong-term. I know of various teams who do this. I >> don't know of any teams that put a heavy reliance on it. > > It might validly be just one element of a defense-in-depth strategy. > > Regards, > > Dave > > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 _ 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] [apps-discuss] HTTP MAC Authentication Scheme
Hi Dave, On 02/06/11 22:16, Dave CROCKER wrote: > Stephen, > > On 6/1/2011 5:16 AM, Stephen Farrell wrote: >> Just on DOSETA - that's not currently got any official >> home in the IETF so its not something that would be right >> to reference at this point (unless the oauth WG wanted to >> adopt DOSETA but I'd be very surprised if that were the >> case for timing reasons). > > I'm confused on two counts. (To be honest, of course, I'm confused > about many points, but two of them are relevant to this thread...) > > One, of course, is that I've been actively raising DOSETA in various > IETF venues for the different groups to considering adopting and/or > adapting it. As such, discussion of DOSETA permits exploring the > possibility of adoption and/or adaptation. I don't get the confusion aspect there, but the rest below might clarify. > The second is that you appear to be stating a policy that a working > group is only permitted to reference things which are currently and > officially IETF work items. I suspect that that is not what you meant, > so at the least, please clarify what you do mean. Right. I wasn't stating any general policy. What I meant was that the oauth WG needs to get oauth2.0 done and that seems to require also getting the mac scheme done, so adding a dependency to something at an early stage of development (like DOSETA) at this point would not be a good plan for oauth. That's all. Exploring whether DOSETA or something similar is useful is a fine thing to do, its just a bit early for oauth. > If you really do mean anything like the interpretation I just > summarized, please explain its basis. > >> To be clear, as an individual, I do think that "something >> like DOSETA" is a really good idea and maybe DOSETA will >> turn out to be that something, I don't know. > > If it is not acceptable to 'reference' DOSETA now and here, then how > will the determination of its utility be made? Following our usual highly-predictable process I guess;-) I assume that the next step would be for a bunch of interested folks to figure out where and when it might make sense to do more on DOSETA. S. > > > Thanks. > > d/ > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth Interim Meeting: Polished Meeting Notes
Meeting Minutes, OAuth Interim Meeting, 23rd May 2011
=
Scribe: Bill Mills (post-processing by Hannes Tschofenig)
Participants:
** in person **
- Hannes Tschofenig
- Jonas Hogberg
- Bill Mills
- Marius Scurtescu
- Andrew Wansley
- Breno de Medeiros
- Thomas Roessler
- Mike Jones
- Kihara Boku
- Hayashi Tatsuya
- Yutaka Oiwa
- Harry Halpin
- David Recordon
- Tony Nadalin
- Matthew Sutkus
- David Robinson
- Skylar Woodward
- Chuck Mortimore
- Phil Hunt
- Dale Olds
- Paul Tarjan
** on the conference bridge **
- Lucy Lynch
- Brian Campbell
- Igor Faynberg
- Peter Saint-Andre
- Axel Nennker
- Karen O'Donoghue
- Doug Tangren
Agenda:
1. draft-ietf-oauth-v2-16
-
*** Client Authentication ***
Concern that Section 3 and 3.1 do not clearly show a way for a native client to
provide client_id (to identify the client only) without doign authentication.
Proposed new text, insert in bold:
"In addition, the authorization server MAY allow unauthenticated access
token requests when the client identity does not matter (e.g. anonymous
client), when client authenitcation is not practical, or when the client
identity is established via other means."
Last paragraph, section 3, proposed new text, reversing the order, putting
"since ..." at the end of the sentence:
The authorization server MUST require the use of a transport-layer security
mechanism when sending requests to exchange an the token endpoint since
requests using a method other than client password this authentication method
result in the transmission of clear-text credentials.
3.1 edit first paragraph
Delete: "(the client identifier together with a shared symmetric secret secret)"
*** Error Description ***
Agreement among the participants that the error codes are meant for consumption
by the developer rather than the end user. Hence, language codes are not
important nor a human readable version that is supposed to be understood by end
users.
Section 4.1.2.1. Error Response -- Character set for error_description
becomes
"OPTIONAL. Human-readable UTF-8 encoded text providing additional
information, used to assist to the developer in understanding the error that
occurred."
Section 4.1.2.1. Error URI -- "resource owner" becomes "developer"
*** Error URIs ***
Agreement among the participants that the error codes are meant for consumption
by the developer rather than the end user.
error_uri
OPTIONAL. A URI identifying a human-readable web page with
information about the error, used to provide the developer
with additional information about the error.
*** Error Response Codes ***
This is considered a possible area for confusion between the HTTP error code
and the error code returned in protocol.
The agreement among the participants was to remove all HTTP error codes and to
investigate whether there is a need to add new error codes.
TODO: Eran H-L to look at which HTTP error codes should be mapped in to
protocol specific error codes.
Section 4.1.2.1. Error -- remove HTTP 4xx and 5xx error code as an allowed
"error" value
Section 4.2.2.1. Error Response -- ibid
*** Security ***
Section 10.10 Session fixation...
Breno does not feel that session fixation is properly described nor dealt with.
Igor is providing reference links to session fixation description (mail to the
list).
TODO: br...@google.com is working on new draft language.
Section 10.13. XSRF/CSRF Prevention
TODO: Breno and Bill M. working on new draft text.
*** Native applications ***
Objections that this recommends against things that are extant implementations.
TODO: Chuck N. to draft revised text.
Discussion on the list:
http://www.ietf.org/mail-archive/web/oauth/current/msg06394.html
Followed by http://www.ietf.org/mail-archive/web/oauth/current/msg06444.html
*** Extensibility ***
TODO: Hannes will look at policy for using IETF URN
TODO: Mike J./Chuck N. to draft 4.5.1 subsection on assertions. Clarifying the
use case there and suggested behavior.
Discussion on the list:
http://www.ietf.org/mail-archive/web/oauth/current/msg06387.html
-Proposed additions
-"Immediate Mode" with display= and response=
-response_type={none, cookie}
TODO: Paul Tarjan to send proposed requirements to the list.
TODO: Eran to add extensibilty language for this based on requirements.
*** Redirect URI ***
Recommendation made that "RedirectURI" should be optional
TODO: Eran to send mail to the list proposing language changes to either change
this from REQUIRED to OPTIONAL and add clarifying language, or leave as
required and add a pre-defined value for "we're not actually using this".
Discussion on the list:
http://www.ietf.org/mail-archive/web/oauth/current/msg06419.html
*** Encoding ***
Section 4.3 (and 3.1) Username/Password: Need to figure out what the encoding
will be here, since these c
Re: [OAUTH-WG] OAuth Interim Meeting: Polished Meeting Notes
Thanks for posting this Hannes -Doug Tangren http://lessis.me On Fri, Jun 3, 2011 at 8:45 AM, Hannes Tschofenig wrote: > Bill Mills (post-processi ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
+1 From: Torsten Lodderstedt To: Skylar Woodward ; Dave Nelson Cc: "oauth@ietf.org" Sent: Friday, June 3, 2011 1:58 AM Subject: Re: [OAUTH-WG] Text for Native Applications +1 Skylar Woodward schrieb: This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0. > >If the client_secret were merely one element in protecting access maybe this >your suggestion would be true. However, given the difficulty of embedding and >obfuscating a secret in a hard-to-find way, and the requirement that every >developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. > >skylar > > >On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > >> On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: >> >>> Well, "rely" is a strong-term. I know of various teams who do this. I >>> don't know of any teams that put a heavy reliance on it. >> >> It might validly be just one element of a defense-in-depth strategy. >> >> Regards, >> >> Dave >> >> David B. Nelson >> Sr. Software Architect >> Elbrys Networks, Inc. >> www.elbrys.com >> +1.603.570.2636 > >> > >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] Client Credentials and Refresh Tokens
On Thu, Jun 2, 2011 at 11:05 PM, Shane B Weeden wrote: > Would anyone care to explain what the value of a refresh token is for peer > to peer applications utilizing the client_credentials grant type, or > validate if my explanation is the intended use case? Are you asking why would an authorization server issue a refresh token when the client credentials grant type is used? My guess is that in most cases authorization servers will not issue a refresh token in this case. Refresh tokens are optional, see sections 4.4.3 and 5.1. I think that the example in 4.4.3 should show only an access token. Also, section 4.4.3 should probably state that in this case the authorization server SHOULD not issue a refresh token. Section numbers are for draft 16. Marius > > Recall: > * it is required to provide client credentials to get an access token [and > refresh token] > * it is also required to provide client credentials to exchange a refresh > token for an access token (small assumption here based on recent > discussions ... but I think it had better be for the client_credentials > flow) > * unlike the authorization code flow, there is no authorization step with > the user involved that makes obtaining a new access token directly from the > client credentials any less onerous than using a refresh token > > About the only use case I can contrive that makes any sense is when > multiple instances of apps use the same client credentials (already a bad > idea) and you want to revoke access to a subset of them. To do the > revocation you would need to simultaneously: > 1. Revoke the refresh token and any access tokens issued to compromised > instances > 2. Update the client secret (or whatever authentication method clients > have) on those client instances that are still considered ok. > > In a deployment where each client has it's own credentials, which should be > "situation normal" from a security perspective, I don't see any value for > the refresh token. I also cringe at the idea of someone suggesting that > refresh token can be presented without client credentials - in this case > that's like saying client X has n passwords, where n is the number of > issued refresh tokens. Better to create n sets of client credentials in the > first place. > > Thanks, > Shane. > > ___ > 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 Credentials and Refresh Tokens
Agreed, it's nuts to return a refresh token for that flow. Eran, why is this still in the spec? You agreed to remove it almost a year ago. It's come up multiple times since then. http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html Cheers, Brian On Fri, Jun 3, 2011 at 9:45 AM, Marius Scurtescu wrote: > > On Thu, Jun 2, 2011 at 11:05 PM, Shane B Weeden wrote: > > Would anyone care to explain what the value of a refresh token is for peer > > to peer applications utilizing the client_credentials grant type, or > > validate if my explanation is the intended use case? > > Are you asking why would an authorization server issue a refresh token > when the client credentials grant type is used? > > My guess is that in most cases authorization servers will not issue a > refresh token in this case. Refresh tokens are optional, see sections > 4.4.3 and 5.1. > > I think that the example in 4.4.3 should show only an access token. > Also, section 4.4.3 should probably state that in this case the > authorization server SHOULD not issue a refresh token. > > Section numbers are for draft 16. > > Marius > > > > > Recall: > > * it is required to provide client credentials to get an access token [and > > refresh token] > > * it is also required to provide client credentials to exchange a refresh > > token for an access token (small assumption here based on recent > > discussions ... but I think it had better be for the client_credentials > > flow) > > * unlike the authorization code flow, there is no authorization step with > > the user involved that makes obtaining a new access token directly from the > > client credentials any less onerous than using a refresh token > > > > About the only use case I can contrive that makes any sense is when > > multiple instances of apps use the same client credentials (already a bad > > idea) and you want to revoke access to a subset of them. To do the > > revocation you would need to simultaneously: > > 1. Revoke the refresh token and any access tokens issued to compromised > > instances > > 2. Update the client secret (or whatever authentication method clients > > have) on those client instances that are still considered ok. > > > > In a deployment where each client has it's own credentials, which should be > > "situation normal" from a security perspective, I don't see any value for > > the refresh token. I also cringe at the idea of someone suggesting that > > refresh token can be presented without client credentials - in this case > > that's like saying client X has n passwords, where n is the number of > > issued refresh tokens. Better to create n sets of client credentials in the > > first place. > > > > Thanks, > > Shane. > > > > ___ > > 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
