Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

2012-01-16 Thread Mark Mcgloin
Hi William Sorry for slow response - comments inline below. I really would like to close out on this set of countermeasures. I think the differing opinions are subjective as this point and we all need to bear in mind that the threat model is intended to advise on best practices and not all of

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

2012-01-16 Thread Michael Thomas
On 01/16/2012 05:52 AM, Mark Mcgloin wrote: Countermeasures: First off the title: it says Countermeasures. Therefore, anything here must be a real and meaningful countermeasure. 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications

Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

2012-01-16 Thread Eran Hammer
Should this be added to the security model document? Is it already addressed there? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of André DeMarre Sent: Tuesday, October 04, 2011 11:33 AM To: OAuth WG Subject: [OAUTH-WG] Phishing

Re: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials

2012-01-16 Thread Eran Hammer
Compliant - sure. Smart - well, that depends on the use case. OAuth provide a very flexible framework (mostly because we could not agree more on restrictions). This means you can follow the spec and produce bad or insecure implementation. The spec does warn against such issues, and in the case

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions

2012-01-16 Thread Eran Hammer
Added: scope = scope-token *( SP scope-token ) scope-token = %x21 / %x23-5B / %x5D-7E EHL -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Tuesday, October 18, 2011 9:40 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG]

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions

2012-01-16 Thread Eran Hammer
Sorry: scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer Sent: Monday, January 16, 2012 10:46 AM To: Julian Reschke Cc: OAuth

[OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Eran Hammer
A question came up about the access token expiration when expires_in is not included in the response. This should probably be made clearer in the spec. The three options are: 1. Does not expire (but can be revoked) 2. Single use token 3. Defaults to whatever the authorization server decides and

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Eran Hammer
expires_in OPTIONAL. The lifetime in seconds of the access token. For example, the value spanx style='verb'3600/spanx denotes that the access token will expire in one hour from the time the response was generated. The authorization

Re: [OAUTH-WG] Security Considerations - Access Tokens

2012-01-16 Thread Eran Hammer
Added the word 'credentials' (e.g. Access token credentials (as well as...) to make this clearer. IOW, when using MAC tokens, the token secret is the part that must be protected, not the token id. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marco De Nadai

Re: [OAUTH-WG] Security Considerations - Access Tokens

2012-01-16 Thread Torsten Lodderstedt
makes sense. regards, Torsten. Am 16.01.2012 20:00, schrieb Eran Hammer: Added the word 'credentials' (e.g. Access token credentials (as well as...) to make this clearer. IOW, when using MAC tokens, the token secret is the part that must be protected, not the token id. EHL

Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

2012-01-16 Thread André DeMarre
Eran, Yes; I think a section should be added to the security model doc. On 2011-12-16 Mark Mcgloin agreed and suggested we call it Client Registration of phishing clients: http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html I'm happy to propose the text; it might be one or two days

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Richer, Justin P.
I think #3. #1 will be a common instance, and #2 (or its variant, a limited number of uses) is a different expiration pattern than time that would want to have its own expiration parameter name. I haven't seen enough concrete use of this pattern to warrant its own extension though. Which is

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Eran Hammer
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? EHL -Original Message- From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Monday, January 16, 2012 7:29 PM To: Eran Hammer Cc: OAuth WG; wolter.eldering Subject: Re: [OAUTH-WG] Access Token Response

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Aaron Parecki
That seems like a good idea, but then it should also be explicitly stated what to do if the server issues non-expiring tokens. aaronpk On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer e...@hueniverse.com wrote: How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? EHL

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Eran Hammer
Hmm. This might become too much work at this stage… Happy for suggestions but I won’t pursue it on my own for now. EHL From: Aaron Parecki [mailto:aa...@parecki.com] Sent: Monday, January 16, 2012 10:36 PM To: OAuth WG Cc: Richer, Justin P.; wolter.eldering; Eran Hammer Subject: Re: [OAUTH-WG]

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Aaron Parecki
Actually now I'm having second thoughts about making expires_in RECOMMENDED. Here's another attempt at a clarification: expires_in OPTIONAL. The lifetime in seconds of the access token. For example, the value 3600 denotes that the access token will expire in one hour

Re: [OAUTH-WG] Access Token Response without expires_in

2012-01-16 Thread Eran Hammer
WFM. From: Aaron Parecki [mailto:aa...@parecki.com] Sent: Monday, January 16, 2012 11:08 PM To: OAuth WG Cc: Eran Hammer; Richer, Justin P.; wolter.eldering Subject: Re: [OAUTH-WG] Access Token Response without expires_in Actually now I'm having second thoughts about making expires_in