OAuth Conference Call - 11th Jan 2013

Participants:
- Bill Mills
- Hannes Tschofenig
- Justin Richer
- Phil Hunt 
- Prateek Mishra
- Derek Atkins
- Mike Jones
- George Fletcher
- John Bradley

Notes:

The slides for the meeting, which are based on the requirements in http://tools.ietf.org/html/draft-tschofenig-oauth-security-01#section-5, can be found here:
http://www.tschofenig.priv.at/OAuth2-Security-11Jan2013.ppt

The discussion started with the requirement for "Cryptographic Algorithm Independence" (or also called crypto agility), which states that "The key management protocol MUST be cryptographic algorithm independent.". There are at least two types of algorithms in the OAuth framework, namely: 

 1) The access token must be cryptographically protected against modifications and may contain the session key encrypted with a key only known to the resource server and the authorization server. The authorization server needs to use an algorithm that is also supported by the resource server to perform the cryptographic computations. 
 
 2) When the client interacts with the resource server and provides the access token it needs to demonstrate the possession of a key by using a keyed message digest or a digital signature computed over the request. Different algorithms may be used by the client and the algorithm selected must be supported by the resource server. For example, a client may be using a HMAC-SHA1-160 keyed message digest computed over selected header fields of the request and the resource server needs to support the same cryptographic algorithm. The notion of an algorithm may, however, also refer to a different credential being supported (asymmetric keys vs. symmetric keys), or an entirely different specification (HOTK vs. the MAC token, for example).

The participants discussed whether the requirement implies a run-time algorithm negotiation or rather an indication of the algorithms as part of the discovery procedure / dynamic client registration. 

In case of the discovery exchange, which happens prior to the protocol exchange between the client and the authorization server, the client learns (for example via WebFinger) what algorithms the resource server supports. For the case of dynamic client registration it was suggested that the client id is used to associate the supported algorithms to a specific client and that any indication of the algorithms during the OAuth protocol exchange are therefore not needed. In that case the client-supported algorithms are implicitly known to the authorization server based on the client id. 

There was also the recommendation to support cases where the AS does not know anything about the resource server. It was not clear how the resource server would be able to obtain the required session key in this case. It was also noted that the current OAuth base specification does not allow the client to convey information about what resource server it wants to interact with. This information would, however, be needed by the authorization server to determine the algorithms supported by the resource server and to encrypt a session key. 
 
No conclusion was reached on how much flexibility is needed nor at what part of the exchange the algorithm indication / negotiation should be take place. Justin even suggested that the topic of crypto-agility is orthogonal to the discussion of enhanced bearer token security.