[Unbearable] Comments on draft-campbell-tokbind-tls-term

Piotr Sikora <piotrsikora@google.com> Mon, 27 March 2017 19:36 UTC

Return-Path: <piotrsikora@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E2912949A for <unbearable@ietfa.amsl.com>; Mon, 27 Mar 2017 12:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 a9Nn-chHfdj9 for <unbearable@ietfa.amsl.com>; Mon, 27 Mar 2017 12:36:15 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 BF405128CB9 for <unbearable@ietf.org>; Mon, 27 Mar 2017 12:36:14 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id l43so72204224wre.1 for <unbearable@ietf.org>; Mon, 27 Mar 2017 12:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UfI6RAgPOc1HK5NhsAQ+zAdk46H5qqksgvU3ZRCX1Hs=; b=lSBS/Vs89e5lkuvGqzmtyhZe1aHrFw6ux93jmcyp1pe0dOz5ur4h5lf+7W4w46RFjR jYL5IrLhPkBwopB7Z9oiB7zD3DrpPGX9rJx2kQ+8R9pXh2Eek841hvtreg2K6KD9ZDf2 osnRe0KoeGXsNFbkGF1Z5wMsvB8oZORLW9f00XmJMReo7mBo7FILKYBkxyy3QGwOkmsA BDZA0V2L7cj6gvP6yAwH/iixVMwir4FTBjMsm2GSJIcV7vqeyEtw++5SJsQWBiRXPvnT kii48vG9IBzlGRPs9Xl0MqzRQg4UnVnfyMhClAR/53DqdDC2l1t1gRXwWQsE0UNw8Co0 gLvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UfI6RAgPOc1HK5NhsAQ+zAdk46H5qqksgvU3ZRCX1Hs=; b=OXhU1voqxhNSNCerdWTlBWl3bDhRn8T3CT2bfAB8SFISqToL5gDGU1NexZ07M4l4Do tRcAe10YnTsUxpZt9GEzk4gO1WtBYFCcsmApXWRBXK7WUxs8MF8Pbl1FTIFdh1uX6niX zKnWVaMP6FpAJkJGhVDj6clrbRdK5XpxMf7d7jLndp33LVMt6Tlf9ej2+bcpsr2xfou5 n7j9y9XCwbOCXghi62rkBOqW/BjErA/c92CUWSYRHIJwVFaxjuqrROoh0NlTrIKjyjpU PFKwOJCpLJleq76Z8s6lKMyKbLem7JsG88vUInBmzJ+Qk0g285sk+g6sIR76DLK1x9ns wwxw==
X-Gm-Message-State: AFeK/H2SdDvxLXTpM/HQdianqxtOd9yUgHZS+x3yYQ/LGZO181Db4FIvqKmtcNOJfg4wgAvjl6kmzRZ+8L8UwP+V
X-Received: by 10.223.167.66 with SMTP id e2mr21303698wrd.48.1490643373088; Mon, 27 Mar 2017 12:36:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.168.85 with HTTP; Mon, 27 Mar 2017 12:36:12 -0700 (PDT)
From: Piotr Sikora <piotrsikora@google.com>
Date: Mon, 27 Mar 2017 14:36:12 -0500
Message-ID: <CAF-CG++MXAgE+E93fRLrOM2pgeTaqXGmbV6-ORXLAzEEq9qdYA@mail.gmail.com>
To: Tokbind WG <unbearable@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/6fTPRk4YRXfUFDBINX-9xb7OeZg>
Subject: [Unbearable] Comments on draft-campbell-tokbind-tls-term
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 19:36:17 -0000

Hey,
I'm a bit late to the party, so apologies if this was already discussed.

>   A backend server that receives a request from a trusted reverse proxy
>   containing the "Token-Binding-Context" and "Sec-Token-Binding"
>   headers decodes the Token Binding Context Message and uses its
>   content to validate the encoded Token Binding Message as described in
>   Section 2 of Token Binding over HTTP [I-D.ietf-tokbind-https] in
>   place of information that otherwise would have come from the TLS
>   connection.

What's the value of sending both to the backend server instead of
validating the Token Binding Message at the reverse proxy and passing
only Token Binding ID (in one form or another) to the backend server?
Especially, since the Token Binding Message must (should?) be
validated by the TLS terminating reverse proxy anyway.

Also, re-using "Sec-Token-Binding" header doesn't allow Token Binding
to be established between reverse proxy and backend server...
Actually, it doesn't allow TLS between reverse proxy and backend
server, since backend server should reject such connection, if Token
Binding protocol wasn't negotiated during TLS handshake.

>   The Token Binding Context Message is a byte sequence that contains
>   the concatenation of the negotiated Token Binding Protocol Version
>   and Key Parameters as well as the exported keying material (EKM) from
>   the TLS connection between the client and reverse proxy.  The first
>   two bytes are the ProtocolVersion, as defined in Section 2 of
>   [I-D.ietf-tokbind-negotiation], that the reverse proxy negotiated
>   with the client.  The third byte is the negotiated
>   TokenBindingKeyParameters (also defined in Section 2 of
>   [I-D.ietf-tokbind-negotiation]).  The remaining 32 or more bytes are
>   the EKM from the TLS connection between the client and the reverse
>   proxy, as defined in Section 3.3 of [I-D.ietf-tokbind-protocol].

Following from the previous comment, why all this information needs to
be passed to the backend server? Wouldn't base64url-encoded Token
Binding ID (or SHA256 hash of it) be good enough?

Best regards,
Piotr Sikora