[OAUTH-WG] Minutes from the Conference Call (21th Jan. 2013)

[Hannes Tschofenig <[e-mail]>]

Here are the minutes from the call:
http://www.ietf.org/proceedings/interim/2013/01/21/oauth/minutes/minutes-interim-2013-oauth-2

Here are the uploaded slides: 
http://www.ietf.org/proceedings/interim/2013/01/21/oauth/slides/slides-interim-2013-oauth-2-0.ppt

----

OAuth Conference Call - 21th Jan 2013

Participants:
- Hannes Tschofenig
- Justin Richer
- Phil Hunt 
- Prateek Mishra
- Derek Atkins
- Mike Jones
- John Bradley
- Tony Nadalin
- Brian Campbell

Notes:

Hannes used the following slides for the meeting:
http://www.tschofenig.priv.at/OAuth2-Security-21Jan2013.ppt

As a first agenda item Justin explained two scenarios posted to the OAuth mailing list in response to the December 2012 conference call:
http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html 

The first scenario focused on the usage of a keyed message digest in HTTP (instead of using JSON). The second scenario was based on placing all MAC parameters into the URL (instead of the header). 

The participants indicated that further thinking about the inclusion of these scenarios is needed. 

A few clarification questions were raised including whether the solutions we are working on would require always a signature/keyed message computed over some portion of the request, and whether key distribution is within scope of the work or not.

Hannes clarified that the work is aiming to provide security properties beyond the bearer token and therefore the client needs to demonstrate possession of a session key. The available options for key distribution were described as part of the presentation slides. 

Q: What about clients that are either not capable of doing cryptographic operations (because they are computationally not powerful enough) or when they do not have access to keying material?

Hannes and Derek clarified that those scenarios are outside the scope of this work. 

As part of the different options for key distribution only Justin raised his preference for a solution that requires the RS to obtain the session key from the AS. 

The conference call participants agreed to focus on a symmetric key based solution and to postpone a solution offering support for asymmetric keys at a latter stage. 

Phil asked whether we really need both replay protection AND message signing?  

Hannes responded that support for replay protection has to be part of the solution. 

Regarding the lifetime of the session key the participants preferred to have it set to the same lifetime as the access token. If a new access token is obtained then the session key is also renewed.  

Regarding the naming of the keying material used in the protocol exchange there were some diverse views on what to use for the session key. Justin suggested that the name of the session key is the access token itself.