[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