Re: [OAUTH-WG] Client authentication requirement
BTW, as I'm working it into the document, these are all great reasons to recommend client authentication, but not to require it. You should clearly require it if you are going to implement all these protections, but at the same time, we clearly have use cases (pretty much from every major provider represented here) to issue refresh tokens to public clients (native apps, etc.) which cannot authenticate. I feel we have been burying our head in the sand for too long about the true requirements and deployment of client authentication. I'm hoping -17 will offer a reasonable fix. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, July 06, 2011 10:20 PM To: Brian Eaton Cc: OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement Very helpful. EHL From: Brian Eaton [mailto:bea...@google.com]mailto:[mailto:bea...@google.com] Sent: Thursday, June 16, 2011 8:38 AM To: Eran Hammer-Lahav Cc: Brian Campbell; OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: Your comment was that having client authentication makes it easier to recovery from an attack. I don't understand how the comments below about changing client secrets every 30 days are relevant. Are you suggesting to wait until the next routine secret cycle to revoke compromised credentials? Or that 30 days is a reasonable time period for ignoring an attack? Sorry, there are multiple good reasons to require client authentication for the access token endpoint. - if you need to recover from a compromise, changing the client credentials will prevent the attacker from abusing refresh tokens they have stolen. Changing a single client credential is much faster than revoking lots of refresh tokens. - if you want to follow best practices for management of authentication credentials, you should do periodic key rotation. Rotation of lots of refresh tokens is quite challenging. Rotation of client credentials is much easier. - if you want to bind refresh tokens to stronger authentication credentials, such as private keys stored in an HSM, you need to require client authentication when using the refresh token. Is that helpful? Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Timely review request: pre-draft-17
I finished the major part of -17, adding a new Client registration section and
folding client authentication into it. This new text attempts to directly
address:
* client authentication requirements
* define client types with regard to keeping secrets
* set registration requirements
* properly explain client identifier
* replace client credentials with a more generic client authentication (in
terms used throughout the document)
* provide a comprehensive discussion of redirection URIs (this is where the few
normative changes are)
* tweak the implicit and authorization code intros to better reflect reality
('optimized for')
* separate client identifier from client authentication (keep binding
requirement)
Normative changes (this should be verified):
* require client authentication for private clients (previously implied)
* require redirection endpoint registration for implicit grant and all for
public clients requests
* remove client_id as a required parameter from the token endpoint (now back to
being part of the client_secret pair)
The draft includes other changes like new error codes, but I'll list those when
the draft is published. I still have about 32 more items on my list to apply
before publishing, but the major changes are done.
You can always find the latest here:
https://github.com/hueniverse/draft-ietf-oauth
Early review of the following sections would be GREALY appreciated:
2. Client Registration
2.1. Client Types
2.2. Registration Requirements
2.3. Client Identifier
2.4. Client Authentication
2.4.1. Client Password
2.4.2. Other Authentication Methods
2.5. Unregistered Clients
3.1.2. Redirection URI
3.2.1. Client Authentication
-17 will be published by Friday at which point I will leave it to the chairs to
decide if they still want to initiate WGLC or give the draft a few days of
informal review.
EHL
-Original Message-
From: Eran Hammer-Lahav
Sent: Monday, July 04, 2011 10:09 PM
To: OAuth WG
Subject: Timely review request: pre-draft-17
I have started sharing my planned changes for 17:
https://github.com/hueniverse/draft-ietf-oauth
Change log:
https://github.com/hueniverse/draft-ietf-
oauth/commit/24a48f99c204331264028
f66708427961a1bc102#diff-3
My main focus right now is to clarify client types, registration, and
identification, as well as tweak the registration requirements for redirection
URIs. This is still very raw. However, I would very much like to get feedback
about the following sections:
1.1.1. Client Types
1.2. Client Registration
2.1.1. Redirection URI
In section 2.1.1, please note that it includes many new normative
requirements, but in practice, they mostly boil down to the requirement to
register a redirection URI for using the implicit grant type as well as using
the
authorization code with a public client (new term for describing client
incapable of keeping secrets).
I have turned the spec around, making registered redirection URIs the
default, and using the parameter as an optional feature.
Feedback is very much appreciated as we only have a few more days before I
have to push out -17 and would like a few more eyes looking at the new text
before published.
I am still not ready to share changes to section 3. Also, I have a long list
of
additional changes raised on the list.
Thanks,
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] state parameter and XSRF detection
Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, June 27, 2011 2:22 PM To: OAuth WG Subject: [OAUTH-WG] state parameter and XSRF detection Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? regards, Torsten. ___ 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] Example tokens
Access tokens realistically may be longer as they may have encrypted scopes and such. From: Eran Hammer-Lahav e...@hueniverse.com To: Brian Campbell bcampb...@pingidentity.com; Oleg Gryb o...@gryb.info Cc: OAuth WG oauth@ietf.org Sent: Wednesday, July 6, 2011 8:53 PM Subject: Re: [OAUTH-WG] Example tokens Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 06, 2011 8:46 PM To: Oleg Gryb Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Example tokens So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ 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] Example tokens
+1 If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger. Thanks, George On 7/7/11 9:24 AM, William J. Mills wrote: Access tokens realistically may be longer as they may have encrypted scopes and such. *From:* Eran Hammer-Lahav e...@hueniverse.com *To:* Brian Campbell bcampb...@pingidentity.com; Oleg Gryb o...@gryb.info *Cc:* OAuth WG oauth@ietf.org *Sent:* Wednesday, July 6, 2011 8:53 PM *Subject:* Re: [OAUTH-WG] Example tokens Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 06, 2011 8:46 PM To: Oleg Gryb Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Example tokens So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com mailto:oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: OAuth WG oauth@ietf.org mailto:oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Timely review request: pre-draft-17
On Thu, Jul 7, 2011 at 4:01 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: -17 will be published by Friday at which point I will leave it to the chairs to decide if they still want to initiate WGLC or give the draft a few days of informal review. Working-group last call can cover all reviews of this. It's a less formal thing than IETF last call, which the IESG will initiate later... and we can recycle the document and do another WGLC if it turns out that we got something so seriously wrong that it's necessary. And I'd like to take this opportunity to say that the chairs are happy with the progress, and we thank everyone for the careful reviews, and for working together to get this work wrapped up. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [oauth] #13: Description of how native applications can use OAuth 2.0
#13: Description of how native applications can use OAuth 2.0 Changes (by barryleiba@…): * status: new = closed * resolution: = fixed Comment: Text provided and incorporated. -- +--- Reporter: Tony Nadalin|Owner: Type: defect | Status: closed Priority: major |Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | +--- Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/13#comment:1 oauth http://tools.ietf.org/oauth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [oauth] #14: Restoring Client Assertion Credentials to the framework specification
#14: Restoring Client Assertion Credentials to the framework specification Changes (by barryleiba@…): * status: new = closed * resolution: = fixed Comment: Assertions document added as WG item. -- +--- Reporter: Tony Nadalin|Owner: Type: defect | Status: closed Priority: major |Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | +--- Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/14#comment:1 oauth http://tools.ietf.org/oauth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
That's not the point. Developers who are going to self-encode tokens don't need the examples. EHL From: George Fletcher [mailto:gffle...@aol.com] Sent: Thursday, July 07, 2011 6:35 AM To: William J. Mills Cc: Eran Hammer-Lahav; Brian Campbell; Oleg Gryb; OAuth WG Subject: Re: [OAUTH-WG] Example tokens +1 If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger. Thanks, George On 7/7/11 9:24 AM, William J. Mills wrote: Access tokens realistically may be longer as they may have encrypted scopes and such. From: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com To: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com; Oleg Gryb o...@gryb.infomailto:o...@gryb.info Cc: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Wednesday, July 6, 2011 8:53 PM Subject: Re: [OAUTH-WG] Example tokens Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.commailto:bcampb...@pingidentity.com] Sent: Wednesday, July 06, 2011 8:46 PM To: Oleg Gryb Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Example tokens So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.commailto:oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto: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] [oauth] #11: 10.3. The OAuth Extensions Error Registry
#11: 10.3. The OAuth Extensions Error Registry Changes (by barryleiba@…): * status: new = closed * resolution: = wontfix -- +--- Reporter: Eran Hammer-Lahav |Owner: Type: suggested change| Status: closed Priority: major |Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: wontfix Keywords: | +--- Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:3 oauth http://tools.ietf.org/oauth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] security considerations - authorization tokens
Looking back at the archives, I didn't find any replies to this proposal. Torsten / Mark / Phil - is this a change you would like me to make? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Sunday, May 22, 2011 8:47 PM To: oauth@ietf.org Subject: [OAUTH-WG] security considerations - authorization tokens As I said in the other note, after reading through the security considerations section a couple of times, I think it could benefit from a different organization. Specifically - keep the introduction, it's awesome. - write new sections for each of the following 1) Authorization Tokens 2) Web Application Clients 3) User-Agent Clients 4) Installed Application Clients 5) Authorization Servers 6) Resource Servers - merge the current text into the appropriate sections. I took a swing at the authorization tokens text. I tried to capture most of the relevant items from the current draft, but might have missed some. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, June 01, 2011 11:43 AM Throughout the document, the various parameters (e.g., client_secret and client_id) are essentially undefined. There is no text about the length of these parameters, the allowable characters (e.g., alpha and digits only, all ASCII characters, full Unicode), internationalization considerations, preparation and comparison of strings, etc. I don't see how developers will build interoperable implementations without clear guidance here. We have no consensus on string sizes. I can add a note that all strings are UTF-8 encoded unless specified otherwise. Access tokens, for example, are defined by each profile. Also, the scope parameter still strike me as extremly vague. Can we at least define the word scope and provide a few examples of how the parameter might be used? Please suggest text. No rules are provided for URI matching (e.g., in Section 4.1 the redirection URI received needs to be checked against the URI used to redirect the client, but not guidance is provided). Perhaps a reference to RFC 3986 is in order here. Here also internationalization concerns might need to be covered (e.g., are IRIs allowed?). Added reference to 3986. As to IRIs, as long as they are encoded as URIs, but last I checked, that was implicit by default. 4.1.2. Authorization Response OLD: If an authorization code is used more than once, the authorization server MAY revoke all tokens previously issued based on that authorization code. NEW: If an authorization code is used more than once, the authorization server SHOULD revoke all tokens previously issued based on that authorization code. RATIONALE: MAY seems weak here. This was changed to MAY because most large scale implementations will not be able to revoke access tokens at all (typically a self-encoded token good for one hour). A SHOULD would be good but impractical advice. I changed it to 'SHOULD attempt' for now. OLD: The authorization server SHOULD issue access tokens with limited scope and duration to clients incapable of authenticating. NEW: If the authorization server issues access tokens to clients that are incapable of authenticating, the scope and duration of such tokens SHOULD be limited. RATIONALE: We're not actively RECOMMENDING authorization servers are to issue such tokens, are we? I removed the sentence are a result of the wg discussion that followed. 10.3. Access Token Credentials The client SHOULD request access token credentials with the minimal scope and duration necessary. Is this enfoced by the authorization server? Not sure how this would be possible. The server can later review what is being used, but not predict. 10.9. Authorization Codes Authorization codes SHOULD be short lived and MUST be single use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD revoke all access tokens already granted based on the compromised authorization code. Is there a good reason why the authorization server would not revoke all the access tokens? If not, change to MUST. See above. Changed it to 'SHOULD attempt' for now. MINOR ISSUES... 1.4.1. Authorization Code OLD: Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client. NEW: Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials at the resource server are never shared with the client. RATIONALE: could the resource owner have credentials at the authorization server? The credentials are always with the authorization server, and the resource server either has access to the credentials, to the server for validation, or relies on cookies and other non-standard credentials replacements. 4.1.2.1. Error Response OLD: error_description OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred. [[ add language and encoding information ]] NEW: error_description OPTIONAL. Descriptive text providing additional information, used to assist in the understanding and resolution of the error that has
Re: [OAUTH-WG] security considerations - authorization tokens
On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin tony...@microsoft.comwrote: When we constructed the current structure in Prague we thought that structure best fit the needs of a implementer, so my preference would be to keep it as it is now but, Torsten / Mark / Phil also may have feedback. Really? The current doc has *no guidelines* on how to implement authorization tokens whatsoever. So even if you like the current organization of the security considerations, I suspect you'll agree it would make sense to offer some guidance on how these tokens ought to be implemented. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] security considerations - authorization tokens
I was responding to the structure question only. The token text is questionable sine the tokens are opaque to the core, seems like the token write-up better belongs in the threat model document. Developers of the various token specs and use this as guidance and reference it. From: Brian Eaton [mailto:bea...@google.com] Sent: Thursday, July 07, 2011 10:59 AM To: Anthony Nadalin Cc: Eran Hammer-Lahav; oauth@ietf.org; Mark Mcgloin (mark.mcgl...@ie.ibm.com); Torsten Lodderstedt (tors...@lodderstedt.net); Phil Hunt (phil.h...@oracle.com) Subject: Re: [OAUTH-WG] security considerations - authorization tokens On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com wrote: When we constructed the current structure in Prague we thought that structure best fit the needs of a implementer, so my preference would be to keep it as it is now but, Torsten / Mark / Phil also may have feedback. Really? The current doc has *no guidelines* on how to implement authorization tokens whatsoever. So even if you like the current organization of the security considerations, I suspect you'll agree it would make sense to offer some guidance on how these tokens ought to be implemented. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] security considerations - authorization tokens
On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin tony...@microsoft.comwrote: I was responding to the structure question only. The token text is questionable sine the tokens are opaque to the core, seems like the token write-up better belongs in the threat model document. Developers of the various token specs and use this as guidance and reference it. OK, leaving aside the question of where the token text should end up, is the text I sent technically correct and useful? The proposed text is here: http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] SAML Assertion Draft Items
WG, Unfortunately I will not be at IETF#81 and will probably not be able to post a new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cutoff date. In lieu of that, I'd like to make a few proposals and/or ask a few questions regarding the next draft in hopes of fostering some productive discussion. Item 1: Profiling of draft-ietf-oauth-assertions Assuming the WG continues to support draft-ietf-oauth-assertions, the SAML draft should become a profile/extension of it. For SAML as a grant type, that should be easy and even shorten/simplify this draft. However, the SAML draft does not currently cover SAML for client authentication and profiling draft-ietf-oauth-assertions would suggest that it should. Is there any general consensus as to if SAML should be profiled as a client authentication method? It is certainly feasible but might require restructuring and retitling the draft. Item 2: URI(s) The value for grant_type is currently defined as http://oauth.net/grant_type/saml/2.0/bearer but there have been some questions raised about the stability and appropriateness of the URL. I really did read RFCs 2648 3553, as was suggested at the last F2F meeting, but it's not clear to me how to register an IETF URI and/or if those RFCs are fully appropriate for this. If someone could explain it to me in terms my preschooler could understand, maybe I could jump though the proper hoops to get the URI to be something like urn:ietf:something:something. Otherwise, I can continue to use http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft should also cover client authentication, also define http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version could then follow a similar pattern. Or perhaps we could use the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer subject confirmation method. It seems like that might be close enough to work out without violating anything serious. And it could be used for both grant_type and client_assertion_type, which is nice. Item 3: Processing rules An out of band request came from folks at a large company to change/relax the validation rules in order to allow for interoperability with existing software products. Which seems very reasonable. The change would basically amount to relaxing the MUST on the SubjectConfirmationData element to a SHOULD (or maybe loser even) while adding a requirement for a NotOnOrAfter attribute on the Conditions element (possibly conditionally based on the existence of it, or not, on the SubjectConfirmationData). It's a little hard to explain but hopefully that conveys the idea. It seems like a change that should be made but I wanted to get some feedback from a wider group before doing it. I realize the assertion stuff is secondary to the core protocol for most of you but I that you, if you've read this far, and I welcome and appreciate any thoughts/feedback on these issues/questions. Thanks, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Native Application Text
What is ‘monitoring http headers’? EHL From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Sent: Tuesday, June 28, 2011 6:15 PM Subject: [OAUTH-WG] Native Application Text 9. Native Applications A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application, etc.). Native applications may require special consideration related to security, platform capabilities, and overall end-user experience. The following are examples of how native applications may utilize OAuth: o Initiate an Authorization Request using an external user-agent: The native application can capture the response from the authorization server using a variety of techniques such as the use of the various methods for redirection including a URI identifying a custom URI scheme (registered with the operating system to invoke the native application as handler), manual copy-and-paste, running a local webserver, browser plug-ins, or by providing a redirection URI identifying a server-hosted resource under the native application's control, which in turn makes the response available to the native application. o Initiate an Authorization Request using an embedded user-agent: The native application obtains the response by directly communicating with the embedded user-agent. Techniques include monitoring state changes emitted during URL loading, monitoring http headers, accessing the user-agent's cookie jar, etc. When choosing between launching an external user-agent and an embedded user-agent, native application developers should consider the following: o External user-agents may improve completion rate as the end-user may already have an active session with the authorization server removing the need to re-authenticate, and provide a familiar user-agent user experience and functionality. The end-user may also rely on extensions or add-ons to assist with authentication (e.g. password managers or 2-factor device reader). o Embedded user-agents may offer an improved end-user flow, as they remove the need to switch context and open new windows. o Embedded user-agents pose a security challenge because end-users are authenticating in an unidentified window without access to the visual protections found on by many of the external user-agents. Embedded user-agents educate end-user to trust unidentified requests for authentication (making phishing attacks easier to execute). When choosing between implicit and authorization code grant types, the following should be considered: o Native applications that use the authorization code grant type flow SHOULD do so without using client password credentials, due to the native application’s inability to keep those credentials secure. o When using the implicit grant type flow a refresh token is not returned ___ OAuth mailing list OAuth@ietf.orgmailto: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] Section 10.1 (Client authentication)
I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com schrieb: It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Subject: Section 10.1 (Client authentication) Hi Eran, would you please add the following sentence (which was contained in the original security considerations text) to the second paragraph of section 1.0.1? Alternatively, authorization servers MUST utilize other means than client authentication to achieve their security objectives. I think it's important to state that authorization server should consider alternative way to validate the client identity if secrets cannot be used. The security threat document also suggest some. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML Assertion Draft Items
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, July 07, 2011 12:06 PM To: oauth Subject: [OAUTH-WG] SAML Assertion Draft Items WG, Unfortunately I will not be at IETF#81 and will probably not be able to post a new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cutoff date. In lieu of that, I'd like to make a few proposals and/or ask a few questions regarding the next draft in hopes of fostering some productive discussion. Item 1: Profiling of draft-ietf-oauth-assertions Assuming the WG continues to support draft-ietf-oauth-assertions, the SAML draft should become a profile/extension of it. For SAML as a grant type, that should be easy and even shorten/simplify this draft. However, the SAML draft does not currently cover SAML for client authentication and profiling draft-ietf-oauth-assertions would suggest that it should. Is there any general consensus as to if SAML should be profiled as a client authentication method? It is certainly feasible but might require restructuring and retitling the draft. Are there use cases pending such functionality today? It would be a shame to delay an otherwise useful draft when the functionality can be added later. Item 2: URI(s) The value for grant_type is currently defined as http://oauth.net/grant_type/saml/2.0/bearer but there have been some questions raised about the stability and appropriateness of the URL. I'm not a fan. I really did read RFCs 2648 3553, as was suggested at the last F2F meeting, but it's not clear to me how to register an IETF URI and/or if those RFCs are fully appropriate for this. If someone could explain it to me in terms my preschooler could understand, maybe I could jump though the proper hoops to get the URI to be something like urn:ietf:something:something. Asking on the URN list usually helps. Otherwise, I can continue to use http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft should also cover client authentication, also define http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version could then follow a similar pattern. Or perhaps we could use the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer subject confirmation method. It seems like that might be close enough to work out without violating anything serious. And it could be used for both grant_type and client_assertion_type, which is nice. Don't use an OASIS URN. That's asking for trouble. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
