Re: [TLS] Review of PR #209

Geoffrey Keating <geoffk@geoffk.org> Tue, 22 September 2015 00:40 UTC

Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06251ACD9B for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 17:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 fNhmPz4QBCTH for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 17:40:04 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9781ACDF2 for <tls@ietf.org>; Mon, 21 Sep 2015 17:40:03 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 17A0A33D080; Tue, 22 Sep 2015 00:40:03 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com> <20150916153041.GA14682@LK-Perkele-VII> <CABkgnnVbJvFQ217Yq7eVLV+_cuQOUVoi1Ydixq5zBC9Zju1U-g@mail.gmail.com> <87eghugo9n.fsf@alice.fifthhorseman.net> <84975A12-87F7-4E5A-BC0D-0E0D68FEB2F1@inria.fr> <87613326ol.fsf@alice.fifthhorseman.net>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 21 Sep 2015 17:40:02 -0700
In-Reply-To: <87613326ol.fsf@alice.fifthhorseman.net>
Message-ID: <m2fv278exp.fsf@localhost.localdomain>
Lines: 31
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YzVC_HAMNbn7jNzv3ANR8j0yV8E>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Review of PR #209
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2015 00:40:06 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> Consider a server has an ongoing session wrapped in TLS that uses client
> authentication to approve or deny some requests from the client.  It
> remembers what requests the client has made as some sort of relevant
> state.  Let's take an imap server working with a client that has state
> of a "currently-examined folder", but this applies to servers and
> clients with much more complex state as well.
...

I think for such a protocol, you'd want to say that authentication is
not retroactive.

For other protocols, you might want something else.  For example, in a
protocol which uses client authentication for billing, you might want
to treat an authentication half-way through the session as the account
to bill for the entire session.

Some protocols will also want to support multiple identities, and some
will not.  For some protocols a new authentication might want to in
some fashion dis-trust previous authentications, other protocols might
say that all previous authentications are valid until the end of the
session.


I think this is something that TLS should allow higher-level protocols
to specify.  The TLS model could be that each client authentication
happens at a particular point in the session, breaking it up into
segments, and TLS informs the higher-level protocols of where the
segments start and end; it's up to the higher-level protocol to work
out what that means.