draft-ietf-tokbind-figures-STB-TTRPs.txt =JeffH Hodges 12-Feb-2017 CONTENTS: References LEGEND CHARACTERISTICS/ACTIONS SCENARIOS References: [1] https://tools.ietf.org/html/draft-ietf-tokbind-https [2] https://tools.ietf.org/html/draft-campbell-tokbind-tls-term [3] https://tools.ietf.org/html/draft-ietf-tokbind-protocol LEGEND: "!" == "no" or "not" - used to negate CHARACTERISTICS/ACTIONS "~" == "might", "may", depending on out-of-scope deployment attributes. used on CHARACTERISTICS/ACTIONS. "{...}" == optional HTTP header - scenario behaves as expected with or without it OS == Origin Server proxy == "forward" proxy STB == Sec-Token-Binding header field [1] TBC == Token-Binding-Context header field [2] TBID == Token Binding ID [1] TBMSG == Token Binding Message [1] TTRP == TLS Terminating Reverse Proxy, aka "gateway" per RFC7230 S 2.3 [2] towards-OS == towards Origin Server (explanation for this term down at end if anyone is curious). CHARACTERISTICS/ACTIONS: TB-aware: A TTRP implemented with knowledge of [1] though it does not validate received STBs (as compared to TB-wielding), and does not negotiate TB on towards-OS connections. Implements [2] and issues TBC on towards-OS connections. Also, forwards STBs received from clients on towards-OS connection regardless of whether client's request listed STB in Connection header field (due to exception clause in RFC7230 S 6.1), process STB: received STB headers are validated, and HTTP responses may include sec tokens bound to the TLS connection with the requester/client process Toks: processes received security tokens, and if they are bound, follows rules in TBPROTO [3] TB-nego: TB negotiation in TLS establishment. In case of entities other than clients, it means TB is nego'd (or not) with client-side entity. TB-wielding: client implementing [1], or Origin Server implementing [1] and [2], or TTRP implementing [1] for client-side connections. Implies client minting STB, and TTRP processing STB as well as possibly binding tokens, and verifying presented tokens (or may have some out-of-scope arrangement with other entities (including the OS) to handle such duties). Compare to TB-aware. NOTE: impl'g [1] implies impl'g TBPROTO [3] & TBNEGO. TB-wieldingDS: TB-wielding proxy that also negotiates [1] on towards-OS connections as well as impl'g [2]. NOTE: we do not believe this is a use case to anticipate/support given our understanding of prevalent reverse proxy and TTRP deployment practices. ------------> HTTPS connection on which TB was negotiated during [TB-nego] TLS establishment. ------------> HTTPS connection on which TB was not negotiated. [!TB-nego] SCENARIOS: Note: in all scenarios, the client is TB-wielding. Note: only TTRPs are considered herein at this time, no forward proxy scenarios ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### Scenario 1: TB-wielding Client w/ STB (optionally) in Connection header, no proxy or TTRP, TB-wielding origin server [[EXPECTED BEHAVIOR]] TB-wielding TB-wielding client Origin Server other server(s)? [TB nego, [TB-nego, mints STB] process STB] GET / HTTP/1.1 Host:... STB:AIkAAg...72REUA {Connection:STB} --------------------------------> [TB-nego] [verifies sig(s) in TBMSG in STB, processes HTTP request, mints sec tokens containing TBID] [[ any requests to other HTTPS servers instigated by this request should not inadvertently leak client's TBIDs. Listing STB in Connection header may help here. GET / HTTP/1.1 Host:... ----------------------------------> HTTP/1.1 200 OK <---------------------------------- ]] HTTP/1.1 200 OK Set-cookie:foo=31d4..aad42 [cookie contains TBID] <------------------------------ [Sec tokens returned to client are bound to TBID.] ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### Scenario 2: TB-wielding TTRP, !TB-wielding origin server [[EXPECTED BEHAVIOR]] Note: this works as expected whether STB is in Connection header or not, given the assumption that a TB-wielding TTRP (as opposed to a TB-aware TTRP) will "consume" the STB, and not generate a TBC header. TB-wielding TB-wielding client TTRP Origin Server [TB nego, [TB-nego, [!TB-nego] mints STB] ~process STB ~process Toks] GET / HTTP/1.1 Host:... STB:AIkAAg...72REUA {Connection:STB} --------------------------------> [TB-nego] [verifies sig(s) in TBMSG in STB, prunes out STB, either per Conn hdr, or per !TB-nego w/Origin Server] GET / HTTP/1.1 Host:... ----------------------------------> [!TB-nego] [processes HTTP request] HTTP/1.1 200 OK {Set-cookie: .... } <---------------------------------- HTTP/1.1 200 OK Set-cookie:foo=31d4..aad42 [cookie contains TBID] <------------------------------ [Sec tokens returned to client contain TBID, this may have involved proprietary proccessing between TTRP and origin server(2), or other entities, or the proxy may have done all the TB processing and sec tokan minting & binding] ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### 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] <------------------------------ ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### Scenario 4: !TB-aware TTRP, TB-wielding (or not) origin server [[EXPECTED BEHAVIOR]] TB-wielding !TB-aware ~TB-wielding client TTRP Origin Server [!TB nego [!TB-nego] [no STB rec'd] !mint STB] GET / HTTP/1.1 Host:... --------------------------------> [!TB-nego] GET / HTTP/1.1 Host:... ----------------------------------> [!TB-nego] No TB-nego, so no STB, no bound tokens, as expected. HTTP/1.1 200 OK Set-cookie:foo=31d4..aad42 [cookie !bound] <---------------------------------- HTTP/1.1 200 OK Set-cookie:foo=31d4..aad42 [cookie !bound] <------------------------------ ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### Scenario 5: no connection header, TB-aware TTRP, !TB-wielding origin server [[ISSUE?]] Note: the difference between this scenario and scenario 2 is that the latter is a "TB-wielding TTRP" (ie, full-fledged TB-wise), and this is a "simple-minded" TTRP that may process the STB but in any case does not impl [2] and allows STB (if not in Connection header) to be forwarded along towards-OS. "simple minded" TB-wielding TB-aware client TTRP Origin Server [TB nego, [TB-nego, mints STB, ~process STB] does not list STB in Connection hdr] GET / HTTP/1.1 Host:... STB:AIkAAg...72REUA --------------------------------> [TB-nego] [STB passed-thru automatically? Is this a problem?] GET / HTTP/1.1 Host:... STB:AIkAAg..72REUA ? ----------------------------------> [!TB-nego] !! TBIDs sent to !TB-wielding server, is this a problem? NOTE: can't process STB or bound sec toks anyway, due to [3] S 4.2 and S 5. ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### Scenario 6: TB-wieldingDS TTRP, TB-wielding origin server [[ISSUE]] NOTE: We do not anticipate folks will implement TB-wieldingDS TTRP However, the Origin Server may receive multiple STB headers if a TTRP is (inadvertently) impl'd/config'd with TB enabled for towards-OS connections. TB-wielding TB-wieldingDS TB-wielding client TTRP Origin Server [TB nego, [TB-nego, [TB-nego, mints STB] process STB, process STB, mints STB of own] using TBC] 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, negotiate TB with OS, mint new STB for this conn to OS, optionally use Connection header.] GET / HTTP/1.1 Host:... STB:AIkAAg..72REUA TBC:AQAClt..7fFs4i STB:1dB_L5..Q59KCO {Connection:STB,TBC} ----------------------------------> [TB-nego] BUT: !! origin server confusion from multiple STBs !! ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### towards-OS: towards Origin Server- used to denote connection from TTRP in direction of origin server--from the TTRP's perspective. This is in contrast to client-side or from-client connections. Using towards-OS and client-side terms rather than "inbound" and "outbound" (from RFC7230 S 2.3) because the latter terms describe message directional flow, regardless of whether the msg is a request or a response, and do not descibe which "side" of a "gateway" (of which a TTRP is an instance) _connections_ are on. "Upstream" and "downstream" are similarly defined from a message flow perspective by RFC7230. client (UA) ------------------ TTRP ------------------ OS <-- client-side towards-OS --> <-- client-side towards-OS --> client (UA) ------------ proxy ------------- TTRP ------------- OS <-- client-side towards-OS --> ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### ----+----1----+----2----+----3----+----4----+----5----+----6----+---- end