Minutes for OAUTH at interim-2013-oauth-1
Web Authorization Protocol
||Minutes for OAUTH at interim-2013-oauth-1
OAuth Conference Call - 11th Jan 2013
- Bill Mills
- Hannes Tschofenig
- Justin Richer
- Phil Hunt
- Prateek Mishra
- Derek Atkins
- Mike Jones
- George Fletcher
- John Bradley
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.