Subject: [Unbearable] TBPROTO: TTRP accordance language (was: on not listing 'Sec-Token-Binding' in the Connection header field?

From: =JeffH <[email-masked]>
Date: Wed, 15 Feb 2017 16:35:15 -0800

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

---

From: Andrei Popov <[email-masked]>
Date: Thu, 16 Feb 2017 00:52:48 +0000

> ..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].

TBPROTO uses the term "server" to refer to the server-side end of the connection. Such "server" can be a datacenter with load balancers, TLS terminators, multiple back-end application servers, etc. The details of the possible topologies of the "servers" are out of scope for TBPROTO, and therefore TBPROTO does not disallow any forwarding of TB messages within the "server".

Tokbind-tls-term spec is probably a better place to discuss HTTP proxies and header forwarding.

Cheers,

Andrei