Subject: [OAUTH-WG] Interim meeting minutes/follow-ups/action items

From: "William J. Mills" <[email-masked]>
Date: Mon, 23 May 2011 21:49:53 -0700 (PDT)

-    Concern that 3 and 3.1 do not clearly show a way for a native client to provide client_id (to identify the client only) without doign authentication.

Proposed new text, insert in bold:  

    "In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client), when client authenitcation is not practical, or when the client identity is established via other means."

-    Last paragraph, section 3, proposed new text, reversing the order, putting "since ..." at the end of the sentence:

   The authorization server MUST require the use of a transport-layer security mechanism when sending requests to exchange an the token endpoint since requests using a method other than client password this authentication method result in the transmission of clear-text credentials.

-    3.1  edit first paragraph

Delete: "(the client identifier together with a shared symmetric secret secret)"

-    4.1.2.1.  Error Response  -- Character set for error_description 

becomes

         "OPTIONAL.  Human-readable UTF-8 encoded text providing additional information, used to assist to the developer in understanding the error that occurred."

-    4.1.2.1.  Error URI  -- "resource owner" becomes "developer"
 
error_uri
         OPTIONAL.  A URI identifying a human-readable web page with
         information about the error, used to provide the developer
         with additional information about the error.

-    4.1.2.1.  Error -- remove HTTP 4xx and 5xx error code as an allowed "error" value  
-    4.2.2.1.  Error Response -- ibid

This is considered a possible area for confusion between the HTTP error code and the error code returned in protocol.

TODO: Eran H-L to look at which HTTP error codes should be mapped in to protocol specific error codes.

-    10 Security considerations....

-    10.10 Session fixation...

Breno does not feel that session fixation is properly described nor dealt with.  

Igor is providing reference links to session fixation description (mail to the list).

TODO: [email-masked] is working on new draft language. 

-    10.13.  XSRF/CSRF Prevention

TODO: Breno and Bill M. working on new draft text.

-    9. Native applications

Objections that this recommends against things that are extant implementations.

TODO:  Chuck N. to draft revised text.

-    4.5 Extensibility 

TODO: Hannes will look at policy for using IETF URN

TODO: Mike J./Chuck N. to draft 4.5.1 subsection on assertions.  Clarifying the use case there and suggested behavior.

-    Proposed additions 
    -    "Immediate Mode" with display= and response=
    -    response_type={none, cookie}

TODO: Paul T. to send proposed requirements to the list.

TODO: Eran to add extensibilty language for this based on requirements.

-    "RedirectURI" should be optional

TODO: Eran to send mail to the list proposing language changes to either change this from REQUIRED to OPTIONAL and add clarifying language, or leave as required and add a pre-defined value for "we're not actually using this".

-    4.3 (and 3.1) Username/Password

Need to figure out what the encoding will be here, since these can be outside the ascii charset.

TODO: Peter St.A to review the language.

-    Discussion on client credentials -- Tony Nadalin.

TODO: Tony N./Chuck N.  to propose new spec to handle assertions both for authentication and authorization.

========================
Moving on to BEARER TOKENS
========================

MIke J. reviewing changes in Draft 5.

-    2. Authenticated requests

Discussed possible language change and oped for no change.

-    400 vs 401 return

TODO: Mike Jones to follow up with HTTP WG or representatives and ask whether there are objections.

NOTE:  Mark Nottingham (in the HTTP community says that either 400 or 401 are acceptible in most cases.

-    can we move from 403 to 401?

Eran's statement is that 403 is sematically correct in HTTP.  Probably true.

========================
Moving on to MAC TOKENS
========================

Eran ran through the current status.

Only significant issue at this time is body hash.  Seems to be a thorny issue, he is looking for actual implementer experience.

========================
Moving on to SAML
========================

Brian Campbell: No recent feedback on the list.  Not sure whether that's good or just no attentionon SAML.

========================
Move to adjourn...  Adjourned.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 24 May 2011 09:12:34 +0200

Hi all,

> Breno does not feel that session fixation is properly described nor  

Breno is right. The threat that shall be prevented here is described  
in the security threat document  
(http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.7, enhanced description in https://github.com/tlodderstedt/oauth2/raw/master/draft-lodderstedt-oauth-security.html). Here the attacker obtains a victim's authorization code by redirecting the flow to its own faked website. It then injects this code into his authorization process with the same service provider. This is obviously _not_ the classical session fixation where an attacker sets up a session and tricks the victim in upgrading/enhancing/personalizing this session in order to abuse the victim's privileges. I suggest to change the name of the attack/section to something like "authorization code theft ..." and to add a section about session  
fixation.

> TODO: Breno and Bill M. working on new draft text.

Isn't the countermeasure for both session fixation and XSRF the same  
(state)? In my opionion, the difference is:
session fixation: get access to a victim's data in service A using the  
attackers account at service B.
XSRF: get access to to a victim's data at a service A using the  
attacker's identity with an identity provider

Please not: Mark McGloin is already working on text regarding XSRF.

> Objections that this recommends against things that are extant  

Would you please give examples?

regards,
Torsten.