Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Cas Cremers <cas.cremers@cs.ox.ac.uk> Wed, 15 February 2017 12:03 UTC

Return-Path: <cas.cremers@gmail.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 BBFCE12952F for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 04:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ng-h5tf15K0T for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 04:03:01 -0800 (PST)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0072C129440 for <tls@ietf.org>; Wed, 15 Feb 2017 04:03:00 -0800 (PST)
Received: by mail-wr0-x236.google.com with SMTP id k90so189036245wrc.3 for <tls@ietf.org>; Wed, 15 Feb 2017 04:03:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L6YInpvokZSe7qFnMVR4+xgfbEVmtKMNYFxlAo4WfTs=; b=U8KLJAwcVyHibBd4Tdopq8kpo+9jDjbw2UheOZ4oQgIywBG0/2O6dS3MKBSwKvVc0S LCF0jon/pKNZTxmVhN9q3WeLwSb8smZbM/CKkHxN9eSiPD2MuDAthKBsvOn74v3UUteB kGfjh5IcQ2Xlesz2+PaU2YV/3uhJ5O4gpamBeKZ+UWlHl3VR0mFmw8HfKD/dX25GmAoX 7xXJWyHr32lt7x7slN3H0bhDCMN1hy874syJe4YcFXFBvg2XrH7a0Phf7Tzb5kaHUMM1 O1E5xRTZT8neQ8Ic9i2HTBRixEtbTPxiAPZvS5AUSAOUaoR982ri5iES51YlhcKIvuPm LUqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=L6YInpvokZSe7qFnMVR4+xgfbEVmtKMNYFxlAo4WfTs=; b=U5Roj7SaHfvM4nmDbesiJcJkVx/KaxmH8QOP0PS3SFxF+AWvARBaZ3ecoDLq7mqvZy q4u0cUxShczvGxiR1L9kHCA6ZMy5i0W5Rk7iq8SxbXl/bPBUclNh35Hot5/SRs92dtJf Pb9tVK5PAJ95AMVU87LusQn+Agu/119qiSY14aP3afgfALzlNxcJ5kfi4sWAcHKfEvV1 RjXvgGy9zcPlAx4n9YnrkTSHrje1kQNLBMzzaecLGKBQQnpZgWpumhLgY1giKd5VcdyW +0Ekcsf02RIc1k2N+bxBVUKIvq9wH3RfdI/JGyvXDjvFuuz+WL2LfJPq/zU6TTqve9um jjQQ==
X-Gm-Message-State: AMke39lDyFKhSgrmO5CdKKyaoGFTD0xYDJiiyTUNRd2JNBLzveDNgwe9HFWyoRcuWnTseCoeLnG+bTH5vmmwLA==
X-Received: by 10.223.139.220 with SMTP id w28mr30337439wra.172.1487160179310; Wed, 15 Feb 2017 04:02:59 -0800 (PST)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.80.138.100 with HTTP; Wed, 15 Feb 2017 04:02:38 -0800 (PST)
In-Reply-To: <20170215110029.C64081A623@ld9781.wdf.sap.corp>
References: <CY1PR0301MB08426CD005E640B9865D1BC38C580@CY1PR0301MB0842.namprd03.prod.outlook.com> <20170215110029.C64081A623@ld9781.wdf.sap.corp>
From: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Date: Wed, 15 Feb 2017 12:02:38 +0000
X-Google-Sender-Auth: VPDtS-MbjwJQQ3C6Wckg1ZsBA0w
Message-ID: <CABdrxL7+t2daeg+-xqmn9HP0=ZYVmFQH4vN5GaJDZ05=VKFSfg@mail.gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="f403045ea69e364bf3054890765a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/j0WfTRWLbt4shPE4eQST3ANrJrw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 15 Feb 2017 12:03:02 -0000

Hi,

I think the idea that "this is the best we can do" depends on quite a
number of assumptions. In theory, I think it is easy to fix, but of course
in the design space we're in, the trade offs are more complex.

We also have to consider the non-web use cases where one might expect more
symmetric guarantees between client and server.

Indeed, "principle of least surprise": I personally find this lack of
agreement for the client surprising, i.e., the fact that the client it is
not informed by the server on its authentication status, especially since
the server asked for the certificate in the first place. This is even the
case if the server doesn't implement the reject-cert-but-continue option,
for the post-handshake authentication.

I can imagine applications that depend on the assumption that the client
knows that it has been authenticated, to both decide what it should send,
or to correctly interpret what it is receiving.

To me, this means we need to at least document this. We'll draft a PR.

Best,

Cas





On Wed, Feb 15, 2017 at 11:00 AM, Martin Rex <mrex@sap.com> wrote:

> I think the issue is more about the "principle of least surprise".
>
> The client needs to know whether it offered authentication by client cert
> and which client cert it offered.  Whether the server accepted it, and
> caches the accepted cert in the session or in a session ticket, is
> the business of the server (it may help in troubleshooting to know,
> but should not be necessary for application flow control).
>
> Clients asserting multiple identities sounds extremely awkward to me.
>
> We do have clients in posession of multiple client certs, but our
> application
> must specify _before_ each TLS handshake which client identity to use (and
> this information is necessary for client-side session caching,
> and client-side session lookup.
>
> There is a significant difference between cached sessions where a
> specific client cert was used (or at least offered by the client),
> and cached sessions where no client cert was offered.
>
> If a client tries to access a resource through a session that is
> authenticated with SSL client cert A, and the server-side authorization
> decision denies access to client cert A, then this will typically
> result in an access failure, _without_ the server asking for a different
> cert.
>
> When no client cert has been used in a session then access to a resource
> that requires a (particular) client cert may result in a request of the
> server for a client cert (renegotiation up to TLSv1.2) after seeing the
> request--provided that the server supports renegotiation.
>
>
> -Martin
>
>
>
> Andrei Popov wrote:
> >
> > Is it important for the client to know, from the TLS stack itself,
> > whether client authentication succeeded or not? My assumption
> > (perhaps incorrect) has been that it is the server that cares about
> > the client's identity (or identities) in order to make an
> > authorization decision.
> >
> > This thread also seems to consider client authentication a binary state:
> > the client is either authenticated, or not. In practice, the client may
> > assert multiple identities, and the server may grant various levels
> > of access.
> >
> > Also, why should the client care whether session ticket X includes client
> > identity Y? If a client resumes a TLS session with a session ticket that
> > does not include (or point to) a client authenticator needed to satisfy
> > the client's request, the server can initiate client auth (or deny the
> > request).
> >
> > Cheers,
> >
> > Andrei
>