Re: New Non-WG Mailing List: unbearable

Nico Williams <nico@cryptonector.com> Tue, 09 December 2014 17:29 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B741A8972; Tue, 9 Dec 2014 09:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMEZ-wXgnCzx; Tue, 9 Dec 2014 09:29:31 -0800 (PST)
Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 821A91A87E9; Tue, 9 Dec 2014 09:29:26 -0800 (PST)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 5E8A327BC065; Tue, 9 Dec 2014 09:29:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=DOzzSorW/aMmIW WR1+qEP4eWy7g=; b=cQ3afz66CKujKuN/hgTGuZV7v9pl5P28ymO8jH5e1V98hk pNshZSlgvGwe1gIsIH9WTxVLm1laAC+VvAsYU2QUtbO3OceAKDsqKad0l7fD91bt 0Ll656bJ2e6Hq3pfmB1Czw4EV57PRmudHoxJRiwLRDvntc0eXM+kr5Xa6jenk=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id E19D027BC064; Tue, 9 Dec 2014 09:29:25 -0800 (PST)
Date: Tue, 09 Dec 2014 11:29:25 -0600
From: Nico Williams <nico@cryptonector.com>
To: Derek Atkins <derek@ihtfp.com>
Subject: Re: New Non-WG Mailing List: unbearable
Message-ID: <20141209172920.GC12979@localhost>
References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> <sjmtx18ziux.fsf@securerf.ihtfp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <sjmtx18ziux.fsf@securerf.ihtfp.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Q42J7JZQ23Z8PkEF860RLnFdbN4
Cc: unbearable@ietf.org, Andrei.Popov@microsoft.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 17:29:33 -0000

On Sat, Dec 06, 2014 at 02:19:34PM -0500, Derek Atkins wrote:
> The OAUTH Working Group is already (and has been for a while!) looking
> into "holder of key" protocols to improve upon Bearer Tokens.
> 
> I would suggest that this work happen there instead of creating a whole
> new group for it.

That's very interesting.

Key confirmation protocols will tend to all look... roughly similar: a
synchronous exchange of "messages" (with cryptographic elements, of
course) between a "client" and a "server" (with perhaps infrastructure
message in the background) until one, the other, or both peers are
authenticated to the other, or the authentication fails.

If you can have keys at all, you can also have session keys, though for
HTTP.. until we get something better than web cookies for session
continuation, having session keys is hardly critical.

Anyways, there's a reason I mention this: we already have several
protocols that look like this, so new not-just-bearer-anymore bearer
token extensions have literature to look at.

A brief list of such protocols that might be useful for lessons to
good, bad, and ugly: TLS, SASL (and various mechanisms), GSS-API (and
various mechanisms), Kerberos V5, IKEv1 and IKEv2, ...

Of those, these tend to have actual APIs in the wild that might be
useful too: TLS (ad-hoc APIs), SASL (ad-hoc APIs), GSS (standard APIs),
Kerberos (ad-hoc APIs), IKEv* (PF_KEY -- a standardish socket API).

I'm not sure which lessons OAuth and others going down this path should
take.  I'll try to think of some so as to save the authors the time of
having to digest all this material.  I suggest others also do this.

Nico
--