Re: [TLS] channel id and oob

Bodo Moeller <bmoeller@acm.org> Mon, 21 October 2013 23:27 UTC

Return-Path: <SRS0=g+Yl=T7=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9C811E82BB for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 16:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.626
X-Spam-Level:
X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T4oDnmWXoid for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 16:27:24 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DA11E827C for <tls@ietf.org>; Mon, 21 Oct 2013 16:27:17 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M4PCy-1VvPPL3DNk-00yhvj; Tue, 22 Oct 2013 01:27:16 +0200
Received: by mail-ie0-f179.google.com with SMTP id aq17so368432iec.24 for <tls@ietf.org>; Mon, 21 Oct 2013 16:27:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rnXRGiLFcMQ3GJjrjUirZp7fK06tkJoRio1T7SXNPr0=; b=WHdcgbZhjWiw38iyMr0Wu21bE+qiYN7PIJNToI49e40iJhDdu4lEeWThb45rIGNK/B ht8M3t/DDZtreh52Yc0E/xcT6TXvA8l4wydAZwLRf8uwCxrFXLeaLi1Zoh5O5D/wHUP+ Xb8chPyNxX4eCkZaRpMBsyQDY8j5WtgUiABXMvNWFNfFfiLLnEulhzf0HfOSAnpcTNX2 tAgbucZb/Lp1snofFS+tY1MnfQIv4rlth1WWQDZGMpGwxh+h3WtI6EEalvZz3+GMa9Ka nh9wg24Xi2gK5qgEwgRM968WFzSIPMdYJoCEjze8eQ+AgHZI+tnZGkNIs4kW01Sz7EYQ 1tPg==
MIME-Version: 1.0
X-Received: by 10.50.109.132 with SMTP id hs4mr11301575igb.34.1382398034452; Mon, 21 Oct 2013 16:27:14 -0700 (PDT)
Received: by 10.43.64.138 with HTTP; Mon, 21 Oct 2013 16:27:14 -0700 (PDT)
In-Reply-To: <CADHfa2AV31gs=WVrNQJ39NaenD2j4_0_nmE-vDzYGD2qu+E18A@mail.gmail.com>
References: <CADHfa2A7jERE=UTudOLcWnH7KppYH+7hcbRJg4aGZuwFeLBqnw@mail.gmail.com> <526123A7.5050305@gmx.net> <CADHfa2AV31gs=WVrNQJ39NaenD2j4_0_nmE-vDzYGD2qu+E18A@mail.gmail.com>
Date: Mon, 21 Oct 2013 19:27:14 -0400
Message-ID: <CADMpkc+=0K5pkYu_JdqzO9jFf1CWcqmZxGDe9fpUHRbrnVFeAw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Dirk Balfanz <balfanz@google.com>
Content-Type: multipart/alternative; boundary=089e013a1d90c82ff104e9489fbc
X-Provags-ID: V02:K0:6KnPXFmrVWrFA48bhGwHPKn2wDleDYXR/UmoEmHM/3T AsCvCjU5lZmINiVDZ4AuajKVXhzUK22weoX0gsGtPOodmDfQUe qfFrmJxEmJr6xolxo9nDobf0hRQqmch+eEmzLT67KSFUutu5bd 6QAvJXkow7KwviqpFnelPrZoEXupezUv8twCwpjdU4URFXBYtX hEGt4RH39SCBq5TlX8DMr8UWIbpSXsO6QLEmST/SH2WrcO4fQk UGwNbvpJBOgSq4/Oxd2NAUoB050biM07ups5zt0wDY7W9XJyoF NycqYLXubb7/ACgF0nKGA5GAceIJErxqUm38xHDPK0E+b0HXnK R9E2u02vfjgrYlqmmrLzNHiB3WYzuE9srHLpRCxpiEdn/2T5eF YYm12rrmydvWoADcH9GC92yvQ7JWghDFJ8xE73NqaOtcPPFrHg u9Wm5
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] channel id and oob
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 21 Oct 2013 23:28:16 -0000

> We actually don't say anything about keeping the key in session state nor
>> about session resumption. I consider those aspects implementation and
>> configuration issues.
>>
>
> That's interesting. I was looking for the part in the TLS spec that says
> "thou shall make client certs part of the session state", and indeed
> couldn't find it. But in practice, of course that is what people are doing,
> right? If your TLS terminators didn't make a client cert part of the
> session state, how could you ever resume a session with them and still be
> considered authenticated with that client cert?
>

In very basic usage of client certificates, a server might be configured to
only ever allow authenticated clients with certificates from a particular
CA to start sessions -- e.g., letting them access intranet content without
having to know which particular client each access is coming from.  In
simple cases like that, there's no need to keep certificate details around
in session state.