From nobody Mon Jun 1 12:21:52 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90221B3121 for ; Mon, 1 Jun 2015 12:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP6aDqLrgJBu for ; Mon, 1 Jun 2015 12:21:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 549C41B2B1F for ; Mon, 1 Jun 2015 12:21:48 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t51JLlcR018572 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Jun 2015 19:21:47 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t51JLjcd027666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 Jun 2015 19:21:47 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t51JLjBU023330 for ; Mon, 1 Jun 2015 19:21:45 GMT Received: from dhcp-burlington9-3rd-a-east-10-152-23-231.usdhcp.oraclecorp.com (/10.152.23.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2015 12:21:45 -0700 Message-ID: <556CB0BE.40507@oracle.com> Date: Mon, 01 Jun 2015 15:21:34 -0400 From: Ron Monzillo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: unbearable@ietf.org Content-Type: multipart/alternative; boundary="------------000108070506090906080805" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Unbearable] matching TBNEGO and TokenBinding algorithm and key lengths X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 19:21:51 -0000 This is a multi-part message in MIME format. --------------000108070506090906080805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit from https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/?include_text=1 section 3. > At least one TokenBinding MUST be > included in the Token Binding message. The signature and hash > algorithm and key length used in the TokenBinding MUST match the > parameters negotiated via [TBNEGO]. the values for hash and signature algorithm are enum { sha256(4), (255) } HashAlgorithm; enum { rsa(1), ecdsap256(3), (255) } SignatureAlgorithm; struct { HashAlgorithm hash; SignatureAlgorithm signature; } SignatureAndHashAlgorithm; in https://tools.ietf.org/html/draft-popov-tokbind-negotiation-00#page-2 there are values that appear to define combinations of algorithm with key length enum { rsa2048_pkcs1.5_sha256(0), rsa2048_pss_sha256(1), ecdsap256_sha256(2), (255) } TokenBindingKeyParameters; Are you planning to adopt a common scheme in both specs? --------------000108070506090906080805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit from https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/?include_text=1

section 3.

At least one TokenBinding MUST be
   included in the Token Binding message.  The signature and hash
   algorithm and key length used in the TokenBinding MUST match the
   parameters negotiated via [TBNEGO].
the values for hash and signature algorithm are 
enum {
    sha256(4), (255)
} HashAlgorithm;

enum {
    rsa(1), ecdsap256(3), (255)
} SignatureAlgorithm;

struct {
    HashAlgorithm hash;
    SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
in https://tools.ietf.org/html/draft-popov-tokbind-negotiation-00#page-2

there are values that appear to define combinations of algorithm with key length 
enum {
    rsa2048_pkcs1.5_sha256(0), rsa2048_pss_sha256(1), ecdsap256_sha256(2), (255)
} TokenBindingKeyParameters;
Are you planning to adopt a common scheme in both specs? 

  


--------------000108070506090906080805--


From nobody Mon Jun  1 15:46:41 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB81A1A7E for ; Mon,  1 Jun 2015 15:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK4mv6-6U7Bw for ; Mon,  1 Jun 2015 15:46:38 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C261A1A7D for ; Mon,  1 Jun 2015 15:46:37 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 22:46:19 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 22:46:19 +0000
From: Andrei Popov 
To: Ron Monzillo , "unbearable@ietf.org" 
Thread-Topic: [Unbearable] matching TBNEGO and TokenBinding algorithm and key lengths
Thread-Index: AQHQnKA6viGQBLXfGUSTbVEao0tPBp2YPvYw
Date: Mon, 1 Jun 2015 22:46:19 +0000
Message-ID: 
References: <556CB0BE.40507@oracle.com>
In-Reply-To: <556CB0BE.40507@oracle.com>
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:ed31::2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 3:Ra+slJgg9TSOR5+6xgFXRkmNmhA5GZCUp/rqmndBfdev1P8jmSuH1eTovXeKWkdQ+LVrPcgocd6083cxaN7qIG54eEl+aou/wsouPkAE91Di6bZpMqwQw/xkhidDg7b4vONro+9nb+UP+kywYr78jA==; 10:i+IuwuX7/zX3t/Q1nijdvxx3MPgsNNNddWJU+9pDn2lUzAf35TtC8u1zVTJHZ1glcSTRTYc4ecSWpTlMMagHcRqUPugLfsyi1TbVO1fIXiA=; 6:T11MENhNGnS36TH0jGWsZ2FNT4rTkmz9VPbBrjVmgnGXCkXfDueAcLSZl2iISvzT
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:BLUPR03MB1393; BCL:0;  PCL:0; RULEID:; SRVR:BLUPR03MB1393; 
x-forefront-prvs: 05947791E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(5001960100002)(50986999)(107886002)(19625215002)(76176999)(54356999)(5001860100001)(5001830100001)(2950100001)(101416001)(106356001)(76576001)(92566002)(2501003)(102836002)(189998001)(15975445007)(77096005)(2900100001)(68736005)(19580395003)(87936001)(77156002)(62966003)(19580405001)(19300405004)(2656002)(19617315012)(16236675004)(64706001)(86612001)(106116001)(74316001)(46102003)(99286002)(105586002)(4001540100001)(81156007)(97736004)(33656002)(40100003)(5001770100001)(5002640100001)(86362001)(122556002)(129583001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.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)
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396BEC77AC68DBBDB09C87C8CB60BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 22:46:19.3922 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393
Archived-At: 
Subject: Re: [Unbearable] matching TBNEGO and TokenBinding algorithm and key lengths
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Jun 2015 22:46:40 -0000

--_000_BLUPR03MB1396BEC77AC68DBBDB09C87C8CB60BLUPR03MB1396namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ron,

I think the 1-byte IDs used in [TBNEGO] have the advantage of simplicity. I=
f the WG agrees with the approach taken in [TBNEGO], then it makes sense to=
 update [TBPROTO] to use the same.

Cheers,

Andrei

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Ron Monz=
illo
Sent: Monday, June 1, 2015 12:22 PM
To: unbearable@ietf.org
Subject: [Unbearable] matching TBNEGO and TokenBinding algorithm and key le=
ngths

from https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/?include_=
text=3D1

section 3.



At least one TokenBinding MUST be

   included in the Token Binding message.  The signature and hash

   algorithm and key length used in the TokenBinding MUST match the

   parameters negotiated via [TBNEGO].
the values for hash and signature algorithm are

enum {

    sha256(4), (255)

} HashAlgorithm;



enum {

    rsa(1), ecdsap256(3), (255)

} SignatureAlgorithm;



struct {

    HashAlgorithm hash;

    SignatureAlgorithm signature;

} SignatureAndHashAlgorithm;


in https://tools.ietf.org/html/draft-popov-tokbind-negotiation-00#page-2

there are values that appear to define combinations of algorithm with key l=
ength

enum {

    rsa2048_pkcs1.5_sha256(0), rsa2048_pss_sha256(1), ecdsap256_sha256(2), =
(255)

} TokenBindingKeyParameters;


Are you planning to adopt a common scheme in both specs?

--_000_BLUPR03MB1396BEC77AC68DBBDB09C87C8CB60BLUPR03MB1396namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Ron,


 


I think the 1-byte IDs used in [TBNEG=
O] have the advantage of simplicity. If the WG agrees with the approach tak=
en in [TBNEGO], then it makes sense to update
 [TBPROTO] to use the same.


 


Cheers,


 


Andrei


 






From: Unbearable [mailto:unbearable-bounces@ietf.org]
On Behalf Of Ron Monzillo

Sent: Monday, June 1, 2015 12:22 PM

To: unbearable@ietf.org

Subject: [Unbearable] matching TBNEGO and TokenBinding algorithm and=
 key lengths






 


from 
https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/?include_text=
=3D1



section 3.










At least one TokenBinding MUST be


   included in the Token Binding message.  The signatur=
e and hash


   algorithm and key length used in the TokenBinding MUST ma=
tch the


   parameters negotiated via [TBNEGO].




the values for hash and signature algorithm are 


enum {


    sha256(4), (255)


} HashAlgorithm;


 


enum {


    rsa(1), ecdsap256(3), (255)


} SignatureAlgorithm;


 


struct {


    HashAlgorithm hash;


    SignatureAlgorithm signature;


} SignatureAndHashAlgorithm;


 


in 
https://tools.ietf.org/html/draft-popov-tokbind-negotiation-00#page-2 <=
br>


there are values that appear to define combinations of algorithm with key l=
ength 



enum {


    rsa2048_pkcs1.5_sha256(0), rsa2048_pss_sha256(1), e=
cdsap256_sha256(2), (255)


} TokenBindingKeyParameters;


 


Are you planning to adopt a common scheme in both sp=
ecs? 







--_000_BLUPR03MB1396BEC77AC68DBBDB09C87C8CB60BLUPR03MB1396namp_--


From nobody Tue Jun 16 12:30:46 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C341B2C41 for ; Tue, 16 Jun 2015 12:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeQq3ZRVuEW5 for ; Tue, 16 Jun 2015 12:30:42 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1553F1B2C42 for ; Tue, 16 Jun 2015 12:30:35 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 19:30:34 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0190.013; Tue, 16 Jun 2015 19:30:34 +0000
From: Andrei Popov 
To: "unbearable@ietf.org" 
Thread-Topic: New and Updated I-Ds
Thread-Index: AdCaaI/uZjPJTA7KT/apdeAdcrT1+gOAYUOA
Date: Tue, 16 Jun 2015 19:30:34 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 3:AISvuHuj3Y9ly05SrOp4/RMh/KyHtw5xKQ4Ms86+Ugxtkh+assSgiaMrra2DTjGZ3Z/aQJgGAHmtD0IUxxHVyOdnXV29NLM1fK2jdnYusxLgsuAMJfxFRL2Z5jpKCnrZGKaoqk98/MBDLPc/fZ930g==; 10:SAHtkshMY/965RjEN6K2++rFdYiSf5xsGSJCnpgoufqfAh0SyMe7M6lewy0U8LKcGrqBii3IuNd/RUsHw5IfomeZs90K0MZMozNxgxm47c4=; 6:7rzcxD75UD0s95oub1rgBA/9pCadhQSN6ZGs5XrMqjgKUgl9TCb1SvJ9ktl7z/rF
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0;  PCL:0; RULEID:; SRVR:BLUPR03MB1394; 
x-forefront-prvs: 06098A2863
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52044002)(377454003)(86612001)(33656002)(110136002)(87936001)(77096005)(62966003)(102836002)(19580405001)(46102003)(15975445007)(19300405004)(19580395003)(5003600100002)(54356999)(86362001)(7110500001)(107886002)(16236675004)(189998001)(76576001)(5001960100002)(450100001)(2420400003)(19625215002)(77156002)(2656002)(2900100001)(74316001)(92566002)(2351001)(2501003)(50986999)(5002640100001)(122556002)(19617315012)(40100003)(99286002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139650BC6C18CD9926E1F8588CA70BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 19:30:34.7519 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394
Archived-At: 
Subject: Re: [Unbearable] New and Updated I-Ds
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2015 19:30:44 -0000

--_000_BLUPR03MB139650BC6C18CD9926E1F8588CA70BLUPR03MB1396namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Also, please feel free to use GitHub to track issues and make pull requests=
: https://github.com/TokenBinding/Internet-Drafts

Now that we have TBNEGO I-D, I've closed a couple of issues related to the =
use of ALPN.

Cheers,

Andrei

From: Andrei Popov
Sent: Friday, May 29, 2015 4:54 PM
To: unbearable@ietf.org
Subject: New and Updated I-Ds

In Dallas we agreed to define a new TLS extension for Token Binding key par=
ameters negotiation, instead of using ALPN.

Today I've submitted TLS Extension for Token Binding Protocol Negotiation  =
I-D: https://datatracker.ietf.org/doc/draft-popov-tokbind-negotiation/


I have also updated the Token Binding Protocol I-D: https://tools.ietf.org/=
html/draft-ietf-tokbind-protocol-01
The updated version has the following changes:

-          Removed ALPN negotiation text;

-          Added a Security Considerations sub-section discussing Token Bin=
ding key sharing between applications;

-          Minor edits, nits, etc.

Comments are very welcome!

Cheers,

Andrei

--_000_BLUPR03MB139650BC6C18CD9926E1F8588CA70BLUPR03MB1396namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Also, please feel free=
 to use GitHub to track issues and make pull requests:
https://github.=
com/TokenBinding/Internet-Drafts


 


Now that we have TBNEG=
O I-D, I’ve closed a couple of issues related to the use of ALPN.


 


Cheers,


 


Andrei


 






From: Andrei Popov 

Sent: Friday, May 29, 2015 4:54 PM

To: unbearable@ietf.org

Subject: New and Updated I-Ds






 


In Dallas we agreed to define a new TLS extension fo=
r Token Binding key parameters negotiation, instead of using ALPN.


 


Today I’ve submitted TLS Extension for Token B=
inding Protocol Negotiation  I-D:
https://datatracker.ietf.org/doc/draft-popov-tokbind-negotiation/


 


I have also updated the Token Binding Protocol I-=
D: 
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01

The updated version has the following changes:<=
/o:p>


-     &=
nbsp;   
Removed ALPN negotiation text;


-     &=
nbsp;   
Added a Security Considerations sub-section discuss=
ing Token Binding key sharing between applications;


-     &=
nbsp;   
Minor edits, nits, etc.


 


Comments are very welcome!


 


Cheers,


 


Andrei






--_000_BLUPR03MB139650BC6C18CD9926E1F8588CA70BLUPR03MB1396namp_--


From nobody Tue Jun 23 00:37:57 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECDF1A8AF4 for ; Tue, 23 Jun 2015 00:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.039
X-Spam-Level: *
X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anxJUjwnaYLo for ; Tue, 23 Jun 2015 00:37:53 -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 AF91C1A8AF2 for ; Tue, 23 Jun 2015 00:37:52 -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 t5N7bolh012743 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 23 Jun 2015 09:37:50 +0200
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t5N7blZd004185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jun 2015 09:37:49 +0200 (CEST)
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=1435045069; bh=tVTZnIjt/TvKNXu9Qwjac3AtfZWNKZvIs/odU9NjUR8=; h=Date:From:To:Subject; b=u5pNBh8Raw+FNFdnCnipfvjyduMQMb9xXLzrxitTKrdlrAcCWGqW15NDArrkl5ODh +TB6BEJPMZR2i0y9EqO5M6zDE5dDlkn75Wxv5/mdqbmbcwwqda0vMpIC8ZEOEU9NyP fLtBDOzZRa8Va8G8yXgUk7D6lt5tth8hp+RDjRYk=
X-Footer: c3VuZXQuc2U=
Received: from [192.36.125.223] ([192.36.125.223]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for unbearable@ietf.org; Tue, 23 Jun 2015 09:37:45 +0200
Message-ID: <55890CC9.3070303@sunet.se>
Date: Tue, 23 Jun 2015 09:37:45 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "unbearable@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
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: 09OHHBOxI - ed3f44fd815b - 20150623
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201
Archived-At: 
Subject: [Unbearable] discussion in github issues
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jun 2015 07:37:55 -0000

Folks - remember to mirror the discussion on github issues on this list.
Discussions on github are not obviously covered by NOTE WELL
for instance.


From nobody Tue Jun 30 03:09:54 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300E1A87DB for ; Tue, 30 Jun 2015 03:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wERLxdYm82PI for ; Tue, 30 Jun 2015 03:09:51 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 A15251A87C4 for ; Tue, 30 Jun 2015 03:09:51 -0700 (PDT)
Received: by igrv9 with SMTP id v9so47689921igr.1 for ; Tue, 30 Jun 2015 03:09:51 -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:content-type; bh=NjGCFJ+eWYYdclw1+yd6VH6LOmSY/XtxhYcxixQGXxU=; b=SzI3A+O3BLODMD60h4fTtEmWbh5XBnspr6dYstK8DF460RLMTfV/Eq9wmE88kXY1VJ /A9e0hPUr/MG0IsYNWP4owM6Dy1SOkYruEub8mpa6RphRnXjbVHek3WClx2ZD/IEXqra AYH2dqDhfmc7ViP607aNCaK+T4Uszu26FVL1uM4RO2XL3KLd3qFiyF22RsoIJ/QkJ+Vt OALrt7biW/2rRsfE2+qzC2LlRg1YiCoXDiMf0Cs83T4jHWf8CImvrqZ1S4CY/JuQq6Bz 8DbKQ/m76EitCOQnEqyMlzInSE2BBt1Xu+t2TsGMLiIJXvta/XToia1p5DyGGG0jzA06 dZMA==
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 :content-type; bh=NjGCFJ+eWYYdclw1+yd6VH6LOmSY/XtxhYcxixQGXxU=; b=bWcq2sl/QkgsGSfYWW4mKwn/qqUNl2iY1Bklsk1Xi5ncQ3G8AiKlsZRMP4hZFs3BYm dbIqEwFsRG2TAduxznOI4epmU/zHRk/fjLGYkPhduQuiLhG/VDopyj8Y17GSaUgeSmMl 8gRQL1IvvhWHGpzZAY7dOe0rZeOc4NoV6lDom9DpUTTGdxslqoos6xswbMgg0iU0XOmo yGGzFEOdPaLeQrPt+bthEjCIKaMWD4CfMUiu9auW+WZhb1sKI8cB+SI+D19k+MYkhNlj zK46dl94FyugQkFK1kw5mBrmHXLuQvopGbRTLsh+EAyzXV5is5Po7lXUT7Fa8GNIzSkW 123A==
X-Gm-Message-State: ALoCoQnmMetnjqfXnqqc0is/DNKZLwKQdHT+B6JLBsqK3sy2M+/KbLO1eK5GhnBfIwDBUO1HdENQ
X-Received: by 10.107.165.206 with SMTP id o197mr14259485ioe.2.1435658991133;  Tue, 30 Jun 2015 03:09:51 -0700 (PDT)
MIME-Version: 1.0
From: Dirk Balfanz 
Date: Tue, 30 Jun 2015 10:09:41 +0000
Message-ID: 
To: Tokbind WG 
Content-Type: multipart/alternative; boundary=001a114150742f9efd0519b9685a
Archived-At: 
Subject: [Unbearable] Sec- prefix for Token-Binding headers
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2015 10:09:52 -0000

--001a114150742f9efd0519b9685a
Content-Type: text/plain; charset=UTF-8

Hi guys,

following Leif's request to mirror discussions here, I wanted to point out
one discussion we're having over there regarding the Sec- prefix for the
Token-Binding header:
https://github.com/TokenBinding/Internet-Drafts/issues/1

Anne favors a Sec- prefix (meaning it can't be set directly from
Javascript), whereas Martin doesn't.

I find Anne's arguments persuasive.

Any other thoughts?

Dirk.

--001a114150742f9efd0519b9685a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi guys,=C2=A0

following Leif's req=
uest to mirror discussions here, I wanted to point out one discussion we=
9;re having over there regarding the Sec- prefix for the Token-Binding head=
er:=C2=A0https://github.com/TokenBinding/Internet-Drafts/issues/1
<=
br>
Anne favors a Sec- prefix (meaning it can't be set direct=
ly from Javascript), whereas Martin doesn't.

I=
 find Anne's arguments persuasive.=C2=A0

Any o=
ther thoughts?

Dirk.


--001a114150742f9efd0519b9685a--


From nobody Tue Jun 30 03:32:06 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430051ACD3A for ; Tue, 30 Jun 2015 03:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM873jOTDBBD for ; Tue, 30 Jun 2015 03:32:03 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0601ACE5D for ; Tue, 30 Jun 2015 03:32:02 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id D78569007D; Tue, 30 Jun 2015 13:32:00 +0300 (EEST)
Date: Tue, 30 Jun 2015 13:32:00 +0300
From: Ilari Liusvaara 
To: Dirk Balfanz 
Message-ID: <20150630103200.GA11277@LK-Perkele-VII>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: Tokbind WG 
Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2015 10:32:05 -0000

On Tue, Jun 30, 2015 at 10:09:41AM +0000, Dirk Balfanz wrote:
> 
> following Leif's request to mirror discussions here, I wanted to point out
> one discussion we're having over there regarding the Sec- prefix for the
> Token-Binding header:
> https://github.com/TokenBinding/Internet-Drafts/issues/1
> 
> Anne favors a Sec- prefix (meaning it can't be set directly from
> Javascript), whereas Martin doesn't.

Because TokenBinding protects cookies, and cookies are already a
forbidden field (that is, Javascript can't set its own cookies
for request), I don't see use for non-Sec field.

Referred token bindings might be another matter (especially if not
actually validated), since the access token might not take the form
of cookie, and thus Javascript can control sending/receiving.


Being able to set TokenBinding header from Javascript might however
lead to weird behaviour:

Generate a key and valid signature with that key. Then override
TokenBinding header with that signature on request to another origin
with cookies sent.

If browser has cookies for the origin, those now get sent with
invalid TokenBinding. Which should be no problem, unless the server
does something dumb.

If the server sends cookies and browser stores those, the
TokenBinding for those cookies will be wrong and those cookies
presumably won't work.


-Ilari


From nobody Tue Jun 30 07:00:48 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401BF1A1BC2; Tue, 30 Jun 2015 07:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeW8P-1L_hiZ; Tue, 30 Jun 2015 07:00:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D52161A016C; Tue, 30 Jun 2015 07:00:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150630140045.31804.45747.idtracker@ietfa.amsl.com>
Date: Tue, 30 Jun 2015 07:00:45 -0700
Archived-At: 
Cc: unbearable@ietf.org
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-01.txt
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2015 14:00:47 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Token Binding Working Group of the IETF.

        Title           : Token Binding over HTTP
        Authors         : Andrei Popov
                          Magnus Nystroem
                          Dirk Balfanz
                          Adam Langley
	Filename        : draft-ietf-tokbind-https-01.txt
	Pages           : 9
	Date            : 2015-06-30

Abstract:
   This document describes a collection of mechanisms that allow HTTP
   servers to cryptographically bind authentication tokens (such as
   cookies and OAuth tokens) to a TLS [RFC5246] connection.

   We describe both _first-party_ as well as _federated_ scenarios.  In
   a first-party scenario, an HTTP server issues a security token (such
   as a cookie) to a client, and expects the client to send the security
   token back to the server at a later time in order to authenticate.
   Binding the token to the TLS connection between client and server
   protects the security token from theft, and ensures that the security
   token can only be used by the client that it was issued to.

   Federated token bindings, on the other hand, allow servers to
   cryptographically bind security tokens to a TLS [RFC5246] 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 [TBPROTO]


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-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-01


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 Tue Jun 30 07:06:57 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996071A21B9 for ; Tue, 30 Jun 2015 07:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6DjP300FjjX for ; Tue, 30 Jun 2015 07:06:54 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CE31A1BF1 for ; Tue, 30 Jun 2015 07:06:53 -0700 (PDT)
Received: by ieqy10 with SMTP id y10so13027790ieq.0 for ; Tue, 30 Jun 2015 07:06:53 -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 :content-type; bh=xfhJehujLWUOenddhuD15x1n7OWz1pwS4v47S/rcCW4=; b=fEzV/fAALMwitGx4f43VHluwcyrePwSHOupJ7MHfaCs90taixr8HOTD6brDqRELalg +7cbABkYMGXGDQLUW8/rDP47TL6oGSM3KpGxl0ItAc9lmUCp9PK/FY0XwQ7R7eFxAdPJ fnSdrL0bJ9whQVV1mnxSh2pbZwaBASkwx5fj4QaMJesmtAIQ3AI5WKxx3ouK8leMzBXo rUFMv1Gti7PDiw1ET4JH5sA/rav1aj/7NC5MNDFpCcj/iGrYfVCI+6F3TruwTZNczeAE xJOjj3Ap+ygnflPTxB/2/S6Xuv+pa3z8a9H1bFq+A6WIsfLUogU7SiWwQ8hOMxPthMj1 pZug==
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:content-type; bh=xfhJehujLWUOenddhuD15x1n7OWz1pwS4v47S/rcCW4=; b=Syl5Nq3mr0n4i/Xs0FvJnLTs7hRZ4ZTvr3WDTG3egYGKD4OTWYlznViFSqc1VC5VhR obeTZKbG9elXe00FNLFcTwEqzMESWSn7eXYeaxa7uKNMizRxFeBj0kKCeFCIE8QAXsf+ 6lN491sO+r7rdJH2xuZ7D4EvFvxXkHQ2aR8q0aTAXOOn+drEPdrcUxTC3gepqSlvFNlq dpS09bFSLZ5U3Zh/IG0hehcKIqSuyTtRrJyOHl7QXcK/4fvoZSNgvJf2lCqm3qJT5zgr p9cQwkzd3w/GM8/36q4SE6vYGZdCnNFTCwjr99lqwa4vIC+Kz6HV7GKY4fdjxhMX+yAy nXSg==
X-Gm-Message-State: ALoCoQkLcUMb26tew9YwTYiC3waVjDjsDcbopFaWvPihLGhfhxM7hV+f6BmTM4JlNcztS0iojJ9E
X-Received: by 10.42.157.200 with SMTP id e8mr26477146icx.84.1435673213052; Tue, 30 Jun 2015 07:06:53 -0700 (PDT)
MIME-Version: 1.0
References: <20150630140045.31804.45747.idtracker@ietfa.amsl.com>
In-Reply-To: <20150630140045.31804.45747.idtracker@ietfa.amsl.com>
From: Dirk Balfanz 
Date: Tue, 30 Jun 2015 14:06:43 +0000
Message-ID: 
To: Tokbind WG 
Content-Type: multipart/alternative; boundary=90e6ba212133e107450519bcb73e
Archived-At: 
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-01.txt
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2015 14:06:55 -0000

--90e6ba212133e107450519bcb73e
Content-Type: text/plain; charset=UTF-8

Hi there,

I submitted a new version of the "Token Binding over HTTP" draft:
https://tools.ietf.org/html/draft-ietf-tokbind-https-01

The main difference is that this draft no longer mentions DOM APIs (the
assumption is that this will be handled by WHATWGs work on fetch()), plus
some minor renamings and rewordings.

Comments welcome!

Dirk.

On Tue, Jun 30, 2015 at 7:00 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Token Binding Working Group of the IETF.
>
>         Title           : Token Binding over HTTP
>         Authors         : Andrei Popov
>                           Magnus Nystroem
>                           Dirk Balfanz
>                           Adam Langley
>         Filename        : draft-ietf-tokbind-https-01.txt
>         Pages           : 9
>         Date            : 2015-06-30
>
> Abstract:
>    This document describes a collection of mechanisms that allow HTTP
>    servers to cryptographically bind authentication tokens (such as
>    cookies and OAuth tokens) to a TLS [RFC5246] connection.
>
>    We describe both _first-party_ as well as _federated_ scenarios.  In
>    a first-party scenario, an HTTP server issues a security token (such
>    as a cookie) to a client, and expects the client to send the security
>    token back to the server at a later time in order to authenticate.
>    Binding the token to the TLS connection between client and server
>    protects the security token from theft, and ensures that the security
>    token can only be used by the client that it was issued to.
>
>    Federated token bindings, on the other hand, allow servers to
>    cryptographically bind security tokens to a TLS [RFC5246] 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 [TBPROTO]
>
>
> 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-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-01
>
>
> 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/
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>

--90e6ba212133e107450519bcb73e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi there,=C2=A0

I submitted a new versi=
on of the "Token Binding over HTTP" draft:=C2=A0https://tools.ietf.org/h=
tml/draft-ietf-tokbind-https-01

The main diffe=
rence is that this draft no longer mentions DOM APIs (the assumption is tha=
t this will be handled by WHATWGs work on fetch()), plus some minor renamin=
gs and rewordings.=C2=A0

Comments welcome!

Dirk.

=
On Tue, Jun 30, 2015 at 7:00 AM <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

=C2=A0This draft is a work item of the Token Binding Working Group of the I=
ETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Token Binding over HTTP

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andr=
ei Popov

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Magnus Nystroem

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Dirk Balfanz

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Adam Langley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-tokbind-https-01.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2015-06-30



Abstract:

=C2=A0 =C2=A0This document describes a collection of mechanisms that allow =
HTTP

=C2=A0 =C2=A0servers to cryptographically bind authentication tokens (such =
as

=C2=A0 =C2=A0cookies and OAuth tokens) to a TLS [RFC5246] connection.



=C2=A0 =C2=A0We describe both _first-party_ as well as _federated_ scenario=
s.=C2=A0 In

=C2=A0 =C2=A0a first-party scenario, an HTTP server issues a security token=
 (such

=C2=A0 =C2=A0as a cookie) to a client, and expects the client to send the s=
ecurity

=C2=A0 =C2=A0token back to the server at a later time in order to authentic=
ate.

=C2=A0 =C2=A0Binding the token to the TLS connection between client and ser=
ver

=C2=A0 =C2=A0protects the security token from theft, and ensures that the s=
ecurity

=C2=A0 =C2=A0token can only be used by the client that it was issued to.


=C2=A0 =C2=A0Federated token bindings, on the other hand, allow servers to<=
br>
=C2=A0 =C2=A0cryptographically bind security tokens to a TLS [RFC5246] conn=
ection

=C2=A0 =C2=A0that the client has with a _different_ server than the one iss=
uing

=C2=A0 =C2=A0the token.



=C2=A0 =C2=A0This Internet-Draft is a companion document to The Token Bindi=
ng

=C2=A0 =C2=A0Protocol [TBPROTO]





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ie=
tf-tokbind-https/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-tokbin=
d-https-01



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Dd=
raft-ietf-tokbind-https-01





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

Unbearable mailing list

Unbearable@ietf.or=
g

https://www.ietf.org/mailman/listinfo/unbearable=





--90e6ba212133e107450519bcb73e--


From nobody Tue Jun 30 09:41:13 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667771ACE6B for ; Tue, 30 Jun 2015 09:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhaSCO2FEez2 for ; Tue, 30 Jun 2015 09:41:10 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A731A6F07 for ; Tue, 30 Jun 2015 09:41:09 -0700 (PDT)
Received: by ykfy125 with SMTP id y125so14177587ykf.1 for ; Tue, 30 Jun 2015 09:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LgVkgLKPm41awlsUiYdFo+dkW6c4Pr6Ge1+zmZxzNFY=; b=bzB09ZBF3lDVEAFiImbuTMf5PbW7bDifIrKOdnFFIor4qhl8VOGjH2OxIc2fPb18a3 tN/eZtv6a0ZVec/oWc2+LKCdL0kU6hxzBbYgOVhBsL0fcJnlG7YW6xH1Q5wC2mwdL2Sf CRlof5d0xiZ1fmdHXbIs/4ZcsJC5F3OLSB+77ymnlPN6+50OpO/cAPlLXEbUt+1wBeDH 4PIwWZHDbJHncpZKYPixPGioICae06NqjdvexvRFiVYvTnpNMZQe7WS2cJD9Xz/8oiho wSMuYNmngjVZUDlY2WceBfnpTCtjsD8WwjLZcg9BiC18Uud7eUqjevt9GSs5cbHO2XKa JfVQ==
MIME-Version: 1.0
X-Received: by 10.13.236.214 with SMTP id v205mr9086119ywe.89.1435682469146; Tue, 30 Jun 2015 09:41:09 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Tue, 30 Jun 2015 09:41:09 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 30 Jun 2015 09:41:09 -0700
Message-ID: 
From: Martin Thomson 
To: Dirk Balfanz 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Tokbind WG 
Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2015 16:41:12 -0000

This is wholly confused, as I explained in the issue.  The security of
token binding is based on the private key.  If it is not, then I think
we need to discuss how that is not sufficient.

On 30 June 2015 at 03:09, Dirk Balfanz  wrote:
> Hi guys,
>
> following Leif's request to mirror discussions here, I wanted to point out
> one discussion we're having over there regarding the Sec- prefix for the
> Token-Binding header:
> https://github.com/TokenBinding/Internet-Drafts/issues/1
>
> Anne favors a Sec- prefix (meaning it can't be set directly from
> Javascript), whereas Martin doesn't.
>
> I find Anne's arguments persuasive.
>
> Any other thoughts?
>
> Dirk.
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>