From nobody Fri Apr 1 11: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 2BA0A12D172 for ; Fri, 1 Apr 2016 11:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_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 veADXyo4FtNp for ; Fri, 1 Apr 2016 11:44:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD2612D142 for ; Fri, 1 Apr 2016 11:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yHzZanmQIAvG3qThfkeEKGKfOzQZOITqyuYyoTz3oC0=; b=R/RdZwJim/LbRsX2TQdUEFT3Wo8rAiDd3/5WSxdylbfrx9byW3ZLx3Yz9YKqct4wWyBRQi95R/LmLTyWQt/BiS79LBESvBOFyiM9UR0c6q+4QV89wcTTgIsazldIKhdQHomdxRZ2qFqnkH5E9fom4YHr33uKNSqOzp8BTnuLxRQ= 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.447.15; Fri, 1 Apr 2016 18:44:18 +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.0447.025; Fri, 1 Apr 2016 18:44:18 +0000 From: Andrei Popov To: =JeffH , IETF Tokbind WG Thread-Topic: [Unbearable] comments on draft-ietf-tokbind-negotiation-02 Thread-Index: AQHRi2RAfPOiw7RSy0qYxkK1JB5qd591ZX7w Date: Fri, 1 Apr 2016 18:44:18 +0000 Message-ID: References: <56FD45D8.3010609@KingsMountain.com> In-Reply-To: <56FD45D8.3010609@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-ms-office365-filtering-correlation-id: f84072ac-1233-4986-069b-08d35a5da1df x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:zM2hyvwdUesAQSaZjgcax2supGp2nWZ4aXipBuOT+IEf6CfZ9Ophp4MMTvLVvdCi+RytJMseahlOHEcog5huUNNLiTsSiVUUza6NX2+7BRUpzcD5vXB0EDl1OmOVijElJ7SkIT20MAyAoJtS7jJwzg==; 24:CSRJrWKrfMbsP9+csMf+LwjVdpjGF+nci2SP656cnuXsDUKbwvAmjR/1hQ5hXM8nX1Utujqtf03J/kS1vNrbMlm62gkpE5NXKTAfV3U2sM8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(50944005)(377454003)(13464003)(15374003)(122556002)(81166005)(5008740100001)(86612001)(54356999)(76176999)(50986999)(10400500002)(5005710100001)(15975445007)(6116002)(77096005)(102836003)(86362001)(76576001)(10090500001)(5004730100002)(2900100001)(2950100001)(33656002)(92566002)(106116001)(1096002)(1220700001)(586003)(11100500001)(10290500002)(8990500004)(99286002)(74316001)(87936001)(3660700001)(3280700002)(5001770100001)(107886002)(2906002)(230783001)(189998001)(5002640100001)(5003600100002)(19580395003)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2016 18:44:18.1703 (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] comments on draft-ietf-tokbind-negotiation-02 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 Apr 2016 18:44:23 -0000 The editorial aspects would probably be easier handled by PR; I would not m= ind merging most of the suggestions. > Though, one possible bug is that step 1 in section 4 refers to 'client' w= hen it should be referring to 'server', yes? see detailed inline comments = on this and other stuff below. No, the text is as intended: the client receiving the "token_binding" exten= sion MUST terminate the handshake if the client did not include the "token_= binding" extension in the client hello. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Thursday, March 31, 2016 8:44 AM To: IETF Tokbind WG Subject: [Unbearable] comments on draft-ietf-tokbind-negotiation-02 I basically have only editorial comments on -tokbind-negotiation-02 aka TBN= EGO. Though, one possible bug is that step 1 in section 4 refers to 'client' whe= n it should be referring to 'server', yes? see detailed inline comments on= this and other stuff below. An overall editorial comment is: RFC5246 defines extensions generically as "Hello Extensions" , rathe= r than as "client hello extension" or "server hello extension".. 7.4.1.4. Hello Extensions The extension format is: struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension; enum { signature_algorithms(13), (65535) } ExtensionType; Here: - "extension_type" identifies the particular extension type. - "extension_data" contains information specific to the particular extension type. The initial set of extensions is defined in a companion document [...]= . An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert. Nonetheless, "server-oriented" extensions may be provided in the future within this framework. [...] ..thus I suggest re-working the TBNEGO sections to define a "TB Nego hello = extension" with subsequent sections defining the client-side and server-sid= e processing of the extension. further editorial comments inline below: > > Transport Layer Security (TLS) Extension for Token Binding Protocol > Negotiation > draft-ietf-tokbind-negotiation-02 > >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. > >Status of This Memo > > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 > 2. Token Binding Negotiation Client Hello Extension . . . . . . 2 > 3. Token Binding Negotiation Server Hello Extension . . . . . . 3 > 4. Negotiating Token Binding Protocol Version and Key Parameters 4 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 > 6.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 6 > 6.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS > Versions . . . . . . . . . . . . . . . . . . . . . . . . 6 > 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 > 8.2. Informative References . . . . . . . . . . . . . . . . . 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > >1. Introduction > > In order to use the Token Binding protocol > [I-D.ietf-tokbind-protocol], the client and server need to agree on > the Token Binding protocol version and the parameters (signature > algorithm, length) of the Token Binding key. This document specifies > a new TLS extension to accomplish this negotiation without > introducing additional network round-trips. > >1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > >2. Token Binding Negotiation Client Hello Extension recast as "Token Binding Negotiation Hello Extension" move client-side processing rules to > > The client uses the "token_binding" TLS extension to indicate the > highest supported Token Binding protocol version and key parameters. > > enum { > token_binding(TBD), (65535) > } ExtensionType; > > The "extension_data" field of this extension contains a > "TokenBindingParameters" value. OLD: The "extension_data" field of this extension contains a "TokenBindingParame= ters" value. NEW: The token_binding extention's "extension_data" field, which is a component = of the Extension struct as defined in Section 7.4.1.4 of [RFC5246], contain= s a "TokenBindingParameters" value, as defined below. > > struct { > uint8 major; > uint8 minor; > } ProtocolVersion; nit: rename this TBProtocolVersion ? > > enum { > rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) > } TokenBindingKeyParameters; > > struct { > ProtocolVersion token_binding_version; > TokenBindingKeyParameters key_parameters_list<1..2^8-1> > } TokenBindingParameters; > > "token_binding_version" indicates the version of the Token Binding > protocol the client wishes to use during this connection. This > SHOULD be the latest (highest valued) version supported by the > client. [I-D.ietf-tokbind-protocol] describes version {1, 0} of the > protocol. add: "RFC Editor - please remove for RFC publication: Note to implementers - " > Prototype implementations of Token Binding drafts can > indicate support of a specific draft version, e.g. {0, 1} or {0, 2}. new parag.. > "key_parameters_list" contains the list of identifiers of the Token > Binding key parameters supported by the client, in descending order > of preference. > >3. Token Binding Negotiation Server Hello Extension > > The server uses the "token_binding" TLS extension to indicate support > for the Token Binding protocol and to select the protocol version and > key parameters. > > The server that supports Token Binding and receives a client hello > message containing the "token_binding" extension, will include the > "token_binding" extension in the server hello if all of the following > conditions are satisfied: > > 1. The server supports the Token Binding protocol version offered by > the client or a lower version. > > 2. The server finds acceptable Token Binding key parameters on the > client's list. > > 3. The server is also negotiating Extended Master Secret [RFC7627] > and Renegotiation Indication [RFC5746] TLS extensions. This > requirement only applies when TLS 1.2 or an older TLS version is > used (see security considerations section below for more > details). > > > The server will ignore any key parameters that it does not recognize. > The "extension_data" field of the "token_binding" extension is > structured the same as described above for the client > "extension_data". > > "token_binding_version" contains the lower of the Token Binding > protocol version offered by the client in the "token_binding" > extension and the highest version supported by the server. > > "key_parameters_list" contains exactly one Token Binding key > parameters identifier selected by the server from the client's list. > >4. Negotiating Token Binding Protocol Version and Key Parameters > > It is expected that a server will have a list of Token Binding key > parameters identifiers that it supports, in preference order. The > server MUST only select an identifier that the client offered. The > server SHOULD select the most highly preferred key parameters > identifier it supports which is also advertised by the client. In > the event that the server supports none of the key parameters that > the client advertises, then the server MUST NOT include > "token_binding" extension in the server hello. > > The client receiving the "token_binding" extension MUST terminate the > handshake with a fatal "unsupported_extension" alert if any of the > following conditions are true: > > 1. The client did not include the "token_binding" extension in the > client hello. s/client/server/ and s/client hello/ServerHello/ ? plus some other cleanup= s, e.g.: 1. The server did not include the "token_binding" extension in its ServerHello message. > 2. "token_binding_version" is higher than the Token Binding protocol > version advertised by the client. append: ..in its ClientHello message. > > 3. "key_parameters_list" includes more than one Token Binding key > parameters identifier. > > 4. "key_parameters_list" includes an identifier that was not > advertised by the client. > > 5. TLS 1.2 or an older TLS version is used, but Extended Master > Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS > extensions are not negotiated (see security considerations > section below for more details). > > If the "token_binding" extension is included in the server hello and > the client supports the Token Binding protocol version selected by > the server, it means that the version and key parameters have been > negotiated between the client and the server and SHALL be definitive > for the TLS connection. move 3d chunk below up to here as a "NOTE:" > In this case, the client MUST use the > negotiated key parameters in the "provided_token_binding" as > described in [I-D.ietf-tokbind-protocol]. Does this stipulation really belong in this spec? ISTM more appropriate to= stipulate this in -tokbind-protocol. > If the client does not support the Token Binding protocol version > selected by the server, then the connection proceeds without Token > Binding. there are security considerations here, yes? how does the app layer know that TB was not negotiated? > Please note that the Token Binding protocol version and key > parameters are negotiated for each TLS connection, which means that > the client and server include their "token_binding" extensions both > in the full TLS handshake that establishes a new TLS session and in > the subsequent abbreviated TLS handshakes that resume the TLS > session. Move this parag up above as a "NOTE:" > >5. IANA Considerations > > This document defines a new TLS extension "token_binding", which > needs to be added to the IANA "Transport Layer Security (TLS) > Extensions" registry. > > This document establishes a registry for identifiers of Token Binding > key parameters entitled "Token Binding Key Parameters" under the > "Token Binding Protocol" heading. > > Entries in this registry require the following fields: > > o Value: The octet value that identifies a set of Token Binding key > parameters (0-255). > > o Description: The description of the Token Binding key parameters. > > o Specification: A reference to a specification that defines the > Token Binding key parameters. > > This registry operates under the "Expert Review" policy as defined in > [RFC5226]. The designated expert is advised to encourage the > inclusion of a reference to a permanent and readily available > specification that enables the creation of interoperable > implementations using the identified set of Token Binding key > parameters. > > An initial set of registrations for this registry follows: > > Value: 0 > > Description: rsa2048_pkcs1.5 > > Specification: this document > > Value: 1 > > Description: rsa2048_pss > > Specification: this document > > Value: 2 > > Description: ecdsap256 > > Specification: this document > >6. Security Considerations > >6.1. Downgrade Attacks > > The Token Binding protocol version and key parameters are negotiated > via "token_binding" extension within the TLS handshake. TLS prevents > active attackers from modifying the messages of the TLS handshake, > therefore it is not possible for the attacker to remove or modify the > "token_binding" extension. The signature algorithm and key length > used in the TokenBinding of type "provided_token_binding" MUST match > the parameters negotiated via "token_binding" extension. suggestion for 2nd sentence: TLS prevents active attackers from modifying the messages of the TLS handshake, therefore it is not possible for the attacker to remove or modify the "token_binding" extension without detection by the TLS layer, as long as the following stipulation regarding the Triple Handshake Vulnerability is adhered to. the last sentence.. The signature algorithm and key length used in the TokenBinding of type "provided_token_binding" MUST match the parameters negotiated via "token_binding" extension. ..seems unnecessary in this spec -- it is more properly addressed in -tokbi= nd-protocol and -tokbind-https. in any case, rather than saying "signature algorithm and key length", it sh= ould say "key parameters" > >6.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions > > The Token Binding protocol relies on the TLS Exporters [RFC5705] to > associate a TLS connection with a Token Binding. The triple > handshake attack [TRIPLE-HS] is a known TLS protocol vulnerability > allowing the attacker to synchronize exported keying material between > TLS connections. The attacker can then successfully replay bound > tokens. For this reason, the Token Binding protocol MUST NOT be > negotiated with these TLS versions, unless the Extended Master Secret > [RFC7627] and Renegotiation Indication [RFC5746] TLS extensions have > also been negotiated. > >7. Acknowledgements > > This document incorporates comments and suggestions offered by Eric > Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Bill Cox, > Nick Harper and others. > >8. References _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c11e4050ac38d484df3cb08d3597b6197%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DHlg56W5gcUcHbLHGXxrEqDii%2bKgNCmZelb82R2tmCW8%3d From nobody Mon Apr 4 03:58: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 A5E2C12D0C5 for ; Mon, 4 Apr 2016 03:58:19 -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 F8WY6zIB-phL for ; Mon, 4 Apr 2016 03:58:18 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 F17F412D0AC for ; Mon, 4 Apr 2016 03:58:16 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id f1so66297412igr.1 for ; Mon, 04 Apr 2016 03:58:16 -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=wKJyNpaeYfjrL9u2k8eytX2mYebEVwy6GYuFjp2rrWk=; b=bhkDsRBb59Q4pG3ZP5qPLXP3THNlYPnwOXtiqNyukZSunxPI9Jd7XoJS9jQcaJDQ9n rtNXnkaZxTBDDjYg39qnu3+NHYiKIsvMjjkGdkhsBQxoNjXKp8v9gvUDTQnEmYUZ1FD1 qv/fSjfS+9EXnu5Xd8ZT+8LW8G7+a+YSPySPU= 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=wKJyNpaeYfjrL9u2k8eytX2mYebEVwy6GYuFjp2rrWk=; b=gngykXFuQ6jF9bb+xBwCuhAiEkUSCirdeTZAjEoINwv4z4TgbuEjPOnjsDbgyZV4jx 3uzUYCNKGEbO7Bx0hirkpS/xz67clTiXDEj+q7WaPKjN15O0BF9wtA7Z1kj0zLeOTpB3 gs+8f32cE1hGHn8D2WnjAZBAyqqNW/JGqnOZcmTobUKCs4aKnff4VgbikFddWiGjvpMv 1a1FBUtRs10jwmZV4ZZialxzc59ShWmjn6JUXU26ZmT54bTbkEbzd5aRJa51NFTnBiqF 3TxBqnb9ecGgBIch0RYy+VUxl+tg0Myi28+tZozCfyzKxng/E6EYbCrxnf8iUhTwmatS 65HQ== X-Gm-Message-State: AD7BkJJ7rFhmtr+j0QEFtoER9HrAC5cKtg878PfNw2ZMC66P5n3oeRc1mkQ5prIEBEloMLAIVhXvttFrtLAJRk/0 X-Received: by 10.107.162.7 with SMTP id l7mr6827710ioe.147.1459767496271; Mon, 04 Apr 2016 03:58:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Mon, 4 Apr 2016 03:57:46 -0700 (PDT) In-Reply-To: References: <56EF4B9B.7000609@KingsMountain.com> From: Brian Campbell Date: Mon, 4 Apr 2016 07:57:46 -0300 Message-ID: To: Dirk Balfanz Content-Type: multipart/alternative; boundary=001a1140e6381200f3052fa69bbe Archived-At: Cc: IETF Tokbind WG , =JeffH Subject: Re: [Unbearable] Referred token binding IDs 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 Apr 2016 10:58:19 -0000 --001a1140e6381200f3052fa69bbe Content-Type: text/plain; charset=UTF-8 +1 to HTTPSTB indicating that servers identified by IP addresses will get keys scoped to that exact IP address. On Mon, Mar 21, 2016 at 3:03 AM, Dirk Balfanz wrote: > > I'd say that servers identified by IP addresses will get keys scoped to > that exact IP address - just like cookies. I think it belongs in HTTPSTB as > a SHOULD for web browsers. > > Dirk > --001a1140e6381200f3052fa69bbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to HTTPSTB indicating that servers identified by IP add= resses will get keys scoped to that exact IP address.

On Mon, Mar 21, 2016 at 3:03 A= M, Dirk Balfanz <balfanz@google.com> wrote:

I'd say that servers identified= by IP addresses will get keys scoped to that exact IP address - just like = cookies. I think it belongs in HTTPSTB as a SHOULD for web browsers.=C2=A0<= /div>

Dirk

--001a1140e6381200f3052fa69bbe-- From nobody Mon Apr 4 04:43:13 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 D613512D516 for ; Mon, 4 Apr 2016 04:43:11 -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 jVs4GqsdCIKn for ; Mon, 4 Apr 2016 04:43:10 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 147CA12D1D1 for ; Mon, 4 Apr 2016 04:43:10 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id g8so23138067igr.0 for ; Mon, 04 Apr 2016 04:43:10 -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=UWiSR5vlBwLT8VVdvjfeAJGDVkZ3Ttze4jmdiVluxtI=; b=OLP0DL4SC7zGOsx2JF+GUCr6YDMdDwWgRe1rCibhj1tIiod+n/xG09swycjlc2Lj6U ER+GmNkO4N1aiXcUMqwNyBBUYqzSu5+id0AfQtI7wJBSmMNXpn/APyDKZ6CPoW6XKVAs 2sQT2vlyFNVfmSPfdQfgpLxcnpDUJG4WX5sKA= 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=UWiSR5vlBwLT8VVdvjfeAJGDVkZ3Ttze4jmdiVluxtI=; b=BK4VqJMxj/V9jLLhR2m6mpnr5GxzQgIz6sDLxjw48a7UA8ZLWKr/iWtKTXnaXr+CGj lPfKc9p+bVI5WtQiHA6ng0f0xHOKweU65sbHl0bZ6fbi999nOZVxFRlA78E1okuVzPsi A+AW/Dl5TiMVCI8a9KVmXdIziO/FhPa+lnuu8Vna+q9qKlOzLIslpWZmakFkpPrsGEy3 oOyeJFjR64QMRncdDEyc4P+as5ci98hJdHDwzZhwjMFETB74klb5010Wjvdp9RxHHsff rfmYVcZMS2m7sTVxy8FPvuiWo97UaVt1/iaWmCS34VmGe5goxVX2VmLZT1BZX+t2xAQ/ B3CQ== X-Gm-Message-State: AD7BkJJJgRA/UhzFDP3WYmKw6uLkzOcx6exuKsfAzgjvuY7+2DRuemOpkGPqu7bFxFZy9ReY7hfqnLWVNxKTpasM X-Received: by 10.50.108.108 with SMTP id hj12mr9373208igb.57.1459770189265; Mon, 04 Apr 2016 04:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Mon, 4 Apr 2016 04:42:39 -0700 (PDT) In-Reply-To: References: <56FAA372.1000400@KingsMountain.com> From: Brian Campbell Date: Mon, 4 Apr 2016 08:42:39 -0300 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=089e0149392a95de24052fa73be1 Archived-At: Cc: IETF Tokbind WG , =JeffH Subject: Re: [Unbearable] Referred token binding IDs 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 Apr 2016 11:43:12 -0000 --089e0149392a95de24052fa73be1 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 29, 2016 at 2:26 PM, Nick Harper wrote: > On Tue, Mar 29, 2016 at 8:46 AM, =JeffH > wrote: > >> >> I was toying with a similar idea and it seemed to me that the set of TBIDs >> conveyed in the TBMSG to whatever server could possibly grow unbounded... >> >> This won't grow more than whatever the browser's redirect limit is (in > Chrome this is 20), since this would only apply for a single chain of > redirects. > Still, a TokenBindingMessage with 20 TokenBindings could be rather large (especially if some/many of the TokenBindingIDs are RSA keys) and enough to cause or exacerbate issues with header size limits in some servers. --089e0149392a95de24052fa73be1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Mar 29, 2016 at 2:26 PM, Nick Harper <nharper@google.com>= wrote:
On Tue, Mar 29, 2016 at 8:46 AM, =3DJeffH <Jeff.Hodges@k= ingsmountain.com> wrote:

 I was toying with a similar idea and it seemed to me that the set of TBIDs<= br> conveyed in the TBMSG to whatever server could possibly grow unbounded...
This won't grow more than whatever the bro= wser's redirect limit is (in Chrome this is 20), since this would only = apply for a single chain of redirects.
=

Still, a TokenBindingMessage with 20 TokenBindings coul= d be rather large (especially if some/many of the TokenBindingIDs are RSA k= eys) and enough to cause or exacerbate issues with header size limits in so= me servers.=C2=A0


--089e0149392a95de24052fa73be1-- From nobody Mon Apr 4 05:07:18 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 34F1312D5A6; Mon, 4 Apr 2016 05:07:17 -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.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404120717.15618.97085.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 05:07:17 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-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: Mon, 04 Apr 2016 12:07:17 -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-05.txt Pages : 14 Date : 2016-04-04 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-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 Mon Apr 4 06:12: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 9BB0712D0E4 for ; Mon, 4 Apr 2016 06:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=buckeyemailosu.onmicrosoft.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 Lfhk79XR1Are for ; Mon, 4 Apr 2016 06:12:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.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 837FB12D0CA for ; Mon, 4 Apr 2016 06:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CwFb1DMDXJGgBLM9kNsrIVYrmMVJQOOqiHPEgJQw0QA=; b=IHAAXRCyf1xZ1dt05dIUT5g2/5A2wtNZlefNHY0tLYWAtkdLqyxc76VHKxU8NTROts8AOCKtC2L9F/z7gQ35kbI8Z4tQ8xeOnTLfLsvxsXQcliYuXap9eeYBI7h1bqCS9HJmUAbDtcOqZpEfK1E4g6siTQHsBav4/fAERov8QG8= Received: from SN1PR01CA0031.prod.exchangelabs.com (10.165.224.41) by BL2PR01MB1905.prod.exchangelabs.com (10.167.95.149) with Microsoft SMTP Server (TLS) id 15.1.453.11; Mon, 4 Apr 2016 13:12:44 +0000 Received: from BL2FFO11OLC016.protection.gbl (2a01:111:f400:7c09::159) by SN1PR01CA0031.outlook.office365.com (2a01:111:e400:7be0::41) with Microsoft SMTP Server (TLS) id 15.1.453.11 via Frontend Transport; Mon, 4 Apr 2016 13:12:44 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.208) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.208 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.208; helo=cio-krc-pf01.osuad.osu.edu; Received: from cio-krc-pf01.osuad.osu.edu (164.107.81.208) by BL2FFO11OLC016.mail.protection.outlook.com (10.173.160.82) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Mon, 4 Apr 2016 13:12:44 +0000 Received: from CIO-KRC-HT01.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-krc-pf01.osuad.osu.edu (Postfix) with ESMTPS id 75317A0073 for ; Mon, 4 Apr 2016 09:12:43 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 09:12:43 -0400 From: "Cantor, Scott" To: "unbearable@ietf.org" Thread-Topic: Suggested change in wording for signal to send referred binding Thread-Index: AdGOcx9OZASbgMqRRlCfx9/WNqeQhQ== Date: Mon, 4 Apr 2016 13:12:41 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1128AD86A@CIO-TNC-D2MBX02.osuad.osu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.255.123] x-header-sapphire: true Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.208; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(199003)(54356999)(50986999)(2900100001)(97756001)(87936001)(2920100001)(5640700001)(2930100002)(6806005)(86362001)(75432002)(90282001)(11100500001)(5250100002)(92566002)(189998001)(2351001)(46406003)(66066001)(47776003)(109096001)(89122001)(5008740100001)(5004730100002)(229853001)(2501003)(110136002)(106466001)(107886002)(450100001)(3846002)(6116002)(102836003)(23726003)(2906002)(5003600100002)(586003)(33656002)(50466002)(16796002)(1096002)(1730700002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR01MB1905; H:cio-krc-pf01.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC016; 1:njRIz/DHTSktlewnz63lju8e9orQfOj19i+Tw/vhD00vGV6z9NIjJJt/DIPiQy4n6kXk24VRDGn64uOnr9f3cGDuHET5wce78P84ogGJvmvCghj77nlIXiyIyngESPXtrBKGL9wRN4yFe8ppFD2yxbhScA9BRsn0gMnkdn1dmq/OXUfWLJMKZ6zeFKuiXYWyvSRAMushhSrAlfpw8H/O1Wtn/rUKPB1I25C/OWxnTUAuQWuS3WBDbaXeKEqCFAjuBvig8C8Ujg0OfzehwGymDUwxY4vrnMA+ia7oYUDS/+3xXIAqfhdA1wkaAz6rG9pA5c+znmGtgUZHmRCZXqSikurXD1xOopptae0u5/S6fldxQCGm45FrjKlVeMRocLj5Pe3NSQuYJU8tKSh/NbezuBmX3MkazkwOTnTWKGbo+QDKGpiHlabOm3aIRxT67FAPykDz75PWmspCN0J1gyxXTSkjpBpwkdKQ/P+SZdwlTYq+enCs+VepWvgGT6OBh2Md X-MS-Office365-Filtering-Correlation-Id: 5dc7465f-3d03-45f0-de28-08d35c8acf89 X-Microsoft-Exchange-Diagnostics: 1; BL2PR01MB1905; 2:a6sQdi5dSeAh56ig0PtsqD0JQiWcMp7prq/4UbRU0XAcQFw+NzVUBPYPb4pCs/V91y5SzV5eCOEF0Y/7s5lDabJeK4N3LE1UUug/rYd7Eox19INER5hYE09OKlq4uoAOhnEI5nPky8JwkNC0rY+bAwXJEjJd4JzV2P7nvSSNbtXv2jF54svDKOJzZAGBTTmo; 3:wRH59AR7QxAiljRqKjQBWBrIE37RhJBb8aes8tZzD+ThzUaRY6SyPdI61OQLiROede0qe3j8EDJJPwyptKx43C5pabXrtXvZUmUBnJTscfvlv6IRc3jOjncKXquoQuz1759jTYp+Am/B0dJXftilzQu/tlRiD9olVGn2mLKG6lJEg1uxgoPIJ3GYttdC6eb3RpyDq0ooKjfjtHgaxj9AMdPuJ3zGh9b5aiJVGBfO0vl4667uAvTKrw7AQneDZ9h4B2CfqhE8Ay7F8AuWUX9GYQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2PR01MB1905; X-Microsoft-Exchange-Diagnostics: 1; BL2PR01MB1905; 25:nvtTny+vdbiUwB20cPLKnOzPMKBlq6+EeFDsejT+ny7oSPxFo666A0yrzxcKft3AQYEefW3o+u7AQ2iiqX+35CfVaZg9rLpCIRmp5bQQ7ilyzHuFysdYeP0ZkGLM+GveiZ7pcNDhyPzLr5Ac48E6V7c5HiUoe7LR0kfwLgr2AuIBxaiZP50LKHpxSuREiT4rSItmpQzL4H/Rjy9jGLXsKrgo6Pt8p0y9tiyoaE2CaTlluiEDxFXa9v6fM7qDa6ZfLlJ9UnyFRFx6cKHYr2BsOpyWxd0upM4b3/4eJqgDYp71UsjaV7LCI3Mly92PyTBFC5icdj2K+pEXtV1s1DF/pZ3FB3mGX34+RTSWRZJXIBgr+2P9z25IqbybdebsnVvK4uNzHZYBnBb/jz+/7WvKCTGV6qMV+/vYeT/MFMOiUbuw8Bm3u6SPvpSmPUUhOL3CywjjT2MnOa4EBisutsNyZvWpGBxIiq8Z92b3knwe5bzcgLu3DO4ZGF8ZrRluGMXwp4wBk90b7CuEMxmSKOP55nGtPwygd9vbe8PWxRsEru8r6aT/aEb3FGjWjXz1ciG9DCA03NpzqLdvVKZBm+40KVkR43ZbBGdAd/V6p1eGs0geooL46IMlx+bn4UHBJEvRhnYebhLN2LaYOebcf+Yeig== X-Microsoft-Exchange-Diagnostics: 1; BL2PR01MB1905; 20:Ot4SCPMIEetW7solD9UQAH+6s7wr/qZNxZBEnx/BwTswzBEm2/cahdOymKU6q6VTtNUgHXjd6mcCTcWRJgGoyLnczm8k+2t4AsqOteztzESJDyYeezaMSyHpd3u3TRJOiKf60r/+v26FZEJcw9svSEgd0v8wBrXI6UylSHthts2CEiNH/OfYO4cXYuj32Ln4BHgYI3Ah3EjkyYRMCY2tvqnfCdnHaZZAO+RYxkXRU08jeAIbSRw5pUQsGYdz6ypBB1mNFKR6FCjQqi8XVIspL2u6oVDsgO1NnvhDgWqspeDliJ8xl95pGZwexYpnWTs/9NrxiAaDwQsnK7xZVLmNbMFa3w8DVha1SNrgKejyWRtZx+qYN3FReo0qCTYeOy+aU9Wh95+P5TysbOa/2jG12Qg67dOkiFUr4x8kbXjWz4b32AIiqqoZWlvFpBTAaBBYaehCRoplRYLkdtqweBS56mMp/nCU0VYbOGuiVwlazYOSDwRaq0xuPfs+VnS0j5Py; 4:Ri03GRDasDsFJumzZLNtJoTdw6ZuIsJta/9aQmOSM0ZbXPC6maEHSv8BhOgwasDyJPsCDKF22NG+YZy1NOF8kOxrgbdoY+ACEirlozOqws1p049QJSvrmlypsEj/7dlq2JNHTzB/Gdt+fBHhhGRagj2zteb6Qx8Un7lHycEk8Osz8ttxN2xb/7a0uY9ICMDNEg+NBDSpS9GBQ6EH71VjQUyEykGNG38BRArOotTGNwyXjdBcCzKWyE1zKZOtWQjFlkM4/hcqNXNgkSJIEhLZv4qoW4K0aefaCRmEwT1CGSECqmZtsffm3vdLuC4tk+w69l2d4f3bdTu7Qk8mxoBH4EWPnEkqKOJQ86iWWG9dkn9zSY2kQK3dkXF3kdUdv23Hv8Qj/BxRMeqKpiE/SBKWNhuTJxD5FtIDwRk/5p2cin71obl+8/ofhTRoZoRXxvvs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(13023025)(13018025)(13017025)(13015025)(13024025)(8121501046)(10201501046)(3002001); SRVR:BL2PR01MB1905; BCL:0; PCL:0; RULEID:; SRVR:BL2PR01MB1905; X-Forefront-PRVS: 0902222726 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR01MB1905; 23:7q/MGUa6RsVNOdG3adjRVT++GMYadIqNHAJhJjZ/L?= =?us-ascii?Q?DNiXflKWdTahLEkqYlnIyeTUXI10jTRqLSZXXK+o70W7N8dmcjzl6BuADr1h?= =?us-ascii?Q?cXF0wMzBLUBQseap944AK6wNPBRb1aqCwCSzljav4+7PxciYj2wO9F9lDgA0?= =?us-ascii?Q?ZbtM1vXpLXvZWmy4J83xqvy1L4U0RyD37Fkzfiei2TXWJTrwIC+5+RuGHtji?= =?us-ascii?Q?49ue7umHom3qxO7bQdv7+NjVclGymIZpzFQEUGDE8XBiJT3XV8bLz3L4I/Az?= =?us-ascii?Q?KKWoxhV4wFNPnGljeSqjlUo23S98dPVResIhvxbWIZuDwZaR6F+gDTRUqfG5?= =?us-ascii?Q?PpzdoLOjIdU+5UIi/+u5Zkh2TwWuh2ffUCttY+zTq00yl+g4NOqzxbbUl8nd?= =?us-ascii?Q?ilFSEjJ1NZwiuwcHb7qVzmiOktDi4Aajoco9T/fIP0WqEinNi2JLjb9y6S34?= =?us-ascii?Q?ehCv9VO3U/4POOVjWcsa08s40Bp7jP6BEpJN6m1oF6zO/KgtnvvT/FxJmAjd?= =?us-ascii?Q?Ox3eDfs7qIVoBQlcaje3lSMJ+M/eA7Hb4WguNL+obaxL2BnT0Z/cTC22Aj0m?= =?us-ascii?Q?kb9tOIXj8jiXjDM3+f8GwXQAzb2BDJoQ9NekbR2SpbR3L9vnE9CIu2IgIDhw?= =?us-ascii?Q?hNZ9tJvovd8PE/+VbhH3lbHKSKCq+bbP3zlG6ISGICWUPaEOdONI6quHbsFS?= =?us-ascii?Q?liMPruE6pJr9MBPDSClHri2HQREIyvQCfBtSNjtCto8oVYA5+fFieUe4/3sd?= =?us-ascii?Q?A7TglIfFM8O62xrIxyg388iPVw6O+3QwxagshC1VqHAPgf7Y5lpk+zZ60LAO?= =?us-ascii?Q?Sfmxbsf9xcfAWpOyxqIH0SRvtOKGomANrC8BzNSOhUGAkJCZDrGXmOOmSIw+?= =?us-ascii?Q?L60U/mKjx+ObLTAklqUQ5OvKMi3HHo/SXxoUVf3UVoHSQ7hoSoStSaaODO5G?= =?us-ascii?Q?ZD3waDBl3BIYjCX2WGnaK2KTuY3LP8ak17DpO4EHtzc/AC6byDsWjGu87dvJ?= =?us-ascii?Q?mJzEf28xzKlFCS2+lpV+ECU02mHImbUQ5MECe45SDnvXq07c4AvGeAEU+nWN?= =?us-ascii?Q?VDhf7TILp1xponbNgHsD+BIk3tH8sx/CXPGlHCRJpc3WT8WXWiRC7AB2ghoR?= =?us-ascii?Q?XtAvJ8lujRMyuFCIv0EApgGBfK8Li/RungXxJU/D6j3GvrkZreEhUFkxwkOP?= =?us-ascii?Q?vgHpt7zCvppXElAZRmD9oguR+0Q79J8kRPsPjrfZ3GaUJbFmCP8nH7saA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR01MB1905; 5:8bxeV96P0k2JXNF1DZ3+3nQ5d2oWJeeKgWSFFWteGRU6+s2BgqTh/IeqZk4JaEXk/zvcexLJUuNCwPXzpi6OcNg8ZyV0XjcmlTF1T4kKI0dv4e9iQXL8sk1rLQM0p4GxGdTLsDibglyRm3Xnn3qvYg==; 24:bgKTma7BBBTJGoIOipFzLwBclDEcjLEQoUXaeutDxsg35K6XzZJmtttL4qUNwD4tAaZjx+wFpe2vI/w5ARnJSAT4Ybdtk36AoSc0u6+3R54=; 20:BGDp0PRU9IdsoI8OBPp0nhtQKF/QWSp6M3pNucBUPkwPjIts+pgyvX2nu1MzWSfQL2T70zH4tLSf7gGaVT5MY0HShGpEB0RrVXHaShB5X6AnRZEZ+vmJcyy34yXVQMXxjdSiR/ImhaYtQHrZINoXZGeTu9nz6frfRkqYHMbyF3c= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2016 13:12:44.5441 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[164.107.81.208]; Helo=[cio-krc-pf01.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR01MB1905 Archived-At: Subject: [Unbearable] Suggested change in wording for signal to send referred 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 Apr 2016 13:12:47 -0000 This isn't terribly substantive, but it jumped out at me while I was readin= g these drafts for the first time. The tokbind-https draft mentions the tok= en consumer giving the client "permission" to send a referred token binding= to the token provider. That struck me as strange wording, as though the RP is in a permission to d= ictate this or that it "owns" the binding. My sense was that revealing a to= ken binding is more of a privacy consideration and that the bindings are re= ally more thought of as being owned by the client. I got the impression that the purpose of the header in that draft was more = about signaling to the client that the destination of the redirect wants/ne= eds the binding, and that the client should (if it deems it appropriate) se= nd it. The tone of the draft seemed to give the agency to the RP, and it seemed to= me the client should have the agency, not be asking permission of the RP. Is that fair? -- Scott From nobody Mon Apr 4 07:54: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 7EF1912D616 for ; Mon, 4 Apr 2016 07:54:50 -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 zVlus2wKo1WC for ; Mon, 4 Apr 2016 07:54:44 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 D66E912D754 for ; Mon, 4 Apr 2016 07:54:18 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id f1so75141873igr.1 for ; Mon, 04 Apr 2016 07:54:18 -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=h21ubd0G0UE1AeZokB0vxefOPSu+12/Y2XbXmE0p5m8=; b=AVlThiauH1Txz82t9yQDhnO8I+GdFxH7WCzmQzGrIYtSOJMOiaNjqk3FP5eREk/a74 XQUIa3R0YjVcrxho+41edxmOcCccRQf97IYgz+wzbnc4mzcqnFBVIOKWmQ/hTwmopruu dHaENPrX2HCf/BbtIkTyhQ+skBV5IbtcykThY= 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=h21ubd0G0UE1AeZokB0vxefOPSu+12/Y2XbXmE0p5m8=; b=Wdhf3JUFCdwq1fOo7ZwWx4TKHKSXq4HGcNKIOJDQzo6KFcQJBCtXIJ4Musr652iYyU x7zRe3y55673f6riFkbG2nkdYfZt2xMqz/2rKX5xvp1Cf70NHQqdhZkkiaCVJY0W6yTi Pvm5bsQDKX/2j1fvd/Jb6fnvouJkUk2Mqf5fKmdRy91bwK1DyR7Cc0LtRjZGv+lgyRMT nmvTz+m55p2S+JjWyGw10AKtztuOs8WmbStY1nVty4gpvTdkxSUxjNJKc7r2J5Sa+01r B5dKcuxxkjUNyPxAvO6nHOb94LJdc4360B2w3YbjTzg5PTSM9LKutrTTFisVj7MibzMJ 8aOg== X-Gm-Message-State: AD7BkJIC2wfFcH1KiJcROv9r6zMBsdGacsczPwYt1/3LZLYu7v1EbvKdzi9Ir5CTMv/R4UsNTIhCWwby8gq4faYh X-Received: by 10.50.108.108 with SMTP id hj12mr10394020igb.57.1459781641561; Mon, 04 Apr 2016 07:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Mon, 4 Apr 2016 07:53:31 -0700 (PDT) In-Reply-To: <56FAAD89.6060005@KingsMountain.com> References: <56FAAD89.6060005@KingsMountain.com> From: Brian Campbell Date: Mon, 4 Apr 2016 11:53:31 -0300 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=089e0149392a324153052fa9e606 Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] Referred token binding IDs 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 Apr 2016 14:54:50 -0000 --089e0149392a324153052fa9e606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (I said this in the meeting today too but was 1/2 way though writing this when the meeting started so figured I'd just finish it and send anyway) There's at least one flexibility mismatch that, I think, will be unavoidable. An "IDP-initiated" or "unsolicited" SSO starts at the IDP and delivers a federated token to the RP without the user/user agent previously or recently interacting with RP. So I don't know that it's possible to have an exact match between what's possible at the different layers. And I think I'm siding with Dirk, Andrei, et al. here that a single referred TB is good enough. Some deployments may have to adjust their flow to fit within that, if they wish to leverage TB. But that should be a minority and I think that's okay. Trying to accommodate a bunch of different use cases and flows of starting at one place and ending at another will add a lot of complexity that I don't think is worth it as it may impede implementation and significantly expand the attack surface. On Tue, Mar 29, 2016 at 1:30 PM, =3DJeffH wrote: > Andrei wrote: > > If we wanted to short-circuit the return path, so that IDP2 can redirec= t > > back to the RP, then indeed we=E2=80=99d need to convey TBID_RP to IDP2= , > > given the flexibility extant in federation frameworks, not facilitating > the above will yield a flexibility mismatch between the latter and > tokbind-https. > > we /can/ say "that's the way it is, live with it", or we can work to > address it. > > in any case, I've posted a plea for review & feedback to a federation > deployment mailing list, we'll see whether they have any cycles to > contribute. > > > =3DJeffH > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --089e0149392a324153052fa9e606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(I said this in the meeting today too but was 1/2 way= though writing this when the meeting started so figured I'd just finis= h it and send anyway)

There's at least one flexibilit= y mismatch that, I think, will be unavoidable. An "IDP-initiated"= or "unsolicited" SSO starts at the IDP and delivers a federated = token to the RP without the user/user agent previously or recently interact= ing with RP.

So I don't know that it's possible = to have an exact match between what's possible at the different layers.= =C2=A0 And I think I'm siding with Dirk, Andrei, et al. here that a sin= gle referred TB is good enough. Some deployments may have to adjust their f= low to fit within that, if they wish to leverage TB. But that should be a m= inority and I think that's okay. Trying to accommodate a bunch of diffe= rent use cases and flows of starting at one place and ending at another wil= l add a lot of complexity that I don't think is worth it as it may impe= de implementation and significantly expand the attack surface.


<= br>

On Tue, Mar 29, 2016 at 1:30 PM, =3DJeffH <Jeff.Hodges@kin= gsmountain.com> wrote:
Andrei wrote:
> If we wanted to short-circuit the return path, so that IDP2 can redire= ct
> back to the RP, then indeed we=E2=80=99d need to convey TBID_RP to IDP= 2,

given the flexibility extant in federation frameworks, not facilitating the= above will yield a flexibility mismatch between the latter and tokbind-htt= ps.

we /can/ say "that's the way it is, live with it", or we can = work to address it.

in any case, I've posted a plea for review & feedback to a federati= on deployment mailing list, we'll see whether they have any cycles to c= ontribute.


=3DJeffH




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

--089e0149392a324153052fa9e606-- From nobody Mon Apr 4 10:47: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 EC74F12D55B for ; Mon, 4 Apr 2016 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_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 SZmCcQKtfn-n for ; Mon, 4 Apr 2016 10:47:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8994D12D115 for ; Mon, 4 Apr 2016 10:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pomi6e3Kn3jrOkOUCYsQbyA2OCzrdfZ9bXKdrrKwH7U=; b=PDYIat9MM8QW5sm6pgovdKRqlezfOdXTwtkgtqg3xQ7Ra2+YniShATQ/hudXFKDuVct+LXeI0SlfdPGkarQaQU3itJSt/G/8NrgqDYKOYjfP7gc+FDob+POjJpTg6ms4rIZTu9fRcECbDZn8nYOOXdVKj7WSiJgPzFOwm8Boo3o= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 4 Apr 2016 17:47:20 +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.0447.027; Mon, 4 Apr 2016 17:47:20 +0000 From: Andrei Popov To: "Cantor, Scott" , "unbearable@ietf.org" Thread-Topic: [Unbearable] Suggested change in wording for signal to send referred binding Thread-Index: AdGOcx9OZASbgMqRRlCfx9/WNqeQhQAJW4Zw Date: Mon, 4 Apr 2016 17:47:20 +0000 Message-ID: References: <9846A6064BD102419D06814DD0D78DE1128AD86A@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: <9846A6064BD102419D06814DD0D78DE1128AD86A@CIO-TNC-D2MBX02.osuad.osu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: osu.edu; dkim=none (message not signed) header.d=none;osu.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:176:7072:e3f6:87cc:f35c] x-ms-office365-filtering-correlation-id: edeaba1f-1ac3-48c3-bcbf-08d35cb12bf9 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:4oFrCVdZZDnoQhsI+ZF6v2Ha67855iKGMUy2bY6OIKtvzvq5V+F89cX+nSyNIfDaXoFt+5d5QWfoe/P49OsOkNQ0NKqqhTIyqQQNIdSB668wTpsfHRzRoyS93O1aTzHUk9yrmwbaser2Q3m2czbEFw==; 24:6Qi17qPT297DroGy7HFWmkPZyxCuf/2FwjJ4bznKXsQsBgz/UF3BTZjHpz5oNRT4UnTgFS3kSrzdNRPuKNuS5GF37Pn2a9rOEFMy6ui0+5c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0902222726 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(86362001)(2906002)(99286002)(3280700002)(3660700001)(586003)(2950100001)(81166005)(5004730100002)(5001770100001)(19580405001)(6116002)(102836003)(5003600100002)(19580395003)(86612001)(122556002)(74316001)(107886002)(10290500002)(1096002)(5005710100001)(10090500001)(92566002)(8990500004)(54356999)(2171001)(76176999)(50986999)(87936001)(33656002)(5008740100001)(76576001)(2900100001)(11100500001)(2501003)(189998001)(1220700001)(15975445007)(77096005)(5002640100001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2016 17:47:20.3313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [Unbearable] Suggested change in wording for signal to send referred 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 Apr 2016 17:47:24 -0000 Hi Scott, I agree that "permission" is probably not the best word. This header is ind= eed a signal from the RP to the user agent. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Cantor, = Scott Sent: Monday, April 4, 2016 10:13 AM To: unbearable@ietf.org Subject: [Unbearable] Suggested change in wording for signal to send referr= ed binding This isn't terribly substantive, but it jumped out at me while I was readin= g these drafts for the first time. The tokbind-https draft mentions the tok= en consumer giving the client "permission" to send a referred token binding= to the token provider. That struck me as strange wording, as though the RP is in a permission to d= ictate this or that it "owns" the binding. My sense was that revealing a to= ken binding is more of a privacy consideration and that the bindings are re= ally more thought of as being owned by the client. I got the impression that the purpose of the header in that draft was more = about signaling to the client that the destination of the redirect wants/ne= eds the binding, and that the client should (if it deems it appropriate) se= nd it. The tone of the draft seemed to give the agency to the RP, and it seemed to= me the client should have the agency, not be asking permission of the RP. Is that fair? -- Scott _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c32ea48e2b362493b7f7108d35c8ad361%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DMTabeU7kgEQ%2fLn4ZIsGVMoBFVHwmRRZ4i1sOy%2fEYQ4k%3d From nobody Mon Apr 4 12:16:39 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 3EFBB12D82E for ; Mon, 4 Apr 2016 12:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 E8N7X3U4-eKi for ; Mon, 4 Apr 2016 12:16:26 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 AAE8F12D82B for ; Mon, 4 Apr 2016 12:16:18 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id j9so57995546obd.3 for ; Mon, 04 Apr 2016 12:16:18 -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=cD+UDhJmPPXbrHjY3OSc5BrWDVjGl56Jy1yAPCmYVWM=; b=TI8DT+R7+tEdAszuhnxSeSKyQGiKsnjDqVPlbq8j309FGMmYkYsIj0fZ0+KmWpcCS2 TYAlnFUWqelTDpMH1VLAZmuJv0IbzugnGKafkUKY4NjpvrsIDXBYPJkJzOKt4gmyW8I8 5GuYAAPz2s40NyG00lXVvtxAH57iS1pXfnjGygk7HMTf7zYo9GLcs64ClRRHlv2nMnv3 OUW5cbDx9VNrnbts3qYNMXh+gu0Pa7ZH5Ul1XeS1DIGjG9Pp5sl/YXZYxN9pIpAcLZ1Y l+CrkW566p5nRzF/a1MrCkjNnbNcHXvWDX+8cuPSlq5EUCKYa2nQQSwU7pMb+C3E6PdI d0Uw== 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=cD+UDhJmPPXbrHjY3OSc5BrWDVjGl56Jy1yAPCmYVWM=; b=FIamycoo59Dw3G24Xy8FmZ83wgYepdmX8WNApOjQ6fP0wIqfQsQd6BUT5sE/ELjZCC gAiRgFmM1XhUD8oTlk8KIhbhaoEY7sNqpEfZwAk/H1Bx4Af6cokEF1a1NTbTQh85JK88 3pD+PTPwwL/tP/KmA4xJgLu4AikqIdX1sSPAkPj36mBMUqnS3rQ8ZbL49poCaEXwMaGU 6rKSmgTWU6LvLv6mlp8JKZIy0uVjNSjFqGi00+qdx2+A9G92CFMcNNvkrr1jdbqRgk+F yoe7z+yy7MRaWFL0w8e57q9tif1Gi+N+iAxwrSDolHEmNH5y4t/QCLPZihO9oV2nf5qi ZRRA== X-Gm-Message-State: AD7BkJIcL33g9Px+vKbJ1NFt50h46zQ49vubwOKtlDfcvH8PtwNDmgx1EuQyLiCS8/1VlPicmN0hlDjhsKwSuhJc X-Received: by 10.60.35.201 with SMTP id k9mr11968909oej.3.1459797377956; Mon, 04 Apr 2016 12:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Mon, 4 Apr 2016 12:15:58 -0700 (PDT) From: William Denniss Date: Mon, 4 Apr 2016 16:15:58 -0300 Message-ID: To: "oauth@ietf.org" , unbearable@ietf.org Content-Type: multipart/alternative; boundary=089e011613bc2884b4052fad907e Archived-At: Subject: [Unbearable] OAuth + Token Binding IETF95 F2F Meetup [April 5, 2pm~4pm] 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 Apr 2016 19:16:28 -0000 --089e011613bc2884b4052fad907e Content-Type: text/plain; charset=UTF-8 As we heard today in the Token Binding WG meeting, we need to do some work on the Federation use-case. With that in mind, we have an informal gathering of interested people from the OAuth and Token Binding work groups during IETF95, on the topic of adding token binding to OAuth. When: Tuesday, April 5 from 2pm to 4pm Where: Alerce Room at the Hilton (Level 5, near Quebracho B) If you're interested, please feel free to join us. --089e011613bc2884b4052fad907e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As we heard today in the Token Binding WG meeting, we need= to do some work on the Federation use-case.

With that i= n mind, we have an informal gathering of interested people from the OAuth a= nd Token Binding work groups during IETF95, on the topic of adding token bi= nding to OAuth.

When: Tuesday, April 5 from 2pm to= 4pm
Where: Alerce Room at the Hilton (Level 5, near Quebracho B)=

If you're interested, please feel free to joi= n us.

--089e011613bc2884b4052fad907e-- From nobody Wed Apr 6 11:39:16 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 CF73812D775 for ; Wed, 6 Apr 2016 11:39:14 -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 4TGNdX-sORJq for ; Wed, 6 Apr 2016 11:39:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025F012D668 for ; Wed, 6 Apr 2016 11:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OzNhQQJqhkiEGQ0b8jeF9joHQ9LMb8ZfGFL410HrJEI=; b=mAN9LKCpCodS8cceFL/8RG1s0pViUbRF56Fu4JeZmpap5288WoKqk1lZaSJ6ykYiO7AOG/Oj740x6SUwkd/aKj1wNX8lHia/cdpwj+FdiwkVs63Z251zrJmLW4MZ5KqcwG7u8xvpJg1yLh5be7cynQ6hcYSusX9mY3SX4ZqNPVQ= Received: from BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) by BL2PR03MB209.namprd03.prod.outlook.com (10.255.230.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 18:38:47 +0000 Received: from BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.18]) by BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.18]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 18:38:47 +0000 From: Andrei Popov To: "unbearable@ietf.org" Thread-Topic: TB APIs in (ASP).NET Thread-Index: AdGQM1fWL9M/KyJKRPK7MO4fEfmqWQ== Date: Wed, 6 Apr 2016 18:38:30 +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;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.180.216] x-ms-office365-filtering-correlation-id: 22cb2e47-9ce6-452c-9fff-08d35e4ab086 x-microsoft-exchange-diagnostics: 1; BL2PR03MB209; 5:3kpg4A3PrHt35BRBFD5+AcdZx3T5u58PCWkWblf2XU91mP4JCnDw+1Kx18sLazn0ECaX2ZKcfOrV+0DVrxAWzf4aPPu1nPHL6ujD0I/xQLoVA9Gni4d3kZw+d96iz+gsKDia9jcOCh86azvrnM4Iew==; 24:x/yl6iAckvXjaXFdrvLsaQioDZfOXDRuRD7lXy+PAXVIPW81bdSKx4v/127W5FN9KbjvaYCmObS+LwBYyTIn/XJWrDIizK7fnhREtrVdagY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB209; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BL2PR03MB209; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB209; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(3905003)(50986999)(8990500004)(92566002)(10400500002)(107886002)(2900100001)(5002640100001)(122556002)(450100001)(5630700001)(5640700001)(54356999)(81166005)(86362001)(97736004)(85806002)(5005710100001)(87936001)(10090500001)(99286002)(5004730100002)(10290500002)(19300405004)(110136002)(19625215002)(66066001)(189998001)(2351001)(33656002)(229853001)(102836003)(790700001)(3846002)(15975445007)(76576001)(5008740100001)(2906002)(6116002)(16236675004)(19580395003)(586003)(11100500001)(86612001)(1730700002)(1220700001)(5003600100002)(1096002)(2501003)(19617315012)(74316001)(3660700001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB209; H:BL2PR03MB210.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB2106CC889D54EA4FB3ECD258C9F0BL2PR03MB210namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 18:38:30.1379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB209 Archived-At: Subject: [Unbearable] TB APIs in (ASP).NET 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 Apr 2016 18:39:15 -0000 --_000_BL2PR03MB2106CC889D54EA4FB3ECD258C9F0BL2PR03MB210namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the meeting on Monday, there were a number of questions about platform s= upport for TB and the APIs available to implementers. Here are some links to (ASP).NET TB API documentation: ASP.Net: http://referencesource.microsoft.com/#System.Web/ITlsTokenBindingI= nfo.cs,4a5e5668f5c31170 .NET code sample (see under "Networking enhancements"): https://blogs.msdn.= microsoft.com/dotnet/2015/11/30/net-framework-4-6-1-is-now-available/ .NET TokenBinding class: https://msdn.microsoft.com/en-us/library/system.se= curity.authentication.extendedprotection.tokenbinding(v=3Dvs.110).aspx Native TB library API, for those who don't believe in garbage collectors: h= ttps://msdn.microsoft.com/en-us/library/windows/desktop/mt269464(v=3Dvs.85)= .aspx Happy coding! Cheers, Andrei --_000_BL2PR03MB2106CC889D54EA4FB3ECD258C9F0BL2PR03MB210namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the meeting on Monday, there were a number of que= stions about platform support for TB and the APIs available to implementers= .

 

Here are some links to (ASP).NET TB API documentatio= n:

 

ASP.Net: http://referencesource.microsoft.com/#System.Web/ITlsTokenBindingInfo.cs,4a= 5e5668f5c31170

 

.NET code sample (see under “Networking enhanc= ements”): https://blogs.msdn.microsoft.com/dotnet/2015/11/30/net-framework-4-6-1-is-n= ow-available/

 

.NET TokenBinding class: https://msdn.microsoft.com/en-us/library/system.security.authentication.ext= endedprotection.tokenbinding(v=3Dvs.110).aspx

 

Native TB library API, for those who don’t bel= ieve in garbage collectors: https://msdn.microsoft.com/en-us/library/windows/desktop/mt269464(v=3Dvs.85= ).aspx

 

Happy coding!

 

Cheers,

 

Andrei

--_000_BL2PR03MB2106CC889D54EA4FB3ECD258C9F0BL2PR03MB210namprd_-- From nobody Thu Apr 7 09:13: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 A6D6E12D1BE for ; Thu, 7 Apr 2016 09:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_RP_MATCHES_RCVD=-0.01] 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 1Ck4YKpXKUcD for ; Thu, 7 Apr 2016 09:13:05 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 9EB1112D148 for ; Thu, 7 Apr 2016 09:12:54 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id k1so105427584vkb.0 for ; Thu, 07 Apr 2016 09:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=gWAX1/ncgigwH0TkA9fEiMRct5dVc9DSVQvvSsMPkEU=; b=PeN4eq0GsaGGZ65cTsXWlVQQgYatVkzRZ8iq6QeFdfCZL+h5ION9VIU1pycFf9HHty 0uAjBDf1JgWNfIgghQLtErlM1iYaqCC3KZhhR1IoBo7SWPyZZpwUzTOccdv8IV5a/HaZ myNABBQs3C1VRibHh5yL+IPq8y5pFjV0uiGlEfZy1vkJx1PYYNjjV9xurILO0anP0o01 DS4fYD23EIU3A1g3KdDZTO/yNiOjuS2Bo1/H/QR7EHx9hPvZprdMcrWYx9DUarUQ4rI6 qfh422cdw9pIhVKBG+Y3t+Z5QSjYEQZVxiUEiHxx4bnwWVwk9s7zBzI1Cw3E/kHFAQqQ V6zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=gWAX1/ncgigwH0TkA9fEiMRct5dVc9DSVQvvSsMPkEU=; b=Me9ruGujlgDjwoTjjHhy28+ReQJUnuOZIzHb5Y7/viQzXJNkNGu9PWfSN621RqgXiU FLVRjJ1VO9vf7NBQFYQ9lQu7mPWwU/XqMIFZmccCpd0B30Pc7U9qOUiq4KpLgo1C7uFt HFjqBT0TJdHUKV3B5GB7lcvCD2zwnfIpZ9wmDOjsWytrLNM26wfvFpDquKVPwYtT9vah HjoYNMezdk96N6lO1o1NK3Bhd1gLZRg/02icybT8mZh2v0ZuIqkoLLrNR8WE+Pgy9Tmt m6VDl4pbjBH/ZERj1TKIkFweAevYSEhcLJmN3mAZgznEAt6RFfoQGasFuMZbMaNMEHt8 si7Q== X-Gm-Message-State: AD7BkJLTmtjvXu0H7UohIAbPRdQmRX3ew7gbU5jvM4GEqjzxsi+njdLMeHFMYfg5Q4i6QLEHqrN9iQTpXwv+SIWB MIME-Version: 1.0 X-Received: by 10.31.134.71 with SMTP id i68mr1807579vkd.46.1460045573534; Thu, 07 Apr 2016 09:12:53 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 7 Apr 2016 09:12:53 -0700 (PDT) Date: Thu, 7 Apr 2016 09:12:53 -0700 Message-ID: From: Bill Cox To: Tokbind WG Content-Type: multipart/alternative; boundary=001a11458eb4c48798052fe75978 Archived-At: Subject: [Unbearable] Support for TLS 1.3 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 Apr 2016 16:13:07 -0000 --001a11458eb4c48798052fe75978 Content-Type: text/plain; charset=UTF-8 TLS 1.3 has these modes of operation of interest, assuming the ECDH 0-RTT mode is dropped: 1) Normal 1-RTT handshakes on every connection 2) 1-RTT hashshake on initial connection, and 1-RTT PSK resumes thereafter 3) 1-RTT handshake on initial connection, and 0-RTT PSK resumes thereafter, where the server provides protection against replay, such as emulating a session cache 4) 1-RTT handshake on initial connection, and 0-RTT PSK resumes w/ stateless servers that allow 0-RTT application request replay Mode 1 is easy. The current TB spec applies directly. Mode 2 is similar to TLS 1.2 resume, where we sign on every resume. I think we should do the TB signature on every resume, just like TLS 1.2. However, we may get some push-back because the only point of 1-RTT PSK resume in most cases will be to avoid extra public key operations. Mode 3 is almost identical in security to mode 2. I think we should also do the TB signature in this mode. By signing the client handshake hash, we ensure that the TB signature is unique, and was made since the RMS was derived. If the TB private key is secured in some hardware thingy, then resumption will not be possible without access to the thingy. Mode 4 is where the server already risks replay attacks and loses some forward secrecy in order to improve scalability by running the servers in a stateless mode. The RMS will be encoded in the ticket, and the same ticket can be used for PSK 0-RTT resume many times. In this mode, there is little additional security to be had by signing the client handshake hash, since the server cannot be sure that the signature is unique, and the proof of possession fails, opening up all kinds of new attacks. Currently, TLS 1.3 does not allow the client to know whether the server has replay protection or not, so the safe thing would probably be to always do the TB signature, even though the additional latency overhead does not seem justified by the additional security benefit when doing stateless PSK 0-RTT resumption. Bill --001a11458eb4c48798052fe75978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TLS 1.3 has these modes of operation of interest, ass= uming the ECDH 0-RTT mode is dropped:

1) Normal 1-= RTT handshakes on every connection
2) 1-RTT hashshake on initial = connection, and 1-RTT PSK resumes thereafter
3) 1-RTT handshake o= n initial connection, and 0-RTT PSK resumes thereafter, where the server pr= ovides protection against replay, such as emulating a session cache
4) 1-RTT handshake on initial connection, and 0-RTT PSK resumes w/ state= less servers that allow 0-RTT application request replay

Mode 1 is easy.=C2=A0 The current TB spec applies directly.

Mode 2 is similar to TLS 1.2 resume, where we sign on ever= y resume.=C2=A0 I think we should do the TB signature on every resume, just= like TLS 1.2.=C2=A0 However, we may get some push-back because the only po= int of 1-RTT PSK resume in most cases will be to avoid extra public key ope= rations.

Mode 3 is almost identical in security to= mode 2.=C2=A0 I think we should also do the TB signature in this mode.=C2= =A0 By signing the client handshake hash, we ensure that the TB signature i= s unique, and was made since the RMS was derived.=C2=A0 If the TB private k= ey is secured in some hardware thingy, then resumption will not be possible= without access to the thingy.

Mode 4 is where the= server already risks replay attacks and loses some forward secrecy in orde= r to improve scalability by running the servers in a stateless mode.=C2=A0 = The RMS will be encoded in the ticket, and the same ticket can be used for = PSK 0-RTT resume many times.=C2=A0 In this mode, there is little additional= security to be had by signing the client handshake hash, since the server = cannot be sure that the signature is unique, and the proof of possession fa= ils, opening up all kinds of new attacks.=C2=A0 Currently, TLS 1.3 does not= allow the client to know whether the server has replay protection or not, = so the safe thing would probably be to always do the TB signature, even tho= ugh the additional latency overhead does not seem justified by the addition= al security benefit when doing stateless PSK 0-RTT resumption.
Bill
--001a11458eb4c48798052fe75978-- From nobody Thu Apr 7 13:55:19 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 5C18912D6F6 for ; Thu, 7 Apr 2016 13:55:13 -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 0XgJTyt2rKdv for ; Thu, 7 Apr 2016 13:55:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC90612D6E8 for ; Thu, 7 Apr 2016 13:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RgX77rqT5ngrkBgdmVt4hVBcZIAJJpBcMB4HxmUp2Cg=; b=QXFAx1T63d+oUmgb0ZvPGSpJSQNiE/OvA+4FeCyssS0fODLAnK8p8K1FLNmE4JFchZ3E/uQKpmLDv5gLL+hqFsKOSJ1++etP5MRJnyedOJ0nvabf56NjUJlrtc/lgQiVyH7s6SfjlZygKKSznMT2Rv+OPiJ3fK+IBHxmtNCW7bI= Received: from BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) by BL2PR03MB209.namprd03.prod.outlook.com (10.255.230.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 20:55:09 +0000 Received: from BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.18]) by BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.18]) with mapi id 15.01.0447.028; Thu, 7 Apr 2016 20:55:09 +0000 From: Andrei Popov To: Bill Cox , Tokbind WG Thread-Topic: [Unbearable] Support for TLS 1.3 Thread-Index: AQHRkOhjvnAQWOug5k+xKTX0EeOFH59+/AhQ Date: Thu, 7 Apr 2016 20:55:09 +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: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:176:2962:e065:ebd8:225d] x-ms-office365-filtering-correlation-id: a7979df5-f04d-41e3-fd10-08d35f26e7cd x-microsoft-exchange-diagnostics: 1; BL2PR03MB209; 5:xE//Sfq0Bt7H3iG87MLgpXMbieS7Ey2VDBu9jDiFnD48u1WNq64fAfTEUrb1gCUfCATIPz+3vTLgL+hZE3xCyh5f8zTFH2Wuq6hJmxeB37AJe8c6MSa7zF0w84ZvT5LtPybbJ1Z7MPJI/DmUGxN1hg==; 24:NDwcdEffwe/0LPHQLwpQwa3XFxn22VBJ9tTfJDv9cP9O7/x0/w4C8V6dXIRbF86DZVrPP9xt481ro1vLl6Qea+BXWKdBuSm7AuKOtbOflp0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB209; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BL2PR03MB209; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB209; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(586003)(11100500001)(19580395003)(19580405001)(16236675004)(86612001)(76576001)(790700001)(5008740100001)(2906002)(6116002)(15975445007)(102836003)(3660700001)(5003600100002)(3280700002)(74316001)(1096002)(86362001)(5001770100001)(107886002)(2950100001)(106116001)(76176999)(19300405004)(1220700001)(50986999)(189998001)(122556002)(2900100001)(5002640100001)(92566002)(5005710100001)(19625215002)(33656002)(54356999)(5004730100002)(10400500002)(85806002)(10290500002)(87936001)(10090500001)(99286002)(81166005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB209; H:BL2PR03MB210.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB2104C25C29F41785D7256F08C900BL2PR03MB210namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 20:55:09.0712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB209 Archived-At: Subject: Re: [Unbearable] Support for TLS 1.3 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 Apr 2016 20:55:13 -0000 --_000_BL2PR03MB2104C25C29F41785D7256F08C900BL2PR03MB210namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBtYWtlcyBzZW5zZSB0byBtZSwgYnV0IEkgdGhpbmsgaW4gY2FzZSAjNCBUQiBkb2VzIG5v dCBoZWxwLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBub3QgYmUgZG9uZSAoZXhjZXB0IHdoZW4gdGhl IFRMUyBtYXN0ZXIgc2VjcmV0IGlzIGFsc28gSFctcHJvdGVjdGVkLCBqdXN0IGxpa2UgdGhlIFRC IHByaXZhdGUga2V5KS4NCg0KQW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgdGhlIGNsaWVudCBoYXMg bm8gd2F5IHRvIGRpc3Rpbmd1aXNoICMzIGFuZCAjNC4gU28gdGhlIG9ubHkgc2VjdXJlIHRoaW5n IGEgY2xpZW50IGNhbiBkbyBpcyB0byBlaXRoZXIgbm90IHVzZSBUQiBpbiAwLVJUVCBvciB0byBt YWtlIHRoZSBUTFMgbWFzdGVyIHNlY3JldCBub24tZXhwb3J0YWJsZS4NCg0KQ2hlZXJzLA0KDQpB bmRyZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBUaHVyc2RheSwgQXByaWwgNywgMjAx NiAxOjEzIFBNDQpUbzogVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFtVbmJlYXJhYmxlXSBTdXBwb3J0IGZvciBUTFMgMS4zDQoNClRMUyAxLjMgaGFzIHRoZXNlIG1v ZGVzIG9mIG9wZXJhdGlvbiBvZiBpbnRlcmVzdCwgYXNzdW1pbmcgdGhlIEVDREggMC1SVFQgbW9k ZSBpcyBkcm9wcGVkOg0KDQoxKSBOb3JtYWwgMS1SVFQgaGFuZHNoYWtlcyBvbiBldmVyeSBjb25u ZWN0aW9uDQoyKSAxLVJUVCBoYXNoc2hha2Ugb24gaW5pdGlhbCBjb25uZWN0aW9uLCBhbmQgMS1S VFQgUFNLIHJlc3VtZXMgdGhlcmVhZnRlcg0KMykgMS1SVFQgaGFuZHNoYWtlIG9uIGluaXRpYWwg Y29ubmVjdGlvbiwgYW5kIDAtUlRUIFBTSyByZXN1bWVzIHRoZXJlYWZ0ZXIsIHdoZXJlIHRoZSBz ZXJ2ZXIgcHJvdmlkZXMgcHJvdGVjdGlvbiBhZ2FpbnN0IHJlcGxheSwgc3VjaCBhcyBlbXVsYXRp bmcgYSBzZXNzaW9uIGNhY2hlDQo0KSAxLVJUVCBoYW5kc2hha2Ugb24gaW5pdGlhbCBjb25uZWN0 aW9uLCBhbmQgMC1SVFQgUFNLIHJlc3VtZXMgdy8gc3RhdGVsZXNzIHNlcnZlcnMgdGhhdCBhbGxv dyAwLVJUVCBhcHBsaWNhdGlvbiByZXF1ZXN0IHJlcGxheQ0KDQpNb2RlIDEgaXMgZWFzeS4gIFRo ZSBjdXJyZW50IFRCIHNwZWMgYXBwbGllcyBkaXJlY3RseS4NCg0KTW9kZSAyIGlzIHNpbWlsYXIg dG8gVExTIDEuMiByZXN1bWUsIHdoZXJlIHdlIHNpZ24gb24gZXZlcnkgcmVzdW1lLiAgSSB0aGlu ayB3ZSBzaG91bGQgZG8gdGhlIFRCIHNpZ25hdHVyZSBvbiBldmVyeSByZXN1bWUsIGp1c3QgbGlr ZSBUTFMgMS4yLiAgSG93ZXZlciwgd2UgbWF5IGdldCBzb21lIHB1c2gtYmFjayBiZWNhdXNlIHRo ZSBvbmx5IHBvaW50IG9mIDEtUlRUIFBTSyByZXN1bWUgaW4gbW9zdCBjYXNlcyB3aWxsIGJlIHRv IGF2b2lkIGV4dHJhIHB1YmxpYyBrZXkgb3BlcmF0aW9ucy4NCg0KTW9kZSAzIGlzIGFsbW9zdCBp ZGVudGljYWwgaW4gc2VjdXJpdHkgdG8gbW9kZSAyLiAgSSB0aGluayB3ZSBzaG91bGQgYWxzbyBk byB0aGUgVEIgc2lnbmF0dXJlIGluIHRoaXMgbW9kZS4gIEJ5IHNpZ25pbmcgdGhlIGNsaWVudCBo YW5kc2hha2UgaGFzaCwgd2UgZW5zdXJlIHRoYXQgdGhlIFRCIHNpZ25hdHVyZSBpcyB1bmlxdWUs IGFuZCB3YXMgbWFkZSBzaW5jZSB0aGUgUk1TIHdhcyBkZXJpdmVkLiAgSWYgdGhlIFRCIHByaXZh dGUga2V5IGlzIHNlY3VyZWQgaW4gc29tZSBoYXJkd2FyZSB0aGluZ3ksIHRoZW4gcmVzdW1wdGlv biB3aWxsIG5vdCBiZSBwb3NzaWJsZSB3aXRob3V0IGFjY2VzcyB0byB0aGUgdGhpbmd5Lg0KDQpN b2RlIDQgaXMgd2hlcmUgdGhlIHNlcnZlciBhbHJlYWR5IHJpc2tzIHJlcGxheSBhdHRhY2tzIGFu ZCBsb3NlcyBzb21lIGZvcndhcmQgc2VjcmVjeSBpbiBvcmRlciB0byBpbXByb3ZlIHNjYWxhYmls aXR5IGJ5IHJ1bm5pbmcgdGhlIHNlcnZlcnMgaW4gYSBzdGF0ZWxlc3MgbW9kZS4gIFRoZSBSTVMg d2lsbCBiZSBlbmNvZGVkIGluIHRoZSB0aWNrZXQsIGFuZCB0aGUgc2FtZSB0aWNrZXQgY2FuIGJl IHVzZWQgZm9yIFBTSyAwLVJUVCByZXN1bWUgbWFueSB0aW1lcy4gIEluIHRoaXMgbW9kZSwgdGhl cmUgaXMgbGl0dGxlIGFkZGl0aW9uYWwgc2VjdXJpdHkgdG8gYmUgaGFkIGJ5IHNpZ25pbmcgdGhl IGNsaWVudCBoYW5kc2hha2UgaGFzaCwgc2luY2UgdGhlIHNlcnZlciBjYW5ub3QgYmUgc3VyZSB0 aGF0IHRoZSBzaWduYXR1cmUgaXMgdW5pcXVlLCBhbmQgdGhlIHByb29mIG9mIHBvc3Nlc3Npb24g ZmFpbHMsIG9wZW5pbmcgdXAgYWxsIGtpbmRzIG9mIG5ldyBhdHRhY2tzLiAgQ3VycmVudGx5LCBU TFMgMS4zIGRvZXMgbm90IGFsbG93IHRoZSBjbGllbnQgdG8ga25vdyB3aGV0aGVyIHRoZSBzZXJ2 ZXIgaGFzIHJlcGxheSBwcm90ZWN0aW9uIG9yIG5vdCwgc28gdGhlIHNhZmUgdGhpbmcgd291bGQg cHJvYmFibHkgYmUgdG8gYWx3YXlzIGRvIHRoZSBUQiBzaWduYXR1cmUsIGV2ZW4gdGhvdWdoIHRo ZSBhZGRpdGlvbmFsIGxhdGVuY3kgb3ZlcmhlYWQgZG9lcyBub3Qgc2VlbSBqdXN0aWZpZWQgYnkg dGhlIGFkZGl0aW9uYWwgc2VjdXJpdHkgYmVuZWZpdCB3aGVuIGRvaW5nIHN0YXRlbGVzcyBQU0sg MC1SVFQgcmVzdW1wdGlvbi4NCg0KQmlsbA0K --_000_BL2PR03MB2104C25C29F41785D7256F08C900BL2PR03MB210namprd_ 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 aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIG1ha2VzIHNlbnNl IHRvIG1lLCBidXQgSSB0aGluayBpbiBjYXNlICM0IFRCIGRvZXMgbm90IGhlbHAsIGFuZCB0aGVy ZWZvcmUgc2hvdWxkIG5vdCBiZSBkb25lIChleGNlcHQgd2hlbiB0aGUgVExTIG1hc3RlciBzZWNy ZXQgaXMgYWxzbyBIVy1wcm90ZWN0ZWQsIGp1c3QNCiBsaWtlIHRoZSBUQiBwcml2YXRlIGtleSku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Bbm90aGVyIHByb2Js ZW0gaXMgdGhhdCB0aGUgY2xpZW50IGhhcyBubyB3YXkgdG8gZGlzdGluZ3Vpc2ggIzMgYW5kICM0 LiBTbyB0aGUgb25seSBzZWN1cmUgdGhpbmcgYSBjbGllbnQgY2FuIGRvIGlzIHRvIGVpdGhlciBu b3QgdXNlIFRCIGluIDAtUlRUIG9yIHRvIG1ha2UgdGhlDQogVExTIG1hc3RlciBzZWNyZXQgbm9u LWV4cG9ydGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENv bXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzp1bmJl YXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJpbGwgQ294PGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDE6MTMgUE08YnI+DQo8Yj5U bzo8L2I+IFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtVbmJlYXJhYmxlXSBTdXBwb3J0IGZvciBUTFMgMS4zPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRMUyAxLjMgaGFzIHRoZXNlIG1vZGVzIG9m IG9wZXJhdGlvbiBvZiBpbnRlcmVzdCwgYXNzdW1pbmcgdGhlIEVDREggMC1SVFQgbW9kZSBpcyBk cm9wcGVkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4xKSBOb3JtYWwgMS1SVFQgaGFuZHNoYWtlcyBvbiBldmVyeSBjb25uZWN0aW9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSAxLVJUVCBo YXNoc2hha2Ugb24gaW5pdGlhbCBjb25uZWN0aW9uLCBhbmQgMS1SVFQgUFNLIHJlc3VtZXMgdGhl cmVhZnRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MykgMS1SVFQgaGFuZHNoYWtlIG9uIGluaXRpYWwgY29ubmVjdGlvbiwgYW5kIDAtUlRUIFBT SyByZXN1bWVzIHRoZXJlYWZ0ZXIsIHdoZXJlIHRoZSBzZXJ2ZXIgcHJvdmlkZXMgcHJvdGVjdGlv biBhZ2FpbnN0IHJlcGxheSwgc3VjaCBhcyBlbXVsYXRpbmcgYSBzZXNzaW9uIGNhY2hlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSAxLVJUVCBo YW5kc2hha2Ugb24gaW5pdGlhbCBjb25uZWN0aW9uLCBhbmQgMC1SVFQgUFNLIHJlc3VtZXMgdy8g c3RhdGVsZXNzIHNlcnZlcnMgdGhhdCBhbGxvdyAwLVJUVCBhcHBsaWNhdGlvbiByZXF1ZXN0IHJl cGxheTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Nb2RlIDEgaXMgZWFzeS4mbmJzcDsgVGhlIGN1cnJlbnQgVEIgc3BlYyBhcHBsaWVzIGRpcmVj dGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Nb2RlIDIgaXMgc2ltaWxhciB0byBUTFMgMS4yIHJlc3VtZSwgd2hlcmUgd2Ugc2lnbiBvbiBl dmVyeSByZXN1bWUuJm5ic3A7IEkgdGhpbmsgd2Ugc2hvdWxkIGRvIHRoZSBUQiBzaWduYXR1cmUg b24gZXZlcnkgcmVzdW1lLCBqdXN0IGxpa2UgVExTIDEuMi4mbmJzcDsgSG93ZXZlciwgd2UgbWF5 IGdldCBzb21lIHB1c2gtYmFjayBiZWNhdXNlIHRoZSBvbmx5IHBvaW50IG9mIDEtUlRUIFBTSyBy ZXN1bWUgaW4gbW9zdCBjYXNlcw0KIHdpbGwgYmUgdG8gYXZvaWQgZXh0cmEgcHVibGljIGtleSBv cGVyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Nb2RlIDMgaXMgYWxtb3N0IGlkZW50aWNhbCBpbiBzZWN1cml0eSB0byBtb2RlIDIu Jm5ic3A7IEkgdGhpbmsgd2Ugc2hvdWxkIGFsc28gZG8gdGhlIFRCIHNpZ25hdHVyZSBpbiB0aGlz IG1vZGUuJm5ic3A7IEJ5IHNpZ25pbmcgdGhlIGNsaWVudCBoYW5kc2hha2UgaGFzaCwgd2UgZW5z dXJlIHRoYXQgdGhlIFRCIHNpZ25hdHVyZSBpcyB1bmlxdWUsIGFuZCB3YXMgbWFkZSBzaW5jZSB0 aGUgUk1TIHdhcyBkZXJpdmVkLiZuYnNwOyBJZiB0aGUNCiBUQiBwcml2YXRlIGtleSBpcyBzZWN1 cmVkIGluIHNvbWUgaGFyZHdhcmUgdGhpbmd5LCB0aGVuIHJlc3VtcHRpb24gd2lsbCBub3QgYmUg cG9zc2libGUgd2l0aG91dCBhY2Nlc3MgdG8gdGhlIHRoaW5neS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9kZSA0IGlzIHdoZXJlIHRoZSBz ZXJ2ZXIgYWxyZWFkeSByaXNrcyByZXBsYXkgYXR0YWNrcyBhbmQgbG9zZXMgc29tZSBmb3J3YXJk IHNlY3JlY3kgaW4gb3JkZXIgdG8gaW1wcm92ZSBzY2FsYWJpbGl0eSBieSBydW5uaW5nIHRoZSBz ZXJ2ZXJzIGluIGEgc3RhdGVsZXNzIG1vZGUuJm5ic3A7IFRoZSBSTVMgd2lsbCBiZSBlbmNvZGVk IGluIHRoZSB0aWNrZXQsIGFuZCB0aGUgc2FtZSB0aWNrZXQgY2FuIGJlIHVzZWQgZm9yDQogUFNL IDAtUlRUIHJlc3VtZSBtYW55IHRpbWVzLiZuYnNwOyBJbiB0aGlzIG1vZGUsIHRoZXJlIGlzIGxp dHRsZSBhZGRpdGlvbmFsIHNlY3VyaXR5IHRvIGJlIGhhZCBieSBzaWduaW5nIHRoZSBjbGllbnQg aGFuZHNoYWtlIGhhc2gsIHNpbmNlIHRoZSBzZXJ2ZXIgY2Fubm90IGJlIHN1cmUgdGhhdCB0aGUg c2lnbmF0dXJlIGlzIHVuaXF1ZSwgYW5kIHRoZSBwcm9vZiBvZiBwb3NzZXNzaW9uIGZhaWxzLCBv cGVuaW5nIHVwIGFsbCBraW5kcyBvZiBuZXcgYXR0YWNrcy4mbmJzcDsNCiBDdXJyZW50bHksIFRM UyAxLjMgZG9lcyBub3QgYWxsb3cgdGhlIGNsaWVudCB0byBrbm93IHdoZXRoZXIgdGhlIHNlcnZl ciBoYXMgcmVwbGF5IHByb3RlY3Rpb24gb3Igbm90LCBzbyB0aGUgc2FmZSB0aGluZyB3b3VsZCBw cm9iYWJseSBiZSB0byBhbHdheXMgZG8gdGhlIFRCIHNpZ25hdHVyZSwgZXZlbiB0aG91Z2ggdGhl IGFkZGl0aW9uYWwgbGF0ZW5jeSBvdmVyaGVhZCBkb2VzIG5vdCBzZWVtIGp1c3RpZmllZCBieSB0 aGUgYWRkaXRpb25hbCBzZWN1cml0eQ0KIGJlbmVmaXQgd2hlbiBkb2luZyBzdGF0ZWxlc3MgUFNL IDAtUlRUIHJlc3VtcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL2PR03MB2104C25C29F41785D7256F08C900BL2PR03MB210namprd_-- From nobody Tue Apr 12 17:28:06 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 43B4812D97F for ; Tue, 12 Apr 2016 17:28:05 -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 lwu9Fh46ld1T for ; Tue, 12 Apr 2016 17:28:03 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 027E612D913 for ; Tue, 12 Apr 2016 17:28:00 -0700 (PDT) Received: (qmail 3966 invoked by uid 0); 13 Apr 2016 00:27:55 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 13 Apr 2016 00:27:55 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id hcTr1s00T2UhLwi01cTuvZ; Tue, 12 Apr 2016 18:27:55 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm 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=VkcqTkgGjVYA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=rBg2x4foAAAA:8 a=jJ06AE73ryYXzuhAFyYA:9 a=FO28XBb1E5DyPRpY:21 a=tYzAYD0N4aHa5Acg:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=uVDK2p7RdF65P4EgXEfofy8DdZP0+GPXok4Q0qOGo5g=; b=RXr+qmhB/0x5A4uf0yZMltrGza jcjISl/3Tl1yiOKqUSD3lEePB6kRiE+mzr7z7gz/vRBtak9M0NWyppM8jlU/Xhn/j6QjDIOp1p/Sn YzUi/5uNu7aHQ0xIufb8MkVFF; Received: from [70.213.11.12] (port=2627 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 1aq8et-0003ws-AL for unbearable@ietf.org; Tue, 12 Apr 2016 18:27:51 -0600 To: IETF Tokbind WG From: =JeffH Message-ID: <570D927A.8090508@KingsMountain.com> Date: Tue, 12 Apr 2016 17:27:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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.11.12 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] IETF-95 tokbind session 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: Wed, 13 Apr 2016 00:28:05 -0000 The chairs posted my hot-off-the-press raw notes as IETF-95 tokbind session minutes.. https://www.ietf.org/proceedings/95/minutes/minutes-95-tokbind ..which I perused and fixed-up some today, and include below. If the 'offical' minutes can be updated with the below it'd be nice :) thx, HTH, =JeffH ------------------------------------------- tokbind IETF-95 Buenos Aires 4-Apr-2016 ------------------------------------------- Leif Johansson & John Bradley presiding https://www.ietf.org/proceedings/95/slides/slides-95-tokbind-0.pdf AndreiP(ap) presenting: -tokbind-protocol (TBPROTO) & -tokbind-negotiation (TBNEGO) see slides: https://www.ietf.org/proceedings/95/slides/slides-95-tokbind-1.pdf -protocol-05 pub'd this morn say explicitly in draft - if receive tbmsg and it contains tb type don't undstand, just skip it also punt referred tbtype to -https spec -- [ note: we have subsequently decided to not do this due to anticipated OAuthTB use of _referred TBtype ] brianC (bc): have cognitive issue with TBID being actually a just a public key -- perhaps explain this better leif(LJ): what need to do to make it done? move referred to -https skip unknown tbid types in tbmsg johnb(jb): is there something else other than a public key that could be a tbid? AP: nope LJ: do one more rev and goto wglc? Tony Nadalin(TN): is fine w/wglc now w/ -05 bc: suggests the drafts goto wglc all together bc: there's language brwn the drafts that refer to the same things but using inconsistent terms -- would be good to clean that all up... vinod(va) proxying Dirk, presenting: -tokbind-https aka HTTPSTB https://www.ietf.org/proceedings/95/slides/slides-95-tokbind-2.pdf leif-- what about the federation questions from the list JeffH(jh): bc: what we ahve is generally sufficient to accomd most use cases, tho there is idp-initiated flow which this may be an issue ap: notes that msft has made idp-initiated work via the 'msft token broker' -- ie is a custom solution jh: might want to add that to the spec in some impl guidance... ap: don't want to write up scott cantor(sc): custom is worthless in a world where the browser has to participate, we need standard behavior john bradley(jb): its best to keep simple enuff to cover 80..90% cases Scott Cantor(sc): but IdP initiated is really common, so that should be highlighted in the draft tn: don't want to spec just rp-initiated flow and say that is what you need to do... jh: wrt tony's comment that's not what we are saying, this rp-init is just an example and it may or may not work for you, tn: agree w/JH lucyl(LL): JH: now pop stack back to scott's more recent comment.. sc: I am still thinking about the actual risks of one server asking the client to reveal a different server's binding, but I wondered about the idea of whitelisting hosts (the IdPs) so the client has reason to believe it should reveal bindings to it vinod(va): RP whitelists itself to the IDP via the header... is current mech sufficient? bc: yes sufficient, whitelist may be too complex... sc: yeah, I see that; I think if we agree to ignore IdP initiated for the browser case, we can live without it lj: do you think we can get this done by Berlin? jb: specs are clear about how things are used in browser, but if have native apps, do we need to explain more clearly how the priv keys are sandboxed? i.e., more than one app might be able to use a given RP-mapped priv key? ap: this is platform specific... we could add a vague general stmt to spec, am not opposed to it.. jb: who has access to the priv key is platform-dep, pls look at platf doctn for details... ap: will add to sec cons bc: what about limits to # keys gen'd on hdwr device? overall ans: we could handwave about that but is platform specific.... bc: is tb estab'd on initial connection? ap: client generates tbid on every tls connection bc: what does that mean? trying to understand particularly with referred tbid -- if user has existing https w/idp w/tbid, it will have provided tbid -- how will redirect to idp work and will client need to regenerate tbid? ap: vinod: bc: thinks it might be more clear to http/app layer if the provided and referred were conveyed in sep headers rather than in the same header-cum-tbmsg bc: on init redir the server would get both of them (hdrs), then on subseq interactions it would get just one header, would be easier to parse out at this layer ie have diff header name for referred -- easier to parse at http/app layer...would make spec more comprehendable and easier to impl ap: we can think about this....in either case the server app needs to pass the tb heaader to some tb impl and get answer from it, so wether i pass one blob or two blobs, seems equivalent.... jb: are there libs, example code folks can look at? ap: do have a tb api in windows that is sort of documented -- will send link to list va: goog working on server side example code sc: is the expectation that TLS impls actually provide the EKM material to applications to verify these token bindings? That seems like a gap if they don't. Initially I had thought all that work was meant to be inside the TLS layer, sounds like the raw material needs to be bubbled out. ap: yes, need EKM exporter in tls api, this can be impl'd in some sort of middleware, but yes the tls stack needs to supply this -- in our impl, have a sep tb lib, pass it tls session handle and it does the work williamd: having disc of applying TB to OAuth, OIDF has released this lib called "appauth" and also the "cronut" libs for native apps -- having discussions this week about this bc: still quite don't understand how this works....if there's been any prog wrt support for referred to be on 30x redirects ... it is not uncommon that RP redirs to IDP via POST .... spec doesn't accomodate this presently ap: can mention this limitation more clearly in the spec... jh: this applies to SAML form-post binding bc: many such other bindings... jh: so perhaps need to think about different signaling, pesent signal is for one thing: just redir -- does every binding need diff signal? bc: see discussion in the issue (not on list (sigh)) perhaps fetch() needs to be updated to more handle these various approaches jb: had a form-post in earlier drafts, yes? sc: I'd be somewhat shocked if Java did, but I've been surprised before, I feel his pain sc: I certainly noted the limitation, this is clearly leading to us killing off these other scenarios, not "supporting them later", just my opinion sc: (unless there is active work going on, sounds like there is?) it's not about language, if you ship browsers that don't support POST, I'm not going to tell people to keep deploying POST, I'm going to kill it -- I was responding to the speaker, not you John va: want to support this stuff, is this the corect forum, or do we need to do this in fetch() ? this works with GET yes? jb: its only if you're doing a POST authn req we need more support... sc: yes, just speaking about POST-conveyed authn requests, and much like the IdP-initiated case, it's a strong pressure on those deployment models, not saying it's good/bad, just highlighting that it will be an outcome bc: maybe will intro of TB make it easier to do certain models and others can be superseded... jb: so supporting other patterns can perhaps be addressed on longer timescale in additional drafts cuz might need help from fetch() ap: bc: ok, so feel even more that having two distinct headers will be much easier for the http/app layer to process, seems more natural, exp if move the notion of referred into the -https spec --- conveying what's going on will be much easier to understand, eg for folks like myself.... va: initial design allows for even more tbtypes did't want to alloc one header per tb type.....but you're making a good case for doing this.... sc: Q: If the token binding message is application layer, then how do you envision the message being validated in conjunction with the negotiated token binding type worked out in the TLS handshake? That seems a bit awkward. ap: impld in asp.net, which gens tokens, creates tbmsg, etc. shields app layer dvlp from it sc: it's how this would work with generic libs like OpenSSL that I'm thinking of jb: expanding on directino of Scott's q -- i can see how msft has impl'd it, but some folks use IIS, is it impl'd in IIS and how's it exposed to .net apps who want to use TBID in cookies? ap: server-side apps use asp.net to do all this jb: is tb exposed such that one can do their own thing? ap: have lib that helps you parse this stuff and verify sigs, you can use lib directly jb: pls send ptrs to the list... sc: believe it or not, though, people ask some of us to supply our own SAML implementations on IIS lucy(ll): asking why having the mult tbids in one msg.... ap: easier to pass to api to deal with it.... lucy: you're getting feedback here that at app layer it might not be "more conveninent" and you should listen to that jb: ll: if you're going with why you're obscuring (ie packaging) things together for folks at app layer va/ap: we can either change the https spec to break things apart or explain why it is packaged together karl rose: what about authn creds, have one per server for priv reasons, but there are use cases where mult entities actually are same entity.... jb: was put in such that we're tryiing to prevent correlation by design; because the keys are pair-wise we're doing audience restriction effectively; va: there are two classes of UAs, browsers and others, because the browser is connecting to "other servers" as matter of course, need this, but in a purpose app UA can relax this requirement... kr: jb: having this restriction is preventing a sec vuln you may have glossed over in your app -- in oauth lib thinks we leaning towards diff keys for diff providers cuz there are priv benefits kr: analogy: in SSH, have priv key per machine, but client can use same key for diff servers kr/jb end tokbind --- From nobody Wed Apr 13 00:09: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 F3B9412D63A for ; Wed, 13 Apr 2016 00:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 kLWpOx3ICzHS for ; Wed, 13 Apr 2016 00:09:24 -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 E981C12D58A for ; Wed, 13 Apr 2016 00:09:23 -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 u3D79LiY026401 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 13 Apr 2016 09:09:21 +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 u3D79ItD024183 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Apr 2016 09:09:20 +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=1460531360; bh=xowlqJMUt4uDFf3x0e9T3QoGdjkXo4T/aTwoy8hJkQQ=; h=Subject:To:References:From:Date:In-Reply-To; b=o0bwOd1a7PUombaGjXEhQEKbuHtioZ25cK+lI7wm8aG105en5kg1dA5kMHV7lknT8 cI7nNp+XfAVjFkoJppuOsiQTDePMked6kewha0nfLKm1aOpe9dnN18izDFtGK7xaqn WlN5sC/cQKeOM9fC8ZaJd5IghCJHVTT3Ykc61KC8= X-Footer: c3VuZXQuc2U= Received: from [194.47.44.200] ([194.47.44.200]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for unbearable@ietf.org; Wed, 13 Apr 2016 09:09:16 +0200 To: unbearable@ietf.org References: <570D927A.8090508@KingsMountain.com> From: Leif Johansson Message-ID: <570DF09B.8070908@sunet.se> Date: Wed, 13 Apr 2016 09:09:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570D927A.8090508@KingsMountain.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QFH9lmC - 297c910d1521 - 20160413 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] IETF-95 tokbind session 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: Wed, 13 Apr 2016 07:09:27 -0000 This is the first time anyone has offered to revise minutes :) New version has been posted, thx =JeffH! From nobody Fri Apr 22 14:46: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 C40B512E5D7 for ; Fri, 22 Apr 2016 14:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, 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] 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 NHugYQF0OL8G for ; Fri, 22 Apr 2016 14:46:51 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2D412E5CE for ; Fri, 22 Apr 2016 14:46:51 -0700 (PDT) Date: Fri, 22 Apr 2016 14:46:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1461361607; bh=MYMHp0Ce53CUkefz7AOfX5PAd0nHuNHUwhpZOYybmX4=; h=From:To:Subject:From; b=PpTmTXs6xNlzArdkTGRB1uqeQgkQ7aKgL0Sfak5fo+4KIqLj6S0zJTQyCNibKyFWV mZrkz0Raw3vI0bUzWNnFe22guaXZ1gKJFqm17iqw/le5JlCuEtQy5xC3eXfYFamck9 tmHGmjNJZYqy4Kt/gtoapPpSS3Grpgfxd45/Flao= From: GitHub To: unbearable-ML Message-ID: <571a9bc72a062_3cc23fb02ed9529c4129e@github-highworker1-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_571a9bc729294_3cc23fb02ed9529c4113c"; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Auto-Response-Suppress: All Archived-At: Subject: [Unbearable] [GitHub] Please verify your email address. 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 Apr 2016 21:46:52 -0000 ----==_mimepart_571a9bc729294_3cc23fb02ed9529c4113c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi @unbearable-ML! Help us secure your GitHub account by verifying your email address (unbea= rable@ietf.org). This lets you access all of GitHub's features. Click the link below to verify your email address: https://github.com/users/unbearable-ML/emails/21641100/confirm_verificati= on/e0d9f2d01d6b0579e4632d030655a4fcd9e8a384 You=E2=80=99re receiving this email because you recently created a new Gi= tHub account or added a new email address. If this wasn=E2=80=99t you, pl= ease ignore this email. --- Sent with <3 by GitHub. GitHub, Inc. 88 Colin P Kelly Jr Street San Francisco, CA 94107 ----==_mimepart_571a9bc729294_3cc23fb02ed9529c4113c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit [GitHub] Please verify your email address.
----==_mimepart_571a9bc729294_3cc23fb02ed9529c4113c-- From nobody Fri Apr 22 15:23:11 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 5C3BD12E9A1 for ; Fri, 22 Apr 2016 15:23:09 -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 80ykXJCg8fhB for ; Fri, 22 Apr 2016 15:23:08 -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 357D712E99B for ; Fri, 22 Apr 2016 15:23:08 -0700 (PDT) Received: (qmail 13012 invoked by uid 0); 22 Apr 2016 22:23:03 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 22 Apr 2016 22:23:03 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id laNz1s0022UhLwi01aP22M; Fri, 22 Apr 2016 16:23:03 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm 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=NEAV23lmAAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=UFWr1SZZQlcA:10 a=kziv93cY1bsA:10 a=SSmOFEACAAAA:8 a=48vgC7mUAAAA:8 a=nBRpE_y7jnm_HWc1TpkA:9 a=zpRwQrBeAd2pVGPK:21 a=Wu1LzitaNytcLlzh:21 a=QEXdDO2ut3YA:10 a=rPvhlfwCp4UA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Cc:Subject:From; bh=5Oapo8D2mv1hv1CeEvW2p0u0h4yI9umOqvn8bSypx5k=; b=1HHdJjyDddq02IDQ5Yk7cVbsNW J5zkzFlO5lN4Jw+NM2zFaon8retSxFcArc83t0OzFIznaw0EXWPBEBlWvOZKREKCd9Uo55uHgLB6E WmROnrOuMEEIvroZgLBLjQ26F; Received: from [70.213.9.16] (port=5702 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 1atjTW-0007dB-Sv; Fri, 22 Apr 2016 16:22:59 -0600 From: =JeffH To: Leif Johansson , John Bradley Message-ID: <571AA437.5020503@KingsMountain.com> Date: Fri, 22 Apr 2016 15:22:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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.9.16 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG Subject: [Unbearable] administrivia: wrt github.com use 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 Apr 2016 22:23:09 -0000 given that the tokbind spec editors chose to ensconce the editors' drafts for the WG in the https://github.com/TokenBinding/Internet-Drafts repo, it would probably be better overall to figure out how to more closely integrate that's repo's use into the traditional IETF WG framework. i.e., rather than having to remember to discuss issues on the mailing list, we can apply the Note Well to the repo and pipe issues and comments to the mailing list. I note that the W3C has largely figured this out, and can pipe github.com issues, pull requests, comments thereof, etc to WG mailing list(s) -- e.g., see.. Using GitHub for W3C specifications https://www.w3.org/2015/Talks/1217-github-w3c/ Re: [Ietf-and-github] Legal notices (was: Re: A possible way of keeping WG informed of github tracked issues? http://www.ietf.org/mail-archive/web/ietf-and-github/current/msg00022.html ..plus, Martin Thomson has put together a nice set of templates for setting up a github.com repo for IETF WG use (some-assembly-required).. https://github.com/martinthomson/i-d-template Given that we're using the TokenBinding/Internet-Drafts repo's issues list and pull request functionality, perhaps we should at least use i-d-template (above) to generate an appropriate CONTRIBUTING.md and add that to the repo. It would be nice if someone (the ietf tools team?) would setup and run https://github.com/dontcallmedom/github-notify-ml for the IETF, but in lieu of that I'm trying an experiment by creating a github user "unbearable-ML" who's email address is this DL and having that user "watch" our repo... if it doesn't work for whatever reason it can be discontinued.. hth, =JeffH From nobody Fri Apr 22 16:10: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 B7C0012E4F8 for ; Fri, 22 Apr 2016 16:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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=-0.996, 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 JlPNeLJke2kI for ; Fri, 22 Apr 2016 16:10:38 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 178A512E4D8 for ; Fri, 22 Apr 2016 16:10:38 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id t129so155163588vkg.2 for ; Fri, 22 Apr 2016 16:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=VVDS6mmW0Kr0q/F/ijQHYIJbfIwOUT0+HWZs4RZdd+c=; b=W6V13TBRSFFyJgoBRuBDaJJd8HZg2nsMkMbtCiGx94sJe8ReHxDDjfKUD6KqBY9QFP PMexNyNbFeuL9x5fn6D7Cg29IStqNrS2WkOiPcpGKW9lOak3pZAnHQ1b8mAMUxK2bofy XvwjiQJ6lXsE2SgmPAEXZT8E/E43wVo/TsyHnsCc0FRquA4KQkVVmur5NNMAN5zbVMij 4jrw2TrdLExTILg/g4TeCfhDi+1Kk1nImigNrjY1yZgpSWMdWVSpoRnrfJA8hncJB/Gx HvF6z+R1A3lHP7EPEA5roIE93r/eCzBiesPUXx4Mi4JSQt4YECxUOBKe5of1QiAWBWXx EbOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=VVDS6mmW0Kr0q/F/ijQHYIJbfIwOUT0+HWZs4RZdd+c=; b=YLTKoMxOqKje9NjqtEYPGEBOjkSwVfwV6ubh2EBczWRK2GjdI44pAeOrLJ0zfE9QsY yGuSxyAzuziWRnVctQJbXLkEr1lUqT37hjVrTujJJNYY82ITloMMhlD4U4LkYH/N/tha a3ovRiSgUkU54v9ivtBUPAxaO9Z8b1KIAVHozGKaumTiqwtma3/FIYh1/WFpMZtrjTXy Bzx2OhYmfzjfDxoxKAtWYiuN/M2VpNuJVifL7Bmrki8pwnajbq0yD0EI5zDDPReR5lC9 9RfoB6+ZuvhDwjUKgthNHJo9OUCm5m2V4q71rtomYbfb5FZjYIB4cg+N3Mwh1lME8MOa G7fw== X-Gm-Message-State: AOPr4FUGvfyvBEb9GIH8uu77Ru15TdAoUBItvvZ/k1CLL84vPRfZtJXsxH/oHHnHRezrdMWJAqhXf4SL06n4xRG3 MIME-Version: 1.0 X-Received: by 10.31.180.213 with SMTP id d204mr11280257vkf.80.1461366636939; Fri, 22 Apr 2016 16:10:36 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Fri, 22 Apr 2016 16:10:36 -0700 (PDT) Date: Fri, 22 Apr 2016 16:10:36 -0700 Message-ID: From: Bill Cox To: Tokbind WG Content-Type: multipart/alternative; boundary=001a1144030e48636205311aef50 Archived-At: Subject: [Unbearable] TLS 1.3 0-RTT client authentication status 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 Apr 2016 23:10:40 -0000 --001a1144030e48636205311aef50 Content-Type: text/plain; charset=UTF-8 I do not think token binding or client certificates are a good idea over 0-RTT without replay protection. The additional security of token binding over these channels seems low compared to the security loss due to allowing attackers to use token-bound auth tokens over 0-RTT channels without replay protection. The difference for servers is whether to store session state in the session cache or ticket. The session state has to be remembered regardless. I prefer server-side session caching for improved PFS and replay protection, and it allows us to offer 0-RTT security fairly similar to TLS 1.2 resumption. However, that's just me. A lot of folks are sold on the benefits of stateless servers. Assuming this group winds up agreeing not to send bound tokens over 0-RTT connections without replay protection, then TLS 1.3 servers should behave in one of four ways when TB is offered by the client: 1) Servers without replay protection refuse to negotiate TB, but allow 0-RTT 2) Servers without replay protection disable 0-RTT, and negotiate TB 3) Servers with replay protection negotiate TB and disable 0-RTT 4) Servers with replay protection negotiate TB and allow 0-RTT Unfortunately, the simplest solutions to manage at scale are 1) and 2), since server-side caching is a bit painful. The choice between 3) and 4) depends on how much the server trusts the client to protect TLS secrets between connections (the Resumption Master Secret in particular). Clients that manage the RMS in a trusted execution mode, as well as the token binding private key, would be clients I would allow to connect in mode 4, assuming my server has replay protection. Mode 2) is particularly problematic for token binding. It is a simple and secure solution for servers, but they punish clients that advertise TB support by slowing down connections. Bill --001a1144030e48636205311aef50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not think token binding or client certificates are a = good idea over 0-RTT without replay protection.=C2=A0 The additional securi= ty of token binding over these channels seems low compared to the security = loss due to allowing attackers to use token-bound auth tokens over 0-RTT ch= annels without replay protection.

The difference fo= r servers is whether to store session state in the session cache or ticket.= =C2=A0 The session state has to be remembered regardless.=C2=A0 I prefer se= rver-side session caching for improved PFS and replay protection, and it al= lows us to offer 0-RTT security fairly similar to TLS 1.2 resumption.=C2=A0= However, that's just me.=C2=A0 A lot of folks are sold on the benefits= of stateless servers.

Assuming this group winds u= p agreeing not to send bound tokens over 0-RTT connections without replay p= rotection, then TLS 1.3 servers should behave in one of four ways when TB i= s offered by the client:

1) Servers without replay= protection refuse to negotiate TB, but allow 0-RTT
2) Server= s without replay protection disable 0-RTT, and negotiate TB
3) Se= rvers with replay protection negotiate TB and disable 0-RTT
4) Se= rvers with replay protection negotiate TB and allow 0-RTT

Unfortunately, the simplest solutions to manage at scale are 1) and= 2), since server-side caching is a bit painful.=C2=A0 The choice between 3= ) and 4) depends on how much the server trusts the client to protect TLS se= crets between connections (the Resumption Master Secret in particular).=C2= =A0 Clients that manage the RMS in a trusted execution mode, as well as the= token binding private key, would be clients I would allow to connect in mo= de 4, assuming my server has replay protection.

Mo= de 2) is particularly problematic for token binding.=C2=A0 It is a simple a= nd secure solution for servers, but they punish clients that advertise TB s= upport by slowing down connections.

Bill
--001a1144030e48636205311aef50-- From nobody Wed Apr 27 16:45:59 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 D281812B060 for ; Wed, 27 Apr 2016 16:45:57 -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 KFfC5OnmM747 for ; Wed, 27 Apr 2016 16:45:56 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 3D9B012B029 for ; Wed, 27 Apr 2016 16:45:56 -0700 (PDT) Received: (qmail 29258 invoked by uid 0); 27 Apr 2016 23:45:53 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 27 Apr 2016 23:45:53 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id nblm1s0092UhLwi01blphh; Wed, 27 Apr 2016 17:45:51 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 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=Dqrycd8-ltMA:10 a=kziv93cY1bsA:10 a=NEAV23lmAAAA:8 a=jDv_7UO6jpSqZDMr1GUA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=TP77ZqC8uJRZ22bY546uATARY8A9KgpXJKT/2e73dwE=; b=QIEc4jy+ZeIvDmmV2QanRrO0fS b+dMPM9/xfCuTnYEj8eMOjB24yrMCARELB0YbPtJlxEB3L8M1i44SKsrYbIClTad+q7nSu8nqirUc ZvpNRt7YlQXV5lF9iud68l8mK; Received: from [70.213.1.239] (port=9821 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 1avZ9Q-0001ov-3h for unbearable@ietf.org; Wed, 27 Apr 2016 17:45:48 -0600 From: =JeffH To: IETF Tokbind WG Message-ID: <57214F22.5070209@KingsMountain.com> Date: Wed, 27 Apr 2016 16:45:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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.1.239 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] Re-opened "added explicit referred TB processing" PR#16 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 Apr 2016 23:45:58 -0000 https://github.com/TokenBinding/Internet-Drafts/pull/16 re-opening, see issue #21 -- have added commits to update these proposed changes. TBPROTO: Add more info about the intended use of Referred bindings #21 https://github.com/TokenBinding/Internet-Drafts/issues/21 per various discussions with OAuth folk at IETF-95, it appears there will be a forthcoming OAuth Internet-Draft making use of Token Binding Protocol and referred_token_binding TBtype ("referred bindings"). Thus, we will retain referred_token_binding TBtype in TBPROTO (-tokbind-protocol) and update the relevant spec prose to hopefully make its semantics and use more clear. NOTE: The present proposed content of PR#16 does not quite fully accomplish the separation of processing rules from the TBMsg syntax exposition, nor clarify the semantics of referred bindings, to the extent that I/we intend to -- tho, if this overall direction seems ok, the necessary further editing can be done either before or after merge of this PR. Please review PR#16 thx, HTH, =JeffH