Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

[=JeffH <[e-mail]>]

Andrei wrote:
 > Amos had said:
 >> The Connection header is not particularly about proxies. It is
 >> simply about distinguishing hop-by-hop things from end-to-end so
 >> any naive/old HTTP recipient can keep the relevant data secure in a
 >>  fail-closed way.
 >
 > ...and TB can be handled hop-by-hop or passed on for subsequent
 > validation; both are valid use-cases.
 >
 > It would be a concern if the backend servers were to assume that any
 >  TB header (and the contained TB message) floating around is always
 > valid. Instead what the specs currently say is that if you receive a
 > TB message, you've got to validate it before accepting a bound
 > token. If validation fails, the bound token is rejected.
 >
 > It seems therefore that stripping TB headers does not "fail closed",
 >  but simply eliminates the possibility that the contained TB message
 > may get verified further down the line.

Actually, unless I'm mis-interpreting TBPROTO (aka -tokbind-protocol),
it presently 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].

Apropos to (a), we are presently thinking that HTTP/TLS Terminating
Reverse Proxies (TTRPs) likely will not negotiate TB on their
towards-origin-server connections (aka backend connections) [3], and so
if they simply forward along the Sec-Token-Binding (STB) header
containing the TBMSG, the receiver is (presently) obliged to reject any
"contained bindings".

In the (b) case, since TBPROTO aspires to be app protocol neutral, there
may be some app layer gateway that does want the gateway to negotiate TB
on the backend connections, and then the present spec language impedes
processing of tokens that have been gathered on prior hops. Plus in the
case where TB is not nego'd on the backend connection, the receiving
backend server is obliged to not honor the bound tokens because their
TBIDs do not match a null TBID of the non-TB'd connection they were
received over.

 > It is true that a proxy could forward Sec-Token-Binding's contents as
 > a custom header, possibly specified in another document. This is a
 > valid design; I'm just not convinced that this should be the only
 > possible design.

Also, if an STB header is forwarded along "automatically" (eg, because
it was not listed in the Connection header), it must be accompanied by 
the EKM et al necessary to validate it, so it seems a forwarding entity 
needs to be "TB-aware" to some degree in order to include said material 
(eg, via the proposed Token-Binding-Context (TBC) header [4]), and if it 
is so "aware", it ostensibly can then also forward along the STB 
regardless of whether the STB is listed in the received Connection 
header (due to the exception Amos cited earlier in RFC7230 S 6.1).

So unless I'm mistaken, we have identified some things we ought to alter 
in TBPROTO in order to facilitate TTRPs. HTTPSTB may also need some 
associated language. This seems to be regardless of what we say about 
STB being conveyed in the Connection header. See diagram at [5]. Other 
scenarios (and a legend etc) also diagrammed at..

http://kingsmountain.com/doc/draft-ietf-tokbind-figures-STB-TTRPs.txt

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


[2] in "5. Bound Security Token Creation and Validation":
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-5

CURRENT:
                                                 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.



[3] <https://www.ietf.org/mail-archive/web/unbearable/current/msg01191.html>

[4] https://tools.ietf.org/html/draft-campbell-tokbind-tls-term

[5] Scenario 3: TB-aware TTRP, TB-wielding origin server.
[[ISSUES]]

Note: this scenario generalizes to more than one TB-aware TTRP in the
path.


TB-wielding                 TB-aware                      TB-wielding
client                      TTRP                        Origin Server
[TB nego,                   [TB-nego,                      [!TB-nego,
  mints STB]                  !process STB,		  process STB
                              !process Toks]		   using TBC,
							process Toks]
GET / HTTP/1.1
Host:...
STB:AIkAAg...72REUA
{Connection:STB}
-------------------------------->
         [TB-nego]
                            [pass-thru STB due to
                             exception clause in
                             RFC7230 S 6.1 (or
			    automatically if no
                             Connection hdr), add TBC,
                             optionally use Connection
			    header.]

                            GET / HTTP/1.1
                            Host:...
                            STB:AIkAAg..72REUA
                            TBC:AQAClt..7fFs4i
                            {Connection:STB,TBC}
                            ---------------------------------->
                                       [!TB-nego]

                                                  WANT:     using TBC,
                                                      origin server is
                                                        able to verify
                                                      TBMSG in STB and
                                                           to bind sec
                                                        tokens to TBID
                                                      from client-TTRP
                                                           connection.
						
                                                 BUT:        No TB on
                                                     connection to OS.
                                                    Also, present spec
                                                 language in [3] S 4.2
                                                  precludes processing
                                                STB, and S 5 precludes
                                                 honoring bound tokens
                                              rec'd on this connection
                                                                   !!!
                                        THUS:
                                                       HTTP/1.1 200 OK
                                            Set-cookie:foo=31d4..aad42
                                                       [cookie !bound]
                                   <----------------------------------

                    HTTP/1.1 200 OK
        Set-cookie:foo=31d4..aad42
                    [cookie !bound]
    <------------------------------



###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###