Subject: Re: [OAUTH-WG] draft 16 review notes

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 3 Jul 2011 20:21:43 -0700

From: Brian Eaton <[email-masked]<mailto:[email-masked]>>
Date: Sun, 22 May 2011 20:38:53 –0700

1.4.1 Authorization Code

maybe expand the section on important security benefits.  “The use of
authorization codes also improves the ability to recover in the event
of compromise of an application server or authorization server.”

Can you explain?

4.2.1 Authorization Request

Validation of the redirect_uri parameter is more important for the
implicit grant type.  Section 2.1.1 leaves registration of the
redirect URI as “SHOULD”.  It’s a “MUST” for the implicit flow.
Suggested language:

The authorization server validates the request to ensure all required
parameters are present and valid.  The authorization server MUST
verify that the redirect URI to which it will redirect the
authorization code matches a redirect URI pre-registered by the
client.  The authorization server SHOULD verify the scheme, authority,
and path of the redirect URI.  The authorization server MAY verify the
query parameters as well.

Changed it for now to:

    The authorization server validates the request to ensure all required parameters are
            present and valid.  The authorization server MUST verify that the redirect URI to which
            it will redirect the access token matches a redirect URI pre-registered by the client.
            The authorization server MUST verify the scheme, authority, and path components of the
            redirection URI and SHOULD verify the query and fragment components.

I'm still not happy with this and want something stronger.

4.3.2 Access Token Request

Really need language in here about the risk of brute force attacks on passwords.

How about:

            Since this access token request utilizes the resource owner's password, the
            authorization server MUST protect the endpoint against brute force attacks.

Section 10.  Security Considerations

There are various security risks mentioned in the OAuth WRAP security
considerations that seem worth mentioning here:

http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf

Care to extract and edit for inclusion?

Section 10.1 Client Authentication

nit: “MUST NOT issue client passwords to installed apps” is a dead
letter, it is not going to change standard industry practice in the
slightest.  The language from section 3 is more constructive.  I’d
suggest the following language for section 10.1 instead

“The authorization server MUST NOT assume that native or user-agent
based applications can maintain the confidentiality of client
secrets.”

That does conform with industry practice, so it’s more likely to be implemented.

Do we have consensus for this change?

Section 10.2 Client Impersonation

I like the content of this section, but it seems to mix several
different topics.

- general risks of native applications

- security considerations for “immediate mode”, where authorization
requests are processed without end-user interaction.

- validation rules for redirect URIs

- open redirectors

- access token design

Most of those merit separate discussion.

Need proposed text.

10.3  Access Token Credentials
“When using the implicit grant type, the access token credentials are
transmitted in the URI fragment, which can expose the credentials to
unauthorized parties.”

That’s basically FUD.  This should be made much more specific.  It
falls into the general category of security considerations for
redirectors and clients...

Need proposed text.

10.9 Authorization Codes

MUST be single use is a dead letter, because it requires atomic
operations at scale.  Even things like password changes are not atomic
in user databases of moderate size.  Authorization codes might be
generated quite frequently (e.g. when “immediate mode” flows are
used), so a MUST for an atomic operation is unrealistic.

Need proposed text.

EHL

---

From: Shane B Weeden <[email-masked]>
Date: Mon, 4 Jul 2011 14:22:46 +1000

From 4.2.1 below:

            The authorization server validates the request to ensure all
required parameters are
            present and valid.  The authorization server MUST verify that
the redirect URI to which
            it will redirect the access token matches a redirect URI
pre-registered by the client.
            The authorization server MUST verify the scheme, authority, and
path components of the
            redirection URI and SHOULD verify the query and fragment
components.

What does it mean for the authorization server to "verify the fragment
component"?

From:	Eran Hammer-Lahav <[email-masked]>
To:	Brian Eaton <[email-masked]>, "[email-masked]"
            <[email-masked]>
Date:	04-07-11 01:25 PM
Subject:	Re: [OAUTH-WG] draft 16 review notes
Sent by:	[email-masked]

From: Brian Eaton <[email-masked]>
Date: Sun, 22 May 2011 20:38:53 –0700

      1.4.1 Authorization Code

Can you explain?

      The authorization server validates the request to ensure all required
      parameters are present and valid.  The authorization server MUST
      verify that the redirect URI to which it will redirect the
      authorization code matches a redirect URI pre-registered by the
      client.  The authorization server SHOULD verify the scheme,
      authority,
      and path of the redirect URI.  The authorization server MAY verify
      the
      query parameters as well.

Changed it for now to:

    The authorization server validates the request to ensure all required
parameters are
            present and valid.  The authorization server MUST verify that
the redirect URI to which
            it will redirect the access token matches a redirect URI
pre-registered by the client.
            The authorization server MUST verify the scheme, authority, and
path components of the
            redirection URI and SHOULD verify the query and fragment
components.

      Really need language in here about the risk of brute force attacks on
      passwords.

How about:

            Since this access token request utilizes the resource owner's
password, the
            authorization server MUST protect the endpoint against brute
force attacks.

      That does conform with industry practice, so it’s more likely to be
      implemented.

      - open redirectors

      - access token design

Need proposed text.

Need proposed text.

      10.9 Authorization Codes

      operations at scale.  Even things like password changes are not
      atomic

Need proposed text.

EHL
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 3 Jul 2011 22:05:56 -0700

If a fragment was registered (or not) and if the authorization server policy require that any fragment provided in the callback matches a pre-reigstered value. Fragments, historically, were not very important and without any real security implications. However, with new browser-based applications, the fragment is used to maintain the application state and has the potential to be used to run code on the client by injecting it through a valid registered callback.

I'm ok with banning fragments completely, but what I much prefer and going to propose shortly is to require full, string-wise comparison of redirection URIs to their registered value. Clients can use the state parameter for any customization they need (and they can register multiple URIs). This seems like a much safer, and saner approach that doesn't take away any real functionality.

EHL

From: Shane Weeden <[email-masked]<mailto:[email-masked]>>
Date: Sun, 3 Jul 2011 21:22:46 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: Brian Eaton <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] draft 16 review notes

From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
To: Brian Eaton <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
            <[email-masked]<mailto:[email-masked]>>
Date: 04-07-11 01:25 PM
Subject: Re: [OAUTH-WG] draft 16 review notes
Sent by: [email-masked]<mailto:[email-masked]>

      1.4.1 Authorization Code

Can you explain?

Changed it for now to:

How about:

      - open redirectors

      - access token design

Need proposed text.

Need proposed text.

      10.9 Authorization Codes

Need proposed text.

EHL
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Jul 2011 12:16:28 -0400

> Need proposed text.
...
> Need proposed text.
...
> Need proposed text.

I will add to this that at this stage in the document development, any
requests for changes need to be accompanied by specific proposed text.
 If you absolutely can't come up with anything, you may make the
comment anyway and explain why you're at a loss for text, but realize
that the editors might not be able to incorporate your suggestion,
though they will try.

The editors plan to submit a -17 version this week, and when they do
we will start Working Group Last Call.  We will expect ALL suggestions
for changes to be specific about what text they propose.

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 12:05:26 -0700

As I go over recent feedback, anything that requires additional text will be bounced back to the list for new proposed language. I need to receive it by noon PT Thur, to be included in –17 (assuming no objections).

EHL

From: Barry Leiba <[email-masked]<mailto:[email-masked]>>
Date: Mon, 4 Jul 2011 09:16:28 -0700
To: OAuth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] draft 16 review notes

On Sun, Jul 3, 2011 at 11:21 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Need proposed text.
...
Need proposed text.
...
Need proposed text.

Barry, as chair