Return-Path: 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 9C7BC12945C for ; Wed, 11 Jan 2017 13:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 HdUM9h_MkkVp for ; Wed, 11 Jan 2017 13:01:25 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 CA0D912985F for ; Wed, 11 Jan 2017 13:01:25 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id l66so3225863ioi.1 for ; Wed, 11 Jan 2017 13:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DjB4Q8Lmx3XiVntIKdOD+CRVGjQoR8XGeVIqyZZbjtM=; b=M9H0lpwJARoQi7orsxmn0xNHgjMfnxAdviILEzwXpr/6DHDzYtVi0qmHtJY0OvbHl2 mxrO4WLFIAJerhf7P+CIQiaB9ZAFojV72bbrF3uHj5yetFQRfNXIMfTWMboqB/3ylwwH gFYUOelX9KK7prIigtOnRny3HJim8iU1Gh1BY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DjB4Q8Lmx3XiVntIKdOD+CRVGjQoR8XGeVIqyZZbjtM=; b=I0GJerMkuTprxuLCiR40JQ14pbXgxTZCgKlpZPe9U+t/dnDo6EtjQTRV3NMzKWtwGE FJyV0yf9MO3q4qtmzgeNLL3auWH6CDsmBLFEim+kRhcb79Pps1dfnOegz2doCbnXHQ8l Nkn/y8JnvziLbWmiiE527mMZAVAgFlhw9TlH47kvCtExNzYNUI7PzfM/LR/aC4P9hDFr e/iYpLrvBokd+UDCuun4ilShCJ6t10JJJfXX6Corrn6lz7Wrl4DF4fvbteih35w5g/u2 fBxGFBZkpHNZ6xe4BpGnh1JT+64VzF2mAl0rNqp0jofpHzLD3j+6iU2Re7vEomr8wS99 SM1Q== X-Gm-Message-State: AIkVDXItdh0SXlHwD8zFwrrjqqCDf6d5nWj/U/YhJv7AQQeH+lTLoW15ofpoYKUU1DGI8NnUlDgyQnU2tsQ13Yiq X-Received: by 10.107.161.83 with SMTP id k80mr9788062ioe.47.1484168485080; Wed, 11 Jan 2017 13:01:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.5 with HTTP; Wed, 11 Jan 2017 13:00:54 -0800 (PST) In-Reply-To: References: <148416636025.8139.11121446658834117013.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 11 Jan 2017 14:00:54 -0700 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a1140fd3c5744a30545d7e7a0 Archived-At: Subject: [Unbearable] Fwd: New Version Notification for draft-campbell-tokbind-tls-term-00.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:01:27 -0000 --001a1140fd3c5744a30545d7e7a0 Content-Type: text/plain; charset=UTF-8 Hi Unbearable Folks, I've uploaded the below individual draft, which is an initial attempt at describing how Token Binding would work with HTTP applications behind TLS terminating reverse proxies. This is the document that at end of the meeting in Seoul I said I was going to work on. But despite it taking me a long time to write, it isn't very long so should be an easy and quick read. Feedback is of course welcome. Thanks, Brian ---------- Forwarded message ---------- From: Date: Wed, Jan 11, 2017 at 1:26 PM Subject: New Version Notification for draft-campbell-tokbind-tls-term-00.txt A new version of I-D, draft-campbell-tokbind-tls-term-00.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-campbell-tokbind-tls-term Revision: 00 Title: HTTPS Token Binding and TLS Terminating Reverse Proxies Document date: 2017-01-11 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-campbell-tokbind- tls-term-00.txt Status: https://datatracker.ietf.org/doc/draft-campbell-tokbind-tls -term/ Htmlized: https://tools.ietf.org/html/draft-campbell-tokbind-tls-term -00 Abstract: This document defines an HTTP header field that enables a TLS terminating reverse proxy to convey the information a backend server needs in order for it to process and validate a Token Binding Message sent by the client. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a1140fd3c5744a30545d7e7a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Unbearable Folks,

I've uploaded th= e below individual draft, which is an initial attempt at describing how Tok= en Binding would work with HTTP applications behind TLS terminating reverse= proxies. This is the document that at end of the meeting in Seoul I said I= was going to work on. But despite it taking me a long time to write, it is= n't very long so should be an easy and quick read. Feedback is of cours= e welcome.

Thanks,
Brian


<= div>

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date:= Wed, Jan 11, 2017 at 1:26 PM
Subject: New Version Notification for draf= t-campbell-tokbind-tls-term-00.txt



A new version of I-D, draft-campbell-tokbind-tls-term-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-tokbind-tls-te= rm
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTPS Token Binding and TLS Termin= ating Reverse Proxies
Document date:=C2=A0 2017-01-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-campbe= ll-tokbind-tls-term-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-tokbind-tls= -term/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-campbell-tokbind-tls-term-00<= br>

Abstract:
=C2=A0 =C2=A0This document defines an HTTP header field that enables a TLS<= br> =C2=A0 =C2=A0terminating reverse proxy to convey the information a backend = server
=C2=A0 =C2=A0needs in order for it to process and validate a Token Binding = Message
=C2=A0 =C2=A0sent by the client.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--001a1140fd3c5744a30545d7e7a0--