Re: [OAUTH-WG] Draft 16 Security Considerations additions

[Eran Hammer-Lahav]

 using a DOM variable (protected by JavaScript or other DOM-binding language's 
enforcement of SOP)

This is not clear without a reference or more details description.

EHL

 -Original Message-
 From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
 Sent: Wednesday, July 06, 2011 8:56 AM
 To: Eran Hammer-Lahav
 Cc: oauth@ietf.org; Torsten Lodderstedt
 Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
 
 Reworded to modify the text around secret and some additional info on
 redirect-uri (with some input from Shane Weaden) and adding state in
 dynamic redirect-uri (with input from Torsten)
 
 CSRF
 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
 requests are transmitted from a user that the website trusts or has
 authenticated. CSRF attacks on OAuth approvals can allow an attacker to
 obtain authorization to OAuth Protected Resources without the consent of
 the User.
 The state parameter should be used to mitigate against CSRF attacks,
 particularly for login CSRF attacks. CSRF attacks against a client's redirect 
 URI
 allow an attacker to inject their own authorization code (or access token for
 implicit grant flow). This may result in the client using an access token
 associated with the attackers account rather than the victims. Depending on
 the nature of the client and the protected resources, this can have
 undesirable and damaging effects.
 It is strongly RECOMMENDED that the client sends the state parameter with
 authorization requests to the authorization server. The state parameter
 MUST be non-guessable and the client MUST be capable of keeping it in a
 location accessible only by the client or the user agent (i.e., protected by
 same-origin policy). e.g.: DOM variable (protected by _javascript_ or other
 DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-
 side storage, etc. The authorization server will send it in the response when
 redirecting the user to back to the client which MUST then validate the state
 parameter matches on the response. Use of the state parameter by a client
 protects against this style of attack as the attacker cannot know the state
 parameter associated with the victims browser session at the client.
 While sending the state parameter is the preferred mechanism for linking
 the client to the authorization requests and callbacks, a state parameter
 (s) embedded into the redirect uri could be used for the same purpose. A
 prerequisite is that the authorization server's uri validation policy must 
 allow
 for dynamic uri query parts.
 
 
 Clickjacking
 Clickjacking is the process of tricking users into revealing confidential
 information or taking control of their computer while clicking on seemingly
 innocuous web pages. In more detail, a malicious site loads the target site 
 in a
 transparent iframe overlaid on top of a set of dummy buttons which are
 carefully constructed to be placed directly under important buttons on the
 target site. When a user clicks a visible button, they are actually clicking a
 button (such as an Authorize button) on the hidden page.
 To prevent clickjacking (and phishing attacks), native applications SHOULD
 use external browsers instead of embedding browsers in an iFrame when
 requesting end-user authorization. For newer browsers, avoidance of
 iFrames can be enforced server side by using the X-FRAME-OPTION header.
 This header can have two values, deny and sameorigin, which will block any
 framing or framing by sites with a different origin, respectively. For older
 browsers, javascript framebusting techniques can be used but may not be
 effective in all browsers.
 
 Regards
 
 Eran Hammer-Lahav e...@hueniverse.com wrote on 04/07/2011 20:02:02:
 
  From:
 
  Eran Hammer-Lahav e...@hueniverse.com
 
  To:
 
  Mark Mcgloin/Ireland/IBM@IBMIE, Torsten Lodderstedt
 tors...@lodderstedt.net
 
  Cc:
 
  oauth@ietf.org oauth@ietf.org
 
  Date:
 
  04/07/2011 20:01
 
  Subject:
 
  Re: [OAUTH-WG] Draft 16 Security Considerations additions
 
  This needs to be reworked to reflect reality. The state value must be
  shared with the resource owner's browser and authorization server, so
  it is not really a secret known only to the client…
 
  EHL
 
  From: Mark Mcgloin mark.mcgl...@ie.ibm.com
  Date: Wed, 1 Jun 2011 11:28:33 -0700
  To: Torsten Lodderstedt tors...@lodderstedt.net
  Cc: oauth@ietf.org oauth@ietf.org
  Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
 
  Hi Torsten
 
  It was implicit that the state parameter would be secret and not
 guessable
  but that it probably worth spelling out, as you and Breno state. Here
  is
 a
  modified version
 
  CSRF
  Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
  requests are transmitted from a user that the website trusts or has
  authenticated. CSRF attacks on OAuth approvals can allow an attacker
  to obtain authorization to OAuth Protected Resources without the
  consent of the User.
  The state 

Re: [OAUTH-WG] Draft 16 Security Considerations additions

[Eran Hammer-Lahav]

Can this be reworked to discuss the authorization endpoint specifically? The 
use of 'target' site is confusing. This section needs to be much more specific 
to the authorization process.

EHL

 -Original Message-
 From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
 Sent: Wednesday, July 06, 2011 8:56 AM
 To: Eran Hammer-Lahav
 Cc: oauth@ietf.org; Torsten Lodderstedt
 Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
 
 
 
 Clickjacking
 Clickjacking is the process of tricking users into revealing confidential
 information or taking control of their computer while clicking on seemingly
 innocuous web pages. In more detail, a malicious site loads the target site 
 in a
 transparent iframe overlaid on top of a set of dummy buttons which are
 carefully constructed to be placed directly under important buttons on the
 target site. When a user clicks a visible button, they are actually clicking a
 button (such as an Authorize button) on the hidden page.
 To prevent clickjacking (and phishing attacks), native applications SHOULD
 use external browsers instead of embedding browsers in an iFrame when
 requesting end-user authorization. For newer browsers, avoidance of
 iFrames can be enforced server side by using the X-FRAME-OPTION header.
 This header can have two values, deny and sameorigin, which will block any
 framing or framing by sites with a different origin, respectively. For older
 browsers, javascript framebusting techniques can be used but may not be
 effective in all browsers.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Timely review request: pre-draft-17

[Eran Hammer-Lahav]

Almost done with -17.

I have sent a few emails to the list with open questions and requests. I will 
include as many of the replies as I can before publishing tomorrow or Saturday.

My remaining task is to try and move as much of the normative text (MUST, 
SHOULD) out of the security consideration section and into the relevant 
sections where the actual component is discussed. I also need to review all the 
normative language and make sure it is consistent (found a few MUST in one spot 
and SHOULD in another).

Changes not discussed fully on the list are marked with [[ Pending Consensus ]].

EHL

 -Original Message-
 From: Eran Hammer-Lahav
 Sent: Thursday, July 07, 2011 1:01 AM
 To: OAuth WG
 Subject: RE: 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] Section 10.1 (Client authentication)

[Torsten Lodderstedt]

seems you are contradicting yourself. 

You criticised the MUST and suggested to include some examples. I bought into 
your argument and suggested to refer to the security doc for examples and 
additional explanations. That's what this document is intended for, to provide 
background beyond what we can cover in the core spec.

And I don't think the spec already makes that point. But you are free to refer 
me to the respective text.

regards,
Torsten.



Eran Hammer-Lahav e...@hueniverse.com schrieb:

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] state parameter and XSRF detection

[Torsten Lodderstedt]

Hi Eran,

including dynamic values within redirect uris is standard practice today and is 
allowed by the spec's text so far. I don't mind to change it but the restricted 
behavior you prefer is a significant protocol change.

Moreover, I would like to understand the threat you have in mind and include it 
into our threat model. So would you please provide a more detailed description?

regards,
Torsten.




Eran Hammer-Lahav e...@hueniverse.com schrieb:

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] security considerations - authorization tokens

[Torsten Lodderstedt]

Hi Brian,

your text is definitely a valuable contribution. Please note: your earlier text 
on OAuth security considerations has already been incorporated into the 
security document. 

I would suggest to first incorporate your new text there (probably together 
with your proposal regarding redirect uri validation). Afterwards we can decide 
what we really need in the core spec's sec considerations section. 

When we wrote the first draft of this section, we intended to keep it focused 
on the essential MUSTs to be considered by implementors (client, as, rs). 
Otherwise we will blow up this section to much and none will read it. I would 
prefer to keep it that way.

Does this sound reasonable for you?

regards,
Torsten.



Brian Eaton bea...@google.com schrieb:

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

Re: [OAUTH-WG] Section 10.1 (Client authentication)

[Eran Hammer-Lahav]

Hey Torsten,

The provided text and alternative text are just not helpful. If I am unable to 
understand it, I have doubt other readers will be able to.

I don't know what you mean by 'other means' which are not already described in 
the document (based on -17). Referencing the security thread model document in 
a normative reference requires making it a normative reference which I am 
opposed to doing - the v2 document should include everything needed to 
implement the protocol without any additional specifications (for the core 
functionality).

When I was asking for examples, I was hoping for something like 'for example, 
use x, y, or z', not a reference to about 10 pages of text (which by itself is 
pretty confusing, but that's a different issue - I hope to find the time to 
provide detailed feedback for that document).

I think the current document makes a pretty good case for using the redirection 
URI as a form of client validation, and clearly lays out the differences 
between a public and private client. It has new requirements for the 
registration of redirection URIs when client authentication is not possible.

If there are specific things the authorization server can do to improve 
security beyond client authentication, we should list them explicitly in the 
document.

Can you list exactly what you have in mind by 'other means'? Just the bullet 
points will be enough.

EHL


 -Original Message-
 From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
 Sent: Friday, July 08, 2011 12:59 AM
 To: Eran Hammer-Lahav; OAuth WG
 Subject: RE: Section 10.1 (Client authentication)
 
 seems you are contradicting yourself.
 
 You criticised the MUST and suggested to include some examples. I bought
 into your argument and suggested to refer to the security doc for examples
 and additional explanations. That's what this document is intended for, to
 provide background beyond what we can cover in the core spec.
 
 And I don't think the spec already makes that point. But you are free to refer
 me to the respective text.
 
 regards,
 Torsten.
 
 
 
 Eran Hammer-Lahav e...@hueniverse.com schrieb:
 
 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] state parameter and XSRF detection

[Eran Hammer-Lahav]

The security of the protocol relies fully (implicit grant) or partially 
(authorization code) on the validation of the redirection URI. This was well 
understood by many experts but until -17, we largely ignored by the 
specification.

Using dynamic values are still fully supported:

   3.1.2.2.  Registration Requirements

   The authorization server MUST require public clients to register
   their redirection URI, MUST require all clients to register their
   redirection URI prior to utilizing the implicit grant type, and
   SHOULD require all clients to register their redirection URI prior to
   utilizing the authorization code grant type.

   The authorization server SHOULD require the client to provide the
   complete redirection URI (the client MAY use the state request
   parameter to achieve per-request customization).  The authorization
   server MAY allow the client to register multiple redirection URIs.
   If requiring the registration of the complete redirection URI is not
   possible, the authorization server SHOULD require the registration of
   the URI scheme, authority, and path.

And 3.1.2.3.  Dynamic Configuration, adds:

   If the authorization server allows the client to dynamically change
   the query component of the redirection URI, the client MUST ensure
   that manipulation of the query component by an attacker cannot lead
   to an abuse of the redirection endpoint as an open redirector.

The rational for this is that comparing full URIs (using simple string 
comparison) provides for much less moving parts. We know from experience that 
URI normalization is hard and that attackers sometimes find ways to inject 
values into the redirection URI and still pass validation (based on the 
specific issues with the server’s normalization logic).

We were unable to come up with a useful set of rules for redirection URI 
validation based on individually registered URI components. This has also been 
an area of great confusion by OAuth 1.0 developers, as each provider has its 
own set of rules and methods for URI registration. Some implementations are 
outright idiotic. On the other hand, if we recommend developers to simply do 
string comparison (per RFC 3986 section 6) and not allow any changes, we know 
it is much more likely to be implemented securely.

Beyond the complexity of normalization and comparison: many existing platform 
allow for internal redirections and special handling using special query 
parameters. Most login pages support some form of automatic redirection to the 
referring resource. If an attacker can access such a parameter, it can 
manipulate the redirection URI to pass validation but produce very different 
results. The worst case scenario is finding a query parameter capable of 
triggering a redirection which will then send the credentials to the attacker.

The simplest form of this attack is the availability of an open redirector 
(which most large providers have, some with better safeguards then others). If 
example.com offers an open redirector, registration of the scheme and authority 
will accomplish nothing, as the open redirector endpoint will pass validation. 
Registration of the full path is *usually* sufficient, but not always, and 
relies of proper normalization that forces a query separator '?' between the 
fully registered path and the appended query (as well as enforce proper 
reserved characters encoding).

The typical sophistication of the authorization server developer is much 
greater than that of the client developer. It is better to encourage the server 
developer to enforce better policy, than hope that the client developer will be 
able to find and close every potential security hole in its entire system to 
render redirection URI validation trustworthy.

The specification provides and highlights the 'state' parameter as the proper 
way of accomplishing redirection URI customization. It is significantly simpler 
to restrict validation to simple string comparison, and protect the 'state' 
parameter on the client from being abused by an attacker.

If I had it my way, the specification would ban any type of dynamic redirection 
URI (other than selecting one out of multiple fully specified options). But 
this proposal was rejected (for no good reasons, just people stuck to their 
broken old ways), so the new text is the best I can do without making breaking 
changes.

EHL





From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] 
Sent: Friday, July 08, 2011 1:23 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: [OAUTH-WG] state parameter and XSRF detection

Hi Eran,

including dynamic values within redirect uris is standard practice today and is 
allowed by the spec's text so far. I don't mind to change it but the restricted 
behavior you prefer is a significant protocol change.

Moreover, I would like to understand the threat you have in mind and include it 
into our threat model. So would you please provide a more detailed description?

[OAUTH-WG] Fw: New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth

[William J. Mills]

FYI and feedback welcome.


- Forwarded Message -
From: William J. Mills wmi...@yahoo-inc.com
To: kit...@ietf.org kit...@ietf.org
Cc: Hannes Tschofenig hannes.tschofe...@nsn.com; hannes.tschofe...@gmx.net 
hannes.tschofe...@gmx.net; Tim Showalter tims...@yahoo-inc.com
Sent: Thursday, July 7, 2011 11:52 AM
Subject: New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth


Hi,

I've posted a new draft.  I believe there is one open issue, and that is 
whether we're going to include text defining how Tunneled HTTP authentication 
(started as OAuth) works with GSS-API. I am coming more and more to the opinion 
that the GSS-API definition is going to be very auth mechanism specific.  This 
draft only defines what SASL needs currently, which is user auth.  GSS-API has 
message integrity as well, and possibly other things that can be mapped into 
HTTP auth schemes, and I think it's going to be  required that the auth schemes 
define their capabilities and GSS_API mappings.

The draft also fixes the channel binding text, not tls-unique specific.  Also 
defining how the CB data is properly generated.

Subject to the open issue above (which could be significant) I
 think this is close to a last call.

Does this draft need some discussion time in Quebec?  If so I'll need to make 
travel plans.

Thanks,

-bill


Meta-Data from the Draft
Documentdraft-mills-kitten-sasl-oauth 
[View first two pages] 
* [Txt version ]
* [Pdf version ]
* [Xml version ] 
Revision03 
WGIndividual Submission 
Document date2011-07-01 
Submission date2011-07-02 
TitleTunneled HTTP Authentication For SASL 
Author information
Author 1William Mills wmi...@yahoo-inc.com 
Author 2Tim Showalter tims...@yahoo-inc.com 
Author 3Hannes Tschofenig hannes.tschofe...@gmx.net 
AbstractSimple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in connection-
oriented protocols via replaceable mechanisms.  OAuth is a protocol
framework for delegated HTTP authentication and thereby provides a
method for clients to access a protected resource on behalf of a
resource owner.

This document defines the use of HTTP authentication over SASL, and
additionally defines authorization and token issuing endpoint
discovery.  Thereby, it enables schemes defined within the OAuth
framework for non-HTTP-based application protocols.

A significant benefit of OAuth for usage in clients that usually
store passwords is storing tokens instead of passwords.  This is much
lower risk since tokens can be more limited in scope of access and
can be managed and revoked separately from the user
 credential
(password).
 
Pages24 ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Authorization code security considerations

[Eran Hammer-Lahav]

Authorization codes MUST be kept confidential

How exactly? They are not confidential by nature, being received via 
redirection in the URI query. I know what this sentence is trying to accomplish 
but not sure how to do that with normative language. SHOULD doesn't really work 
here either.

Suggestions?

EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization code security considerations

[Brian Eaton]

On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
 How exactly? They are not confidential by nature, being received via 
 redirection in the URI query. I know what this sentence is trying to 
 accomplish but not sure how to do that with normative language. SHOULD 
 doesn't really work here either.

The browser same origin policy does apply to URI queries.  They MUST
be kept confidential, i.e. only sent to authorized entities.  That
covers:

- the client web site
- the browser
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization code security considerations

[Eran Hammer-Lahav]

Can you provide this in a form suitable for pasting into the current text? 
Browser same origin policy is enforced by the user-agent, and is beyond the 
scope of this protocol.

EHL

 -Original Message-
 From: Brian Eaton [mailto:bea...@google.com]
 Sent: Friday, July 08, 2011 11:52 AM
 To: Eran Hammer-Lahav
 Cc: OAuth WG
 Subject: Re: [OAUTH-WG] Authorization code security considerations
 
 On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav e...@hueniverse.com
 wrote:
  How exactly? They are not confidential by nature, being received via
 redirection in the URI query. I know what this sentence is trying to
 accomplish but not sure how to do that with normative language. SHOULD
 doesn't really work here either.
 
 The browser same origin policy does apply to URI queries.  They MUST be
 kept confidential, i.e. only sent to authorized entities.  That
 covers:
 
 - the client web site
 - the browser
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt

[internet-drafts]

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   : The OAuth 2.0 Authorization Protocol
Author(s)   : Eran Hammer-Lahav
  David Recordon
  Dick Hardt
Filename: draft-ietf-oauth-v2-17.txt
Pages   : 62
Date: 2011-07-08

   The OAuth 2.0 authorization protocol enables a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt

[Eran Hammer-Lahav]

Please ignore. This was a bad submission (wrong file). -18 will follow shortly.

EHL

 -Original Message-
 From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
 Of internet-dra...@ietf.org
 Sent: Friday, July 08, 2011 11:55 AM
 To: i-d-annou...@ietf.org
 Cc: oauth@ietf.org
 Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-17.txt
 
 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   : The OAuth 2.0 Authorization Protocol
   Author(s)   : Eran Hammer-Lahav
   David Recordon
   Dick Hardt
   Filename: draft-ietf-oauth-v2-17.txt
   Pages   : 62
   Date: 2011-07-08
 
The OAuth 2.0 authorization protocol enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.
 
 
 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 This Internet-Draft can be retrieved at:
 ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-17.txt
 ___
 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] I-D Action: draft-ietf-oauth-v2-18.txt

[internet-drafts]

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   : The OAuth 2.0 Authorization Protocol
Author(s)   : Eran Hammer-Lahav
  David Recordon
  Dick Hardt
Filename: draft-ietf-oauth-v2-18.txt
Pages   : 61
Date: 2011-07-08

   The OAuth 2.0 authorization protocol enables a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-18.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-18.txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-ietf-oauth-v2-18

[Eran Hammer-Lahav]

Published draft-ietf-oauth-v2-18.

This was a much larger effort than I was previously expecting or planning. 
Review requires reading the full text as the number of changes makes using a 
diff tool impractical. Below is the mostly complete list of changes. The new 
draft should include very few normative changes requiring changes to existing 
code (at least that was the intention).

*** Please do not reply to this thread but instead start new threads per issue 
to make discussion easier.

List of open issues:

* Consensus for new Client Registration section (2)
* Consensus for revised Redirection URI section (3.1.2)
* Consensus for new token endpoint Client Authentication section (3.2.1)
* Consensus for new authorization endpoint response type extensibility (8.4)
* Missing example from security section 10.4 Refresh Tokens
* Missing reference to DOM variable example in section 10.12 Cross-Site Request 
Forgery
* Need editing for 10.13 Clickjacking to better align with the protocol 
terminology, missing reference for x-frame-options header

(This is the complete list. If you have an issue not listed you must raise it 
again as it is not being tracked.)


Changes from -16:

* Many editorial changes, typos, and clarifications.
* Replaced end-user with resource owner anywhere were the term was referring to 
the official role. End-user is only used for casual references to people.
* Replaced computer with device.
* Replaced duration with lifetime.
* Expanded TOS to three levels deep.
* Replaced client credentials with client authentication as a general term.
* Replaced secrets with credentials as a general term.
* Removed definition of refresh token as a self-encoded credential.
* Removed client credentials as a distinct object in diagrams, kept explicit 
authentication language in diagram text.
* Removed document structure section in introduction.
* Added new Client Registration section, folded previous Client Authentication 
section into it.
* Forbid including a fragment component in authorization endpoint URIs.
* Significantly expanded the Redirection URI section, added discussion about 
URI matching, multiple registered URIs, and including of third-party scripts in 
landing page.
* Added requirement to register redirection URIs for all public clients, and 
for all usage of the implicit grant.
* Added recommendation to register the entire redirection URI.
* Added discussion of the reasons and requirements of client authentication 
when using the token endpoint.
* Adjusted grant type introductions from 'suitable' to 'optimize' to better 
align with other use cases.
* Changed redirect_uri to OPTIONAL (was implicitly already).
* Added requirement to expire the authorization code and recommended 10 minutes 
lifetime.
* Changed language from 'MAY' to 'SHOULD attempt' regarding revoking access 
tokens issued via a compromised authorization code.
* Replaced example tokens with 22 character strings
* Added state parameter to examples
* Removed client_id from the various sections describing the token endpoints, 
moved back to the client password credentials section.
* Removed error extensibility using HTTP status codes, added new error codes: 
server_error and temporarily_unavailable.
* Clarified error_description and error_uri as used for debugging only.
* Changed implicit grant type 'Web server with client resource' to 'Web-hosted 
client resource' to reduce confusion with other servers.
* Fixed various typos in scope definitions.
* Added note about user-agent support for fragments in redirection Location 
headers.
* Added note to resource owner password credentials grant type about brute 
force attacks.
* Clarified that the client credentials grant type applies to other forms of 
client authentications (not just via credentials).
* Added recommendation not to issue refresh tokens when using client 
credentials grant.
* Added charset=UTF-8 to all content-type header examples.
* Added 'Pragma: no-cache' to credential responses.
* Added requirement to authenticate the client when refreshing tokens for 
private clients.
* Clarified that new refresh tokens must have the same scope as the one used to 
make the refresh request.
* Added response type extensibility and registry for the authorization 
endpoint, added special designation for the '+' character in response type 
names (no parsing).
* New native applications section text.
* Cleanup of security considerations text, moving some normative requirements 
to previous sections.
* Added reference to RFC 4949.
* Added reference to RFC 2818.
* Rearranged the order of sections in security considerations.
* Imported phishing text from OAuth 1.0 RFC.
* Added CSRF and Clickjacking sections.
* Removed empty Redirection URI Validation section in security considerations.


EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization code security considerations

[Justin Richer]

I'm not sure normative language even fits here. We need something like 
Authorization codes should be treated as sensitive and the client needs 
to try to make sure it doesn't leak the authorization code. But more 
formal and less garden pathy than I'm able to pen at the moment.

  -- Justin

On 7/8/2011 2:39 PM, Eran Hammer-Lahav wrote:

Authorization codes MUST be kept confidential

How exactly? They are not confidential by nature, being received via 
redirection in the URI query. I know what this sentence is trying to accomplish 
but not sure how to do that with normative language. SHOULD doesn't really work 
here either.

Suggestions?

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