[Unbearable] TBPROTO: TTRP accordance language (was: on not listing 'Sec-Token-Binding' in the Connection header field?
=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 16 February 2017 00:35 UTC
Return-Path: <Jeff.Hodges@kingsmountain.com>
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 285DE129863 for <unbearable@ietfa.amsl.com>; Wed, 15 Feb 2017 16:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level:
X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwZ69wr7t5MH for <unbearable@ietfa.amsl.com>; Wed, 15 Feb 2017 16:35:25 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 9807712953F for <unbearable@ietf.org>; Wed, 15 Feb 2017 16:35:25 -0800 (PST)
Received: (qmail 22114 invoked by uid 0); 16 Feb 2017 00:35:20 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 16 Feb 2017 00:35:20 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id lCbG1u0142UhLwi01CbKNt; Wed, 15 Feb 2017 17:35:20 -0700
X-Authority-Analysis: v=2.1 cv=Pets2ERd 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=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=OhYhTfOFuhghmRSOqKoA:9 a=QEXdDO2ut3YA:10 a=b1CPlgppWbsA:10 a=lRJ6R7Cb8V8A:10 a=w1C3t2QeGrPiZgrLijVG:22
Received: from [173.224.162.69] (port=12917 helo=[10.225.80.64]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ceA2W-0006hk-RC for unbearable@ietf.org; Wed, 15 Feb 2017 17:35:16 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
To: IETF TokBind WG <unbearable@ietf.org>
Message-ID: <2395df08-a976-7022-822d-7d3356854e33@KingsMountain.com>
Date: Wed, 15 Feb 2017 16:35:15 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box514.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - KingsMountain.com
X-BWhitelist: no
X-Source-IP: 173.224.162.69
X-Exim-ID: 1ceA2W-0006hk-RC
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([10.225.80.64]) [173.224.162.69]:12917
X-Source-Auth: jeff.hodges+kingsmountain.com
X-Email-Count: 1
X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/M-V18gizDF4nyErm_sZAxadTPfA>
Subject: [Unbearable] TBPROTO: TTRP accordance language (was: on not listing 'Sec-Token-Binding' in the Connection header field?
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.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 00:35:27 -0000
As noted in.. on not listing 'Sec-Token-Binding' in the Connection header field? <https://www.ietf.org/mail-archive/web/unbearable/current/msg01192.html> ..it seems TBPROTO (aka -tokbind-protocol) does not allow an application-layer proxy/gateway (that terminates the client-side TLS connection) to simply pass a TBMSG on to the next hop because (a) present spec language in TBPROTO S 4.2 precludes processing TBMSG if TB was not negotiated on the connection [1], and (b) S 5 precludes honoring bound tokens rec'd on a connection where their embedded TBIDs do not match the TBID established for the connection they were received over [2]. Proposed language to rectify this is below at [1] and [2]. HTH, =JeffH [1] in "4.2 Server Processing Rules": https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-4.2 CURRENT: If the use of the Token Binding protocol was not negotiated, but the client sends the Token Binding message, the server MUST reject any contained bindings. PROPOSED: If the server receives a Token Binding message on a connection where the use of the Token Binding protocol was not negotiated, and the server has no additional information regarding the client's role, the server MUST reject any contained bindings. However, if the server is aware (e.g., via policy) that the client's is an application-layer proxy, and the server and client have negotiated a secure connection, the server MAY process the Token Binding message, provided it also has access to the EKM and key parameters necessary to verify the signature(s) contained in the Token Binding message. Conveyance of the latter information is beyond the scope of this specification but may be detailed in other specifications. If the server's role is that of an application-layer proxy, and the Token Binding protocol was negotiated with the client, then the server MAY forward the Token Binding Message to the next hop (e.g., if stipulated by policy). It MUST do so in a secure fashion, e.g., using a secure connection, or using message-level encryption. [2] in "5. Bound Security Token Creation and Validation": https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-5 CURRENT: Upon receipt of a security token, the server attempts to retrieve Token Binding ID information from the token and from the TLS connection with the client. Application-provided policy determines whether to honor non-bound (bearer) tokens. If the token is bound and a Token Binding has not been established for the client connection, the server MUST discard the token. If the Token Binding ID for the token does not match the Token Binding ID established for the client connection, the server MUST discard the token. PROPOSED: Upon receipt of a security token, the server attempts to retrieve Token Binding ID information from the token and from the TLS connection with the client. Application-provided policy determines whether to honor non-bound (bearer) tokens. If the token is bound and a Token Binding is established for the client connection, then if the Token Binding ID in the token does not match the Token Binding ID established for the client connection, the server MUST discard the token. If the server is acting as an application-layer proxy, it MAY forward the bound token to the next hop (e.g., if stipulated by policy). It MUST do so in a secure fashion, e.g., using a secure connection, or using message-level encryption. Otherwise, if the token is bound, a Token Binding is not established for the client connection, and the server is aware (e.g., via policy) that the client is an application-layer proxy, then the server MAY process the bound token, provided it also received a valid corresponding Token Binding message from the proxy (see <xref target="ServerProcRules"/>). If the Token Binding ID in the token does not match the Token Binding ID from the corresponding Token Binding message, the server MUST discard the token. end