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 --
- Re: New Non-WG Mailing List: unbearable John C Klensin
- Re: New Non-WG Mailing List: unbearable Derek Atkins
- RE: [Unbearable] New Non-WG Mailing List: unbeara… Mike Jones
- Re: [Unbearable] New Non-WG Mailing List: unbeara… Stephen Farrell
- Re: [Unbearable] New Non-WG Mailing List: unbeara… Phil Hunt
- Re: [Unbearable] New Non-WG Mailing List: unbeara… John Bradley
- Re: New Non-WG Mailing List: unbearable Nico Williams
- Re: New Non-WG Mailing List: unbearable Nico Williams
- Re: New Non-WG Mailing List: unbearable John C Klensin
- Re: New Non-WG Mailing List: unbearable Douglas Otis