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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sat, 19 January 2013 16:19 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A743221F85DB for <oauth@ietfa.amsl.com>; Sat, 19 Jan 2013 08:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.306
X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XrrcNf8VIKyD for <oauth@ietfa.amsl.com>; Sat, 19 Jan 2013 08:19:51 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D221F8610 for <oauth@ietf.org>; Sat, 19 Jan 2013 08:19:45 -0800 (PST)
Received: from mailout-de.gmx.net ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MgJFg-1Tb5ks1S3q-00Nk3y for <oauth@ietf.org>; Sat, 19 Jan 2013 17:19:44 +0100
Received: (qmail invoked by alias); 19 Jan 2013 16:19:44 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO []) [] by mail.gmx.net (mp017) with SMTP; 19 Jan 2013 17:19:44 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18MOJgV/8sMjFtLQwpa2kVnZA+zRZP+CmJXjdanZB D6mD7FB8y9DGV5
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 19 Jan 2013 18:19:43 +0200
Message-Id: <20D098C4-46EB-483F-B656-C9D7236F843A@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Minutes from the Conference Call (11th Jan. 2013)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jan 2013 16:19:52 -0000

Hi all, 

here are the minutes from the recent conference call:


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:

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. 


Feedback on my notes are appreciated. Maybe someone was able to take more detailed notes during the call. 

I have also uploaded them to the meeting materials page: