Re: [TLS] channel id and oob

mrex@sap.com (Martin Rex) Tue, 22 October 2013 00:28 UTC

Return-Path: <mrex@sap.com>
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 C2CE711E87A3 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 17:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.059
X-Spam-Level:
X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 ptGm8o5DjHBU for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 17:28:50 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 498FD11E85CE for <tls@ietf.org>; Mon, 21 Oct 2013 17:28:40 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r9M0Sb7d025753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Oct 2013 02:28:37 +0200 (MEST)
In-Reply-To: <CADHfa2AV31gs=WVrNQJ39NaenD2j4_0_nmE-vDzYGD2qu+E18A@mail.gmail.com>
To: Dirk Balfanz <balfanz@google.com>
Date: Tue, 22 Oct 2013 02:28:36 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131022002836.9CBCA1AA15@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
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
Reply-To: mrex@sap.com
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: Tue, 22 Oct 2013 00:28:55 -0000

Dirk Balfanz wrote:
> 
> When your TLS terminators resume a session with a client - what do those
> terminators tell their backends about the session? If the client proved
> possession of a private key/certificate during the original handshake, so
> terminators not tell their backends about that key on a resumed session?

Reverse Proxies will normally forward the authenticated client cert
PLUS any chain certificates that were received and successfully verified
during the full handshake to the backend.

Clients will normally also cache the Server certificate plus the entire
chain in the client side session cache.  Every reasonably portable and
generic TLS protocol implementation is likely going to include that
information in its SSL session cache.  Applications may not necesserily
know nor care whether the TLS handshake was a full handshake or
abbreviated handshake (aka session resume).


> 
> 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?

Session caching simply would not make any sense without caching
most of the attributes that were successfully established or successfully
negotiated during the full TLS handshake.  I do not see a difference
between the client caching the server's certificate chain and the
server caching the client's certificate chain.


> 
> Yeah, I'm a bit confused about this. I was a bit surprised to not find more
> explicit mention of what it means to resume a session in the TLS spec.

TLS is underspecified in a lot of places.  You may remember the result
of renegotiation being underspecified. A security problem that remained
unnoticed for ~13 years.


>
> Clearly, a resumed session (from the server's point of view) means "the guy
> on the other end knows the same master secret as I do". But in practice it
> also means "the guy on the other side wields the private key corresponding
> to this certain public key", if that's what was proven during the initial
> handshake.

Each peer only knows that the peer was able to perform a proof-of-posession
during the full TLS handshake.  It would be unwise to make any assumptions
about the posession of a private key for any point in time, much less any
later points in time, independent of whether the original TLS
connection has been running for a few hours, or whether this is about
a newly established TLS connection that has just been resumed from
the TLS session cache, with the original TLS handshake a few hours
in the past.

The certificate path validation (in particular when revocation checking
from remote information sources is performed) may be in the same ballpark
that the full handshake crypto operations, so typically, there is not
going to be a certificate path validation on session resume.


-Martin