Subject: [OAUTH-WG] Security Considerations Section Proposal

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 31 Mar 2011 12:08:05 +0200

Hi all,

I just uploaded a proposal for the security section of the core spec to 
the IETF site 
(http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-securityconsiderations/). 

As posted on the list previously, our idea was first to derive a 
security consideration section for the core spec by cutting down 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/  to a 
reasonable size. We tried to go through the document and identify the 
pieces that should go into the spec in the informal OAuth security 
session here at IETF-80. Although we did not make it further than 4.1.3, 
the meeting turned out to be valuable since we agreed on certain 
principles we are expected to apply when producing the section:
- focus on service provider and application developers perspective (and 
the protocol implementation)
- document the "what" and not the "why" - for "why" include informative 
reference to security document
- explicitely state don'ts and explicitely define and distinguish three 
client categories (web, native, JavaScript)
For example we had a really lengthy discussion about native apps, client 
secrets and client authentication - bottom line: we just state 
"Authorization server MUST NOT issue client secrets to installed or 
JavaScript applications."

Moreover, we agreed to produce a security considerations section as 
concise as possible and as quickly as possible. There were objections in 
the room to "just" cut down our document. Instead the proposal was to 
start something new.

So the proposed text focus on the "WHAT" and references 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ for a 
discussion of the "WHY".

Your feedback is appreciated.

regards,
Torsten.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2011 14:17:55 +0200

Hi all, 

I am very happy that you got a proposal put together to quickly. Thanks for the good writeup!

A few comments below. 

---------------

2.  Security Considerations

   Note: This section focuses on the security principles implementors of
   the protocol MUST consider.  These principles have been derived based
   on the comprehensive security analysis of the OAuth 2.0 protocol
   given in [
I-D.lodderstedt-oauth-security
].

I would write: 

This section focuses on the security principles implementors of
 the protocol must consider.  We encourage readers to consult the 
more detailed analysis with additional background information can
be found in [I-D.lodderstedt-oauth-security].

2.1.  Client Secrets

   Authorization servers can issue client secrets to web applications.
   Application developers MUST ensure confidentiality of client secrets.

   Authorization server MUST NOT issue client secrets to native or
   JavaScript applications.  

[hannes] "... since these client secrets cannot be protected easily in these 
environments."

Instead authorization servers MUST utilize

[hannes] I added the MUST here. 

   other means than client authentication to achieve their security
   objectives.  Authorization servers can issue client secrets to native
   applications on a per installation base.

[hannes] I am not sure what you want to say with the last sentence given what you said in the earlier sentence. 

   Authorization servers MUST NOT automatic repeat approvals for clients
   without secrets.

[hannes] Could you say why? 

2.2.  Refresh Tokens

   Authorization servers may issue refresh tokens to web and native
   applications.

[hannes] I would say: "The OAuth protocol allows authorization servers 
may issue refresh tokens to web and native applications."

   Refresh tokens should only be accessible to the authorization server
   and the client the token has been issued to.  

[hannes] why do you say "should"? Couldn't we say "MUST"?

The authorization
   server MUST maintain the link between a refresh token and the client
   it has been issued to.  This relation MUST be validated on every
   token refreshment request.

   Authorization server as well as application developers MUST ensure

[hannes] write: 
"Authorization server operators as well as application developers MUST ensure"

   confidentiality of refresh tokens, on transit and storage.
   Authorization servers should implement means to detect abuse of
   refresh tokens.

[hannes] write : "It is RECOMMENDED for authorization server operators to enable means to detect abuse of
   refresh tokens." 

On the other hand we could argue that authorization server operators are encouraged to monitor abuse in general; not only for refresh tokens.

   (what about revocation?)

[hannes] Ignore revocation because OAuth core does not consider revocation. 

2.3.  Access Tokens

   Access tokens should only be accessible to the authorization server,
   the target resource servers and the client the token has been issued
   to.

[hannes] why should and not must? 
(with the exception listed below)

  The only exception is the implicit grant where the user agent
   gets access to the access token that is transmitted in the URI
   fragment.

   Application developers MUST NOT store access tokens in non-transient
   memory.

2.4.  Token Scope

   Application developers should only acquire access tokens with the
   minimal scope they need in order to implement the respective
   application function.

[hannes] I would say that it is useful to talk about "It is strongly RECOMMENDED ....". 

2.5.  Phishing attacks on redirect-based flows

   Application developers should, when possible, use external browsers
   instead of browsers embedded in the application for performing the
   end-user authorization process.

[hannes] again, recommended is more appropriate. I would also extend the sentence to say 
a few words about the why.

   Authorization servers MUST ensure authenticity of the endpoint in
   order to prevent phishing attacks.

[hannes] I wonder whether this is the right way of phrasing it: What about 
"To reduce the risk of phishing attacks authorization servers MUST provide their 
identity to other entities."

  For example, they can utilize
   HTTPS server authentication for that purpose.  Moreover, service
   Providers should attempt to educate users about the risks phishing
   attacks pose, and should provide mechanisms that make it easy for
   Users to confirm the authenticity of their sites. e.g. extended
   validation certificates.

[hannes] s/Providers/providers
s/Users/users. 

2.6.  Request confidentiality

   The following data MUST be transmitted over secure transport (such as
   TLS) only:

[hannes] What about The following security sensitive data elements MUST NOT transmitted in clear: 
 access tokens, refresh tokens, resource owner passwords,
   authorization codes, and client secrets.

2.7.  Online Guessing Attacks

   Authorization servers MUST prevent guessing attacks on the following
   credentials: authorization codes, refresh tokens, resource owner
   passwords, and client secrets.

   When creating token handles or other secrets not intended for usage
   by human users, the authorization server MUST include a reasonable
   level of entropy in order to mitigate the risk of guessing attacks.

2.8.  Authorization code disclosure

   Confidentiality of authorization codes MUST be ensured on transport,
   even considering browser histories and HTTP referer headers.

   Authorization server as well as the client MUST ensure that
   authorization code transmission is protected by using transport-layer
   mechanisms such as TLS and that the duration of an authorization code
   is limited.

[hannes] Minor change: 
"
   The authorization server and the client MUST ensure that the 
   authorization code transmission is protected by using channel security, 
   such as TLS, and that the lifetime of the authorization code
   is limited.
"

   For web applications, authorization servers MUST authenticate the
   client and validate that the authorization code had been issued to
   the same client.

   For native applications, authorization servers MUST enforce one time
   usage of the authorization code.  Moreover, if an Authorization
   Server observes multiple attempts to redeem an authorization code,
   the Authorization Server MAY want to revoke all tokens granted based
   on the authorization code.

2.9.  Session Fixation

   The session fixation attack leverages the authorization code flow in
   an attempt to get another user to log-in and authorize access on
   behalf of the attacker.  The victim, seeing only a normal request
   from an expected application, approves the request.  The attacker
   then uses the victim's authorization to gain access to the
   information unknowingly authorized by the victim.

   In order to prevent such an attack, authorization servers MUST ensure
   that the redirect_uri used in the authorization flow is the same as
   the redirect_uri used to exchange the respective authorization code
   into tokens.  Authorization servers SHOULD require clients to pre-
   register their redirect_uri's and validate the actual redirect_uri
   against the pre-registered value.

[hannes] I think that this is what you want to say: 
"
The authorization server operators SHOULD require client application 
developers  to pre-register their redirect_uri's and validate the actual 
redirect_uri against the pre-registered value.
"

2.10.  Malicious client obtains authorization

   A malicious client could impersonate a valid client and obtain an
   access authorization that way.

[hannes] 
"
   A malicious client could impersonate as a valid client to obtain
   access to a protected resource. 
"

   Assumption: It is not the task of the authorization server to protect
   the end-user's device from malicious software.  This is the
   responsibility of the platform running on the particular device
   probably in cooperation with other components of the respective
   ecosystem (e.g. an application management infrastructure).  The sole
   responsibility of the authorization server is to control access to
   the end-user's resources living in resource servers and to prevent
   unauthorized access to them.  Based on this assumption, the following
   countermeasures are recommended.

   If the impersonated client is a web application, the authorization
   server MUST authentication the client.  

   [hannes] Write: 

"
In case of a client running as web application, the authorization
   server MUST authentication the client.  
"

The authorization server
   SHOULD require clients to pre-register their redirect_uri's and
   validate the actual redirect_uri against the pre-registered value.

   If the impersonated client is an native or JavaScript application,

[hannes] write: 

"In case of a client running as a native or JavaScript application,"

   the authorization server MUST utilize other means to achieve its
   security objectives.  The authorization server may enforce explicit
   user authentication or ask the end-user for consent.  In this
   context, the user shall be explained the purpose, scope, and duration
   of the authorization.  The authorization server must make the metat-
   data available to the end-user it associates with the particular
   client.  It is up to the user to validate the binding of this data to
   the particular application (e.g.  Name) and to approve the
   authorization request.

[hannes] Do you want to use RFC 2119 language in the above paragraph?
What meta-data are you talking about? 

   The authorization server MAY also limit the scope of tokens.

[hannes] Is MAY a bit weak here? In what cases would you say it is 
highly recommended to limit the scope. Would't you always want to do that? 

2.11.  Resource Owner Password Credentials

   The "Resource Owner Password Credentials" grant type is often used
   for legacy/migration reasons.  It has higher risk because it
   maintains the uid/password anti-pattern and the client could abuse
   the user id and password.  Additionally, because the user does not
   have control over the authorization process, clients using this grant
   type are not limited by scope, but instead have potentially the same
   capabilities as the user themselves.  The client could also acquire
   long-living tokens and pass them up to a attacker web service for
   further abuse.

   Authorization servers and application developers SHOULD minimize use
   of this grant types.  Other flows which facilitate user control and
   transparency should be used instead.

[hannes] This writeup essentially says "Please don't use it; it is completely insecure". 

   The authorization server SHOULD generally restrict the scope of
   access tokens issued by this flow.

   The authorization server MUST ensure the resource owners control and
   transparency with respect to all authorizations issued to clients.

2.12.  Authenticity of endpoints

   Authorization servers MUST support validation of endpoint
   authenticity using HTTPS server authentication.

[hannes] write: 

"
HTTPS with server-side authentication MUST be implemented and used by 
authorization servers in all exchanges.
"

   Application developers MUST validate the authorization server
   endpoint's authenticity and ensure proper handling of CA certificates
   as well as certificate chain validation.

[hannes] I am not sure what you want. Do you want the human (as the application developer to verify something) or do you want the application developer to write code that does certificate checking. Then, you may also want to perform authorization. 

---------------

Ciao
Hannes

On Mar 31, 2011, at 12:08 PM, Torsten Lodderstedt wrote:

> Hi all,
> 
> I just uploaded a proposal for the security section of the core spec to the IETF site (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-securityconsiderations/). 
> 
> As posted on the list previously, our idea was first to derive a security consideration section for the core spec by cutting down http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/  to a reasonable size. We tried to go through the document and identify the pieces that should go into the spec in the informal OAuth security session here at IETF-80. Although we did not make it further than 4.1.3, the meeting turned out to be valuable since we agreed on certain principles we are expected to apply when producing the section:
> - focus on service provider and application developers perspective (and the protocol implementation)
> - document the "what" and not the "why" - for "why" include informative reference to security document
> - explicitely state don'ts and explicitely define and distinguish three client categories (web, native, JavaScript)
> For example we had a really lengthy discussion about native apps, client secrets and client authentication - bottom line: we just state "Authorization server MUST NOT issue client secrets to installed or JavaScript applications."
> 
> Moreover, we agreed to produce a security considerations section as concise as possible and as quickly as possible. There were objections in the room to "just" cut down our document. Instead the proposal was to start something new.
> 
> So the proposed text focus on the "WHAT" and references http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ for a discussion of the "WHY".
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 31 Mar 2011 17:50:02 +0200

I just uploaded a revised version incorporating most comments we 
gathered today.

http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01

regards,
Torsten.
Am 31.03.2011 12:08, schrieb Torsten Lodderstedt:
> Hi all,
>
> I just uploaded a proposal for the security section of the core spec 
> to the IETF site 
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/  to 
> a reasonable size. We tried to go through the document and identify 
> the pieces that should go into the spec in the informal OAuth security 
> session here at IETF-80. Although we did not make it further than 
> 4.1.3, the meeting turned out to be valuable since we agreed on 
> certain principles we are expected to apply when producing the section:
> - document the "what" and not the "why" - for "why" include 
> informative reference to security document
> - explicitely state don'ts and explicitely define and distinguish 
> three client categories (web, native, JavaScript)
> For example we had a really lengthy discussion about native apps, 
> client secrets and client authentication - bottom line: we just state 
> concise as possible and as quickly as possible. There were objections 
> in the room to "just" cut down our document. Instead the proposal was 
> to start something new.
>
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ for 
> a discussion of the "WHY".
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mark Mcgloin <[email-masked]>
Date: Thu, 31 Mar 2011 17:01:49 +0100

Some comments Torsten. Will also think about missing considerations later

2.4.  Token Scope
I think this should be from the perspective of the Authorization server.
e.g.
When obtaining end user authorization and where the client requests scope,
the authorization server MAY want to consider whether to honour that scope
based on who/what the client is and the type of access grant or for
automated approvals etc

Why? If there are good reasons, then they need to be stated.

2.6.  Request confidentiality
What is secure transport? I think it should just state TLS or give some
examples if you are referring to something else
However , stating that authorization codes must be sent over TLS is still
being debated  wrt redirect_uri

2.12.  Authenticity of endpoints
I think I must be missing some subtleties of the statements in this section
as I don't understand. Is it just stating that both must be capable of
supporting TLS?

Mark McGloin

Torsten Lodderstedt <[email-masked]> wrote on 31/03/2011 11:08:05:

> Torsten Lodderstedt <[email-masked]>
> 31/03/2011 11:08
>
> To
>
> OAuth WG <[email-masked]>
>
> cc
>
> Phil Hunt <[email-masked]>, Mark Mcgloin/Ireland/IBM@IBMIE,
> Anthony Nadalin <[email-masked]>, Eran Hammer-Lahav
> <[email-masked]>, Hannes Tschofenig <[email-masked]>
>
> Subject
>
> Security Considerations Section Proposal
>
> Hi all,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 31 Mar 2011 18:12:04 +0200

Hi Mark,

thank you for your comments:

> based on who/what the client is and the type of access grant or for

The intention of the current text is to advice developers to apply the 
least-privileges pattern. I will add something wrt the authz server 
based on your proposal.

> Why? If there are good reasons, then they need to be stated.

Added some text in -01 (hopefully helpful :-))

> being debated  wrt redirect_uri

completly reformulated in -01

> as I don't understand. Is it just stating that both must be capable of

in the end, yes.
tried to make that more clear in -01

regards,
Torsten.

> Mark McGloin
>
>
> Torsten Lodderstedt<[email-masked]>  wrote on 31/03/2011 11:08:05:
>
>> Torsten Lodderstedt<[email-masked]>
>> 31/03/2011 11:08
>>
>> To
>>
>> OAuth WG<[email-masked]>
>>
>> cc
>>
>> Phil Hunt<[email-masked]>, Mark Mcgloin/Ireland/IBM@IBMIE,
>> Anthony Nadalin<[email-masked]>, Eran Hammer-Lahav
>> <[email-masked]>, Hannes Tschofenig<[email-masked]>
>>
>> Subject
>>