From nobody Tue Feb 2 15:50:40 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C1D1A90DF for ; Tue, 2 Feb 2016 15:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 FU0g2PRdDKt0 for ; Tue, 2 Feb 2016 15:50:29 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 3A6EF1A90D5 for ; Tue, 2 Feb 2016 15:50:29 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id s5so2157803qkd.0 for ; Tue, 02 Feb 2016 15:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=TqaALnfyv1l+QpK2i50TwtUYj+z2zuCKEocUO7xQw9A=; b=TC2ZFsywgq2cMLxJ5Oart2PKnjrd2owYD6PZNpK8J9cuLrUjSqOd7BOpSqULnDho/r aiFCTLup64+qn9oqaL1yWHJs9tCmQ2Lgs+eFmXUko+XtgtrQWWzCzrO8BTJgHRBMK2Ap XraQYTVRl/l3mDgIoTnSke+o8qXD/kQmvyXX2wH4SosL45HF0iyBT+vPzroarJJyyXkM zzi5VZs/UOaNorgwb5IsTlALsCF+lqz09X6P/Ma5ntVp2XWEW1PhHKYCuluM12cmW1yG Y0HEjstfpiGiDxn8/GPIFhIqvtKpl1ghwU8u8pWBtviev4HuQyZtcIj5FitzFVpeNiVG 232w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=TqaALnfyv1l+QpK2i50TwtUYj+z2zuCKEocUO7xQw9A=; b=S7mKW2iQj8smVCUZfipl7LBp68AqFY0aszZu/kV8zBPy175mBS0geTAxa3166qJjZo dAUQgNflvQ+1CQ6Ezw6gZrG0Lq7oCLkThORn+8WKsK/pfVP7YJ31p5SA5061Oey3FH3A FrKme94YH6X5WbsceDonTF4hfsc9cx63p90IvhTD7TAy9dfoo4qKPDHf8oMs/ezVw/nd pzaihX69AAuAcE1BwIuacuFuUeC7yKjvOuWdk7XeRNma21hu6/3PXxF2rUSeUqWUKkMB C7IKbNrJUJ+/OJgIsWmXUGCUOxtqZvFaYz+AnKlemTg8mHiWIWYnISoD9LG7RMuK4qd7 hVHg== X-Gm-Message-State: AG10YOREKumNAmfyftCZBbEuOeZ7eDJXaUm3klBPSsrsp/wEdGASqRZca3BMoDEtJLX/zA== X-Received: by 10.55.82.2 with SMTP id g2mr38159795qkb.53.1454457028300; Tue, 02 Feb 2016 15:50:28 -0800 (PST) Received: from [192.168.8.100] ([181.202.20.169]) by smtp.gmail.com with ESMTPSA id r6sm1811250qhr.28.2016.02.02.15.50.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Feb 2016 15:50:27 -0800 (PST) From: John Bradley Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC1D8C3-A029-48E0-9E42-58740DE5FFB2" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Tue, 2 Feb 2016 20:50:23 -0300 References: To: iana@iana.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Tokbind WG , Stephen Farrell Subject: [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 02 Feb 2016 23:50:32 -0000 --Apple-Mail=_ACC1D8C3-A029-48E0-9E42-58740DE5FFB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Tokbind WG would like to ask for an early allocation of an IANA code = point for the "TLS Extension for Token Binding Protocol Negotiation" = (https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02 = ). This = document defines a new TLS extension "token_binding", which needs to be = added to the IANA "Transport Layer Security (TLS) Extensions" registry. =20 Please note that this document also seeks to establish a registry for = identifiers of Token Binding key parameters entitled "Token Binding Key = Parameters" under the "Token Binding Protocol" heading. This new = registry is not part of the early assignment request. =20 At this point, authors do not expect major changes in the "TLS Extension = for Token Binding Protocol Negotiation" specification. There are at = least two prototype implementations of this specification being worked = on (by Google and Microsoft). An early IANA code point assignment would = facilitate implementation and deployment experience prior to the = publication of the RFC. =20 Regards John Bradley= --Apple-Mail=_ACC1D8C3-A029-48E0-9E42-58740DE5FFB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The Tokbind WG would = like to ask for an early allocation of an IANA code point for the "TLS = Extension for Token Binding Protocol Negotiation" (https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02). This document defines a new TLS extension "token_binding", which = needs to be added to the IANA "Transport Layer Security (TLS) = Extensions" registry.
 
At this point, authors do not expect = major changes in the "TLS Extension for Token Binding Protocol = Negotiation" specification. There are at least two prototype = implementations of this specification being worked on (by Google and = Microsoft). An early IANA code point assignment would facilitate = implementation and deployment experience prior to the publication of the = RFC.
 
Regards
John Bradley
= --Apple-Mail=_ACC1D8C3-A029-48E0-9E42-58740DE5FFB2-- From nobody Wed Feb 3 16:47:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A751B379A; Wed, 3 Feb 2016 16:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wumRTW_0JP-O; Wed, 3 Feb 2016 16:47:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C56F1ACE85; Wed, 3 Feb 2016 16:47:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E443EBE3F; Thu, 4 Feb 2016 00:47:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxxAvW65v_1h; Thu, 4 Feb 2016 00:47:18 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.42.27.19]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 725BCBE3E; Thu, 4 Feb 2016 00:47:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454546838; bh=MM0GP4SvRgzpMlZoWB8dzU0cs8kqjzmecAGpFnicJ7M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=0GtRYDbzKox4w2vkdPelFUVdkfm/fFP47nT6xYejiK7JRm9AGvfNKDbMJgZlOrytP gJpylEc6szxzBBTOV3mYnO3zktWYZ2VdBt8XtnvNdPVs3vaRn705zBAkkFJIUEhJPz XZwmcbPbe1bh2d+xYjTflDSAjMgq9ZH4YywSYG/Y= To: John Bradley , iana@iana.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B29F96.9050107@cs.tcd.ie> Date: Thu, 4 Feb 2016 00:47:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Tokbind WG , "tls@ietf.org" Subject: Re: [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 00:47:26 -0000 Hi All, (Adding the TLS wg list, just in case.) I think this is fine and IANA should allocate a codepoint as requested. Cheers, S. On 02/02/16 23:50, John Bradley wrote: > > The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token Binding Protocol > Negotiation" > (https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02 > ). > This document defines a new TLS extension "token_binding", which > needs to be added to the IANA "Transport Layer Security (TLS) > Extensions" registry. > > Please note that this document also seeks to establish a registry for > identifiers of Token Binding key parameters entitled "Token Binding > Key Parameters" under the "Token Binding Protocol" heading. This new > registry is not part of the early assignment request. > > At this point, authors do not expect major changes in the "TLS > Extension for Token Binding Protocol Negotiation" specification. > There are at least two prototype implementations of this > specification being worked on (by Google and Microsoft). An early > IANA code point assignment would facilitate implementation and > deployment experience prior to the publication of the RFC. > > Regards John Bradley > > > > _______________________________________________ Unbearable mailing > list Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Wed Feb 3 16:50:31 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6091B37A5 for ; Wed, 3 Feb 2016 16:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 hOoy0yd87m5R for ; Wed, 3 Feb 2016 16:50:24 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 DA9111B379F for ; Wed, 3 Feb 2016 16:50:23 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id r207so33967338ykd.2 for ; Wed, 03 Feb 2016 16:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AMor43vykguC2boo2fMVhrnz3chB/wLPrGYhJ0ho3To=; b=iz8sq+aTa5O68PUV2tE56GMgdszqEoix8yYiP9zyxr8nzZEoho9Ho8YOgrkXN35LDW ehOt084l1AlInBZX5K39IBl36a6XzGV5V68GejwmpJaZJv/aQNgZjlZh1BDrH/MV5ZnG popeRh/WraLfpcI3Xe4dBv+SfPIK2Ft40ZBVY7FiKfFgVCznT2kAad1iuxxvE3CpBLhV 8eHodOlFH3gYKvNYH+8f0DhRL7WBO0/5+TXfn9zi+F8kk4zJQbszaM/VtW6bcmwf3kYN RkIcq8oeH1t2dADnI9s9jPQdAM+sIRM6LL2L8sFsD2tlW6t51qY5EJ7RLzwKWBSkk+j5 zVtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AMor43vykguC2boo2fMVhrnz3chB/wLPrGYhJ0ho3To=; b=T/mULZA10z7+dFDO1FDinJnDfH3Tdq8wBEeqtBqY/xqQSUpsbn1tVvNvSwVyFqhbHn 1HS7ESiuJiWMJLQz8D/1PsS5hdagsErjNWXba5D6Sj605u5mbX+8aEh+g17LjBebuv4K 5Y7DftskXI8PHTr2jPZSuHNpy9rwM4x3briAhFSkbfC+egnhe6eQH+PD/REaScHBHprH jlU60iO9Hvh73B3Hn4yeTX89N8kcreJP7bqO6qq7aZ0wHNDZ1lNhJ0s82uQobtiAMJyf b+0xdBB4+fAdBh58xZBRrcWoAodPaVgXXi9FD49+gNds7Yc/HV34FKMtVAaEVqET7TxR A85A== X-Gm-Message-State: AG10YORGjkBfQTg4J7c0VtXMb/g9ldf5MmdqGqttOA2yKL8+mjCy5tlyNPzeG02yzFsOxY416VbBhUrpu6jRVg== MIME-Version: 1.0 X-Received: by 10.37.76.3 with SMTP id z3mr2362392yba.165.1454547023192; Wed, 03 Feb 2016 16:50:23 -0800 (PST) Received: by 10.37.207.5 with HTTP; Wed, 3 Feb 2016 16:50:22 -0800 (PST) Received: by 10.37.207.5 with HTTP; Wed, 3 Feb 2016 16:50:22 -0800 (PST) In-Reply-To: <56B29F96.9050107@cs.tcd.ie> References: <56B29F96.9050107@cs.tcd.ie> Date: Wed, 3 Feb 2016 21:50:22 -0300 Message-ID: From: John Bradley To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113e6b66a09d1f052ae71ee5 Archived-At: Cc: Tokbind WG , iana@iana.org, "tls@ietf.org" Subject: Re: [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 00:50:25 -0000 --001a113e6b66a09d1f052ae71ee5 Content-Type: text/plain; charset=UTF-8 Thanks. On Feb 3, 2016 9:47 PM, "Stephen Farrell" wrote: > > Hi All, > > (Adding the TLS wg list, just in case.) > > I think this is fine and IANA should allocate a codepoint as > requested. > > Cheers, > S. > > On 02/02/16 23:50, John Bradley wrote: > > > > The Tokbind WG would like to ask for an early allocation of an IANA > > code point for the "TLS Extension for Token Binding Protocol > > Negotiation" > > (https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02 > > ). > > This document defines a new TLS extension "token_binding", which > > needs to be added to the IANA "Transport Layer Security (TLS) > > Extensions" registry. > > > > Please note that this document also seeks to establish a registry for > > identifiers of Token Binding key parameters entitled "Token Binding > > Key Parameters" under the "Token Binding Protocol" heading. This new > > registry is not part of the early assignment request. > > > > At this point, authors do not expect major changes in the "TLS > > Extension for Token Binding Protocol Negotiation" specification. > > There are at least two prototype implementations of this > > specification being worked on (by Google and Microsoft). An early > > IANA code point assignment would facilitate implementation and > > deployment experience prior to the publication of the RFC. > > > > Regards John Bradley > > > > > > > > _______________________________________________ Unbearable mailing > > list Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable > > > --001a113e6b66a09d1f052ae71ee5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks.

On Feb 3, 2016 9:47 PM, "Stephen Farrell&qu= ot; <stephen.farrell@cs.tcd= .ie> wrote:
<= br> Hi All,

(Adding the TLS wg list, just in case.)

I think this is fine and IANA should allocate a codepoint as
requested.

Cheers,
S.

On 02/02/16 23:50, John Bradley wrote:
>
> The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token Binding Protocol
> Negotiation"
> (https://tools.ietf.org/html/draft= -ietf-tokbind-negotiation-02
> <https://tools.ietf.org/html/dr= aft-ietf-tokbind-negotiation-02>).
> This document defines a new TLS extension "token_binding", w= hich
> needs to be added to the IANA "Transport Layer Security (TLS)
> Extensions" registry.
>
> Please note that this document also seeks to establish a registry for<= br> > identifiers of Token Binding key parameters entitled "Token Bindi= ng
> Key Parameters" under the "Token Binding Protocol" head= ing. This new
> registry is not part of the early assignment request.
>
> At this point, authors do not expect major changes in the "TLS > Extension for Token Binding Protocol Negotiation" specification.<= br> > There are at least two prototype implementations of this
> specification being worked on (by Google and Microsoft). An early
> IANA code point assignment would facilitate implementation and
> deployment experience prior to the publication of the RFC.
>
> Regards John Bradley
>
>
>
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearabl= e
>
--001a113e6b66a09d1f052ae71ee5-- From nobody Fri Feb 19 12:41:01 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539E71ACD72 for ; Fri, 19 Feb 2016 12:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 5u08On7HnNXL for ; Fri, 19 Feb 2016 12:40:57 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C4F1B2F50 for ; Fri, 19 Feb 2016 12:40:57 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u1JKese0030413 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 19 Feb 2016 21:40:54 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u1JKepc8023931 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Feb 2016 21:40:54 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1455914454; bh=zdcW4fni86GQH8vKxqSRkepl019kRBk09svqrf+iYRw=; h=Subject:References:To:From:Date:In-Reply-To; b=sRxYqToFOnlNATtis0UKseiswWGd7uSmBT/hQQa/C6tU5e+GE/CN6ozZnXkDWlZ0n YpDPDLdx8P7nCYFJAA+QQLTKfa7DiGZgXCTkHAZ4xvjHWxobENzrgmelP2jc7z/hNM J8MLfNizul2SBtEggJ6v4F8rsZ/+1Eo/UotwzOVY= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.109] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for unbearable@ietf.org; Fri, 19 Feb 2016 21:40:49 +0100 References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> To: "unbearable@ietf.org" From: Leif Johansson X-Forwarded-Message-Id: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> Message-ID: <56C77DD0.8020303@sunet.se> Date: Fri, 19 Feb 2016 21:40:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QkkESmD - 909084dd5377 - 20160219 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Feb 2016 20:41:00 -0000 I'm not 100% we decided if we needed a session in BA but I have put in a slot request just the same. Am I right in thinking that at least some of the key contributors will be in BA? Cheers Leif -------- Forwarded Message -------- Subject: tokbind - New Meeting Session Request for IETF 95 Date: Fri, 19 Feb 2016 12:15:41 -0800 From: "IETF Meeting Session Request Tool" To: session-request@ietf.org CC: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: httpbis oauth Second Priority: jose Special Requests: Avoid entire SEC area --------------------------------------------------------- From nobody Fri Feb 19 12:58:29 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42581B3515 for ; Fri, 19 Feb 2016 12:58:28 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9lp38JRXHBvG for ; Fri, 19 Feb 2016 12:58:25 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0EC1B351E for ; Fri, 19 Feb 2016 12:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2CQIrIgll7m3Bl8porvu1p3aGJnvyBW7X1I0wshFuto=; b=Z+1shQFj6f4fasXplxdOQP5ykeNiukfXYLvtpFPecbmqD4BZjjpdZggy9h3ByNkeV2cuCTv94H8W5y35NMo6wpRggsBqALdc7oy2ioCqaZSkoNRokiVVj0M+yg7OVpLX1ivJPoW+d6b3c4RKdZpxzkUVAbU7eJKdOyCVysBgXxE= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 20:58:23 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 20:58:22 +0000 From: Andrei Popov To: Leif Johansson , "unbearable@ietf.org" Thread-Topic: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 Thread-Index: AQHRa1XamAjN4GnWtEmdhfJoRgA3fJ8z2Zig Date: Fri, 19 Feb 2016 20:58:21 +0000 Message-ID: References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> <56C77DD0.8020303@sunet.se> In-Reply-To: <56C77DD0.8020303@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sunet.se; dkim=none (message not signed) header.d=none;sunet.se; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::1d2] x-ms-office365-filtering-correlation-id: fe8f3a16-8313-4a2f-eaf3-08d3396f675c x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:V27z5EaC5O3+wldiWzN8zW15rT/RMIhQFF95lRCXJHOnKngRssJXJBttiHxvr0SmbOc3Ysc0cJ4nO6P33+0GtwnCx6eVvlSnttrxUsFx2C5Vxo60JZAe6ftG7218c9KLru9ns0YnVpnsYGyWCqun3g==; 24:qZyttnuf2WDgYUw4ymUde8JByiRvKGxB3OIIQv46tpoLzi6Urq1WmsIpacHanM5AAVPQEZ9DuZPh6MBDMj3biERHDY8Rul1LyhnZK2U904A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(1096002)(2501003)(5001770100001)(33656002)(77096005)(102836003)(5003600100002)(5002640100001)(99286002)(15975445007)(107886002)(86362001)(5001960100002)(1220700001)(3280700002)(3660700001)(87936001)(586003)(8990500004)(5004730100002)(74316001)(2950100001)(50986999)(19580405001)(106116001)(5008740100001)(2900100001)(2906002)(19580395003)(189998001)(54356999)(10290500002)(5005710100001)(10400500002)(76576001)(92566002)(40100003)(76176999)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 20:58:22.0167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Feb 2016 20:58:29 -0000 So far I'm planning on attending, esp. if TB will be discussed. -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif Joh= ansson Sent: Friday, February 19, 2016 12:41 PM To: unbearable@ietf.org Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 9= 5 =09 I'm not 100% we decided if we needed a session in BA but I have put in a sl= ot request just the same. Am I right in thinking that at least some of the key contributors will be i= n BA? Cheers Leif -------- Forwarded Message -------- Subject: tokbind - New Meeting Session Request for IETF 95 Date: Fri, 19 Feb 2016 12:15:41 -0800 From: "IETF Meeting Session Request Tool" To: session-request@ietf.org CC: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, st= ephen.farrell@cs.tcd.ie A new meeting session request has just been submitted by Leif Johansson, a = Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: httpbis oauth Second Priority: jose Special Requests: Avoid entire SEC area --------------------------------------------------------- _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DTvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d From nobody Fri Feb 19 12:59:45 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B21B352E for ; Fri, 19 Feb 2016 12:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no 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 uMAR3ItTHNUR for ; Fri, 19 Feb 2016 12:59:41 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 322FB1B3524 for ; Fri, 19 Feb 2016 12:59:41 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id u9so39961205ykd.1 for ; Fri, 19 Feb 2016 12:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JT/WZE8O9Uk8p3htkd942Q6U3NyWude1wnSnOcvJLzI=; b=CcEO28EWYZa7s+YyHufc9IVLVrdEv6nCZEswyDKwoZPi3IMHn/m3Y8ugCTfbeUEbft fqAN2LuABXrEgcddZxnniWsW2JEjshM/rX7yv3rqDuEcFB+oCtWmOOeex8vkZdZ3kEzd 9n/Z3d1rld/WDUhAwQ4cQAGyn9GgtjMC5JBOtn095Grx44suQ3LHnZ1nn3y6ufmEURk6 C7awoxTXmLtVxrik8no097e2U5TVZR2O1NKGofqyn6acOLm8rGPRDIk5kqHzhQ/4J5iM YesWqdd/9Za8DACbYrWuV6hz+Da+hxXRbYj3ZhhVqpdu1T0BoC5Xr5KOmrfftEm0k9xE 1UXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JT/WZE8O9Uk8p3htkd942Q6U3NyWude1wnSnOcvJLzI=; b=KJwchqxlVuLhcr2ryg6T4Mzp4HS2tWJ1ekgHJSJIMiIPtPYKb/DCVdZBZe4E5s42/J lxoYFTxstSsCIbvR5gS/RvZ8lyR17ms9NTkLbV478XKpAToACWmAYU1prO4uhZyRBuXx VIoPQ/tjoehaHMnuo/0vDv2W8yFRljbw+1fpP3PR7s809M9VDvAi0qYk537X35xRQrNI +UVlOOX/soqgZpMEZCu/hURNWUB5TyElteaf2lfil50OuCfEGhmrqWTrRc65vpw9NLnM HViqQ/Sd1ZJbii5sEAg+pnhSlVANtQ2FYxeWbxJ+YQlf0wbmWRgccJrucHqalo6sBiBR /F3g== X-Gm-Message-State: AG10YOSi+c17gVPLYyWlfzb1/8hdt68+t99k7EpOYyqcN9lpYj+ILb8CG/FMfy2N4D76OtRDGMeAJYBI/ArT8A== X-Received: by 10.37.95.67 with SMTP id t64mr8742152ybb.82.1455915580463; Fri, 19 Feb 2016 12:59:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 12:59:01 -0800 (PST) In-Reply-To: References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> <56C77DD0.8020303@sunet.se> From: Eric Rescorla Date: Fri, 19 Feb 2016 13:59:01 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11422d0cff5288052c25c2a5 Archived-At: Cc: "unbearable@ietf.org" , Leif Johansson Subject: Re: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Feb 2016 20:59:43 -0000 --001a11422d0cff5288052c25c2a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I will be there On Fri, Feb 19, 2016 at 1:58 PM, Andrei Popov wrote: > So far I'm planning on attending, esp. if TB will be discussed. > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif > Johansson > Sent: Friday, February 19, 2016 12:41 PM > To: unbearable@ietf.org > Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF > 95 > > > I'm not 100% we decided if we needed a session in BA but I have put in a > slot request just the same. > > Am I right in thinking that at least some of the key contributors will be > in BA? > > Cheers Leif > > > -------- Forwarded Message -------- > Subject: tokbind - New Meeting Session Request for IETF 95 > Date: Fri, 19 Feb 2016 12:15:41 -0800 > From: "IETF Meeting Session Request Tool" > > To: session-request@ietf.org > CC: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, > stephen.farrell@cs.tcd.ie > > > > A new meeting session request has just been submitted by Leif Johansson, = a > Chair of the tokbind working group. > > > --------------------------------------------------------- > Working Group Name: Token Binding > Area Name: Security Area > Session Requester: Leif Johansson > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 75 > Conflicts to Avoid: > First Priority: httpbis oauth > Second Priority: jose > > > > Special Requests: > Avoid entire SEC area > --------------------------------------------------------- > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40mi= crosoft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd0= 11db47%7c1&sdata=3DTvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a11422d0cff5288052c25c2a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I will be there

On Fri, Feb 19, 2016 at 1:58 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
So far I'm planning on attending, esp. if TB will be discuss= ed.

-----Original Message-----
From: Unbearable [mailto:unb= earable-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Friday, February 19, 2016 12:41 PM
To: unbearable@ietf.org
Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 9= 5


I'm not 100% we decided if we needed a session in BA but I have put in = a slot request just the same.

Am I right in thinking that at least some of the key contributors will be i= n BA?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif


-------- Forwarded Message --------
Subject: tokbind - New Meeting Session Request for IETF 95
Date: Fri, 19 Feb 2016 12:15:41 -0800
From: "IETF Meeting Session Request Tool"
<session_request_= developers@ietf.org>
To: session-request@ietf.org
CC: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie



A new meeting session request has just been submitted by Leif Johansson, a = Chair of the tokbind working group.


---------------------------------------------------------
Working Group Name: Token Binding
Area Name: Security Area
Session Requester: Leif Johansson

Number of Sessions: 1
Length of Session(s):=C2=A0 2 Hours
Number of Attendees: 75
Conflicts to Avoid:
=C2=A0First Priority: httpbis oauth
=C2=A0Second Priority: jose



Special Requests:
=C2=A0 Avoid entire SEC area
---------------------------------------------------------




_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https:/= /na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2f= mailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40microso= ft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DTvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable=

--001a11422d0cff5288052c25c2a5-- From nobody Fri Feb 19 14:37:34 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315AF1B2FA8 for ; Fri, 19 Feb 2016 14:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.5 X-Spam-Level: X-Spam-Status: No, score=-22.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 nfbfCxituUjW for ; Fri, 19 Feb 2016 14:37:28 -0800 (PST) Received: from den-ipout-03-data1.paypalcorp.com (den-ipout-03-data1.paypalcorp.com [173.224.160.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F151A909F for ; Fri, 19 Feb 2016 14:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1455921448; x=1487457448; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WEIxlzcCqJ7z1yAkno68f66C2lvhrKS/ySA7SqB/CoM=; b=Xe7y74lXgdKnn8Ow4khUAoj9iaZFWkSDwhVc/Nqwt49pAHeYi+kMrzhU +wiGpQzJP4uulchm1sEeVruu+4CQDB0recVM/wwdt0R8lvf6oUs4ldHBn QJW1LPuCfqUVFpzq91qBnpYd8Ag+6St+bMWGYLH+1dg4H7P+J9imAZA3j zd1pWLb8YW6NdDW+38Nyz9sqVOjw36lcFbEqtx1uJEgQoP7/8aW76yNAI TOaY2hwXKemSQjETfm/7D51UHCErlnTNOgqIsd8TD7u/zCxln2fX6whUx el8AjpXkBM+narEOL69CTPUB1sYgSKYHrymB0m+VBYAg/5a6HAbdnfdHb w==; X-IronPort-AV: E=Sophos; i="5.22,472,1449558000"; d="scan'208,217"; a="10503502" Received: from unknown (HELO lvs-ipcld-01-data1.paypalcorp.com) ([10.184.246.164]) by den-ipout-03-data1.paypalcorp.com with ESMTP; 19 Feb 2016 15:37:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,472,1449561600"; d="scan'208,217";a="3864153" X-CloudService: Office365 Received: from mail-bn1lp0142.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) ([207.46.163.142]) by lvs-ipcld-01-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 19 Feb 2016 14:37:27 -0800 Received: from CO2PR06MB457.namprd06.prod.outlook.com (10.141.196.142) by CO2PR06MB460.namprd06.prod.outlook.com (10.141.196.154) with Microsoft SMTP Server (TLS) id 15.1.403.16; Fri, 19 Feb 2016 22:37:25 +0000 Received: from CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) by CO2PR06MB457.namprd06.prod.outlook.com ([10.141.196.142]) with mapi id 15.01.0403.019; Fri, 19 Feb 2016 22:37:25 +0000 From: "Hodges, Jeff" To: Leif Johansson Thread-Topic: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 Thread-Index: AQHRa1Xa8adcX1ITtkWdhFxNo4Snx58zb2cA Date: Fri, 19 Feb 2016 22:37:24 +0000 Message-ID: References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> <56C77DD0.8020303@sunet.se> In-Reply-To: <56C77DD0.8020303@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sunet.se; dkim=none (message not signed) header.d=none;sunet.se; dmarc=none action=none header.from=paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [73.202.80.238] x-microsoft-exchange-diagnostics: 1; CO2PR06MB460; 5:p9bhixrF3ffD+6oD338HMfJJMw6ICG1kayaZZ4CCT1g9yNfR6JoSKfzTpRwBIRUOtmcXQFQidV6HktUkpDawsh07MhuVUgYeiL0Nw+rAeMevTntoZ67gR8jN9js/pO9nBndOY9poPOLXFgrp9iUA+Q==; 24:47UnY7AWT7t+vKfNH3cz8hq7lYtppwoTWRVA+BmPm7j1rWG+9rk5uWK5pPd//ws8jipCNmtrcGRwGAgu2hatzGy4tkp0wujMCyBHjTZrLT8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR06MB460; x-ms-office365-filtering-correlation-id: ad204981-60da-4ef6-4161-08d3397d3d51 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CO2PR06MB460; BCL:0; PCL:0; RULEID:; SRVR:CO2PR06MB460; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(479174004)(377454003)(11100500001)(102836003)(4326007)(2950100001)(10290500002)(3660700001)(1096002)(2906002)(5008740100001)(586003)(1220700001)(77072002)(86362001)(3846002)(36756003)(15975445007)(40100003)(110136002)(4500500003)(3280700002)(2900100001)(189998001)(10400500002)(122556002)(92566002)(10770500004)(82432001)(77096005)(5001960100002)(10300500001)(66066001)(10630500004)(106116001)(73692002)(5004730100002)(19580395003)(99286002)(19580405001)(10130500003)(16236675004)(76176999)(54356999)(50986999)(19617315012)(5002640100001)(87936001)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR06MB460; H:CO2PR06MB457.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2ECD910717C9jehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 22:37:24.8833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR06MB460 X-CFilter: Scanned den1 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Feb 2016 22:37:30 -0000 --_000_D2ECD910717C9jehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will be there On 2/19/16, 12:40 PM, "Unbearable on behalf of Leif Johansson" on behalf of leifj@sun= et.se> wrote: I'm not 100% we decided if we needed a session in BA but I have put in a slot request just the same. Am I right in thinking that at least some of the key contributors will be in BA? Cheers Leif -------- Forwarded Message -------- Subject: tokbind - New Meeting Session Request for IETF 95 Date: Fri, 19 Feb 2016 12:15:41 -0800 From: "IETF Meeting Session Request Tool" > To: session-request@ietf.org CC: leifj@matematik.su.se, unbearable@ietf.or= g, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: httpbis oauth Second Priority: jose Special Requests: Avoid entire SEC area --------------------------------------------------------- _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_D2ECD910717C9jehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <77E2F6EF0AC2F0419BB178F164D256B1@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
I will be there

On 2/19/16, 12:40 PM, "Unbearable on behalf of Leif Johansson&quo= t; <unbearable-bounces@ie= tf.org on behalf of leifj@sunet.se> wrote:

I'm not 100% we decided if we needed a session in BA but I have put in= a
slot request just the same.

Am I right in thinking that at least some of the key contributors will=
be in BA?

Cheers= Leif


-------- Forwarded Message --------
Subject: tokbind - New Meeting Session Request for IETF 95
Date: Fri, 19 Feb 2016 12:15:41 -0800
From: "IETF Meeting Session Request Tool"



A new meeting session request has just been submitted by Leif Johansso= n,
a Chair of the tokbind working group.


---------------------------------------------------------
Working Group Name: Token Binding
Area Name: Security Area
Session Requester: Leif Johansson

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 75
Conflicts to Avoid:
First Priority: httpbis oauth
Second Priority: jose



Special Requests:
  Avoid entire SEC area
---------------------------------------------------------




_______________________________________________
Unbearable mailing list


--_000_D2ECD910717C9jehodgespaypalcorpcom_-- From nobody Sun Feb 21 11:42:13 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2531A892E for ; Sun, 21 Feb 2016 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 0mMjbWpVBa6S for ; Sun, 21 Feb 2016 11:42:10 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 409D51A8A41 for ; Sun, 21 Feb 2016 11:42:10 -0800 (PST) Received: (qmail 4407 invoked by uid 0); 21 Feb 2016 19:42:10 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 21 Feb 2016 19:42:09 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id M7i51s0082UhLwi017i8pk; Sun, 21 Feb 2016 12:42:08 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=jFJIQSaiL_oA:10 a=yMhMjlubAAAA:8 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=ieNpE_y6AAAA:8 a=s2ZWIaHYaxcCQB_zed8A:9 a=QEXdDO2ut3YA:10 a=c9vr-ChAvOYA:10 a=mFkzXppuxewA:10 a=juAPylRto0sA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=Hcm+o9yCtPOjnAYVobRj0czB3B4uYYF37XJWegE/gjU=; b=MJLhrb/PM8vPS//ty2hGefo7Vya/mwVtCEmuofWxaLI+q0eujRIiAK3i1xlQfVcYDn7ciae5Ska0emDkM7qrhteR3Lm5VVdOadLHKmHmalhPcM07MjdBqLB4Onf5lDdI; Received: from [73.202.80.238] (port=41929 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aXZtO-0002wv-Qx for unbearable@ietf.org; Sun, 21 Feb 2016 12:42:06 -0700 To: IETF Tokbind WG From: =JeffH Message-ID: <56CA1307.7090007@KingsMountain.com> Date: Sun, 21 Feb 2016 11:41:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 21 Feb 2016 19:42:12 -0000 I scrawled back on Wed, 27 Jan 2016: > on Fri, 18 Sep 2015 19:05:30 +0000 Andrei Popov > wrote: > > > QUIC's use of TB will require a separate specification with their own > > TB parameters negotiation mechanism, and their own binding method > > (analogous to EKM for TLS). > > ISTM at this time that draft-ietf-tokbind-protocol-04 needs a bit of work > in order to make it truly agnostic wrt the underlying transport protocol > (i.e., TLS or QUIC or whatever). see: https://github.com/TokenBinding/Internet-Drafts/pull/15 In the spirit of supporting "security protocols other than TLS and application protocols other than HTTP", as Andrei noted here.. Re: [Unbearable] Should Token Binding support non-TLS applications? https://www.ietf.org/mail-archive/web/unbearable/current/msg00287.html ..I've drafted what seem to be the minimal changes to draft-ietf-tokbind-protocol-04 in order to make the TB protocol itself agnostic to the secure transport layer underlying the application layer, and to generalize from HTTP. Note that the admonitions wrt TLS 1.2 (and earlier) Triple Handshake vuln and remediations thereof, noted in sections 4 and 8.5, are removed entirely. This is for two reasons: (1) this is TLS-specific, and (2) is already addressed draft-ietf-tokbind-negotiation. Other than that, and updating the spec's title, the changes are fairly minor. However, still to be done: 1. Move the TLS-specific keying material exporting language to draft-ietf-tokbind-negotiation. 2. further surgery needed to fully generalize from HTTP-specific app layer assumptions. 3. I have further detailed feedback on draft-ietf-tokbind-protocol-04 still to post (coming soon) visual side-by-side diff available here: http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html HTH, =JeffH From nobody Sun Feb 21 11:51:08 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF71A7023 for ; Sun, 21 Feb 2016 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RIy_JCPX7V7N for ; Sun, 21 Feb 2016 11:51:05 -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 15B7C1A00CD for ; Sun, 21 Feb 2016 11:51:05 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id l127so157331897iof.3 for ; Sun, 21 Feb 2016 11:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ca2gYGMbaTrh8EF95qO/uZn6RJhKW3X1C9GO/7rlBM8=; b=Kbp3Ooiq4TPzWsAR3pdxnjwkENA8ydYo86xmhMpMXiCIheCdAC16BenpiONxWGcXKF stY+JreI8y61ZCIOryX6tDboGBnhrV16mOAVjxORZGAPJ7xaSGO4gB7WPlYAkLkI2ZLb MNKQ26iYo3/MurAtHpi17wI+lw5aSOnM239/61NrFKmbhwtfFM6yscqLwErtvCblpaD2 zAtWRi0fDxsP/Odk/BSC/hK3OM1FuWiqexbNBLuOGPoIyX9q4L86CA1Z1BaJkvNVUPQS cak+bNbb52scaZsYwXs/HA5nBNw30zWjjb58FjUsmpiZG9VO57ZTf8zoljWyh8mqi04f Z6Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ca2gYGMbaTrh8EF95qO/uZn6RJhKW3X1C9GO/7rlBM8=; b=j/TZyQfQrxdZYLSDID5ZNoh/cBuxpQYW5rU1wjgTMxhMPjoBv4gAqviQHOrBXv/hoV ox2Gb/N3PhQGRwRk1cOcEcnpPcDbV6mW2wsguMkOFnVbWdIGb5x3fUbUbINUo5CZFZCR 4bXSbJ5Zm41/yb5Upq0kDnb2a0MDk3jE5Y4OL4rCOSLE0VQCXwf50m5eU5/S3vkRc0B1 ZyaRG7w40GhygqC2Y9l5FLIW2DX1GowQ6bRYFPOYZtswXAqsO0dK37jVfWp0c4qaivVE s0wckgxE7x1KeXJ1OcR9W7FfiCDivW74U1gqYSMsi58MigMNezKqxGpGcFDGJodZmvrk D2GQ== X-Gm-Message-State: AG10YORlAn1hnVlV8l7KHkD90vQ5OGm7En9dShqcc2FUOmnvx/P4OJFYti5ZP4q3+U/3cII3IxuQvBnvVu3T9Q== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr12729642iop.100.1456084264537; Sun, 21 Feb 2016 11:51:04 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 11:51:04 -0800 (PST) In-Reply-To: <56CA1307.7090007@KingsMountain.com> References: <56CA1307.7090007@KingsMountain.com> Date: Sun, 21 Feb 2016 11:51:04 -0800 Message-ID: From: Martin Thomson To: "=JeffH" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 21 Feb 2016 19:51:07 -0000 What is your goal? A direct coupling has the advantage that you don't have a different STL created that does not meet the basic requirements. I don't see any text establishing requirements on the STL and the token that it exports. That would seem to be important. On 21 February 2016 at 11:41, =JeffH wrote: > I scrawled back on Wed, 27 Jan 2016: >> on Fri, 18 Sep 2015 19:05:30 +0000 Andrei Popov >> wrote: >> >> > QUIC's use of TB will require a separate specification with their own >> > TB parameters negotiation mechanism, and their own binding method >> > (analogous to EKM for TLS). >> >> ISTM at this time that draft-ietf-tokbind-protocol-04 needs a bit of work >> in order to make it truly agnostic wrt the underlying transport protocol >> (i.e., TLS or QUIC or whatever). > > > see: https://github.com/TokenBinding/Internet-Drafts/pull/15 > > In the spirit of supporting "security protocols other than TLS and > application protocols other than HTTP", as Andrei noted here.. > > Re: [Unbearable] Should Token Binding support non-TLS applications? > https://www.ietf.org/mail-archive/web/unbearable/current/msg00287.html > > ..I've drafted what seem to be the minimal changes to > draft-ietf-tokbind-protocol-04 in order to make the TB protocol itself > agnostic to the secure transport layer underlying the application layer, and > to generalize from HTTP. > > Note that the admonitions wrt TLS 1.2 (and earlier) Triple Handshake vuln > and remediations thereof, noted in sections 4 and 8.5, are removed entirely. > This is for two reasons: (1) this is TLS-specific, and (2) is already > addressed draft-ietf-tokbind-negotiation. > > Other than that, and updating the spec's title, the changes are fairly > minor. > > However, still to be done: > > 1. Move the TLS-specific keying material exporting language to > draft-ietf-tokbind-negotiation. > 2. further surgery needed to fully generalize from HTTP-specific app layer > assumptions. > 3. I have further detailed feedback on draft-ietf-tokbind-protocol-04 still > to post (coming soon) > > visual side-by-side diff available here: > http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html > > > HTH, > > =JeffH > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Mon Feb 22 11:09:10 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FA81B3829 for ; Mon, 22 Feb 2016 11:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 o-kGgi_U9mJp for ; Mon, 22 Feb 2016 11:09:07 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id EC18B1B3826 for ; Mon, 22 Feb 2016 11:09:06 -0800 (PST) Received: (qmail 28995 invoked by uid 0); 22 Feb 2016 19:09:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 22 Feb 2016 19:09:05 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id Me8y1s01F2UhLwi01e91xV; Mon, 22 Feb 2016 19:09:02 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=qj0Z3I53uFQA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=B6KMzFptAAAA:20 a=ieNpE_y6AAAA:8 a=yMhMjlubAAAA:8 a=NEAV23lmAAAA:8 a=1MINwVM_eBvCvDtL2h0A:9 a=QEXdDO2ut3YA:10 a=c9vr-ChAvOYA:10 a=mFkzXppuxewA:10 a=juAPylRto0sA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=S5IRI2SXc/4hZZAKndJ0DPr7s8JMEIMlxl8raFgBVDE=; b=gbAQfzOtI7s8Bn4sMlPr2b2P802zGi4JMB/xR+PfhfutBrh5hR5DR0kNjaTtXT4zBqVHI3ze7nkskNx+t1TU0eijspFm9fc9+i1xexoAEtrOyNDFRzIfz/X844wk7i7+; Received: from [70.197.5.168] (port=9267 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aXvqv-0005vo-A3; Mon, 22 Feb 2016 12:09:01 -0700 To: Martin Thomson From: =JeffH Message-ID: <56CB5CC8.8080104@KingsMountain.com> Date: Mon, 22 Feb 2016 11:08:56 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.168 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 22 Feb 2016 19:09:09 -0000 > What is your goal? A direct coupling has the advantage that you don't > have a different STL created that does not meet the basic > requirements. well, my goal, nominially as an exercise, is to generalize the spec for non-TLS underlying STL(s) as noted in.. ..and the encompassing thread, given that Andrei was supportive and that the QUIC tokenbinding impl is ensconced in QUIC code.. ..and there's a design doc.. Token Binding over QUIC Of course, the working group and the spec editors need to formally decide whether this is a direction they in fact wish to head. I note that the wg charter does not explicitly indicate that the TB Protocol will be applicable to only TLS, but also does not explicitly state generalization for other underlying STLs (secure transport layers). The charter does, however, wrt app layer protocols state (fwiw).. "Make the Token Binding protocol useable in combination with a variety of application protocols" > I don't see any text establishing requirements on the STL and the > token that it exports. That would seem to be important. the requirements on the STL, agreed. WRT "token that it exports" -- are you referring to keying material exported from the underlying STL, for which there's cryptographic and behavioral requirements (eg as expressed in RFC5705) ? if so, agreed. eg, when the quic folk write their I-D equivalent to draft-ietf-tokbind-https, it will likely need to document the use of quic's keying material exporter function (the latter which will itself need to be documented a la RFC5705) Note also that given the crypto direction TLS 1.3 is headed (deprecation of the PRF() function), and its not-yet-fleshed-out keying material exporter, that RFC5705 arguably does not apply to TLS 1.3, and thus TLS 1.3 will need to be treated as yet another STL from the Token Binding Protocol perspective, it seems to me at this point. HTH, =JeffH > On 21 February 2016 at 11:41, =JeffH wrote: >> I scrawled back on Wed, 27 Jan 2016: >>> on Fri, 18 Sep 2015 19:05:30 +0000 Andrei Popov >>> wrote: >>> >>> > QUIC's use of TB will require a separate specification with their own >>> > TB parameters negotiation mechanism, and their own binding method >>> > (analogous to EKM for TLS). >>> >>> ISTM at this time that draft-ietf-tokbind-protocol-04 needs a bit of work >>> in order to make it truly agnostic wrt the underlying transport protocol >>> (i.e., TLS or QUIC or whatever). >> >> >> see: https://github.com/TokenBinding/Internet-Drafts/pull/15 >> >> In the spirit of supporting "security protocols other than TLS and >> application protocols other than HTTP", as Andrei noted here.. >> >> Re: [Unbearable] Should Token Binding support non-TLS applications? >> https://www.ietf.org/mail-archive/web/unbearable/current/msg00287.html >> >> ..I've drafted what seem to be the minimal changes to >> draft-ietf-tokbind-protocol-04 in order to make the TB protocol itself >> agnostic to the secure transport layer underlying the application layer, and >> to generalize from HTTP. >> >> Note that the admonitions wrt TLS 1.2 (and earlier) Triple Handshake vuln >> and remediations thereof, noted in sections 4 and 8.5, are removed entirely. >> This is for two reasons: (1) this is TLS-specific, and (2) is already >> addressed draft-ietf-tokbind-negotiation. >> >> Other than that, and updating the spec's title, the changes are fairly >> minor. >> >> However, still to be done: >> >> 1. Move the TLS-specific keying material exporting language to >> draft-ietf-tokbind-negotiation. >> 2. further surgery needed to fully generalize from HTTP-specific app layer >> assumptions. >> 3. I have further detailed feedback on draft-ietf-tokbind-protocol-04 still >> to post (coming soon) >> >> visual side-by-side diff available here: >> http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html >> From nobody Mon Feb 22 16:33:52 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C219D1B38EC for ; Mon, 22 Feb 2016 16:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 d_xZ6TYQi0a3 for ; Mon, 22 Feb 2016 16:33:48 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 6E1691B38EB for ; Mon, 22 Feb 2016 16:33:48 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id dm2so6276169obb.2 for ; Mon, 22 Feb 2016 16:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wynfmzE6DybTDzPCji+vTL01s1N0tzlXkwHFI5jeEYk=; b=Uod0rTVfTKjqmKFq8BiazzqEUAzuj8IACLs7gKmBCM/7c5TE9W5nWLd0XzQI9fF/gu 2ux/fiWN1W8xoYL6gzKabx8xJaNEWyvA/HHC7BCvii+6abrWhsYToCNiX596tnsBmOmi sxTO8XkL+2FGlRQCQCCDHS0dcnKKxJqhszEds1ScPPGuKoBkBg2HNKLolrDficBiPBFB 7nv0j3+8wy/BDGLOcJ8kLFYrcIDa3+lSOzWX5zl2MF1TFsQhtRVGp+ELGgQ781UOLniJ o5f+uBUeaNNIyTopsViK6lGt+ujbWL0CuVIqjMo15f/7csUMytaf2XL0yry7kRfoT/hw /Y+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wynfmzE6DybTDzPCji+vTL01s1N0tzlXkwHFI5jeEYk=; b=KPDSgIoj24oPZvPpK1rGLkrxokU87P05AVDSjuKAaFJ4bt1RC3LDu2s6s66jf6qY4r mKcQYMY2fjSRc10/GyVbfa64XkwkAeUmIpoV4yBdJZbx5r9lHnXR5keFAimOhfK0capA 9MHtTKcrpZil4jRI0WAxFEMZZs+JpTPb4ZK0bD1EGlYwhxM8n25bZ3IiHsgXrlXD6gmn TmWpHFDqKRA1BI60rjtChpRiP3JwQNRgkyBgO9YSGkNqhG5sIvUjmXSG0WLV/7Ig5PAV u7SRzMSHPIKhUrjrpPvQNHMhVWNQhABnPpesyvLgN2j6mBSrv3GAvOkSL+f2h5dK0FbC JTOA== X-Gm-Message-State: AG10YOQwHjg+ej3SDplmCzcETiWvziIkxsdQVPPX+eSqq/RxwV+IKp7N+0lzcdmcg83fPy+QVxk4DXtdJ8L0ZuaU X-Received: by 10.60.232.99 with SMTP id tn3mr24613706oec.8.1456187627626; Mon, 22 Feb 2016 16:33:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.86.207 with HTTP; Mon, 22 Feb 2016 16:33:28 -0800 (PST) In-Reply-To: <56CB5CC8.8080104@KingsMountain.com> References: <56CB5CC8.8080104@KingsMountain.com> From: Nick Harper Date: Mon, 22 Feb 2016 16:33:28 -0800 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=001a1136aa5645b649052c651af8 Archived-At: Cc: IETF Tokbind WG , Martin Thomson Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 23 Feb 2016 00:33:50 -0000 --001a1136aa5645b649052c651af8 Content-Type: text/plain; charset=UTF-8 QUIC crypto is destined to die (and be replaced by TLS 1.3), so I wouldn't worry about making spec changes to accommodate QUIC specifically. However, I agree with Jeff about TLS 1.3 needing to be treated differently from the Token Binding Protocol perspective because of the difference in keying material exporters. On Mon, Feb 22, 2016 at 11:08 AM, =JeffH wrote: > > What is your goal? A direct coupling has the advantage that you don't > > have a different STL created that does not meet the basic > > requirements. > > well, my goal, nominially as an exercise, is to generalize the spec for > non-TLS underlying STL(s) as noted in.. > > < > https://mailarchive.ietf.org/arch/msg/unbearable/thqNHlHciMBBijVdVV07Kbs8ohs > > > > ..and the encompassing thread, given that Andrei was supportive and that > the QUIC tokenbinding impl is ensconced in QUIC code.. > > :^src/net/quic/&sq=package:chromium&type=cs> > > ..and there's a design doc.. > > Token Binding over QUIC > < > https://docs.google.com/document/d/12eKfkdC7g5IGUCtghzg7Wi__qiEkY65fX09n8sjLtHg > > > > Of course, the working group and the spec editors need to formally decide > whether this is a direction they in fact wish to head. > > I note that the wg charter does not explicitly indicate that the TB > Protocol will be applicable to only TLS, but also does not explicitly state > generalization for other underlying STLs (secure transport layers). The > charter does, however, wrt app layer protocols state (fwiw).. > > "Make the Token Binding protocol useable in combination with a variety of > application protocols" > > > > I don't see any text establishing requirements on the STL and the > > token that it exports. That would seem to be important. > > the requirements on the STL, agreed. WRT "token that it exports" -- are > you referring to keying material exported from the underlying STL, for > which there's cryptographic and behavioral requirements (eg as expressed in > RFC5705) ? if so, agreed. > > eg, when the quic folk write their I-D equivalent to > draft-ietf-tokbind-https, it will likely need to document the use of quic's > keying material exporter function (the latter which will itself need to be > documented a la RFC5705) > > Note also that given the crypto direction TLS 1.3 is headed (deprecation > of the PRF() function), and its not-yet-fleshed-out keying material > exporter, that RFC5705 arguably does not apply to TLS 1.3, and thus TLS 1.3 > will need to be treated as yet another STL from the Token Binding Protocol > perspective, it seems to me at this point. > > HTH, > > =JeffH > > > > > > On 21 February 2016 at 11:41, =JeffH > wrote: > >> I scrawled back on Wed, 27 Jan 2016: > >>> on Fri, 18 Sep 2015 19:05:30 +0000 Andrei Popov > >>> wrote: > >>> > >>> > QUIC's use of TB will require a separate specification with their own > >>> > TB parameters negotiation mechanism, and their own binding method > >>> > (analogous to EKM for TLS). > >>> > >>> ISTM at this time that draft-ietf-tokbind-protocol-04 needs a bit of > work > >>> in order to make it truly agnostic wrt the underlying transport > protocol > >>> (i.e., TLS or QUIC or whatever). > >> > >> > >> see: https://github.com/TokenBinding/Internet-Drafts/pull/15 > >> > >> In the spirit of supporting "security protocols other than TLS and > >> application protocols other than HTTP", as Andrei noted here.. > >> > >> Re: [Unbearable] Should Token Binding support non-TLS applications? > >> https://www.ietf.org/mail-archive/web/unbearable/current/msg00287.html > >> > >> ..I've drafted what seem to be the minimal changes to > >> draft-ietf-tokbind-protocol-04 in order to make the TB protocol itself > >> agnostic to the secure transport layer underlying the application > layer, and > >> to generalize from HTTP. > >> > >> Note that the admonitions wrt TLS 1.2 (and earlier) Triple Handshake > vuln > >> and remediations thereof, noted in sections 4 and 8.5, are removed > entirely. > >> This is for two reasons: (1) this is TLS-specific, and (2) is already > >> addressed draft-ietf-tokbind-negotiation. > >> > >> Other than that, and updating the spec's title, the changes are fairly > >> minor. > >> > >> However, still to be done: > >> > >> 1. Move the TLS-specific keying material exporting language to > >> draft-ietf-tokbind-negotiation. > >> 2. further surgery needed to fully generalize from HTTP-specific app > layer > >> assumptions. > >> 3. I have further detailed feedback on draft-ietf-tokbind-protocol-04 > still > >> to post (coming soon) > >> > >> visual side-by-side diff available here: > >> > http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html > >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a1136aa5645b649052c651af8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
QUIC crypto is destined to die (and be replaced by TLS 1.3= ), so I wouldn't worry about making spec changes to accommodate QUIC sp= ecifically. However, I agree with Jeff about TLS 1.3 needing to be treated = differently from the Token Binding Protocol perspective because of the diff= erence in keying material exporters.

On Mon, Feb 22, 2016 at 11:08 AM, =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:
> What is your goal?=C2=A0 A direct c= oupling has the advantage that you don't
> have a different STL created that does not meet the basic
> requirements.

 well, my goal, nominially as an exercise, is to generalize the spec for non= -TLS underlying STL(s) as noted in..

<https://mailarchive.= ietf.org/arch/msg/unbearable/thqNHlHciMBBijVdVV07Kbs8ohs>

..and the encompassing thread, given that Andrei was supportive and that th= e QUIC tokenbinding impl is ensconced in QUIC code..

<https://code.goog= le.com/p/chromium/codesearch#search/&q=3Dtokenbind%20file:^src/net/= quic/&sq=3Dpackage:chromium&type=3Dcs>

..and there's a design doc..

Token Binding over QUIC
<https://docs.goog= le.com/document/d/12eKfkdC7g5IGUCtghzg7Wi__qiEkY65fX09n8sjLtHg>

Of course, the working group and the spec editors need to formally decide w= hether this is a direction they in fact wish to head.

I note that the wg charter does not explicitly indicate that the TB Protoco= l will be applicable to only TLS, but also does not explicitly state genera= lization for other underlying STLs (secure transport layers). The charter d= oes, however, wrt app layer protocols state (fwiw)..

"Make the Token Binding protocol useable in combination with a variety= of application protocols"


> I don't see any text establishing requirements on the STL and the<= br> > token that it exports.=C2=A0 That would seem to be important.

 the requirements on the STL, agreed. WRT "token that it exports" = -- are you referring to keying material exported from the underlying STL, f= or which there's cryptographic and behavioral requirements (eg as expre= ssed in RFC5705) ? if so, agreed.

eg, when the quic folk write their I-D equivalent to draft-ietf-tokbind-htt= ps, it will likely need to document the use of quic's keying material e= xporter function (the latter which will itself need to be documented a la R= FC5705)

Note also that given the crypto direction TLS 1.3 is headed (deprecation of= the PRF() function), and its not-yet-fleshed-out keying material exporter,= that RFC5705 arguably does not apply to TLS 1.3, and thus TLS 1.3 will nee= d to be treated as yet another STL from the Token Binding Protocol perspect= ive, it seems to me at this point.

HTH,

=3DJeffH




> On 21 February 2016 at 11:41, =3DJeffH <Jeff.Hodges@kingsmountain.com&g= t; wrote:
>> I scrawled back on Wed, 27 Jan 2016:
>>> on Fri, 18 Sep 2015 19:05:30 +0000 Andrei Popov
>>> <Andrei.Popov@microsoft.com> wrote:
>>>
>>> > QUIC's use of TB will require a separate specificatio= n with their own
>>> > TB parameters negotiation mechanism, and their own bindin= g method
>>> > (analogous to EKM for TLS).
>>>
>>> ISTM at this time that draft-ietf-tokbind-protocol-04 needs a = bit of work
>>> in order to make it truly agnostic wrt the underlying transpor= t protocol
>>> (i.e., TLS or QUIC or whatever).
>>
>>
>> see: https://github.com/TokenBinding= /Internet-Drafts/pull/15
>>
>> In the spirit of supporting "security protocols other than TL= S and
>> application protocols other than HTTP", as Andrei noted here.= .
>>
>> Re: [Unbearable] Should Token Binding support non-TLS applications= ?
>> https://www.ietf.org/= mail-archive/web/unbearable/current/msg00287.html
>>
>> ..I've drafted what seem to be the minimal changes to
>> draft-ietf-tokbind-protocol-04 in order to make the TB protocol it= self
>> agnostic to the secure transport layer underlying the application = layer, and
>> to generalize from HTTP.
>>
>> Note that the admonitions wrt TLS 1.2 (and earlier) Triple Handsha= ke vuln
>> and remediations thereof, noted in sections 4 and 8.5, are removed= entirely.
>> This is for two reasons: (1) this is TLS-specific, and (2) is alre= ady
>> addressed draft-ietf-tokbind-negotiation.
>>
>> Other than that, and updating the spec's title, the changes ar= e fairly
>> minor.
>>
>> However, still to be done:
>>
>> 1. Move the TLS-specific keying material exporting language to
>> draft-ietf-tokbind-negotiation.
>> 2. further surgery needed to fully generalize from HTTP-specific a= pp layer
>> assumptions.
>> 3. I have further detailed feedback on draft-ietf-tokbind-protocol= -04 still
>> to post (coming soon)
>>
>> visual side-by-side diff available here:
>> http://kingsmountain.com/doc/diff/Diff--draft-= ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html<= /a>
>>

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=

--001a1136aa5645b649052c651af8-- From nobody Mon Feb 22 17:06:56 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68521A8979 for ; Mon, 22 Feb 2016 17:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 r3dnxHxvNqo0 for ; Mon, 22 Feb 2016 17:06:48 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4CF1A89B5 for ; Mon, 22 Feb 2016 17:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GVtQHIEwjFKb11HbiZtCNYpEFNf859GtZoCe4tcXw7s=; b=dBbN5T43ILzKs41Fdrbj8cXkGH2J5k0A/zXe76yCyI29xzKD/KhNHoj8bLeKeyU2piqx0mnZCTFDcs1vA1+hUUEv6q9gkdXPlAuxao7MxF6vToetu+RlDVmQHugxE/inmA5Y7RmoBIhXaeS6NWqntph7E5YzCi5cFm+6c0djpr0= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 01:06:45 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 01:06:45 +0000 From: Andrei Popov To: Nick Harper , =JeffH Thread-Topic: [Unbearable] Should Token Binding support non-TLS applications? Thread-Index: AQHRbaR6BqcNTIsNp0msYAg2PolnoZ84yFcAgAACtWA= Date: Tue, 23 Feb 2016 01:06:45 +0000 Message-ID: References: <56CB5CC8.8080104@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 2ee0df60-acb9-48ff-8bd2-08d33bed9981 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:BadshtVMKxx8oQ2QBrXlC9rD1o/VqHizVldkOX1zXwB6VlT5vVTR9mCJLSZuux5E7+2FvUC0+I3OOSKmGOLrYi+h9TGHB53UM3R6ijE4wIQFlN9EByXh5Z48mORVefab+nq8oQQESRf6t7PCXoR5Qg==; 24:vX4qB+c/XH/VD92m901jFBG8EPpC7ok4XEylxOD8bd7CSxNYpCmug/1ike8FVHZMcoXVbYft6/fHdIkibxVwM0Ns//BmPoQ8SHm9zX2f2UE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19609705001)(92566002)(790700001)(3660700001)(15975445007)(74316001)(99286002)(6116002)(3280700002)(19617315012)(77096005)(19580395003)(19580405001)(5001770100001)(8990500004)(40100003)(10290500002)(5005710100001)(16236675004)(2900100001)(2950100001)(86612001)(10400500002)(15395725005)(122556002)(33656002)(86362001)(19625215002)(19300405004)(11100500001)(54356999)(76176999)(189998001)(5001960100002)(1096002)(87936001)(50986999)(102836003)(4326007)(1220700001)(586003)(5002510100001)(76576001)(5003600100002)(5002640100001)(2906002)(5004730100002)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139661179CC30C0CC4AEF3F98CA40BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 01:06:45.6657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: IETF Tokbind WG , Martin Thomson Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 23 Feb 2016 01:06:53 -0000 --_000_BLUPR03MB139661179CC30C0CC4AEF3F98CA40BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEplZmYgZm9yIHJldmlld2luZyB0aGUgZG9jdW1lbnRzIGFuZCBwcm92aWRpbmcgdGhl IHB1bGwgcmVxdWVzdC4gSSBhbSBub3Qgb3Bwb3NlZCB0byB0aGUgb3ZlcmFsbCBnb2FsIG9mIHRo aXMgUFIuDQoNCklmIHRoZSBXRyBkZWNpZGVzIHRvIHB1cnN1ZSB0aGlzIHR5cGUgb2YgY2hhbmdl LCBJIHRoaW5rIHdlIHdvdWxkIGVpdGhlciBuZWVkIGEgbmV3IEktRCB0aGF0IHdpbGwgY29udGFp biBUTFMtc3BlY2lmaWMgaW5mb3JtYXRpb24gKHByaW1hcmlseSBwYXJhbWV0ZXJzIGZvciB0aGUg a2V5IGV4cG9ydGVycyBhbmQgVExTLXNwZWNpZmljIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zKSwg b3IgZHJhZnQtaWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uIHdvdWxkIG5lZWQgdG8gYmUgZXhwYW5k ZWQgYW5kIHRyYW5zZm9ybWVkIGludG8gZHJhZnQtaWV0Zi10b2tiaW5kLXRscy4NCg0KQ2hlZXJz LA0KDQpBbmRyZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5pY2sgSGFycGVyDQpTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDIyLCAyMDE2IDQ6MzMgUE0NClRvOiA9SmVmZkggPEplZmYuSG9kZ2VzQGtpbmdzbW91bnRh aW4uY29tPg0KQ2M6IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IE1hcnRp biBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVh cmFibGVdIFNob3VsZCBUb2tlbiBCaW5kaW5nIHN1cHBvcnQgbm9uLVRMUyBhcHBsaWNhdGlvbnM/ DQoNClFVSUMgY3J5cHRvIGlzIGRlc3RpbmVkIHRvIGRpZSAoYW5kIGJlIHJlcGxhY2VkIGJ5IFRM UyAxLjMpLCBzbyBJIHdvdWxkbid0IHdvcnJ5IGFib3V0IG1ha2luZyBzcGVjIGNoYW5nZXMgdG8g YWNjb21tb2RhdGUgUVVJQyBzcGVjaWZpY2FsbHkuIEhvd2V2ZXIsIEkgYWdyZWUgd2l0aCBKZWZm IGFib3V0IFRMUyAxLjMgbmVlZGluZyB0byBiZSB0cmVhdGVkIGRpZmZlcmVudGx5IGZyb20gdGhl IFRva2VuIEJpbmRpbmcgUHJvdG9jb2wgcGVyc3BlY3RpdmUgYmVjYXVzZSBvZiB0aGUgZGlmZmVy ZW5jZSBpbiBrZXlpbmcgbWF0ZXJpYWwgZXhwb3J0ZXJzLg0KDQpPbiBNb24sIEZlYiAyMiwgMjAx NiBhdCAxMTowOCBBTSwgPUplZmZIIDxKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTxtYWls dG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+PiB3cm90ZToNCj4gV2hhdCBpcyB5b3Vy IGdvYWw/ICBBIGRpcmVjdCBjb3VwbGluZyBoYXMgdGhlIGFkdmFudGFnZSB0aGF0IHlvdSBkb24n dA0KPiBoYXZlIGEgZGlmZmVyZW50IFNUTCBjcmVhdGVkIHRoYXQgZG9lcyBub3QgbWVldCB0aGUg YmFzaWMNCj4gcmVxdWlyZW1lbnRzLg0KDQp3ZWxsLCBteSBnb2FsLCBub21pbmlhbGx5IGFzIGFu IGV4ZXJjaXNlLCBpcyB0byBnZW5lcmFsaXplIHRoZSBzcGVjIGZvciBub24tVExTIHVuZGVybHlp bmcgU1RMKHMpIGFzIG5vdGVkIGluLi4NCg0KPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvdW5iZWFyYWJsZS90aHFOSGxIY2lNQkJpalZkVlYwN0ticzhvaHM8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZt YWlsYXJjaGl2ZS5pZXRmLm9yZyUyZmFyY2glMmZtc2clMmZ1bmJlYXJhYmxlJTJmdGhxTkhsSGNp TUJCaWpWZFZWMDdLYnM4b2hzJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29m dC5jb20lN2M4MTllZjU4NzgzN2M0OTQ4NDg1NjA4ZDMzYmU5MDI4NSU3YzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1sQWNaVzNhN0FrMmlSTjl1UDNvVkZrQkYzNjNi ZTNmcktiTm1rbDhBWTNrJTNkPj4NCg0KLi5hbmQgdGhlIGVuY29tcGFzc2luZyB0aHJlYWQsIGdp dmVuIHRoYXQgQW5kcmVpIHdhcyBzdXBwb3J0aXZlIGFuZCB0aGF0IHRoZSBRVUlDIHRva2VuYmlu ZGluZyBpbXBsIGlzIGVuc2NvbmNlZCBpbiBRVUlDIGNvZGUuLg0KDQo8aHR0cHM6Ly9jb2RlLmdv b2dsZS5jb20vcC9jaHJvbWl1bS9jb2Rlc2VhcmNoI3NlYXJjaC8mcT10b2tlbmJpbmQlMjBmaWxl PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmY29kZS5nb29nbGUuY29tJTJmcCUyZmNocm9taXVtJTJmY29kZXNlYXJjaCUyM3Nl YXJjaCUyZiUyNnElM2R0b2tlbmJpbmQlMjUyMGZpbGUmZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBv cG92JTQwbWljcm9zb2Z0LmNvbSU3YzgxOWVmNTg3ODM3YzQ5NDg0ODU2MDhkMzNiZTkwMjg1JTdj NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPThYZHN4ayUyYlkwVjBy R0hlSXhyUG1mamRBblA0NXdrMkdkZFJ6ZzhQRDVpUSUzZD46XnNyYy9uZXQvcXVpYy8mc3E9cGFj a2FnZTpjaHJvbWl1bSZ0eXBlPWNzPg0KDQouLmFuZCB0aGVyZSdzIGEgZGVzaWduIGRvYy4uDQoN ClRva2VuIEJpbmRpbmcgb3ZlciBRVUlDDQo8aHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1l bnQvZC8xMmVLZmtkQzdnNUlHVUN0Z2h6ZzdXaV9fcWlFa1k2NWZYMDluOHNqTHRIZzxodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUy ZmRvY3MuZ29vZ2xlLmNvbSUyZmRvY3VtZW50JTJmZCUyZjEyZUtma2RDN2c1SUdVQ3RnaHpnN1dp X19xaUVrWTY1ZlgwOW44c2pMdEhnJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jv c29mdC5jb20lN2M4MTllZjU4NzgzN2M0OTQ4NDg1NjA4ZDMzYmU5MDI4NSU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1NV3hzNEw2TmNBRDRjanZZYTFKTVR4Qkw2 bnolMmIzYzMxZ3QlMmZTeGx1blJFWSUzZD4+DQoNCk9mIGNvdXJzZSwgdGhlIHdvcmtpbmcgZ3Jv dXAgYW5kIHRoZSBzcGVjIGVkaXRvcnMgbmVlZCB0byBmb3JtYWxseSBkZWNpZGUgd2hldGhlciB0 aGlzIGlzIGEgZGlyZWN0aW9uIHRoZXkgaW4gZmFjdCB3aXNoIHRvIGhlYWQuDQoNCkkgbm90ZSB0 aGF0IHRoZSB3ZyBjaGFydGVyIGRvZXMgbm90IGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhhdCB0aGUg VEIgUHJvdG9jb2wgd2lsbCBiZSBhcHBsaWNhYmxlIHRvIG9ubHkgVExTLCBidXQgYWxzbyBkb2Vz IG5vdCBleHBsaWNpdGx5IHN0YXRlIGdlbmVyYWxpemF0aW9uIGZvciBvdGhlciB1bmRlcmx5aW5n IFNUTHMgKHNlY3VyZSB0cmFuc3BvcnQgbGF5ZXJzKS4gVGhlIGNoYXJ0ZXIgZG9lcywgaG93ZXZl ciwgd3J0IGFwcCBsYXllciBwcm90b2NvbHMgc3RhdGUgKGZ3aXcpLi4NCg0KIk1ha2UgdGhlIFRv a2VuIEJpbmRpbmcgcHJvdG9jb2wgdXNlYWJsZSBpbiBjb21iaW5hdGlvbiB3aXRoIGEgdmFyaWV0 eSBvZiBhcHBsaWNhdGlvbiBwcm90b2NvbHMiDQoNCg0KPiBJIGRvbid0IHNlZSBhbnkgdGV4dCBl c3RhYmxpc2hpbmcgcmVxdWlyZW1lbnRzIG9uIHRoZSBTVEwgYW5kIHRoZQ0KPiB0b2tlbiB0aGF0 IGl0IGV4cG9ydHMuICBUaGF0IHdvdWxkIHNlZW0gdG8gYmUgaW1wb3J0YW50Lg0KDQp0aGUgcmVx dWlyZW1lbnRzIG9uIHRoZSBTVEwsIGFncmVlZC4gV1JUICJ0b2tlbiB0aGF0IGl0IGV4cG9ydHMi IC0tIGFyZSB5b3UgcmVmZXJyaW5nIHRvIGtleWluZyBtYXRlcmlhbCBleHBvcnRlZCBmcm9tIHRo ZSB1bmRlcmx5aW5nIFNUTCwgZm9yIHdoaWNoIHRoZXJlJ3MgY3J5cHRvZ3JhcGhpYyBhbmQgYmVo YXZpb3JhbCByZXF1aXJlbWVudHMgKGVnIGFzIGV4cHJlc3NlZCBpbiBSRkM1NzA1KSA/IGlmIHNv LCBhZ3JlZWQuDQoNCmVnLCB3aGVuIHRoZSBxdWljIGZvbGsgd3JpdGUgdGhlaXIgSS1EIGVxdWl2 YWxlbnQgdG8gZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLCBpdCB3aWxsIGxpa2VseSBuZWVkIHRv IGRvY3VtZW50IHRoZSB1c2Ugb2YgcXVpYydzIGtleWluZyBtYXRlcmlhbCBleHBvcnRlciBmdW5j dGlvbiAodGhlIGxhdHRlciB3aGljaCB3aWxsIGl0c2VsZiBuZWVkIHRvIGJlIGRvY3VtZW50ZWQg YSBsYSBSRkM1NzA1KQ0KDQpOb3RlIGFsc28gdGhhdCBnaXZlbiB0aGUgY3J5cHRvIGRpcmVjdGlv biBUTFMgMS4zIGlzIGhlYWRlZCAoZGVwcmVjYXRpb24gb2YgdGhlIFBSRigpIGZ1bmN0aW9uKSwg YW5kIGl0cyBub3QteWV0LWZsZXNoZWQtb3V0IGtleWluZyBtYXRlcmlhbCBleHBvcnRlciwgdGhh dCBSRkM1NzA1IGFyZ3VhYmx5IGRvZXMgbm90IGFwcGx5IHRvIFRMUyAxLjMsIGFuZCB0aHVzIFRM UyAxLjMgd2lsbCBuZWVkIHRvIGJlIHRyZWF0ZWQgYXMgeWV0IGFub3RoZXIgU1RMIGZyb20gdGhl IFRva2VuIEJpbmRpbmcgUHJvdG9jb2wgcGVyc3BlY3RpdmUsIGl0IHNlZW1zIHRvIG1lIGF0IHRo aXMgcG9pbnQuDQoNCkhUSCwNCg0KPUplZmZIDQoNCg0KDQoNCj4gT24gMjEgRmVicnVhcnkgMjAx NiBhdCAxMTo0MSwgPUplZmZIIDxKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTxtYWlsdG86 SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+PiB3cm90ZToNCj4+IEkgc2NyYXdsZWQgYmFj ayBvbiBXZWQsIDI3IEphbiAyMDE2Og0KPj4+IG9uIEZyaSwgMTggU2VwIDIwMTUgMTk6MDU6MzAg KzAwMDAgQW5kcmVpIFBvcG92DQo+Pj4gPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0 bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4gPiBRVUlDJ3Mg dXNlIG9mIFRCIHdpbGwgcmVxdWlyZSBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gd2l0aCB0aGVp ciBvd24NCj4+PiA+IFRCIHBhcmFtZXRlcnMgbmVnb3RpYXRpb24gbWVjaGFuaXNtLCBhbmQgdGhl aXIgb3duIGJpbmRpbmcgbWV0aG9kDQo+Pj4gPiAoYW5hbG9nb3VzIHRvIEVLTSBmb3IgVExTKS4N Cj4+Pg0KPj4+IElTVE0gYXQgdGhpcyB0aW1lIHRoYXQgZHJhZnQtaWV0Zi10b2tiaW5kLXByb3Rv Y29sLTA0IG5lZWRzIGEgYml0IG9mIHdvcmsNCj4+PiBpbiBvcmRlciB0byBtYWtlIGl0IHRydWx5 IGFnbm9zdGljIHdydCB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2wNCj4+PiAoaS5l LiwgVExTIG9yIFFVSUMgb3Igd2hhdGV2ZXIpLg0KPj4NCj4+DQo+PiBzZWU6IGh0dHBzOi8vZ2l0 aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL3B1bGwvMTUNCj4+DQo+PiBJbiB0 aGUgc3Bpcml0IG9mIHN1cHBvcnRpbmcgInNlY3VyaXR5IHByb3RvY29scyBvdGhlciB0aGFuIFRM UyBhbmQNCj4+IGFwcGxpY2F0aW9uIHByb3RvY29scyBvdGhlciB0aGFuIEhUVFAiLCBhcyBBbmRy ZWkgbm90ZWQgaGVyZS4uDQo+Pg0KPj4gUmU6IFtVbmJlYXJhYmxlXSBTaG91bGQgVG9rZW4gQmlu ZGluZyBzdXBwb3J0IG5vbi1UTFMgYXBwbGljYXRpb25zPw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi91bmJlYXJhYmxlL2N1cnJlbnQvbXNnMDAyODcuaHRtbDxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWwtYXJjaGl2ZSUyZndlYiUyZnVuYmVhcmFibGUlMmZjdXJy ZW50JTJmbXNnMDAyODcuaHRtbCZkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3Nv ZnQuY29tJTdjODE5ZWY1ODc4MzdjNDk0ODQ4NTYwOGQzM2JlOTAyODUlN2M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9SE1MUGpsYmdrTzJ6aWpvd3U1SlIycUcyJTJm UmN5eXFmSm9QOGliaThlYVZnJTNkPg0KPj4NCj4+IC4uSSd2ZSBkcmFmdGVkIHdoYXQgc2VlbSB0 byBiZSB0aGUgbWluaW1hbCBjaGFuZ2VzIHRvDQo+PiBkcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9j b2wtMDQgaW4gb3JkZXIgdG8gbWFrZSB0aGUgVEIgcHJvdG9jb2wgaXRzZWxmDQo+PiBhZ25vc3Rp YyB0byB0aGUgc2VjdXJlIHRyYW5zcG9ydCBsYXllciB1bmRlcmx5aW5nIHRoZSBhcHBsaWNhdGlv biBsYXllciwgYW5kDQo+PiB0byBnZW5lcmFsaXplIGZyb20gSFRUUC4NCj4+DQo+PiBOb3RlIHRo YXQgdGhlIGFkbW9uaXRpb25zIHdydCBUTFMgMS4yIChhbmQgZWFybGllcikgVHJpcGxlIEhhbmRz aGFrZSB2dWxuDQo+PiBhbmQgcmVtZWRpYXRpb25zIHRoZXJlb2YsIG5vdGVkIGluIHNlY3Rpb25z IDQgYW5kIDguNSwgYXJlIHJlbW92ZWQgZW50aXJlbHkuDQo+PiBUaGlzIGlzIGZvciB0d28gcmVh c29uczogKDEpIHRoaXMgaXMgVExTLXNwZWNpZmljLCBhbmQgKDIpIGlzIGFscmVhZHkNCj4+IGFk ZHJlc3NlZCBkcmFmdC1pZXRmLXRva2JpbmQtbmVnb3RpYXRpb24uDQo+Pg0KPj4gT3RoZXIgdGhh biB0aGF0LCBhbmQgdXBkYXRpbmcgdGhlIHNwZWMncyB0aXRsZSwgdGhlIGNoYW5nZXMgYXJlIGZh aXJseQ0KPj4gbWlub3IuDQo+Pg0KPj4gSG93ZXZlciwgc3RpbGwgdG8gYmUgZG9uZToNCj4+DQo+ PiAxLiBNb3ZlIHRoZSBUTFMtc3BlY2lmaWMga2V5aW5nIG1hdGVyaWFsIGV4cG9ydGluZyBsYW5n dWFnZSB0bw0KPj4gZHJhZnQtaWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uLg0KPj4gMi4gZnVydGhl ciBzdXJnZXJ5IG5lZWRlZCB0byBmdWxseSBnZW5lcmFsaXplIGZyb20gSFRUUC1zcGVjaWZpYyBh cHAgbGF5ZXINCj4+IGFzc3VtcHRpb25zLg0KPj4gMy4gSSBoYXZlIGZ1cnRoZXIgZGV0YWlsZWQg ZmVlZGJhY2sgb24gZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA0IHN0aWxsDQo+PiB0byBw b3N0IChjb21pbmcgc29vbikNCj4+DQo+PiB2aXN1YWwgc2lkZS1ieS1zaWRlIGRpZmYgYXZhaWxh YmxlIGhlcmU6DQo+PiBodHRwOi8va2luZ3Ntb3VudGFpbi5jb20vZG9jL2RpZmYvRGlmZi0tZHJh ZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA0LnR4dC0tdG8tLWRyYWZ0LWlldGYtdG9rYmluZC1w cm90b2NvbC0wNGIudHh0Lmh0bWw8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmtpbmdzbW91bnRhaW4uY29tJTJmZG9jJTJmZGlm ZiUyZkRpZmYtLWRyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNC50eHQtLXRvLS1kcmFmdC1p ZXRmLXRva2JpbmQtcHJvdG9jb2wtMDRiLnR4dC5odG1sJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Q b3BvdiU0MG1pY3Jvc29mdC5jb20lN2M4MTllZjU4NzgzN2M0OTQ4NDg1NjA4ZDMzYmU5MDI4NSU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT0wMEx3dWpPUEV1ZnhY NzByeUZJbEMwb0UxTmFYWkNybnNybVNnblNJeGhrJTNkPg0KPj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0K VW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRm Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnVuYmVhcmFibGUmZGF0YT0wMSU3YzAxJTdjQW5k cmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3YzgxOWVmNTg3ODM3YzQ5NDg0ODU2MDhkMzNiZTkw Mjg1JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXZlMExSUmxm S2I5YTkwREpZeFRQN1VVUiUyZkU1WndxYXBjS01tNTZLN1kwQSUzZD4NCg0K --_000_BLUPR03MB139661179CC30C0CC4AEF3F98CA40BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIEplZmYgZm9yIHJldmlld2lu ZyB0aGUgZG9jdW1lbnRzIGFuZCBwcm92aWRpbmcgdGhlIHB1bGwgcmVxdWVzdC4gSSBhbSBub3Qg b3Bwb3NlZCB0byB0aGUgb3ZlcmFsbCBnb2FsIG9mIHRoaXMgUFIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB0aGUgV0cgZGVjaWRlcyB0byBwdXJzdWUgdGhp cyB0eXBlIG9mIGNoYW5nZSwgSSB0aGluayB3ZSB3b3VsZCBlaXRoZXIgbmVlZCBhIG5ldyBJLUQg dGhhdCB3aWxsIGNvbnRhaW4gVExTLXNwZWNpZmljIGluZm9ybWF0aW9uIChwcmltYXJpbHkgcGFy YW1ldGVycyBmb3IgdGhlDQoga2V5IGV4cG9ydGVycyBhbmQgVExTLXNwZWNpZmljIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zKSwgb3IgZHJhZnQtaWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uIHdvdWxk IG5lZWQgdG8gYmUgZXhwYW5kZWQgYW5kIHRyYW5zZm9ybWVkIGludG8gZHJhZnQtaWV0Zi10b2ti aW5kLXRscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVy cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5OaWNrIEhhcnBlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZl YnJ1YXJ5IDIyLCAyMDE2IDQ6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+ID1KZWZmSCAmbHQ7SmVmZi5I b2RnZXNAa2luZ3Ntb3VudGFpbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFRva2JpbmQg V0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGlu LnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFi bGVdIFNob3VsZCBUb2tlbiBCaW5kaW5nIHN1cHBvcnQgbm9uLVRMUyBhcHBsaWNhdGlvbnM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UVVJQyBjcnlwdG8gaXMgZGVzdGlu ZWQgdG8gZGllIChhbmQgYmUgcmVwbGFjZWQgYnkgVExTIDEuMyksIHNvIEkgd291bGRuJ3Qgd29y cnkgYWJvdXQgbWFraW5nIHNwZWMgY2hhbmdlcyB0byBhY2NvbW1vZGF0ZSBRVUlDIHNwZWNpZmlj YWxseS4gSG93ZXZlciwgSSBhZ3JlZSB3aXRoIEplZmYgYWJvdXQgVExTIDEuMyBuZWVkaW5nIHRv IGJlIHRyZWF0ZWQgZGlmZmVyZW50bHkgZnJvbSB0aGUgVG9rZW4gQmluZGluZw0KIFByb3RvY29s IHBlcnNwZWN0aXZlIGJlY2F1c2Ugb2YgdGhlIGRpZmZlcmVuY2UgaW4ga2V5aW5nIG1hdGVyaWFs IGV4cG9ydGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgRmViIDIyLCAyMDE2IGF0IDExOjA4IEFNLCA9SmVmZkggJmx0OzxhIGhyZWY9Im1h aWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkplZmYu SG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBXaGF0IGlzIHlvdXIgZ29hbD8m bmJzcDsgQSBkaXJlY3QgY291cGxpbmcgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCB5b3UgZG9uJ3Q8 YnI+DQomZ3Q7IGhhdmUgYSBkaWZmZXJlbnQgU1RMIGNyZWF0ZWQgdGhhdCBkb2VzIG5vdCBtZWV0 IHRoZSBiYXNpYzxicj4NCiZndDsgcmVxdWlyZW1lbnRzLjxicj4NCjxicj4NCndlbGwsIG15IGdv YWwsIG5vbWluaWFsbHkgYXMgYW4gZXhlcmNpc2UsIGlzIHRvIGdlbmVyYWxpemUgdGhlIHNwZWMg Zm9yIG5vbi1UTFMgdW5kZXJseWluZyBTVEwocykgYXMgbm90ZWQgaW4uLjxicj4NCjxicj4NCiZs dDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzYSUyZiUyZm1haWxhcmNoaXZlLmlldGYub3JnJTJmYXJjaCUyZm1zZyUyZnVu YmVhcmFibGUlMmZ0aHFOSGxIY2lNQkJpalZkVlYwN0ticzhvaHMmYW1wO2RhdGE9MDElN2MwMSU3 Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2M4MTllZjU4NzgzN2M0OTQ4NDg1NjA4ZDMz YmU5MDI4NSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9 bEFjWlczYTdBazJpUk45dVAzb1ZGa0JGMzYzYmUzZnJLYk5ta2w4QVkzayUzZCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdW5iZWFyYWJsZS90 aHFOSGxIY2lNQkJpalZkVlYwN0ticzhvaHM8L2E+Jmd0Ozxicj4NCjxicj4NCi4uYW5kIHRoZSBl bmNvbXBhc3NpbmcgdGhyZWFkLCBnaXZlbiB0aGF0IEFuZHJlaSB3YXMgc3VwcG9ydGl2ZSBhbmQg dGhhdCB0aGUgUVVJQyB0b2tlbmJpbmRpbmcgaW1wbCBpcyBlbnNjb25jZWQgaW4gUVVJQyBjb2Rl Li48YnI+DQo8YnI+DQombHQ7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZjb2RlLmdvb2dsZS5jb20lMmZwJTJm Y2hyb21pdW0lMmZjb2Rlc2VhcmNoJTIzc2VhcmNoJTJmJTI2cSUzZHRva2VuYmluZCUyNTIwZmls ZSZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3YzgxOWVm NTg3ODM3YzQ5NDg0ODU2MDhkMzNiZTkwMjg1JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJmFtcDtzZGF0YT04WGRzeGslMmJZMFYwckdIZUl4clBtZmpkQW5QNDV3azJHZGRS emc4UEQ1aVElM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL2No cm9taXVtL2NvZGVzZWFyY2gjc2VhcmNoLyZhbXA7cT10b2tlbmJpbmQlMjBmaWxlPC9hPjpec3Jj L25ldC9xdWljLyZhbXA7c3E9cGFja2FnZTpjaHJvbWl1bSZhbXA7dHlwZT1jcyZndDs8YnI+DQo8 YnI+DQouLmFuZCB0aGVyZSdzIGEgZGVzaWduIGRvYy4uPGJyPg0KPGJyPg0KVG9rZW4gQmluZGlu ZyBvdmVyIFFVSUM8YnI+DQombHQ7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZkb2NzLmdvb2dsZS5jb20lMmZk b2N1bWVudCUyZmQlMmYxMmVLZmtkQzdnNUlHVUN0Z2h6ZzdXaV9fcWlFa1k2NWZYMDluOHNqTHRI ZyZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3YzgxOWVm NTg3ODM3YzQ5NDg0ODU2MDhkMzNiZTkwMjg1JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJmFtcDtzZGF0YT1NV3hzNEw2TmNBRDRjanZZYTFKTVR4Qkw2bnolMmIzYzMxZ3Ql MmZTeGx1blJFWSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2Rv Y3VtZW50L2QvMTJlS2ZrZEM3ZzVJR1VDdGdoemc3V2lfX3FpRWtZNjVmWDA5bjhzakx0SGc8L2E+ Jmd0Ozxicj4NCjxicj4NCk9mIGNvdXJzZSwgdGhlIHdvcmtpbmcgZ3JvdXAgYW5kIHRoZSBzcGVj IGVkaXRvcnMgbmVlZCB0byBmb3JtYWxseSBkZWNpZGUgd2hldGhlciB0aGlzIGlzIGEgZGlyZWN0 aW9uIHRoZXkgaW4gZmFjdCB3aXNoIHRvIGhlYWQuPGJyPg0KPGJyPg0KSSBub3RlIHRoYXQgdGhl IHdnIGNoYXJ0ZXIgZG9lcyBub3QgZXhwbGljaXRseSBpbmRpY2F0ZSB0aGF0IHRoZSBUQiBQcm90 b2NvbCB3aWxsIGJlIGFwcGxpY2FibGUgdG8gb25seSBUTFMsIGJ1dCBhbHNvIGRvZXMgbm90IGV4 cGxpY2l0bHkgc3RhdGUgZ2VuZXJhbGl6YXRpb24gZm9yIG90aGVyIHVuZGVybHlpbmcgU1RMcyAo c2VjdXJlIHRyYW5zcG9ydCBsYXllcnMpLiBUaGUgY2hhcnRlciBkb2VzLCBob3dldmVyLCB3cnQg YXBwIGxheWVyIHByb3RvY29scw0KIHN0YXRlIChmd2l3KS4uPGJyPg0KPGJyPg0KJnF1b3Q7TWFr ZSB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB1c2VhYmxlIGluIGNvbWJpbmF0aW9uIHdpdGgg YSB2YXJpZXR5IG9mIGFwcGxpY2F0aW9uIHByb3RvY29scyZxdW90Ozxicj4NCjxicj4NCjxicj4N CiZndDsgSSBkb24ndCBzZWUgYW55IHRleHQgZXN0YWJsaXNoaW5nIHJlcXVpcmVtZW50cyBvbiB0 aGUgU1RMIGFuZCB0aGU8YnI+DQomZ3Q7IHRva2VuIHRoYXQgaXQgZXhwb3J0cy4mbmJzcDsgVGhh dCB3b3VsZCBzZWVtIHRvIGJlIGltcG9ydGFudC48YnI+DQo8YnI+DQp0aGUgcmVxdWlyZW1lbnRz IG9uIHRoZSBTVEwsIGFncmVlZC4gV1JUICZxdW90O3Rva2VuIHRoYXQgaXQgZXhwb3J0cyZxdW90 OyAtLSBhcmUgeW91IHJlZmVycmluZyB0byBrZXlpbmcgbWF0ZXJpYWwgZXhwb3J0ZWQgZnJvbSB0 aGUgdW5kZXJseWluZyBTVEwsIGZvciB3aGljaCB0aGVyZSdzIGNyeXB0b2dyYXBoaWMgYW5kIGJl aGF2aW9yYWwgcmVxdWlyZW1lbnRzIChlZyBhcyBleHByZXNzZWQgaW4gUkZDNTcwNSkgPyBpZiBz bywgYWdyZWVkLjxicj4NCjxicj4NCmVnLCB3aGVuIHRoZSBxdWljIGZvbGsgd3JpdGUgdGhlaXIg SS1EIGVxdWl2YWxlbnQgdG8gZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLCBpdCB3aWxsIGxpa2Vs eSBuZWVkIHRvIGRvY3VtZW50IHRoZSB1c2Ugb2YgcXVpYydzIGtleWluZyBtYXRlcmlhbCBleHBv cnRlciBmdW5jdGlvbiAodGhlIGxhdHRlciB3aGljaCB3aWxsIGl0c2VsZiBuZWVkIHRvIGJlIGRv Y3VtZW50ZWQgYSBsYSBSRkM1NzA1KTxicj4NCjxicj4NCk5vdGUgYWxzbyB0aGF0IGdpdmVuIHRo ZSBjcnlwdG8gZGlyZWN0aW9uIFRMUyAxLjMgaXMgaGVhZGVkIChkZXByZWNhdGlvbiBvZiB0aGUg UFJGKCkgZnVuY3Rpb24pLCBhbmQgaXRzIG5vdC15ZXQtZmxlc2hlZC1vdXQga2V5aW5nIG1hdGVy aWFsIGV4cG9ydGVyLCB0aGF0IFJGQzU3MDUgYXJndWFibHkgZG9lcyBub3QgYXBwbHkgdG8gVExT IDEuMywgYW5kIHRodXMgVExTIDEuMyB3aWxsIG5lZWQgdG8gYmUgdHJlYXRlZCBhcyB5ZXQgYW5v dGhlciBTVEwNCiBmcm9tIHRoZSBUb2tlbiBCaW5kaW5nIFByb3RvY29sIHBlcnNwZWN0aXZlLCBp dCBzZWVtcyB0byBtZSBhdCB0aGlzIHBvaW50Ljxicj4NCjxicj4NCkhUSCw8YnI+DQo8YnI+DQo9 SmVmZkg8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7 IE9uIDIxIEZlYnJ1YXJ5IDIwMTYgYXQgMTE6NDEsID1KZWZmSCAmbHQ7PGEgaHJlZj0ibWFpbHRv OkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+SmVmZi5Ib2Rn ZXNAa2luZ3Ntb3VudGFpbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBJIHNjcmF3 bGVkIGJhY2sgb24gV2VkLCAyNyBKYW4gMjAxNjo8YnI+DQomZ3Q7Jmd0OyZndDsgb24gRnJpLCAx OCBTZXAgMjAxNSAxOTowNTozMCAmIzQzOzAwMDAgQW5kcmVpIFBvcG92PGJyPg0KJmd0OyZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IFFVSUMncyB1c2Ugb2YgVEIgd2ls bCByZXF1aXJlIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiB3aXRoIHRoZWlyIG93bjxicj4NCiZn dDsmZ3Q7Jmd0OyAmZ3Q7IFRCIHBhcmFtZXRlcnMgbmVnb3RpYXRpb24gbWVjaGFuaXNtLCBhbmQg dGhlaXIgb3duIGJpbmRpbmcgbWV0aG9kPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgKGFuYWxvZ291 cyB0byBFS00gZm9yIFRMUykuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IElT VE0gYXQgdGhpcyB0aW1lIHRoYXQgZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA0IG5lZWRz IGEgYml0IG9mIHdvcms8YnI+DQomZ3Q7Jmd0OyZndDsgaW4gb3JkZXIgdG8gbWFrZSBpdCB0cnVs eSBhZ25vc3RpYyB3cnQgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IHByb3RvY29sPGJyPg0KJmd0 OyZndDsmZ3Q7IChpLmUuLCBUTFMgb3IgUVVJQyBvciB3aGF0ZXZlcikuPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHNlZTogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMvcHVsbC8xNSIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMvcHVsbC8x NTwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEluIHRoZSBzcGlyaXQgb2Ygc3VwcG9y dGluZyAmcXVvdDtzZWN1cml0eSBwcm90b2NvbHMgb3RoZXIgdGhhbiBUTFMgYW5kPGJyPg0KJmd0 OyZndDsgYXBwbGljYXRpb24gcHJvdG9jb2xzIG90aGVyIHRoYW4gSFRUUCZxdW90OywgYXMgQW5k cmVpIG5vdGVkIGhlcmUuLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUmU6IFtVbmJlYXJh YmxlXSBTaG91bGQgVG9rZW4gQmluZGluZyBzdXBwb3J0IG5vbi1UTFMgYXBwbGljYXRpb25zPzxi cj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbC1hcmNoaXZl JTJmd2ViJTJmdW5iZWFyYWJsZSUyZmN1cnJlbnQlMmZtc2cwMDI4Ny5odG1sJmFtcDtkYXRhPTAx JTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjODE5ZWY1ODc4MzdjNDk0ODQ4 NTYwOGQzM2JlOTAyODUlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1w O3NkYXRhPUhNTFBqbGJna08yemlqb3d1NUpSMnFHMiUyZlJjeXlxZkpvUDhpYmk4ZWFWZyUzZCIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi91 bmJlYXJhYmxlL2N1cnJlbnQvbXNnMDAyODcuaHRtbDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IC4uSSd2ZSBkcmFmdGVkIHdoYXQgc2VlbSB0byBiZSB0aGUgbWluaW1hbCBjaGFuZ2Vz IHRvPGJyPg0KJmd0OyZndDsgZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA0IGluIG9yZGVy IHRvIG1ha2UgdGhlIFRCIHByb3RvY29sIGl0c2VsZjxicj4NCiZndDsmZ3Q7IGFnbm9zdGljIHRv IHRoZSBzZWN1cmUgdHJhbnNwb3J0IGxheWVyIHVuZGVybHlpbmcgdGhlIGFwcGxpY2F0aW9uIGxh eWVyLCBhbmQ8YnI+DQomZ3Q7Jmd0OyB0byBnZW5lcmFsaXplIGZyb20gSFRUUC48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vdGUgdGhhdCB0aGUgYWRtb25pdGlvbnMgd3J0IFRMUyAxLjIg KGFuZCBlYXJsaWVyKSBUcmlwbGUgSGFuZHNoYWtlIHZ1bG48YnI+DQomZ3Q7Jmd0OyBhbmQgcmVt ZWRpYXRpb25zIHRoZXJlb2YsIG5vdGVkIGluIHNlY3Rpb25zIDQgYW5kIDguNSwgYXJlIHJlbW92 ZWQgZW50aXJlbHkuPGJyPg0KJmd0OyZndDsgVGhpcyBpcyBmb3IgdHdvIHJlYXNvbnM6ICgxKSB0 aGlzIGlzIFRMUy1zcGVjaWZpYywgYW5kICgyKSBpcyBhbHJlYWR5PGJyPg0KJmd0OyZndDsgYWRk cmVzc2VkIGRyYWZ0LWlldGYtdG9rYmluZC1uZWdvdGlhdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IE90aGVyIHRoYW4gdGhhdCwgYW5kIHVwZGF0aW5nIHRoZSBzcGVjJ3MgdGl0bGUs IHRoZSBjaGFuZ2VzIGFyZSBmYWlybHk8YnI+DQomZ3Q7Jmd0OyBtaW5vci48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEhvd2V2ZXIsIHN0aWxsIHRvIGJlIGRvbmU6PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAxLiBNb3ZlIHRoZSBUTFMtc3BlY2lmaWMga2V5aW5nIG1hdGVyaWFsIGV4 cG9ydGluZyBsYW5ndWFnZSB0bzxicj4NCiZndDsmZ3Q7IGRyYWZ0LWlldGYtdG9rYmluZC1uZWdv dGlhdGlvbi48YnI+DQomZ3Q7Jmd0OyAyLiBmdXJ0aGVyIHN1cmdlcnkgbmVlZGVkIHRvIGZ1bGx5 IGdlbmVyYWxpemUgZnJvbSBIVFRQLXNwZWNpZmljIGFwcCBsYXllcjxicj4NCiZndDsmZ3Q7IGFz c3VtcHRpb25zLjxicj4NCiZndDsmZ3Q7IDMuIEkgaGF2ZSBmdXJ0aGVyIGRldGFpbGVkIGZlZWRi YWNrIG9uIGRyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNCBzdGlsbDxicj4NCiZndDsmZ3Q7 IHRvIHBvc3QgKGNvbWluZyBzb29uKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgdmlzdWFs IHNpZGUtYnktc2lkZSBkaWZmIGF2YWlsYWJsZSBoZXJlOjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAl M2ElMmYlMmZraW5nc21vdW50YWluLmNvbSUyZmRvYyUyZmRpZmYlMmZEaWZmLS1kcmFmdC1pZXRm LXRva2JpbmQtcHJvdG9jb2wtMDQudHh0LS10by0tZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29s LTA0Yi50eHQuaHRtbCZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0 LmNvbSU3YzgxOWVmNTg3ODM3YzQ5NDg0ODU2MDhkMzNiZTkwMjg1JTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT0wMEx3dWpPUEV1ZnhYNzByeUZJbEMwb0Ux TmFYWkNybnNybVNnblNJeGhrJTNkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8va2luZ3Ntb3Vu dGFpbi5jb20vZG9jL2RpZmYvRGlmZi0tZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA0LnR4 dC0tdG8tLWRyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNGIudHh0Lmh0bWw8L2E+PGJyPg0K Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlz dGluZm8lMmZ1bmJlYXJhYmxlJmFtcDtkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNy b3NvZnQuY29tJTdjODE5ZWY1ODc4MzdjNDk0ODQ4NTYwOGQzM2JlOTAyODUlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXZlMExSUmxmS2I5YTkwREpZeFRQ N1VVUiUyZkU1WndxYXBjS01tNTZLN1kwQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_BLUPR03MB139661179CC30C0CC4AEF3F98CA40BLUPR03MB1396namp_-- From nobody Tue Feb 23 07:32:16 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A291A1B9C for ; Tue, 23 Feb 2016 07:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 vIpHFW0T7qP5 for ; Tue, 23 Feb 2016 07:32:14 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 D8FB21ACF59 for ; Tue, 23 Feb 2016 07:32:08 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id 78so117484958lfy.3 for ; Tue, 23 Feb 2016 07:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=GqLZkc1rg3SnaULB5nuHt4g7TgoGYB+n2PHK7mKApws=; b=ue/XUbc4Mls3PsTtieaAaHoHeuiyMipdD1ofx8K8TMGJ76I2kPqclY8JV7asYxTzv5 vueo9gM7RrbTYBu1QAwTSjzFpk7+E8MC/CRwBok9RqXNw+ramslCW5TLBV+PXj0Pmt6E T7WFmcgmH5FZJsEitoEtO2Xb+Qs6vWuY+aeHATLaXoFY1h4EMxQU6AmidJ+1v2UjI+HV 9jfDTjIGImxdD7MddW/P6xEzzg727rX+bNtnWBEh3BpCgi/DCcZDk1T39Jk4DsUnxsf0 bWe/3mgFQyqYqKX+YsAn8kogi+SWVXDfBvAr6dxxPR9ufkvRdLOw0a2Qm67SghyYChge Ntiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=GqLZkc1rg3SnaULB5nuHt4g7TgoGYB+n2PHK7mKApws=; b=Ia/9cRBODcG9xBw1NanY7mcUZ3r9aszt7slRRxANqk+OGGvoHnuuDN7UktkAQXw+JH 847LSFltA4AUaRqgCK+tvTpknyiUBpauVGZi/IRXoJN/TVCG+ovrYqw04kWNfZy3bW6p ozbwr9ibzDCIlvMUYK2ieT/jz5nTU9sCc5ptbyAc42OhuuAi9w32PVKbimyU/C7MpI/l DrbNBt1O6ItTVW8kDDTGEJ6ir50/FE/izuay4TlJA/z6ofa5ZcABoGHzyOkA/eYO7lLx oZ/QwkzYlPwTr5780Uzuo05A1mKs4cCXAcJLZs7latF2vJuysryKu8LVxW9rzJYdG+tO Botw== X-Gm-Message-State: AG10YOQBvYl4H74vn0Huf5dZZ7KXVc2c80akhiK90qTNJpqk0Rxb6cCAeLYWjifRdUCRdw== X-Received: by 10.25.207.204 with SMTP id f195mr12450122lfg.41.1456241527127; Tue, 23 Feb 2016 07:32:07 -0800 (PST) Received: from [10.0.0.109] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.googlemail.com with ESMTPSA id k65sm4185877lfe.41.2016.02.23.07.32.05 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 07:32:05 -0800 (PST) To: unbearable@ietf.org References: <56CB5CC8.8080104@KingsMountain.com> From: Leif Johansson Message-ID: <56CC7B73.1080908@mnt.se> Date: Tue, 23 Feb 2016 16:32:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 23 Feb 2016 15:32:16 -0000 On 2016-02-23 02:06, Andrei Popov wrote: > Thanks Jeff for reviewing the documents and providing the pull request. > I am not opposed to the overall goal of this PR. > > > > If the WG decides to pursue this type of change, I think we would either > need a new I-D that will contain TLS-specific information (primarily > parameters for the key exporters and TLS-specific security > considerations), or draft-ietf-tokbind-negotiation would need to be > expanded and transformed into draft-ietf-tokbind-tls. > this does represent a major change (not measuring by words but by scope) and there has to be pretty strong consensus from the WG to take this on. Cheers Leif From nobody Tue Feb 23 09:50:19 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546FE1B3679 for ; Tue, 23 Feb 2016 09:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 V0HgOCbVUKTI for ; Tue, 23 Feb 2016 09:50:16 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 C93631ACD24 for ; Tue, 23 Feb 2016 09:50:16 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id g203so220885113iof.2 for ; Tue, 23 Feb 2016 09:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jRuOd6Cwi9bhmzeQEzve1lYzZjTg+fGP3ITBBRHxlMM=; b=G50dsPoxlKvNnJvWENZz2s3EZ7xyXdseGajhgpVXipmoAtIkH1mU15pvIpTPNgltVz WpTzjPW4DmaCoT/2PXzKoBXQIKlM5JQaBFpqgexwnJ21IBfi5Bru1f2+Zs+MJe1YKXFq 0zFTbavEIaJdB2zTTTh+0asXlIA373HEgPn50Cqma2hzfJTC+BvDzeJWDoBDpOpKMTRz FWErh+nFF90/gF2l9mrYNC66dX1zffuXAe1LPup4kXOQfDPp3uH31WKVyMkDaJm5jybA xAq5SGc5A3hWaBDOHA8r9i8+MrVR/BDS+JhQ5Rb62Xq1CH74q77wVzi5KBDYEsoiW9ol qHBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jRuOd6Cwi9bhmzeQEzve1lYzZjTg+fGP3ITBBRHxlMM=; b=J0IkimtVRIYwTSO6t8onl09SJllyog0dPi4eyVtAvUyfAOUbGVZ5Lp5tPI6/90eKqq sJBLlvmw0hr3wsZLXSjfoaHmBEcxk+gAvTflcLKhDn2D6R2rZhyC/vK6miNfl5efrVQ6 7SI6YClSoGS6u+Em256wEuBJzG5MZHT6LOEdKPsF5U12QgBymto1el5sRIbDCnYbNb2V r7zBh4G5bqcpSCRXDpXQG0FnGaKzeynmwrZeDU6KYErbdk2U4I6irxHa+G2CqUvhL0Mo YhLuhNzZOCfgmTeWM1yP7CWrr8SZqgSCvcLfEAM0XnuCZcz8NiN1YX3F/+z/4OFkmA1s MC5g== X-Gm-Message-State: AG10YOQOvpcodJFm/KxMZvX8N1hD7p/lIq1g6zyMuKxC7Zqu4CvZWb12Fr8xs/RemqlQuwHOYfdPhKKzEEq0OA== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr37234408iod.190.1456249816205; Tue, 23 Feb 2016 09:50:16 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 09:50:16 -0800 (PST) In-Reply-To: <56CC7B73.1080908@mnt.se> References: <56CB5CC8.8080104@KingsMountain.com> <56CC7B73.1080908@mnt.se> Date: Tue, 23 Feb 2016 09:50:16 -0800 Message-ID: From: Martin Thomson To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 23 Feb 2016 17:50:18 -0000 On 23 February 2016 at 07:32, Leif Johansson wrote: > this does represent a major change (not measuring by words but by scope) > and there has to be pretty strong consensus from the WG to > take this on. I don't think that this is a good idea. If there is a need for this capability in other places, then we can discuss that need. Given that QUIC is basically HTTP and will eventually use TLS, the problem will solve itself there, so that leaves us generalizing something without a customer for that generalization. I've noted a couple of concerns with the approach in the PR. I'm not confident that those are the only problems we'd have to solve. Avoiding an abstraction layer at this point avoids having to do all that work and completely avoids the risk that we mess it up. From nobody Tue Feb 23 10:22:22 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C41B3F16 for ; Tue, 23 Feb 2016 10:22:12 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Fj5CsqJDwyG0 for ; Tue, 23 Feb 2016 10:22:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C924B1B3F05 for ; Tue, 23 Feb 2016 10:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sA7mIuu4IcRncLhTWrsXWQGNW7ZsR8zOlfMUArfvtxw=; b=csySdGYow2va2aN2eh3PCelp2a0l9DLassNn95xxPnU3I09QTEzkFdsmi4/bfWC95npxU0xic30ouolh1qlZhkHY23dfmCxxhf+kww+gkeBkxhV5cktRnvR/R0xl0jqeKWhcK5ZF8nu02yC39EJaUwOLw3ILy2gK/z82SE4vZAc= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 18:21:46 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 18:21:46 +0000 From: Andrei Popov To: Martin Thomson , Leif Johansson Thread-Topic: [Unbearable] Should Token Binding support non-TLS applications? Thread-Index: AQHRbaR6BqcNTIsNp0msYAg2PolnoZ84yFcAgAACtWCAAPhbgIAAJp4AgAACC2A= Date: Tue, 23 Feb 2016 18:21:46 +0000 Message-ID: References: <56CB5CC8.8080104@KingsMountain.com> <56CC7B73.1080908@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: 3ce258f4-5dec-4be5-bbe0-08d33c7e309b x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:ua+Wm5rGrEA4CfF4m2T6SsIvAaxqz4h3FScA37lWNF+8oA4J3Lkwc815r2NWASTKUSWo5KT0wS/IfIzfjKucQVPNtKpJpW0uXVArotgs/6BFiVfYCMe2blyfTrnHoWPTUiqK62clnAqwtWbXxIPJZg==; 24:81C5mrfmpxnh7zvYBSnFY0Gc+OHmFriZ38J8LrJoVT4eixC1gO71w120p8GFMTn4+VNDr+wlV7AMFzNOAzMrrvpcN/rBbIYXGmfxMHXNv1U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(24454002)(13464003)(377454003)(87936001)(40100003)(122556002)(10090500001)(93886004)(86612001)(86362001)(50986999)(76176999)(54356999)(3660700001)(99286002)(11100500001)(106116001)(1220700001)(10290500002)(10400500002)(5005710100001)(8990500004)(5008740100001)(5004730100002)(6116002)(586003)(102836003)(1096002)(33656002)(4326007)(5001770100001)(189998001)(74316001)(92566002)(15975445007)(5003600100002)(77096005)(19580395003)(5001960100002)(2950100001)(5002640100001)(2900100001)(2906002)(3280700002)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 18:21:46.4992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 23 Feb 2016 18:22:12 -0000 > this does represent a major change (not measuring by words but by=20 > scope) and there has to be pretty strong consensus from the WG to take=20 > this on. Yes, let the WG decide. At this time, I don't feel strongly either way. > Avoiding an abstraction layer at this point avoids having to do all that = work and completely avoids the risk that we mess it up. I think that publishing TBPROTO and TBNEGO in their current form would not = preclude future documents describing the use of the Token Binding protocol = with e.g. Kerberos or DTLS. And Martin's point about delaying the generaliz= ation until we have a few adaptations to various STLs makes sense to me.=20 Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin T= homson Sent: Tuesday, February 23, 2016 9:50 AM To: Leif Johansson Cc: unbearable@ietf.org Subject: Re: [Unbearable] Should Token Binding support non-TLS applications= ? On 23 February 2016 at 07:32, Leif Johansson wrote: > this does represent a major change (not measuring by words but by=20 > scope) and there has to be pretty strong consensus from the WG to take=20 > this on. I don't think that this is a good idea. If there is a need for this capabi= lity in other places, then we can discuss that need. Given that QUIC is ba= sically HTTP and will eventually use TLS, the problem will solve itself the= re, so that leaves us generalizing something without a customer for that ge= neralization. I've noted a couple of concerns with the approach in the PR. I'm not confi= dent that those are the only problems we'd have to solve. Avoiding an abstraction layer at this point avoids having to do all that wo= rk and completely avoids the risk that we mess it up. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue Feb 23 16:43:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F201A21B5 for ; Tue, 23 Feb 2016 16:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 1X3WweOZNk6D for ; Tue, 23 Feb 2016 16:43:24 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 82AD81A21B4 for ; Tue, 23 Feb 2016 16:43:24 -0800 (PST) Received: (qmail 10590 invoked by uid 0); 24 Feb 2016 00:43:22 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 24 Feb 2016 00:43:22 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id N0jJ1s0072UhLwi010jMGh; Tue, 23 Feb 2016 17:43:22 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=OQYI39TyycwA:10 a=jFJIQSaiL_oA:10 a=L6GK3tcXQbM5tLIp7doA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=J+LXHquIWU7yLbotjHrlsvVer+SahfN3tchhtjOHAoM=; b=1TVIChNUpkLP6JG03KycGa+wqbfEUFscfFSCSn9Va1YnOlnluXmOWYyVOouOJae0mwyCYIS4sOBhIemiSd1pJKlFRtPjYEfDA7138zCJntaonfMZJ5b0DT3KRSstoSWp; Received: from [70.197.23.113] (port=2691 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYNXx-0002c5-QF; Tue, 23 Feb 2016 17:43:17 -0700 To: Nick Harper From: =JeffH Message-ID: <56CCFC9F.5080505@KingsMountain.com> Date: Tue, 23 Feb 2016 16:43:11 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.23.113 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 00:43:25 -0000 > QUIC crypto is destined to die (and be replaced by TLS 1.3), so I wouldn't > worry about making spec changes to accommodate QUIC specifically. well, it depends to some degree on how QUIC's reliance on TLS 1.3 ends up being specified -- there's not an internet-draft for that as yet, correct? > However, I agree with Jeff about TLS 1.3 needing to be treated > differently from the Token Binding Protocol perspective because of the > difference in keying material exporters. noted, thx. =JeffH From nobody Tue Feb 23 16:45:50 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA9A1B2A47 for ; Tue, 23 Feb 2016 16:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no 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 pmBtFC2nlhar for ; Tue, 23 Feb 2016 16:45:42 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 0FF9D1ACF1A for ; Tue, 23 Feb 2016 16:45:42 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id r207so1439297ykd.2 for ; Tue, 23 Feb 2016 16:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tzErhlAf27A0dgeQXfccmW3y8Q3lGQLrkeVeF7Ex/kk=; b=Tj23vrDzinsl4FxrzWTb1kz5DJw6HXjQera34M82vhzZAAhD/kedO9Xbbj3Xd9tC5S 6uiyTZcjCpbCr9ADeaKtnvpIOt+rX3IJzEmvsTGgPKycq6qTNA2IHbrJEyF6xwNDfLNl 4d1iDsb50D6kSu30x6fECeuFIw3n9opQhoW8bu/NQ7cdfJVPso+8r9UeRpuJAhxvApvh BlJuyrnk+l2g+4ULWh1zkvl5w0WeqdB6MBRsoQOG0BMvdMEVDyiyg/hH6SxQSk31kekJ TZn0mw37oqXsu33IfIio6xrMs+KRPhDcoAB+B3WbwTNig/ZUGRqeV7IFMpx2bcZ9+AI1 QDyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tzErhlAf27A0dgeQXfccmW3y8Q3lGQLrkeVeF7Ex/kk=; b=Pjl0bHKUY6m6s6U3TBCDGyQ24y1k8W9Lr6bBV2bRnegLxUqBAczGXbOhbf4hUhdPHr ZHrgFUeLP25rh9wN8vuV1Poba/vgLC4VAoIhFAq7Z0jWfrBOvnSUaoMcoZWbKwHCM3Hr lJeh0WMARHXKawatKV6hWX86ti0HRcmE2HbC45s8xmRRFXzhFK6CHG6u2wlhF2EXmwPU +FmmPojcqzzt8mhovyWMjHxkNKlStdxNcHEz+yuhUw5w4/7U4dQC/9R+leaA5u+ZgA6B EJXylgXQccTbpMovs5VEgzkbQx26MVcLico4ZqkVdQMf8Gfwrfd2IoaZTDSHpJEoPC/9 NszA== X-Gm-Message-State: AG10YOR1ASaRAszXUQuNxc/See05Vs4xR8jZhJXp5lAqud4saNP8JcBQxktZrYBYptdp/ytqka+D6D3ouofg6w== X-Received: by 10.37.230.210 with SMTP id d201mr1161747ybh.74.1456274741343; Tue, 23 Feb 2016 16:45:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 23 Feb 2016 16:45:01 -0800 (PST) In-Reply-To: <56CCFC9F.5080505@KingsMountain.com> References: <56CCFC9F.5080505@KingsMountain.com> From: Eric Rescorla Date: Wed, 24 Feb 2016 08:45:01 +0800 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=94eb2c0a8b54a76f29052c7962cc Archived-At: Cc: IETF Tokbind WG , Nick Harper Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 00:45:43 -0000 --94eb2c0a8b54a76f29052c7962cc Content-Type: text/plain; charset=UTF-8 On Wed, Feb 24, 2016 at 8:43 AM, =JeffH wrote: > > QUIC crypto is destined to die (and be replaced by TLS 1.3), so I > wouldn't > > worry about making spec changes to accommodate QUIC specifically. > > well, it depends to some degree on how QUIC's reliance on TLS 1.3 ends up > being specified All the integrations I have seen would probably have similar properties. > -- there's not an internet-draft for that as yet, correct? Correct: MT is working on one, but it's not quite ready yet... -Ekr > > > > However, I agree with Jeff about TLS 1.3 needing to be treated > > differently from the Token Binding Protocol perspective because of the > > difference in keying material exporters. > > noted, thx. > > =JeffH > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --94eb2c0a8b54a76f29052c7962cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 24, 2016 at 8:43 AM, =3DJeffH <Jeff.Hodges@kin= gsmountain.com> wrote:
> QUIC crypto is destined to die (and be replaced by TLS 1.= 3), so I wouldn't
> worry about making spec changes to accommodate QUIC specifically.

well, it depends to some degree on how QUIC's reliance on TLS 1.3 ends = up being specified

All the integrations I h= ave seen would probably have similar properties.

= =C2=A0
-- there's not an internet-= draft for that as yet, correct?

Correct: MT= is working on one, but it's not quite ready yet...

-Ekr




> However, I agree with Jeff about TLS 1.3 needing to be treated
> differently from the Token Binding Protocol perspective because of the=
> difference in keying material exporters.

 noted, thx.

=3DJeffH



_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=

--94eb2c0a8b54a76f29052c7962cc-- From nobody Tue Feb 23 17:19:38 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DCB1B3FB2 for ; Tue, 23 Feb 2016 17:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 1je7C802Tel7 for ; Tue, 23 Feb 2016 17:19:35 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 4BD231B3FB0 for ; Tue, 23 Feb 2016 17:19:35 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id g203so11990955iof.2 for ; Tue, 23 Feb 2016 17:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ItBcgbIJmDkt4hF6Oh4C4Sh9doD4T2CuoheBvhv7vDA=; b=DnHYuriizUcb0dcS3AoSsPrHQ2OTGsqRcG46baZEftOIwcTXOf2CuK8FN9CSlN2bJH 41In8n2Es7ixqPhJ55xSU04uleT6z7xQVrMpMSibP54Jy9UkHp2oFtligSjnjMLZibom HzEW1/M3c6UmSzT7zDNcqpYUrqfENgDrAFrI7Dpr4Z/SE+Dsz2muf5h1FsJOa38nsfFt +xk2z2vDLQa3ZrfQ8iAGbLvaYJjAvy6Q9YN/VRaCp7N4+zw9lkL+oGGqFQwt5lTL+IcM ZUp/E4dR1lbx5C7RfWfmpmfL1UH9XVFYQtTDrdS4rozjDzWL38ISvOiN8GccJafPFec2 CVkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ItBcgbIJmDkt4hF6Oh4C4Sh9doD4T2CuoheBvhv7vDA=; b=kbm5yGp4fJcl22Y9um1JYtLecISBTyEdB5/2jDWXHTPZ5Nw1wEI+nggvISWvW67wxB eE52oQiWpW+JMsKRGXnen2uTg5cXjxIs9C40WP8G5qvdfcF/4UIWpJCluntQ0mMsZa76 gaEhsIVdQvtEJVB8i0TpUNIQCLw7DIF5pkKhCtiGO8NkmSJWx6c1EpcyvMFCyPmp8rGV m/B5HiqGS3UzQsamGP0lgmP/+aFhbbj4XSBGdG9o5uiRQEWEhJkQnprx2Fu4AokHXp9g N/nGJLFQq7b6HnIGnLKdcvT03yxNuADS66Zc0tELIalz18OYTR3kwlKy7JmDauWsSg0n qaAw== X-Gm-Message-State: AG10YOQwb5RUDxwD+UKgnSA6S0sTypQIXytPVUMjuYK+MjM8JGE1FwbBvCmjl1zS5FdKsn8r+flcwy437zH3BQ== MIME-Version: 1.0 X-Received: by 10.50.20.129 with SMTP id n1mr20797409ige.77.1456276774679; Tue, 23 Feb 2016 17:19:34 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 17:19:34 -0800 (PST) In-Reply-To: References: <56CCFC9F.5080505@KingsMountain.com> Date: Tue, 23 Feb 2016 17:19:34 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Tokbind WG , Nick Harper , =JeffH Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 01:19:36 -0000 On 23 February 2016 at 16:45, Eric Rescorla wrote: > Correct: MT is working on one, but it's not quite ready yet... Well, I have two already. From nobody Wed Feb 24 10:27:11 2016 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AE61B34E0; Fri, 19 Feb 2016 12:15:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 12:15:41 -0800 Archived-At: X-Mailman-Approved-At: Wed, 24 Feb 2016 10:27:10 -0800 Cc: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Unbearable] tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Feb 2016 20:15:42 -0000 A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: httpbis oauth Second Priority: jose Special Requests: Avoid entire SEC area --------------------------------------------------------- From nobody Wed Feb 24 11:06:46 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064C81B38CF for ; Wed, 24 Feb 2016 11:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 RNu2kU_clZV6 for ; Wed, 24 Feb 2016 11:06:40 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 6650E1B3B15 for ; Wed, 24 Feb 2016 11:06:37 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id g62so287132584wme.1 for ; Wed, 24 Feb 2016 11:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aTJW7ncwhcwBSjdVbwkjzhVfRiRweynXDQgzHI3CES8=; b=bRTG97hG6GMkkgU8MvdcQK3zaXEdCGgo9HswkyobbF1iGLOHQWf0gfUkWaVMLo1Zd+ R71EswLW/elR4eexk6Qz3xTceUFdtMDvYUbfLkPGon5j+VDJ8vfI79+wYFSCgag4RKsc 34v2O7y8IiGWR3xHa2RjFo4ZG1jKSaAml6emXNHBAsrCvAQkNBAaligvJcf05y8bwbN3 mOgDYq+A7Guqg4Sxfm1oNrGG79nWIA3nYW/rH/ZNUPbTfDkG+upna9j74LGSlwOyf84D NsGmZcFCg+a8IkO3KtR6Gp2f2YRKWw3jfvMMn++ekf3uDA3uPHgFdt5UKIn91tRL5d0l W7jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aTJW7ncwhcwBSjdVbwkjzhVfRiRweynXDQgzHI3CES8=; b=nI5aODmDZ6aSyLyVh9HNOdtnuySA3SyssBbavfAwXEvPj9D6Zy8yiFDCVUdA6zQHF7 8qEeev1snwc65hiGAukb93s2ISrer+0lCZ1TUfcZGGNtWiCpTG20tifY7mRTm0NXNu1j wu8AU0bHsLio3fudnStcgufvFFoFqsSqEdDFHjw0+IdZobcb7Zwj0IJxszho3TWb0NFw uyjKOAfAcwDuUdhMSsRXmJIC1pOAmFaImGMwCyMBB9zgR0jV/PDYSWF0CaZ+gdx5xuwI 0CBASQJY0G3YyV2O5vG673Lt1msauEhQUxh4BqpdsTCZNr+e56gQ0wm76Hi+0l8WOVhT 7gqQ== X-Gm-Message-State: AG10YOSGgtTJpy1YQ/E6bwO43BQCy9+Vc3QYjvwSIu7dd6GQvf0kXqicdk4+3VSjn+TjWnjCSrtpOXeKZjePhfYY MIME-Version: 1.0 X-Received: by 10.194.123.102 with SMTP id lz6mr46361349wjb.2.1456340795821; Wed, 24 Feb 2016 11:06:35 -0800 (PST) Received: by 10.28.157.88 with HTTP; Wed, 24 Feb 2016 11:06:35 -0800 (PST) In-Reply-To: References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> <56C77DD0.8020303@sunet.se> Date: Wed, 24 Feb 2016 11:06:35 -0800 Message-ID: From: Vinod Anupam To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e01160950ceedf1052c88c332 Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" , Leif Johansson Subject: Re: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 19:06:44 -0000 --089e01160950ceedf1052c88c332 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I too will attend esp. if TB will be discussed. cheers, -Anupam On Fri, Feb 19, 2016 at 12:59 PM, Eric Rescorla wrote: > I will be there > > On Fri, Feb 19, 2016 at 1:58 PM, Andrei Popov > wrote: > >> So far I'm planning on attending, esp. if TB will be discussed. >> >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif >> Johansson >> Sent: Friday, February 19, 2016 12:41 PM >> To: unbearable@ietf.org >> Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IET= F >> 95 >> >> >> I'm not 100% we decided if we needed a session in BA but I have put in a >> slot request just the same. >> >> Am I right in thinking that at least some of the key contributors will b= e >> in BA? >> >> Cheers Leif >> >> >> -------- Forwarded Message -------- >> Subject: tokbind - New Meeting Session Request for IETF 95 >> Date: Fri, 19 Feb 2016 12:15:41 -0800 >> From: "IETF Meeting Session Request Tool" >> >> To: session-request@ietf.org >> CC: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, >> stephen.farrell@cs.tcd.ie >> >> >> >> A new meeting session request has just been submitted by Leif Johansson, >> a Chair of the tokbind working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Token Binding >> Area Name: Security Area >> Session Requester: Leif Johansson >> >> Number of Sessions: 1 >> Length of Session(s): 2 Hours >> Number of Attendees: 75 >> Conflicts to Avoid: >> First Priority: httpbis oauth >> Second Priority: jose >> >> >> >> Special Requests: >> Avoid entire SEC area >> --------------------------------------------------------- >> >> >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= etf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40m= icrosoft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd= 011db47%7c1&sdata=3DTvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --089e01160950ceedf1052c88c332 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I too will attend esp. if TB will be discussed.

cheers,
-Anupam
On Fri, Feb 19, 2016 at 12:59 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
I will be there

On Fri, Feb 19, 2016 = at 1:58 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
So far I'm planning on atte= nding, esp. if TB will be discussed.

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif Johansson=
Sent: Friday, February 19, 2016 12:41 PM
To: unbearable@iet= f.org
Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 9= 5


I'm not 100% we decided if we needed a session in BA but I have put in = a slot request just the same.

Am I right in thinking that at least some of the key contributors will be i= n BA?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif


-------- Forwarded Message --------
Subject: tokbind - New Meeting Session Request for IETF 95
Date: Fri, 19 Feb 2016 12:15:41 -0800
From: "IETF Meeting Session Request Tool"
<session_request_developers@ietf.org>
To: session-r= equest@ietf.org
CC: leifj@matema= tik.su.se, unb= earable@ietf.org, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie



A new meeting session request has just been submitted by Leif Johansson, a = Chair of the tokbind working group.


---------------------------------------------------------
Working Group Name: Token Binding
Area Name: Security Area
Session Requester: Leif Johansson

Number of Sessions: 1
Length of Session(s):=C2=A0 2 Hours
Number of Attendees: 75
Conflicts to Avoid:
=C2=A0First Priority: httpbis oauth
=C2=A0Second Priority: jose



Special Requests:
=C2=A0 Avoid entire SEC area
---------------------------------------------------------




_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https:/= /na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2f= mailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40microso= ft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DTvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable=


--089e01160950ceedf1052c88c332-- From nobody Wed Feb 24 11:11:54 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CCA1B2BDB for ; Wed, 24 Feb 2016 11:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 INkBxZG6rrYj for ; Wed, 24 Feb 2016 11:11:50 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 4D4A51A1B83 for ; Wed, 24 Feb 2016 11:11:49 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so44309642wme.0 for ; Wed, 24 Feb 2016 11:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=B8+gB55Z33N5inorM8GyiUd4TG+Cdln79yIzai6SKgY=; b=h0pZF4qrpJGcRG2IbkBiahCmhqVumQ04wvmoxI8cusEvk9drz6G3oJu3hPaCwu4WYX 888N6GyOWAsoF7tq/3kUbaVGMOa/K5MhIniOhOevEoHCpVx7QxEJ+RGEQ1ojTtWBE0vi /PRyOBiZ1HHlrtYt21IHEh41XE4+da4THxNuVOOC6pPzZDaIIrAaHX9iYEHK+oCClpvM JsR2jRF8PfEkF9zValIkwnkMc8syKX3dUdzPsJ20atu4aHjL07k5gwO2u3Dp0Lgp3z87 2ybzWOUhuTJD0DQU25UgclY8FUjgD8UlEIpszVfeUGzyRAdrmGdelQROBU+yibT5wym+ XEGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=B8+gB55Z33N5inorM8GyiUd4TG+Cdln79yIzai6SKgY=; b=FBOGomrg4yW2afzHvBOU+E287LIsNB/AZUdQgQlNlpMgo/ZqtTIR9vqapC9jukaPay NKMR7ri2VWoijb6LhBrc4kpMcIfFCcBEd7nVnh875ollMdold7HI6T5N6av+VdrAf7n6 25Ikw8T5q4Bu+PRYEBHDIz9jCK+gVrSaapTxXD34ogjZ5xAlJq2xvCkC3zcAcFbYr1Jl Y/1hYMCZ0uv7YFjyhmUMAJZdCzndzb6ANFuFHXx2Xo5IUB36hWvXnd658+OHQmH02yOF reB+3RwlgLN8OJynX15R6ZVFkY4+GSfAS53jphal2BUxqeM2aCWeVsX4bnFzRiIxVrPt cdLA== X-Gm-Message-State: AG10YOSRnRcxbtFYf/n4Q1IGu6lOljcVxlhffFxvMuWa2zpLp4LkOozRPbjg2oacejIeyA== X-Received: by 10.28.148.130 with SMTP id w124mr26171641wmd.71.1456341107689; Wed, 24 Feb 2016 11:11:47 -0800 (PST) Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id bg1sm4356832wjc.27.2016.02.24.11.11.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Feb 2016 11:11:46 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_AEA68B2E-9DC3-464A-912B-5420EFE326F5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 24 Feb 2016 20:11:44 +0100 Message-Id: <3134C6C7-8A8F-47A9-B281-9338251ADC33@ve7jtb.com> References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> <56C77DD0.8020303@sunet.se> To: Andrei Popov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "unbearable@ietf.org" , Leif Johansson Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 19:11:52 -0000 --Apple-Mail=_AEA68B2E-9DC3-464A-912B-5420EFE326F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am going. =20 > On Feb 19, 2016, at 9:58 PM, Andrei Popov = wrote: >=20 > So far I'm planning on attending, esp. if TB will be discussed. >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = Leif Johansson > Sent: Friday, February 19, 2016 12:41 PM > To: unbearable@ietf.org > Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for = IETF 95 >=20 > =09 > I'm not 100% we decided if we needed a session in BA but I have put in = a slot request just the same. >=20 > Am I right in thinking that at least some of the key contributors will = be in BA? >=20 > Cheers Leif >=20 >=20 > -------- Forwarded Message -------- > Subject: tokbind - New Meeting Session Request for IETF 95 > Date: Fri, 19 Feb 2016 12:15:41 -0800 > From: "IETF Meeting Session Request Tool" > > To: session-request@ietf.org > CC: leifj@matematik.su.se, unbearable@ietf.org, = tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie >=20 >=20 >=20 > A new meeting session request has just been submitted by Leif = Johansson, a Chair of the tokbind working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Token Binding > Area Name: Security Area > Session Requester: Leif Johansson >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 75 > Conflicts to Avoid: > First Priority: httpbis oauth > Second Priority: jose >=20 >=20 >=20 > Special Requests: > Avoid entire SEC area > --------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40mi= crosoft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd= 011db47%7c1&sdata=3DTvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d= >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_AEA68B2E-9DC3-464A-912B-5420EFE326F5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMjQxOTExNDRaMCMGCSqGSIb3DQEJBDEWBBQhwHUwmkYTyHwjA0hUaHGn fwu7HzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCMXIZadqL83zehhtHLONWVp8xY4hfRlszKR+2qUkjNl/hGIh5GtJxZ iL8SS2hzLGXtFCMGBvGryryFXG6pVHUX60fwkMZFjE8lxaJkNBDxngywwf//8EqrkwFPHN6Dfvz6 5ScMjwkH6ovZ6VLLALraRqbc8idj4m7NjHZj0PMlNIqAYNEjmna/1Vm9n3zdqGGC1npoximxpd4X HsQGMHgk8NOvNOZgHUivqkp1m2zRPRXsFj2JoltvBl/B5qLP17epZf94wD3e6ke97Qw+pM1y4jQx Jg/nQ22NJGVvV5q6IAmsM1KxwhfJzvXNXs+M7yQyAaFkE+G2WV6ZWDcL6rdqAAAAAAAA --Apple-Mail=_AEA68B2E-9DC3-464A-912B-5420EFE326F5-- From nobody Wed Feb 24 13:30:09 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32331B40C6 for ; Wed, 24 Feb 2016 13:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 2ODom_S98f9z for ; Wed, 24 Feb 2016 13:30:05 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id E27CE1B40C3 for ; Wed, 24 Feb 2016 13:30:04 -0800 (PST) Received: (qmail 21307 invoked by uid 0); 24 Feb 2016 21:30:01 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 24 Feb 2016 21:30:01 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id NMVw1s00N2UhLwi01MVzLC; Wed, 24 Feb 2016 14:29:59 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o8x0CelELPUA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=B--oRfCUgacoHUpaxtUA:9 a=QEXdDO2ut3YA:10 a=jamb4OCfP6IA:10 a=MQpXSwVLbyUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:To:From; bh=r7WlZjNSrntTSTOrXgrmhGSyA06Bj/XerTDWBa3Z8N8=; b=S/PMFk/clDQ8/kW+Nx6fRNU9cn7+UxYXLFAd24njtntQwBUFk6p7+aWOTc1OIZmUqV99In2NEV5gdhuz9zvozC8yBnKOb8n8yJnrSChTwxoco4BKqRxrvFk++Ca9BiHW; Received: from [70.213.12.105] (port=6577 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYh0P-0007i3-Qu for unbearable@ietf.org; Wed, 24 Feb 2016 14:29:57 -0700 From: =JeffH To: IETF Tokbind WG Message-ID: <56CE20D0.7080509@KingsMountain.com> Date: Wed, 24 Feb 2016 13:29:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.12.105 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 21:30:08 -0000 Andrei replied: >MT said: >> Avoiding an abstraction layer at this point [i.e. not >> generalizing -tokbind-protocol] avoids having to do all >> that work and completely avoids the risk that we mess it up. > > I think that publishing TBPROTO and TBNEGO in their current form would > not preclude future documents describing the use of the Token Binding > protocol with e.g. Kerberos or DTLS. And Martin's point about delaying > the generalization until we have a few adaptations to various STLs makes > sense to me. Ok, so given that the assessment over on the TLS list is that RFC5705 keying material exporter, which -tokbind-protocol (aka TBPROTO) normatively depends upon, is not compatible with TLS 1.3.. https://www.ietf.org/mail-archive/web/tls/current/msg19329.html ..(if folks disagree, they perhaps ought to post to that thread), then it seems that we ought to do one of two things with -tokbind-protocol.. 1. clarify that -tokbind-protocol is applicable to TLS 1.2 and earlier only, or, 2. wait for TLS 1.3 exporter to get defined and either add normative dependence just to the latter and otherwise keep spec TLS-specific (or generalize it for other underlying secure transports). Doing #1 seems likely to get the present set of tokbind specs published sooner. HTH, =JeffH From nobody Wed Feb 24 13:33:46 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A21A894C for ; Wed, 24 Feb 2016 13:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no 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 kdsgwI7VAzB8 for ; Wed, 24 Feb 2016 13:33:43 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 C621B1B414C for ; Wed, 24 Feb 2016 13:33:42 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id g127so26966420ywf.2 for ; Wed, 24 Feb 2016 13:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zoxHMVFXJdJUMvzY3q2MnQbqi9E6dLVcNvePj9Lb8ao=; b=XcRimbIL49nIbVUFzDmIuXzl/ib7UvOVn4HD7oRrDeme2smkyan2wJUtCXI2wxBtJH jML8w0Yz8CZemAlQ5QQkITGReY3a2/2M6t/WHj6vMu/Uo2I/kveG1+b8UF0J8ESgwtlE +lkhpr0B4goN1jSvFpS1QgDm/powG11MkUOuDo/Ud63ULbfx1pW5X09nt6u/uaunnHX0 FFm1zWeuqp01XHTshGX2c4qTaGs2o8FIkYJOKVb6LEsHDhtWnFjntrc6i/SbsxbaXK56 YxLSxSLshPpRql5cctyWJlu+cvX6ZuosulzyxLvwstRor4ftRGvVklV3TP2erSK4JTP1 QF7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zoxHMVFXJdJUMvzY3q2MnQbqi9E6dLVcNvePj9Lb8ao=; b=m56lPkoJNeifNiujCyf8UGg18J28uphrxc9FUrlfxxcS9OqoLImThDcNbsevM06IF2 +KajqAQzFuFbO7ehUkLNg3t+0RMccVTz+xxB5ypEzJ38lC7dKfjDmW+YgUihVVcj/b3j fMcsLLXXr1e7RAmhNNU/7/zjxr8S7OwHMO3aH0eCBdKksDwrvHZg3aASKHtGG07XNyf6 UdEcJ2xWJ9j9vJmsvlMKYgnhbQOCK1FflHvSyKTBhX4cwYsxfTHdDnQLpn/xBMr44FkN BwA78RnVvy2UnaJ6l0WbI1S9oMV4lWZ4N67kqCszyPoUJ1eHSK/rvsb5PlN9eP58cCH+ 3trg== X-Gm-Message-State: AG10YOR/qQmzyh+tP6yw9sxIYRy1Pc5Vic4y/uo8JgZ+HCxT9vFKspQxtq/8s4q6c3GY4w5DMPzHCW5ceOQByw== X-Received: by 10.129.46.15 with SMTP id u15mr20457620ywu.129.1456349622137; Wed, 24 Feb 2016 13:33:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 24 Feb 2016 13:33:02 -0800 (PST) In-Reply-To: <56CE20D0.7080509@KingsMountain.com> References: <56CE20D0.7080509@KingsMountain.com> From: Eric Rescorla Date: Thu, 25 Feb 2016 05:33:02 +0800 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=001a11414df0e5a70a052c8ad1cc Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 21:33:44 -0000 --001a11414df0e5a70a052c8ad1cc Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 5:29 AM, =JeffH wrote: > Andrei replied: > >MT said: > >> Avoiding an abstraction layer at this point [i.e. not > >> generalizing -tokbind-protocol] avoids having to do all > >> that work and completely avoids the risk that we mess it up. > > > > I think that publishing TBPROTO and TBNEGO in their current form would > > not preclude future documents describing the use of the Token Binding > > protocol with e.g. Kerberos or DTLS. And Martin's point about delaying > > the generalization until we have a few adaptations to various STLs makes > > sense to me. > > Ok, so given that the assessment over on the TLS list is that RFC5705 > keying material exporter, which -tokbind-protocol (aka TBPROTO) normatively > depends upon, is not compatible with TLS 1.3.. > > https://www.ietf.org/mail-archive/web/tls/current/msg19329.html > > ..(if folks disagree, they perhaps ought to post to that thread), then it > seems that we ought to do one of two things with -tokbind-protocol.. > > 1. clarify that -tokbind-protocol is applicable to TLS 1.2 and earlier > only, or, > > 2. wait for TLS 1.3 exporter to get defined and either add normative > dependence just to the latter and otherwise keep spec TLS-specific (or > generalize it for other underlying secure transports). > I'm not quite following the problem here. When we are finished with TLS 1.3 we will have defined an exporter for it and then Tokbind will be usable with it. Until TLS 1.3 is finished you couldn't use Tokbind it with TLS 1.3 anyway. So referring to the TLS 1.3 draft and saying we'll need exporters from there seems straightforward, and the AD should be able to handle the mechanics. -Ekr Doing #1 seems likely to get the present set of tokbind specs published > sooner. > > HTH, > > > =JeffH > > > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a11414df0e5a70a052c8ad1cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 25, 2016 at 5:29 AM, =3DJeffH <Jeff.Hodges@kin= gsmountain.com> wrote:
Andr= ei replied:
>MT said:
>> Avoiding an abstraction layer at this point [i.e. not
>> generalizing -tokbind-protocol] avoids having to do all
>> that work and completely avoids the risk that we mess it up.
>
> I think that publishing TBPROTO and TBNEGO in their current form would=
> not preclude future documents describing the use of the Token Binding<= br> > protocol with e.g. Kerberos or DTLS. And Martin's point about dela= ying
> the generalization until we have a few adaptations to various STLs mak= es
> sense to me.

 Ok, so given that the assessment over on the TLS list is that RFC5705 keyin= g material exporter, which -tokbind-protocol (aka TBPROTO) normatively depe= nds upon, is not compatible with TLS 1.3..

=C2=A0 https://www.ietf.org/mail-arch= ive/web/tls/current/msg19329.html

..(if folks disagree, they perhaps ought to post to that thread), then it s= eems that we ought to do one of two things with -tokbind-protocol..

1. clarify that -tokbind-protocol is applicable to TLS 1.2 and earlier only= , or,

2. wait for TLS 1.3 exporter to get defined and either add normative depend= ence just to the latter and otherwise keep spec TLS-specific (or generalize= it for other underlying secure transports).

I'm not quite following the problem here. When we are finished wi= th TLS 1.3 we
will have defined an exporter for it and then Tokbi= nd will be usable with it.
Until TLS 1.3 is finished you couldn&#= 39;t use Tokbind it with TLS 1.3 anyway. So
referring to the TLS = 1.3 draft and saying we'll need exporters from there
seems st= raightforward, and the AD should be able to handle the mechanics.

-Ekr

Doing #1 seems likely to get the present set of tokbind specs published soo= ner.

HTH,


=3DJeffH







_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=

--001a11414df0e5a70a052c8ad1cc-- From nobody Wed Feb 24 13:52:37 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71F1B2A9A for ; Wed, 24 Feb 2016 13:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Vfuk56ep2ezG for ; Wed, 24 Feb 2016 13:52:34 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 3B9F01B3263 for ; Wed, 24 Feb 2016 13:52:34 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id g203so68321377iof.2 for ; Wed, 24 Feb 2016 13:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m41+i7nitoqOWUKFTTP1pFitPfzA1pYPDvtprHNG3Jg=; b=Vl7NBVkawmrVMJSwdR1UeibfLP/WxjsS1dRPq62bU0NGuAPbNN4h1KplmvPzOmZ696 bfQsXz5tftFJ77enPWqmyBlyrOm9P31cNNuoSFTjPdE87XQMcLSWM3VofnjCQwYid00u ckHzDU2qvJEqi6qxJzlI6t5oXWv2Ei7olDEXCqcBhOu5fZ8YqiGNm4E7SjdqOsLC4E3g 5AIW+uebgRT72FtXtJ+Rkb5GrrTMz4kX/xl+Whls6cH4E4IDAQwq5eS3bxb6Gfom1bWi 2A1H7w9UElrOLbZfGltmi/5xiQvjDqxBFJAmoj+yqR48VGWa0cr0i0794ZuPqf0Loaqc gKMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m41+i7nitoqOWUKFTTP1pFitPfzA1pYPDvtprHNG3Jg=; b=LFDuGMZ1pR6k+rRxJxfm41supJE5WLURO7lpK9xw0ljxjyRVk3tMKF7HmUc4ZOnBwA ExcRadonD+E0DQNTx/0eBDRs2/7AWt6ixFltcNL2Y8/YbS2iUOwRjPprEpjpMyohNFuy +GLlwQmhXYF3ni6Ikh0IqkGx7AsNQifwO7NiTcuwOQHItOJyFIyyMIC767NGJxFmIkvJ 9F/bvbwXRCkAyIl+r4gwyZScYXX09zXeM9iJtkS5dccIaZqoYD/yY5FihRR4Ff5xLfay EurSGWe90cFX7Y59WK6OEB+MptPQQSHsj97C7Uz/SfFToffpR2CCqzQf2vp6QziwNNAN pG0A== X-Gm-Message-State: AG10YOSQaemWJYSuOZK1yWkjy/p9A8qJWdy0n+3ha9WXMV4TIRo7oHU8bLmrJqK03HkHyuRE+vXa5IG6/YT8eQ== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr37295337ioi.108.1456350753649; Wed, 24 Feb 2016 13:52:33 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 13:52:33 -0800 (PST) In-Reply-To: References: <56CE20D0.7080509@KingsMountain.com> Date: Wed, 24 Feb 2016 13:52:33 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Tokbind WG , =JeffH Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 21:52:35 -0000 On 24 February 2016 at 13:33, Eric Rescorla wrote: > I'm not quite following the problem here. When we are finished with TLS 1.3 > we > will have defined an exporter for it and then Tokbind will be usable with > it. > Until TLS 1.3 is finished you couldn't use Tokbind it with TLS 1.3 anyway. > So > referring to the TLS 1.3 draft and saying we'll need exporters from there > seems straightforward, and the AD should be able to handle the mechanics. Yes, this is right. We can't ship 1.3 without fixing exporters. You could avoid referring to TLS 1.3 and simply allow TLS 1.3 to obsolete 1.2 and 5705 in due course. If you were concerned about time frame. From nobody Wed Feb 24 13:56:54 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19A81A009D for ; Wed, 24 Feb 2016 13:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 SxxowkHVrHEc for ; Wed, 24 Feb 2016 13:56:52 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id DFA9A1A88AD for ; Wed, 24 Feb 2016 13:56:48 -0800 (PST) Received: (qmail 31777 invoked by uid 0); 24 Feb 2016 21:56:48 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 24 Feb 2016 21:56:48 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id NMwi1s01a2UhLwi01MwlDQ; Wed, 24 Feb 2016 14:56:46 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o8x0CelELPUA:10 a=jFJIQSaiL_oA:10 a=qRR73oMWW0t8IFUX2ScA:9 a=QEXdDO2ut3YA:10 a=ZMYF5MFLlLAA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To:Cc; bh=pC8jMJsX9dl4DNKFa++qhYGyeeIsgLCfG+mbOxBAvwk=; b=RpGefpwW4Xzz0czm72iFwi3p85TrwkNydKxP8//84HgjblTdVg2IcwCiH+9pEcfeGIUqCOXiYDkr202Zebfo1Yrbb2hmbNMVudcIDCtdr2fe9RZ1SpbuQazq7k59V2KP; Received: from [70.213.12.105] (port=6588 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYhQK-00015s-92; Wed, 24 Feb 2016 14:56:44 -0700 To: Eric Rescorla From: =JeffH Message-ID: <56CE2717.5040801@KingsMountain.com> Date: Wed, 24 Feb 2016 13:56:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.12.105 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 21:56:54 -0000 > So referring to the TLS 1.3 draft and saying we'll need exporters from > there seems straightforward, and the AD should be able to handle the > mechanics. If that's a viable option, then agreed. =JeffH From nobody Wed Feb 24 14:04:12 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099D71B3321 for ; Wed, 24 Feb 2016 14:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 E1HEN8HtyQOM for ; Wed, 24 Feb 2016 14:04:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7BB1B325D for ; Wed, 24 Feb 2016 14:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+6LHuIVR9vEWvHkxKVCHtVPl6lxJDNWV/FL0jDl1v88=; b=WTkDqsiQ5ukpITCNikPoFDK9Sj6dLTkeGoU92pgvNADHhVEGUg+DHZX9ka8tr22qiCbfuyMGivS19iwEUuVLIHoXHgipKI9AnmqgXRfCQyy3G7bMNJwXqpJaEgfyiM3f1m7PTuYVFiDKwgaMl7AXQIPj2N7v+sYnIBrFXuTFgw4= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 22:03:49 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 22:03:49 +0000 From: Andrei Popov To: Eric Rescorla , =JeffH Thread-Topic: [Unbearable] Should Token Binding support non-TLS applications? Thread-Index: AQHRb0p/BqcNTIsNp0msYAg2PolnoZ87t0sAgAAHnwA= Date: Wed, 24 Feb 2016 22:03:48 +0000 Message-ID: References: <56CE20D0.7080509@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: ab556965-41bc-4bf8-eb9a-08d33d665fa7 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:fvEBJpnj26i5fnnz7efrGD7c+ipgzKBwUyGKDujayqTUBMV7gzeX3lLMRZZyY91sXaZg48bd9u67cVtyn4WBzL3obnoh2/GycLlw++bnMguPqllHlviYcbrAicVO+ezGBoeOa2XBDQLSGnPcZ4xkdQ==; 24:zmluawyrRDwxFVmfDRyN+YVcFJNSaMrDKCdftTJynaySKs7lGyOYiYUR6Ra8GSABXTjT7ua+vMMwUE3pNw3tsa1nMZ2bJ6wxLSFCWNCA094= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 08626BE3A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(51444003)(377454003)(87936001)(122556002)(10090500001)(86612001)(40100003)(76576001)(86362001)(76176999)(54356999)(50986999)(3660700001)(11100500001)(106116001)(99286002)(10290500002)(1220700001)(10400500002)(8990500004)(19617315012)(5005710100001)(5004730100002)(5008740100001)(6116002)(16236675004)(102836003)(33656002)(790700001)(1096002)(19625215002)(586003)(74316001)(189998001)(92566002)(3280700002)(15975445007)(77096005)(5003600100002)(19580395003)(5001960100002)(2906002)(19300405004)(2950100001)(2900100001)(5002640100001)(4326007)(5001770100001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13964E895788120C25C8759C8CA50BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 22:03:48.8139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2016 22:04:11 -0000 --_000_BLUPR03MB13964E895788120C25C8759C8CA50BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFdoZW4gd2UgYXJlIGZpbmlzaGVkIHdpdGggVExTIDEuMyB3ZQ0KDQrDmCAgd2lsbCBoYXZl IGRlZmluZWQgYW4gZXhwb3J0ZXIgZm9yIGl0IGFuZCB0aGVuIFRva2JpbmQgd2lsbCBiZSB1c2Fi bGUgd2l0aCBpdC4NClllcywgdGhpcyB3YXMgbXkgdW5kZXJzdGFuZGluZyB0b28uIEkgZG9u4oCZ dCBzZWUgYSByZWFzb24gdG8gc2F5IFRCUFJPVE8gaXMgZm9yIFRMUyA8PSAxLjIgb25seS4NCg0K RnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIw MTYgMTozMyBQTQ0KVG86ID1KZWZmSCA8SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+DQpD YzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtV bmJlYXJhYmxlXSBTaG91bGQgVG9rZW4gQmluZGluZyBzdXBwb3J0IG5vbi1UTFMgYXBwbGljYXRp b25zPw0KDQoNCg0KT24gVGh1LCBGZWIgMjUsIDIwMTYgYXQgNToyOSBBTSwgPUplZmZIIDxKZWZm LkhvZGdlc0BraW5nc21vdW50YWluLmNvbTxtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFp bi5jb20+PiB3cm90ZToNCkFuZHJlaSByZXBsaWVkOg0KPk1UIHNhaWQ6DQo+PiBBdm9pZGluZyBh biBhYnN0cmFjdGlvbiBsYXllciBhdCB0aGlzIHBvaW50IFtpLmUuIG5vdA0KPj4gZ2VuZXJhbGl6 aW5nIC10b2tiaW5kLXByb3RvY29sXSBhdm9pZHMgaGF2aW5nIHRvIGRvIGFsbA0KPj4gdGhhdCB3 b3JrIGFuZCBjb21wbGV0ZWx5IGF2b2lkcyB0aGUgcmlzayB0aGF0IHdlIG1lc3MgaXQgdXAuDQo+ DQo+IEkgdGhpbmsgdGhhdCBwdWJsaXNoaW5nIFRCUFJPVE8gYW5kIFRCTkVHTyBpbiB0aGVpciBj dXJyZW50IGZvcm0gd291bGQNCj4gbm90IHByZWNsdWRlIGZ1dHVyZSBkb2N1bWVudHMgZGVzY3Jp YmluZyB0aGUgdXNlIG9mIHRoZSBUb2tlbiBCaW5kaW5nDQo+IHByb3RvY29sIHdpdGggZS5nLiBL ZXJiZXJvcyBvciBEVExTLiBBbmQgTWFydGluJ3MgcG9pbnQgYWJvdXQgZGVsYXlpbmcNCj4gdGhl IGdlbmVyYWxpemF0aW9uIHVudGlsIHdlIGhhdmUgYSBmZXcgYWRhcHRhdGlvbnMgdG8gdmFyaW91 cyBTVExzIG1ha2VzDQo+IHNlbnNlIHRvIG1lLg0KDQpPaywgc28gZ2l2ZW4gdGhhdCB0aGUgYXNz ZXNzbWVudCBvdmVyIG9uIHRoZSBUTFMgbGlzdCBpcyB0aGF0IFJGQzU3MDUga2V5aW5nIG1hdGVy aWFsIGV4cG9ydGVyLCB3aGljaCAtdG9rYmluZC1wcm90b2NvbCAoYWthIFRCUFJPVE8pIG5vcm1h dGl2ZWx5IGRlcGVuZHMgdXBvbiwgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBUTFMgMS4zLi4NCg0K ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzE5 MzI5Lmh0bWw8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsLWFyY2hpdmUlMmZ3ZWIlMmZ0bHMl MmZjdXJyZW50JTJmbXNnMTkzMjkuaHRtbCZkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBt aWNyb3NvZnQuY29tJTdjYmViZTkwYTIwYjA3NGQ3ZWYxMGUwOGQzM2Q2MjMwNTElN2M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9eUJKaEliU08lMmZTUllYenNTVTJh TFJweWJSJTJialZ5bmlDJTJmMFpuY1RQMDE3VSUzZD4NCg0KLi4oaWYgZm9sa3MgZGlzYWdyZWUs IHRoZXkgcGVyaGFwcyBvdWdodCB0byBwb3N0IHRvIHRoYXQgdGhyZWFkKSwgdGhlbiBpdCBzZWVt cyB0aGF0IHdlIG91Z2h0IHRvIGRvIG9uZSBvZiB0d28gdGhpbmdzIHdpdGggLXRva2JpbmQtcHJv dG9jb2wuLg0KDQoxLiBjbGFyaWZ5IHRoYXQgLXRva2JpbmQtcHJvdG9jb2wgaXMgYXBwbGljYWJs ZSB0byBUTFMgMS4yIGFuZCBlYXJsaWVyIG9ubHksIG9yLA0KDQoyLiB3YWl0IGZvciBUTFMgMS4z IGV4cG9ydGVyIHRvIGdldCBkZWZpbmVkIGFuZCBlaXRoZXIgYWRkIG5vcm1hdGl2ZSBkZXBlbmRl bmNlIGp1c3QgdG8gdGhlIGxhdHRlciBhbmQgb3RoZXJ3aXNlIGtlZXAgc3BlYyBUTFMtc3BlY2lm aWMgKG9yIGdlbmVyYWxpemUgaXQgZm9yIG90aGVyIHVuZGVybHlpbmcgc2VjdXJlIHRyYW5zcG9y dHMpLg0KDQpJJ20gbm90IHF1aXRlIGZvbGxvd2luZyB0aGUgcHJvYmxlbSBoZXJlLiBXaGVuIHdl IGFyZSBmaW5pc2hlZCB3aXRoIFRMUyAxLjMgd2UNCndpbGwgaGF2ZSBkZWZpbmVkIGFuIGV4cG9y dGVyIGZvciBpdCBhbmQgdGhlbiBUb2tiaW5kIHdpbGwgYmUgdXNhYmxlIHdpdGggaXQuDQpVbnRp bCBUTFMgMS4zIGlzIGZpbmlzaGVkIHlvdSBjb3VsZG4ndCB1c2UgVG9rYmluZCBpdCB3aXRoIFRM UyAxLjMgYW55d2F5LiBTbw0KcmVmZXJyaW5nIHRvIHRoZSBUTFMgMS4zIGRyYWZ0IGFuZCBzYXlp bmcgd2UnbGwgbmVlZCBleHBvcnRlcnMgZnJvbSB0aGVyZQ0Kc2VlbXMgc3RyYWlnaHRmb3J3YXJk LCBhbmQgdGhlIEFEIHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSB0aGUgbWVjaGFuaWNzLg0KDQot RWtyDQoNCkRvaW5nICMxIHNlZW1zIGxpa2VseSB0byBnZXQgdGhlIHByZXNlbnQgc2V0IG9mIHRv a2JpbmQgc3BlY3MgcHVibGlzaGVkIHNvb25lci4NCg0KSFRILA0KDQoNCj1KZWZmSA0KDQoNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVh cmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu YmVhcmFibGU8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ1bmJl YXJhYmxlJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NiZWJl OTBhMjBiMDc0ZDdlZjEwZTA4ZDMzZDYyMzA1MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSZzZGF0YT14d1pZd3dSOXp5VGdoaEFWeCUyYklnYmVKMjczR25nQjVIZmpWM1hq Z0gyckklM2Q+DQoNCg== --_000_BLUPR03MB13964E895788120C25C8759C8CA50BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1NjUyMjA4Mzc7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjY4NDYxNTYwIC00Mjcx MDk3NTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5XaGVuIHdlIGFyZSBmaW5p c2hlZCB3aXRoIFRMUyAxLjMgd2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPndpbGwgaGF2ZSBkZWZp bmVkIGFuIGV4cG9ydGVyIGZvciBpdCBhbmQgdGhlbiBUb2tiaW5kIHdpbGwgYmUgdXNhYmxlIHdp dGggaXQuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Z ZXMsIHRoaXMgd2FzIG15IHVuZGVyc3RhbmRpbmcgdG9vLiBJIGRvbuKAmXQgc2VlIGEgcmVhc29u IHRvIHNheSBUQlBST1RPIGlzIGZvciBUTFMgJmx0Oz0gMS4yIG9ubHkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVh cmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFy eSAyNCwgMjAxNiAxOjMzIFBNPGJyPg0KPGI+VG86PC9iPiA9SmVmZkggJmx0O0plZmYuSG9kZ2Vz QGtpbmdzbW91bnRhaW4uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBUb2tiaW5kIFdHICZs dDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVh cmFibGVdIFNob3VsZCBUb2tlbiBCaW5kaW5nIHN1cHBvcnQgbm9uLVRMUyBhcHBsaWNhdGlvbnM/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMjUsIDIwMTYgYXQgNToyOSBB TSwgPUplZmZIICZsdDs8YSBocmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5j b20iIHRhcmdldD0iX2JsYW5rIj5KZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFuZHJlaSByZXBsaWVkOjxicj4NCiZndDtNVCBzYWlkOjxicj4NCiZndDsmZ3Q7IEF2b2lkaW5n IGFuIGFic3RyYWN0aW9uIGxheWVyIGF0IHRoaXMgcG9pbnQgW2kuZS4gbm90PGJyPg0KJmd0OyZn dDsgZ2VuZXJhbGl6aW5nIC10b2tiaW5kLXByb3RvY29sXSBhdm9pZHMgaGF2aW5nIHRvIGRvIGFs bDxicj4NCiZndDsmZ3Q7IHRoYXQgd29yayBhbmQgY29tcGxldGVseSBhdm9pZHMgdGhlIHJpc2sg dGhhdCB3ZSBtZXNzIGl0IHVwLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgdGhhdCBwdWJs aXNoaW5nIFRCUFJPVE8gYW5kIFRCTkVHTyBpbiB0aGVpciBjdXJyZW50IGZvcm0gd291bGQ8YnI+ DQomZ3Q7IG5vdCBwcmVjbHVkZSBmdXR1cmUgZG9jdW1lbnRzIGRlc2NyaWJpbmcgdGhlIHVzZSBv ZiB0aGUgVG9rZW4gQmluZGluZzxicj4NCiZndDsgcHJvdG9jb2wgd2l0aCBlLmcuIEtlcmJlcm9z IG9yIERUTFMuIEFuZCBNYXJ0aW4ncyBwb2ludCBhYm91dCBkZWxheWluZzxicj4NCiZndDsgdGhl IGdlbmVyYWxpemF0aW9uIHVudGlsIHdlIGhhdmUgYSBmZXcgYWRhcHRhdGlvbnMgdG8gdmFyaW91 cyBTVExzIG1ha2VzPGJyPg0KJmd0OyBzZW5zZSB0byBtZS48YnI+DQo8YnI+DQpPaywgc28gZ2l2 ZW4gdGhhdCB0aGUgYXNzZXNzbWVudCBvdmVyIG9uIHRoZSBUTFMgbGlzdCBpcyB0aGF0IFJGQzU3 MDUga2V5aW5nIG1hdGVyaWFsIGV4cG9ydGVyLCB3aGljaCAtdG9rYmluZC1wcm90b2NvbCAoYWth IFRCUFJPVE8pIG5vcm1hdGl2ZWx5IGRlcGVuZHMgdXBvbiwgaXMgbm90IGNvbXBhdGlibGUgd2l0 aCBUTFMgMS4zLi48YnI+DQo8YnI+DQombmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v cmclMmZtYWlsLWFyY2hpdmUlMmZ3ZWIlMmZ0bHMlMmZjdXJyZW50JTJmbXNnMTkzMjkuaHRtbCZh bXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Y2JlYmU5MGEy MGIwNzRkN2VmMTBlMDhkMzNkNjIzMDUxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN2MxJmFtcDtzZGF0YT15QkpoSWJTTyUyZlNSWVh6c1NVMmFMUnB5YlIlMmJqVnluaUMlMmYw Wm5jVFAwMTdVJTNkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzE5MzI5Lmh0bWw8L2E+PGJyPg0KPGJyPg0KLi4o aWYgZm9sa3MgZGlzYWdyZWUsIHRoZXkgcGVyaGFwcyBvdWdodCB0byBwb3N0IHRvIHRoYXQgdGhy ZWFkKSwgdGhlbiBpdCBzZWVtcyB0aGF0IHdlIG91Z2h0IHRvIGRvIG9uZSBvZiB0d28gdGhpbmdz IHdpdGggLXRva2JpbmQtcHJvdG9jb2wuLjxicj4NCjxicj4NCjEuIGNsYXJpZnkgdGhhdCAtdG9r YmluZC1wcm90b2NvbCBpcyBhcHBsaWNhYmxlIHRvIFRMUyAxLjIgYW5kIGVhcmxpZXIgb25seSwg b3IsPGJyPg0KPGJyPg0KMi4gd2FpdCBmb3IgVExTIDEuMyBleHBvcnRlciB0byBnZXQgZGVmaW5l ZCBhbmQgZWl0aGVyIGFkZCBub3JtYXRpdmUgZGVwZW5kZW5jZSBqdXN0IHRvIHRoZSBsYXR0ZXIg YW5kIG90aGVyd2lzZSBrZWVwIHNwZWMgVExTLXNwZWNpZmljIChvciBnZW5lcmFsaXplIGl0IGZv ciBvdGhlciB1bmRlcmx5aW5nIHNlY3VyZSB0cmFuc3BvcnRzKS48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgcXVpdGUg Zm9sbG93aW5nIHRoZSBwcm9ibGVtIGhlcmUuIFdoZW4gd2UgYXJlIGZpbmlzaGVkIHdpdGggVExT IDEuMyB3ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+d2lsbCBoYXZlIGRlZmluZWQgYW4gZXhwb3J0ZXIgZm9yIGl0IGFuZCB0aGVuIFRva2JpbmQg d2lsbCBiZSB1c2FibGUgd2l0aCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlVudGlsIFRMUyAxLjMgaXMgZmluaXNoZWQgeW91IGNvdWxkbid0 IHVzZSBUb2tiaW5kIGl0IHdpdGggVExTIDEuMyBhbnl3YXkuIFNvPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWZlcnJpbmcgdG8gdGhlIFRMUyAx LjMgZHJhZnQgYW5kIHNheWluZyB3ZSdsbCBuZWVkIGV4cG9ydGVycyBmcm9tIHRoZXJlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWVtcyBzdHJh aWdodGZvcndhcmQsIGFuZCB0aGUgQUQgc2hvdWxkIGJlIGFibGUgdG8gaGFuZGxlIHRoZSBtZWNo YW5pY3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RG9pbmcgIzEgc2VlbXMgbGlrZWx5IHRvIGdldCB0aGUgcHJlc2VudCBzZXQg b2YgdG9rYmluZCBzcGVjcyBwdWJsaXNoZWQgc29vbmVyLjxicj4NCjxicj4NCkhUSCw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PUplZmZIPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJh YmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnVuYmVhcmFibGUmYW1w O2RhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NiZWJlOTBhMjBi MDc0ZDdlZjEwZTA4ZDMzZDYyMzA1MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdjMSZhbXA7c2RhdGE9eHdaWXd3Ujl6eVRnaGhBVnglMmJJZ2JlSjI3M0duZ0I1SGZqVjNYamdI MnJJJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB13964E895788120C25C8759C8CA50BLUPR03MB1396namp_-- From nobody Wed Feb 24 23:32:24 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34C1A00FC for ; Wed, 24 Feb 2016 23:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.605 X-Spam-Level: X-Spam-Status: No, score=0.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 AN7hr6IMv788 for ; Wed, 24 Feb 2016 23:32:20 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 426991A008A for ; Wed, 24 Feb 2016 23:32:20 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id c200so15160034wme.0 for ; Wed, 24 Feb 2016 23:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=eCrQzG6PC/s4ZXpkUQMuf8V54xNtw4Th0xYnBMTDilw=; b=TQEvYBtCl+OhA/eppwW8sgJYg7dKnJzmEGZue4/yirLWrinhnhXPJAFlGFh9C8cFpa rMICVI40pvseQPikr+w5cuQlkyj8wCG7ZgAazXlxJftL5H9tKypRBKjqt1wQZmiYv0uR uW893JaLLEJv0t2Eg/Gw9QmQVftIvpm46UpIhJ4pTwe8abu9x68G2FqRr6fUqehrRTjr Dm5H9J/MLrqAKIDV+EVBWIKBOPs4iXgfvZA+tcM3D/GnI4JsB28YG2YlKRIfdITiyXwa rFB8xtnqUk2dup3sbXBIjosnJd71+AguiG22x1GGEs6aaOjY/EvDVsT4jIj8WbqRd8Pp T3mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=eCrQzG6PC/s4ZXpkUQMuf8V54xNtw4Th0xYnBMTDilw=; b=CKOmaHn98xzRikmqtjf/TRfWu6XsoJL+oPx3Ph6RuJQ095u85x+5GXY/yOvQ/MBIS7 iba+1kfjBEbBjYa35vb7jcUpzpeNO4qEK9RPIygjGArXhqtGZqdRpbSsyMTcxV74VIDc Qjer3iH1faGZbeumB0Pl0fWmZ9NYCnUK22qYXesuCkYIz/kH7kT4L4dSFwfOrZbGCGat QVr9cn25DkPYi6gVqagvJApf4Z0uEFop/XQTklTwkCv7O2ROXXPB3n8XqLlrto+RE/26 TSfvNcbmrZjBVYCzSf9Rc+LeMQQYhHqiCNoflwUpExuHUroz0AyQ+EXkgHNFbDKGe0Fi aC0A== X-Gm-Message-State: AG10YOSNUKdPFK84uem3JOKpG9kb791/E5IxY227ZY+sdoq5YcoUAno9Po5NIxg00XpClROhYH0I9RdP/LlyYK6H X-Received: by 10.194.78.148 with SMTP id b20mr42830359wjx.71.1456385538763; Wed, 24 Feb 2016 23:32:18 -0800 (PST) MIME-Version: 1.0 References: <56CE20D0.7080509@KingsMountain.com> In-Reply-To: From: Dirk Balfanz Date: Thu, 25 Feb 2016 07:32:09 +0000 Message-ID: To: Andrei Popov , Eric Rescorla , "=JeffH" Content-Type: multipart/alternative; boundary=047d7bfd0e5eb2040a052c932e54 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Should Token Binding support non-TLS applications? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 25 Feb 2016 07:32:22 -0000 --047d7bfd0e5eb2040a052c932e54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Dirk. On Wed, Feb 24, 2016 at 2:04 PM Andrei Popov wrote: > =C3=98 When we are finished with TLS 1.3 we > > =C3=98 will have defined an exporter for it and then Tokbind will be usa= ble > with it. > > Yes, this was my understanding too. I don=E2=80=99t see a reason to say T= BPROTO is > for TLS <=3D 1.2 only. > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Er= ic > Rescorla > *Sent:* Wednesday, February 24, 2016 1:33 PM > *To:* =3DJeffH > *Cc:* IETF Tokbind WG > > > *Subject:* Re: [Unbearable] Should Token Binding support non-TLS > applications? > > > > > > > > On Thu, Feb 25, 2016 at 5:29 AM, =3DJeffH > wrote: > > Andrei replied: > >MT said: > >> Avoiding an abstraction layer at this point [i.e. not > >> generalizing -tokbind-protocol] avoids having to do all > >> that work and completely avoids the risk that we mess it up. > > > > I think that publishing TBPROTO and TBNEGO in their current form would > > not preclude future documents describing the use of the Token Binding > > protocol with e.g. Kerberos or DTLS. And Martin's point about delaying > > the generalization until we have a few adaptations to various STLs make= s > > sense to me. > > Ok, so given that the assessment over on the TLS list is that RFC5705 > keying material exporter, which -tokbind-protocol (aka TBPROTO) normative= ly > depends upon, is not compatible with TLS 1.3.. > > https://www.ietf.org/mail-archive/web/tls/current/msg19329.html > > > ..(if folks disagree, they perhaps ought to post to that thread), then it > seems that we ought to do one of two things with -tokbind-protocol.. > > 1. clarify that -tokbind-protocol is applicable to TLS 1.2 and earlier > only, or, > > 2. wait for TLS 1.3 exporter to get defined and either add normative > dependence just to the latter and otherwise keep spec TLS-specific (or > generalize it for other underlying secure transports). > > > > I'm not quite following the problem here. When we are finished with TLS > 1.3 we > > will have defined an exporter for it and then Tokbind will be usable with > it. > > Until TLS 1.3 is finished you couldn't use Tokbind it with TLS 1.3 anyway= . > So > > referring to the TLS 1.3 draft and saying we'll need exporters from there > > seems straightforward, and the AD should be able to handle the mechanics. > > > > -Ekr > > > > Doing #1 seems likely to get the present set of tokbind specs published > sooner. > > HTH, > > > > =3DJeffH > > > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --047d7bfd0e5eb2040a052c932e54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Dirk.

On Wed, Feb 24, 2016 at 2:04 PM Andrei Popov <= ;Andrei.Popov@microsoft.com> wrote:


Subject: Re: [Unbearable] Should Token Binding support non-TLS appli= cations?

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 25, 2016 at 5:29 AM, =3DJeffH <Jeff.Hodges@ki= ngsmountain.com> wrote:

Andrei replied:
>MT said:
>> Avoiding an abstraction layer at this point [i.e. not
>> generalizing -tokbind-protocol] avoids having to do all
>> that work and completely avoids the risk that we mess it up.
>
> I think that publishing TBPROTO and TBNEGO in their current form would=
> not preclude future documents describing the use of the Token Binding<= br> > protocol with e.g. Kerberos or DTLS. And Martin's point about dela= ying
> the generalization until we have a few adaptations to various STLs mak= es
> sense to me.

Ok, so given that the assessment over on the TLS list is that RFC5705 keyin= g material exporter, which -tokbind-protocol (aka TBPROTO) normatively depe= nds upon, is not compatible with TLS 1.3..

=C2=A0 https://www.ietf.org/mail-archive/web/tls/current/msg19329.html

..(if folks disagree, they perhaps ought to post to that thread), then it s= eems that we ought to do one of two things with -tokbind-protocol..

1. clarify that -tokbind-protocol is applicable to TLS 1.2 and earlier only= , or,

2. wait for TLS 1.3 exporter to get defined and either add normative depend= ence just to the latter and otherwise keep spec TLS-specific (or generalize= it for other underlying secure transports).

=C2=A0

I'm not quite following the problem here. When w= e are finished with TLS 1.3 we

will have defined an exporter for it and then Tokbin= d will be usable with it.

Until TLS 1.3 is finished you couldn't use Tokbi= nd it with TLS 1.3 anyway. So

referring to the TLS 1.3 draft and saying we'll = need exporters from there

seems straightforward, and the AD should be able to = handle the mechanics.

=C2=A0

-Ekr

=C2=A0

Doing #1 seems likely to get the present set of tokb= ind specs published sooner.

HTH,



=3DJeffH







_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearab= le

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=
--047d7bfd0e5eb2040a052c932e54-- From nobody Sun Feb 28 21:43:01 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FCE1B2C7E for ; Sun, 28 Feb 2016 21:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.667 X-Spam-Level: X-Spam-Status: No, score=-99.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 J6Lp1o5bxmpZ for ; Sun, 28 Feb 2016 21:42:58 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id E89661B2C7B for ; Sun, 28 Feb 2016 21:42:57 -0800 (PST) Received: (qmail 17642 invoked by uid 0); 29 Feb 2016 05:42:55 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 29 Feb 2016 05:42:55 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id Q5il1s00D2UhLwi015ioA6; Sun, 28 Feb 2016 22:42:53 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=CPISHRbvJHmrvb06n5kA:9 a=VwEixMzTUVB5t9Ij:21 a=AibWw55WkMzakyQF:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=yaM/Ng4Jl4YF+VYKbIar8MCLxWdkXxGoB3Mt6VDr9NA=; b=wmW0tph7ycf3jQXE6e58Avebia91EmK81MdAC3uFnw0mezGcC00O8bzo7377zOT4hQTXucKMiYF/yIMY40D0OUADhl1uvOmWU5f7j8Q9hYVRyDVSqlevl++OhJOm9FxT; Received: from [73.202.80.238] (port=52718 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aaGbX-0008HB-0a for unbearable@ietf.org; Sun, 28 Feb 2016 22:42:47 -0700 To: IETF Tokbind WG From: =JeffH Message-ID: <56D3DA4F.6070806@KingsMountain.com> Date: Sun, 28 Feb 2016 21:42:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 29 Feb 2016 05:43:00 -0000 fyi/fwiw, when reviewing draft-ietf-tokbind-https-02 I found it somewhat difficult to follow along which entities play which roles and such, given all the various terminology in play, so I drew some figures (below, fixed pitch font is your fried) to try to tease it all apart.The first is the overall model, and the 2nd is the particular "Federation Use Cases" in the spec. Are these accurate? (if they get horribly mangled transiting email systems, i'll blog 'em or sumptin'..) HTH, =JeffH Overall "Federated token bindings" model per https://tools.ietf.org/html/draft-ietf-tokbind-https-02 Token Token Consumer Provider +--------+ +----+ +-----+ | client | | TC | | TP | +--------+ +----+ +-----+ | | | | | | | | | | | | 1. Client interacts w/TC |<--------------------->| | TBID1 established | | | | | | TC gives client perms | | | to reveal TBID1 to TP | | | | | | | | | 2. Client interacts w/TP |<-------------------------------------->| TBID2 established | | | | | | Client includes both | | | TBID1 and TBID2 in TB | | | message to TP | | | | | | Illustration of section 3. Federation Use Cases https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3 What: Typical HTTP Redirect-based Web Broswer SSO Profile (no artifact, no callbacks), featuring binding of, e.g., a TLS Token Binding ID into an OpenID Connect "ID Token". Legend: ID Token: the "ID Token" in OIDC, is semantic equivalent of a SAML "authentication assertion" OIDC: Open ID Connect TBID: Token Binding ID TBIDn: Token Binding ID number "n", i.e., mapped to particular TLS session(s) & connection(s) with particular party ETBMSG: Token-Binding header field conveying EncodedTokenBindingMessage, lists the conveyed TBID(s) and their type(s) within "[...]" Client, Token Consumer, Token Provider, aka: aka: aka: User Agent OpenID Client, OpenID Provider, OIDC Relying Party, OIDC Provider, SAML Relying Party SAML Identity Provider +--------+ +----+ +-----+ | Client | | TC | | TP | +--------+ +----+ +-----+ | | | | | | | | | | 0. Client interacts w/TC | | | over HTTPS, establishes TBID1 | | | ETBMSG[TBID1:provided_token_binding] | |------------------------------>| | | | | | | | | | | | 1a. OIDC ID Token request, aka| | | "Authentication Request", conveyed with | | HTTP response header field of: | | Include-Referer-Token-Binding-ID:true; | | any security-relevant cookies | | | should contain TBID1 | | +<- - - - - - - - - - - - - - - - | | . | (redirect to TP via 301, 302, | | . | 303, 307 or 308) | | . | | | +------------------------------------------------------->| | 1b. opens HTTPS & establishes TBID2, | | sends GET or POST with | | ETBMSG[TBID2:provided_token_binding, | | TBID1:referred_token_binding] | | conveying ID Token request | | | | | | | | | | | | 2. user authentication (if applicable, | | methods vary, particulars are out of scope) | |<====================================================>| | (TP generates ID Token for TC containing TBID1, may | | also set cookie(s) containing TBID2 and/or TBID1, | | details vary, particulars are out of scope) | | | | | | | | | | | 3a. ID Token containing TBID1, issued for TC, | | conveyed via OIDC "Authentication Response" | +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to TC) | | . | | | . | | | +-------------------------------->| | | 3b. HTTPS GET or POST with | | TBMSG[TBID1:provided_token_binding] | | conveying Authn Reponse containing | | ID Token w/TBID1, issued for TC | | | | | | | | | | | 4. user is signed-on, any security-relevant cookie(s)| | that are set SHOULD contain TBID1 | |<------------------------------| | | | | | | | From nobody Mon Feb 29 10:14:37 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1EB1B394D for ; Mon, 29 Feb 2016 10:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 QTrg1kIXuIMw for ; Mon, 29 Feb 2016 10:14:32 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 9DAD81B394C for ; Mon, 29 Feb 2016 10:14:32 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id ts10so142465641obc.1 for ; Mon, 29 Feb 2016 10:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H3UueGv9EpXFoXtgslnNrDMhOW407zGiEL8OazM0nLk=; b=khkWYOe+NZ/gg3JTFDHpRQhTHNvR7maqFy2HFTQZREkAVYV+hNiUhlePyFIJwIWx+f 68UHw66vEodCTrvxm1R74X5DtzDqBHWpebiASQR8bnfMT0pOUREZ9MIBxpLYZyTzEChC ulge0d1kwONBe6HBzYEdU7JT4qSf0tmi4zvdT9KDbo7Nwh408jPdiirIml6/BLw8dthj u6yQ3xQ3dIiutdYjKWI520z9Nx2E+L+GQ+h4oEUbFl87R7om65+houZBRuWiPiWPbZVy 7UkPTD3AuambVreEn9kKHtWduqh/2tsNtO96yxbmN0EZuP5lxAc65gAahNCMlKa/St1o MzaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H3UueGv9EpXFoXtgslnNrDMhOW407zGiEL8OazM0nLk=; b=B6YzmdUCIMML93r6NTMuyC6+GrwC4qqZ0I4N1Sz9h5crB6iOQkoOKlGGegRquh+xm5 9D6FEDgHj989JeUYvdPuOpXk8MgRqR1jHVLtTGWvb6LmOy2iPlEkcsTTLv64WoryJHIM DAsyc6+/+skomVjh6CDurn6kxc/GjvQc04kbLmHxghMYOHSeDf6I6jnZl0u7M7PknBCS eH2EjjyR0sOrkcYpozVskURpMkg4OdkkeDrXAZsbfCTFcJdTSiBBZz+zu7B/Gl2CmLuy CaA0dVb8/Mn4i1r81k60wwNBEXDDh0o44F1lfPVEuQFg35Tn68wvY0KvMdPIkjwPnYwR jjEA== X-Gm-Message-State: AD7BkJLLv+1EkfptuscYXxlqyjYE0SmA4pftpw5nXHTR1taCvuPBzi+HP3gGsTg2NovKElOZyT2AEWP852zA0LC8 X-Received: by 10.182.133.4 with SMTP id oy4mr12680085obb.65.1456769671825; Mon, 29 Feb 2016 10:14:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.44.86 with HTTP; Mon, 29 Feb 2016 10:14:12 -0800 (PST) In-Reply-To: <56D3DA4F.6070806@KingsMountain.com> References: <56D3DA4F.6070806@KingsMountain.com> From: Nick Harper Date: Mon, 29 Feb 2016 10:14:12 -0800 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=e89a8ff25258cf4884052cec9e26 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 29 Feb 2016 18:14:35 -0000 --e89a8ff25258cf4884052cec9e26 Content-Type: text/plain; charset=UTF-8 That matches my understanding of how referred token bindings are supposed to work. On Sun, Feb 28, 2016 at 9:42 PM, =JeffH wrote: > fyi/fwiw, when reviewing draft-ietf-tokbind-https-02 I found it somewhat > difficult to follow along which entities play which roles and such, given > all the various terminology in play, so I drew some figures (below, fixed > pitch font is your fried) to try to tease it all apart.The first is the > overall model, and the 2nd is the particular "Federation Use Cases" in the > spec. > > Are these accurate? (if they get horribly mangled transiting email > systems, i'll blog 'em or sumptin'..) > > HTH, > > =JeffH > > > > Overall "Federated token bindings" model > per https://tools.ietf.org/html/draft-ietf-tokbind-https-02 > > Token Token > Consumer Provider > +--------+ +----+ +-----+ > | client | | TC | | TP | > +--------+ +----+ +-----+ > | | | > | | | > | | | > | | | > 1. Client interacts w/TC |<--------------------->| | > TBID1 established | | | > | | | > TC gives client perms | | | > to reveal TBID1 to TP | | | > | | | > | | | > 2. Client interacts w/TP |<-------------------------------------->| > TBID2 established | | | > | | | > Client includes both | | | > TBID1 and TBID2 in TB | | | > message to TP | | | > | | | > > > > > Illustration of section 3. Federation Use Cases > https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3 > > What: > Typical HTTP Redirect-based Web Broswer SSO Profile > (no artifact, no callbacks), featuring binding of, > e.g., a TLS Token Binding ID into an OpenID Connect "ID Token". > > Legend: > > ID Token: the "ID Token" in OIDC, is semantic equivalent > of a SAML "authentication assertion" > > OIDC: Open ID Connect > > TBID: Token Binding ID > > TBIDn: Token Binding ID number "n", i.e., mapped to particular TLS > session(s) & connection(s) with particular party > > ETBMSG: Token-Binding header field conveying > EncodedTokenBindingMessage, > lists the conveyed TBID(s) and their type(s) within "[...]" > > > > Client, Token Consumer, Token Provider, > aka: aka: aka: > User Agent OpenID Client, OpenID Provider, > OIDC Relying Party, OIDC Provider, > SAML Relying Party SAML Identity Provider > +--------+ +----+ +-----+ > | Client | | TC | | TP | > +--------+ +----+ +-----+ > | | | > | | | > | | | > | 0. Client interacts w/TC | | > | over HTTPS, establishes TBID1 | | > | ETBMSG[TBID1:provided_token_binding] | > |------------------------------>| | > | | | > | | | > | | | > | 1a. OIDC ID Token request, aka| | > | "Authentication Request", conveyed with | > | HTTP response header field of: | > | Include-Referer-Token-Binding-ID:true; | > | any security-relevant cookies | | > | should contain TBID1 | | > +<- - - - - - - - - - - - - - - - | | > . | (redirect to TP via 301, 302, | | > . | 303, 307 or 308) | | > . | | | > +------------------------------------------------------->| > | 1b. opens HTTPS & establishes TBID2, | > | sends GET or POST with | > | ETBMSG[TBID2:provided_token_binding, | > | TBID1:referred_token_binding] | > | conveying ID Token request | | > | | | > | | | > | | | > | 2. user authentication (if applicable, | > | methods vary, particulars are out of scope) | > |<====================================================>| > | (TP generates ID Token for TC containing TBID1, may | > | also set cookie(s) containing TBID2 and/or TBID1, | > | details vary, particulars are out of scope) | > | | | > | | | > | | | > | 3a. ID Token containing TBID1, issued for TC, | > | conveyed via OIDC "Authentication Response" | > +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -| > . | (redirect to TC) | | > . | | | > . | | | > +-------------------------------->| | > | 3b. HTTPS GET or POST with | > | TBMSG[TBID1:provided_token_binding] | > | conveying Authn Reponse containing | > | ID Token w/TBID1, issued for TC | > | | | > | | | > | | | > | 4. user is signed-on, any security-relevant cookie(s)| > | that are set SHOULD contain TBID1 | > |<------------------------------| | > | | | > | | | > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --e89a8ff25258cf4884052cec9e26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VGhhdCBtYXRjaGVzIG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IHJlZmVy cmVkIHRva2VuIGJpbmRpbmdzIGFyZSBzdXBwb3NlZCB0byB3b3JrLjwvZGl2PjxkaXYgY2xhc3M9 ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFN1biwgRmViIDI4 LCAyMDE2IGF0IDk6NDIgUE0sID1KZWZmSCA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h aWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkplZmYu SG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5meWkvZndpdywgd2hlbiByZXZp ZXdpbmcgZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTAyIEkgZm91bmQgaXQgc29tZXdoYXQgZGlm ZmljdWx0IHRvIGZvbGxvdyBhbG9uZyB3aGljaCBlbnRpdGllcyBwbGF5IHdoaWNoIHJvbGVzIGFu ZCBzdWNoLCBnaXZlbiBhbGwgdGhlIHZhcmlvdXMgdGVybWlub2xvZ3kgaW4gcGxheSwgc28gSSBk cmV3IHNvbWUgZmlndXJlcyAoYmVsb3csIGZpeGVkIHBpdGNoIGZvbnQgaXMgeW91ciBmcmllZCkg dG8gdHJ5IHRvIHRlYXNlIGl0IGFsbCBhcGFydC5UaGUgZmlyc3QgaXMgdGhlIG92ZXJhbGwgbW9k ZWwsIGFuZCB0aGUgMm5kIGlzIHRoZSBwYXJ0aWN1bGFyICZxdW90O0ZlZGVyYXRpb24gVXNlIENh c2VzJnF1b3Q7IGluIHRoZSBzcGVjLjxicj4NCjxicj4NCkFyZSB0aGVzZSBhY2N1cmF0ZT/CoCAo aWYgdGhleSBnZXQgaG9ycmlibHkgbWFuZ2xlZCB0cmFuc2l0aW5nIGVtYWlsIHN5c3RlbXMsIGkm IzM5O2xsIGJsb2cgJiMzOTtlbSBvciBzdW1wdGluJiMzOTsuLik8YnI+DQo8YnI+DQpIVEgsPGJy Pg0KPGJyPg0KPUplZmZIPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT3ZlcmFsbCAmcXVvdDtGZWRl cmF0ZWQgdG9rZW4gYmluZGluZ3MmcXVvdDsgbW9kZWw8YnI+DQpwZXIgPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wMiIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdG9rYmluZC1odHRwcy0wMjwvYT48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBUb2tlbsKgIMKgIMKgIMKgIMKgIFRva2VuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBDb25zdW1l csKgIMKgIMKgIMKgIFByb3ZpZGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqArLS0tLS0tLS0rwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0rwqAgwqAgwqAgwqAg wqAgKy0tLS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBjbGll bnQgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgVEMgfMKgIMKgIMKgIMKgIMKgIHwgVFDCoCB8 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0tLS0rwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0rwqAgwqAgwqAgwqAgwqAgKy0tLS0tKzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQoxLiBDbGllbnQgaW50ZXJhY3RzIHcvVEPC oCDCoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3zCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8PGJyPg0KwqAgwqBUQklEMSBlc3RhYmxpc2hlZMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqBUQyBn aXZlcyBjbGllbnQgcGVybXPCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqB0byByZXZlYWwgVEJJRDEgdG8g VFDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHw8YnI+DQoyLiBDbGllbnQgaW50ZXJhY3RzIHcvVFDCoCDCoHwmbHQ7LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4NCsKgIMKgVEJJRDIgZXN0YWJsaXNoZWTC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfDxicj4NCsKgIMKgQ2xpZW50IGluY2x1ZGVzIGJvdGjCoCDCoCB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4N CsKgIMKgVEJJRDEgYW5kIFRCSUQyIGluIFRCwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgbWVzc2FnZSB0 byBUUMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSWxsdXN0 cmF0aW9uIG9mIHNlY3Rpb24gMy4gRmVkZXJhdGlvbiBVc2UgQ2FzZXM8YnI+DQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTAyI3Nl Y3Rpb24tMyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wMiNzZWN0aW9uLTM8L2E+PGJy Pg0KPGJyPg0KwqBXaGF0Ojxicj4NCsKgIMKgIFR5cGljYWwgSFRUUCBSZWRpcmVjdC1iYXNlZCBX ZWIgQnJvc3dlciBTU08gUHJvZmlsZTxicj4NCsKgIMKgIChubyBhcnRpZmFjdCwgbm8gY2FsbGJh Y2tzKSwgZmVhdHVyaW5nIGJpbmRpbmcgb2YsPGJyPg0KwqAgwqAgZS5nLiwgYSBUTFMgVG9rZW4g QmluZGluZyBJRCBpbnRvIGFuIE9wZW5JRCBDb25uZWN0ICZxdW90O0lEIFRva2VuJnF1b3Q7Ljxi cj4NCjxicj4NCsKgTGVnZW5kOjxicj4NCjxicj4NCsKgIMKgIElEIFRva2VuOiB0aGUgJnF1b3Q7 SUQgVG9rZW4mcXVvdDsgaW4gT0lEQywgaXMgc2VtYW50aWMgZXF1aXZhbGVudDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIG9mIGEgU0FNTCAmcXVvdDthdXRoZW50aWNhdGlvbiBhc3NlcnRpb24m cXVvdDs8YnI+DQo8YnI+DQrCoCDCoCBPSURDOiBPcGVuIElEIENvbm5lY3Q8YnI+DQo8YnI+DQrC oCDCoCBUQklEOsKgIFRva2VuIEJpbmRpbmcgSUQ8YnI+DQo8YnI+DQrCoCDCoCBUQklEbjogVG9r ZW4gQmluZGluZyBJRCBudW1iZXIgJnF1b3Q7biZxdW90OywgaS5lLiwgbWFwcGVkIHRvIHBhcnRp Y3VsYXIgVExTPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqBzZXNzaW9uKHMpICZhbXA7IGNvbm5lY3Rp b24ocykgd2l0aCBwYXJ0aWN1bGFyIHBhcnR5PGJyPg0KPGJyPg0KwqAgwqAgRVRCTVNHOiBUb2tl bi1CaW5kaW5nIGhlYWRlciBmaWVsZCBjb252ZXlpbmcgRW5jb2RlZFRva2VuQmluZGluZ01lc3Nh Z2UsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgbGlzdHMgdGhlIGNvbnZleWVkIFRCSUQocykgYW5k IHRoZWlyIHR5cGUocykgd2l0aGluICZxdW90O1suLi5dJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KwqAgQ2xpZW50LMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRva2VuIENv bnN1bWVyLMKgIMKgIMKgIMKgVG9rZW4gUHJvdmlkZXIsPGJyPg0KwqAgYWthOsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWthOsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGFrYTo8YnI+DQrCoCBVc2VyIEFnZW50wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPcGVu SUQgQ2xpZW50LMKgIMKgIMKgIMKgIE9wZW5JRCBQcm92aWRlciw8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE9JREMgUmVseWluZyBQYXJ0eSzCoCDC oE9JREMgUHJvdmlkZXIsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBTQU1MIFJlbHlpbmcgUGFydHnCoCDCoCBTQU1MIElkZW50aXR5IFByb3ZpZGVy PGJyPg0KwqAgKy0tLS0tLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICst LS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLSs8YnI+DQrCoCB8IENsaWVudCB8wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCBUQyB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCBUUMKgIHw8YnI+DQrCoCArLS0tLS0tLS0rwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKy0tLS0rwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0tKzxicj4NCsKg IMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fDxicj4NCsKgIMKgIMKgIHwgMC4gQ2xpZW50IGludGVyYWN0cyB3L1RDwqAgwqAgwqAgfMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8IG92ZXIgSFRUUFMs IGVzdGFibGlzaGVzIFRCSUQxIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJy Pg0KwqAgwqAgwqAgfCBFVEJNU0dbVEJJRDE6cHJvdmlkZWRfdG9rZW5fYmluZGluZ13CoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJmd0O3zCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAg wqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 PGJyPg0KwqAgwqAgwqAgfCAxYS4gT0lEQyBJRCBUb2tlbiByZXF1ZXN0LCBha2F8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIHwgJnF1b3Q7QXV0aGVudGlj YXRpb24gUmVxdWVzdCZxdW90OywgY29udmV5ZWQgd2l0aMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8 YnI+DQrCoCDCoCDCoCB8IEhUVFAgcmVzcG9uc2UgaGVhZGVyIGZpZWxkIG9mOsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIHwgSW5jbHVkZS1SZWZlcmVy LVRva2VuLUJpbmRpbmctSUQ6dHJ1ZTvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDC oCDCoCB8IGFueSBzZWN1cml0eS1yZWxldmFudCBjb29raWVzIHzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfCBzaG91bGQgY29udGFpbiBUQklEMcKgIMKg IMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAg KyZsdDstIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIHzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgLiB8IChyZWRpcmVjdCB0byBUUCB2aWEgMzAxLCAz MDIsIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgLiB8wqAg MzAzLCAzMDcgb3IgMzA4KcKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCAuIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJy Pg0KwqAgwqAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mZ3Q7fDxicj4NCsKgIMKgIMKgIHwgMWIuIG9wZW5zIEhUVFBTICZhbXA7IGVzdGFi bGlzaGVzIFRCSUQyLMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIHwg c2VuZHMgR0VUIG9yIFBPU1Qgd2l0aMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIHwgRVRCTVNHW1RCSUQyOnByb3ZpZGVkX3Rva2Vu X2JpbmRpbmcswqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgfMKgIMKg IMKgIMKgVEJJRDE6cmVmZXJyZWRfdG9rZW5fYmluZGluZ13CoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8PGJyPg0KwqAgwqAgwqAgfCBjb252ZXlpbmcgSUQgVG9rZW4gcmVxdWVzdMKgIMKgIHzC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fDxicj4NCsKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAg fCAyLiB1c2VyIGF1dGhlbnRpY2F0aW9uIChpZiBhcHBsaWNhYmxlLMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIMKgIHzCoCDCoCBtZXRob2RzIHZhcnksIHBhcnRpY3VsYXJzIGFy ZSBvdXQgb2Ygc2NvcGUpwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgfCZsdDs9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+DQrCoCDC oCDCoCB8IChUUCBnZW5lcmF0ZXMgSUQgVG9rZW4gZm9yIFRDIGNvbnRhaW5pbmcgVEJJRDEsIG1h ecKgIHw8YnI+DQrCoCDCoCDCoCB8wqAgYWxzbyBzZXQgY29va2llKHMpIGNvbnRhaW5pbmcgVEJJ RDIgYW5kL29yIFRCSUQxLMKgIMKgfDxicj4NCsKgIMKgIMKgIHzCoCBkZXRhaWxzIHZhcnksIHBh cnRpY3VsYXJzIGFyZSBvdXQgb2Ygc2NvcGUpwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0K wqAgwqAgwqAgfCAzYS4gSUQgVG9rZW4gY29udGFpbmluZyBUQklEMSwgaXNzdWVkIGZvciBUQyzC oCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfMKgIMKgIGNvbnZleWVkIHZpYSBPSURDICZxdW90 O0F1dGhlbnRpY2F0aW9uIFJlc3BvbnNlJnF1b3Q7wqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgKyZs dDstIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt fDxicj4NCsKgIMKgIC4gfMKgIMKgKHJlZGlyZWN0IHRvIFRDKcKgIMKgIMKgIMKgIMKgIMKgIHzC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgLiB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIC4gfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8 YnI+DQrCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8IDNiLiBIVFRQUyBHRVQg b3IgUE9TVCB3aXRowqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJy Pg0KwqAgwqAgwqAgfCBUQk1TR1tUQklEMTpwcm92aWRlZF90b2tlbl9iaW5kaW5nXcKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8IGNvbnZleWluZyBBdXRobiBSZXBv bnNlIGNvbnRhaW5pbmfCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDC oCB8IElEIFRva2VuIHcvVEJJRDEsIGlzc3VlZCBmb3IgVEPCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+ DQrCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfCA0LiB1c2VyIGlzIHNpZ25lZC1v biwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZShzKXw8YnI+DQrCoCDCoCDCoCB8IHRoYXQg YXJlIHNldCBTSE9VTEQgY29udGFpbiBUQklEMcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHw8YnI+DQrCoCDCoCDCoCB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgfMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxi cj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby91bmJlYXJhYmxlIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJyPg0KPC9ibG9j a3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCg== --e89a8ff25258cf4884052cec9e26-- From nobody Mon Feb 29 13:57:35 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23971B3D4C for ; Mon, 29 Feb 2016 13:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 sMyHYdS7FiMr for ; Mon, 29 Feb 2016 13:57:33 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 5979B1B3D4A for ; Mon, 29 Feb 2016 13:57:33 -0800 (PST) Received: (qmail 6456 invoked by uid 0); 29 Feb 2016 21:57:32 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 29 Feb 2016 21:57:32 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id QMxT1s01B2UhLwi01MxWTy; Mon, 29 Feb 2016 14:57:31 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=S7WxGyuiic6gJVOE464A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:Message-ID; bh=FuTgf/yfwg2/f+iXl237LbzvAWQDfbXR6rpZtGjFh5s=; b=yeGwwp3MYYBINclD4Y6clyNWWeu/EnEJs8n3YQubXzZJbWxgQj3xsqG1NXRHjGlJWCJx4z/Rl30De5ovtf7RbQELDzuM3qQc+UTcF+w51y4TrdYvLshZpy13DlgHrCBM; Received: from localhost ([127.0.0.1]:38149 helo=box514.bluehost.com) by box514.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1aaVom-0000mN-TU for unbearable@ietf.org; Mon, 29 Feb 2016 14:57:28 -0700 Received: from 70.213.10.137 ([70.213.10.137]) (SquirrelMail authenticated user jeff.hodges@kingsmountain.com) by box514.bluehost.com with HTTP; Mon, 29 Feb 2016 14:57:28 -0700 Message-ID: <4c28612dcfaeaad73c9b1b8fb18d55ef.squirrel@box514.bluehost.com> Date: Mon, 29 Feb 2016 14:57:28 -0700 From: jeff.hodges@kingsmountain.com To: "Tokbind WG" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} Archived-At: Subject: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 29 Feb 2016 21:57:34 -0000 Hi, The last paragraph of -tokbind-protocol-04 section 4 [1] begins with.. If the Token Binding message does not contain at least one TokenBinding structure, or the signature contained in a TokenBinding structure is invalid, the server MUST terminate the connection. ..however, if the Token Binding Message received from the client, over "this" TLS session, contains TokenBinding structure(s) with.. TokenBinding.tokenbinding_type == referred_token_binding ..(as well as provided_token_binding types), then the server will not be able to verify the signature(s) within those "referred" TokenBinding struct(s) because the server would obtain an Exported Keying Material (EKM) [RFC5705] value from the TLS stack that is different from the EKM value used when the referred_token_binding TokenBinding struct was created by the client, but with a different server over a different TLS session -- yes ? Or am I misunderstanding how [RFC5705] works? thanks, =JeffH [1] From nobody Mon Feb 29 14:27:30 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41911B3E13 for ; Mon, 29 Feb 2016 14:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 DnHYKqX9iRcq for ; Mon, 29 Feb 2016 14:27:27 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 7D3271B3E12 for ; Mon, 29 Feb 2016 14:27:27 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id s6so98629563obg.3 for ; Mon, 29 Feb 2016 14:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DwKLmzYmcoWHJ2HHQIvy86BYshN2LXBgsejFoSq/nDQ=; b=e7wBsmOsFi32IxyltPjnKeHd3KShqi5TCQcKharJIz5jP6KWlH2365Ncxo/UQ8EV7a ifmHsqXDC251vfbTaC3GlKvYYJHqnSfMlJHpz0wfQ9VuwYi8ScD4YtmlSpEImj0Ppecy WcwrsM2Iw7Xq/9o0NJNxtk/3TJQ7WaELmR9B5gNkZTXup1SuU83/7HAiD6G8Q4FcH6Zm qON6LHfjCIHKYP8GOuDmtB4Hcmm5T79i9Tf0ZfcJQRYPmcLuwJVQKPwcqM2htrxM4c+U ZlkB+8jkDzvOpChQgiusvSMsoFANPGDpyWYLZBngDHK7gNZ3K7vko1PGBePGZxhCrC2R nv1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DwKLmzYmcoWHJ2HHQIvy86BYshN2LXBgsejFoSq/nDQ=; b=KZ/fIRt+IrJkM1HRxLLPDE2RckgdSofN3ZCgI5ysETxDuEx81jq+lAgdyMiQdlcKzT c+n4PNYEev9K1hwa4m/7Yms5yp6+8pglu4ml4ExkbaGV8V7Us61KCWTjoIHNV8NZZ5TP hIm7rYSCUOISLbcVJa4vrtazwqiVDlz/ab9DLl1Uz/LcNpAQvkEflcCvdTcqKx2YmxS4 eOAxGmQCGiVY/jRZJK3mrp9RlZBDygdfkotk8RDnwar6BEt6LtQwOAXPzdwkUxEB0qzi dyfRAk1JGO4UVkyQ++x7rXVQkP8EOtR1kYzmjgg0htNETzaMAEoR6awBZ7r8H2j+iZ0j GYoA== X-Gm-Message-State: AD7BkJIruSPdepUFiNblrmsA0RB9aTcoo+OgmB67H6W+nKHEYWVd/9UgN3ovpIyI7ld5YtnbNGhWhbGxn6gGjHr2 X-Received: by 10.182.240.138 with SMTP id wa10mr13662636obc.42.1456784846736; Mon, 29 Feb 2016 14:27:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.44.86 with HTTP; Mon, 29 Feb 2016 14:27:07 -0800 (PST) In-Reply-To: <4c28612dcfaeaad73c9b1b8fb18d55ef.squirrel@box514.bluehost.com> References: <4c28612dcfaeaad73c9b1b8fb18d55ef.squirrel@box514.bluehost.com> From: Nick Harper Date: Mon, 29 Feb 2016 14:27:07 -0800 Message-ID: To: Jeff Hodges Content-Type: multipart/alternative; boundary=089e016348a84e1767052cf02730 Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 29 Feb 2016 22:27:29 -0000 --089e016348a84e1767052cf02730 Content-Type: text/plain; charset=UTF-8 My understanding of referred token bindings is that the signature in the TokenBinding struct is over the same EKM value for all TokenBinding structs in the TokenBindingMessage. That is, when server A sends the Include-Referer-Token-Binding-ID and redirects to server B, the TokenBindingMessage sent to server B has a provided TokenBinding with the client's TokenBindingID for server B and a signature of the EKM for the connection to server B, and a referred TokenBinding with the client's TokenBindingID for server A and a signature of the EKM for the connection to server B. This way, server B can verify the signature for both keys (assuming server B supports the key parameter used for the referred TokenBinding). On Mon, Feb 29, 2016 at 1:57 PM, wrote: > Hi, > > The last paragraph of -tokbind-protocol-04 section 4 [1] begins with.. > > If the Token Binding message does not contain at least one > TokenBinding structure, or the signature contained in a > TokenBinding structure is invalid, the server MUST terminate > the connection. > > ..however, if the Token Binding Message received from the client, over > "this" TLS session, contains TokenBinding structure(s) with.. > > TokenBinding.tokenbinding_type == referred_token_binding > > ..(as well as provided_token_binding types), then the server will not be > able to verify the signature(s) within those "referred" TokenBinding > struct(s) because the server would obtain an Exported Keying Material > (EKM) [RFC5705] value from the TLS stack that is different from the EKM > value used when the referred_token_binding TokenBinding struct was created > by the client, but with a different server over a different TLS session > -- yes ? Or am I misunderstanding how [RFC5705] works? > > thanks, > > =JeffH > > [1] > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --089e016348a84e1767052cf02730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My understanding of referred token bindings is that the si= gnature in the TokenBinding struct is over the same EKM value for all Token= Binding structs in the TokenBindingMessage. That is, when server A sends th= e Include-Referer-Token-Binding-ID and redirects to server B, the TokenBind= ingMessage sent to server B has a provided TokenBinding with the client'= ;s TokenBindingID for server B and a signature of the EKM for the connectio= n to server B, and a referred TokenBinding with the client's TokenBindi= ngID for server A and a signature of the EKM for the connection to server B= . This way, server B can verify the signature for both keys (assuming serve= r B supports the key parameter used for the referred TokenBinding).

On Mon, Feb 29, 201= 6 at 1:57 PM, <jeff.hodges@kingsmountain.com> w= rote:
Hi,

The=C2=A0 last paragraph of -tokbind-protocol-04 section 4 [1] begins with.= .

=C2=A0 =C2=A0If the Token Binding message does not contain at least one
=C2=A0 =C2=A0TokenBinding structure, or the signature contained in a
=C2=A0 =C2=A0TokenBinding structure is invalid, the server MUST terminate =C2=A0 =C2=A0the connection.

..however, if the Token Binding Message received from the client, over
"this" TLS session, contains TokenBinding structure(s) with..

=C2=A0 TokenBinding.tokenbinding_type =3D=3D referred_token_binding

..(as well as provided_token_binding types), then the server will not be able to verify the signature(s) within those "referred" TokenBind= ing
struct(s) because the server would obtain an Exported Keying Material
(EKM) [RFC5705] value from the TLS stack that is different from the EKM
value used when the referred_token_binding TokenBinding struct was created<= br> by the client, but with a different server over a different TLS session
-- yes ?=C2=A0 =C2=A0Or am I misunderstanding how [RFC5705] works?

thanks,

=3DJeffH

[1] <https://tools.ietf.org/h= tml/draft-ietf-tokbind-protocol-04#section-4>


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable=

--089e016348a84e1767052cf02730-- From nobody Mon Feb 29 14:59:20 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CC1A0089 for ; Mon, 29 Feb 2016 14:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no 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 MHny4ifxCk84 for ; Mon, 29 Feb 2016 14:59:18 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 F14191A008A for ; Mon, 29 Feb 2016 14:59:17 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g203so203735258iof.2 for ; Mon, 29 Feb 2016 14:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0mY3e+iLo2OsK6oOQn3vq4iwDucFe8A4Ya3mi3f90f8=; b=pypzqwXKCOxgPI8CxHcsZRloPbOZlNzhomu1bqHsaIOt0Nc+zljRu+P5r48L5ITHAV GyUkcq14eZdBQCIJa0pKNZGYL9oOZu99W1uzCvJmz99VPLkTPLLVLDwCzA9Jd9NlXw/M Ea/G/XRLKxmWwB2/Z0DZh4i6IPh0gZLA8vmc0M5/BgE5YZ0EHdu75cpHIodL6A+57Io0 dc5bW7LPUHDZ3CthfkhfQtYFTganNMU44JyyNCMDmcMYZb4SxEUMtFq+aWmUwrZSptHb y7G5XihryXvLU673WjGrHc8Uw1q3Qoj3UlaeNqvDwSanoZ+y2zzjn1zCy89Ua8TvUvnz pckw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0mY3e+iLo2OsK6oOQn3vq4iwDucFe8A4Ya3mi3f90f8=; b=Tjy2Z3vRX6/x08qpCN4fj2aFaO/YlZHKw5YDRIoxVX0Pi4HPz6VuCmtJ8I6nKadlst f/bhX27tbWv6EX2njDT2IuLGQwIoQEO0NLRlNBy05tETJ4bdhkdiP/Fu6+l6gMIknQ88 enpo7YeYcudU2Rglu0GzxV/CptQ1FP5xxWSDK1LJ4sEwUYVxkuKo4FEoMmwazrgDIU6u qlVRGHeZdxbQY7Kwu9CndnxipnNFDGOBE/C4maEmc8InFKqT5RYNtJPr3RvfVKGteWsW sA4rN9Ai95s5zJ/pfl1plKy8v61nuAJ4jJTlC1B1aAFUj7sHHS0okMg/6QzWmHEYHMp0 SrJw== X-Gm-Message-State: AG10YORCEX+x6XlFLPSyeQJA+gfunHhYjq4C/Bj2o7vVFyVEmGldQYg3pFichyLoV2k+LLC9ufLxVP3G2shCUztA MIME-Version: 1.0 X-Received: by 10.107.10.101 with SMTP id u98mr22896953ioi.60.1456786757352; Mon, 29 Feb 2016 14:59:17 -0800 (PST) Received: by 10.107.183.141 with HTTP; Mon, 29 Feb 2016 14:59:17 -0800 (PST) In-Reply-To: References: <4c28612dcfaeaad73c9b1b8fb18d55ef.squirrel@box514.bluehost.com> Date: Mon, 29 Feb 2016 14:59:17 -0800 Message-ID: From: Bill Cox To: Nick Harper Content-Type: multipart/alternative; boundary=001a113edb302fbd33052cf09956 Archived-At: Cc: Tokbind WG , Jeff Hodges Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 29 Feb 2016 22:59:19 -0000 --001a113edb302fbd33052cf09956 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 29, 2016 at 2:27 PM, Nick Harper wrote: > My understanding of referred token bindings is that the signature in the > TokenBinding struct is over the same EKM value for all TokenBinding structs > in the TokenBindingMessage. That is, when server A sends the > Include-Referer-Token-Binding-ID and redirects to server B, the > TokenBindingMessage sent to server B has a provided TokenBinding with the > client's TokenBindingID for server B and a signature of the EKM for the > connection to server B, and a referred TokenBinding with the client's > TokenBindingID for server A and a signature of the EKM for the connection > to server B. This way, server B can verify the signature for both keys > (assuming server B supports the key parameter used for the referred > TokenBinding). > That's my understanding as well. Bill --001a113edb302fbd33052cf09956 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 29, 2016 at 2:27 PM, Nick Harper <nharper@google.com> wrote:
My understandi= ng of referred token bindings is that the signature in the TokenBinding str= uct is over the same EKM value for all TokenBinding structs in the TokenBin= dingMessage. That is, when server A sends the Include-Referer-Token-Binding= -ID and redirects to server B, the TokenBindingMessage sent to server B has= a provided TokenBinding with the client's TokenBindingID for server B = and a signature of the EKM for the connection to server B, and a referred T= okenBinding with the client's TokenBindingID for server A and a signatu= re of the EKM for the connection to server B. This way, server B can verify= the signature for both keys (assuming server B supports the key parameter = used for the referred TokenBinding).

= That's my understanding as well.

Bill=C2=A0
--001a113edb302fbd33052cf09956-- From nobody Mon Feb 29 17:41:00 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648251A88F3 for ; Mon, 29 Feb 2016 17:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 skVJ4b6BmuF8 for ; Mon, 29 Feb 2016 17:40:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6BD1A88EA for ; Mon, 29 Feb 2016 17:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qnPFfW9H3Vbq9ux7nMErU2BSIDMgeSZsA7NzWQzs7uY=; b=VKTts9P3UGenk9jiHyVDycA1GkS5/WiiLI1kHVi3eVLnYZZUfIkCz+4FPTpeyxDY1eF7juBesmTMIoBKvfCvxn8J++3upiOATjtwxJ0pi9qe6pqY0vG6nmzlDUOS+iGquwIPxA2vqNUgrRggoj7tJSVDppwINmhlG8nWb9+uXM0= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.415.20; Tue, 1 Mar 2016 01:40:33 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0415.022; Tue, 1 Mar 2016 01:40:33 +0000 From: Andrei Popov To: Bill Cox , Nick Harper Thread-Topic: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? Thread-Index: AQHRczw3axihkR3iDEaUh1hHSUJ8xp9DmiyAgAAI/YCAACo9oA== Date: Tue, 1 Mar 2016 01:40:33 +0000 Message-ID: References: <4c28612dcfaeaad73c9b1b8fb18d55ef.squirrel@box514.bluehost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-ms-office365-filtering-correlation-id: b7ed76c9-29dd-4fcf-64ac-08d341727ae9 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:FWQS9BLhxoXjZMn16hVxQtp1OlV/QN6opVAzXkTTl00adfim7wUnZEJjLJjhagWrOmYKOUcHJB/rOjBO5vh7l/6olMBsXzBPIyaJDMrS8mn0hAbQX2u/6vke8JpFxAvtKusJ3NlFJWspx1OXqmYbDg==; 24:p6uPuOWKl/BSvFKXP/CGesuRiO67qVYuCiyFJM/syrffFgvaO/WP+tOGdyCDqgT/cRjHgtjBY/9zrBCy6iE32F+JLO2gavwBqEA25LMTsqY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(74316001)(19580395003)(2900100001)(189998001)(2950100001)(5003600100002)(10290500002)(11100500001)(99286002)(2420400007)(7110500001)(15650500001)(1096002)(4326007)(1220700001)(102836003)(6116002)(87936001)(790700001)(5004730100002)(586003)(2906002)(76576001)(230783001)(19609705001)(10710500007)(10090500001)(3660700001)(5002640100001)(5005710100001)(106116001)(10400500002)(50986999)(40100003)(33656002)(92566002)(76176999)(54356999)(19625215002)(77096005)(86362001)(19617315012)(86612001)(16236675004)(15975445007)(3280700002)(122556002)(5008740100001)(5001770100001)(19300405004)(81156008)(5001960100003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13960E25993B50B722980F4B8CBB0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 01:40:33.2002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: Tokbind WG , Jeff Hodges Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Mar 2016 01:40:59 -0000 --_000_BLUPR03MB13960E25993B50B722980F4B8CBB0BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdCwgaW4gb3JkZXIgZm9yIGEgc2VydmVyIHRvIHZlcmlmeSB0aGUgYmluZGluZywgdGhl IHNpZ25hdHVyZSBoYXMgdG8gYmUgb3ZlciB0aGUgRUtNIG9mIHRoZSBUTFMgY29ubmVjdGlvbiB3 aXRoIHRoaXMgc2VydmVyLiBTdWNoIGZlZGVyYXRpb24gc2NlbmFyaW9zIGFyZSBkZXNjcmliZWQg aW4gZGV0YWlsIGluIHNlY3Rpb24gMy4yIG9mIEhUVFBTVEI6IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDIjc2VjdGlvbi0zLjINCg0KQ2hlZXJz LA0KDQpBbmRyZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5 IDI5LCAyMDE2IDI6NTkgUE0NClRvOiBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPg0K Q2M6IFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+OyBKZWZmIEhvZGdlcyA8amVmZi5o b2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIC10b2ti aW5kLXByb3RvY29sLTA0OiB2ZXJpZnlpbmcgc2lnbmF0dXJlKHMpIGluIFRva2VuQmluZGluZ01l c3NhZ2UuVG9rZW5CaW5kaW5nPw0KDQpPbiBNb24sIEZlYiAyOSwgMjAxNiBhdCAyOjI3IFBNLCBO aWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+ PiB3cm90ZToNCk15IHVuZGVyc3RhbmRpbmcgb2YgcmVmZXJyZWQgdG9rZW4gYmluZGluZ3MgaXMg dGhhdCB0aGUgc2lnbmF0dXJlIGluIHRoZSBUb2tlbkJpbmRpbmcgc3RydWN0IGlzIG92ZXIgdGhl IHNhbWUgRUtNIHZhbHVlIGZvciBhbGwgVG9rZW5CaW5kaW5nIHN0cnVjdHMgaW4gdGhlIFRva2Vu QmluZGluZ01lc3NhZ2UuIFRoYXQgaXMsIHdoZW4gc2VydmVyIEEgc2VuZHMgdGhlIEluY2x1ZGUt UmVmZXJlci1Ub2tlbi1CaW5kaW5nLUlEIGFuZCByZWRpcmVjdHMgdG8gc2VydmVyIEIsIHRoZSBU b2tlbkJpbmRpbmdNZXNzYWdlIHNlbnQgdG8gc2VydmVyIEIgaGFzIGEgcHJvdmlkZWQgVG9rZW5C aW5kaW5nIHdpdGggdGhlIGNsaWVudCdzIFRva2VuQmluZGluZ0lEIGZvciBzZXJ2ZXIgQiBhbmQg YSBzaWduYXR1cmUgb2YgdGhlIEVLTSBmb3IgdGhlIGNvbm5lY3Rpb24gdG8gc2VydmVyIEIsIGFu ZCBhIHJlZmVycmVkIFRva2VuQmluZGluZyB3aXRoIHRoZSBjbGllbnQncyBUb2tlbkJpbmRpbmdJ RCBmb3Igc2VydmVyIEEgYW5kIGEgc2lnbmF0dXJlIG9mIHRoZSBFS00gZm9yIHRoZSBjb25uZWN0 aW9uIHRvIHNlcnZlciBCLiBUaGlzIHdheSwgc2VydmVyIEIgY2FuIHZlcmlmeSB0aGUgc2lnbmF0 dXJlIGZvciBib3RoIGtleXMgKGFzc3VtaW5nIHNlcnZlciBCIHN1cHBvcnRzIHRoZSBrZXkgcGFy YW1ldGVyIHVzZWQgZm9yIHRoZSByZWZlcnJlZCBUb2tlbkJpbmRpbmcpLg0KDQpUaGF0J3MgbXkg dW5kZXJzdGFuZGluZyBhcyB3ZWxsLg0KDQpCaWxsDQo= --_000_BLUPR03MB13960E25993B50B722980F4B8CBB0BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29ycmVjdCwgaW4gb3JkZXIgZm9yIGEg c2VydmVyIHRvIHZlcmlmeSB0aGUgYmluZGluZywgdGhlIHNpZ25hdHVyZSBoYXMgdG8gYmUgb3Zl ciB0aGUgRUtNIG9mIHRoZSBUTFMgY29ubmVjdGlvbiB3aXRoIHRoaXMgc2VydmVyLiBTdWNoIGZl ZGVyYXRpb24gc2NlbmFyaW9zIGFyZQ0KIGRlc2NyaWJlZCBpbiBkZXRhaWwgaW4gc2VjdGlvbiAz LjIgb2YgSFRUUFNUQjogPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdG9rYmluZC1odHRwcy0wMiNzZWN0aW9uLTMuMiI+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTAyI3NlY3Rpb24tMy4yPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFi bGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkJpbGwgQ294PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjksIDIwMTYg Mjo1OSBQTTxicj4NCjxiPlRvOjwvYj4gTmljayBIYXJwZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcm Z3Q7OyBKZWZmIEhvZGdlcyAmbHQ7amVmZi5ob2RnZXNAa2luZ3Ntb3VudGFpbi5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gLXRva2JpbmQtcHJvdG9jb2wtMDQ6 IHZlcmlmeWluZyBzaWduYXR1cmUocykgaW4gVG9rZW5CaW5kaW5nTWVzc2FnZS5Ub2tlbkJpbmRp bmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIEZlYiAyOSwgMjAxNiBhdCAyOjI3IFBNLCBOaWNrIEhhcnBlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIG9mIHJlZmVycmVkIHRva2VuIGJp bmRpbmdzIGlzIHRoYXQgdGhlIHNpZ25hdHVyZSBpbiB0aGUgVG9rZW5CaW5kaW5nIHN0cnVjdCBp cyBvdmVyIHRoZSBzYW1lIEVLTSB2YWx1ZSBmb3IgYWxsIFRva2VuQmluZGluZyBzdHJ1Y3RzIGlu IHRoZSBUb2tlbkJpbmRpbmdNZXNzYWdlLiBUaGF0IGlzLCB3aGVuIHNlcnZlciBBIHNlbmRzIHRo ZSBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmluZGluZy1JRA0KIGFuZCByZWRpcmVjdHMgdG8gc2Vy dmVyIEIsIHRoZSBUb2tlbkJpbmRpbmdNZXNzYWdlIHNlbnQgdG8gc2VydmVyIEIgaGFzIGEgcHJv dmlkZWQgVG9rZW5CaW5kaW5nIHdpdGggdGhlIGNsaWVudCdzIFRva2VuQmluZGluZ0lEIGZvciBz ZXJ2ZXIgQiBhbmQgYSBzaWduYXR1cmUgb2YgdGhlIEVLTSBmb3IgdGhlIGNvbm5lY3Rpb24gdG8g c2VydmVyIEIsIGFuZCBhIHJlZmVycmVkIFRva2VuQmluZGluZyB3aXRoIHRoZSBjbGllbnQncyBU b2tlbkJpbmRpbmdJRA0KIGZvciBzZXJ2ZXIgQSBhbmQgYSBzaWduYXR1cmUgb2YgdGhlIEVLTSBm b3IgdGhlIGNvbm5lY3Rpb24gdG8gc2VydmVyIEIuIFRoaXMgd2F5LCBzZXJ2ZXIgQiBjYW4gdmVy aWZ5IHRoZSBzaWduYXR1cmUgZm9yIGJvdGgga2V5cyAoYXNzdW1pbmcgc2VydmVyIEIgc3VwcG9y dHMgdGhlIGtleSBwYXJhbWV0ZXIgdXNlZCBmb3IgdGhlIHJlZmVycmVkIFRva2VuQmluZGluZyku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYXQncyBteSB1bmRlcnN0YW5kaW5nIGFzIHdlbGwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpbGwmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB13960E25993B50B722980F4B8CBB0BLUPR03MB1396namp_--