Minutes for OAUTH at interim-2013-oauth-1
minutes-interim-2013-oauth-1-1

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.