From nobody Fri Jul 1 11:36:27 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9012D7B2 for ; Fri, 1 Jul 2016 11:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG-YLskhh-CO for ; Fri, 1 Jul 2016 11:36:23 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1468812D760 for ; Fri, 1 Jul 2016 11:36:17 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id t127so216379144qkf.1 for ; Fri, 01 Jul 2016 11:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Sv98gKkgxfHKx4McswBiT8KnkbtFeAlAOW3mnFT3f7E=; b=L5Ye0B9taaK6SB2r5sajFlgfRIxrbnevcjyFDjDgZNOqzgnk34D8jIol8CgIh4GFlo 5mbzx1tvY0JrlVyNyMJL+YC+mMPscmlm5EJPb2S4c/x5bZYSCy8omtZGaacWRbofshNh o9ddojql3OqavwOFNiGYzHVyAwxtkRfqf9YoHXrpBEiy2gvNU1unUu8glb3nHyXO9FPq YOcSz7T35M/1S/mtU0PkHY9Z3lkqgLEM/Sb/lb5SBKZ384fJfNWu1qRVLiXoRQS+oIWS PFoyHcVB2PtrRscDlj1hSUOw0fh/wWHSiKpHA/Nv+MVANRKzsqpmfeaAMmjF7UOLREGq UloA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Sv98gKkgxfHKx4McswBiT8KnkbtFeAlAOW3mnFT3f7E=; b=KUlIGTRSIX/ARvkgNmGiug34V/s5ku9fM8Ugck4t4uXVgC7Y3gsec6w6p+Pa6szAZd dX8/A6u4/eSiOlNxjQKm0CffW01XI34XJvuqC6kyqll834fDLPS/LNCeOBQglIP9tpbj k2r9e24QDIIe3rESF/lKx4vKGAR3JbZgBZuYjExyfAl6lmuN38syH/DbZHrqTyBWTMDw rCHyIZFBcFCJ8DcSxS54KPXWSftD2pZAIjeBwzcLR4lgSwOSeXVbTmOmpS63J3APUSgN /AavS0f30x9zW8gkXTSv826JHuH1M3wfDFOzYekEoitxcA9BC59CDu4LopqqHL7Jxc6n szdw== X-Gm-Message-State: ALyK8tJ6zkOAiBNHEEbpkouFSoNU8CgR72nmN3zCPlHSg8ayda7jqFUEYow39o4FpfLeYA== X-Received: by 10.55.201.70 with SMTP id q67mr27716291qki.124.1467398176159; Fri, 01 Jul 2016 11:36:16 -0700 (PDT) Received: from [192.168.1.41] ([191.115.51.34]) by smtp.gmail.com with ESMTPSA id f53sm2799465qtf.25.2016.07.01.11.36.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 11:36:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_425E16D4-7B00-46FE-AA86-9605643607E6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 1 Jul 2016 14:35:29 -0400 Message-Id: <6DC1B959-8AFE-49C4-B883-954A3D345751@ve7jtb.com> References: To: TokenBinding/Internet-Drafts X-Mailer: Apple Mail (2.3124) Archived-At: Cc: TokenBinding/Internet-Drafts , IETF Tokbind WG Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: use "same-site" rather than "first-party" terminology (#44) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 18:36:25 -0000 --Apple-Mail=_425E16D4-7B00-46FE-AA86-9605643607E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That make sense to do now. > On Jul 1, 2016, at 12:55 PM, =3DJeffH = wrote: >=20 > In the HTTP WG's efforts to update the "cookies" spec RFC6265, we've = settled on the terms "same-site" (rather than "first-party") and = "cross-site" (rather than "third-party"). >=20 > I do not doubt HTTPSTB will receive feedback during last calls on the = "first-party" and "federation" terms, and so think we should make such a = terminology change now. We can do it by drawing equivalence between = "same-site" & "first-party", and "federation" & "cross-site". >=20 > see also: = https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site = , and = #43 > =E2=80=94 > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub = , or mute the = thread = . >=20 --Apple-Mail=_425E16D4-7B00-46FE-AA86-9605643607E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That make sense to do now.


On Jul 1, 2016, at 12:55 PM, = =3DJeffH <notifications@github.com> wrote:

In the = HTTP WG's efforts to update the "cookies" spec RFC6265, we've settled = on the terms "same-site" (rather than "first-party") and "cross-site" = (rather than "third-party").

I do not doubt HTTPSTB = will receive feedback during last calls on the "first-party" and = "federation" terms, and so think we should make such a terminology = change now. We can do it by drawing equivalence between "same-site" = & "first-party", and "federation" & "cross-site".

see also: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site= , and #43

=E2=80=94
You are receiving this because you = are subscribed to this thread.
Reply to this email = directly, view it on GitHub, or mute the thread.3D""


= --Apple-Mail=_425E16D4-7B00-46FE-AA86-9605643607E6-- From nobody Fri Jul 1 15:00:15 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4112D0C8 for ; Fri, 1 Jul 2016 15:00:13 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gng3kVoDkMDC for ; Fri, 1 Jul 2016 15:00:11 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0138.outbound.protection.outlook.com [104.47.42.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A204812D0C0 for ; Fri, 1 Jul 2016 15:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ER5/fe70YrNMH1PQNtyT77wEgcEg5IWXsUqo9R734hM=; b=WJBCiGZUPClysEK8t8/G9DqsOIWn3azPei/7QTO5qSLGQiJbEYiJHdYqhfhj6kwBXg/eZnVkQQwNv031piyDTxd2WP1CSaX6Lz8xmFm868ePY9w2nNIfg3Fvk1LRLKOlgSrR4cG5DtojlcblOwPxFTM2y4QiBmG0UGpcYQjqCUo= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by BLUPR03MB1443.namprd03.prod.outlook.com (10.163.81.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Fri, 1 Jul 2016 22:00:08 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0523.025; Fri, 1 Jul 2016 22:00:09 +0000 From: Mike Jones To: "unbearable@ietf.org" Thread-Topic: Treating Token Binding ID as an opaque byte sequence Thread-Index: AdHT47NukPP44HVKTu2PZwFpWbVPpg== Date: Fri, 1 Jul 2016 22:00:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:9::650] x-ms-office365-filtering-correlation-id: c5d80fb8-2853-451f-0959-08d3a1fb116e x-microsoft-exchange-diagnostics: 1; BLUPR03MB1443; 6:MMC3FluJ4Yp7Yd1AkQiHkhRJPGVrV0u/zGqRhPiVpwfrYyEjj+iuqTAGUq/60Y3uCmM6BsXYiwlfntXJaSujiW6zRUiDxa6ZujB6N/Fih6jzGKsJ6wkkpwlcEseS4UopD7JxeL96EXwMIkX7AsBodMjZAwedgv+S60guo9wPmB01hwu3LnC3VRQ5c2Y0s8qrwVTooeInlsPhXOWoBHJqS064LdMZd6CbB5tG/wN5HfWUgfXA7XormDAIrng07mxcZbiLd90iCmI4xssB+v2SnWtvSu+Uv0CfUO2KpISk7Xq7B5zXSSD+sRXdAwa8jQhpFu3HWrUiQH8n8weVh/PoTT5goZEV+dfilXi63OC/0wg=; 5:uiGBZGVp7aBSS2sujafEtaZJGMu49wJt+IsxW055A3izvE3jcK70oSqVtV7oIeYSg7Dh+RM+0xG2a8AH1pcvDOtSjl9Q47Vvw/ewenR2b/FcDP3a9VxHom0WJInI063qpfZofd5jyujBeR66DsN82Q==; 24:h9rEy4dL6DOrm5TIIMXDu3dY1lSWLK8jbuId2v1VJCO+QRdrzwrSsHDpmf1w3MUTPIzt0kUFpbinx6k4w+XteFZSVxBzML1cGmaXQK2gaxw=; 7:HU86pewNWKviEKVJo1T86Nw+uUHGRQp65mXw3+NWMs/4Wm1YtqM5Q3Vo5hXcYSryxghL35yoUlpf0ifo1TBp+dOgC1DQ5eJ/V2CC/SnhNSf5pPa0YfhKjiP0TLNdvAIhvUjedTMe9AD5kQAVkh8C+JKaBKaillWkk6/mYbjul4VCGQAjOAuQya+3aJyM3LwaQ4a9cGzhZjQ6xszM+jbUYJpP+AHr9t0q7spiXhon33qJxebGJAqUX66pS8jBAYdNCMJ/tZ+E+EVWiUbUFm5J7Kcz1CRUZj3EJSujyqC9iH4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1443; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1443; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(16236675004)(189998001)(77096005)(33656002)(86612001)(5002640100001)(54356999)(10400500002)(50986999)(10290500002)(107886002)(5005710100001)(110136002)(15975445007)(8990500004)(19580395003)(8676002)(229853001)(105586002)(450100001)(76576001)(101416001)(106356001)(2351001)(790700001)(6116002)(102836003)(586003)(81166006)(99286002)(4001430100002)(10090500001)(19625215002)(122556002)(97736004)(92566002)(4326007)(2900100001)(8936002)(9686002)(3280700002)(7736002)(5003600100003)(7696003)(7846002)(19300405004)(1730700003)(74316002)(86362001)(81156014)(68736007)(3660700001)(2501003)(2906002)(5640700001)(5630700001)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1443; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16453F437F3FC7E9EE38723EF5250SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 22:00:08.8467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1443 Archived-At: Cc: Andrei Popov Subject: [Unbearable] Treating Token Binding ID as an opaque byte sequence X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 22:00:14 -0000 --_000_SN1PR0301MB16453F437F3FC7E9EE38723EF5250SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a private conversation with Andrei, we talked about adding a note to the= spec recommending that Token Binding APIs treat the Token Binding ID as an= opaque byte sequence, rather than as the structure defined in the protocol= (type byte, followed by public key representation). Doing so would allow = the Token Binding ID contents to change in future protocol versions without= breaking applications. This is a reminder to add this note to the spec. -- Mike --_000_SN1PR0301MB16453F437F3FC7E9EE38723EF5250SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In a private conversation with Andrei, we talked abo= ut adding a note to the spec recommending that Token Binding APIs treat the= Token Binding ID as an opaque byte sequence, rather than as the structure = defined in the protocol (type byte, followed by public key representation).  Doing so would allow the Tok= en Binding ID contents to change in future protocol versions without breaki= ng applications.

 

This is a reminder to add this note to the spec.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_SN1PR0301MB16453F437F3FC7E9EE38723EF5250SN1PR0301MB1645_-- From nobody Sun Jul 3 19:04:54 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C757912D1B3 for ; Sun, 3 Jul 2016 19:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s24D6bsGLWyF for ; Sun, 3 Jul 2016 19:04:50 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id BB75F128874 for ; Sun, 3 Jul 2016 19:04:50 -0700 (PDT) Received: (qmail 15930 invoked by uid 0); 4 Jul 2016 02:04:45 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 4 Jul 2016 02:04:45 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id ES4c1t00D2UhLwi01S4fgb; Sun, 03 Jul 2016 20:04:44 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB 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=cAmyUtKerLwA:10 a=NEAV23lmAAAA:8 a=J0XNs_veWOjPMakIKbwA:9 a=QEXdDO2ut3YA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:Subject:Cc:To: From:Message-ID:Date; bh=9ix1MfPD37DxIxfPAGArCa2wiKSrsnzpoW6lNDQBKxM=; b=pTAF 0xISGdRx6DKGKQxX/j/umtWycbBAB56MMpcmiS4Dke8IBdQLm9+nv4cH6ptHWLXpP7NpTV6Z5HHR9 nPoUdzUZc3kmF0ZbRMh75BtfUa5ZGrsVV9GEwx4cOmLWaHU; Received: from [127.0.0.1] (port=49800 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bJtFV-0005j3-JK; Sun, 03 Jul 2016 20:04:37 -0600 Received: from 73.202.80.238 ([73.202.80.238]) by box514.bluehost.com (Horde Framework) with HTTP; Sun, 03 Jul 2016 20:04:35 -0600 Date: Sun, 03 Jul 2016 20:04:35 -0600 Message-ID: <20160703200435.Horde.Ke4QqE3nHi50pQaiuWxuLB7@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Dirk Balfanz User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bJtFV-0005j3-JK X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:49800 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF Tokbind WG Subject: [Unbearable] HTTPSTB: use 'misuse' rather than 'theft' regarding theats to bound security tokens X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 02:04:53 -0000 https://github.com/TokenBinding/Internet-Drafts/issues/45 -tokbind-https aka HTTPSTB presently uses (in 3 places) the word "theft" in terms of the threats bound security tokens are protected from (by virtue of being bound to the client-server TLS layer). In thinking about it, and as alluded to in [TBPROTO] section 8.1 "security token replay", a bound security token is not protected from misappropriation (per se) by virtue of being bound. Rather, it is protected from being successfully misused by an attacker -- i.e., it will not be honored by the server (unless the attacker has infiltrated the user agent itself). Thus I propose we use the term "misuse" rather than "theft" and alter surrounding text appropriately. HTH, =JeffH From nobody Sun Jul 3 19:49:47 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD1A12D0F1 for ; Sun, 3 Jul 2016 19:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjPUNWs5aYWn for ; Sun, 3 Jul 2016 19:49:44 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id B5EAD12B03D for ; Sun, 3 Jul 2016 19:49:44 -0700 (PDT) Received: (qmail 1913 invoked by uid 0); 4 Jul 2016 02:49:36 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Jul 2016 02:49:36 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id ESpW1t00Q2UhLwi01SpZ6J; Sun, 03 Jul 2016 20:49:36 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN 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=cAmyUtKerLwA:10 a=NEAV23lmAAAA:8 a=p2bSW4TYYJjeCuLfacUA:9 a=QEXdDO2ut3YA:10 a=a2Cu53CcaCMA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:Subject:Cc:To: From:Message-ID:Date; bh=xXafssCXThVo+ohioxPhPLJu8hAsYHKIq9EuqAQN6cI=; b=IYPx FetQLyAW4lLoz6EIjI9Wdteuesm17F57AlQkYmpAWduSbh8bMs7gPZKZolqcWeUTRZ2ujgG8NBSW+ o4NTVx8DTPYTt20ezkcTGNq7BVRvleZ3ahYni6s3PeBRvkp; Received: from [127.0.0.1] (port=58441 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bJtwx-0001DV-03; Sun, 03 Jul 2016 20:49:31 -0600 Received: from 73.202.80.238 ([73.202.80.238]) by box514.bluehost.com (Horde Framework) with HTTP; Sun, 03 Jul 2016 20:49:28 -0600 Date: Sun, 03 Jul 2016 20:49:28 -0600 Message-ID: <20160703204928.Horde.Q114kcRX7h5OnnVUDCwu1ya@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Dirk Balfanz User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bJtwx-0001DV-03 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:58441 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF Tokbind WG Subject: [Unbearable] HTTPSTB-editorial: resolves various issues PR#46 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 02:49:46 -0000 Dirk -- for your (and others' :) review... https://github.com/TokenBinding/Internet-Drafts/pull/46 This initial set of commits comprises some minor editorial cleanups of wording and how citations are manifested, and fixes #43, fixes #44, begins work on #45. I may add further commits this evening. HTH, =JeffH From nobody Mon Jul 4 08:15:48 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0326A12D159 for ; Mon, 4 Jul 2016 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCZuHxcxZ0FO for ; Mon, 4 Jul 2016 08:15:45 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 6814312D094 for ; Mon, 4 Jul 2016 08:15:45 -0700 (PDT) Received: (qmail 23200 invoked by uid 0); 4 Jul 2016 15:15:45 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 4 Jul 2016 15:15:45 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id EfFe1t00M2UhLwi01fFhH5; Mon, 04 Jul 2016 09:15:45 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H 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=cAmyUtKerLwA:10 a=NEAV23lmAAAA:8 a=_5ne70Eg8WYmqH0uk3IA:9 a=QEXdDO2ut3YA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:Subject:Cc:To: From:Message-ID:Date; bh=DCA0c+Y2LH6+yeDufPEa7Jx/KnADEPJ9Pdji6/Al01s=; b=l9ac 4ZbiqxLGUIQp2W8+KcuHhkP2gn1CAxv74sufLvc0JwaAzHOeq6w4Uy1rfeB9j9rHh/czRiK2ktien HJCrEwoIuCM7WiRZtMg2++z6DdESVAr6B7p+ERVHyOfuhCj; Received: from [127.0.0.1] (port=53903 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bK5b0-0001fj-9f; Mon, 04 Jul 2016 09:15:38 -0600 Received: from 73.202.80.238 ([73.202.80.238]) by box514.bluehost.com (Horde Framework) with HTTP; Mon, 04 Jul 2016 09:15:35 -0600 Date: Mon, 04 Jul 2016 09:15:35 -0600 Message-ID: <20160704091535.Horde.Q8rc3sfmPfwCk0vd8-iFMmg@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Dirk Balfanz User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bK5b0-0001fj-9f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:53903 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF Tokbind WG Subject: [Unbearable] HTTPSTB-#23-muti-hop: PR#47: be more explicit about multi-hop binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 15:15:47 -0000 Dirk wrote in > suggestions what this should look like in the spec? Since we > convinced ourselves that a single referred token binding suffices > for these scenario, how should this be addressed in the spec? see: https://github.com/TokenBinding/Internet-Drafts/pull/47 This is a stab at addressing issue #23 "HTTPSTB: be more explicit about multi-hop binding (RP->IDP1->IDP2->IDP1->RP)" -- WDYT? =JeffH From nobody Mon Jul 4 08:57:53 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EFE12B031 for ; Mon, 4 Jul 2016 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr0cUGcTbwt2 for ; Mon, 4 Jul 2016 08:57:48 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 4E81912D16D for ; Mon, 4 Jul 2016 08:57:48 -0700 (PDT) Received: (qmail 3233 invoked by uid 0); 4 Jul 2016 15:57:47 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Jul 2016 15:57:47 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id Efxk1t00D2UhLwi01fxnTc; Mon, 04 Jul 2016 09:57:47 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H 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=cAmyUtKerLwA:10 a=yMhMjlubAAAA:8 a=NEAV23lmAAAA:8 a=hLc_RHG4h2zNSm3gqwYA:9 a=QEXdDO2ut3YA:10 a=BKKCjISod1eDJeS0ORpz:22 a=Bn2pgwyD2vrAyMmN8A2t:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:In-Reply-To: Subject:Cc:To:From:Message-ID:Date; bh=cOExJADm2acBQl67dB4afCGlTVzmwvVqv8cCtjfVmJg=; b=CSLMOKdqz9NhD3JhcFACK3dJF5 hMoVtQsN5Fm6r/hEFoyM7IKwZp0+3L/SZtaQq6bW/835pGwV86zVW2/IQP6+Cn4xn63jAD8FOxALP TyST8o9fxrFy1YzkXOOHSylW7; Received: from [127.0.0.1] (port=57438 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bK6Fk-0000SM-0a; Mon, 04 Jul 2016 09:57:44 -0600 Received: from 73.202.80.238 ([73.202.80.238]) by box514.bluehost.com (Horde Framework) with HTTP; Mon, 04 Jul 2016 09:57:41 -0600 Date: Mon, 04 Jul 2016 09:57:41 -0600 Message-ID: <20160704095741.Horde.DFWmfj51Q9UsysRx7bCJg5x@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Mike Jones In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bK6Fk-0000SM-0a X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:57438 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: unbearable@ietf.org, Andrei Popov Subject: Re: [Unbearable] Treating Token Binding ID as an opaque byte sequence X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 15:57:50 -0000 Quoting Mike Jones : > In a private conversation with Andrei, we talked about adding a note > to the spec recommending that Token Binding APIs treat the Token > Binding ID as an opaque byte sequence, rather than as the structure > defined in the protocol (type byte, followed by public key > representation). Doing so would allow the Token Binding ID contents > to change in future protocol versions without breaking applications. > > This is a reminder to add this note to the spec. submitted as: https://github.com/TokenBinding/Internet-Drafts/issues/48 From nobody Mon Jul 4 13:19:42 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F1A12D08C for ; Mon, 4 Jul 2016 13:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsaKIA6Zi0qp for ; Mon, 4 Jul 2016 13:19:39 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 7D5D0127078 for ; Mon, 4 Jul 2016 13:19:39 -0700 (PDT) Received: (qmail 19725 invoked by uid 0); 4 Jul 2016 20:19:38 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Jul 2016 20:19:38 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id EkKY1t00a2UhLwi01kKb9x; Mon, 04 Jul 2016 14:19:36 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB 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=cAmyUtKerLwA:10 a=NEAV23lmAAAA:8 a=-88CysqsFPrWMsW6vsoA:9 a=QEXdDO2ut3YA:10 a=avybmMxr35MA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:Subject:Cc:To: From:Message-ID:Date; bh=XtPz1OcIPFfXEb9cmqKeOLWeRb7iiH0stf5fOkij5SE=; b=VNsO 5fx7ZvwHrw93Ih2w4vTMtEgFPxEnlUhJGPfw3DQeVAAnMROf1AKKAS2h9vdJxswGw6V1y3JnipWT6 hdM2/ZHOOlszk0oXIRk0oTtg5WFz+xDc3akhGTGT3scZ01q; Received: from [127.0.0.1] (port=43547 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bKAL8-0006cA-0h; Mon, 04 Jul 2016 14:19:34 -0600 Received: from 73.202.80.238 ([73.202.80.238]) by box514.bluehost.com (Horde Framework) with HTTP; Mon, 04 Jul 2016 14:19:31 -0600 Date: Mon, 04 Jul 2016 14:19:31 -0600 Message-ID: <20160704141931.Horde.Yt3ckkOY-okV0GPzKbyu1Th@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Dirk Balfanz User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bKAL8-0006cA-0h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:43547 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF Tokbind WG Subject: [Unbearable] HTTPSTB-#33-scoping: fixes #33 scoping of TB keys X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 20:19:41 -0000 Dirk -- for your (and others' :) review... https://github.com/TokenBinding/Internet-Drafts/pull/49 this is a stab at addressing #33 scoping of TB keys. it assumes that #46 is adopted (hm, looks like it was) -- upon merging of this PR, additional proper xrefs between key-scoping and first-party and federation sections ought to be added. HTH =JeffH From nobody Mon Jul 4 19:35:35 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE5F12D0C7 for ; Mon, 4 Jul 2016 19:35:33 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARMt8PlpXb7M for ; Mon, 4 Jul 2016 19:35:31 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0132.outbound.protection.outlook.com [104.47.34.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D2712D0C5 for ; Mon, 4 Jul 2016 19:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NAhGr1BsH4LJWGRrDLX8T6il771Mg+Yi2cEEFFlufOo=; b=CPaEiHWXR1J0dEScUZ/9h54hObUpF6L6tJvwDTHrGm4M3Mz9oJOiMgP7MplZncbVSwPNa+lKMTfA207HDDTtfC9Dy4fYxczUzkmziZ0/VzaM763TiXemVpmp6v+JsflLnAtLZgHL7SrK5tqkVHKS+p1WONAzvPMp0a3EVLPyHl8= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Tue, 5 Jul 2016 02:35:30 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0523.028; Tue, 5 Jul 2016 02:35:30 +0000 From: Mike Jones To: "unbearable@ietf.org" Thread-Topic: Token Binding for Access Tokens, Refresh Tokens, and ID Tokens Thread-Index: AdHWXIEv5fjJPXp1SGC8eaL/01WjRgACVWbQ Date: Tue, 5 Jul 2016 02:35:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.19] x-ms-office365-filtering-correlation-id: 6aaf57cb-fe3a-4945-86ee-08d3a47d07fa x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:xzkH1FhL1baCJarjBruJwnYl4cUB//EIes9Qd8UZubVt2grZ/HIYIScgqAvD3ppjaa82PUR7BuwHHgvc6LTmPLq+awOk4IV6Dh27u2NWoyL/PwDl40YQNUM9zitTzxhTIWmzY14PwgubDzcyBCJe3K7cLWqqzpa4ZaENT8HYDq6Sg/ouWQtNNwhYEfO0rH4X2Sa3RmT0XpwEsS1pKOjsQNpl9Dy4uhV2Yz2jaF3S0FZ2xQRez/qCW2lRQ/rvpvKPq0ZDgtYQIsFg1JFlWmpFTTzScn6JXspvHRdeHxngC5wad9XGbXaiXGu7Nxk9RT8syIhXqe5kiTkkRa4IhqsYUQ==; 5:gO3QUPmrC/FhjKzGINdJz0rI/XrZ4XTtqgsej+gUURVq9XC8cM+wPHkgdwnQWtwiHfWQPMOs3+RNYHg3aXOxk8tLcHTeynaD8mLtmGe+gj4LEKGAUNfUf2mWca08HO+UQm8PRxkQVpJWrk7mBkH74Q==; 24:W8qmMTkyDlpgZEI+6+ZhzYTeebR//V1LU2PGcWoVGgcUh3JE1NZm5CSEiq39D5/fbCJ7iQrkOkLNtZrFpIE2IXSW6uOctefUl6Pk4C3j8ac=; 7:OWPdNfcF2N+HSDDMbUCMueoo+NMSZFA+JZnhpG2u2LIJgYcMpnGgss4iLnCGpKDn1M2WCwgvIvYRT5NA8VTMY3cNSapvZponG1ysWa9X9biARN9q3AMv2b/rdXF7eI93gvjA7KyuiXXWHR5vvx5zJaGoLvg2/TlihxznXEp/mzx+Q6Pb6Ss8AruBf3fhOAlg2Um4lRe+/yVLoUdJU9R43Dtn+zZZcJWLptf9GK5lPNO9jR8n7cOYprsOvrAT5BUd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(31418570063057)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(377454003)(199003)(189002)(122556002)(8990500004)(99286002)(33656002)(19617315012)(68736007)(19625215002)(87936001)(8936002)(3900700001)(105586002)(86612001)(106356001)(2501003)(19300405004)(86362001)(2351001)(11100500001)(3280700002)(3660700001)(16236675004)(50986999)(10090500001)(9686002)(6116002)(3846002)(102836003)(790700001)(76576001)(5002640100001)(586003)(450100001)(7846002)(7906003)(92566002)(77096005)(74316002)(15975445007)(2900100001)(2950100001)(2906002)(5003600100003)(7696003)(7736002)(10400500002)(110136002)(10290500002)(97736004)(5005710100001)(54356999)(76176999)(66066001)(19580405001)(19580395003)(101416001)(5640700001)(81166006)(81156014)(1730700003)(5630700001)(107886002)(189998001)(8676002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645CFEAA301921F3DA43BE8F5390SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2016 02:35:29.9576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Subject: [Unbearable] FW: Token Binding for Access Tokens, Refresh Tokens, and ID Tokens X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 02:35:33 -0000 --_000_SN1PR0301MB1645CFEAA301921F3DA43BE8F5390SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would be useful to discuss the first open issue about the ability for th= e client to provide a referred token binding for the resource server to the= authorization server at https://tools.ietf.org/html/draft-jones-oauth-toke= n-binding-00#appendix-B on the list and in Berlin. -- Mike From: Mike Jones Sent: Monday, July 4, 2016 7:33 PM To: oauth@ietf.org Subject: Token Binding for Access Tokens, Refresh Tokens, and ID Tokens Two new related specifications define syntax and semantics for applying Tok= en Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect = ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-t= oken-bound-authentication-1_0 contains the OpenID Connect portions. These are being submitted now to hopefully enable end-to-end implementation= s and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID = Tokens across multiple platforms before the Token Binding specifications ar= e finalized. The OAuth specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-token-binding-00 (HTML= ized text plus links to other formats) * http://self-issued.info/docs/draft-jones-oauth-token-binding-00.htm= l (HTML) The OpenID Connect specification is available at: * http://self-issued.info/docs/openid-connect-token-bound-authenticat= ion-1_0-00.html (HTML) * http://self-issued.info/docs/openid-connect-token-bound-authenticat= ion-1_0-00.txt (Text) * http://self-issued.info/docs/openid-connect-token-bound-authenticat= ion-1_0-00.xml (XML Source) Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell fo= r reviews of earlier versions of these specifications and to Dirk Balfanz a= nd William Denniss for some earlier discussions providing input to these sp= ecifications. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1577 and as= @selfissued. --_000_SN1PR0301MB1645CFEAA301921F3DA43BE8F5390SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would be useful to discuss the first open issue a= bout the ability for the client to provide a referred token binding for the= resource server to the authorization server at https://tools.ietf.org/html/draft-jones-oauth-token-binding-00#appendix-B on the list and in Berlin.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

From: Mike Jones
Sent: Monday, July 4, 2016 7:33 PM
To: oauth@ietf.org
Subject: Token Binding for Access Tokens, Refresh Tokens, and ID Tok= ens

 

Two new related specifications define syntax and sem= antics for applying Token Binding to OAuth Access Tokens and Refresh Tokens= and to OpenID Connect ID Tokens.  draf= t-jones-oauth-token-binding contains the OAuth portions.  openid-connect-token-bound-authentication-1_0 contains the OpenID Conne= ct portions.

 

These are being submitted now to hopefully enable en= d-to-end implementations and interop testing of Token Bound Access Tokens, = Refresh Tokens, and ID Tokens across multiple platforms before the Token Bi= nding specifications are finalized.

 

The OAuth specification is available at:<= /p>

·       http://tools.ietf.org/html/draft-jones-oauth-= token-binding-00 (HTMLized text plus links to other formats)=

·       http://self-issued.info/docs/draft-jon= es-oauth-token-binding-00.html (HTML)

 

The OpenID Connect specification is available at:

·       http://self-issued.info/= docs/openid-connect-token-bound-authentication-1_0-00.html (HTML)<= /o:p>

·       http://self-issued.info/d= ocs/openid-connect-token-bound-authentication-1_0-00.txt (Text)

·       http://self-issued.info/d= ocs/openid-connect-token-bound-authentication-1_0-00.xml (XML Source)

 

Thanks to Andrei Popov, Yordan Rouskov, John Bradley= , and Brian Campbell for reviews of earlier versions of these specification= s and to Dirk Balfanz and William Denniss for some earlier discussions prov= iding input to these specifications.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1577 and as @selfissued.

--_000_SN1PR0301MB1645CFEAA301921F3DA43BE8F5390SN1PR0301MB1645_-- From nobody Tue Jul 5 11:35:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409BE12D0CD for ; Tue, 5 Jul 2016 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzNW7rS73FCh for ; Tue, 5 Jul 2016 11:35:24 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 B997F12D68A for ; Tue, 5 Jul 2016 11:35:20 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id j185so57428386ith.0 for ; Tue, 05 Jul 2016 11:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qRuze971NUq3SgRgqn3/8M7I++KmB7YFw9h6GpycMoM=; b=Q70xivGvL9fhByP8OBnnPn/WSwAiXofltBFPAVC2Bf+UohiTaTMRyPvkJ+qEe6L7uP UBUjefF0Y0gq+z11Zx1k9S1xCHAcSekbF7LNtSto89aDP+pQONChKWtAIA0tmL+OWdWh ygQeH4QyVEEv+vdU45oB+nr97aygZaP2intDU= 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=qRuze971NUq3SgRgqn3/8M7I++KmB7YFw9h6GpycMoM=; b=mrxJs2Y9nxDIiO4kdv6I3zsmA7LNdiqizoDNhlOyobEhqpMED/6LY51bq44tf6vJr8 0WC6nhUO5BfF2uei5ctjawPYboS2x5M1ghXSv37CNqQlkmh6UTczaUAbOKqilQNmB72O AOCcDG1Il1KqXfr9psxzkxXc3YgpiwpC9mRTRITuZqF8lRvm/PXCqs8ZqA7rmVRRWqp4 PmnTJ1hlFUcemFv9X1CXTONg6rUoOMIbQOjkXPtrCudm9C4Py+m/td7rmmGV5aqVEtH6 5kwGSVDN8pjDD0dN8JJOV8K1DnahjNmAfvu9dgdR0TfO7SE77TrHA+4kxosBjBdIGQb5 phKg== X-Gm-Message-State: ALyK8tLaFviZTkx1XGVvasqwWBMBX+sYaB8SKF0p097cvo9XIJPeZ+MyiYxaKvUfkid6uUqrDxnJAZROg7or0xE6 X-Received: by 10.36.77.70 with SMTP id l67mr15705552itb.11.1467743720022; Tue, 05 Jul 2016 11:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Tue, 5 Jul 2016 11:34:50 -0700 (PDT) In-Reply-To: <20160703200435.Horde.Ke4QqE3nHi50pQaiuWxuLB7@box514.bluehost.com> References: <20160703200435.Horde.Ke4QqE3nHi50pQaiuWxuLB7@box514.bluehost.com> From: Brian Campbell Date: Tue, 5 Jul 2016 12:34:50 -0600 Message-ID: To: Jeff Hodges Content-Type: multipart/alternative; boundary=001a114493600de2730536e7b73b Archived-At: Cc: IETF Tokbind WG , Dirk Balfanz Subject: Re: [Unbearable] HTTPSTB: use 'misuse' rather than 'theft' regarding theats to bound security tokens X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:35:26 -0000 --001a114493600de2730536e7b73b Content-Type: text/plain; charset=UTF-8 Makes sense to me. On Sun, Jul 3, 2016 at 8:04 PM, wrote: > https://github.com/TokenBinding/Internet-Drafts/issues/45 > > -tokbind-https aka HTTPSTB presently uses (in 3 places) the word "theft" > in terms of the threats bound security tokens are protected from (by virtue > of being bound to the client-server TLS layer). > > In thinking about it, and as alluded to in [TBPROTO] section 8.1 "security > token replay", a bound security token is not protected from > misappropriation (per se) by virtue of being bound. Rather, it is protected > from being successfully misused by an attacker -- i.e., it will not be > honored by the server (unless the attacker has infiltrated the user agent > itself). > > Thus I propose we use the term "misuse" rather than "theft" and alter > surrounding text appropriately. > > HTH, > > =JeffH > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114493600de2730536e7b73b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Makes sense to me.
On Sun, Jul 3, 2016 at 8:04 PM, <jeff.hodges@kingsmountain.com> wrote:
https://github.com/TokenBindi= ng/Internet-Drafts/issues/45

-tokbind-https aka HTTPSTB presently uses (in 3 places) the word "thef= t" in terms of the threats bound security tokens are protected from (b= y virtue of being bound to the client-server TLS layer).

In thinking about it, and as alluded to in [TBPROTO] section 8.1 "secu= rity token replay", a bound security token is not protected from misap= propriation (per se) by virtue of being bound. Rather, it is protected from= being successfully misused by an attacker -- i.e., it will not be honored = by the server (unless the attacker has infiltrated the user agent itself).<= br>
Thus I propose we use the term "misuse" rather than "theft&q= uot; and alter surrounding text appropriately.

HTH,

=3DJeffH

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

--001a114493600de2730536e7b73b-- From nobody Tue Jul 5 13:12:35 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1F912D0FC for ; Tue, 5 Jul 2016 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV-g0PNc1AoK for ; Tue, 5 Jul 2016 13:12:32 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 A327512B050 for ; Tue, 5 Jul 2016 13:12:32 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a66so167186637wme.0 for ; Tue, 05 Jul 2016 13:12:32 -0700 (PDT) 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; bh=M8Xr58ujHE5tCJYZ1Ff+EMW6LkPsY7A7vOIacTlYFKY=; b=NFaC9TWzD7iABpEJDkwFhc0QamfW4VMAwhfor/R2UrXEmU/MZY5cOQs3TS/HALnSnJ FMhWL0YEnamE7juk5fQeje7dt97JK3dYH1GYcI+ed/TnUmltKQsT02JgPIy90GVywKPZ 3bCgLkdXr2AbQJ5/WZhfd1G7JSPfCPJaYEQa+enSW0nmENJqvAJPOlH22h1amAAnkAp3 83325HowiGsQleYmq+89UoXekKDQ9/Yk2h2+DYNLg9TjL+gVnnN9+NgWZCbceSjzck/L JUrhOIvzD7pR/tSCN5iD7ZJbaGzn6/AF2cj5+Kn6xhhWbar1QBX9juslvUSulaLoxCy6 CHtQ== 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; bh=M8Xr58ujHE5tCJYZ1Ff+EMW6LkPsY7A7vOIacTlYFKY=; b=FgDI3gEpEIvmHB3dwArVyCCgPkOMQNzltnLuH2n2ytSJnwnPFMOaRxAzqLD6lP4UKH 0+1HiUZpQgWM8nD+9FmByCtAtNoBHNrilwtQwF+sKWF0Wy3bPGBLTgSL8rRm2Sw4vrwK dKJh8svjqAC+0tdH+WyvKP/Gg0UUAf1HTxnbRdnVfNtfIEMIFgckn2rS4csuQ3+zxQZg S283B0joADcrZXCRs46QyZo7hGCGmJgneztmouJmOzrtvKODT5Sl5tY6Vnr8+3PCqB1S 5WQRGzo2aW2cLl1PRlzeF2fHL0+XfTCGRcTxSrfczGujrBnnRrptgNjgURmM9CPkoD8O YMGQ== X-Gm-Message-State: ALyK8tKR8YdXWGtN6Wdzi8lPBjyPI8G9vgxYKXxwNAgXKa6/yWslv3RUKQj8EvqFNnc25OSkWS5AOSA/bAVO0DFj X-Received: by 10.28.188.137 with SMTP id m131mr16990384wmf.4.1467749550853; Tue, 05 Jul 2016 13:12:30 -0700 (PDT) MIME-Version: 1.0 References: <20160704141931.Horde.Yt3ckkOY-okV0GPzKbyu1Th@box514.bluehost.com> In-Reply-To: <20160704141931.Horde.Yt3ckkOY-okV0GPzKbyu1Th@box514.bluehost.com> From: Dirk Balfanz Date: Tue, 05 Jul 2016 20:12:21 +0000 Message-ID: To: jeff.hodges@kingsmountain.com Content-Type: multipart/alternative; boundary=001a114b14ce99c1b90536e91249 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB-#33-scoping: fixes #33 scoping of TB keys X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 20:12:34 -0000 --001a114b14ce99c1b90536e91249 Content-Type: text/plain; charset=UTF-8 Hi Jeff - I merged this PR. I tried to fix the merge conflicts, but can you double-check? Dirk. On Mon, Jul 4, 2016 at 10:19 PM wrote: > > Dirk -- for your (and others' :) review... > > https://github.com/TokenBinding/Internet-Drafts/pull/49 > > this is a stab at addressing #33 scoping of TB keys. it assumes that > #46 is adopted (hm, looks like it was) -- upon merging of this PR, > additional proper xrefs between key-scoping and first-party and > federation sections ought to be added. > > HTH > > =JeffH > > > --001a114b14ce99c1b90536e91249 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff - I merged this PR. I tried to fix the merge confl= icts, but can you double-check?

Dirk.


On Mon, Jul 4, 2016= at 10:19 PM <jeff.hodg= es@kingsmountain.com> wrote:

Dirk -- for your (and others' :) review...

https://github.com/TokenBinding/Internet-Draf= ts/pull/49

this is a stab at addressing #33 scoping of TB keys. it assumes that
#46 is adopted (hm, looks like it was) -- upon merging of this PR,
additional proper xrefs between key-scoping and first-party and
federation sections ought to be added.

HTH

=3DJeffH


--001a114b14ce99c1b90536e91249-- From nobody Tue Jul 5 17:25:18 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D312D50C for ; Tue, 5 Jul 2016 17:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15LHe9SxrEJS for ; Tue, 5 Jul 2016 17:25:15 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 9CDA012D0C8 for ; Tue, 5 Jul 2016 17:25:15 -0700 (PDT) Received: (qmail 16092 invoked by uid 0); 6 Jul 2016 00:25:14 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 6 Jul 2016 00:25:14 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id FCRB1t00P2UhLwi01CREUl; Tue, 05 Jul 2016 18:25:14 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H 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=REyjYVsJDQUA:10 a=cAmyUtKerLwA:10 a=48vgC7mUAAAA:8 a=bt8Zh30PAAAA:8 a=NEAV23lmAAAA:8 a=myxBTT9_BLWsKPHr9kQA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=oiBpN-rYJXxenNlZAEox:22 a=Bn2pgwyD2vrAyMmN8A2t:22 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=1ujzQ0MCfZS72UDPnYk0g8ah4OS5GpqXNcs8hlbAoHk=; b=aB+JlDYYfPO9qJyOXDYp4QtZKl flyKbAGsDq/MaHF7TMz2UbVcVWN8Epf1U19Y2tfyiC5MzE9Jos7bFOCVxM365C7/B/FxUDQglZmQ/ O94Hc6vECvTJ/Ybfcg4IqsEEo; Received: from [70.213.15.11] (port=1420 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1bKaeM-0001Kv-Vd for unbearable@ietf.org; Tue, 05 Jul 2016 18:25:11 -0600 To: IETF Tokbind WG From: =JeffH Message-ID: <577C4FE1.20406@KingsMountain.com> Date: Tue, 5 Jul 2016 17:25:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 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.15.11 authed with jeff.hodges+kingsmountain.com} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-Source-IP: 70.213.15.11 X-Exim-ID: 1bKaeM-0001Kv-Vd X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.0.0.1]) [70.213.15.11]:1420 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] various issues addressed in nascent HTTPSTB X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 00:25:17 -0000 the present nascent HTTPSTB aka -tokbind-https-04 incorporates fixes to several issues -- you can review an HTML rendering of the in-progress spec here.. ..without waiting for it to be submitted to the IETF Internet-Drafts repository (which will happen by this coming Friday 8-Jul; there's still some open issues to address) [ the above rendering is also linked-to in the README for our github repo: ] recently fixed issues.. #44, #43, #40, #36, #35, #34, #33, #28, #27, #25, #24, #23, #21 HTH, =JeffH From nobody Thu Jul 7 12:52:07 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 CEF1412D86B; Thu, 7 Jul 2016 12:52:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707195205.23697.32438.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 12:52:05 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-04.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 19:52:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-https-04.txt Pages : 19 Date : 2016-07-07 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to TLS [RFC5246] connections. We describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [I-D.ietf-tokbind-protocol] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 13:04:19 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 B1C1212D88A; Thu, 7 Jul 2016 13:04:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707200414.23709.27533.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 13:04:14 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-03.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 20:04:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Filename : draft-ietf-tokbind-negotiation-03.txt Pages : 7 Date : 2016-07-07 Abstract: This document specifies a Transport Layer Security (TLS) [RFC5246] extension for the negotiation of Token Binding protocol [I-D.ietf-tokbind-protocol] version and key parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-negotiation-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 13:05:43 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 1AE7912D894; Thu, 7 Jul 2016 13:05:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707200541.23685.66356.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 13:05:41 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-07.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 20:05:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-07.txt Pages : 16 Date : 2016-07-07 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the TLS Token Binding identifiers are only transmitted encrypted and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 13:06:18 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C4912D613 for ; Thu, 7 Jul 2016 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVH96Ovu2Uhm for ; Thu, 7 Jul 2016 13:06:14 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 5140112D5AD for ; Thu, 7 Jul 2016 13:06:11 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n127so29070740wme.1 for ; Thu, 07 Jul 2016 13:06:11 -0700 (PDT) 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; bh=FrBZjg2T8tSE1/ZOgzHDIYpV0AJaBi1w9gNRAtgPVxc=; b=ctPxcsuuoRNcOq3yNyEJwCXGj+Xzt+VMPEMPzVktl/YbIYniCtW53nLGt7mnT6/VUk 3IOk/EccpKzNWRuYR/sTR33qC4/qWsBCCutDpfn7U5F3kC6tQ36wPH3GE3ultu6IjPIe DcvVYw8ZpzCobbm/VxFqyxD1FdAw1InSTAWtVktyjVXVGaTTvLKdCItgANqXwm8zFmrT kOCtPs8/LelqbeqempSB5r3Rb7Ol8zWz/v8KF0WoBBcgeG5OQ+XgOU18ceIXA+R6qtAH yhNQptN+5wYszb/eXx2J6rlcdT91iwJi8nuP35l6EDVUW80XIFtrsxJLDqFh9K8lV+IZ SOZg== 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; bh=FrBZjg2T8tSE1/ZOgzHDIYpV0AJaBi1w9gNRAtgPVxc=; b=YqMAp0Iomr7/TrOfvdoRH56LFpnb+5vb0KCoWVM6BohIGPwARF1JA+yFByCpfhCPOq effouKl7bVoDi4RBH8leC7Agev5P8nXwfjrZx2n4YKJaqAyLGPJR1CWLZED3I2TaEwkB J92DUMrBD9iTbF/BfxicPRAmYZ1urlWUYi6t2dwhTH22z1Y1RDcMtK8N+he1LwK0tJt6 TEKxOEkR5Hrp1mHMfqqsrIdnr5eKYhfmYMSV2fMYarBsR4nD2l/BJiDqbPNojaNvdmJ7 jXozXYEyVfAahMQaiujvv5tZbeJW4lT9s0Xjoq4EdVE+Uw+rHst8ZUOIhGppYUOSiDcF DYJQ== X-Gm-Message-State: ALyK8tJMmDAUj+fV9gi0nV6XgJ1QqVBaBhEmhZfui9rsN8irHuP/1pYsc3iCWnkwuqILxe2FB1i1R+tRhhyItFh0 X-Received: by 10.28.36.136 with SMTP id k130mr4438431wmk.4.1467921969693; Thu, 07 Jul 2016 13:06:09 -0700 (PDT) MIME-Version: 1.0 References: <577C4FE1.20406@KingsMountain.com> In-Reply-To: <577C4FE1.20406@KingsMountain.com> From: Dirk Balfanz Date: Thu, 07 Jul 2016 20:06:00 +0000 Message-ID: To: "=JeffH" , IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a1142be5a9041890537113727 Archived-At: Subject: Re: [Unbearable] various issues addressed in nascent HTTPSTB X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 20:06:16 -0000 --001a1142be5a9041890537113727 Content-Type: text/plain; charset=UTF-8 Hi there, I submitted draft-ietf-tokbind-https-04 to the IETF. I also started a -05 version in github. There are a couple of open issues left (feel free to comment or fix in github) - if we get them fixed by tomorrow mid-day, feel free to submit a -05 version - I'll be on a plane all day and won't be able to do it... Dirk. On Wed, Jul 6, 2016 at 2:25 AM =JeffH wrote: > the present nascent HTTPSTB aka -tokbind-https-04 incorporates fixes to > several issues -- you can review an HTML rendering of the in-progress > spec here.. > > < > http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Drafts/master/draft-ietf-tokbind-https-04.xml > > > > ..without waiting for it to be submitted to the IETF Internet-Drafts > repository (which will happen by this coming Friday 8-Jul; there's still > some open issues to address) > > [ the above rendering is also linked-to in the README for our github repo: > ] > > recently fixed issues.. > > #44, #43, #40, #36, #35, #34, #33, #28, #27, #25, #24, #23, #21 > > > HTH, > > =JeffH > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a1142be5a9041890537113727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

I submitted draft-ietf-tokbi= nd-https-04 to the IETF.=C2=A0I also started a -05 version in github. There= are a couple of open issues left (feel free to comment or fix in github) -= if we get them fixed by tomorrow mid-day, feel free to submit a -05 versio= n - I'll be on a plane all day and won't be able to do it...
Dirk.


On Wed, Jul 6, 2016 at 2:25 AM =3DJeffH <Jeff.Hodges@kingsmountain.com> w= rote:
the present nascent HTTPSTB a= ka -tokbind-https-04 incorporates fixes to
several issues -- you can review an HTML rendering of the in-progress
spec here..

<http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml= /ascii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Dr= afts/master/draft-ietf-tokbind-https-04.xml>

..without waiting for it to be submitted to the IETF Internet-Drafts
repository (which will happen by this coming Friday 8-Jul; there's stil= l
some open issues to address)

[ the above rendering is also linked-to in the README for our github repo:<= br> =C2=A0 =C2=A0 <https://github.com/TokenBinding/Int= ernet-Drafts> ]

recently fixed issues..

#44, #43, #40, #36, #35, #34, #33, #28, #27, #25, #24, #23, #21


HTH,

=3DJeffH

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=
--001a1142be5a9041890537113727-- From nobody Thu Jul 7 13:27:46 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 CDFC912D607; Thu, 7 Jul 2016 13:27:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707202744.23622.58424.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 13:27:44 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-05.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 20:27:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-https-05.txt Pages : 19 Date : 2016-07-07 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to TLS [RFC5246] connections. We describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [I-D.ietf-tokbind-protocol] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 13:50:20 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024D212D647 for ; Thu, 7 Jul 2016 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnSqj-YB07QR for ; Thu, 7 Jul 2016 13:50:16 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0092.outbound.protection.outlook.com [104.47.32.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449E712D630 for ; Thu, 7 Jul 2016 13:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MfvzPW1Id1279LfeUxS0WaSelsMvmRZxK6L38YcNZ9w=; b=bApeeH99pSi2yUp9+cePCFREmX2bNPRACLn5EqnM1rEZLFzNgbpzgnnKyFTf57c+ZdoE4UvO7rkB0Ex/OQ1KoT1UcBKMydDJ8fq4MgKPxXs/5o2DrqfEU9q6JhoiApaqzJiTTUkn8wzcyEU7O/p6wqNNy+rplQUZcYLkp7gLWk0= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Thu, 7 Jul 2016 20:50:15 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.020; Thu, 7 Jul 2016 20:50:14 +0000 From: Andrei Popov To: Dirk Balfanz , =JeffH , IETF Tokbind WG Thread-Topic: [Unbearable] various issues addressed in nascent HTTPSTB Thread-Index: AQHR1xzr64diOCFmqkuAOIJ0z2aYhqANZ7wAgAAGMJA= Date: Thu, 7 Jul 2016 20:50:14 +0000 Message-ID: References: <577C4FE1.20406@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 16b2b0da-938c-41e9-fdc4-08d3a6a84bf3 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2156; 6:MKOlvzERU+FCHzV4kvNTiGgNA/2+wuM9PmT+XYA7ESYf9AHHvxF2M7qcaZ3T1D7EOzc2FRQfkWw3zoa0yBTPPncZgvtVgep5Qn8aC4QZIXqqX2YZj8hnmAKUGlrh+CCEWgoZqjR4BcND36Y5CJSyBzJgD8ljB4X6/TCFBMddNjuLL9WCftMFipeipkGQlwREKytrBJYIZSrRDz0aPfaRHWl1G+CkWrx26+Hh2jM4tLVPzmYIB3SkA5uEbTDOEDRv3YfHkN38HsKzjI0TSq0e5HbJBXRY/SmVXqt36scj5lQnvj3GdBUmEZYDtbC1KEM5Q5sygB+loBSPldurzt4qlA==; 5:TP1VwhxBfXsiRYXx5oOxbbm2KH627nW302r2DrEUcwExlNRAnuge3BHIPjRr4SzHQtoWn60BU2zB/4XbEM/ETC3dO+LMAxDEDenhLfTnhIiDWrP09/pRIk3BsJbblnModG9Jilh97xHecrSkJgX/kQ==; 24:CVp3vcYjZX/mg4hySX0lhRg8z2L77vdChPqCCAbsp4hLGrFrUlYJ9GR3xmmMgw7cCB9j2Id/XtIfX6hs/62iO1tUofWjwdqIxpYHK2li5PA=; 7:fEQzR8qxqkrb17hmzLrvavjj2xeY8g1jWcXXTPTJWqa10zWoCS7rGIbrekNakZ2Mge4zKnRk4hG2Z4elJGkIl/Uzjq+u38ligwr1oiVlreEKD+5babr7CHV61YBeUJOTGOmci+ya1h2ApXPcBujNEH5SDrRbhgEuynuwPJsvSB8Th60o+7Na0VqBLYp9KLtvLm/mmqVJbM0KnCkwXUcexkwoMpSxfGhU/V7V7wZzJ79sms9GPQdhAJXuPdC2UW+1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(275740015457677)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2156; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2156; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(24454002)(52044002)(189002)(68736007)(5005710100001)(107886002)(97736004)(19300405004)(5001770100001)(3660700001)(8990500004)(2906002)(19625215002)(7846002)(7736002)(189998001)(16236675004)(92566002)(77096005)(10400500002)(3280700002)(19580405001)(8676002)(81166006)(33656002)(7906003)(81156014)(87936001)(10290500002)(5003600100003)(7696003)(5002640100001)(86362001)(76576001)(101416001)(790700001)(76176999)(54356999)(2900100001)(10090500001)(50986999)(74316002)(99286002)(86612001)(6116002)(102836003)(586003)(19580395003)(2950100001)(122556002)(9686002)(106116001)(15975445007)(106356001)(105586002)(19617315012)(19609705001)(8936002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2156; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155A1D3B0B9EF2C5A1AADD98C3B0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 20:50:14.7379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2156 Archived-At: Subject: Re: [Unbearable] various issues addressed in nascent HTTPSTB X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 20:50:19 -0000 --_000_CY1PR03MB2155A1D3B0B9EF2C5A1AADD98C3B0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VEJORUdPLTAzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQt bmVnb3RpYXRpb24tMDM+LCBUQlBST1RPLTA3PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMDc+IGFuZCBIVFRQU1RCLTA1PGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDU+IGhhdmUgYmVlbiBz dWJtaXR0ZWQgdG8gYWRkcmVzcyBpc3N1ZXMgIzQxIChtb3ZlIFRCIGtleSBwYXJhbWV0ZXJzIHJl Z2lzdHJhdGlvbiBmcm9tIFRCTkVHTyB0byBUQlBST1RPKSBhbmQgIzQ4ICh0cmVhdGluZyBUb2tl biBCaW5kaW5nIElEIGFzIGFuIG9wYXF1ZSBieXRlIHNlcXVlbmNlKS4NCg0KUGxlYXNlIHJldmll dyB0aGUgdXBkYXRlZCBJLURzIGFuZCBjb21tZW50IG9uIHRoZSBmZXcgcmVtYWluaW5nIG9wZW4g R2l0SHViIGlzc3VlcyBpZiB5b3UgZmVlbCB0aGF0IHRoZXkgbmVlZCB0byBiZSBhZGRyZXNzZWQu DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaXJrIEJhbGZhbnoNClNlbnQ6IFRo dXJzZGF5LCBKdWx5IDcsIDIwMTYgMTowNiBQTQ0KVG86ID1KZWZmSCA8SmVmZi5Ib2RnZXNAa2lu Z3Ntb3VudGFpbi5jb20+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIHZhcmlvdXMgaXNzdWVzIGFkZHJlc3NlZCBpbiBuYXNj ZW50IEhUVFBTVEINCg0KSGkgdGhlcmUsDQoNCkkgc3VibWl0dGVkIGRyYWZ0LWlldGYtdG9rYmlu ZC1odHRwcy0wNCB0byB0aGUgSUVURi4gSSBhbHNvIHN0YXJ0ZWQgYSAtMDUgdmVyc2lvbiBpbiBn aXRodWIuIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBvcGVuIGlzc3VlcyBsZWZ0IChmZWVsIGZyZWUg dG8gY29tbWVudCBvciBmaXggaW4gZ2l0aHViKSAtIGlmIHdlIGdldCB0aGVtIGZpeGVkIGJ5IHRv bW9ycm93IG1pZC1kYXksIGZlZWwgZnJlZSB0byBzdWJtaXQgYSAtMDUgdmVyc2lvbiAtIEknbGwg YmUgb24gYSBwbGFuZSBhbGwgZGF5IGFuZCB3b24ndCBiZSBhYmxlIHRvIGRvIGl0Li4uDQoNCkRp cmsuDQoNCg0KT24gV2VkLCBKdWwgNiwgMjAxNiBhdCAyOjI1IEFNID1KZWZmSCA8SmVmZi5Ib2Rn ZXNAa2luZ3Ntb3VudGFpbi5jb208bWFpbHRvOkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29t Pj4gd3JvdGU6DQp0aGUgcHJlc2VudCBuYXNjZW50IEhUVFBTVEIgYWthIC10b2tiaW5kLWh0dHBz LTA0IGluY29ycG9yYXRlcyBmaXhlcyB0bw0Kc2V2ZXJhbCBpc3N1ZXMgLS0geW91IGNhbiByZXZp ZXcgYW4gSFRNTCByZW5kZXJpbmcgb2YgdGhlIGluLXByb2dyZXNzDQpzcGVjIGhlcmUuLg0KDQo8 aHR0cDovL3htbDJyZmMuaWV0Zi5vcmcvY2dpLWJpbi94bWwycmZjLmNnaT9tb2RlQXNGb3JtYXQ9 aHRtbC9hc2NpaSZ1cmw9aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL1Rva2VuQmlu ZGluZy9JbnRlcm5ldC1EcmFmdHMvbWFzdGVyL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNC54 bWw+DQoNCi4ud2l0aG91dCB3YWl0aW5nIGZvciBpdCB0byBiZSBzdWJtaXR0ZWQgdG8gdGhlIElF VEYgSW50ZXJuZXQtRHJhZnRzDQpyZXBvc2l0b3J5ICh3aGljaCB3aWxsIGhhcHBlbiBieSB0aGlz IGNvbWluZyBGcmlkYXkgOC1KdWw7IHRoZXJlJ3Mgc3RpbGwNCnNvbWUgb3BlbiBpc3N1ZXMgdG8g YWRkcmVzcykNCg0KWyB0aGUgYWJvdmUgcmVuZGVyaW5nIGlzIGFsc28gbGlua2VkLXRvIGluIHRo ZSBSRUFETUUgZm9yIG91ciBnaXRodWIgcmVwbzoNCiAgICA8aHR0cHM6Ly9naXRodWIuY29tL1Rv a2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHM+IF0NCg0KcmVjZW50bHkgZml4ZWQgaXNzdWVzLi4N Cg0KIzQ0LCAjNDMsICM0MCwgIzM2LCAjMzUsICMzNCwgIzMzLCAjMjgsICMyNywgIzI1LCAjMjQs ICMyMywgIzIxDQoNCg0KSFRILA0KDQo9SmVmZkgNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJh YmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo= --_000_CY1PR03MB2155A1D3B0B9EF2C5A1AADD98C3B0CY1PR03MB2155namp_ 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 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uLTAzIj5UQk5FR08tMDM8L2E+LA0KPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNyI+ VEJQUk9UTy0wNzwvYT4gYW5kDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTA1Ij5IVFRQU1RCLTA1PC9hPiBoYXZlIGJlZW4gc3Vi bWl0dGVkIHRvIGFkZHJlc3MgaXNzdWVzICM0MSAobW92ZSBUQiBrZXkgcGFyYW1ldGVycyByZWdp c3RyYXRpb24gZnJvbSBUQk5FR08gdG8gVEJQUk9UTykgYW5kICM0OCAodHJlYXRpbmcgVG9rZW4g QmluZGluZyBJRCBhcyBhbiBvcGFxdWUgYnl0ZSBzZXF1ZW5jZSkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBs ZWFzZSByZXZpZXcgdGhlIHVwZGF0ZWQgSS1EcyBhbmQgY29tbWVudCBvbiB0aGUgZmV3IHJlbWFp bmluZyBvcGVuIEdpdEh1YiBpc3N1ZXMgaWYgeW91IGZlZWwgdGhhdCB0aGV5IG5lZWQgdG8gYmUg YWRkcmVzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJlaTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFy YWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+RGlyayBCYWxmYW56PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDcsIDIw MTYgMTowNiBQTTxicj4NCjxiPlRvOjwvYj4gPUplZmZIICZsdDtKZWZmLkhvZGdlc0BraW5nc21v dW50YWluLmNvbSZndDs7IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSB2YXJpb3VzIGlzc3VlcyBh ZGRyZXNzZWQgaW4gbmFzY2VudCBIVFRQU1RCPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgdGhlcmUsJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgc3VibWl0dGVkIGRyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNCB0byB0aGUgSUVU Ri4mbmJzcDtJIGFsc28gc3RhcnRlZCBhIC0wNSB2ZXJzaW9uIGluIGdpdGh1Yi4gVGhlcmUgYXJl IGEgY291cGxlIG9mIG9wZW4gaXNzdWVzIGxlZnQgKGZlZWwgZnJlZSB0byBjb21tZW50IG9yIGZp eCBpbiBnaXRodWIpIC0gaWYgd2UgZ2V0IHRoZW0gZml4ZWQgYnkgdG9tb3Jyb3cgbWlkLWRheSwg ZmVlbCBmcmVlIHRvIHN1Ym1pdA0KIGEgLTA1IHZlcnNpb24gLSBJJ2xsIGJlIG9uIGEgcGxhbmUg YWxsIGRheSBhbmQgd29uJ3QgYmUgYWJsZSB0byBkbyBpdC4uLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlyay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCA2LCAyMDE2IGF0IDI6 MjUgQU0gPUplZmZIICZsdDs8YSBocmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFp bi5jb20iPkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUg cHJlc2VudCBuYXNjZW50IEhUVFBTVEIgYWthIC10b2tiaW5kLWh0dHBzLTA0IGluY29ycG9yYXRl cyBmaXhlcyB0bzxicj4NCnNldmVyYWwgaXNzdWVzIC0tIHlvdSBjYW4gcmV2aWV3IGFuIEhUTUwg cmVuZGVyaW5nIG9mIHRoZSBpbi1wcm9ncmVzczxicj4NCnNwZWMgaGVyZS4uPGJyPg0KPGJyPg0K Jmx0OzxhIGhyZWY9Imh0dHA6Ly94bWwycmZjLmlldGYub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2k/ bW9kZUFzRm9ybWF0PWh0bWwvYXNjaWkmYW1wO3VybD1odHRwczovL3Jhdy5naXRodWJ1c2VyY29u dGVudC5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9tYXN0ZXIvZHJhZnQtaWV0Zi10 b2tiaW5kLWh0dHBzLTA0LnhtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly94bWwycmZjLmlldGYu b3JnL2NnaS1iaW4veG1sMnJmYy5jZ2k/bW9kZUFzRm9ybWF0PWh0bWwvYXNjaWkmYW1wO3VybD1o dHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURy YWZ0cy9tYXN0ZXIvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTA0LnhtbDwvYT4mZ3Q7PGJyPg0K PGJyPg0KLi53aXRob3V0IHdhaXRpbmcgZm9yIGl0IHRvIGJlIHN1Ym1pdHRlZCB0byB0aGUgSUVU RiBJbnRlcm5ldC1EcmFmdHM8YnI+DQpyZXBvc2l0b3J5ICh3aGljaCB3aWxsIGhhcHBlbiBieSB0 aGlzIGNvbWluZyBGcmlkYXkgOC1KdWw7IHRoZXJlJ3Mgc3RpbGw8YnI+DQpzb21lIG9wZW4gaXNz dWVzIHRvIGFkZHJlc3MpPGJyPg0KPGJyPg0KWyB0aGUgYWJvdmUgcmVuZGVyaW5nIGlzIGFsc28g bGlua2VkLXRvIGluIHRoZSBSRUFETUUgZm9yIG91ciBnaXRodWIgcmVwbzo8YnI+DQombmJzcDsg Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVy bmV0LURyYWZ0cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRp bmcvSW50ZXJuZXQtRHJhZnRzPC9hPiZndDsgXTxicj4NCjxicj4NCnJlY2VudGx5IGZpeGVkIGlz c3Vlcy4uPGJyPg0KPGJyPg0KIzQ0LCAjNDMsICM0MCwgIzM2LCAjMzUsICMzNCwgIzMzLCAjMjgs ICMyNywgIzI1LCAjMjQsICMyMywgIzIxPGJyPg0KPGJyPg0KPGJyPg0KSFRILDxicj4NCjxicj4N Cj1KZWZmSDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2155A1D3B0B9EF2C5A1AADD98C3B0CY1PR03MB2155namp_-- From nobody Fri Jul 8 10:22:37 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563C0127058 for ; Fri, 8 Jul 2016 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghunHJqTclyz for ; Fri, 8 Jul 2016 10:22:31 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 5CDD312D0BF for ; Fri, 8 Jul 2016 10:22:31 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1467998550; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=lZ/hnfVfkN+s2YRcqvWn7g29QzpJ1bAZyt72I6CCn3I=; b=lOJZodDG1oqlKX11SKVx8xv4AlbnLmE0qmmUmhFc7X1ARFslfcwMMC4Sz77dFYw1dg+U8Y+F vikxarIpxnJ4Lb3UTmq0Z0885Vr5dNEYmBJs0b64Ledn0wzo2h2A6Y4aDb/D3eeRfal51YFX 8sjjAq+1VxLGqeJaDdNMipXpA5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=qi6ae1vrOIT/uBBgHRzHtpqFEijbDFG36eBvhvgFjHLYHYc1gQZ8P49ZctXmw63Sg3jojK L9abCI/uxOH6NzIVJEw2VC9ZVSEw3AVksNfH71cj6PAtHq8Vj24yGHqEKJcGXDkJc/UOn3h1 ITwR87GB2wmx/hTQsl9YB+kjalFZI= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.46]) by mxa.mailgun.org with ESMTP id 577fe154.7f4b56d31060-in6; Fri, 08 Jul 2016 17:22:28 -0000 (UTC) Date: Fri, 08 Jul 2016 10:22:28 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <577fe154702f7_4dad3fa82e1892bc27878c@hookshot-fe4-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_577fe1546f7c2_4dad3fa82e1892bc2786f7"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 27c29c: Starting v5 of HTTPSTB X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 08 Jul 2016 17:22:33 -0000 ----==_mimepart_577fe1546f7c2_4dad3fa82e1892bc2786f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 27c29cc5df38afbd46a333056f7e16a6b3b46c17 https://github.com/TokenBinding/Internet-Drafts/commit/27c29cc5df38afbd46a333056f7e16a6b3b46c17 Author: Andrei Popov Date: 2016-07-07 (Thu, 07 Jul 2016) Changed paths: M README.md R draft-ietf-tokbind-https-04.xml A draft-ietf-tokbind-https-05.xml Log Message: ----------- Starting v5 of HTTPSTB Commit: c4125ac7daf73aa03b5c9120dacd3bb54ac93a9d https://github.com/TokenBinding/Internet-Drafts/commit/c4125ac7daf73aa03b5c9120dacd3bb54ac93a9d Author: Andrei Popov Date: 2016-07-07 (Thu, 07 Jul 2016) Log Message: ----------- Merge branch 'master' of https://github.com/TokenBinding/Internet-Drafts Compare: https://github.com/TokenBinding/Internet-Drafts/compare/5c48d3b544db...c4125ac7daf7 ----==_mimepart_577fe1546f7c2_4dad3fa82e1892bc2786f7-- From nobody Fri Jul 8 14:20:45 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2413F12D8A6 for ; Fri, 8 Jul 2016 14:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNMqiYTZDP6Z for ; Fri, 8 Jul 2016 14:20:42 -0700 (PDT) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (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 9062E12D8A0 for ; Fri, 8 Jul 2016 14:20:15 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1468012814; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=S6m9zhwbaanHbTFeyB/JA7IpEheYk53qy04oO/m/aKM=; b=ZluwWA/Q5Pbc/OVZtC6bsz7aU//H6OaELypLRpie5D5Ylpt03FzUMDk8W3s1+jbsOFZF7BXc YDYYa+acp1Shm/IFGkA2e9qht7y4Ag2a9mLjj5HyPhQ/lH6YKjN83zv8f2ijFvRcxhIi0qbo 8idRe9UIjtykHOO9CN183RnMQ10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=nNGC95mPGj6Jt1A8o0ADb5iTfBzxGMjp03eiWt/+jQjIO/sidF7tXFEWLamGYk81RF3ARz S0HViGTeLat342ROw6XxgZWBu/qRSFGgfdCalDHtacGL0po5zEWxC2bBI1m4atrMBwLkPZZ0 aTwzFPYnotmQTBiYvLtxwhT2QJsv4= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 5780190d.7f1d9e6b0c90-in06; Fri, 08 Jul 2016 21:20:13 -0000 (UTC) Date: Fri, 08 Jul 2016 14:20:13 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <5780190dd610b_78053fa71460129c1921d4@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5780190dd5cdc_78053fa71460129c1920c6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 5b958b: Starting v8 of TBPROTO X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 08 Jul 2016 21:20:45 -0000 ----==_mimepart_5780190dd5cdc_78053fa71460129c1920c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 5b958ba16e94bb543d516c29ced43c7a3556a364 https://github.com/TokenBinding/Internet-Drafts/commit/5b958ba16e94bb543d516c29ced43c7a3556a364 Author: JeffH Date: 2016-07-08 (Fri, 08 Jul 2016) Changed paths: M README.md R draft-ietf-tokbind-protocol-07.xml A draft-ietf-tokbind-protocol-08.xml Log Message: ----------- Starting v8 of TBPROTO Commit: 3cfa034f7d4a3a84e26450874cd8fa0d837d692c https://github.com/TokenBinding/Internet-Drafts/commit/3cfa034f7d4a3a84e26450874cd8fa0d837d692c Author: JeffH Date: 2016-07-08 (Fri, 08 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-08.xml Log Message: ----------- editorial cleanups, prep to address #22 Commit: 639fe3b7028fff132d9306d15aab4ca91e2ab9a2 https://github.com/TokenBinding/Internet-Drafts/commit/639fe3b7028fff132d9306d15aab4ca91e2ab9a2 Author: JeffH Date: 2016-07-08 (Fri, 08 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-08.xml Log Message: ----------- fixes #22 Commit: d8b83a4fa765b70a855dc646cd96643921984a48 https://github.com/TokenBinding/Internet-Drafts/commit/d8b83a4fa765b70a855dc646cd96643921984a48 Author: Andrei Popov Date: 2016-07-08 (Fri, 08 Jul 2016) Changed paths: M README.md R draft-ietf-tokbind-protocol-07.xml A draft-ietf-tokbind-protocol-08.xml Log Message: ----------- Merge branch 'equalsJeffH-TBPROTO-#22-ClientSideBind' Commit: 2470035e4427e35fb5f6f65141a4acf187e2f2aa https://github.com/TokenBinding/Internet-Drafts/commit/2470035e4427e35fb5f6f65141a4acf187e2f2aa Author: Andrei Popov Date: 2016-07-08 (Fri, 08 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-08.xml Log Message: ----------- Merging PR 52 Compare: https://github.com/TokenBinding/Internet-Drafts/compare/c4125ac7daf7...2470035e4427 ----==_mimepart_5780190dd5cdc_78053fa71460129c1920c6-- From nobody Fri Jul 8 14:42:41 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF1112D921 for ; Fri, 8 Jul 2016 14:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY18qTPs6UAo for ; Fri, 8 Jul 2016 14:42:37 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 B67D112D0E8 for ; Fri, 8 Jul 2016 14:42:33 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1468014153; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=P85ykLpJh16rTp4N5GKK39Y1bfJotyO6SCyyvLjUrbY=; b=wT/V0WhVA75wdwqDddc1AriptFpYmgXLMpnUBKVYAzeriiSYaI5BMYalx0M40s3s43Z/GROA 2NzrulIbavKoDQ53YpY7tXtykzsUQdSJ0nmm/qIZUUXp9X0yfo5zA26cb2fI1kj93pds6Yvw yRx2zGBtNf/jzBUwy5ojJ0ZVkzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=bTQzZvIDDMhslHVoVntkM4yIMBV+0xTkmI9y5zHSAG+xb4V1FWLLJLfvrvh9Ne4ALlaTG2 8+lYGSj7yH3PP85V46z8OUEtRjVuymloXjxCzARrWJT34ZY2VTgbUeRQoh7uNjsxlYoeyiam ZrHYkfErtgMehvra4hzw3zmJ0ccN0= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.40]) by mxa.mailgun.org with ESMTP id 57801e47.7faa6c091540-in07; Fri, 08 Jul 2016 21:42:31 -0000 (UTC) Date: Fri, 08 Jul 2016 14:42:31 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57801e47b8c5f_79783fc4226a52b8277325@hookshot-fe6-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57801e47b885d_79783fc4226a52b8277288"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 747c8f: Harminized terminology to address issues ## 50, 51... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 08 Jul 2016 21:42:38 -0000 ----==_mimepart_57801e47b885d_79783fc4226a52b8277288 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 747c8fed3bdf3f8f895e1222bd6443330f74bbf8 https://github.com/TokenBinding/Internet-Drafts/commit/747c8fed3bdf3f8f895e1222bd6443330f74bbf8 Author: Andrei Popov Date: 2016-07-08 (Fri, 08 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-08.xml Log Message: ----------- Harminized terminology to address issues ## 50, 51. ----==_mimepart_57801e47b885d_79783fc4226a52b8277288-- From nobody Fri Jul 8 14:47:05 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 6631312D960; Fri, 8 Jul 2016 14:47:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708214704.32071.28686.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:47:04 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-08.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 21:47:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-08.txt Pages : 16 Date : 2016-07-08 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only transmitted encrypted and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 14 09:18:09 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6012D0E9 for ; Thu, 14 Jul 2016 09:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DLf5hkhu7HT for ; Thu, 14 Jul 2016 09:18:07 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 3669912D0AD for ; Thu, 14 Jul 2016 09:18:07 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id w127so59766011vkh.2 for ; Thu, 14 Jul 2016 09:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=zzAq1Kj4ORObiSVd3WOWGG/yPT0L8hnjJlVbVX3aJdk=; b=N4klsgzPLa4mgBKaspSzHIrr9bDZ+RKeoRta7Y7VnQuSf0kBhsV4MCmtZhuMJdLzP8 PYNLpliJ6R0OFsdpOrGhtcOW52696U5W6l/wtCEYWKpo+iv6/bn0T3fHB6iOL4cJ70JQ v2sRQj4MVlAKbFqU4V6zyNDz1aAgsfp1j5h6sR3qW/jxWg4II1VH4A9wTcJYnV1RE26/ Tyfu3Wkvo71UvCcUVKDzLsmdX8A/SyJ65PRQl6dDN8Int/CRBb47YFH8T1KsWCYJoozo L0vcipNw1mjPNnj3EXHaWW4osbd2i0H77ISWOJtZ+1lCwiVHRo0Mqyq5oR3TWYNQpGxO nJug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zzAq1Kj4ORObiSVd3WOWGG/yPT0L8hnjJlVbVX3aJdk=; b=NVZsnyflhXvbaokqjY6kJS80HF0tQ/oMhDXa+Bm4UauyCENl5UtFB/0Mh+hxBDmu7u y9v0bbV3LY7ISJ949H8tgEipPFJYQx967IAkk54KKWrofqRDw0TuZHuuYEoarZ5N0/E9 8wbsYJIpA3o06bw7MFD+cOb0TzeNzvop1Q91AJs690cJCTWz5xKuvcvbHoBqURaOHb3u JaqTFQ7Us+YdI2btOiFxjnKagEleaEK4ZCVWlZI5kAra+iuTc+4DB1M2hIIZIkjBGtDU yJ920onipg45TnRFn3e85bXUhQu10zN001xT/q/fgglOps8Hz82bYaR2Ejsgd7SJkt7L /mdw== X-Gm-Message-State: ALyK8tKYMLSLWzBcb6qALDmgf0yNrha+VFIdQ+CqWMCYH7x8JAhvM0igiCfUMkDoB+diI6EUtlrtw//w4EQoE0Lv X-Received: by 10.31.108.12 with SMTP id h12mr6549205vkc.46.1468513086098; Thu, 14 Jul 2016 09:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.83.194 with HTTP; Thu, 14 Jul 2016 09:18:05 -0700 (PDT) From: Bill Cox Date: Thu, 14 Jul 2016 09:18:05 -0700 Message-ID: To: Tokbind WG Content-Type: multipart/alternative; boundary=001a114783b2d89fe005379ad85f Archived-At: Subject: [Unbearable] Do we strip leading 0's on modulus and exponent? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:18:08 -0000 --001a114783b2d89fe005379ad85f Content-Type: text/plain; charset=UTF-8 I'm just finishing converting to the new custom token-binding format (which was fairly painful). One think I would like to see is that there is one unique encoding for any given key or signature. I think we succeeded in this for ECDSA-P256, and for RSA signatures (which are 32 bytes long always), but it is not clear to me from the spec whether or not to strip leading 0's on the RSA modulus and exponent in RSA keys. My guess is that yes, we need to strip them, so that there is only one unique way to represent an RSA key. Is this right? Either way, I think we should specify this in the spec. Thanks, Bill --001a114783b2d89fe005379ad85f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm just finishing converting to the new custom token-= binding format (which was fairly painful).=C2=A0 One think I would like to = see is that there is one unique encoding for any given key or signature.=C2= =A0 I think we succeeded in this for ECDSA-P256, and for RSA signatures (wh= ich are 32 bytes long always), but it is not clear to me from the spec whet= her or not to strip leading 0's on the RSA modulus and exponent in RSA = keys.=C2=A0 My guess is that yes, we need to strip them, so that there is o= nly one unique way to represent an RSA key.=C2=A0 Is this right?=C2=A0 Eith= er way, I think we should specify this in the spec.

Than= ks,
Bill
--001a114783b2d89fe005379ad85f-- From nobody Thu Jul 14 14:51:33 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB7112D858 for ; Thu, 14 Jul 2016 14:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4b0_Uhw7B83 for ; Thu, 14 Jul 2016 14:51:28 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0123.outbound.protection.outlook.com [104.47.40.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D62112D86D for ; Thu, 14 Jul 2016 14:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nDdo371+qJd7aao2/UWyW55ZJbeX0kzUuA9uX1IcZ2U=; b=JG/sJFSHjDFpGxTGX9eiAaEQUFzbUQm4xlOMaOXTspxKmzQyH7wSXs2DGhHpVGT3Sfbmw7CmQbTrvAQjZCincP0wLJjjZdCurgFSn7bYYUqyo4KUQgKAqT/epGtPHtffW80Ud0MHNA8gYiTAvZv4Cx4/EvwmYZnVtAqYtOJHLNw= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Thu, 14 Jul 2016 21:51:18 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.023; Thu, 14 Jul 2016 21:51:18 +0000 From: Andrei Popov To: Bill Cox , Tokbind WG Thread-Topic: [Unbearable] Do we strip leading 0's on modulus and exponent? Thread-Index: AQHR3etSpXwXfXFy1kqOrdqT2UT3P6AYdZ+Q Date: Thu, 14 Jul 2016 21:51:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:e::1d2] x-ms-office365-filtering-correlation-id: de0a805a-9428-4846-9d8d-08d3ac30fc54 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:bnQZsH/TaoWjFJliFpKYYuQZcdBdQTnZds1+yeIxLouR7jqWBWWQhdobEHf6Q5LeladFUvXXgoBBbDEIi/gC1oGLN8lje3qcj3UNBpp9SrI666ylSnBf1uFGn5ln1omvdeytS8uU4A2LutyuKqP7L0pItDJanvQz1YRomnhqN5ekgRwS8LKLieNXc7m50BME1cuZgvI/96ix5tBALtF2/5zQmq/CcD4LiOP26x3bKPM+nYAkJ2RzB6X47WlJ7JVUb7WslAywLWShUREl0xAmqE5CJyeWyFOSt1YCc69Mk5C2N9kF9ml1C4OzLATgFd2cBelWJM0GAbI0BqjSOmaYKQ==; 5:13yX8ZESAktH6ZcD2jXlSm0RWYN2XXaS1NvfoRQJziZrl4yjTcHqlEojmuOZvFBrdiFF6oQONaheOUvTq4YLUImzKI4ug8YEbzAxM8X7+52sPzAkGjidSjt/+nLOBvdnhbuJWvzlBhcgVLbmUtKKEvNTYmXot3au4sWMJU8TPwo=; 24:JH7Qgd5CTUIHoVllUcZFZaPx4dM50cxSyNMY9lZTfzXSp5UeXHGxR921nY/HXYe3gcsMFhUn7s7Ve9nLB+ctSUf36H6CEaAEom6sVgFztH8=; 7:mvUooc5hALF9bzM1P2vhAGl5E99e/MwiZ73V+GrbV53FL8YRHVxga8TBrTS6vOS4tZuC3ho6go/i03hX2DpU50qXxywHuziSWNJPfL6SLOd6jjO42OygIPN8pZUT7i5yOUeoLAtNcOuNAhPvoNwZJaHeyHKb4Xk88laCi+SeoMoNiyBy35KLRVmylrUSR/OQABzuhdXOFR46TaFecsGdTt00I3AJ4RwfEiohaahak4hwtOi+h9vg8Ef48VG+SwvU x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:(304825044); SRVR:CY1PR03MB2154; x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(8936002)(122556002)(5002640100001)(16236675004)(74316002)(3280700002)(7696003)(11100500001)(68736007)(50986999)(102836003)(6116002)(19300405004)(790700001)(76176999)(15975445007)(189998001)(86362001)(10290500002)(107886002)(9686002)(87936001)(86612001)(19580395003)(19580405001)(19625215002)(10090500001)(8676002)(105586002)(33656002)(92566002)(101416001)(5001770100001)(106356001)(7846002)(2906002)(5003600100003)(10400500002)(99286002)(8990500004)(97736004)(586003)(81166006)(7736002)(106116001)(3660700001)(2900100001)(54356999)(2950100001)(5005710100001)(77096005)(76576001)(81156014)(58070200004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB215517C1C3F2966D4447427F8C320CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2016 21:51:17.9271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Subject: Re: [Unbearable] Do we strip leading 0's on modulus and exponent? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 21:51:31 -0000 --_000_CY1PR03MB215517C1C3F2966D4447427F8C320CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbGVhbmluZyB0b3dhcmRzIGhhdmluZyBhIFRCIGltcGxlbWVudGF0aW9uIGFjY2VwdCB0 aGUgMC1wYWRkaW5nLCBpZiBwcm92aWRlZCBieSB0aGUgcGVlci4gQ3J5cHRvIGxpYnJhcmllcyBk aWZmZXIgaW4gaG93IHRoZXkgcmVwcmVzZW50IFJTQSBrZXlzLCBhbmQgaWYgc3RyaXBwaW5nIHRo ZSB6ZXJvcyByZXN1bHRzIGluIGFkZGl0aW9uYWwgbWVtb3J5IGNvcGllcywgSeKAmWQgcmF0aGVy IGF2b2lkIHRoYXQuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21h aWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCaWxsIENveA0K U2VudDogVGh1cnNkYXksIEp1bHkgMTQsIDIwMTYgOToxOCBBTQ0KVG86IFRva2JpbmQgV0cgPHVu YmVhcmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gRG8gd2Ugc3RyaXAgbGVh ZGluZyAwJ3Mgb24gbW9kdWx1cyBhbmQgZXhwb25lbnQ/DQoNCkknbSBqdXN0IGZpbmlzaGluZyBj b252ZXJ0aW5nIHRvIHRoZSBuZXcgY3VzdG9tIHRva2VuLWJpbmRpbmcgZm9ybWF0ICh3aGljaCB3 YXMgZmFpcmx5IHBhaW5mdWwpLiAgT25lIHRoaW5rIEkgd291bGQgbGlrZSB0byBzZWUgaXMgdGhh dCB0aGVyZSBpcyBvbmUgdW5pcXVlIGVuY29kaW5nIGZvciBhbnkgZ2l2ZW4ga2V5IG9yIHNpZ25h dHVyZS4gIEkgdGhpbmsgd2Ugc3VjY2VlZGVkIGluIHRoaXMgZm9yIEVDRFNBLVAyNTYsIGFuZCBm b3IgUlNBIHNpZ25hdHVyZXMgKHdoaWNoIGFyZSAzMiBieXRlcyBsb25nIGFsd2F5cyksIGJ1dCBp dCBpcyBub3QgY2xlYXIgdG8gbWUgZnJvbSB0aGUgc3BlYyB3aGV0aGVyIG9yIG5vdCB0byBzdHJp cCBsZWFkaW5nIDAncyBvbiB0aGUgUlNBIG1vZHVsdXMgYW5kIGV4cG9uZW50IGluIFJTQSBrZXlz LiAgTXkgZ3Vlc3MgaXMgdGhhdCB5ZXMsIHdlIG5lZWQgdG8gc3RyaXAgdGhlbSwgc28gdGhhdCB0 aGVyZSBpcyBvbmx5IG9uZSB1bmlxdWUgd2F5IHRvIHJlcHJlc2VudCBhbiBSU0Ega2V5LiAgSXMg dGhpcyByaWdodD8gIEVpdGhlciB3YXksIEkgdGhpbmsgd2Ugc2hvdWxkIHNwZWNpZnkgdGhpcyBp biB0aGUgc3BlYy4NCg0KVGhhbmtzLA0KQmlsbA0K --_000_CY1PR03MB215517C1C3F2966D4447427F8C320CY1PR03MB2155namp_ 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 b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SeKAmW0gbGVhbmluZyB0b3dhcmRzIGhhdmlu ZyBhIFRCIGltcGxlbWVudGF0aW9uIGFjY2VwdCB0aGUgMC1wYWRkaW5nLCBpZiBwcm92aWRlZCBi eSB0aGUgcGVlci4gQ3J5cHRvIGxpYnJhcmllcyBkaWZmZXIgaW4gaG93IHRoZXkgcmVwcmVzZW50 IFJTQSBrZXlzLCBhbmQgaWYgc3RyaXBwaW5nIHRoZSB6ZXJvcw0KIHJlc3VsdHMgaW4gYWRkaXRp b25hbCBtZW1vcnkgY29waWVzLCBJ4oCZZCByYXRoZXIgYXZvaWQgdGhhdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxl LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJpbGwgQ294PGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDE0LCAyMDE2IDk6MTggQU08YnI+DQo8Yj5Ubzo8L2I+ IFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtVbmJlYXJhYmxlXSBEbyB3ZSBzdHJpcCBsZWFkaW5nIDAncyBvbiBtb2R1bHVzIGFuZCBl eHBvbmVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20ganVzdCBm aW5pc2hpbmcgY29udmVydGluZyB0byB0aGUgbmV3IGN1c3RvbSB0b2tlbi1iaW5kaW5nIGZvcm1h dCAod2hpY2ggd2FzIGZhaXJseSBwYWluZnVsKS4mbmJzcDsgT25lIHRoaW5rIEkgd291bGQgbGlr ZSB0byBzZWUgaXMgdGhhdCB0aGVyZSBpcyBvbmUgdW5pcXVlIGVuY29kaW5nIGZvciBhbnkgZ2l2 ZW4ga2V5IG9yIHNpZ25hdHVyZS4mbmJzcDsgSSB0aGluayB3ZSBzdWNjZWVkZWQgaW4gdGhpcyBm b3IgRUNEU0EtUDI1NiwNCiBhbmQgZm9yIFJTQSBzaWduYXR1cmVzICh3aGljaCBhcmUgMzIgYnl0 ZXMgbG9uZyBhbHdheXMpLCBidXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIGZyb20gdGhlIHNwZWMg d2hldGhlciBvciBub3QgdG8gc3RyaXAgbGVhZGluZyAwJ3Mgb24gdGhlIFJTQSBtb2R1bHVzIGFu ZCBleHBvbmVudCBpbiBSU0Ega2V5cy4mbmJzcDsgTXkgZ3Vlc3MgaXMgdGhhdCB5ZXMsIHdlIG5l ZWQgdG8gc3RyaXAgdGhlbSwgc28gdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSB1bmlxdWUNCiB3YXkg dG8gcmVwcmVzZW50IGFuIFJTQSBrZXkuJm5ic3A7IElzIHRoaXMgcmlnaHQ/Jm5ic3A7IEVpdGhl ciB3YXksIEkgdGhpbmsgd2Ugc2hvdWxkIHNwZWNpZnkgdGhpcyBpbiB0aGUgc3BlYy48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8YnI+DQpCaWxs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CY1PR03MB215517C1C3F2966D4447427F8C320CY1PR03MB2155namp_-- From nobody Sun Jul 17 10:24:41 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647AD12D11A for ; Sun, 17 Jul 2016 10:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP5uq0L5POGd for ; Sun, 17 Jul 2016 10:24:37 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 C108112D0FF for ; Sun, 17 Jul 2016 10:24:37 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id w127so154948485vkh.2 for ; Sun, 17 Jul 2016 10:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=GOfq9VwLvoReGSimEgz/EEFM9FmMj4Mm5omFq5vpS/o=; b=ZQJhHFPWBW5lLppmKB+VjFFwy16UEOBu2QEl+fTrr2LAbAcOikhQ950raSUhGVWQcJ Vf4DbSqEQIy1KuX3xEFZdzOAWaBDVS7cHN3hVg2j+2hQl+KbNa8L1erYgFWnMkXmoXyF J1l0tV26Jl4Kx4QgDAEuMcbr5zL+nbvfQTuei9bk1CNerX4NLujEJvvtmN5KV62d4X+F Uw6+xnieWXOzoiZlaJnJE48xsjjN0NOjHt/e67EgFjmKpJdJ7Bo6Li27udessECG7ExB s4XrcjlHOJIc6JhCRcd5xF+1BbU+AGMkkdq5C05cbQdaXPVlg7kxQFsGmP0Wigm4bCn9 I2Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GOfq9VwLvoReGSimEgz/EEFM9FmMj4Mm5omFq5vpS/o=; b=iHyNMRtKOAgXLZRe3/cMzDyk6pja/tEnH1Hq+cqItWoY6Aak/ryoA1ujGuGBBOXvnT d3ZgRUzm9ZEp1tmN44Gmv37M9Qrp0Q7NSqmTHZMP7pZA16lL+dsW2M2VBLSW0u2fHOBi FfQoMy4hoWdXNqh0ZrrJG700BwgmWNlU4+ZPmVNhEoSdOLVSL2pSRHfZ2v5/xbI2U5n0 YoukVNHNXfELwm7iX8VU52usnvY6dBmpnAvey1Ks/DGNSFKtBMVGwjkvBcWWaqm3URbQ gRdVBiS9o8q8DZrcXDOlAluRi5PevHKh5sK8bZNeLJstKqg8NIew8pbowQyfrCp5fQJU /rnw== X-Gm-Message-State: ALyK8tIlHYqGilmp8AAqHmv07aWJrMrO/WSdTST3xhhSFJ70Y2c9NIvAiaWP96xsOEQR9+i22ISK3dAns8NxExao X-Received: by 10.159.39.71 with SMTP id a65mr15840437uaa.34.1468776276601; Sun, 17 Jul 2016 10:24:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.83.194 with HTTP; Sun, 17 Jul 2016 10:24:36 -0700 (PDT) From: Bill Cox Date: Sun, 17 Jul 2016 10:24:36 -0700 Message-ID: To: Tokbind WG Content-Type: multipart/alternative; boundary=94eb2c1246ba391a7e0537d820d9 Archived-At: Subject: [Unbearable] Open-source token binding library status update X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 17:24:39 -0000 --94eb2c1246ba391a7e0537d820d9 Content-Type: text/plain; charset=UTF-8 Several people have asked about this, so I'm just giving a status update on the open-source token binding library. The library is partially through the open-sourcing process. The main holdup is that I need to rewrite it in C so that it can be used with another open-source project, and that task is big enough that I have pushed it to after rolling out initial support for token binding on Google servers, which is an involved process. If I had to guess, I'd say the ETA is maybe 4 to 6 weeks from now. Bill --94eb2c1246ba391a7e0537d820d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Several people have asked about this, so I'm just= giving a status update on the open-source token binding library.

The library is partially through the open-sourcing process.=C2= =A0 The main holdup is that I need to rewrite it in C so that it can be use= d with another open-source project, and that task is big enough that I have= pushed it to after rolling out initial support for token binding on Google= servers, which is an involved process.=C2=A0 If I had to guess, I'd sa= y the ETA is maybe 4 to 6 weeks from now.

Bill
=
--94eb2c1246ba391a7e0537d820d9-- From nobody Tue Jul 19 07:49:20 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963B312D87F for ; Tue, 19 Jul 2016 07:49:18 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz3JzGCn6wFe for ; Tue, 19 Jul 2016 07:49:15 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 3E1A912E055 for ; Tue, 19 Jul 2016 07:24:11 -0700 (PDT) Received: (qmail 11299 invoked by uid 0); 19 Jul 2016 14:24:08 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 19 Jul 2016 14:24:08 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id LeQ31t00k2UhLwi01eQ6FJ; Tue, 19 Jul 2016 08:24:06 -0600 X-Authority-Analysis: v=2.1 cv=KaJB72oD 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=cAmyUtKerLwA:10 a=48vgC7mUAAAA:8 a=FQjh2a8AAAAA:8 a=NEAV23lmAAAA:8 a=KWay_7z4eITffF70wFcA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=PuV6PcL1-KkOzm2SamYU:22 a=Bn2pgwyD2vrAyMmN8A2t:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:Subject:To:From: Message-ID:Date; bh=ejZhcEN39KvFIKPk/r+B+vL3Hx1iqyU3hrDCGubAljM=; b=v5GtGvYln ED3UgvHfrKQ0NbjPmiii/Hxj171CIe46asWRJgTBcJX+GxNqxW7va0XAF23N6iwXzPKB5ccYoTKNF btru/ZTyo7mu90dHmzHaaI+JNL940wi/LO5ED6JeIq; Received: from [127.0.0.1] (port=37388 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bPVwL-0002BM-8d for unbearable@ietf.org; Tue, 19 Jul 2016 08:24:05 -0600 Received: from 31.133.180.173 ([31.133.180.173]) by box514.bluehost.com (Horde Framework) with HTTP; Tue, 19 Jul 2016 08:24:02 -0600 Date: Tue, 19 Jul 2016 08:24:02 -0600 Message-ID: <20160719082402.Horde.OTgOzEdC032jxwU0_oRUoC8@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Tokbind WG User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bPVwL-0002BM-8d X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:37388 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] IETF-96 tokbind raw minutes X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:49:19 -0000 ########## Token Binding WG - IETF96 Berlin ============= http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-tokbind > * Note Well and Agenda Bashing (5 min) https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-2.pdf let's jump straight to presos... > * Core Documents (55 min) > - draft-ietf-tokbind-protocol-08 -- Andrei Popov https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-0.pdf > - draft-ietf-tokbind-negotiation-03 mostly all editorial changes since ietf-95 -- see slides > - draft-ietf-tokbind-https-05 -- dirk balfanz https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-4.pdf dirk gives demo using canary chrome and google frontend (at a particular endpoint which is an alpha/canary TLS frontend... https://tokbindrptest.appspot.com echo -n | base64 -D | od -Ax -tx1 Update Fetch to support Token Binding -- vinod working on this https://github.com/whatwg/fetch/pull/325 william denis: what about the 302 redirect req -- is that the only way to do things? what about other patterns? dirk(db): we need diff triggers for diff patterns, for patterns that utilize redirects, the response header field in spec is the trigger -- for other patterns, need to write other profiles and define diff patterns -- that's somthing that'll happen in other WGs -- i imagine will work with XHR like: when create XHR obj, have a flag that's 'include-referred-tb' -- in saml world, have an auto-submit form, could have a boolean attr on the page that signals inclusion of the referred TB --- wrt whatwg/w3c, once stuff in fetch, the stuff passed down from higher layer ought to Just Work -- each of these have in comman that there's an origin from which the req is made and one to which the provided and referred TBIDs are sent subodh: what about priv implications of including this referred header field? db: browsers have notions of whether to send 3d party cookies or not, if bwsr is sending out a req in which it is not ok to send 3d party cookies, it will not send TB header wseltzer: when bring this up in webappsec WG ? db: onece Anne gives ok to the PR#325 vinod: probably just weeks until done leif: can these 3 specs goto WGLC? mike jones(mj): maybe you shud ask that question again after my oauth preso, i'll raise an open issue with the core specs... john bradley(jb): hans has a version of mod_ssl that does TB -- any other impls? andrei (ap): have impl in IE & Edge (both use same http engine) subodh: have started working on impl > * Related work: Token Binding for OAUTH (30 min) > - draft-jones-oauth-token-binding-00 --- Mike JOnes https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-3.pdf see slides wrt slide 3 tony nadalin(tn): notes that if connection had gone away might get a lot of reauthns db: notes that TBID lifetime can be long and span multiple tls sessions slide 4: TB ID Tokens defined in: openid-connect-token-bound-authentication-1_0 3-party use case, this seems to work out well given the present tbind specs slide 5: representation in openid connect ID Token they put hast of TBID in ID Token -- saves bytes. an open issue of how to have crypto agility for the hash function b campbell(bc): how bout just define names for hashes algs... slide 6: Tokenbound access tokens see slides... slide 7: issue for TB access tokens this is not using redirects, cross-domain comms is by expicit connection the prob: two channesl not crypto'y bound when using the explicit param method proposed soln: req TB impls to provide APIs for clients to explicitly provide TB info to be sent as referred TB Andrei(ap): pushes back on this notion: "don't need to write any api reqs in a protocol spec" JeffH: well, rfc5929 tls channel bindings does have a section "7. Required Application Programming Interfaces" that is along these lines and serves as a reasonable precedent torsten l.: can see need for such language in the spec, and without it, eg if such api isn't made availaBLE, then TB isn't useful [ tony nadalin, dirk and andrei push back] tn: you put your api reqs into the oauth TB profile spec... mjb: well, ought to be in tb-protocol spec because there's other apps than oauth who'll want to do this johnbradly(jb): thinks such broad language is fine subodh: what does it mean to be a token binding impl -- so does this apply to whom and where and in what context? dick hardt: agree with JeffH and Mike wrt general api guidance justin richer(jabber): This is all about non-browser-based HTTP communication. You *can* do it with the current spec, but there ought to be functional guidance so non-browser apps can all do this the same way. there's no reason for OAuth to be a special snowflake here. william d: either way there's apis to add to tls stack and such guidance makes sense tony(tn): stacks are going to look at their resources to writing api, they can make decisions on their own... jb: unclear whether app on top of stack will have access to the referredTBID, if we pass it as extra param, there's sec issues maybe; if we have an agreement TB will be available to native apps, it'll be easier to developers to have access to this martin thomson(mt): what is this api ? jb: its a native api mt: why is this not simply looking at this "we have simple api, enrich it a BIT" and mike's happy? william d(wd): paramater or header need tls stack cooperation... chair: leif: can someone provide actual text -- this is only a couple lines yes? can do this during WGLC? ?: notes that if we are writing app on top of tls stack and we can't rely on there being an API providing this then life is difficult.... leif: hum on whether we need such api guidance/reqs in the spec ? result: was roughly 50/50 on support and no support for the notion leif: who believes having non-norm guidance is ok? fair hum who believes it is evil? no hum MT: hm, there's possible sec issues here if an app can tell the tls stack to send the TB to some other arbitrary host....? mjb: we're trying to secure existing app comms patterns.... MT: db: so whoever crafts this please include to not violate privacy... bc: MT is getting to convcerns wrt key scoping -- perhaps some guidance wrt scoping in APIs will be necessary... sf: not clear to me that you can craft the sec cons for the full generality of these such API guidance... leif: if we have text, we can actually dicuss more concretely leif: are these specs ready for last call? (various hands go up) lucy lynch(LL): advises that priv review occur before WGLC MT: has priv concerns with this stuff... leif: will you MT do a priv review? LL and WendyS ? u have a month approx before we go into WGLC > - draft-campbell-oauth-tbpkce-00 -- biran campbell https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-1.pdf a TB method for OAuth proof key token exchange... pronounced pixy rfc7636 final slide "what are next steps?" -- questn is more for oauth WG db: one what to think about pkce is it is assym operation, having TB protects against MITM, so yes we should bother jb: it does improve sec, perhaps gets around some impl issues am playing around with TB client IDs... subodh: does this prevent against atks in android & ios where u can register req URLs? jb: pkce does that now Kaoru Maeda: PKCE is to differenciate two apps residing on one device. TBID is associated to TLS connection, that is device to server. Since HTTP/2 requests may coalsce on a single TLS connection, context separation may not be what is desired. end From nobody Fri Jul 22 02:26:52 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2769B12DB5A for ; Fri, 22 Jul 2016 02:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.52 X-Spam-Level: X-Spam-Status: No, score=-22.52 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56iPDnlj9T8P for ; Fri, 22 Jul 2016 02:26:48 -0700 (PDT) Received: from den-ipout-01-data1.paypalcorp.com (den-ipout-01-data1.paypalcorp.com [173.224.160.153]) (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 A06F412DF23 for ; Fri, 22 Jul 2016 02:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1469179608; x=1500715608; h=from:to:subject:date:message-id:mime-version; bh=LdBaYXCgi4E7ZE8QTNWqYEA3Vfv6CTayZZYiMXMO1/g=; b=Wy7r3Xy3jjSiFRjcmwqvMTGYBaCspfS9kzdUL7jlwb9ApQ/rmvUW9pSa RKikcuLjvtuY2JrPE432+ZqBHLgYXAVhLBZXe0Vr/pZpCZKvOt2N5Ph3Y AwjBdShHUWhvrqz4oD0hCaOiMCsaUmP+4Az8KeS/7WynOR+HwTleUH+uv YC3qZqJYjDjjMrKN8Xbfib+NDCyCDnNgpqgZvZgDnW+GE9IRdvQjElDWQ loXkoffJffeuCTNIJ+TJGekz4T7acUNQmzWKpfgZis4GZqv4iKLKBrmn/ Dq32/ozc/lI/vntfIA2j0YOq33FECV5huCLP3+TOvWlJaASbIsL1AdRhs Q==; X-IronPort-AV: E=Sophos; i="5.28,404,1464674400"; d="scan'208,217"; a="18862645" Received: from unknown (HELO lvs-ipcld-02-data1.paypalcorp.com) ([10.184.246.165]) by den-ipout-01-data1.paypalcorp.com with ESMTP; 22 Jul 2016 03:26:47 -0600 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,404,1464678000"; d="scan'208,217";a="6309777" X-CloudService: Office365 Received: from mail-bn3nam01lp0176.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) ([216.32.180.176]) by lvs-ipcld-02-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 22 Jul 2016 02:26:16 -0700 Received: from SN1PR06MB2094.namprd06.prod.outlook.com (10.169.125.142) by SN1PR06MB2096.namprd06.prod.outlook.com (10.169.125.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Fri, 22 Jul 2016 09:26:43 +0000 Received: from SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) by SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) with mapi id 15.01.0539.021; Fri, 22 Jul 2016 09:26:43 +0000 From: "Hodges, Jeff" To: Tokbind WG Thread-Topic: PR#54: TBPROTO-09: address implementation/api guidance Thread-Index: AQHR4/soxpW9I2zkUEKpK8sbSC1kug== Date: Fri, 22 Jul 2016 09:26:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.176.206] x-ms-office365-filtering-correlation-id: c1296dc6-3fd0-4b9a-3605-08d3b2124ba7 x-microsoft-exchange-diagnostics: 1; SN1PR06MB2096; 6:evP2fKYPPNCC6nHdkQU+iKKyDjdc5wbFa645NCZXA+HV3TbfvnmS+tCNP8pfvAZy51PS0GOjnImzXXWt+SBpHANm0yMSNtCZhlIqslCNFkedHGmGs7n00RAg/eSRw88mHwKcaytbQ9+hQpIO8c+21jvPtiRCYhpazqZSjNkc+INBWeREwhTYhfuABIFEH6H5IOsw+ZL8EmWRb+S7gTA2chKmCcaMS+jUf56QQ9vvfVmbTH0uToBxcGOaunJv1IOMCO13/3NsuNdUUL9FqYeHscVvMY2gDK1VYSJ0BFsVlPPJSGnR5dFGtN3/cHqiumTIRvH/9MnkThXOM90Wfq12/w==; 5:RM+p6AXkl8KFPOYmb9Nr401r3GX0FPtMCWAX6zkvuKdS34qLs1zloT1L//Sew8Q38qRgtxW3qavrmg3QGBs4SNN/oU55HwUhzadejda7F71VmpxIKWF3rupRozAvFTXZk/AvBpIvwvrBvpBd70uJ7g==; 24:LMyTlgd0j7SSHcfwiBcwfesT7wkwuYDh1/kQj1zYnexZf/XEoFVO1YbsU6ANnqedQOwZRM8TM/H+ea1GhwbTtQR/DNrf9Hg6v+0mR4EAgyw=; 7:6GpF0+dLkkgL6Wc+4jpuMjrx3EUMEV4XLX/n8XKsPXFw+YYoJUGWKqUasHdIBsySea1mH/2Sj37Dvj17O+zFZVNWDwVRzsTz27yaXuPpElO/a8nLWz88ZYDH9vL2VL23bMgM78PLrXJNAYYjEcXbEm7n94iJMg2zzbqMDkMny7Frozj5I30Yw3pd8ATcqA3R8wdvfw81MTP6rYUpfy7ITpFbTXk0JSiFkJ12+50jMhv7iQqiDMSQQ6/Fp5HFzJxp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB2096; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN1PR06MB2096; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB2096; x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(10300500001)(101416001)(9686002)(10130500003)(11100500001)(10400500002)(19617315012)(77072002)(4500500003)(6116002)(102836003)(54356999)(3846002)(450100001)(66066001)(10290500002)(106116001)(68736007)(87936001)(105586002)(189998001)(99286002)(106356001)(15975445007)(229853001)(2906002)(5002640100001)(7906003)(86362001)(92566002)(122556002)(50986999)(4001350100001)(81156014)(81166006)(83506001)(8936002)(3280700002)(19580395003)(10770500004)(7736002)(110136002)(73692002)(8676002)(3660700001)(2900100001)(97736004)(82432001)(16236675004)(586003)(36756003)(7846002)(77096005)(107886002)(10630500005)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR06MB2096; H:SN1PR06MB2094.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3B734F4CD28Bjehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2016 09:26:43.5304 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB2096 X-CFilter: Scanned den1 Archived-At: Subject: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:26:50 -0000 --_000_D3B734F4CD28Bjehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike and I have crafted proposed text to resolve #53 "add TB api guidance", as we agreed to= do during the working group meeting on Tuesday. It comprises a new short= "Implementation considerations" section and an additional paragraph in the= Privacy Considerations section, addressing the request by Stephen Farrell. thoughts? thanks, HTH, =3DJeffH & Mike Jones --_000_D3B734F4CD28Bjehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7AD7D763EC8F884391269A6367F50E3C@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Mike and I have crafted proposed text to resolve #53 "add TB api guidance", as we agreed to do during the work= ing group meeting on Tuesday.   It comprises a new short "Impleme= ntation considerations" section and an additional paragraph in the Pri= vacy Considerations section, addressing the request by Stephen Farrell.

thoughts? 

thanks, HTH, 

=3DJeffH & Mike Jones


 
--_000_D3B734F4CD28Bjehodgespaypalcorpcom_-- From nobody Fri Jul 22 03:44:24 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B61712DC65 for ; Fri, 22 Jul 2016 03:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 b6JVT0lzBGOC for ; Fri, 22 Jul 2016 03:44:20 -0700 (PDT) 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 BA55812DA1C for ; Fri, 22 Jul 2016 03:44:19 -0700 (PDT) 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 u6MAiGdI007786 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Jul 2016 12:44:17 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.9) with ESMTP id u6MAiDYZ020921 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 10:44:16 GMT 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=1469184256; bh=gTyT0V8hGcxrqohjMqdqHuLTe7Krg6notatS3kHR4IE=; h=Subject:From:To:Date:In-Reply-To:References; b=NEfuNsWjMAyfYT/FiAw0iUDIRqaZgqBhU2LkUaF32CuZ3jjNdLvogWxr7fZNdVgYF qxl0Tzd1FzVbFvftMBKEZQ/m+X569oqG5tDWc7yx+94h74iXj/vPZWoe3mpBVIJy7d gFzuoosec0Zs/xy/AFFScG/zz12ksZZuihVrmBH8= X-Footer: c3VuZXQuc2U= Received: from dhcp-8f51.meeting.ietf.org ([31.133.143.81]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.1.0) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 22 Jul 2016 12:44:11 +0200 Message-ID: <1469184250.12541.6.camel@sunet.se> From: Leif Johansson To: "Hodges, Jeff" , Tokbind WG Date: Fri, 22 Jul 2016 12:44:10 +0200 In-Reply-To: References: Organization: SUNET Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: 09RlKIhps - 815ab7f5e745 - 20160722 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: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 10:44:23 -0000 On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote: > Mike and I have crafted proposed text to resolve #53 "add TB api > guidance", as we agreed to do during the working group meeting on > Tuesday.   It comprises a new short "Implementation considerations" > section and an additional paragraph in the Privacy Considerations > section, addressing the request by Stephen Farrell. > > thoughts?  > > thanks, HTH,  > > =JeffH & Mike Jones > Thx for this. I'd like +1s or -1s (with some motivation preferably) from the WG! From nobody Fri Jul 22 04:27:56 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC07312DA6D for ; Fri, 22 Jul 2016 04:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATxFF-jSJH7I for ; Fri, 22 Jul 2016 04:27:49 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0129.outbound.protection.outlook.com [104.47.37.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7169A12DAA0 for ; Fri, 22 Jul 2016 04:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qV/pjxHSoMJ8MoUHrRl3wp53kF86tJO4NLMHqDfEakg=; b=ZPlh7zcfWvo25oqOzlgX9HsvPAGWQ6IyalL/+weNfDrJTXn/4vl6otmsISj425lxgnS74ZGKHx5UtHGM6zGL7zipEiAxHz1fYWJAZzFz2Lw8bUT0U+srxLYC+k9a+k1on9+sPue85Qyy89kKkL4rvdGYGp/CP4lxrLufPWRD43s= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Fri, 22 Jul 2016 11:27:46 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0544.017; Fri, 22 Jul 2016 11:27:46 +0000 From: Andrei Popov To: Leif Johansson , "Hodges, Jeff" , Tokbind WG Thread-Topic: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance Thread-Index: AQHR4/soxpW9I2zkUEKpK8sbSC1kuqAkQ/4AgAAHrgA= Date: Fri, 22 Jul 2016 11:27:46 +0000 Message-ID: References: <1469184250.12541.6.camel@sunet.se> In-Reply-To: <1469184250.12541.6.camel@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [46.189.28.35] x-ms-office365-filtering-correlation-id: 22df36f6-b42c-4bed-9d8d-08d3b2233481 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:8fjaWXRJOUxIK7msIYw/MTP74tpk6jreP4gdHppcGN9I8TdkjgkWnY5VcGD6YWJC2Zy7F8oC7kHgTyItl3WbRR0XQW6iJgpPR4KDC0fhQUnEM3zFZTKhFLKklPA9Xr0KOwQNse1fRO/5nNLp0dF4+PKP/40RT84fFpExxbdl90km6cQbF47soMFg+sQ5iOR+x1TB19Pm6PMPbIs/VDrYs5ARWm+vKn2SDY+Srubien8i5l3i+qfnAZ9ulQc3KLzMwtcIFpMIWzXdUDtIX1gVDnmw52GPqIkGccoJHW1IdF7iMSq9vzu/WclD6UNa9k0s5ve8f5PrmlHxHoD/JLas3g==; 5:JjUCOpYjrLln21hIq1RqIFlweBSTtBnHCuDuW1KY5+ks1bSA2/136M2ODuGbw/MhP0F8SMeUku7RFDl3xZC12b83PshOo/S46zJqGsgIqFMuRvNsucwavaLRttrC95bi7XST/OMWOzN8H6LWhbme9A==; 24:SDsczBjpb+r3CbcmFz7pSBhN0pm6Wk+8+Gk2KiVIKhU2N9DvXht5b5qeZreegR6VTqqs8A8/ka9gmSK7UtBgzJYMxkdlFT3Lql+KTzFYI7M=; 7:Ge1m6SCzM8noe5Mm3j5Xvzs4uqhNVrBpjnFZ0GkvoIa/bbwIz/aYF4Kod3panQVBtk/WUWm9c0aOn8/wXdVOVNTwd1LzktfBPw+JxJJ3nOm1H1vkovHnb8AGSfINRz1yVOoqAZnliBlbQsi4LKD0GYslRhWYgB5DtvsKjbhRRjYe6o5hxmyeeyhqq+Arwhrh82x7+aO78fmfYw5JlZkOXs1B3nS5733tA2LqkwRaVscgNIJoZbKxeUXJY9Ul5tYo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(252895345309445)(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(24454002)(377424004)(199003)(377454003)(101416001)(81156014)(76176999)(106116001)(10090500001)(8676002)(9686002)(106356001)(50986999)(54356999)(87936001)(189998001)(5002640100001)(68736007)(5001770100001)(8936002)(81166006)(3846002)(122556002)(6116002)(2950100001)(15975445007)(102836003)(92566002)(2900100001)(8990500004)(86612001)(586003)(19580395003)(77096005)(105586002)(99286002)(19580405001)(7846002)(7736002)(76576001)(305945005)(97736004)(11100500001)(5003600100003)(7696003)(66066001)(3660700001)(86362001)(33656002)(74316002)(3280700002)(5005710100001)(10400500002)(2906002)(107886002)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2016 11:27:46.0618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 11:27:55 -0000 VG8gcmVzdGF0ZSBteSBwb3NpdGlvbiBvbiB0aGlzLCBpdCBpcyBncmVhdCB0byBoYXZlIEFQSSBn dWlkYW5jZSwgYnV0IFRCUFJPVE8gaXMgbm90IHRoZSBhcHByb3ByaWF0ZSBzcGVjIGZvciBpdC4g VEJQUk9UTyBkZXNjcmliZXMgdGhlIGZ1bmRhbWVudGFsIG1lc3NhZ2UgZm9ybWF0cyBmb3IgZXZl cnkga2luZCBvZiBhcHBsaWNhdGlvbiBhbmQgYXJjaGl0ZWN0dXJlLCBmcm9tIHNlbGYtY29udGFp bmVkIGFwcHMgdG8gbGF5ZXJlZCBwbGF0Zm9ybXMuIEl0J3MgaGFyZCB0byBjb21lIHVwIHdpdGgg c3BlY2lmaWMgQVBJIGd1aWRlbGluZXMgdGhhdCBhcmUgZ2VuZXJhbGx5IGFwcGxpY2FibGUuIE15 IHZvdGUgaXMgdG8gY29ycmVjdCB0aGlzIHRleHQgYW5kIHB1dCBpdCBpbiB0aGUgT0FVVEhUQiBz cGVjLCB3aGljaCBhY3R1YWxseSByZXF1aXJlcyB0aGVzZSBBUElzLg0KDQpIZXJlIGFyZSB0aGUg c3BlY2lmaWMgaXNzdWVzIEkgaGF2ZSB3aXRoIHRoZSBwcm9wb3NlZCB0ZXh0Og0KMS4J4oCcSW4g YWRkaXRpb24gdG8gdGhlIGZ1bmN0aW9uYWxpdHkgdG8gdXNlIHJlZmVycmVkIFRva2VuIEJpbmRp bmcgSURz4oCm4oCdIC0gdGhlIGxhbmd1YWdlIGZvY3VzZXMgb24gdGhlIHJlZmVycmVkIFRva2Vu IEJpbmRpbmdzLCBidXQgYWN0dWFsbHkgdGhlIGFwcGxpY2F0aW9uIEFQSSB3b3VsZCBuZWVkIHRv IGFsbG93IHRoZSB1c2Ugb2YgYW55IFRCIHR5cGVzICh0aGF0IHRoZSBpbXBsZW1lbnRlciBpcyB3 aWxsaW5nIHRvIHN1cHBvcnQgYW5kIGV4cG9zZSksIGFuZCBtb3N0IGNlcnRhaW5seSBwcm92aWRl ZCBvbmVzLg0KMi4J4oCcVG9rZW4gQmluZGluZyBpbXBsZW1lbnRhdGlvbnMgcHJvdmlkaW5nIGFu IEFwcGxpY2F0aW9uIFByb2dyYW1taW5nIEludGVyZmFjZSAoQVBJKSBzaG91bGQgcHJvdmlkZSBt ZWFucyBmb3IgYXBwbGljYXRpb25zIHRvIHByb2R1Y2UgVG9rZW4gQmluZGluZyBtZXNzYWdlcyBj b250YWluaW5nIFRva2VuIEJpbmRpbmcgSURzIGZvciBhcHBsaWNhdGlvbi1zcGVjaWZpZWQgVExT IGNvbm5lY3Rpb25z4oCdLSBlLmcuIGluIHRoZSBJRFAtZmlyc3Qgc2NlbmFyaW9zLCB0aGUgVExT IGNvbm5lY3Rpb24gdG8gdGhlIFJQIGRvZXMgbm90IGV4aXN0IGF0IHRoZSB0aW1lIGl0cyBUQiBJ RCBpcyB1c2VkIGluIFRCIG1lc3NhZ2VzLiBBbGwgdGhlIGFwcCBjYW4gcHJvdmlkZSBpbiB0aGlz IGNhc2UgaXMgdGhlIHRhcmdldCBSUCwgb3IgdGhlIFRCIGtleSB0aGF0IHdpbGwgYmUgdXNlZCB3 aXRoIHRoaXMgUlAuDQozLgnigJxUaGUgYXBwbGljYXRpb24gbmVlZHMgdG8gYmUgYWJsZSB0byBk ZW5vdGUgdGhlIFRva2VuIEJpbmRpbmcgVHlwZSAoZS5nLiwgcHJvdmlkZWQsIHJlZmVycmVkLCBl dGMuKSBvZiBlYWNoIHNwZWNpZmllZCBjb25uZWN0aW9uIGFzIHdlbGwgYXMgdGhlIFRMUyBjb25u ZWN0aW9uIHRoZSBhcHBsaWNhdGlvbiBpbnRlbmRzIHRvIHNlbmQgdGhlIFRva2VuIEJpbmRpbmcg bWVzc2FnZSBvdmVy4oCdIOKAkyB0aGUgQVBJIGNvdWxkIGFjY2VwdCB0aGUg4oCcVExTIGNvbm5l Y3Rpb27igJ0sIG9yIGl0IGNvdWxkIGFjY2VwdCB0aGUgY29ycmVzcG9uZGluZyBFS00gdmFsdWXi gKYgaW4gdGhpcyBsb3ctbGV2ZWwgc3BlYywgd2Ugc2hvdWxkIG5vdCBwcmVzY3JpYmUgb25lIEFQ SSBkZXNpZ24uIEhvd2V2ZXIsIGluIGEgaGlnaGVyLWxldmVsIHNwZWMsIHNwZWNpZmljIEFQSSBk ZXNpZ24gbWF5IGJlIHdlbGNvbWUuIEhlbmNlIG15IHByZWZlcmVuY2UgdGhhdCB0aGlzIHdvdWxk IGFsbCBiZSBpbiBPQVVUSFRCLg0KNC4J4oCcVGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGJlIGFi bGUgdG8gZGVub3RlIHRoZSBUb2tlbiBCaW5kaW5nIFR5cGUgKGUuZy4sIHByb3ZpZGVkLCByZWZl cnJlZCwgZXRjLikgb2YgZWFjaCBzcGVjaWZpZWQgY29ubmVjdGlvbuKApuKAnSDigJMgSSBjYW4n dCBwYXJzZSB0aGlzIGJlY2F1c2UgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhICJUb2tlbiBC aW5kaW5nIFR5cGUgb2YgYSBUTFMgY29ubmVjdGlvbiIuDQo1LgnigJzigKYgYXMgd2VsbCBhcyB0 aGUgVExTIGNvbm5lY3Rpb24gdGhlIGFwcGxpY2F0aW9uIGludGVuZHMgdG8gc2VuZCB0aGUgVG9r ZW4gQmluZGluZyBtZXNzYWdlIG92ZXLigJ0g4oCTIHNhbWUgY29tbWVudCBhcyAjIyAyIGFuZCAz IGFib3ZlLg0KNi4J4oCcQWRkaXRpb25hbGx5LCB0aGUgdXNlIG9mIFRva2VuIEJpbmRpbmcgSURz IGZvciBvdGhlciB0aGFuIHRoZSBwcm92aWRlZCBUb2tlbiBCaW5kaW5nIFR5cGUgZ2l2ZXMgY29t bXVuaWNhdGluZyBwYXJ0aWVzIGluZm9tYXRpb24gYWJvdXQgYWRkaXRpb25hbCBUTFMgY29ubmVj dGlvbnMgb2YgdGhlIGFwcGxpY2F0aW9uLuKAnSDigJMgYXBhcnQgZnJvbSB0aGUgdHlwbywgdGhp cyBpcyBub3QgdGhlIGVzc2VuY2Ugb2YgdGhlIGlzc3VlLiBUaGUgbGlua2FiaWxpdHkgaXNzdWUg ZXhpc3RzIHdoZW4gYW4gYXBwIGlzIGFibGUgdG8gcXVlcnkgVEJzIHRoYXQgb3RoZXIgYXBwcyBt YXkgYmUgdXNpbmcgKG9mIGFueSB0eXBlOiBwcm92aWRlZCwgcmVmZXJyZWQsIC4uLikgU3VjaCBh biBhcHAgY2FuIGNvcnJlbGF0ZSB0cmFmZmljLiBGdXJ0aGVyLCBkZXBlbmRpbmcgb24gdGhlIEFQ SSwgc3VjaCBhbiBhcHAgbWF5IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHdoYXQgdGFyZ2V0IHNlcnZl cnMgaGF2ZSBiZWVuIHZpc2l0ZWQuDQo3LgnigJxIb3dldmVyLCBpZiBub3QsIHRoZW4gdGhlcmUg aXMgcG90ZW50aWFsIGZvciBleHBvc2luZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFuZCBkdWUg Y2F1dGlvbiBzaG91bGQgYmUgZXhlcmNpc2VkIGJ5IHRoZSBhcHBsaWNhdGlvbuKAnSDigJMgdGhp cyBpcyBub3QgYW4gYWN0aW9uYWJsZSBtaXRpZ2F0aW9uLiBJbnN0ZWFkLCB0aGlzIHNob3VsZCBi ZSBtaXRpZ2F0ZWQgYnkgaXNvbGF0aW5nIGtleXMsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDgu NC4g4oCcVG9rZW4gQmluZGluZyBLZXkgU2hhcmluZyBCZXR3ZWVuIEFwcGxpY2F0aW9uc+KAnS4N Cg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMZWlmIEpvaGFuc3Nvbg0KU2VudDogRnJpZGF5LCBKdWx5IDIyLCAyMDE2IDEyOjQ0IFBN DQpUbzogSG9kZ2VzLCBKZWZmIDxqZWZmLmhvZGdlc0BwYXlwYWwuY29tPjsgVG9rYmluZCBXRyA8 dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gUFIjNTQ6IFRC UFJPVE8tMDk6IGFkZHJlc3MgaW1wbGVtZW50YXRpb24vYXBpIGd1aWRhbmNlDQoNCk9uIGZyZSwg MjAxNi0wNy0yMiBhdCAwOToyNiArMDAwMCwgSG9kZ2VzLCBKZWZmIHdyb3RlOg0KPiBNaWtlIGFu ZCBJIGhhdmUgY3JhZnRlZCBwcm9wb3NlZCB0ZXh0IHRvIHJlc29sdmUgIzUzICJhZGQgVEIgYXBp IA0KPiBndWlkYW5jZSIsIGFzIHdlIGFncmVlZCB0byBkbyBkdXJpbmcgdGhlIHdvcmtpbmcgZ3Jv dXAgbWVldGluZyBvbiANCj4gVHVlc2RheS4gwqAgSXQgY29tcHJpc2VzIGEgbmV3IHNob3J0ICJJ bXBsZW1lbnRhdGlvbiBjb25zaWRlcmF0aW9ucyINCj4gc2VjdGlvbiBhbmQgYW4gYWRkaXRpb25h bCBwYXJhZ3JhcGggaW4gdGhlIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgDQo+IHNlY3Rpb24sIGFk ZHJlc3NpbmcgdGhlIHJlcXVlc3QgYnkgU3RlcGhlbiBGYXJyZWxsLg0KPiANCj4gdGhvdWdodHM/ DQo+IA0KPiB0aGFua3MsIEhUSCwNCj4gDQo+ID1KZWZmSCAmIE1pa2UgSm9uZXMNCj4gDQoNCg0K VGh4IGZvciB0aGlzLg0KDQpJJ2QgbGlrZSArMXMgb3IgLTFzICh3aXRoIHNvbWUgbW90aXZhdGlv biBwcmVmZXJhYmx5KSBmcm9tIHRoZSBXRyENCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFi bGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZQ0K From nobody Fri Jul 22 06:38:10 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF012D11A for ; Fri, 22 Jul 2016 06:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zac_SRu0Jpol for ; Fri, 22 Jul 2016 06:38:06 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 5FC3E12D0F1 for ; Fri, 22 Jul 2016 06:38:06 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id u134so102785588ywg.3 for ; Fri, 22 Jul 2016 06:38:06 -0700 (PDT) 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=C9A5lzLJ8JjYq/UpY1GkF66SW2NlVXVUNNb4/cN5BkI=; b=ZT0FPY+PJgpcjuHzKvOpssDR6SlCzbbkI/72Jdqoq/Quyj0Solfa3hqxf5Z8j7qROe pAzluaz6FAtN/feOHrQxOskszEsKixflDmyQCGCwSAWokee821wD6xq8JCiUX9Lhu+I/ FsYM+3ocn4gy8UR14WEhyQT9k2xUOUrg50I+14YYT3utNAbgb4OGdmFVwW2DZdSekCy2 u/xCS2FUvETHgDp2GxhlPhE+oODeA5s9DiDxCJl2jNwv248KDNLUAgX8Gu+5z8yIdeYg eEsfLblsHHLOPEXCGoHn+TGkJ8e0Q0RKoMfidCEidVa/DUrvig9ucFhyRaBqhgJPfbOR pEYQ== 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=C9A5lzLJ8JjYq/UpY1GkF66SW2NlVXVUNNb4/cN5BkI=; b=ANHuB5MZ/q7VOA/UKDqJrWO1p2dhBGt9etwcZBQFpN+IHd304MivZVag0WARFZ+/cl +c4wk7ZUf2hVZy/m41DnXWH8dcGHGJUNDh7Gc0f5PRpyuAd9D94HZsOyItQ5xTHLvZqz z1ekmsANtcAUcpG1W70epF3PAFfv1UwyvEJh+zYRHgLmoNKaQmkccO2yd4uQwvMDYe1x VlCm193fZ0W8sb4zkrNRO+OmOBU/q3XB3/9hHultIguIzul6ecXK2DdXnMKFOqadSqAL xyUDsKaMMDIUnlA6o4IRa+SCDXPBUmQNRZPRdOG/oflYWXm8cQt5sHkMc9D40q/iVm87 hhow== X-Gm-Message-State: AEkoouvhTh5QpRf2olE7zLcpYtubhNkVKTP/0/2kiTNqcIOCWz2dR+ICT99LER2RRbOll5SZtxZLJ4ZHMKuGNtS5 X-Received: by 10.129.109.14 with SMTP id i14mr3115363ywc.4.1469194685306; Fri, 22 Jul 2016 06:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.199 with HTTP; Fri, 22 Jul 2016 06:37:45 -0700 (PDT) In-Reply-To: References: <1469184250.12541.6.camel@sunet.se> From: William Denniss Date: Fri, 22 Jul 2016 15:37:45 +0200 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114db696534e3b0538398b76 Archived-At: Cc: Tokbind WG , Leif Johansson , "Hodges, Jeff" Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 13:38:09 -0000 --001a114db696534e3b0538398b76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The HTTPS spec defines the header: "Sec-Token-Binding" which has options for federated token binding. Apps that use HTTPS, which includes Browsers, and other Native apps need to be able to send the Sec-Token-Binding header with a referred token binding. That is, they need to be able to set the referred token binding in the header. The language in this PR should probably be moved to the HTTPS draft, as it relates to how an HTTPS library would expose this functionality to native apps (such as a browser). On Fri, Jul 22, 2016 at 1:27 PM, Andrei Popov wrote: > To restate my position on this, it is great to have API guidance, but > TBPROTO is not the appropriate spec for it. TBPROTO describes the > fundamental message formats for every kind of application and architectur= e, > from self-contained apps to layered platforms. It's hard to come up with > specific API guidelines that are generally applicable. My vote is to > correct this text and put it in the OAUTHTB spec, which actually requires > these APIs. > > Here are the specific issues I have with the proposed text: > 1. =E2=80=9CIn addition to the functionality to use referred Token B= inding > IDs=E2=80=A6=E2=80=9D - the language focuses on the referred Token Bindin= gs, but actually > the application API would need to allow the use of any TB types (that the > implementer is willing to support and expose), and most certainly provide= d > ones. > 2. =E2=80=9CToken Binding implementations providing an Application > Programming Interface (API) should provide means for applications to > produce Token Binding messages containing Token Binding IDs for > application-specified TLS connections=E2=80=9D- e.g. in the IDP-first sce= narios, > the TLS connection to the RP does not exist at the time its TB ID is used > in TB messages. All the app can provide in this case is the target RP, or > the TB key that will be used with this RP. > 3. =E2=80=9CThe application needs to be able to denote the Token Bin= ding Type > (e.g., provided, referred, etc.) of each specified connection as well as > the TLS connection the application intends to send the Token Binding > message over=E2=80=9D =E2=80=93 the API could accept the =E2=80=9CTLS con= nection=E2=80=9D, or it could > accept the corresponding EKM value=E2=80=A6 in this low-level spec, we sh= ould not > prescribe one API design. However, in a higher-level spec, specific API > design may be welcome. Hence my preference that this would all be in > OAUTHTB. > 4. =E2=80=9CThe application needs to be able to denote the Token Bin= ding Type > (e.g., provided, referred, etc.) of each specified connection=E2=80=A6=E2= =80=9D =E2=80=93 I can't > parse this because there is no such thing as a "Token Binding Type of a T= LS > connection". > 5. =E2=80=9C=E2=80=A6 as well as the TLS connection the application = intends to send > the Token Binding message over=E2=80=9D =E2=80=93 same comment as ## 2 an= d 3 above. > 6. =E2=80=9CAdditionally, the use of Token Binding IDs for other tha= n the > provided Token Binding Type gives communicating parties infomation about > additional TLS connections of the application.=E2=80=9D =E2=80=93 apart f= rom the typo, this > is not the essence of the issue. The linkability issue exists when an app > is able to query TBs that other apps may be using (of any type: provided, > referred, ...) Such an app can correlate traffic. Further, depending on t= he > API, such an app may be able to determine what target servers have been > visited. > 7. =E2=80=9CHowever, if not, then there is potential for exposing ad= ditional > information and due caution should be exercised by the application=E2=80= =9D =E2=80=93 this > is not an actionable mitigation. Instead, this should be mitigated by > isolating keys, as described in section 8.4. =E2=80=9CToken Binding Key S= haring > Between Applications=E2=80=9D. > > Cheers, > > Andrei > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif > Johansson > Sent: Friday, July 22, 2016 12:44 PM > To: Hodges, Jeff ; Tokbind WG > > Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api > guidance > > On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote: > > Mike and I have crafted proposed text to resolve #53 "add TB api > > guidance", as we agreed to do during the working group meeting on > > Tuesday. It comprises a new short "Implementation considerations" > > section and an additional paragraph in the Privacy Considerations > > section, addressing the request by Stephen Farrell. > > > > thoughts? > > > > thanks, HTH, > > > > =3DJeffH & Mike Jones > > > > > Thx for this. > > I'd like +1s or -1s (with some motivation preferably) from the WG! > > > _______________________________________________ > 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 > --001a114db696534e3b0538398b76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The HTTPS spec defines the header: "Sec-Token-Binding" which has= options for federated token binding.

Apps = that use HTTPS, which includes Browsers, and other Native apps need to be a= ble to send the=C2=A0S= ec-Token-Binding header with a referred token binding.=C2=A0 That is, they = need to be able to set the referred token binding in the header.

The language in= this PR should probably be moved to the HTTPS draft, as it relates to how = an HTTPS library would expose this functionality to native apps (such as a = browser).



On Fri, Jul 22, 2016 at 1:27 PM, A= ndrei Popov <Andrei.Popov@microsoft.com> wrote:
=
To restate my position on this, it is great = to have API guidance, but TBPROTO is not the appropriate spec for it. TBPRO= TO describes the fundamental message formats for every kind of application = and architecture, from self-contained apps to layered platforms. It's h= ard to come up with specific API guidelines that are generally applicable. = My vote is to correct this text and put it in the OAUTHTB spec, which actua= lly requires these APIs.

Here are the specific issues I have with the proposed text:
1.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CIn addition to the functionality to use ref= erred Token Binding IDs=E2=80=A6=E2=80=9D - the language focuses on the ref= erred Token Bindings, but actually the application API would need to allow = the use of any TB types (that the implementer is willing to support and exp= ose), and most certainly provided ones.
2.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CToken Binding implementations providing an = Application Programming Interface (API) should provide means for applicatio= ns to produce Token Binding messages containing Token Binding IDs for appli= cation-specified TLS connections=E2=80=9D- e.g. in the IDP-first scenarios,= the TLS connection to the RP does not exist at the time its TB ID is used = in TB messages. All the app can provide in this case is the target RP, or t= he TB key that will be used with this RP.
3.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CThe application needs to be able to denote = the Token Binding Type (e.g., provided, referred, etc.) of each specified c= onnection as well as the TLS connection the application intends to send the= Token Binding message over=E2=80=9D =E2=80=93 the API could accept the =E2= =80=9CTLS connection=E2=80=9D, or it could accept the corresponding EKM val= ue=E2=80=A6 in this low-level spec, we should not prescribe one API design.= However, in a higher-level spec, specific API design may be welcome. Hence= my preference that this would all be in OAUTHTB.
4.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CThe application needs to be able to denote = the Token Binding Type (e.g., provided, referred, etc.) of each specified c= onnection=E2=80=A6=E2=80=9D =E2=80=93 I can't parse this because there = is no such thing as a "Token Binding Type of a TLS connection". 5.=C2=A0 =C2=A0 =C2=A0 =E2=80=9C=E2=80=A6 as well as the TLS connection the= application intends to send the Token Binding message over=E2=80=9D =E2=80= =93 same comment as ## 2 and 3 above.
6.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CAdditionally, the use of Token Binding IDs = for other than the provided Token Binding Type gives communicating parties = infomation about additional TLS connections of the application.=E2=80=9D = =E2=80=93 apart from the typo, this is not the essence of the issue. The li= nkability issue exists when an app is able to query TBs that other apps may= be using (of any type: provided, referred, ...) Such an app can correlate = traffic. Further, depending on the API, such an app may be able to determin= e what target servers have been visited.
7.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CHowever, if not, then there is potential fo= r exposing additional information and due caution should be exercised by th= e application=E2=80=9D =E2=80=93 this is not an actionable mitigation. Inst= ead, this should be mitigated by isolating keys, as described in section 8.= 4. =E2=80=9CToken Binding Key Sharing Between Applications=E2=80=9D.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unb= earable-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Friday, July 22, 2016 12:44 PM
To: Hodges, Jeff <jeff.hodges@= paypal.com>; Tokbind WG <u= nbearable@ietf.org>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api gui= dance

On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote:
> Mike and I have crafted proposed text to resolve #53 "add TB api<= br> > guidance", as we agreed to do during the working group meeting on=
> Tuesday. =C2=A0 It comprises a new short "Implementation consider= ations"
> section and an additional paragraph in the Privacy Considerations
> section, addressing the request by Stephen Farrell.
>
> thoughts?
>
> thanks, HTH,
>
> =3DJeffH & Mike Jones
>


Thx for this.

I'd like +1s or -1s (with some motivation preferably) from the WG!


_______________________________________________
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=

--001a114db696534e3b0538398b76-- From nobody Fri Jul 22 06:41:58 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A428C12DA18 for ; Fri, 22 Jul 2016 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6WXZVGSTewN for ; Fri, 22 Jul 2016 06:41:53 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0131.outbound.protection.outlook.com [104.47.38.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C1912D8EA for ; Fri, 22 Jul 2016 06:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IbyYf2tc9w2vv0WJBEXfLAE/e7xzck8ws2I/YI2vim8=; b=cLZaS0c2K2QkPQx1m5BI/wDsZQXgekKF09GW4SKwIR22xO7SeMqxH6N00xrn6Vlarxxjjv/GYfBA3oktwOb2IGEYUeNhPg/f2epJPlNDG374yOHwRxD8ZmcQkhYTcG+eAzcZzY+59p3/14eUwpbi/k6v+0MXWdcRyabbvUdLKdQ= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Fri, 22 Jul 2016 13:41:50 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0544.017; Fri, 22 Jul 2016 13:41:50 +0000 From: Andrei Popov To: William Denniss Thread-Topic: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance Thread-Index: AQHR4/soxpW9I2zkUEKpK8sbSC1kuqAkQ/4AgAAHrgCAACjSgIAAAMgA Date: Fri, 22 Jul 2016 13:41:49 +0000 Message-ID: References: <1469184250.12541.6.camel@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [46.189.28.35] x-ms-office365-filtering-correlation-id: 58d79027-2d3d-492e-787f-08d3b235eee3 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2156; 6:8W9uLwmQdWv5FUH2A4BSxfElqwvmYUlT1N4EarkxgNOWgsaUKPeKs0cuW01x8p4faBZ/jR5vhtXmb1KEJpBF7WSl23eRoJpXeg8eHDIyLK+J+onRtK1347mpy8oocxOX4xjNLNArD/gdXj6FdNlt4m51LIZL5a5uqI3efHsoad7s0E6io7gQTYNwKt7pGz41nmn0yZQ1gOAaASeRBF9n3aZNl6LNwoTRUjqISBY0rR4xdFmXgNTBjs06xZ7K6A6adWrvhZ2Pdb1y1E0C/PX2CNQmlzLKawjzXLNJluBK9MWydFt9X/XPUtYvlA3Bx0xldXNHQiaj3vtAK4BzN8E8CA==; 5:0sn4uDrf7gDVNxmqCl8PfBIwfRP1FrGwZgYvmfHXxXo5TRenkg3sobHbIkSIp7tcST/l9K0yKtQr9ArSYNNRRqOAxTD/1EezfX14rh15hFgpEUuI/0ES5evTxp74KgdCEA/sPX9RMaIYC8Cbo0Yt7A==; 24:FE3h0mW72UTbJp1ZW1VjfpIozCBK0gsOKQ/ZBQCaSZw4pT7uFbNzHVW0HYyRtnS+W2aruPbyNTV9ms8gSpbe+B7LrZeuAU9z1kvbHJFki+4=; 7:52vjYsE/FeCAooY+HZG/AgWZaN6Ut55Whebglg7/GVq4GDFBQRaITo15SEnwWu3bPMvTdToD11aRTLn1KVBbJ5wDAKQjVCDVu9YX4RRCXuI9GOYTJDkiVGcZ//7OACtrNk1DSBUNRPOks6T+G8S5QJv+j5uDUE5uQMJNm7/ybbwPzpJa6X31s8RIBJtN02S6hwfjGjaeIfrU1hf6PPZxvfHx84v+jEnZHxCwenm3RRg7puqtnYibqQe6yd3PevwE x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(252895345309445)(278428928389397)(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2156; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2156; x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377424004)(24454002)(13464003)(377454003)(2950100001)(86612001)(81166006)(76176999)(2900100001)(97736004)(50986999)(81156014)(8676002)(8936002)(54356999)(19300405004)(101416001)(19625215002)(86362001)(76576001)(77096005)(11100500001)(15975445007)(92566002)(10400500002)(5005710100001)(106356001)(106116001)(8990500004)(10290500002)(19580395003)(19580405001)(33656002)(19617315012)(10090500001)(105586002)(110136002)(9686002)(5002640100001)(16236675004)(68736007)(7846002)(189998001)(99286002)(66066001)(7736002)(7696003)(3660700001)(74316002)(3280700002)(5003600100003)(7906003)(102836003)(790700001)(6116002)(3846002)(87936001)(4326007)(2906002)(122556002)(93886004)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2156; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21556D67B66E5F23555CBD468C0A0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2016 13:41:49.7845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2156 Archived-At: Cc: Tokbind WG , Leif Johansson , "Hodges, Jeff" Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 13:41:56 -0000 --_000_CY1PR03MB21556D67B66E5F23555CBD468C0A0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZSBsYW5ndWFnZSBpbiB0aGlzIFBSIHNob3VsZCBwcm9iYWJseSBiZSBtb3ZlZCB0byB0 aGUgSFRUUFMgZHJhZnQsIGFzIGl0IHJlbGF0ZXMgdG8gaG93IGFuIEhUVFBTIGxpYnJhcnkgd291 bGQgZXhwb3NlIHRoaXMgZnVuY3Rpb25hbGl0eSB0byBuYXRpdmUgYXBwcyAoc3VjaCBhcyBhIGJy b3dzZXIpLg0KVGhhdCB3b3VsZCBiZSBhbiBpbXByb3ZlbWVudCBvdmVyIHB1dHRpbmcgaXQgaW4g VEJQUk9UTy4NCg0KRnJvbTogV2lsbGlhbSBEZW5uaXNzIFttYWlsdG86d2Rlbm5pc3NAZ29vZ2xl LmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAyMiwgMjAxNiAzOjM4IFBNDQpUbzogQW5kcmVpIFBv cG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBMZWlmIEpvaGFuc3NvbiA8bGVp ZmpAc3VuZXQuc2U+OyBIb2RnZXMsIEplZmYgPGplZmYuaG9kZ2VzQHBheXBhbC5jb20+OyBUb2ti aW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBQ UiM1NDogVEJQUk9UTy0wOTogYWRkcmVzcyBpbXBsZW1lbnRhdGlvbi9hcGkgZ3VpZGFuY2UNCg0K VGhlIEhUVFBTIHNwZWMgZGVmaW5lcyB0aGUgaGVhZGVyOiAiU2VjLVRva2VuLUJpbmRpbmciIHdo aWNoIGhhcyBvcHRpb25zIGZvciBmZWRlcmF0ZWQgdG9rZW4gYmluZGluZy4NCg0KQXBwcyB0aGF0 IHVzZSBIVFRQUywgd2hpY2ggaW5jbHVkZXMgQnJvd3NlcnMsIGFuZCBvdGhlciBOYXRpdmUgYXBw cyBuZWVkIHRvIGJlIGFibGUgdG8gc2VuZCB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyIHdp dGggYSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nLiAgVGhhdCBpcywgdGhleSBuZWVkIHRvIGJlIGFi bGUgdG8gc2V0IHRoZSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nIGluIHRoZSBoZWFkZXIuDQoNClRo ZSBsYW5ndWFnZSBpbiB0aGlzIFBSIHNob3VsZCBwcm9iYWJseSBiZSBtb3ZlZCB0byB0aGUgSFRU UFMgZHJhZnQsIGFzIGl0IHJlbGF0ZXMgdG8gaG93IGFuIEhUVFBTIGxpYnJhcnkgd291bGQgZXhw b3NlIHRoaXMgZnVuY3Rpb25hbGl0eSB0byBuYXRpdmUgYXBwcyAoc3VjaCBhcyBhIGJyb3dzZXIp Lg0KDQoNCg0KT24gRnJpLCBKdWwgMjIsIDIwMTYgYXQgMToyNyBQTSwgQW5kcmVpIFBvcG92IDxB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b20+PiB3cm90ZToNClRvIHJlc3RhdGUgbXkgcG9zaXRpb24gb24gdGhpcywgaXQgaXMgZ3JlYXQg dG8gaGF2ZSBBUEkgZ3VpZGFuY2UsIGJ1dCBUQlBST1RPIGlzIG5vdCB0aGUgYXBwcm9wcmlhdGUg c3BlYyBmb3IgaXQuIFRCUFJPVE8gZGVzY3JpYmVzIHRoZSBmdW5kYW1lbnRhbCBtZXNzYWdlIGZv cm1hdHMgZm9yIGV2ZXJ5IGtpbmQgb2YgYXBwbGljYXRpb24gYW5kIGFyY2hpdGVjdHVyZSwgZnJv bSBzZWxmLWNvbnRhaW5lZCBhcHBzIHRvIGxheWVyZWQgcGxhdGZvcm1zLiBJdCdzIGhhcmQgdG8g Y29tZSB1cCB3aXRoIHNwZWNpZmljIEFQSSBndWlkZWxpbmVzIHRoYXQgYXJlIGdlbmVyYWxseSBh cHBsaWNhYmxlLiBNeSB2b3RlIGlzIHRvIGNvcnJlY3QgdGhpcyB0ZXh0IGFuZCBwdXQgaXQgaW4g dGhlIE9BVVRIVEIgc3BlYywgd2hpY2ggYWN0dWFsbHkgcmVxdWlyZXMgdGhlc2UgQVBJcy4NCg0K SGVyZSBhcmUgdGhlIHNwZWNpZmljIGlzc3VlcyBJIGhhdmUgd2l0aCB0aGUgcHJvcG9zZWQgdGV4 dDoNCjEuICAgICAg4oCcSW4gYWRkaXRpb24gdG8gdGhlIGZ1bmN0aW9uYWxpdHkgdG8gdXNlIHJl ZmVycmVkIFRva2VuIEJpbmRpbmcgSURz4oCm4oCdIC0gdGhlIGxhbmd1YWdlIGZvY3VzZXMgb24g dGhlIHJlZmVycmVkIFRva2VuIEJpbmRpbmdzLCBidXQgYWN0dWFsbHkgdGhlIGFwcGxpY2F0aW9u IEFQSSB3b3VsZCBuZWVkIHRvIGFsbG93IHRoZSB1c2Ugb2YgYW55IFRCIHR5cGVzICh0aGF0IHRo ZSBpbXBsZW1lbnRlciBpcyB3aWxsaW5nIHRvIHN1cHBvcnQgYW5kIGV4cG9zZSksIGFuZCBtb3N0 IGNlcnRhaW5seSBwcm92aWRlZCBvbmVzLg0KMi4gICAgICDigJxUb2tlbiBCaW5kaW5nIGltcGxl bWVudGF0aW9ucyBwcm92aWRpbmcgYW4gQXBwbGljYXRpb24gUHJvZ3JhbW1pbmcgSW50ZXJmYWNl IChBUEkpIHNob3VsZCBwcm92aWRlIG1lYW5zIGZvciBhcHBsaWNhdGlvbnMgdG8gcHJvZHVjZSBU b2tlbiBCaW5kaW5nIG1lc3NhZ2VzIGNvbnRhaW5pbmcgVG9rZW4gQmluZGluZyBJRHMgZm9yIGFw cGxpY2F0aW9uLXNwZWNpZmllZCBUTFMgY29ubmVjdGlvbnPigJ0tIGUuZy4gaW4gdGhlIElEUC1m aXJzdCBzY2VuYXJpb3MsIHRoZSBUTFMgY29ubmVjdGlvbiB0byB0aGUgUlAgZG9lcyBub3QgZXhp c3QgYXQgdGhlIHRpbWUgaXRzIFRCIElEIGlzIHVzZWQgaW4gVEIgbWVzc2FnZXMuIEFsbCB0aGUg YXBwIGNhbiBwcm92aWRlIGluIHRoaXMgY2FzZSBpcyB0aGUgdGFyZ2V0IFJQLCBvciB0aGUgVEIg a2V5IHRoYXQgd2lsbCBiZSB1c2VkIHdpdGggdGhpcyBSUC4NCjMuICAgICAg4oCcVGhlIGFwcGxp Y2F0aW9uIG5lZWRzIHRvIGJlIGFibGUgdG8gZGVub3RlIHRoZSBUb2tlbiBCaW5kaW5nIFR5cGUg KGUuZy4sIHByb3ZpZGVkLCByZWZlcnJlZCwgZXRjLikgb2YgZWFjaCBzcGVjaWZpZWQgY29ubmVj dGlvbiBhcyB3ZWxsIGFzIHRoZSBUTFMgY29ubmVjdGlvbiB0aGUgYXBwbGljYXRpb24gaW50ZW5k cyB0byBzZW5kIHRoZSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2Ugb3ZlcuKAnSDigJMgdGhlIEFQSSBj b3VsZCBhY2NlcHQgdGhlIOKAnFRMUyBjb25uZWN0aW9u4oCdLCBvciBpdCBjb3VsZCBhY2NlcHQg dGhlIGNvcnJlc3BvbmRpbmcgRUtNIHZhbHVl4oCmIGluIHRoaXMgbG93LWxldmVsIHNwZWMsIHdl IHNob3VsZCBub3QgcHJlc2NyaWJlIG9uZSBBUEkgZGVzaWduLiBIb3dldmVyLCBpbiBhIGhpZ2hl ci1sZXZlbCBzcGVjLCBzcGVjaWZpYyBBUEkgZGVzaWduIG1heSBiZSB3ZWxjb21lLiBIZW5jZSBt eSBwcmVmZXJlbmNlIHRoYXQgdGhpcyB3b3VsZCBhbGwgYmUgaW4gT0FVVEhUQi4NCjQuICAgICAg 4oCcVGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGJlIGFibGUgdG8gZGVub3RlIHRoZSBUb2tlbiBC aW5kaW5nIFR5cGUgKGUuZy4sIHByb3ZpZGVkLCByZWZlcnJlZCwgZXRjLikgb2YgZWFjaCBzcGVj aWZpZWQgY29ubmVjdGlvbuKApuKAnSDigJMgSSBjYW4ndCBwYXJzZSB0aGlzIGJlY2F1c2UgdGhl cmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhICJUb2tlbiBCaW5kaW5nIFR5cGUgb2YgYSBUTFMgY29u bmVjdGlvbiIuDQo1LiAgICAgIOKAnOKApiBhcyB3ZWxsIGFzIHRoZSBUTFMgY29ubmVjdGlvbiB0 aGUgYXBwbGljYXRpb24gaW50ZW5kcyB0byBzZW5kIHRoZSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2Ug b3ZlcuKAnSDigJMgc2FtZSBjb21tZW50IGFzICMjIDIgYW5kIDMgYWJvdmUuDQo2LiAgICAgIOKA nEFkZGl0aW9uYWxseSwgdGhlIHVzZSBvZiBUb2tlbiBCaW5kaW5nIElEcyBmb3Igb3RoZXIgdGhh biB0aGUgcHJvdmlkZWQgVG9rZW4gQmluZGluZyBUeXBlIGdpdmVzIGNvbW11bmljYXRpbmcgcGFy dGllcyBpbmZvbWF0aW9uIGFib3V0IGFkZGl0aW9uYWwgVExTIGNvbm5lY3Rpb25zIG9mIHRoZSBh cHBsaWNhdGlvbi7igJ0g4oCTIGFwYXJ0IGZyb20gdGhlIHR5cG8sIHRoaXMgaXMgbm90IHRoZSBl c3NlbmNlIG9mIHRoZSBpc3N1ZS4gVGhlIGxpbmthYmlsaXR5IGlzc3VlIGV4aXN0cyB3aGVuIGFu IGFwcCBpcyBhYmxlIHRvIHF1ZXJ5IFRCcyB0aGF0IG90aGVyIGFwcHMgbWF5IGJlIHVzaW5nIChv ZiBhbnkgdHlwZTogcHJvdmlkZWQsIHJlZmVycmVkLCAuLi4pIFN1Y2ggYW4gYXBwIGNhbiBjb3Jy ZWxhdGUgdHJhZmZpYy4gRnVydGhlciwgZGVwZW5kaW5nIG9uIHRoZSBBUEksIHN1Y2ggYW4gYXBw IG1heSBiZSBhYmxlIHRvIGRldGVybWluZSB3aGF0IHRhcmdldCBzZXJ2ZXJzIGhhdmUgYmVlbiB2 aXNpdGVkLg0KNy4gICAgICDigJxIb3dldmVyLCBpZiBub3QsIHRoZW4gdGhlcmUgaXMgcG90ZW50 aWFsIGZvciBleHBvc2luZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFuZCBkdWUgY2F1dGlvbiBz aG91bGQgYmUgZXhlcmNpc2VkIGJ5IHRoZSBhcHBsaWNhdGlvbuKAnSDigJMgdGhpcyBpcyBub3Qg YW4gYWN0aW9uYWJsZSBtaXRpZ2F0aW9uLiBJbnN0ZWFkLCB0aGlzIHNob3VsZCBiZSBtaXRpZ2F0 ZWQgYnkgaXNvbGF0aW5nIGtleXMsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDguNC4g4oCcVG9r ZW4gQmluZGluZyBLZXkgU2hhcmluZyBCZXR3ZWVuIEFwcGxpY2F0aW9uc+KAnS4NCg0KQ2hlZXJz LA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFVuYmVhcmFi bGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGUt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBMZWlmIEpvaGFuc3Nvbg0KU2VudDogRnJp ZGF5LCBKdWx5IDIyLCAyMDE2IDEyOjQ0IFBNDQpUbzogSG9kZ2VzLCBKZWZmIDxqZWZmLmhvZGdl c0BwYXlwYWwuY29tPG1haWx0bzpqZWZmLmhvZGdlc0BwYXlwYWwuY29tPj47IFRva2JpbmQgV0cg PHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtVbmJlYXJhYmxlXSBQUiM1NDogVEJQUk9UTy0wOTogYWRkcmVzcyBpbXBsZW1lbnRh dGlvbi9hcGkgZ3VpZGFuY2UNCg0KT24gZnJlLCAyMDE2LTA3LTIyIGF0IDA5OjI2ICswMDAwLCBI b2RnZXMsIEplZmYgd3JvdGU6DQo+IE1pa2UgYW5kIEkgaGF2ZSBjcmFmdGVkIHByb3Bvc2VkIHRl eHQgdG8gcmVzb2x2ZSAjNTMgImFkZCBUQiBhcGkNCj4gZ3VpZGFuY2UiLCBhcyB3ZSBhZ3JlZWQg dG8gZG8gZHVyaW5nIHRoZSB3b3JraW5nIGdyb3VwIG1lZXRpbmcgb24NCj4gVHVlc2RheS4gICBJ dCBjb21wcmlzZXMgYSBuZXcgc2hvcnQgIkltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb25zIg0K PiBzZWN0aW9uIGFuZCBhbiBhZGRpdGlvbmFsIHBhcmFncmFwaCBpbiB0aGUgUHJpdmFjeSBDb25z aWRlcmF0aW9ucw0KPiBzZWN0aW9uLCBhZGRyZXNzaW5nIHRoZSByZXF1ZXN0IGJ5IFN0ZXBoZW4g RmFycmVsbC4NCj4NCj4gdGhvdWdodHM/DQo+DQo+IHRoYW5rcywgSFRILA0KPg0KPiA9SmVmZkgg JiBNaWtlIEpvbmVzDQo+DQoNCg0KVGh4IGZvciB0aGlzLg0KDQpJJ2QgbGlrZSArMXMgb3IgLTFz ICh3aXRoIHNvbWUgbW90aXZhdGlvbiBwcmVmZXJhYmx5KSBmcm9tIHRoZSBXRyENCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBt YWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJlYXJhYmxl IG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0K DQo= --_000_CY1PR03MB21556D67B66E5F23555CBD468C0A0CY1PR03MB2155namp_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEzNTgyMzQ0Mjc7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTM0NTQ4NDUyIC0y MTA3MzI1NDk0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlRoZSBsYW5ndWFnZSBpbiB0aGlzIFBSIHNo b3VsZCBwcm9iYWJseSBiZSBtb3ZlZCB0byB0aGUgSFRUUFMgZHJhZnQsIGFzIGl0IHJlbGF0ZXMg dG8gaG93IGFuIEhUVFBTIGxpYnJhcnkgd291bGQgZXhwb3NlIHRoaXMgZnVuY3Rpb25hbGl0eSB0 byBuYXRpdmUgYXBwcyAoc3VjaCBhcyBhIGJyb3dzZXIpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCB3b3VsZCBiZSBhbiBp bXByb3ZlbWVudCBvdmVyIHB1dHRpbmcgaXQgaW4gVEJQUk9UTy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDIyLCAyMDE2IDM6MzggUE08YnI+DQo8Yj5Ubzo8 L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBMZWlmIEpvaGFuc3NvbiAmbHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7OyBIb2RnZXMs IEplZmYgJmx0O2plZmYuaG9kZ2VzQHBheXBhbC5jb20mZ3Q7OyBUb2tiaW5kIFdHICZsdDt1bmJl YXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVd IFBSIzU0OiBUQlBST1RPLTA5OiBhZGRyZXNzIGltcGxlbWVudGF0aW9uL2FwaSBndWlkYW5jZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgSFRUUFMgc3Bl YyBkZWZpbmVzIHRoZSBoZWFkZXI6ICZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOmJsYWNrIj5TZWMtVG9rZW4tQmluZGluZyZxdW90OyB3aGljaCBoYXMgb3B0aW9ucyBm b3IgZmVkZXJhdGVkIHRva2VuIGJpbmRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHBzIHRoYXQgdXNlIEhUVFBTLCB3aGlj aCBpbmNsdWRlcyBCcm93c2VycywgYW5kIG90aGVyIE5hdGl2ZSBhcHBzIG5lZWQgdG8gYmUgYWJs ZSB0byBzZW5kIHRoZSZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj5TZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgd2l0aCBhIHJlZmVycmVkIHRva2VuIGJpbmRp bmcuJm5ic3A7IFRoYXQgaXMsIHRoZXkgbmVlZCB0byBiZSBhYmxlIHRvIHNldCB0aGUNCiByZWZl cnJlZCB0b2tlbiBiaW5kaW5nIGluIHRoZSBoZWFkZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+VGhlIGxhbmd1YWdlIGluIHRoaXMgUFIgc2hvdWxkIHBy b2JhYmx5IGJlIG1vdmVkIHRvIHRoZSBIVFRQUyBkcmFmdCwgYXMgaXQgcmVsYXRlcyB0byBob3cg YW4gSFRUUFMgbGlicmFyeSB3b3VsZCBleHBvc2UgdGhpcyBmdW5jdGlvbmFsaXR5IHRvIG5hdGl2 ZSBhcHBzIChzdWNoIGFzIGEgYnJvd3NlcikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdWwgMjIsIDIwMTYg YXQgMToyNyBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRvIHJlc3RhdGUgbXkgcG9zaXRpb24gb24gdGhpcywgaXQgaXMgZ3JlYXQgdG8g aGF2ZSBBUEkgZ3VpZGFuY2UsIGJ1dCBUQlBST1RPIGlzIG5vdCB0aGUgYXBwcm9wcmlhdGUgc3Bl YyBmb3IgaXQuIFRCUFJPVE8gZGVzY3JpYmVzIHRoZSBmdW5kYW1lbnRhbCBtZXNzYWdlIGZvcm1h dHMgZm9yIGV2ZXJ5IGtpbmQgb2YgYXBwbGljYXRpb24gYW5kIGFyY2hpdGVjdHVyZSwgZnJvbSBz ZWxmLWNvbnRhaW5lZCBhcHBzDQogdG8gbGF5ZXJlZCBwbGF0Zm9ybXMuIEl0J3MgaGFyZCB0byBj b21lIHVwIHdpdGggc3BlY2lmaWMgQVBJIGd1aWRlbGluZXMgdGhhdCBhcmUgZ2VuZXJhbGx5IGFw cGxpY2FibGUuIE15IHZvdGUgaXMgdG8gY29ycmVjdCB0aGlzIHRleHQgYW5kIHB1dCBpdCBpbiB0 aGUgT0FVVEhUQiBzcGVjLCB3aGljaCBhY3R1YWxseSByZXF1aXJlcyB0aGVzZSBBUElzLjxicj4N Cjxicj4NCkhlcmUgYXJlIHRoZSBzcGVjaWZpYyBpc3N1ZXMgSSBoYXZlIHdpdGggdGhlIHByb3Bv c2VkIHRleHQ6PGJyPg0KMS4mbmJzcDsgJm5ic3A7ICZuYnNwOyDigJxJbiBhZGRpdGlvbiB0byB0 aGUgZnVuY3Rpb25hbGl0eSB0byB1c2UgcmVmZXJyZWQgVG9rZW4gQmluZGluZyBJRHPigKbigJ0g LSB0aGUgbGFuZ3VhZ2UgZm9jdXNlcyBvbiB0aGUgcmVmZXJyZWQgVG9rZW4gQmluZGluZ3MsIGJ1 dCBhY3R1YWxseSB0aGUgYXBwbGljYXRpb24gQVBJIHdvdWxkIG5lZWQgdG8gYWxsb3cgdGhlIHVz ZSBvZiBhbnkgVEIgdHlwZXMgKHRoYXQgdGhlIGltcGxlbWVudGVyIGlzIHdpbGxpbmcgdG8gc3Vw cG9ydCBhbmQNCiBleHBvc2UpLCBhbmQgbW9zdCBjZXJ0YWlubHkgcHJvdmlkZWQgb25lcy48YnI+ DQoyLiZuYnNwOyAmbmJzcDsgJm5ic3A7IOKAnFRva2VuIEJpbmRpbmcgaW1wbGVtZW50YXRpb25z IHByb3ZpZGluZyBhbiBBcHBsaWNhdGlvbiBQcm9ncmFtbWluZyBJbnRlcmZhY2UgKEFQSSkgc2hv dWxkIHByb3ZpZGUgbWVhbnMgZm9yIGFwcGxpY2F0aW9ucyB0byBwcm9kdWNlIFRva2VuIEJpbmRp bmcgbWVzc2FnZXMgY29udGFpbmluZyBUb2tlbiBCaW5kaW5nIElEcyBmb3IgYXBwbGljYXRpb24t c3BlY2lmaWVkIFRMUyBjb25uZWN0aW9uc+KAnS0gZS5nLiBpbiB0aGUgSURQLWZpcnN0DQogc2Nl bmFyaW9zLCB0aGUgVExTIGNvbm5lY3Rpb24gdG8gdGhlIFJQIGRvZXMgbm90IGV4aXN0IGF0IHRo ZSB0aW1lIGl0cyBUQiBJRCBpcyB1c2VkIGluIFRCIG1lc3NhZ2VzLiBBbGwgdGhlIGFwcCBjYW4g cHJvdmlkZSBpbiB0aGlzIGNhc2UgaXMgdGhlIHRhcmdldCBSUCwgb3IgdGhlIFRCIGtleSB0aGF0 IHdpbGwgYmUgdXNlZCB3aXRoIHRoaXMgUlAuPGJyPg0KMy4mbmJzcDsgJm5ic3A7ICZuYnNwOyDi gJxUaGUgYXBwbGljYXRpb24gbmVlZHMgdG8gYmUgYWJsZSB0byBkZW5vdGUgdGhlIFRva2VuIEJp bmRpbmcgVHlwZSAoZS5nLiwgcHJvdmlkZWQsIHJlZmVycmVkLCBldGMuKSBvZiBlYWNoIHNwZWNp ZmllZCBjb25uZWN0aW9uIGFzIHdlbGwgYXMgdGhlIFRMUyBjb25uZWN0aW9uIHRoZSBhcHBsaWNh dGlvbiBpbnRlbmRzIHRvIHNlbmQgdGhlIFRva2VuIEJpbmRpbmcgbWVzc2FnZSBvdmVy4oCdIOKA kyB0aGUgQVBJIGNvdWxkIGFjY2VwdCB0aGUNCiDigJxUTFMgY29ubmVjdGlvbuKAnSwgb3IgaXQg Y291bGQgYWNjZXB0IHRoZSBjb3JyZXNwb25kaW5nIEVLTSB2YWx1ZeKApiBpbiB0aGlzIGxvdy1s ZXZlbCBzcGVjLCB3ZSBzaG91bGQgbm90IHByZXNjcmliZSBvbmUgQVBJIGRlc2lnbi4gSG93ZXZl ciwgaW4gYSBoaWdoZXItbGV2ZWwgc3BlYywgc3BlY2lmaWMgQVBJIGRlc2lnbiBtYXkgYmUgd2Vs Y29tZS4gSGVuY2UgbXkgcHJlZmVyZW5jZSB0aGF0IHRoaXMgd291bGQgYWxsIGJlIGluIE9BVVRI VEIuPGJyPg0KNC4mbmJzcDsgJm5ic3A7ICZuYnNwOyDigJxUaGUgYXBwbGljYXRpb24gbmVlZHMg dG8gYmUgYWJsZSB0byBkZW5vdGUgdGhlIFRva2VuIEJpbmRpbmcgVHlwZSAoZS5nLiwgcHJvdmlk ZWQsIHJlZmVycmVkLCBldGMuKSBvZiBlYWNoIHNwZWNpZmllZCBjb25uZWN0aW9u4oCm4oCdIOKA kyBJIGNhbid0IHBhcnNlIHRoaXMgYmVjYXVzZSB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGEg JnF1b3Q7VG9rZW4gQmluZGluZyBUeXBlIG9mIGEgVExTIGNvbm5lY3Rpb24mcXVvdDsuPGJyPg0K NS4mbmJzcDsgJm5ic3A7ICZuYnNwOyDigJzigKYgYXMgd2VsbCBhcyB0aGUgVExTIGNvbm5lY3Rp b24gdGhlIGFwcGxpY2F0aW9uIGludGVuZHMgdG8gc2VuZCB0aGUgVG9rZW4gQmluZGluZyBtZXNz YWdlIG92ZXLigJ0g4oCTIHNhbWUgY29tbWVudCBhcyAjIyAyIGFuZCAzIGFib3ZlLjxicj4NCjYu Jm5ic3A7ICZuYnNwOyAmbmJzcDsg4oCcQWRkaXRpb25hbGx5LCB0aGUgdXNlIG9mIFRva2VuIEJp bmRpbmcgSURzIGZvciBvdGhlciB0aGFuIHRoZSBwcm92aWRlZCBUb2tlbiBCaW5kaW5nIFR5cGUg Z2l2ZXMgY29tbXVuaWNhdGluZyBwYXJ0aWVzIGluZm9tYXRpb24gYWJvdXQgYWRkaXRpb25hbCBU TFMgY29ubmVjdGlvbnMgb2YgdGhlIGFwcGxpY2F0aW9uLuKAnSDigJMgYXBhcnQgZnJvbSB0aGUg dHlwbywgdGhpcyBpcyBub3QgdGhlIGVzc2VuY2Ugb2YgdGhlIGlzc3VlLiBUaGUNCiBsaW5rYWJp bGl0eSBpc3N1ZSBleGlzdHMgd2hlbiBhbiBhcHAgaXMgYWJsZSB0byBxdWVyeSBUQnMgdGhhdCBv dGhlciBhcHBzIG1heSBiZSB1c2luZyAob2YgYW55IHR5cGU6IHByb3ZpZGVkLCByZWZlcnJlZCwg Li4uKSBTdWNoIGFuIGFwcCBjYW4gY29ycmVsYXRlIHRyYWZmaWMuIEZ1cnRoZXIsIGRlcGVuZGlu ZyBvbiB0aGUgQVBJLCBzdWNoIGFuIGFwcCBtYXkgYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hhdCB0 YXJnZXQgc2VydmVycyBoYXZlIGJlZW4NCiB2aXNpdGVkLjxicj4NCjcuJm5ic3A7ICZuYnNwOyAm bmJzcDsg4oCcSG93ZXZlciwgaWYgbm90LCB0aGVuIHRoZXJlIGlzIHBvdGVudGlhbCBmb3IgZXhw b3NpbmcgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhbmQgZHVlIGNhdXRpb24gc2hvdWxkIGJlIGV4 ZXJjaXNlZCBieSB0aGUgYXBwbGljYXRpb27igJ0g4oCTIHRoaXMgaXMgbm90IGFuIGFjdGlvbmFi bGUgbWl0aWdhdGlvbi4gSW5zdGVhZCwgdGhpcyBzaG91bGQgYmUgbWl0aWdhdGVkIGJ5IGlzb2xh dGluZyBrZXlzLCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbg0KIDguNC4g4oCcVG9rZW4gQmluZGlu ZyBLZXkgU2hhcmluZyBCZXR3ZWVuIEFwcGxpY2F0aW9uc+KAnS48YnI+DQo8YnI+DQpDaGVlcnMs PGJyPg0KPGJyPg0KQW5kcmVpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog VW5iZWFyYWJsZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0 Zi5vcmciPnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBMZWlm IEpvaGFuc3Nvbjxicj4NClNlbnQ6IEZyaWRheSwgSnVseSAyMiwgMjAxNiAxMjo0NCBQTTxicj4N ClRvOiBIb2RnZXMsIEplZmYgJmx0OzxhIGhyZWY9Im1haWx0bzpqZWZmLmhvZGdlc0BwYXlwYWwu Y29tIj5qZWZmLmhvZGdlc0BwYXlwYWwuY29tPC9hPiZndDs7IFRva2JpbmQgV0cgJmx0OzxhIGhy ZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZn dDs8YnI+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFBSIzU0OiBUQlBST1RPLTA5OiBhZGRy ZXNzIGltcGxlbWVudGF0aW9uL2FwaSBndWlkYW5jZTxicj4NCjxicj4NCk9uIGZyZSwgMjAxNi0w Ny0yMiBhdCAwOToyNiAmIzQzOzAwMDAsIEhvZGdlcywgSmVmZiB3cm90ZTo8YnI+DQomZ3Q7IE1p a2UgYW5kIEkgaGF2ZSBjcmFmdGVkIHByb3Bvc2VkIHRleHQgdG8gcmVzb2x2ZSAjNTMgJnF1b3Q7 YWRkIFRCIGFwaTxicj4NCiZndDsgZ3VpZGFuY2UmcXVvdDssIGFzIHdlIGFncmVlZCB0byBkbyBk dXJpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgbWVldGluZyBvbjxicj4NCiZndDsgVHVlc2RheS4gJm5i c3A7IEl0IGNvbXByaXNlcyBhIG5ldyBzaG9ydCAmcXVvdDtJbXBsZW1lbnRhdGlvbiBjb25zaWRl cmF0aW9ucyZxdW90Ozxicj4NCiZndDsgc2VjdGlvbiBhbmQgYW4gYWRkaXRpb25hbCBwYXJhZ3Jh cGggaW4gdGhlIFByaXZhY3kgQ29uc2lkZXJhdGlvbnM8YnI+DQomZ3Q7IHNlY3Rpb24sIGFkZHJl c3NpbmcgdGhlIHJlcXVlc3QgYnkgU3RlcGhlbiBGYXJyZWxsLjxicj4NCiZndDs8YnI+DQomZ3Q7 IHRob3VnaHRzPzxicj4NCiZndDs8YnI+DQomZ3Q7IHRoYW5rcywgSFRILDxicj4NCiZndDs8YnI+ DQomZ3Q7ID1KZWZmSCAmYW1wOyBNaWtlIEpvbmVzPGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4N ClRoeCBmb3IgdGhpcy48YnI+DQo8YnI+DQpJJ2QgbGlrZSAmIzQzOzFzIG9yIC0xcyAod2l0aCBz b21lIG1vdGl2YXRpb24gcHJlZmVyYWJseSkgZnJvbSB0aGUgV0chPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJl YXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYu b3JnIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFi bGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmci PlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CY1PR03MB21556D67B66E5F23555CBD468C0A0CY1PR03MB2155namp_-- From nobody Fri Jul 22 06:46:17 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022A312D5C6 for ; Fri, 22 Jul 2016 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLdzInHRHDWa for ; Fri, 22 Jul 2016 06:46:13 -0700 (PDT) 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 2999912D928 for ; Fri, 22 Jul 2016 06:46:12 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id m101so105397760ioi.2 for ; Fri, 22 Jul 2016 06:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wNv07MvEv+gIlQVaS5ihJY+05bMS2YPzgw9FLF79/aI=; b=POQ/M6GYmVo+azVaxtU0D8VcqnJi07H6O10Q0cuCTz8ei133fFll9lgdYJPOSjAp+3 7Hdr5yFU8uiZveORer+21iobVap6MBOl2UhZRYtW5fuHEuUT+AEOX9WyWowoJ+yBpI/e 5cp2ffRVlFY1x8guytzBWK8FHRQr3xyeBLQjM= 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=wNv07MvEv+gIlQVaS5ihJY+05bMS2YPzgw9FLF79/aI=; b=hx7UB8Qb5j+7H2akBW0zoIkjmk2NqfAg/eJE/C6onpeJOh/mYX8fYvGitRbrxgyrx6 Mq82lxsxG80xINRPYqwOUe0jGZ8lBVRyg79nDUl/mPtCMpAFJAfJRvtVAl/PFFyJlLTF BQEl1YDKJzy7DaRELWW40jiohZAZ8r2C5m7IF4D1IeE8Ib9Y/MrKrN54WcMf32V/jmtC 97AAdCUvLiVUHDoXD6V+jxnQPucIBLUHqphutenukIdF9VC9LoYGKabdH80bKIOWpXmn DqLIt06S/NQCtLAVPw/Q/d1HCbzqS/H6ucuzJSm9K666FBrTPX7pkEC57sOAH4WPE9qc sBSQ== X-Gm-Message-State: AEkoouv2jaQiikN4Ti7NXf6SFEzvw/brQeQCeHYniCmrNS/aLPJ116P9mH163A4e03wVQEpZo53PD0jbAsdAT8DG X-Received: by 10.107.8.94 with SMTP id 91mr4608180ioi.86.1469195171433; Fri, 22 Jul 2016 06:46:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Fri, 22 Jul 2016 06:45:42 -0700 (PDT) In-Reply-To: References: <1469184250.12541.6.camel@sunet.se> From: Brian Campbell Date: Fri, 22 Jul 2016 15:45:42 +0200 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113f3a884cb257053839a8db Archived-At: Cc: William Denniss , Tokbind WG , Leif Johansson , "Hodges, Jeff" Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 13:46:16 -0000 --001a113f3a884cb257053839a8db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with William's characterization of this and think the guidance belongs in HTTPSTB. On Fri, Jul 22, 2016 at 3:41 PM, Andrei Popov wrote: > =C3=98 The language in this PR should probably be moved to the HTTPS dra= ft, > as it relates to how an HTTPS library would expose this functionality to > native apps (such as a browser). > > That would be an improvement over putting it in TBPROTO. > > > > *From:* William Denniss [mailto:wdenniss@google.com] > *Sent:* Friday, July 22, 2016 3:38 PM > *To:* Andrei Popov > *Cc:* Leif Johansson ; Hodges, Jeff < > jeff.hodges@paypal.com>; Tokbind WG > > *Subject:* Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api > guidance > > > > The HTTPS spec defines the header: "Sec-Token-Binding" which has options > for federated token binding. > > > > Apps that use HTTPS, which includes Browsers, and other Native apps need > to be able to send the Sec-Token-Binding header with a referred token > binding. That is, they need to be able to set the referred token binding > in the header. > > > > The language in this PR should probably be moved to the HTTPS draft, as i= t > relates to how an HTTPS library would expose this functionality to native > apps (such as a browser). > > > > > > > > On Fri, Jul 22, 2016 at 1:27 PM, Andrei Popov > wrote: > > To restate my position on this, it is great to have API guidance, but > TBPROTO is not the appropriate spec for it. TBPROTO describes the > fundamental message formats for every kind of application and architectur= e, > from self-contained apps to layered platforms. It's hard to come up with > specific API guidelines that are generally applicable. My vote is to > correct this text and put it in the OAUTHTB spec, which actually requires > these APIs. > > Here are the specific issues I have with the proposed text: > 1. =E2=80=9CIn addition to the functionality to use referred Token B= inding > IDs=E2=80=A6=E2=80=9D - the language focuses on the referred Token Bindin= gs, but actually > the application API would need to allow the use of any TB types (that the > implementer is willing to support and expose), and most certainly provide= d > ones. > 2. =E2=80=9CToken Binding implementations providing an Application > Programming Interface (API) should provide means for applications to > produce Token Binding messages containing Token Binding IDs for > application-specified TLS connections=E2=80=9D- e.g. in the IDP-first sce= narios, > the TLS connection to the RP does not exist at the time its TB ID is used > in TB messages. All the app can provide in this case is the target RP, or > the TB key that will be used with this RP. > 3. =E2=80=9CThe application needs to be able to denote the Token Bin= ding Type > (e.g., provided, referred, etc.) of each specified connection as well as > the TLS connection the application intends to send the Token Binding > message over=E2=80=9D =E2=80=93 the API could accept the =E2=80=9CTLS con= nection=E2=80=9D, or it could > accept the corresponding EKM value=E2=80=A6 in this low-level spec, we sh= ould not > prescribe one API design. However, in a higher-level spec, specific API > design may be welcome. Hence my preference that this would all be in > OAUTHTB. > 4. =E2=80=9CThe application needs to be able to denote the Token Bin= ding Type > (e.g., provided, referred, etc.) of each specified connection=E2=80=A6=E2= =80=9D =E2=80=93 I can't > parse this because there is no such thing as a "Token Binding Type of a T= LS > connection". > 5. =E2=80=9C=E2=80=A6 as well as the TLS connection the application = intends to send > the Token Binding message over=E2=80=9D =E2=80=93 same comment as ## 2 an= d 3 above. > 6. =E2=80=9CAdditionally, the use of Token Binding IDs for other tha= n the > provided Token Binding Type gives communicating parties infomation about > additional TLS connections of the application.=E2=80=9D =E2=80=93 apart f= rom the typo, this > is not the essence of the issue. The linkability issue exists when an app > is able to query TBs that other apps may be using (of any type: provided, > referred, ...) Such an app can correlate traffic. Further, depending on t= he > API, such an app may be able to determine what target servers have been > visited. > 7. =E2=80=9CHowever, if not, then there is potential for exposing ad= ditional > information and due caution should be exercised by the application=E2=80= =9D =E2=80=93 this > is not an actionable mitigation. Instead, this should be mitigated by > isolating keys, as described in section 8.4. =E2=80=9CToken Binding Key S= haring > Between Applications=E2=80=9D. > > Cheers, > > Andrei > > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif > Johansson > Sent: Friday, July 22, 2016 12:44 PM > To: Hodges, Jeff ; Tokbind WG > > Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api > guidance > > On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote: > > Mike and I have crafted proposed text to resolve #53 "add TB api > > guidance", as we agreed to do during the working group meeting on > > Tuesday. It comprises a new short "Implementation considerations" > > section and an additional paragraph in the Privacy Considerations > > section, addressing the request by Stephen Farrell. > > > > thoughts? > > > > thanks, HTH, > > > > =3DJeffH & Mike Jones > > > > > Thx for this. > > I'd like +1s or -1s (with some motivation preferably) from the WG! > > > _______________________________________________ > 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 > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --=20 [image: Ping Identity] Brian Campbell Distinguished Engineer bcampbell@pingidentity.com w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] --001a113f3a884cb257053839a8db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with William's characterization of this and th= ink the guidance belongs in HTTPSTB.
<= br>
On Fri, Jul 22, 2016 at 3:41 PM, Andrei Popov= <Andrei.Popov@microsoft.com> wrote:

=C3=98=C2=A0 Th= e language in this PR should probably be moved to the HTTPS draft, as it re= lates to how an HTTPS library would expose this functionality to native app= s (such as a browser).

That would be an improvement over putting it in TBP= ROTO.

<= u>=C2=A0

From: William Denniss [mailto:wdenniss@google.com]
Sent: Friday, July 22, 2016 3:38 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Leif Johansson <leifj@sunet.se>; Hodges, Jeff <jeff.hodges@paypal.com>; Tokbind WG= <unbearable@ie= tf.org>


Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/= api guidance

=C2=A0

The HTTPS spec defines the header: "Sec-Token-Binding" which has options= for federated token binding.

=C2=A0

Apps that use HTTPS, which includes Browsers, and ot= her Native apps need to be able to send the=C2=A0Sec-Token-Binding header with a referred token binding.= =C2=A0 That is, they need to be able to set the referred token binding in the header.

=C2=A0

The lan= guage in this PR should probably be moved to the HTTPS draft, as it relates= to how an HTTPS library would expose this functionality to native apps (su= ch as a browser).

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 22, 2016 at 1:27 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

To restate my position on this, it is great to have = API guidance, but TBPROTO is not the appropriate spec for it. TBPROTO descr= ibes the fundamental message formats for every kind of application and arch= itecture, from self-contained apps to layered platforms. It's hard to come up with specific API guideline= s that are generally applicable. My vote is to correct this text and put it= in the OAUTHTB spec, which actually requires these APIs.

Here are the specific issues I have with the proposed text:
1.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CIn addition to the functionality to use ref= erred Token Binding IDs=E2=80=A6=E2=80=9D - the language focuses on the ref= erred Token Bindings, but actually the application API would need to allow = the use of any TB types (that the implementer is willing to support and expose), and most certainly provided ones.
2.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CToken Binding implementations providing an = Application Programming Interface (API) should provide means for applicatio= ns to produce Token Binding messages containing Token Binding IDs for appli= cation-specified TLS connections=E2=80=9D- e.g. in the IDP-first scenarios, the TLS connection to the RP does not exist at the time its TB = ID is used in TB messages. All the app can provide in this case is the targ= et RP, or the TB key that will be used with this RP.
3.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CThe application needs to be able to denote = the Token Binding Type (e.g., provided, referred, etc.) of each specified c= onnection as well as the TLS connection the application intends to send the= Token Binding message over=E2=80=9D =E2=80=93 the API could accept the =E2=80=9CTLS connection=E2=80=9D, or it could accept the corresponding EKM= value=E2=80=A6 in this low-level spec, we should not prescribe one API des= ign. However, in a higher-level spec, specific API design may be welcome. H= ence my preference that this would all be in OAUTHTB.
4.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CThe application needs to be able to denote = the Token Binding Type (e.g., provided, referred, etc.) of each specified c= onnection=E2=80=A6=E2=80=9D =E2=80=93 I can't parse this because there = is no such thing as a "Token Binding Type of a TLS connection". 5.=C2=A0 =C2=A0 =C2=A0 =E2=80=9C=E2=80=A6 as well as the TLS connection the= application intends to send the Token Binding message over=E2=80=9D =E2=80= =93 same comment as ## 2 and 3 above.
6.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CAdditionally, the use of Token Binding IDs = for other than the provided Token Binding Type gives communicating parties = infomation about additional TLS connections of the application.=E2=80=9D = =E2=80=93 apart from the typo, this is not the essence of the issue. The linkability issue exists when an app is able to query TBs that other apps = may be using (of any type: provided, referred, ...) Such an app can correla= te traffic. Further, depending on the API, such an app may be able to deter= mine what target servers have been visited.
7.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CHowever, if not, then there is potential fo= r exposing additional information and due caution should be exercised by th= e application=E2=80=9D =E2=80=93 this is not an actionable mitigation. Inst= ead, this should be mitigated by isolating keys, as described in section 8.4. =E2=80=9CToken Binding Key Sharing Between Applications=E2=80=9D.

Cheers,

Andrei


-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif Johansson=
Sent: Friday, July 22, 2016 12:44 PM
To: Hodges, Jeff <jeff.hodges@paypal.com>; Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api gui= dance

On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote:
> Mike and I have crafted proposed text to resolve #53 "add TB api<= br> > guidance", as we agreed to do during the working group meeting on=
> Tuesday. =C2=A0 It comprises a new short "Implementation consider= ations"
> section and an additional paragraph in the Privacy Considerations
> section, addressing the request by Stephen Farrell.
>
> thoughts?
>
> thanks, HTH,
>
> =3DJeffH & Mike Jones
>


Thx for this.

I'd like +1s or -1s (with some motivation preferably) from the WG!


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

=C2=A0


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




--
=09
3D"Ping =09
= Distinguished Engineer
bcampbell@pingidentity.com
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: 3D"Glassdoor 3D"LinkedI= 3D"twitter 3D"face= =3D"youtube 3D"Google+ 3D"Blog =09
--001a113f3a884cb257053839a8db-- From nobody Fri Jul 22 09:03:31 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0789512D691 for ; Fri, 22 Jul 2016 09:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv8c9DXYcO-u for ; Fri, 22 Jul 2016 09:03:26 -0700 (PDT) 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 AF4C2128E18 for ; Fri, 22 Jul 2016 09:03:25 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id i5so72748799wmg.0 for ; Fri, 22 Jul 2016 09:03:25 -0700 (PDT) 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; bh=MVEFNd+75R0Gp1S1RAxDQlU1QnOakp6mwZSouespy+k=; b=RFDJyXRNEa5kScF9Yh8p1iP7CR71uYnk0eF6O+llfX671CoDkiDP89PwEJ4DkneLNb DsRdAMNIieRgtI1NHMeuEuwX65n4yVN+YQUEnVYmUhOMvY6Bo3JYwLgKdYJ+tA3qPTjU eCkAr5JjdtNGWN+Xz8OY0pwkuJ/Sk5xPWcoSrWO7OejynME28lLWMPlGUf/J7naaaZdx ERLjOmLHcxy5NxJAjeoiYl2YTHxRatNSJ/DLoDohilSJ3YB5dpkEngp3ON/40dif8xoO n2wO2TWFion6rU1k/vBD4XEHcz2s4O+Po9+usvOWwBUW6qp/o8wFQSFhgnl3DRMkPJzH Ou5Q== 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; bh=MVEFNd+75R0Gp1S1RAxDQlU1QnOakp6mwZSouespy+k=; b=V5eUS+/TWtsCgEzX4xwNsAx5oiv8h9IoYt9g/tV1yj8GGKnGdX0Bkd00Gji0flRfAQ 8hoXbN1XtPYbavsDJHrSpdXdsha19B0Qzuul552n5Rzaa/WLXNFm0tjefopwjP92RAHP rYgUjxq1ZbXOC1Czm4I+qjjJABqvZify7GSqsZtvDkf2VDDr6/0rT5MyX8Ngo4l69MeB iK/1DEiTiQPgV/+jaqqcoAG4WoWu162gHgl6tqmsGFwKDEDssQUv0R7LMknzs/U3LeXT N4TFeQO9bVJkkT+7rKjT2lKMdnZGJj+k+/r9liJYKoHCfSsSxlYWbjFoq7VT8BGMlMRB Crjg== X-Gm-Message-State: AEkoouuo0s68tNiW87k629bVOOUunwb83fn4Sm9XCNQRaoj27jbyNDJkxYizNfs8KQgDzPyQdi3b/UY2Sq809CkM X-Received: by 10.194.133.200 with SMTP id pe8mr1582488wjb.14.1469203404013; Fri, 22 Jul 2016 09:03:24 -0700 (PDT) MIME-Version: 1.0 References: <1469184250.12541.6.camel@sunet.se> In-Reply-To: From: Dirk Balfanz Date: Fri, 22 Jul 2016 16:03:11 +0000 Message-ID: To: William Denniss , Andrei Popov Content-Type: multipart/alternative; boundary=089e0117671f00375b05383b93d5 Archived-At: Cc: Tokbind WG , Leif Johansson , "Hodges, Jeff" Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 16:03:29 -0000 --089e0117671f00375b05383b93d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to the language in the PR (modulo some nits below). Thanks for doing this! But like William, I wonder whether this belongs in the HTTPS draft. It says that you're giving the API Considerations for apps that don't want to use HTTPS, but really I think what you're trying to say is that you're giving guidance for applications that use HTTPS, but that aren't browsers. After all, we haven't specified anywhere how you would transport a Token Binding message over anything other than HTTPS. If you insist on leaving it in this doc, I would change the language to something like: gives guidance to User Agents about the use of referred Token Binding IDs, but the ability to provide referred and other Token Binding Types is also intended to be made available to applications not using . What do you think? Dirk. On Fri, Jul 22, 2016 at 3:38 PM William Denniss wrote= : > The HTTPS spec defines the header: "Sec-Token-Binding" which has options > for federated token binding. > > Apps that use HTTPS, which includes Browsers, and other Native apps need > to be able to send the Sec-Token-Binding header with a referred token > binding. That is, they need to be able to set the referred token binding > in the header. > > The language in this PR should probably be moved to the HTTPS draft, as i= t > relates to how an HTTPS library would expose this functionality to native > apps (such as a browser). > > > > On Fri, Jul 22, 2016 at 1:27 PM, Andrei Popov > wrote: > >> To restate my position on this, it is great to have API guidance, but >> TBPROTO is not the appropriate spec for it. TBPROTO describes the >> fundamental message formats for every kind of application and architectu= re, >> from self-contained apps to layered platforms. It's hard to come up with >> specific API guidelines that are generally applicable. My vote is to >> correct this text and put it in the OAUTHTB spec, which actually require= s >> these APIs. >> >> Here are the specific issues I have with the proposed text: >> 1. =E2=80=9CIn addition to the functionality to use referred Token = Binding >> IDs=E2=80=A6=E2=80=9D - the language focuses on the referred Token Bindi= ngs, but actually >> the application API would need to allow the use of any TB types (that th= e >> implementer is willing to support and expose), and most certainly provid= ed >> ones. >> 2. =E2=80=9CToken Binding implementations providing an Application >> Programming Interface (API) should provide means for applications to >> produce Token Binding messages containing Token Binding IDs for >> application-specified TLS connections=E2=80=9D- e.g. in the IDP-first sc= enarios, >> the TLS connection to the RP does not exist at the time its TB ID is use= d >> in TB messages. All the app can provide in this case is the target RP, o= r >> the TB key that will be used with this RP. >> 3. =E2=80=9CThe application needs to be able to denote the Token Bi= nding >> Type (e.g., provided, referred, etc.) of each specified connection as we= ll >> as the TLS connection the application intends to send the Token Binding >> message over=E2=80=9D =E2=80=93 the API could accept the =E2=80=9CTLS co= nnection=E2=80=9D, or it could >> accept the corresponding EKM value=E2=80=A6 in this low-level spec, we s= hould not >> prescribe one API design. However, in a higher-level spec, specific API >> design may be welcome. Hence my preference that this would all be in >> OAUTHTB. >> 4. =E2=80=9CThe application needs to be able to denote the Token Bi= nding >> Type (e.g., provided, referred, etc.) of each specified connection=E2=80= =A6=E2=80=9D =E2=80=93 I >> can't parse this because there is no such thing as a "Token Binding Type= of >> a TLS connection". >> 5. =E2=80=9C=E2=80=A6 as well as the TLS connection the application= intends to send >> the Token Binding message over=E2=80=9D =E2=80=93 same comment as ## 2 a= nd 3 above. >> 6. =E2=80=9CAdditionally, the use of Token Binding IDs for other th= an the >> provided Token Binding Type gives communicating parties infomation about >> additional TLS connections of the application.=E2=80=9D =E2=80=93 apart = from the typo, this >> is not the essence of the issue. The linkability issue exists when an ap= p >> is able to query TBs that other apps may be using (of any type: provided= , >> referred, ...) Such an app can correlate traffic. Further, depending on = the >> API, such an app may be able to determine what target servers have been >> visited. >> 7. =E2=80=9CHowever, if not, then there is potential for exposing a= dditional >> information and due caution should be exercised by the application=E2=80= =9D =E2=80=93 this >> is not an actionable mitigation. Instead, this should be mitigated by >> isolating keys, as described in section 8.4. =E2=80=9CToken Binding Key = Sharing >> Between Applications=E2=80=9D. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif >> Johansson >> Sent: Friday, July 22, 2016 12:44 PM >> To: Hodges, Jeff ; Tokbind WG < >> unbearable@ietf.org> >> Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api >> guidance >> >> On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote: >> > Mike and I have crafted proposed text to resolve #53 "add TB api >> > guidance", as we agreed to do during the working group meeting on >> > Tuesday. It comprises a new short "Implementation considerations" >> > section and an additional paragraph in the Privacy Considerations >> > section, addressing the request by Stephen Farrell. >> > >> > thoughts? >> > >> > thanks, HTH, >> > >> > =3DJeffH & Mike Jones >> > >> >> >> Thx for this. >> >> I'd like +1s or -1s (with some motivation preferably) from the WG! >> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --089e0117671f00375b05383b93d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to the language in the PR (modulo some nits below). Tha= nks for doing this!

But like William, I wonder wheth= er this belongs in the HTTPS draft. It says that you're giving the API = Considerations for apps that don't want to use HTTPS, but really I thin= k what you're trying to say is that you're giving guidance for appl= ications that use HTTPS, but that aren't browsers. After all, we haven&= #39;t specified anywhere how you would transport a Token Binding message ov= er anything other than HTTPS.

If you insist on lea= ving it in this doc, I would change the language to something like:

=
<t><xref target=3D"I-D.ietf-tokbi= nd-https"/> gives guidance to User Agents about the use of=C2=A0r= eferred Token Binding IDs, but the
ability to provide referred and oth= er Token Binding Types is also intended to be made available to=C2=A0
applications not using <xref = target=3D"I-D.ietf-tokbind-https"/>.</t>
=
What do you think?<= /font>

Dirk.


O= n Fri, Jul 22, 2016 at 3:38 PM William Denniss <wdenniss@google.com> wrote:
The HTTPS spec defines the header: &qu= ot;Sec-Token-Binding&q= uot; which has options for federated token binding.

Apps that use HTTPS, which includes Browsers, and other Native app= s need to be able to send the=C2=A0Sec-Token-Binding header with a referred token binding.=C2=A0 = That is, they need to be able to set the referred token binding in the head= er.
<= br>
T= he language in this PR should probably be moved to the HTTPS draft, as it r= elates to how an HTTPS library would expose this functionality to native ap= ps (such as a browser).



On Fri, Jul 22, 2016= at 1:27 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
To restate my position on this= , it is great to have API guidance, but TBPROTO is not the appropriate spec= for it. TBPROTO describes the fundamental message formats for every kind o= f application and architecture, from self-contained apps to layered platfor= ms. It's hard to come up with specific API guidelines that are generall= y applicable. My vote is to correct this text and put it in the OAUTHTB spe= c, which actually requires these APIs.

Here are the specific issues I have with the proposed text:
1.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CIn addition to the functionality to use ref= erred Token Binding IDs=E2=80=A6=E2=80=9D - the language focuses on the ref= erred Token Bindings, but actually the application API would need to allow = the use of any TB types (that the implementer is willing to support and exp= ose), and most certainly provided ones.
2.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CToken Binding implementations providing an = Application Programming Interface (API) should provide means for applicatio= ns to produce Token Binding messages containing Token Binding IDs for appli= cation-specified TLS connections=E2=80=9D- e.g. in the IDP-first scenarios,= the TLS connection to the RP does not exist at the time its TB ID is used = in TB messages. All the app can provide in this case is the target RP, or t= he TB key that will be used with this RP.
3.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CThe application needs to be able to denote = the Token Binding Type (e.g., provided, referred, etc.) of each specified c= onnection as well as the TLS connection the application intends to send the= Token Binding message over=E2=80=9D =E2=80=93 the API could accept the =E2= =80=9CTLS connection=E2=80=9D, or it could accept the corresponding EKM val= ue=E2=80=A6 in this low-level spec, we should not prescribe one API design.= However, in a higher-level spec, specific API design may be welcome. Hence= my preference that this would all be in OAUTHTB.
4.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CThe application needs to be able to denote = the Token Binding Type (e.g., provided, referred, etc.) of each specified c= onnection=E2=80=A6=E2=80=9D =E2=80=93 I can't parse this because there = is no such thing as a "Token Binding Type of a TLS connection". 5.=C2=A0 =C2=A0 =C2=A0 =E2=80=9C=E2=80=A6 as well as the TLS connection the= application intends to send the Token Binding message over=E2=80=9D =E2=80= =93 same comment as ## 2 and 3 above.
6.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CAdditionally, the use of Token Binding IDs = for other than the provided Token Binding Type gives communicating parties = infomation about additional TLS connections of the application.=E2=80=9D = =E2=80=93 apart from the typo, this is not the essence of the issue. The li= nkability issue exists when an app is able to query TBs that other apps may= be using (of any type: provided, referred, ...) Such an app can correlate = traffic. Further, depending on the API, such an app may be able to determin= e what target servers have been visited.
7.=C2=A0 =C2=A0 =C2=A0 =E2=80=9CHowever, if not, then there is potential fo= r exposing additional information and due caution should be exercised by th= e application=E2=80=9D =E2=80=93 this is not an actionable mitigation. Inst= ead, this should be mitigated by isolating keys, as described in section 8.= 4. =E2=80=9CToken Binding Key Sharing Between Applications=E2=80=9D.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif Johansson=
Sent: Friday, July 22, 2016 12:44 PM
To: Hodges, Jeff <jeff.hodges@paypal.com>; Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api gui= dance

On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote:
> Mike and I have crafted proposed text to resolve #53 "add TB api<= br> > guidance", as we agreed to do during the working group meeting on=
> Tuesday. =C2=A0 It comprises a new short "Implementation consider= ations"
> section and an additional paragraph in the Privacy Considerations
> section, addressing the request by Stephen Farrell.
>
> thoughts?
>
> thanks, HTH,
>
> =3DJeffH & Mike Jones
>


Thx for this.

I'd like +1s or -1s (with some motivation preferably) from the WG!


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

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=
--089e0117671f00375b05383b93d5-- From nobody Fri Jul 22 09:25:32 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD912DDF8 for ; Fri, 22 Jul 2016 09:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3ufjB4nrEeZ for ; Fri, 22 Jul 2016 09:25:27 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0134.outbound.protection.outlook.com [104.47.38.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0755112DDF3 for ; Fri, 22 Jul 2016 09:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ASlDjUui3VVl9T1XhvyK7VsPuPL2j4WzQPPFr2NRlkk=; b=fixbrkjWTPlUpgAESSIVDfXuj96+1CO2JYtE1YTcoBT3XiCmYXeeB7KfbP8YG+altpEEIrSRP9p4MRZ5n8UBkVbii9nmmo6j/Z2CZ9wll6WTGOQIVdgyTHg9bUzUDmtETo+ZiUNPKFn3XyDyjlfaBuTOeae3rP4faA10MNScgS0= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by CO2PR03MB2152.namprd03.prod.outlook.com (10.166.92.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Fri, 22 Jul 2016 16:25:23 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0544.017; Fri, 22 Jul 2016 16:25:23 +0000 From: Mike Jones To: Dirk Balfanz , William Denniss , Andrei Popov Thread-Topic: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance Thread-Index: AQHR4/soxpW9I2zkUEKpK8sbSC1kuqAkQ/4AgAAHrgCAACjSgIAAKKKAgAAFHZA= Date: Fri, 22 Jul 2016 16:25:22 +0000 Message-ID: References: <1469184250.12541.6.camel@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [217.110.245.66] x-ms-office365-filtering-correlation-id: cbcbb1c3-d177-420e-cbfe-08d3b24cc7f6 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2152; 6:17Dtwr0V6sQcCHzepYaPDC10yHzXcR5bkEw8Q5kGMB+EqpVSxf7ogMFAojL0ZfD66A2jy/EZnZ2xLg4ROX7PNmAsb8Jn4xaRI0At+ofcTQGJb3YAaxngvMHkYTH5FmusAdM7oK+a/DFxXvc3QTJWOmb2ubixFkjk4lvj3icU85ysGRRZ5jWo//89Vcy18Kt/NJHUothJFJSfcmEQHv/tB4rfdFkA2RlL6s2FhH2obgQJspDCPRUa2FfiXGrTj45UlP2qAik8cOSwh7PKrMDvwccejgRQ4vOoctQ5Luz3yo5yLi1wP8ow4wRkT+CXN9IvnlzYFUx1ocsjH2sy9RffMw==; 5:o7lMBR84U75JJjXWDYxp6kweaDY8n+J9P9nZWP7w90abxwR56M1TBWkreeVrB4XHSAIEL3w+MoYzyr5pxsxdsrIl65/g0yln0t6Fibx8Zxofys54xiEurldLw1DtANRSYEJSvP2Ti9ZfYbAfV5ulgg==; 24:/LKuetwOK87JS8obQa4eQUOBJm6CJIpafxXguaLTnhQQPjEa7Ry4QCmqeclxuBE/27ZoxDmhmnN5k9bzpJquZOE5cUGA8VcHdAsVN9BWs4Q=; 7:fV0CW0Q0r5gcug6VLjlZjeJZ3x26M+XD31NKcSNTafd1toBdSGcMjiqup6FjsBiaBUiWA4pf/LiDRNHMwc8IBuQl2/Wu14Sew801AWPf3tc6FBrmJvet5TX/Pftxx7s7imQGnVF1C07UU7N5sNtW+dfMSKclv+0gRfeGSI8CUC43gY8Tb53TlW3ednA4cwWRNQu9Mv7a9Z2WqF878MFP2nDB4GwwwMfg0BGfvgM91K+q0aVn4qg3spNWcBNT63Gv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2152; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(252895345309445)(278428928389397)(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2152; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2152; x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(377424004)(13464003)(76104003)(199003)(189002)(86362001)(4001450100002)(87936001)(74316002)(19617315012)(5002640100001)(11100500001)(19625215002)(3846002)(102836003)(6116002)(77096005)(86612001)(81156014)(790700001)(81166006)(10290500002)(189998001)(15975445007)(4326007)(76576001)(7736002)(5003600100003)(7696003)(3280700002)(10400500002)(2906002)(19300405004)(2561002)(8936002)(5005710100001)(101416001)(7906003)(10090500001)(7846002)(97736004)(2421001)(33656002)(93886004)(3660700001)(92566002)(54356999)(68736007)(99286002)(8990500004)(2950100001)(2900100001)(106116001)(105586002)(1511001)(76176999)(106356001)(122556002)(9686002)(19580405001)(19580395003)(19609705001)(8676002)(5001770100001)(16236675004)(50986999)(66066001)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2152; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16450A87986DD9B61D71CD29F50A0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2016 16:25:22.8978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2152 Archived-At: Cc: Tokbind WG , Leif Johansson , "Hodges, Jeff" Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 16:25:30 -0000 --_000_SN1PR0301MB16450A87986DD9B61D71CD29F50A0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBBbmRyZWksIFdpbGxpYW0sIEJyaWFuLCBhbmQgRGlyay4gIFJlYWRpbmcgYWxsIG9m IHlvdXIgZmVlZGJhY2ssIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gbW92ZSB0aGUgZ3VpZGFu Y2UgdG8gdGhlIEhUVFBTIGRyYWZ0LiAgSeKAmWxsIHBsYW4gdG8gd29yayB3aXRoIEplZmYgdG8g cmV2aXNlIHRoZSBwdWxsIHJlcXVlc3QgYWNjb3JkaW5nbHkuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFVu YmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBEaXJrIEJhbGZhbnoNClNlbnQ6IEZyaWRheSwgSnVseSAyMiwgMjAxNiA2OjAzIFBNDQpUbzog V2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPjsgQW5kcmVpIFBvcG92IDxBbmRy ZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYu b3JnPjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPjsgSG9kZ2VzLCBKZWZmIDxqZWZm LmhvZGdlc0BwYXlwYWwuY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBQUiM1NDogVEJQ Uk9UTy0wOTogYWRkcmVzcyBpbXBsZW1lbnRhdGlvbi9hcGkgZ3VpZGFuY2UNCg0KKzEgdG8gdGhl IGxhbmd1YWdlIGluIHRoZSBQUiAobW9kdWxvIHNvbWUgbml0cyBiZWxvdykuIFRoYW5rcyBmb3Ig ZG9pbmcgdGhpcyENCg0KQnV0IGxpa2UgV2lsbGlhbSwgSSB3b25kZXIgd2hldGhlciB0aGlzIGJl bG9uZ3MgaW4gdGhlIEhUVFBTIGRyYWZ0LiBJdCBzYXlzIHRoYXQgeW91J3JlIGdpdmluZyB0aGUg QVBJIENvbnNpZGVyYXRpb25zIGZvciBhcHBzIHRoYXQgZG9uJ3Qgd2FudCB0byB1c2UgSFRUUFMs IGJ1dCByZWFsbHkgSSB0aGluayB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gc2F5IGlzIHRoYXQgeW91 J3JlIGdpdmluZyBndWlkYW5jZSBmb3IgYXBwbGljYXRpb25zIHRoYXQgdXNlIEhUVFBTLCBidXQg dGhhdCBhcmVuJ3QgYnJvd3NlcnMuIEFmdGVyIGFsbCwgd2UgaGF2ZW4ndCBzcGVjaWZpZWQgYW55 d2hlcmUgaG93IHlvdSB3b3VsZCB0cmFuc3BvcnQgYSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2Ugb3Zl ciBhbnl0aGluZyBvdGhlciB0aGFuIEhUVFBTLg0KDQpJZiB5b3UgaW5zaXN0IG9uIGxlYXZpbmcg aXQgaW4gdGhpcyBkb2MsIEkgd291bGQgY2hhbmdlIHRoZSBsYW5ndWFnZSB0byBzb21ldGhpbmcg bGlrZToNCg0KPHQ+PHhyZWYgdGFyZ2V0PSJJLUQuaWV0Zi10b2tiaW5kLWh0dHBzIi8+IGdpdmVz IGd1aWRhbmNlIHRvIFVzZXIgQWdlbnRzIGFib3V0IHRoZSB1c2Ugb2YgcmVmZXJyZWQgVG9rZW4g QmluZGluZyBJRHMsIGJ1dCB0aGUNCmFiaWxpdHkgdG8gcHJvdmlkZSByZWZlcnJlZCBhbmQgb3Ro ZXIgVG9rZW4gQmluZGluZyBUeXBlcyBpcyBhbHNvIGludGVuZGVkIHRvIGJlIG1hZGUgYXZhaWxh YmxlIHRvDQphcHBsaWNhdGlvbnMgbm90IHVzaW5nIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtdG9r YmluZC1odHRwcyIvPi48L3Q+DQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpEaXJrLg0KDQoNCk9u IEZyaSwgSnVsIDIyLCAyMDE2IGF0IDM6MzggUE0gV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bn b29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPj4gd3JvdGU6DQpUaGUgSFRUUFMg c3BlYyBkZWZpbmVzIHRoZSBoZWFkZXI6ICJTZWMtVG9rZW4tQmluZGluZyIgd2hpY2ggaGFzIG9w dGlvbnMgZm9yIGZlZGVyYXRlZCB0b2tlbiBiaW5kaW5nLg0KDQpBcHBzIHRoYXQgdXNlIEhUVFBT LCB3aGljaCBpbmNsdWRlcyBCcm93c2VycywgYW5kIG90aGVyIE5hdGl2ZSBhcHBzIG5lZWQgdG8g YmUgYWJsZSB0byBzZW5kIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgd2l0aCBhIHJlZmVy cmVkIHRva2VuIGJpbmRpbmcuICBUaGF0IGlzLCB0aGV5IG5lZWQgdG8gYmUgYWJsZSB0byBzZXQg dGhlIHJlZmVycmVkIHRva2VuIGJpbmRpbmcgaW4gdGhlIGhlYWRlci4NCg0KVGhlIGxhbmd1YWdl IGluIHRoaXMgUFIgc2hvdWxkIHByb2JhYmx5IGJlIG1vdmVkIHRvIHRoZSBIVFRQUyBkcmFmdCwg YXMgaXQgcmVsYXRlcyB0byBob3cgYW4gSFRUUFMgbGlicmFyeSB3b3VsZCBleHBvc2UgdGhpcyBm dW5jdGlvbmFsaXR5IHRvIG5hdGl2ZSBhcHBzIChzdWNoIGFzIGEgYnJvd3NlcikuDQoNCg0KDQpP biBGcmksIEp1bCAyMiwgMjAxNiBhdCAxOjI3IFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KVG8gcmVzdGF0ZSBteSBwb3NpdGlvbiBvbiB0aGlzLCBpdCBpcyBncmVhdCB0byBoYXZlIEFQ SSBndWlkYW5jZSwgYnV0IFRCUFJPVE8gaXMgbm90IHRoZSBhcHByb3ByaWF0ZSBzcGVjIGZvciBp dC4gVEJQUk9UTyBkZXNjcmliZXMgdGhlIGZ1bmRhbWVudGFsIG1lc3NhZ2UgZm9ybWF0cyBmb3Ig ZXZlcnkga2luZCBvZiBhcHBsaWNhdGlvbiBhbmQgYXJjaGl0ZWN0dXJlLCBmcm9tIHNlbGYtY29u dGFpbmVkIGFwcHMgdG8gbGF5ZXJlZCBwbGF0Zm9ybXMuIEl0J3MgaGFyZCB0byBjb21lIHVwIHdp dGggc3BlY2lmaWMgQVBJIGd1aWRlbGluZXMgdGhhdCBhcmUgZ2VuZXJhbGx5IGFwcGxpY2FibGUu IE15IHZvdGUgaXMgdG8gY29ycmVjdCB0aGlzIHRleHQgYW5kIHB1dCBpdCBpbiB0aGUgT0FVVEhU QiBzcGVjLCB3aGljaCBhY3R1YWxseSByZXF1aXJlcyB0aGVzZSBBUElzLg0KDQpIZXJlIGFyZSB0 aGUgc3BlY2lmaWMgaXNzdWVzIEkgaGF2ZSB3aXRoIHRoZSBwcm9wb3NlZCB0ZXh0Og0KMS4gICAg ICDigJxJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25hbGl0eSB0byB1c2UgcmVmZXJyZWQgVG9r ZW4gQmluZGluZyBJRHPigKbigJ0gLSB0aGUgbGFuZ3VhZ2UgZm9jdXNlcyBvbiB0aGUgcmVmZXJy ZWQgVG9rZW4gQmluZGluZ3MsIGJ1dCBhY3R1YWxseSB0aGUgYXBwbGljYXRpb24gQVBJIHdvdWxk IG5lZWQgdG8gYWxsb3cgdGhlIHVzZSBvZiBhbnkgVEIgdHlwZXMgKHRoYXQgdGhlIGltcGxlbWVu dGVyIGlzIHdpbGxpbmcgdG8gc3VwcG9ydCBhbmQgZXhwb3NlKSwgYW5kIG1vc3QgY2VydGFpbmx5 IHByb3ZpZGVkIG9uZXMuDQoyLiAgICAgIOKAnFRva2VuIEJpbmRpbmcgaW1wbGVtZW50YXRpb25z IHByb3ZpZGluZyBhbiBBcHBsaWNhdGlvbiBQcm9ncmFtbWluZyBJbnRlcmZhY2UgKEFQSSkgc2hv dWxkIHByb3ZpZGUgbWVhbnMgZm9yIGFwcGxpY2F0aW9ucyB0byBwcm9kdWNlIFRva2VuIEJpbmRp bmcgbWVzc2FnZXMgY29udGFpbmluZyBUb2tlbiBCaW5kaW5nIElEcyBmb3IgYXBwbGljYXRpb24t c3BlY2lmaWVkIFRMUyBjb25uZWN0aW9uc+KAnS0gZS5nLiBpbiB0aGUgSURQLWZpcnN0IHNjZW5h cmlvcywgdGhlIFRMUyBjb25uZWN0aW9uIHRvIHRoZSBSUCBkb2VzIG5vdCBleGlzdCBhdCB0aGUg dGltZSBpdHMgVEIgSUQgaXMgdXNlZCBpbiBUQiBtZXNzYWdlcy4gQWxsIHRoZSBhcHAgY2FuIHBy b3ZpZGUgaW4gdGhpcyBjYXNlIGlzIHRoZSB0YXJnZXQgUlAsIG9yIHRoZSBUQiBrZXkgdGhhdCB3 aWxsIGJlIHVzZWQgd2l0aCB0aGlzIFJQLg0KMy4gICAgICDigJxUaGUgYXBwbGljYXRpb24gbmVl ZHMgdG8gYmUgYWJsZSB0byBkZW5vdGUgdGhlIFRva2VuIEJpbmRpbmcgVHlwZSAoZS5nLiwgcHJv dmlkZWQsIHJlZmVycmVkLCBldGMuKSBvZiBlYWNoIHNwZWNpZmllZCBjb25uZWN0aW9uIGFzIHdl bGwgYXMgdGhlIFRMUyBjb25uZWN0aW9uIHRoZSBhcHBsaWNhdGlvbiBpbnRlbmRzIHRvIHNlbmQg dGhlIFRva2VuIEJpbmRpbmcgbWVzc2FnZSBvdmVy4oCdIOKAkyB0aGUgQVBJIGNvdWxkIGFjY2Vw dCB0aGUg4oCcVExTIGNvbm5lY3Rpb27igJ0sIG9yIGl0IGNvdWxkIGFjY2VwdCB0aGUgY29ycmVz cG9uZGluZyBFS00gdmFsdWXigKYgaW4gdGhpcyBsb3ctbGV2ZWwgc3BlYywgd2Ugc2hvdWxkIG5v dCBwcmVzY3JpYmUgb25lIEFQSSBkZXNpZ24uIEhvd2V2ZXIsIGluIGEgaGlnaGVyLWxldmVsIHNw ZWMsIHNwZWNpZmljIEFQSSBkZXNpZ24gbWF5IGJlIHdlbGNvbWUuIEhlbmNlIG15IHByZWZlcmVu Y2UgdGhhdCB0aGlzIHdvdWxkIGFsbCBiZSBpbiBPQVVUSFRCLg0KNC4gICAgICDigJxUaGUgYXBw bGljYXRpb24gbmVlZHMgdG8gYmUgYWJsZSB0byBkZW5vdGUgdGhlIFRva2VuIEJpbmRpbmcgVHlw ZSAoZS5nLiwgcHJvdmlkZWQsIHJlZmVycmVkLCBldGMuKSBvZiBlYWNoIHNwZWNpZmllZCBjb25u ZWN0aW9u4oCm4oCdIOKAkyBJIGNhbid0IHBhcnNlIHRoaXMgYmVjYXVzZSB0aGVyZSBpcyBubyBz dWNoIHRoaW5nIGFzIGEgIlRva2VuIEJpbmRpbmcgVHlwZSBvZiBhIFRMUyBjb25uZWN0aW9uIi4N CjUuICAgICAg4oCc4oCmIGFzIHdlbGwgYXMgdGhlIFRMUyBjb25uZWN0aW9uIHRoZSBhcHBsaWNh dGlvbiBpbnRlbmRzIHRvIHNlbmQgdGhlIFRva2VuIEJpbmRpbmcgbWVzc2FnZSBvdmVy4oCdIOKA kyBzYW1lIGNvbW1lbnQgYXMgIyMgMiBhbmQgMyBhYm92ZS4NCjYuICAgICAg4oCcQWRkaXRpb25h bGx5LCB0aGUgdXNlIG9mIFRva2VuIEJpbmRpbmcgSURzIGZvciBvdGhlciB0aGFuIHRoZSBwcm92 aWRlZCBUb2tlbiBCaW5kaW5nIFR5cGUgZ2l2ZXMgY29tbXVuaWNhdGluZyBwYXJ0aWVzIGluZm9t YXRpb24gYWJvdXQgYWRkaXRpb25hbCBUTFMgY29ubmVjdGlvbnMgb2YgdGhlIGFwcGxpY2F0aW9u LuKAnSDigJMgYXBhcnQgZnJvbSB0aGUgdHlwbywgdGhpcyBpcyBub3QgdGhlIGVzc2VuY2Ugb2Yg dGhlIGlzc3VlLiBUaGUgbGlua2FiaWxpdHkgaXNzdWUgZXhpc3RzIHdoZW4gYW4gYXBwIGlzIGFi bGUgdG8gcXVlcnkgVEJzIHRoYXQgb3RoZXIgYXBwcyBtYXkgYmUgdXNpbmcgKG9mIGFueSB0eXBl OiBwcm92aWRlZCwgcmVmZXJyZWQsIC4uLikgU3VjaCBhbiBhcHAgY2FuIGNvcnJlbGF0ZSB0cmFm ZmljLiBGdXJ0aGVyLCBkZXBlbmRpbmcgb24gdGhlIEFQSSwgc3VjaCBhbiBhcHAgbWF5IGJlIGFi bGUgdG8gZGV0ZXJtaW5lIHdoYXQgdGFyZ2V0IHNlcnZlcnMgaGF2ZSBiZWVuIHZpc2l0ZWQuDQo3 LiAgICAgIOKAnEhvd2V2ZXIsIGlmIG5vdCwgdGhlbiB0aGVyZSBpcyBwb3RlbnRpYWwgZm9yIGV4 cG9zaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYW5kIGR1ZSBjYXV0aW9uIHNob3VsZCBiZSBl eGVyY2lzZWQgYnkgdGhlIGFwcGxpY2F0aW9u4oCdIOKAkyB0aGlzIGlzIG5vdCBhbiBhY3Rpb25h YmxlIG1pdGlnYXRpb24uIEluc3RlYWQsIHRoaXMgc2hvdWxkIGJlIG1pdGlnYXRlZCBieSBpc29s YXRpbmcga2V5cywgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gOC40LiDigJxUb2tlbiBCaW5kaW5n IEtleSBTaGFyaW5nIEJldHdlZW4gQXBwbGljYXRpb25z4oCdLg0KDQpDaGVlcnMsDQoNCkFuZHJl aQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRv OnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIExlaWYgSm9oYW5zc29uDQpTZW50OiBGcmlkYXksIEp1bHkg MjIsIDIwMTYgMTI6NDQgUE0NClRvOiBIb2RnZXMsIEplZmYgPGplZmYuaG9kZ2VzQHBheXBhbC5j b208bWFpbHRvOmplZmYuaG9kZ2VzQHBheXBhbC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJs ZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1Vu YmVhcmFibGVdIFBSIzU0OiBUQlBST1RPLTA5OiBhZGRyZXNzIGltcGxlbWVudGF0aW9uL2FwaSBn dWlkYW5jZQ0KDQpPbiBmcmUsIDIwMTYtMDctMjIgYXQgMDk6MjYgKzAwMDAsIEhvZGdlcywgSmVm ZiB3cm90ZToNCj4gTWlrZSBhbmQgSSBoYXZlIGNyYWZ0ZWQgcHJvcG9zZWQgdGV4dCB0byByZXNv bHZlICM1MyAiYWRkIFRCIGFwaQ0KPiBndWlkYW5jZSIsIGFzIHdlIGFncmVlZCB0byBkbyBkdXJp bmcgdGhlIHdvcmtpbmcgZ3JvdXAgbWVldGluZyBvbg0KPiBUdWVzZGF5LiAgIEl0IGNvbXByaXNl cyBhIG5ldyBzaG9ydCAiSW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbnMiDQo+IHNlY3Rpb24g YW5kIGFuIGFkZGl0aW9uYWwgcGFyYWdyYXBoIGluIHRoZSBQcml2YWN5IENvbnNpZGVyYXRpb25z DQo+IHNlY3Rpb24sIGFkZHJlc3NpbmcgdGhlIHJlcXVlc3QgYnkgU3RlcGhlbiBGYXJyZWxsLg0K Pg0KPiB0aG91Z2h0cz8NCj4NCj4gdGhhbmtzLCBIVEgsDQo+DQo+ID1KZWZmSCAmIE1pa2UgSm9u ZXMNCj4NCg0KDQpUaHggZm9yIHRoaXMuDQoNCkknZCBsaWtlICsxcyBvciAtMXMgKHdpdGggc29t ZSBtb3RpdmF0aW9uIHByZWZlcmFibHkpIGZyb20gdGhlIFdHIQ0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlz dA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBs aXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxp bmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0K --_000_SN1PR0301MB16450A87986DD9B61D71CD29F50A0SN1PR0301MB1645_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzLCBBbmRyZWksIFdpbGxpYW0s IEJyaWFuLCBhbmQgRGlyay4mbmJzcDsgUmVhZGluZyBhbGwgb2YgeW91ciBmZWVkYmFjaywgSSB0 aGluayBpdCBtYWtlcyBzZW5zZSB0byBtb3ZlIHRoZSBndWlkYW5jZSB0byB0aGUgSFRUUFMgZHJh ZnQuJm5ic3A7IEnigJlsbCBwbGFuIHRvIHdvcmsgd2l0aA0KIEplZmYgdG8gcmV2aXNlIHRoZSBw dWxsIHJlcXVlc3QgYWNjb3JkaW5nbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k Q29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVu YmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGlyayBCYWxm YW56PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMiwgMjAxNiA2OjAzIFBNPGJyPg0K PGI+VG86PC9iPiBXaWxsaWFtIERlbm5pc3MgJmx0O3dkZW5uaXNzQGdvb2dsZS5jb20mZ3Q7OyBB bmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs7IExlaWYgSm9oYW5z c29uICZsdDtsZWlmakBzdW5ldC5zZSZndDs7IEhvZGdlcywgSmVmZiAmbHQ7amVmZi5ob2RnZXNA cGF5cGFsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBQUiM1 NDogVEJQUk9UTy0wOTogYWRkcmVzcyBpbXBsZW1lbnRhdGlvbi9hcGkgZ3VpZGFuY2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgdG8gdGhlIGxhbmd1YWdlIGlu IHRoZSBQUiAobW9kdWxvIHNvbWUgbml0cyBiZWxvdykuIFRoYW5rcyBmb3IgZG9pbmcgdGhpcyE8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBsaWtlIFdp bGxpYW0sIEkgd29uZGVyIHdoZXRoZXIgdGhpcyBiZWxvbmdzIGluIHRoZSBIVFRQUyBkcmFmdC4g SXQgc2F5cyB0aGF0IHlvdSdyZSBnaXZpbmcgdGhlIEFQSSBDb25zaWRlcmF0aW9ucyBmb3IgYXBw cyB0aGF0IGRvbid0IHdhbnQgdG8gdXNlIEhUVFBTLCBidXQgcmVhbGx5IEkgdGhpbmsgd2hhdCB5 b3UncmUgdHJ5aW5nIHRvIHNheSBpcyB0aGF0IHlvdSdyZSBnaXZpbmcgZ3VpZGFuY2UgZm9yDQog YXBwbGljYXRpb25zIHRoYXQgdXNlIEhUVFBTLCBidXQgdGhhdCBhcmVuJ3QgYnJvd3NlcnMuIEFm dGVyIGFsbCwgd2UgaGF2ZW4ndCBzcGVjaWZpZWQgYW55d2hlcmUgaG93IHlvdSB3b3VsZCB0cmFu c3BvcnQgYSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2Ugb3ZlciBhbnl0aGluZyBvdGhlciB0aGFuIEhU VFBTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB5b3UgaW5zaXN0IG9uIGxlYXZpbmcgaXQgaW4gdGhpcyBkb2MsIEkgd291bGQgY2hhbmdl IHRoZSBsYW5ndWFnZSB0byBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZsdDt0Jmd0Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZsdDt4cmVm IHRhcmdldD0mcXVvdDtJLUQuaWV0Zi10b2tiaW5kLWh0dHBzJnF1b3Q7LyZndDsgZ2l2ZXMgZ3Vp ZGFuY2UgdG8gVXNlciBBZ2VudHMgYWJvdXQgdGhlIHVzZSBvZiZuYnNwO3JlZmVycmVkIFRva2Vu IEJpbmRpbmcgSURzLCBidXQgdGhlPGJyPg0KYWJpbGl0eSB0byBwcm92aWRlIHJlZmVycmVkIGFu ZCBvdGhlciBUb2tlbiBCaW5kaW5nIFR5cGVzIGlzIGFsc28gaW50ZW5kZWQgdG8gYmUgbWFkZSBh dmFpbGFibGUgdG8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hcHBsaWNhdGlvbnMgbm90IHVzaW5nICZsdDt4cmVmIHRh cmdldD0mcXVvdDtJLUQuaWV0Zi10b2tiaW5kLWh0dHBzJnF1b3Q7LyZndDsuJmx0Oy90Jmd0Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5XaGF0IGRvIHlvdSB0aGluaz88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KRGlyay48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdWwgMjIsIDIw MTYgYXQgMzozOCBQTSBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZGVubmlz c0Bnb29nbGUuY29tIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBIVFRQUyBzcGVjIGRlZmluZXMgdGhlIGhlYWRlcjogJnF1b3Q7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlNlYy1Ub2tlbi1CaW5kaW5nJnF1b3Q7 IHdoaWNoIGhhcyBvcHRpb25zIGZvciBmZWRlcmF0ZWQgdG9rZW4gYmluZGluZy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFwcHMg dGhhdCB1c2UgSFRUUFMsIHdoaWNoIGluY2x1ZGVzIEJyb3dzZXJzLCBhbmQgb3RoZXIgTmF0aXZl IGFwcHMgbmVlZCB0byBiZSBhYmxlIHRvIHNlbmQgdGhlJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB3aXRoIGEg cmVmZXJyZWQgdG9rZW4gYmluZGluZy4mbmJzcDsgVGhhdCBpcywgdGhleSBuZWVkIHRvIGJlIGFi bGUgdG8gc2V0IHRoZQ0KIHJlZmVycmVkIHRva2VuIGJpbmRpbmcgaW4gdGhlIGhlYWRlci48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5UaGUgbGFuZ3VhZ2Ug aW4gdGhpcyBQUiBzaG91bGQgcHJvYmFibHkgYmUgbW92ZWQgdG8gdGhlIEhUVFBTIGRyYWZ0LCBh cyBpdCByZWxhdGVzIHRvIGhvdyBhbiBIVFRQUyBsaWJyYXJ5IHdvdWxkIGV4cG9zZSB0aGlzIGZ1 bmN0aW9uYWxpdHkgdG8gbmF0aXZlIGFwcHMgKHN1Y2ggYXMgYSBicm93c2VyKS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBGcmksIEp1bCAyMiwgMjAxNiBhdCAxOjI3IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9 Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gcmVzdGF0ZSBteSBwb3NpdGlvbiBvbiB0 aGlzLCBpdCBpcyBncmVhdCB0byBoYXZlIEFQSSBndWlkYW5jZSwgYnV0IFRCUFJPVE8gaXMgbm90 IHRoZSBhcHByb3ByaWF0ZSBzcGVjIGZvciBpdC4gVEJQUk9UTyBkZXNjcmliZXMgdGhlIGZ1bmRh bWVudGFsIG1lc3NhZ2UgZm9ybWF0cyBmb3IgZXZlcnkga2luZCBvZiBhcHBsaWNhdGlvbiBhbmQg YXJjaGl0ZWN0dXJlLCBmcm9tIHNlbGYtY29udGFpbmVkIGFwcHMNCiB0byBsYXllcmVkIHBsYXRm b3Jtcy4gSXQncyBoYXJkIHRvIGNvbWUgdXAgd2l0aCBzcGVjaWZpYyBBUEkgZ3VpZGVsaW5lcyB0 aGF0IGFyZSBnZW5lcmFsbHkgYXBwbGljYWJsZS4gTXkgdm90ZSBpcyB0byBjb3JyZWN0IHRoaXMg dGV4dCBhbmQgcHV0IGl0IGluIHRoZSBPQVVUSFRCIHNwZWMsIHdoaWNoIGFjdHVhbGx5IHJlcXVp cmVzIHRoZXNlIEFQSXMuPGJyPg0KPGJyPg0KSGVyZSBhcmUgdGhlIHNwZWNpZmljIGlzc3VlcyBJ IGhhdmUgd2l0aCB0aGUgcHJvcG9zZWQgdGV4dDo8YnI+DQoxLiZuYnNwOyAmbmJzcDsgJm5ic3A7 IOKAnEluIGFkZGl0aW9uIHRvIHRoZSBmdW5jdGlvbmFsaXR5IHRvIHVzZSByZWZlcnJlZCBUb2tl biBCaW5kaW5nIElEc+KApuKAnSAtIHRoZSBsYW5ndWFnZSBmb2N1c2VzIG9uIHRoZSByZWZlcnJl ZCBUb2tlbiBCaW5kaW5ncywgYnV0IGFjdHVhbGx5IHRoZSBhcHBsaWNhdGlvbiBBUEkgd291bGQg bmVlZCB0byBhbGxvdyB0aGUgdXNlIG9mIGFueSBUQiB0eXBlcyAodGhhdCB0aGUgaW1wbGVtZW50 ZXIgaXMgd2lsbGluZyB0byBzdXBwb3J0IGFuZA0KIGV4cG9zZSksIGFuZCBtb3N0IGNlcnRhaW5s eSBwcm92aWRlZCBvbmVzLjxicj4NCjIuJm5ic3A7ICZuYnNwOyAmbmJzcDsg4oCcVG9rZW4gQmlu ZGluZyBpbXBsZW1lbnRhdGlvbnMgcHJvdmlkaW5nIGFuIEFwcGxpY2F0aW9uIFByb2dyYW1taW5n IEludGVyZmFjZSAoQVBJKSBzaG91bGQgcHJvdmlkZSBtZWFucyBmb3IgYXBwbGljYXRpb25zIHRv IHByb2R1Y2UgVG9rZW4gQmluZGluZyBtZXNzYWdlcyBjb250YWluaW5nIFRva2VuIEJpbmRpbmcg SURzIGZvciBhcHBsaWNhdGlvbi1zcGVjaWZpZWQgVExTIGNvbm5lY3Rpb25z4oCdLSBlLmcuIGlu IHRoZSBJRFAtZmlyc3QNCiBzY2VuYXJpb3MsIHRoZSBUTFMgY29ubmVjdGlvbiB0byB0aGUgUlAg ZG9lcyBub3QgZXhpc3QgYXQgdGhlIHRpbWUgaXRzIFRCIElEIGlzIHVzZWQgaW4gVEIgbWVzc2Fn ZXMuIEFsbCB0aGUgYXBwIGNhbiBwcm92aWRlIGluIHRoaXMgY2FzZSBpcyB0aGUgdGFyZ2V0IFJQ LCBvciB0aGUgVEIga2V5IHRoYXQgd2lsbCBiZSB1c2VkIHdpdGggdGhpcyBSUC48YnI+DQozLiZu YnNwOyAmbmJzcDsgJm5ic3A7IOKAnFRoZSBhcHBsaWNhdGlvbiBuZWVkcyB0byBiZSBhYmxlIHRv IGRlbm90ZSB0aGUgVG9rZW4gQmluZGluZyBUeXBlIChlLmcuLCBwcm92aWRlZCwgcmVmZXJyZWQs IGV0Yy4pIG9mIGVhY2ggc3BlY2lmaWVkIGNvbm5lY3Rpb24gYXMgd2VsbCBhcyB0aGUgVExTIGNv bm5lY3Rpb24gdGhlIGFwcGxpY2F0aW9uIGludGVuZHMgdG8gc2VuZCB0aGUgVG9rZW4gQmluZGlu ZyBtZXNzYWdlIG92ZXLigJ0g4oCTIHRoZSBBUEkgY291bGQgYWNjZXB0IHRoZQ0KIOKAnFRMUyBj b25uZWN0aW9u4oCdLCBvciBpdCBjb3VsZCBhY2NlcHQgdGhlIGNvcnJlc3BvbmRpbmcgRUtNIHZh bHVl4oCmIGluIHRoaXMgbG93LWxldmVsIHNwZWMsIHdlIHNob3VsZCBub3QgcHJlc2NyaWJlIG9u ZSBBUEkgZGVzaWduLiBIb3dldmVyLCBpbiBhIGhpZ2hlci1sZXZlbCBzcGVjLCBzcGVjaWZpYyBB UEkgZGVzaWduIG1heSBiZSB3ZWxjb21lLiBIZW5jZSBteSBwcmVmZXJlbmNlIHRoYXQgdGhpcyB3 b3VsZCBhbGwgYmUgaW4gT0FVVEhUQi48YnI+DQo0LiZuYnNwOyAmbmJzcDsgJm5ic3A7IOKAnFRo ZSBhcHBsaWNhdGlvbiBuZWVkcyB0byBiZSBhYmxlIHRvIGRlbm90ZSB0aGUgVG9rZW4gQmluZGlu ZyBUeXBlIChlLmcuLCBwcm92aWRlZCwgcmVmZXJyZWQsIGV0Yy4pIG9mIGVhY2ggc3BlY2lmaWVk IGNvbm5lY3Rpb27igKbigJ0g4oCTIEkgY2FuJ3QgcGFyc2UgdGhpcyBiZWNhdXNlIHRoZXJlIGlz IG5vIHN1Y2ggdGhpbmcgYXMgYSAmcXVvdDtUb2tlbiBCaW5kaW5nIFR5cGUgb2YgYSBUTFMgY29u bmVjdGlvbiZxdW90Oy48YnI+DQo1LiZuYnNwOyAmbmJzcDsgJm5ic3A7IOKAnOKApiBhcyB3ZWxs IGFzIHRoZSBUTFMgY29ubmVjdGlvbiB0aGUgYXBwbGljYXRpb24gaW50ZW5kcyB0byBzZW5kIHRo ZSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2Ugb3ZlcuKAnSDigJMgc2FtZSBjb21tZW50IGFzICMjIDIg YW5kIDMgYWJvdmUuPGJyPg0KNi4mbmJzcDsgJm5ic3A7ICZuYnNwOyDigJxBZGRpdGlvbmFsbHks IHRoZSB1c2Ugb2YgVG9rZW4gQmluZGluZyBJRHMgZm9yIG90aGVyIHRoYW4gdGhlIHByb3ZpZGVk IFRva2VuIEJpbmRpbmcgVHlwZSBnaXZlcyBjb21tdW5pY2F0aW5nIHBhcnRpZXMgaW5mb21hdGlv biBhYm91dCBhZGRpdGlvbmFsIFRMUyBjb25uZWN0aW9ucyBvZiB0aGUgYXBwbGljYXRpb24u4oCd IOKAkyBhcGFydCBmcm9tIHRoZSB0eXBvLCB0aGlzIGlzIG5vdCB0aGUgZXNzZW5jZSBvZiB0aGUg aXNzdWUuIFRoZQ0KIGxpbmthYmlsaXR5IGlzc3VlIGV4aXN0cyB3aGVuIGFuIGFwcCBpcyBhYmxl IHRvIHF1ZXJ5IFRCcyB0aGF0IG90aGVyIGFwcHMgbWF5IGJlIHVzaW5nIChvZiBhbnkgdHlwZTog cHJvdmlkZWQsIHJlZmVycmVkLCAuLi4pIFN1Y2ggYW4gYXBwIGNhbiBjb3JyZWxhdGUgdHJhZmZp Yy4gRnVydGhlciwgZGVwZW5kaW5nIG9uIHRoZSBBUEksIHN1Y2ggYW4gYXBwIG1heSBiZSBhYmxl IHRvIGRldGVybWluZSB3aGF0IHRhcmdldCBzZXJ2ZXJzIGhhdmUgYmVlbg0KIHZpc2l0ZWQuPGJy Pg0KNy4mbmJzcDsgJm5ic3A7ICZuYnNwOyDigJxIb3dldmVyLCBpZiBub3QsIHRoZW4gdGhlcmUg aXMgcG90ZW50aWFsIGZvciBleHBvc2luZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFuZCBkdWUg Y2F1dGlvbiBzaG91bGQgYmUgZXhlcmNpc2VkIGJ5IHRoZSBhcHBsaWNhdGlvbuKAnSDigJMgdGhp cyBpcyBub3QgYW4gYWN0aW9uYWJsZSBtaXRpZ2F0aW9uLiBJbnN0ZWFkLCB0aGlzIHNob3VsZCBi ZSBtaXRpZ2F0ZWQgYnkgaXNvbGF0aW5nIGtleXMsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uDQog OC40LiDigJxUb2tlbiBCaW5kaW5nIEtleSBTaGFyaW5nIEJldHdlZW4gQXBwbGljYXRpb25z4oCd Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+DQpBbmRyZWk8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVu YmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGUtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBMZWlmIEpvaGFuc3Nvbjxicj4NClNlbnQ6 IEZyaWRheSwgSnVseSAyMiwgMjAxNiAxMjo0NCBQTTxicj4NClRvOiBIb2RnZXMsIEplZmYgJmx0 OzxhIGhyZWY9Im1haWx0bzpqZWZmLmhvZGdlc0BwYXlwYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ amVmZi5ob2RnZXNAcGF5cGFsLmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdHICZsdDs8YSBocmVmPSJt YWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGVAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gUFIjNTQ6IFRCUFJP VE8tMDk6IGFkZHJlc3MgaW1wbGVtZW50YXRpb24vYXBpIGd1aWRhbmNlPGJyPg0KPGJyPg0KT24g ZnJlLCAyMDE2LTA3LTIyIGF0IDA5OjI2ICYjNDM7MDAwMCwgSG9kZ2VzLCBKZWZmIHdyb3RlOjxi cj4NCiZndDsgTWlrZSBhbmQgSSBoYXZlIGNyYWZ0ZWQgcHJvcG9zZWQgdGV4dCB0byByZXNvbHZl ICM1MyAmcXVvdDthZGQgVEIgYXBpPGJyPg0KJmd0OyBndWlkYW5jZSZxdW90OywgYXMgd2UgYWdy ZWVkIHRvIGRvIGR1cmluZyB0aGUgd29ya2luZyBncm91cCBtZWV0aW5nIG9uPGJyPg0KJmd0OyBU dWVzZGF5LiAmbmJzcDsgSXQgY29tcHJpc2VzIGEgbmV3IHNob3J0ICZxdW90O0ltcGxlbWVudGF0 aW9uIGNvbnNpZGVyYXRpb25zJnF1b3Q7PGJyPg0KJmd0OyBzZWN0aW9uIGFuZCBhbiBhZGRpdGlv bmFsIHBhcmFncmFwaCBpbiB0aGUgUHJpdmFjeSBDb25zaWRlcmF0aW9uczxicj4NCiZndDsgc2Vj dGlvbiwgYWRkcmVzc2luZyB0aGUgcmVxdWVzdCBieSBTdGVwaGVuIEZhcnJlbGwuPGJyPg0KJmd0 Ozxicj4NCiZndDsgdGhvdWdodHM/PGJyPg0KJmd0Ozxicj4NCiZndDsgdGhhbmtzLCBIVEgsPGJy Pg0KJmd0Ozxicj4NCiZndDsgPUplZmZIICZhbXA7IE1pa2UgSm9uZXM8YnI+DQomZ3Q7PGJyPg0K PGJyPg0KPGJyPg0KVGh4IGZvciB0aGlzLjxicj4NCjxicj4NCkknZCBsaWtlICYjNDM7MXMgb3Ig LTFzICh3aXRoIHNvbWUgbW90aXZhdGlvbiBwcmVmZXJhYmx5KSBmcm9tIHRoZSBXRyE8YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVh cmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdW5iZWFyYWJsZTwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_SN1PR0301MB16450A87986DD9B61D71CD29F50A0SN1PR0301MB1645_-- From nobody Fri Jul 22 11:26:25 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3AC12DBDC for ; Fri, 22 Jul 2016 02:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czXCowZL3BC8 for ; Fri, 22 Jul 2016 02:22:08 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433F212D1D8 for ; Fri, 22 Jul 2016 02:22:08 -0700 (PDT) Date: Fri, 22 Jul 2016 02:22:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1469179325; bh=sYSrJ9i8ATX+uose5oHaiJrRJha7sCDIqU9a7aLchRE=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=iqoeU1equzAgfPOESw27kvhFx2ygzAjpb/VjFdmsn/RAg9AUlZYAH4qz2LHJfmZ5r okJmEc4VazwKETmMP16yIBbojIjLWesJ3TD0dVCBOjYSyiV6sewrnsTX3sSnModv3e 8i0IvClwWg6Bi/9MLd0JutSycJ25HImLTGt6BNWY= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5791e5bd17a1f_53f43fde6385b2a07207ab"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Fri, 22 Jul 2016 11:26:24 -0700 Subject: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implmentation/api guidance (#54) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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, 22 Jul 2016 09:22:10 -0000 ----==_mimepart_5791e5bd17a1f_53f43fde6385b2a07207ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mike and I have crafted proposed text to resolve #53 "add TB api guidance". it comprises a new "Implementation considerations" section and an additional paragraph in the Privacy Considerations section. You can view, comment on, or merge this pull request online at: https://github.com/TokenBinding/Internet-Drafts/pull/54 -- Commit Summary -- * initiate TBPROTO -09 rev * add impl cons and additional priv cons * add line breaks * Update draft-ietf-tokbind-protocol-09.xml -- File Changes -- R draft-ietf-tokbind-protocol-09.xml (34) -- Patch Links -- https://github.com/TokenBinding/Internet-Drafts/pull/54.patch https://github.com/TokenBinding/Internet-Drafts/pull/54.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/54 ----==_mimepart_5791e5bd17a1f_53f43fde6385b2a07207ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Mike and I have crafted proposed text to resolve #53 "add TB api guidance". it comprises a new "Implementation considerations" section and an additional paragraph in the Privacy Considerations section.

You can view, comment on, or merge this pull request online at:

  https://github.com/TokenBinding/Internet-Drafts/pull/54

Commit Summary

  • initiate TBPROTO -09 rev
  • add impl cons and additional priv cons
  • add line breaks
  • Update draft-ietf-tokbind-protocol-09.xml

File Changes

Patch Links:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5791e5bd17a1f_53f43fde6385b2a07207ab-- From nobody Sat Jul 23 01:54:45 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7012D133 for ; Sat, 23 Jul 2016 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeTOpbiqmBaF for ; Sat, 23 Jul 2016 01:54:42 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id E541612B056 for ; Sat, 23 Jul 2016 01:54:41 -0700 (PDT) Received: (qmail 29872 invoked by uid 0); 23 Jul 2016 08:54:40 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 23 Jul 2016 08:54:40 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id N8uW1t0052UhLwi018uZWF; Sat, 23 Jul 2016 02:54:38 -0600 X-Authority-Analysis: v=2.1 cv=KaJB72oD 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=cAmyUtKerLwA:10 a=yMhMjlubAAAA:8 a=vpeElGJGLTaRPczRExoA:9 a=QEXdDO2ut3YA:10 a=u2M28iEEeCwA:10 a=BKKCjISod1eDJeS0ORpz:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:MIME-Version: Content-Type:In-Reply-To:References:Subject:Cc:To:From:Message-ID:Date; bh=E4WXvlUjd6JC6QPgJbTRpDGr5RQyRf33Wt7rSQxwB/8=; b=icymwT9owbAoMgxn82uK8VeoXQ miOElCCM/pybCaLtJqGPiZf7aSoc/1x0Svef0icT8Ii8L4wtHDv6b82GiAeeYUCU2B+lux/7bWabg ly3TALTUJDoTTkctsl3EIzCMG; Received: from [127.0.0.1] (port=54460 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bQshb-0006rc-T2; Sat, 23 Jul 2016 02:54:31 -0600 Received: from 85.177.85.233 ([85.177.85.233]) by box514.bluehost.com (Horde Framework) with HTTP; Sat, 23 Jul 2016 02:54:26 -0600 Date: Sat, 23 Jul 2016 02:54:26 -0600 Message-ID: <20160723025426.Horde.0-CtvWrQbaSTWepGIJFKnTq@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Mike Jones References: <1469184250.12541.6.camel@sunet.se> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bQshb-0006rc-T2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:54460 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: William Denniss , Andrei Popov , Dirk Balfanz , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 08:54:43 -0000 Quoting Mike Jones : > Thanks, Andrei, William, Brian, and Dirk. Reading all of your > feedback, I think it makes sense to move the guidance to the HTTPS > draft. I’ll plan to work with Jeff to revise the pull request > accordingly. Yep, works for me. =JeffH From nobody Mon Jul 25 09:30:51 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E9812D0D8 for ; Sat, 23 Jul 2016 12:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc2KSGUmcpdn for ; Sat, 23 Jul 2016 12:56:56 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFB712B00B for ; Sat, 23 Jul 2016 12:56:56 -0700 (PDT) Date: Sat, 23 Jul 2016 12:56:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1469303815; bh=aPQCGYwwG02Nhu+X41p6/nfHrSfvush9tire9+97I60=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GsI9i3iSgSF/AGSiVfdX3SLqHxQuTo8L8zYEZFw+xSPkR/RID9vVrx9c62VegLNVB iLWnhg/xn2MymOfRwnz/tg2C+5OsEQ4S+ZW7LRD/NT8J9XNn7WKMfiTy8TOLd+3lFf OQUQfnvTw16CZos9fCD4OEGtl3/vKou/VrEHaOw8= From: Mike Jones To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5793cc073c5b0_2c313fbc2afe72b821543b"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: push X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 25 Jul 2016 09:30:50 -0700 Cc: Push Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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: Sat, 23 Jul 2016 19:56:58 -0000 ----==_mimepart_5793cc073c5b0_2c313fbc2afe72b821543b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @selfissued pushed 1 commit. 71df58b Moved Implementation Considerations and additional Privacy Considerations to tokbind-https spec --- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/54/files/25b4098735e6e1ade253e1a3dd3aee2b69da39b1..71df58b4e95382123ec8bedd39b3f525171350a4 ----==_mimepart_5793cc073c5b0_2c313fbc2afe72b821543b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@selfissued pushed 1 commit.

  • 71df58b Moved Implementation Considerations and additional Privacy Considerations to tokbind-https spec

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_5793cc073c5b0_2c313fbc2afe72b821543b-- From nobody Mon Jul 25 15:21:47 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E46912D578 for ; Mon, 25 Jul 2016 15:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olAusvyG3hzo for ; Mon, 25 Jul 2016 15:21:36 -0700 (PDT) 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 447D812D5F6 for ; Mon, 25 Jul 2016 15:21:36 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id r9so169859636ywg.0 for ; Mon, 25 Jul 2016 15:21:36 -0700 (PDT) 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=/VxsSAy2nVoozGbr6i192hbuA58o1PcbkbupUgeR0oE=; b=QisllI3bOkKYRMYywWrnBM8DseF9kLRya9I+IQdHKJCc4kvaLVedgMdgYSGeTAjY4l a/mmwcxYX1+aobDmxreMPgc6illV6fS5ItiH1sAum/HGAiYbCZbxyy9hSsb6Gxnikymk GOCc0qjRIDaMv3ruZ/CI/cD4hkmUq3a4yF6ISgHQU4a1goJVcSwdnAy0E9SbHPeHZ1UN fo3v5UdoL/UFOw3nImEap4qdBYnmxDdmKUHXCHAqDKaNHBGDVkp2/Ue3aa46TOXysAP8 IC07Yu+JIf6NPVLlO+/qc5feZ9PNOY/PaCoQI79ansCLVuPhMzEbj7kwyi6C3Y2pqk5u Zk7g== 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=/VxsSAy2nVoozGbr6i192hbuA58o1PcbkbupUgeR0oE=; b=YbnqmBWSqzPw63evzc/OQpc6M0T3DQEj0582ZBoEdX9pKF0uceRVHER6ZL0CXLbtfM PyFsKirH1lIhexXsmG+Dg4cFVRkV66voWq4nN7tCpDeMD1OpcJIXmFCZ58pZxATvBtJc gdTqkedBQ3yLSmpLt3M9VC9QNj35Vq7CEBVl3OXQj36/2+pYISw83TjllcO5ww8nwPVh 4+riUhlHAGcqqkFdwrq8nOXMKbsRhqW6Ud0jyw5wpIQ70ASwswllTR7gVbH2KKW+0yGV 0JNwrasP44Catr8I5kdqipTBD/o014nyIMm/5Y39BRzwqko0RRSf4epPsoV0tDXKzHDp BKRQ== X-Gm-Message-State: AEkooutCxYWbC1dsNsiJK2ua2tj7VmhgjtsK/E5hAbhfIz9AN14uCPjGGKBnUgRhMcQVF0MZX1x/ZPXRrXOdKmeJ X-Received: by 10.159.33.182 with SMTP id 51mr10110911uac.104.1469485295266; Mon, 25 Jul 2016 15:21:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Mon, 25 Jul 2016 15:21:15 -0700 (PDT) In-Reply-To: <20160723025426.Horde.0-CtvWrQbaSTWepGIJFKnTq@box514.bluehost.com> References: <1469184250.12541.6.camel@sunet.se> <20160723025426.Horde.0-CtvWrQbaSTWepGIJFKnTq@box514.bluehost.com> From: Nick Harper Date: Mon, 25 Jul 2016 15:21:15 -0700 Message-ID: To: Jeff Hodges Content-Type: multipart/alternative; boundary=001a113ac7c2073f6305387d3577 Archived-At: Cc: Andrei Popov , Dirk Balfanz , Tokbind WG , Mike Jones , William Denniss , Leif Johansson Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 22:21:40 -0000 --001a113ac7c2073f6305387d3577 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm still concerned that the privacy concerns are not being addressed with this proposal. Section 4.1 of the HTTPS draft states that the common idea among the federation mechanisms is that the server signals to the client to reveal its provided TBID to another server (with the Include-Referred-Token-Binding-ID header being one such mechanism). However, the wording in this pull request makes no indication that the use of this API to set referred TBIDs would be limited to when the referring server indicates to do so. The new section in "Privacy Considerations" is missing some of the cases of correlation that could happen. Suppose Example App decides to send a referred TBID (for its connection to example.com) on every HTTPS request it makes, and it happens to make requests to evil1.com and evil2.com (whose operators are trying to correlate traffic between them). This referred TBID is the same on both requests, and the site operators can now correlate requests, whereas if the app didn't (mis)use the API for setting referred TBIDs, the site operators wouldn't have been able to use Token Binding to correlate the requests. I think this example contradicts the wording that states "If the application is already aware of these other connections to these endpoints, then no additional information is being exposed." In this case, the application is aware of the connections (to evil1.com and evil2.com), yet the referred TBIDs that it sends can be used for correlation, which is additional information being exposed. My preference is that this API guidance not be included in these drafts, and that it can go in whichever draft defines an alternate mechanism for a server indicating to the client to reveal its TBID to another server. I also wouldn't mind the Privacy Considerations section reiterating the point that a referred TBID should only be sent when indicated to do so by the referring server. On Sat, Jul 23, 2016 at 1:54 AM, wrote: > > Quoting Mike Jones : > >> Thanks, Andrei, William, Brian, and Dirk. Reading all of your feedback, >> I think it makes sense to move the guidance to the HTTPS draft. I=E2=80= =99ll plan >> to work with Jeff to revise the pull request accordingly. >> > > Yep, works for me. > > =3DJeffH > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a113ac7c2073f6305387d3577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm still concerned that the privacy concerns are not = being addressed with this proposal. Section 4.1 of the HTTPS draft states t= hat the common idea among the federation mechanisms is that the server sign= als to the client to reveal its provided TBID to another server (with the I= nclude-Referred-Token-Binding-ID header being one such mechanism). However,= the wording in this pull request makes no indication that the use of this = API to set referred TBIDs would be limited to when the referring server ind= icates to do so.

The new section in "Privacy Consid= erations" is missing some of the cases of correlation that could happe= n. Suppose Example App decides to send a referred TBID (for its connection = to example.com) on every HTTPS request i= t makes, and it happens to make requests to ev= il1.com and evil2.com (whose operators= are trying to correlate traffic between them). This referred TBID is the s= ame on both requests, and the site operators can now correlate requests, wh= ereas if the app didn't (mis)use the API for setting referred TBIDs, th= e site operators wouldn't have been able to use Token Binding to correl= ate the requests. I think this example contradicts the wording that states = "If the application is already aware of these other connections to the= se endpoints, then no additional information is being exposed." In thi= s case, the application is aware of the connections (to evil1.com and evil2.com), ye= t the referred TBIDs that it sends can be used for correlation, which is ad= ditional information being exposed.

My preference = is that this API guidance not be included in these drafts, and that it can = go in whichever draft defines an alternate mechanism for a server indicatin= g to the client to reveal its TBID to another server. I also wouldn't m= ind the Privacy Considerations section reiterating the point that a referre= d TBID should only be sent when indicated to do so by the referring server.=

On Sa= t, Jul 23, 2016 at 1:54 AM, <jeff.hodges@kingsmountain.com> wrote:

Quoting Mike Jones <Michael.Jones@microsoft.com>:
Thanks, Andrei, William, Brian, and Dirk.=C2=A0 Reading all of your feedbac= k, I think it makes sense to move the guidance to the HTTPS draft.=C2=A0 I= =E2=80=99ll plan to work with Jeff to revise the pull request accordingly.<= br>

Yep, works for me.

=3DJeffH



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

--001a113ac7c2073f6305387d3577-- From nobody Wed Jul 27 12:31:49 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0526212D8E4 for ; Wed, 27 Jul 2016 12:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snR1ERwWmxZR for ; Wed, 27 Jul 2016 12:31:35 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 24F6F12D8E2 for ; Wed, 27 Jul 2016 12:31:35 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id q83so80170171iod.1 for ; Wed, 27 Jul 2016 12:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=7ZRD36VBazxTOPxwP1kdhbDYBuHrrziAY8ZECUx06XQ=; b=bofJ+eijwy7vl98m3MYDcKlnjQBU1nCcIROYneUH9u+YU4r2W0w6ngdae3zBYt/hom DZALnTwgwWoeTbzUSjjUZlTbhUuer/cbStm+2Ad0g50omTLpgUnEFUkttUZmhMn0ydBD jClvEl+UEfXP6w8UP1qbo48MQlcicC0V2X0nc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7ZRD36VBazxTOPxwP1kdhbDYBuHrrziAY8ZECUx06XQ=; b=WbLNiQqIw3JDZvPrNPdmmRD159OeZ6aYbUAG3LOXOrEY0RhDqOvU33+DFwoRn5hlrm IdQDBdRTc+6MzezWQqSYTDgKeaTPuWr2PnHVbwDhUc08wrvg96coYlRxxdk4FMd7j7Ma vOvZs7GWYAX9jENAKDIR7F1/NpK5N+qeHIgNmElzeX0UZlXkfbHSSxRB4nxkVsUjjHvG q808bb6yGcu9BbZWRJ271UBRR4VHkF5Wy09cxC5JJzh+Qf+ZIAsVuqNIao+XQFb4B0mj q5UTBgjNOJCHEMMSjU3VrR8oPkQR/H9/lWALC1xHtJz9ICGapaqzHu/1pOO94iqQfhCr nPjQ== X-Gm-Message-State: AEkoousMqMnSAbYp49wgV8kFMa7erIajax28yqR8yj/4yQyPN7PBCuRiMdB1uOlUsqsbuxMF07n5XzggDhwGzctG X-Received: by 10.107.8.140 with SMTP id h12mr35625878ioi.95.1469647886967; Wed, 27 Jul 2016 12:31:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.149 with HTTP; Wed, 27 Jul 2016 12:30:57 -0700 (PDT) From: Brian Campbell Date: Wed, 27 Jul 2016 13:30:57 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a113fb6b03f93820538a3100f Archived-At: Subject: [Unbearable] Include-Referred-Token-Binding-ID redirects within a domain X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 19:31:47 -0000 --001a113fb6b03f93820538a3100f Content-Type: text/plain; charset=UTF-8 What is the expected behavior when a browser receives a redirect with the Include-Referred-Token-Binding-ID but is from and to URIs in the same TLD+1 and everyone is able to negotiate Token Binding? I don't think the situation is explicitly covered in HTTPSTB. For example, when a request made to https://application.example.com receives an HTTP 302 that has Include-Referred-Token-Binding-ID:true with https://idp.example.com as the location. Is only the provided token binding sent by the browser to https://idp.example.com? Or are a provided and referred token binding both sent (with the same token binding id)? Or something else? This situation is fairly common in federated SSO deployments today and, depending on how things work from the HTTPSTB perspective, the referred token binding alone might not be enough of a signal to the token provider about what token binding ID to bind into the SSO token. The initial draft of TB for OpenID Connect, for example, relies on the presence of the Referred Token Binding being sent. I guess I'm suggesting, so federated protocols that use HTTPSTB don't have to have special treatment of this situation, that HTTPSTB explicitly say that a redirect with the Include-Referred-Token-Binding-ID header signals to the browser that it is to send a referred token binding on the resulting request even when both resources fall under the same same TLD+1 and the provided and referred token bindings would be the same. --001a113fb6b03f93820538a3100f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What is the expected behavior when a browse= r receives a redirect with the Include-Referred-Token-Binding-ID but is fro= m and to URIs in the same TLD+1 and everyone is able to negotiate Token Bin= ding? I don't think the situation is explicitly covered in HTTPSTB.
For example, when a request made to https://application.example.com recei= ves an HTTP 302 that has Include-Referred-Token-Binding-ID:true with https://idp.example.com= as the location. Is only the provided token binding sent by the browser to= https://idp.example.= com? Or are a provided and referred token binding both sent (with the s= ame token binding id)? Or something else?

This situation is fairly common in federated SSO deployments today and,=20 depending on how things work from the HTTPSTB perspective, the referred=20 token binding alone might not be enough of a signal to the token=20 provider about what token binding ID to bind into the SSO token. The initial draft of TB for OpenID Connect, for example, reli= es on the presence of the Referred Token Binding being sent.

= I guess I'm suggesting, so federated protocols that use HTTPSTB don'= ;t have to have special treatment of this situation, that HTTPSTB explicitl= y say that a redirect with the Include-Referred-Token-Binding-ID header sig= nals to the browser that it is to send a referred token binding on the resu= lting request even when both resources fall under the same same TLD+1 and t= he provided and referred token bindings would be the same.
--001a113fb6b03f93820538a3100f-- From nobody Thu Jul 28 22:12:30 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C093112D0E1 for ; Thu, 28 Jul 2016 22:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmMeJV-xFr0l for ; Thu, 28 Jul 2016 22:12:27 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 BB13A12D533 for ; Thu, 28 Jul 2016 22:12:26 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id l32so54635094ual.2 for ; Thu, 28 Jul 2016 22:12:26 -0700 (PDT) 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=XLirrmcrKTJS2VzWxUQt+z5TU/XnmBZnKUznSMucwF4=; b=KRurImNB0YjFlnLkFIxwyAXNGIupXJcsgf7/KFgK9cO5tGvUnXrsCBWxXQG+3V/Vvu QCVlzQdkFTYsCUPPVW4pE4GnK8cocqUqUAYb+bZ+ifwBaVhXqvu84fOeJrFxwMpM3wrs idXJnwzbfpjHzz/WZO8wVjb0unkjJ7+JM7/52thqRQs+rDGqJM+b7MVm2TYdikaHQXUM z5du0XWeGx1V61TPP8hC+aG0EpZEoNt8EQSuzxiBE2ZqtUshX5E535hTTabK2FJA0yt+ 6ENWk7faK1PekytJZV4FFfEoUaog0q+0ikTcD9gQy57JAWUMlqA+5Trzm1geS6yvl7F9 Mp5w== 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=XLirrmcrKTJS2VzWxUQt+z5TU/XnmBZnKUznSMucwF4=; b=WL6vg/QiV+ZsNickuhyaj5pUkTi5FIlmAjNRkaztHWbX9PEM/5F/Zr+bMCeBF/EdRc s6G/ZyrhEft1DrNm+rCUKbu5hQjYmdN0XGeNKvd8G1xQzJhjyNmo0iGdLHjXaz0O1949 OhmLQ40f1BUhH75fPzT+0KszBJRajX5i+ywQl6ynvXHTOj09eHiQCfZVnzXtXnAMucJG Sx4YiTdaKWXt9jp1w3O0rPYlAlhyO6AqYnrxtIq5GVBPQPmt3WjCG4DItwiK3x7pmQ3L rTXGATTDE3dzsu6IG7UgECtqoG9mUmGIy63Pux0m26wLondMGYyz6+METde3dSRW+sOx Msrg== X-Gm-Message-State: AEkoouvz6G4YtR6etxDYfTFpP2+8rHGCWatxCG3MpGeQ+AdJF51r1hvuI3Rfl/G0P+7gbLBqRGkt+3j/UxvMVYjo X-Received: by 10.159.33.182 with SMTP id 51mr18830047uac.104.1469769145695; Thu, 28 Jul 2016 22:12:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Thu, 28 Jul 2016 22:12:06 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Thu, 28 Jul 2016 22:12:06 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113ac7c2d50b4a0538bf4b27 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Include-Referred-Token-Binding-ID redirects within a domain X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 05:12:28 -0000 --001a113ac7c2d50b4a0538bf4b27 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 27, 2016 at 12:30 PM, Brian Campbell wrote: > What is the expected behavior when a browser receives a redirect with the > Include-Referred-Token-Binding-ID but is from and to URIs in the same TLD+1 > and everyone is able to negotiate Token Binding? I don't think the > situation is explicitly covered in HTTPSTB. > > For example, when a request made to https://application.example.com > receives an HTTP 302 that has Include-Referred-Token-Binding-ID:true with > https://idp.example.com as the location. Is only the provided token > binding sent by the browser to https://idp.example.com? Or are a provided > and referred token binding both sent (with the same token binding id)? Or > something else? > It should send both. If it doesn't send both, then the idp has to check other signals (e.g. Referer header) when it receives only a provided TB to determine whether it should issue an unbound token or a token bound to the provided (and in effect the referred) TB. I think it's easier for both the client and the server if the client sends a referred TB even when the eTLD+1 is the same. > > This situation is fairly common in federated SSO deployments today and, > depending on how things work from the HTTPSTB perspective, the referred > token binding alone might not be enough of a signal to the token provider > about what token binding ID to bind into the SSO token. The initial draft > of TB for OpenID Connect, > > for example, relies on the presence of the Referred Token Binding being > sent. > > I guess I'm suggesting, so federated protocols that use HTTPSTB don't have > to have special treatment of this situation, that HTTPSTB explicitly say > that a redirect with the Include-Referred-Token-Binding-ID header signals > to the browser that it is to send a referred token binding on the resulting > request even when both resources fall under the same same TLD+1 and the > provided and referred token bindings would be the same. > This is how Chrome currently behaves, and matches what the the HTTPSTB spec says, since the spec doesn't call for any special treatment when the token bindings would be the same. I don't have any objections to the spec clarifying this point. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a113ac7c2d50b4a0538bf4b27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 27, 2016 at 12:30 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
What is the expected behavior when a browser recei= ves a redirect with the Include-Referred-Token-Binding-ID but is from and t= o URIs in the same TLD+1 and everyone is able to negotiate Token Binding? I= don't think the situation is explicitly covered in HTTPSTB.

For example, when a request made to https://application.example.com receives an = HTTP 302 that has Include-Referred-Token-Binding-ID:true with https://idp.example.com as the= location. Is only the provided token binding sent by the browser to https://idp.example.com= ? Or are a provided and referred token binding both sent (with the same tok= en binding id)? Or something else?
<= br>
It should send both. If it doesn't send both, then the id= p has to check other signals (e.g. Referer header) when it receives only a = provided TB to determine whether it should issue an unbound token or a toke= n bound to the provided (and in effect the referred) TB. I think it's e= asier for both the client and the server if the client sends a referred TB = even when the eTLD+1 is the same.=C2=A0

This situation is fairly common in federated SSO deployments today and,=20 depending on how things work from the HTTPSTB perspective, the referred=20 token binding alone might not be enough of a signal to the token=20 provider about what token binding ID to bind into the SSO token. The initial draft of TB for OpenID Connect,= for example, relies on the presence of the Referred Token Binding being se= nt.

I guess I'm suggesting, so federated protocols that u= se HTTPSTB don't have to have special treatment of this situation, that= HTTPSTB explicitly say that a redirect with the Include-Referred-Token-Bin= ding-ID header signals to the browser that it is to send a referred token b= inding on the resulting request even when both resources fall under the sam= e same TLD+1 and the provided and referred token bindings would be the same= .

This is how Chrome currently b= ehaves, and matches what the the HTTPSTB spec says, since the spec doesn= 9;t call for any special treatment when the token bindings would be the sam= e. I don't have any objections to the spec clarifying this point.=C2=A0=

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


--001a113ac7c2d50b4a0538bf4b27-- From nobody Fri Jul 29 13:37:56 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7184B12D884 for ; Fri, 29 Jul 2016 13:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhiCENuwtIh4 for ; Fri, 29 Jul 2016 13:37:53 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 2417912D8B9 for ; Fri, 29 Jul 2016 13:37:41 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m101so138981698ioi.2 for ; Fri, 29 Jul 2016 13:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XVROyOb5wYJQDnLdNkNX1UTcpIbs80xM5qzJFNprbfI=; b=DWUnIVIpkgkbBu70gRLftQLI999AI3ED0IBPHJdAFYAXJlJDoRKtdqs8Vjy9K/aUxP V9MouvYKrAJpMHbwIM1TW4YDL4Gji+0PGkXZF+/ufxctcWFwQ8v5IhVI+/mvewNopSt6 7EgEUWYh5XLdV4auEA4GM41qnb1k8rp62x2JI= 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=XVROyOb5wYJQDnLdNkNX1UTcpIbs80xM5qzJFNprbfI=; b=cNuAaVlxVgfUM1Fr2Hdw9AgQZdmVqzcd7MTR7mgyxx0AMLQdN9ewils2hOxRj1V0Td vzE4u2ng5rJpBpPkZDEk+x43IQGrfphYVoYnqzqp05w+OZam71XTzCB7kCSASxjRvkvG EydaeQcBtIWyC2/oXGGZjSeP5VGoinYmL/1Ex2OWg0nrE8nZtCDXnDcuKXkDiYDYcpjJ e1t8kVtvYyO28jyQFpedcQ11FhhKGRC+muoK/ahFhGIj2TjsuCpcbHcGGAzzLh3kBxwA IWDQi3tIIipA3JpEyFrb9aImbDHVDuAeGBoGo4zbp3aZmPZJQEcJZYO4mIIjFZtm7RBV v0ZA== X-Gm-Message-State: AEkoousKHVaS/JNk35vAPUsm5yUHSeL5k7h4hEEelFEb2YMQOJrRAcP0Jt2Ma+1l4JDIqIYgrnwNNwuOEGNLQUsv X-Received: by 10.107.50.19 with SMTP id y19mr44206049ioy.174.1469824660423; Fri, 29 Jul 2016 13:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Fri, 29 Jul 2016 13:37:10 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 29 Jul 2016 14:37:10 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a114469c4c46b400538cc3852 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Include-Referred-Token-Binding-ID redirects within a domain X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:37:55 -0000 --001a114469c4c46b400538cc3852 Content-Type: text/plain; charset=UTF-8 Thanks for the response, Nick. Sounds like we're on the same page about how it should work. While you already interpret the spec text in that way, I do think there's some room for a different interpretation with the current text. And a clarifying the point would help ensure consistent behavior from different browsers. I'll put an issue in the github repo. On Thu, Jul 28, 2016 at 11:12 PM, Nick Harper wrote: > > On Wed, Jul 27, 2016 at 12:30 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> What is the expected behavior when a browser receives a redirect with the >> Include-Referred-Token-Binding-ID but is from and to URIs in the same TLD+1 >> and everyone is able to negotiate Token Binding? I don't think the >> situation is explicitly covered in HTTPSTB. >> >> For example, when a request made to https://application.example.com >> receives an HTTP 302 that has Include-Referred-Token-Binding-ID:true with >> https://idp.example.com as the location. Is only the provided token >> binding sent by the browser to https://idp.example.com? Or are a >> provided and referred token binding both sent (with the same token binding >> id)? Or something else? >> > > It should send both. If it doesn't send both, then the idp has to check > other signals (e.g. Referer header) when it receives only a provided TB to > determine whether it should issue an unbound token or a token bound to the > provided (and in effect the referred) TB. I think it's easier for both the > client and the server if the client sends a referred TB even when the > eTLD+1 is the same. > >> >> This situation is fairly common in federated SSO deployments today and, >> depending on how things work from the HTTPSTB perspective, the referred >> token binding alone might not be enough of a signal to the token provider >> about what token binding ID to bind into the SSO token. The initial >> draft of TB for OpenID Connect, >> >> for example, relies on the presence of the Referred Token Binding being >> sent. >> >> I guess I'm suggesting, so federated protocols that use HTTPSTB don't >> have to have special treatment of this situation, that HTTPSTB explicitly >> say that a redirect with the Include-Referred-Token-Binding-ID header >> signals to the browser that it is to send a referred token binding on the >> resulting request even when both resources fall under the same same TLD+1 >> and the provided and referred token bindings would be the same. >> > > This is how Chrome currently behaves, and matches what the the HTTPSTB > spec says, since the spec doesn't call for any special treatment when the > token bindings would be the same. I don't have any objections to the spec > clarifying this point. > >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> > --001a114469c4c46b400538cc3852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the response, Nick. Sounds like we're on th= e same page about how it should work. While you already interpret the spec = text in that way, I do think there's some room for a different interpre= tation with the current text. And a clarifying the point would help ensure = consistent behavior from different browsers. I'll put an issue in the g= ithub repo.

On Thu, Jul 28, 2016 at 11:12 PM, Nick Harper <nharper@google.com= > wrote:

On We= d, Jul 27, 2016 at 12:30 PM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
What is the expected behavior when a browser receiv= es a redirect with the Include-Referred-Token-Binding-ID but is from and to= URIs in the same TLD+1 and everyone is able to negotiate Token Binding? I = don't think the situation is explicitly covered in HTTPSTB.

For example, when a request made to https://application.example.com receives an H= TTP 302 that has Include-Referred-Token-Binding-ID:true with https://idp.example.com as the = location. Is only the provided token binding sent by the browser to https://idp.example.com?= Or are a provided and referred token binding both sent (with the same toke= n binding id)? Or something else?
It should send both. If it doesn't send both, then = the idp has to check other signals (e.g. Referer header) when it receives o= nly a provided TB to determine whether it should issue an unbound token or = a token bound to the provided (and in effect the referred) TB. I think it&#= 39;s easier for both the client and the server if the client sends a referr= ed TB even when the eTLD+1 is the same.=C2=A0

This situation is fairly common in federated SSO deployments today and,=20 depending on how things work from the HTTPSTB perspective, the referred=20 token binding alone might not be enough of a signal to the token=20 provider about what token binding ID to bind into the SSO token. The initial draft of TB for OpenID Connect,= for example, relies on the presence of the Referred Token Binding being se= nt.

I guess I'm suggesting, so federated protocols that u= se HTTPSTB don't have to have special treatment of this situation, that= HTTPSTB explicitly say that a redirect with the Include-Referred-Token-Bin= ding-ID header signals to the browser that it is to send a referred token b= inding on the resulting request even when both resources fall under the sam= e same TLD+1 and the provided and referred token bindings would be the same= .

This is how Chrome curr= ently behaves, and matches what the the HTTPSTB spec says, since the spec d= oesn't call for any special treatment when the token bindings would be = the same. I don't have any objections to the spec clarifying this point= .=C2=A0

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



--001a114469c4c46b400538cc3852-- From nobody Fri Jul 29 15:30:42 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D79912D5EC for ; Fri, 29 Jul 2016 15:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.007 X-Spam-Level: X-Spam-Status: No, score=-4.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BhsNZDaI6Dr for ; Fri, 29 Jul 2016 15:30:39 -0700 (PDT) Received: from pv35p16im-ztdg05081101.me.com (pv35p16im-ztdg05081101.me.com [17.133.187.172]) (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 7541C12D5C0 for ; Fri, 29 Jul 2016 15:30:39 -0700 (PDT) Received: from process-dkim-sign-daemon.pv35p16im-ztdg05081101.me.com by pv35p16im-ztdg05081101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OB300I00KWG9200@pv35p16im-ztdg05081101.me.com> for unbearable@ietf.org; Fri, 29 Jul 2016 22:30:39 +0000 (GMT) Received: from [192.168.1.36] (191-115-32-179.baf.movistar.cl [191.115.32.179]) by pv35p16im-ztdg05081101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OB300NJVL6S5M40@pv35p16im-ztdg05081101.me.com>; Fri, 29 Jul 2016 22:30:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-29_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1607290224 From: John Bradley Content-type: multipart/alternative; boundary="Apple-Mail=_E21C77DF-7E38-4E72-8756-DDA28F7EBDB4" Date: Fri, 29 Jul 2016 18:30:26 -0400 Message-id: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> To: IETF Tokbind WG MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1469831439; bh=cjBglr3SXm6RSN3MTn5H2Ltm/AR1NZ9uDOiNi2LsTY0=; h=From:Content-type:Subject:Date:Message-id:To:MIME-version; b=ZZzcS6a4qkvRpP7S6GlvmVer41ThKXl17K64C+6z6BBJL14xL74nK638hunfYvDhU 2UMvv0/ZKHEskGIJIIl5MWLF1W4wyGOi1RBPY4hNrNJDXSjkKhp2sSa/ROaSwgEDNr c4xvVQGG4Dv8uzUDNQsBRW7wqWXmUPL5CqbSPGdzzsWI4mrnpI+OTkZq3cGH1DjJkO JTfIwBWy1BLThMCF7v9bmBca/ieLq20E+hV8fM/tQwalOXCOdF5Z0gNNp+JfEqu2BB aLivIwIfLHljd5i4PMJJ4OIn3zkAyDQXyuOJXY5bYdO8960hZ77/kWp1PthBxB7Q0Q 26gqPYNft3X4g== Archived-At: Cc: Andrei Popov , Dirk Balfanz , =JeffH Hodges Subject: [Unbearable] Base64url encoding in draft-ietf-tokbind-https X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 22:30:41 -0000 --Apple-Mail=_E21C77DF-7E38-4E72-8756-DDA28F7EBDB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 = it is sending Sec-Token-Binding headers with padding. In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 = we = say The header field name is "Sec-Token-Binding", and EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] Section=C2=A05 ) of = the TokenBindingMessage as defined in [I-D.ietf-tokbind-protocol = ] When we did JOSE we found RFC4648 = a touch to vague on = padding. in principal encoders and decoders will work both ways. However for interoperability and space saving we required the producer = to send non padded to avoid confusion. We also added a appendix to help people with base64url without padding. https://tools.ietf.org/html/rfc7515#appendix-C = Can the authors look at clarifying this, as written sending with or = without padding is allowed by my reading. Including the appendix would also be fine with me if people think it = would help clarify things for developers. Thanks. John B.= --Apple-Mail=_E21C77DF-7E38-4E72-8756-DDA28F7EBDB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Brian Campbell has pointed out to me that in testing = Chrome 54.0.2811.0 it is sending Sec-Token-Binding headers with = padding.

In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section= -2 we say
 The =
header field name is "Sec-Token-Binding", and
   EncodedTokenBindingMessage is a base64url encoding (see [RFC4648]
   Section 5) of the TokenBindingMessage as defined in
   [I-D.ietf-tokbind-protocol]

When we did JOSE = we found RFC4648 a = touch to vague on padding.  in principal encoders and decoders will = work both ways.
However for interoperability and = space saving we required the producer to send non padded to avoid = confusion.

We = also added a appendix to help people with base64url without = padding.
https://tools.ietf.org/html/rfc7515#appendix-C

Can the authors =  look at clarifying this,  as written sending with or without = padding is allowed by my reading.

Including the appendix would also be = fine with me if people think it would help clarify things for = developers.

Thanks.

John B.
= --Apple-Mail=_E21C77DF-7E38-4E72-8756-DDA28F7EBDB4--