TLS Working Group TLS Pathsec Protocol Joseph Hui INTERNET-DRAFT Digital Island Expires March, 2002 September, 2001 Intended Category: Standards track TLS Pathsec Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Hui Expires: March 2002 [Page 1] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 Abstract The TLS Pathsec Protocol (or Pathsec Protocol in short) extends the TLS protocol into securing data in transit not only between two end points, but also between the intermediaries en route, based on TLS 1.0 with appropriate extensions that include injecting source routing policies above the Transport layer. A typical Pathsec session comprises several sub-sessions, each of which is a TLS session with Pathsec extended semantics. It involves a client, a server, one or more intermediaries, and three individually secured channels for data and signal transports. Integral to the Pathsec protocol are audit and opt-out features. The client or the server may selectively monitor the fidelity of the data arriving at the destination after (the data) having undergone purposed transformations performed by authorized and authenticated intermediaries designated in a routing metric; and if either end point finds the data exceedingly distorted, it may opt out gracefully. Hui Expires: March 2002 [Page 2] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 Table of Contents 1 Introduction .......................................... 4 1.1 Venue of Discourse .................................... 5 2 Terminology ........................................... 6 2.1 Key Word Convention ................................... 8 2.2 Data Type Convention .................................. 8 3 Pathsec Session ....................................... 9 3.1 Pathsec Main Channel ................................. 12 3.2 Pathsec Outbound Channel ............................. 12 3.3 Pathsec Inbound Channel .............................. 14 3.4 Pathsec Routing Metrics .............................. 14 3.4.1 Pathsec Strict Source (and Record) Routing ........... 17 3.4.2 Pathsec Loose Source (and Record) Routing ............ 18 3.5 Pathsec Extended TLS ClientHello/ServerHello ......... 21 3.6 Pathsec Extended TLS Alert ........................... 21 3.6.1 Pathsec Signals ...................................... 23 3.7 Pathsec Set-up ....................................... 30 3.8. Pathsec In-session ................................... 31 3.8.1 Pathsec Verify ....................................... 31 3.8.2 Pathsec Audit ........................................ 32 3.8.3 Pathsec Opt-out ...................................... 33 3.9 Pathsec Tear-down .................................... 33 3.10 Pathsec Close ........................................ 33 3.11 Pathsec Re-open ...................................... 33 4 Pathsec Extensions to TLS ............................ 34 5 Application Considerations ........................... 34 6 Security Considerations .............................. 34 6.1 Compromised Private Key .............................. 35 6.2 Compromised Sub-session Key .......................... 35 6.3 Compromised Master Secret ............................ 35 6.4 Compromised Pre-Master Secret ........................ 36 6.5 Ciphersuite Degradation .............................. 36 6.6 Perils of Sharing Master Secret Across Channels ...... 36 6.7 Intermediary Weakness ................................ 36 6.8 Remote Execute ....................................... 37 7 Internationalization Considerations .................. 37 8 Intellectual Property Rights ......................... 38 9 Acknowledgments ...................................... 38 10 References ........................................... 39 11 Author's Address ..................................... 40 Hui Expires: March 2002 [Page 3] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 1 Introduction This document describes the TLS Pathsec Protocol (or Pathsec Protocol in short) which extends the TLS protocol into securing data in transit not only between two end points, but also between the intermediaries en route. Based on TLS 1.0 [TLS1] with extensions defined in [TLSX] and inspired by IP source routing [IP,STEVENS,XMPR], Pathsec in general emulates the well established end-to-end model, with augmentation for injecting routing policy necessary for traversing designated intermediaries where data may undergo authorized transformation. Thus Pathsec, with security and robustness being the paramount goals, embeds no more intelligence than what is necessary for securing the payloads entrusted by both the client and its server during a secured session. For example. In a Pathsec session, Pathsec uses routing metrics for specifying the hops between end points and the orders of traversal; but the construction of the metrics, such as by provisioning or by discovery, is outside the scope of Pathsec. Pathsec is designed to be well suited for the request-response computing model where a client, a server, and zero or more intermediaries dot a linear processing path. Finite loops in a processing path are permissible, as they can be unfolded to form a linear pattern in Pathsec Routing Metrics. A typical Pathsec session comprises several sub-sessions, of which each is a TLS session with Pathsec extended semantics. It involves a client, a server, one or more intermediaries, and three individually secured channels for data and signal transports. The server and all intermediaries are individually authenticated according to the TLS protocol. Integral to the Pathsec protocol is an audit feature that allows the client or the server to selectively verify the fidelity of the data arriving at the destination. The feature is based on a "trust-but- verify" principle, for monitoring whether the extent of data distortion, which is the direct result of well-intended transformations performed by authorized and authenticated intermediaries designated in a routing metric, is within the limits of tolerance. Also integral to the Pathsec protocol is an opt-out feature that allows the client or the server, during a session, at unilateral discretion, gracefully, to opt out of Pathsec mode and switch into the conventional TLS mode, or to opt out of the session entirely, i.e. to abort the session in progress. Hui Expires: March 2002 [Page 4] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 Not unlike TLS or any cryptosystem, a Pathsec session is susceptible to catastrophic failure in the face of attacks aided by, for instance, compromised session key, compromised private key, compromised master secret, compromised pre-master secret, or security negligence. As a Pathsec session involves more hops than a conventional TLS session does, it inevitably presents a larger target for attackers, even though all hops are meant to be equally securable by design; thus, it is imperative that Pathsec practitioners (in implementation and in deployment) abide by the specification in strictest adherence. It is conceivable that Pathsec may, with reference to the end-to-end model, evolve into covering virtual end points, which may be surrogates or proxies of origin servers or user agents, in a secured content processing context. To the TLS protocol semantics, Pathsec adds a "pathsec_signal(120)" TLS alert, a "notification" alert level, an optional "extension" element to the Alert struct (for piggy-backing supplemental data for alert processing), and a pathsec_rm(6) extension to ClientHello and to ServerHello (for facilitating Pathsec source routing). IANA may be requested to assign a default port for Pathsec Intermediaries. 1.1. Venue of Discourse Please send comments on this document to the IETF TLF working group's mailing list, at the writing of this document: ietf-tls@lists.certicom.com , or directly to the author if the sender prefers: jhui@digisle.net . Hui Expires: March 2002 [Page 5] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 2 Terminology data fidelity The quality of data arriving at the destination of a content delivery path, measurable either quantitatively or qualitatively against the data at the source of the same content delivery path, for determining the extent of distortion. data integrity The quality of data arriving intact at the destination of a content delivery path. That is. if measured in terms of data fidelity, absolute data integrity means zero distortion. Message Digests are usually used for verifying data integrity. inbound/outbound Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server," and "outbound" means "traveling toward the user agent." [HTTP] In Pathsec, "inbound" means "traveling toward the Pathsec server, which may be an origin server or its surrogate/proxy," and "outbound" means "traveling toward the Pathsec client, which may not necessarily be a user agent." (Pathsec) Channels There are three duplex communication channels in a Pathsec Session: 1) the Main Channel; 2) the Outbound Channel; and 3) the Inbound Channel. Ref: Figure 1. *** Forward Compatibility Note: *** Pathsec may in the future support multiple Outbound Channels. (Pathsec) Client An end point in a Pathsec session. A Pathsec client is usually a user agent, but may also be some other application entity, such as a caching proxy in a content delivery network. (Pathsec) Hop The direct path between two (Pathsec) nodes. (Pathsec) Inbound Channel (IC) An inbound [HTTP] data channel from the client to the server, with one or more intermediaries en route. The hop connecting any two adjacent nodes is secured by a Pathsec Sub-session, in the form of a TLS session. Thus, an Inbound Channel is a chain of Pathsec Sub-sessions, starting at the client and ending at the server. (Pathsec) Inbound Intermediary (II) An intermediary in an Inbound Channel, identifiable in an Inbound Hui Expires: March 2002 [Page 6] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 Routing Metric. The numbering of Inbound Intermediaries always starts from the client. For example, the first II immediately next to the client is II1. (Pathsec) Inbound Routing Metric (IRM) An Inbound Routing Metric designates the hops from the client to the server, using a strict/loose source routing policy. (Pathsec) Main Channel (MC) A Pathsec Sub-session, in the form of a TLS session, between the client and the server, with no intermediaries involved. (Pathsec) Node A Pathsec client, server, or intermediary. (Pathsec) Outbound Channel (OC) An outbound [HTTP] data channel from the server to the client, with one or more intermediaries en route. The hop connecting any two adjacent hops is secured by a Pathsec Sub-session, in the form of a TLS session. Thus, an Outbound Channel is a chain of Pathsec Sub-sessions, starting at the server and ending at the client. (Pathsec) Outbound Intermediary (OI) An intermediary in an Outbound Channel, identifiable in an Outbound Routing Metric. The numbering of Outbound Intermediaries always starts from the client. For example, the first OI immediately next to the client is OI1. (Pathsec) Outbound Routing Metric (ORM) An Outbound Routing Metric designates the hops from the server to the client, using a strict/loose source routing policy. (Pathsec) Routing Metrics There are two types of Pathsec Routing Metrics: 1) Outbound Routing Metrics; and 2) Inbound Routing Metrics. (Pathsec) Server An end point in a Pathsec Session. A Pathsec server is usually an origin server but may also be some other application entity, such as an origin server's surrogate (or proxy). (Pathsec) Signal A Pathsec Signal is issued by a client, a server, or an intermediary in the form of a TLS alert. A Pathsec signal may be accompanied by supplemental message(s), synchronously. (Pathsec) Session and Sub-session A Pathsec Session is comprised of one or more Pathsec Sub- Hui Expires: March 2002 [Page 7] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 sessions, of which each is secured in the form of a TLS session between two adjacent Pathsec nodes. (Pathsec) Sub-session Key The TLS session key set for a Pathsec Sub-session, shared by two connecting Pathsec nodes. relay An intermediary that relays data or signal between client and server. upstream/downstream Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream. [HTTP] virtual end point A virtual end point -- with reference to the end-to-end y -- is a surrogate (or proxy) of a server or client. It is a terminal in a processing path (that involves a client, a server, and zero or more intermediaries). 2.1 Key Word Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KWORD]. 2.2 Data Type Conventions All data types specified in this document are to be interpreted as described in RFC-1832 [XDR] and RFC-2246 [TLS1]. Hui Expires: March 2002 [Page 8] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 3 Pathsec Session +-----------------------------------------------------------------+ | Client (C) | | if (verify(R,R'') > limit_of_tolerence) opt_out(); | +-----------------------------------------------------------------+ | ^ | ^ ^ | | ^ | | | | | | |Q 8| | | | | | | 3| |R'' | | | | | | v | | | | | | | +----------------+ +----------------+ | | | | | | | Inbound | | Outbound | | | | | | | | Intermediary 1 | | Intermediary 1 | 1| | | | | | | (II1) | | (OI1) | | | | | | |12 +----------------+ +----------------+ | |2 | | | | | ^ | | | | | |R'' |Q' 7| | | | | | | 4| |R' | | | | 11| | v | | | | | | | +----------------+ +----------------+ | | | | A| | | Inbound | | Outbound | | | | | | | | Intermediary 2 | | Intermediary 2 | | | | |10 | | | (II2) | | (OI2) | | | 9| | | | +----------------+ +----------------+ | | | |R | | | ^ | | V| | | | |Q'' 6| | | | | | | 5| |R v | v | | v v | +-----------------------------------------------------------------+ | Server (S) | | if (audit(R,R'') > limit_of_tolerence) opt_out(); | +-----------------------------------------------------------------+ KEYS: A -- Request (from server to client) to audit responses -- R vs. R''. Q -- Original request/query from client. Q' -- Result of transforming Q by Inbound Intermediary 1 (II1). Q'' -- Result of transforming Q' by Inbound Intermediary 2 (II1). R -- Original response from server. R' -- Result of transforming R by Outbound Intermediary 2 (OI2). R'' -- Result of transforming R' by Outbound Intermediary 1 (OI1). V -- Request (from client to server) to verify responses -- R vs. R''. Pathsec Main Channel encompasses paths: 1, 2, 9, 10, 11, and 12. Pathsec Inbound Channel encompasses paths: 3, 4, and 5. Pathsec Outbound Channel encompasses paths: 6, 7, and 8. Figure 1: Pathsec Session Conceptual/Data Flow Diagram Hui Expires: March 2002 [Page 9] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 +--------------+ | | | Open/Re-Open | | | +--------+ +--------------+ 16 | | | /----------------------------->| Close! | 1| | | | v | +--------+ +----------+ | +-------------+ ^ | | | | | | | SetUp-MC |--------/ | TearDown-OC | | | | | | | +----------+ +-------------+ | | | ^ | 2| 13| |12 | v v | | +----------+ 10 +-------------------------+ | | |<------| | | | SetUp-OC | | In-Session | |6 | |------>| |-----\ | +----------+ 11 +-------------------------+ | | | | | ^ | ^ | | | | | | 14| |15 | | | | | |4 v | | | | | | | +-------------+ | | | 3| 9| | | | |5 | | | | | | TearDown-IC | | | 7| v | | | | | | | +----------+ | | +-------------+ | | | | |<-----/ | v | | | SetUp-IC |--------/ 8 +--------------+ | | |------------------------------>| | | +----------+ | TearDown-All | \------------------------------------------->| | 7 +--------------+ KEYS: Label Alert/Signal Label Alert/Signal 1 -- pathsec_set_up_mc*, or nill 10 -- pathsec_set_up_oc* 2 -- pathsec_set_up_oc* 11 -- pathsec_oc_set_up* 3 -- pathsec_set_up_ic* 12 -- pathsec_tear_down_oc* 4 -- pathsec_ic_set_up* 13 -- pathsec_oc_torn_down* 5 -- pathsec_tear_down_all* 14 -- pathsec_tear_down_ic* 6 -- close_notify#, or nill 15 -- pathsec_ic_torn_down* 7 -- pathsec_tear_down_all* 16 -- close_notify#, or nill 8 -- pathsec_tear_down_all* 9 -- pathsec_set_up_ic* # Existing TLS Alert * Pathsec Signal ! Terminal State Figure 2: Pathsec State Machine Hui Expires: March 2002 [Page 10] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 Frequent referals to Figures 1 and 2 are deemed helpful for the discussions throughout the document. A Pathsec Session comprises one or more Pathsec Sub-session. A Pathsec Sub-session, secured in the same manner as a conventional TLS session with Pathsec-extended semantics, is held between two adjacent nodes along a Pathsec Channel. Architecturally, a Pathsec Session is conducted over three secured communication channels: the Main Channel; the Outbound Channel; and the Inbound Channel. The channels are constructed during a Pathsec Set-up, which occurs at the start of the session, or in the middle of the session at the cue of Pathsec signals. The Main Channel connects the server and the client directly. The Outbound Channel carries outbound data from the server to the client through one or more intermediaries. Conversely, the Inbound Channel carries inbound data from the client to the server through one or more intermediaries. The existence of the Main Channel is mandatory. The Outbound and Inbound channels are optional. In the absense of the Outbound Channel, the Main Channel takes over its functionality in the secured delivery of outbound data, e.g. server responses. In the absense of the Inbound Channel, the Main Channel takes over its functionality in the secured delivery of inbound data, e.g. client requests. In the absense of both Outbound and Inbound Channels, the Pathsec session is operating in TLS mode, i.e. just like a conventional TLS session, with the exception that a Pathsec signal -- pathsec_set_up_oc or pathsec_set_up_ic -- may switch the session into Pathsec mode. Pathsec signals are carried individually in a Pathsec extended TLS alert: pathsec_signal. A Pathsec Session is always started by the client (at the Open/Re- open state in the Pathsec State Machine. [Ref:Fig 2]). A Pathsec Session is set up by the construction of the Main, Outbound, and Inbound Channels, undergoing a series of state transitions: SetUp-MC -> SetUp-OC -> SetUp-IC -> In-Session. [Ref:Fig 2] While Pathsec is In-Session, either the client or the server MAY signal its counterpart to tear down the OC or the IC, or to set up the OC or the IC if none exists. In addition, Audit or Verify signals MAY also be sent by the server or the client, respectively. [Ref:3.8.1,3.8.2] The closure of a Pathsec Session, either by natural ending or by opt-out, is preceded by a TearDown-All process, which MUST sequentially close down the Inbound Channel, the Outbound Channel, Hui Expires: March 2002 [Page 11] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 and the Main Channel. [Ref:3.9,3.10] A closed Pathsec Session MAY be re-opened in manner similar to resuming a TLS session. [Ref:3.11] 3.1 Pathsec Main Channel The Main Channel (MC) is defined by a Pathsec sub-session in the form of a TLS session between the client and the server. There MUST NOT be any intermediary in MC. As a part of Pathsec Set-up, the construction of MC starts from the client, in the same manner as starting a TLS handshake, whose successful conclusion marks the establishment of MC, which MAY be optionally milestoned by the server issuing to itself and to the client a pathsec_mc_set_up signal. All TLS alerts, including Pathsec signals, may travel bi- directionally in MC. In the absence of OC, outbound data, such as application server responses, travel in MC. In the absence of IC, inbound data, such as application client requests, travel in MC. The server's responses to a client's request to verify data fidelity travel in MC. The client's responses to a server's request to audit (data fidelity e.g.) travel in MC. A fatal alert affecting MC SHALL always result in the closure of the entire Pathsec Session. MC MUST not share its pre-master and master secrets with OC. MC SHOULD NOT share its pre-master and master secrets with IC. 3.2 Pathsec Outbound Channel The Outbound Channel (OC) is defined by a chain of Pathsec sub- sessions in the form of hop-by-hop TLS sessions between the client and the server, inclusively. Hui Expires: March 2002 [Page 12] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 There SHOULD be one or more intermediaries in OC. There MAY also be zero intermediary in OC, i.e. a single-hop OC where the client also plays the role of OI1 and OIn. (OI1 is the intermediary that is next to the client in OC. OIn is the intermediary that is next to the server in OC.) The number of intermediaries is limited only by the size of the hopList element in the PathsecRoutingMetric data structure. [Ref:3.4] Note that when speaking of source routing in Pathsec, the client is always the source, where the channel construction (of hops eventually linking to the server) starts, irrespective of the channel being OC or IC. Once the channel has been set up, the concept of routing ceases to exist in a Pathsec node, which cares only to read from upstream and write to downstream. The number and the sequence of hops, as well as other route properties, are defined in an ORM. The client and the intermediaries MAY or MAY NOT modify certain aspects of the ORM, dependent upon the ORM properties specified by the server and the client. The ORM is carried outbound (via MC) in a TLS ServerHello pathsec_rm extension, or inbound (via OC) in a TLS ClientHello pathsec_rm extension, or in pathsec_signal_data accompanying a pathsec_set_up_oc signal (via MC). [Ref:3.4,3.6.1,TLSX] All TLS alerts, including Pathsec signals, may travel in OC, in any direction. Outbound application data, such as application server responses, travel in OC. The construction of OC is hop-by-hop, with the first hop starting from the client to OI1. During the client-OI1 TLS handshake, the ORM is passed from the client to OI1. Upon completion of the first hop, OI1 connects to the next intermediary, if any, designated in ORM, and iterates the Pathsec-augmented TLS handshake with OI2, passing along the ORM. The iteration ends at the last hop with the server as the terminus. The ShareMasterSecret property in ORM indicates if master secret is shared. If all nodes in OC are to share a common master secret, then the client is responsible for propagating a fixed set of keying material -- pre-master secret, client random, and server random towards the server. All nodes belonging to the channel are to use such set of keying material for sub-session key generation. Hui Expires: March 2002 [Page 13] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 If the nodes in OC do not share a common master secret, then each sub-session in OC holds its own keying secrets. OC SHOULD NOT share its pre-master and master secrets with IC. Prior to transporting application data in OC, the server MUST first audit the channel, by sending the client via MC a pathsec_ping signal that designates OC as the echo channel. The client MUST reply with a pathsec_echo via OC. By comparing the PathsecPing and PathsecEcho supplemental data accompanying the signals, the server is able to authenticate the channel. Upon positive authentication, the server sends the client a pathsec_echo_ok signal; otherwise, a fatal TLS alert is raised. [Ref:3.6.1] 3.3 Pathsec Inbound Channel The Outbound Channel semantics apply equally to the Inbound Channel. (That is, 3.3 is an almost-identical twin of 3.2, substituting: inbound for outbound; IC for OC; IRM for ORM; II1, II2, IIn for OI1, OI2, OIn, respectively; "client requests" for "server responses;" and pathsec_set_up_ic for pathsec_set_up_oc.) Whereas OC SHOULD NOT share its pre-master and master secrets with IC, IC MUST NOT share its pre-master and master secrets with OC. 3.4 Pathsec Routing Metrics There are two types of Pathsec Routing Metrics (RMs): 1) Outbound Routing Metrics (ORM), for routing application data from the server to the client; and 2) Inbound Routing Metrics (IRM), for routing application data from the client to the server. All Pathsec Routing Metrics share an identical format and have same semantics, as in the following: struct { RoutingPolicy routingPolicy; RouteLength routeLength; RoutePointer routePointer; RouteDirection routeDirection; ShareMasterSecret shareMasterSecret; ServerMayModHopList serverMayModHopList; ClientMayModHopList clientMayModHopList; IntermMayModHopList intermMayModHopList; opaque serverRandom[32]; /* also serves as * channel ticket */ opaque pathsecReserved[64]; Hui Expires: March 2002 [Page 14] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 opaque hopList<1..2^14> } PathsecRoutingMetric; enum { loose_source_routing(0x83), /* 0x83 & 0x89 are from IP */ strict_source_routing(0x89) /* default */ } RoutingPolicy; typedef uint8 RouteLength; typedef unit8 RoutePointer; enum { outbound(1), inbound(2) } RouteDirection; /* no default */ enum { dont_share_master_secret(0), share_master_secret(1) /* default */ } ShareMasterSecret; enum { server_may_not_modify_hop_list(0), server_may_modify_hop_list(1) /* default */ } ServerMayModRM; enum { client_may_not_modify_hop_list(0), client_may_modify_hop_list(1) /* default */ } ClientMayModRM; enum { interm_may_not_modify_hop_list(0), /* default */ interm_may_modify_hop_list(1) } IntermMayModRM; hopList := hops hops := hostport [ , hops ] hostport := host [ : port ] host := hostname | hostnumber hostname := ialpha [ . hostname ] hostnumber := digits . digits . digits . digits port := digits (Refer to [URI] for ialpha and digits.) Pathsec server and intermediaries share with TLS the same default Hui Expires: March 2002 [Page 15] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 port: 443. *** Forward Compatibility Note: *** IANA may be requested to assign a new default port for *** Pathsec Intermediaries. An examples of (comma-delimited) hopList: "I1.x.com,I2.y.com:4567,server.z.com:7890" is a three-hop list such that in an ORM, application data flow in the way of: server.z.com:7890 -> I2.y.com:4567 -> I1.x.com -> client and in an IRM, application data flow in the way of: client -> I1.x.com -> I2.y.com:4567 -> server.z.com:7890 A Routing Metric (RM) may be carried in a pathsec_rm extension in a ServerHello or a ClientHello. It may also be carried in the pathsec_signal_data accompanying a pathsec_set_up_oc or pathsec_set_up_ic signal, which is delivered in a TLS alert typed pathsec_signal. Either the server or the client MAY be the RM originator, whose wishes (as specified in routingPolicy, routeDirection, shareMasterSecret, serverMayModHopList, clientMayModHopList, intermMayModHopList, and hopList) must be respected by all nodes in a channel, with the following exceptions. The server MAY negotiate loose_source_routing to strict_source_routing; the server MAY negotiate server_may_not_modify_hop_list to server_may_modify_hop_list; the server MAY negotiate the server MAY negotiate interm_may_modify_hop_list to interm_may_not_modify_hop_list; or the server MAY negotiate share_master_secret to dont_share_master_secret. The client MUST NOT perterb the "server-side" hops specified by the server, though it MAY prepend "client-side" hops to hopList. The server SHOULD NOT perterb the "client-side" hops specified by the client, though it MAY append "server-side" hops to them. RoutingPolicy is for the originator of an RM, usually the server but sometimes the client, to specify the routing policy governing a Pathsec channel: loose source routing, or strict source routing (the default). RoutingPolicy, once set, SHOULD NOT be changed. All nodes MUST execute the routing policy in the exact manner as described in [3.4.1] and [3.4.2]. (Also refer to [IP,STEVENS] for the workings of IP source routing.) RouteLength specifies the number of hops in hopList, e.g. 3 for three hops. Hui Expires: March 2002 [Page 16] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 RoutePointer points at the destination node of the current hop. RoutePointer increments by 1 per hop. RouteDirection indicates if the route is for inbound or outbound application data. For example, if routeDirection = outbound, then the RM is for OC, i.e. ORM. ShareMasterSecret indicates if all nodes belonging to the channel that employs the RM are to share a common master secret for keying purpose. ServerMayModHopList indicates if the server may modify hopList. ClientMayModHopList indicates if the client may modify hopList. IntermMayModHopList indicates if the intermediaries may modify hopList. ServerRandom contains the server random for keying purpose, in case of share_master_secret. ServerRandom also serves as the channel ticket, by which the server, which may face multiple connection requests, determines which channel a connecting party belongs to during a TLS handshake. PathsecReserved is a dummy at the writing of this document. HopList contains the list nodes en route, in format defined above. The first node is always II1 or OI1, and the last node is always the server, because the construction of IC or OC always starts from the client. All nodes in a channel must observe the rules set in: serverMayModHopList, clientMayModHopList, and intermMayModHopList, with few forementioned server exceptions. 3.4.1 Pathsec Strict Source (and Record) Routing In Pathsec strict source (and record) routing (PSSRR), the client of a Pathsec channel to be constructed is first given an RM, i.e. PathsecRoutingMetric, either through a ServerHello pathsec_rm extension or in the pathsec_signal_data accompanying a pathsec_set_up_ic/pathsec_set_up_oc signal, where routingPolicy is set to strict_source_routing. The RM is to be forwarded inbound through a ClientHello pathsec_rm extension during the TLS handshakes that will establish the sub-sessions in the channel. Before forwarding the RM in a ClientHello, a Pathsec node MUST increment routePointer by 1. Hui Expires: March 2002 [Page 17] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 Each node (in the channel) uses routePointer as the locator for determining its TLS server (in a Pathsec sub-session) to connect to, only if routePointer is not greater than routeLength. For example, if routePointer is 2, then the second node in hopList is the TLS server of the sub-session to be established. If routePointer is greater the routeLength, then the end of the route has been reached. (Note that routePointer pointing at the Pathsec server does not necessarily indicate the end of the route.) An intermediary MUST be aware that if routeLength equals routePointer in the RM given, then it is the last intermediary in the channel, e.g. OIn, or IIn, and may be called upon to perform a special task (such as flipping an authentication string) in channel authentication later. [Ref:3.6.1-pathsec_echo] Figure 3 illustrates the algorithm of Pathsec strict source (and record) routing by example. The recording of the route is done by leaving hopList alone and incrementing routePointer properly in each hop. 3.4.2 Pathsec Loose Source (and Record) Routing Pathsec loose source (and record) routing (PLSRR) works in similar ways as PSSRR does, with the crucial exception that the client or an intermediary may, if permitted by the client_may_modify_hop_list or interm_may_modify_hop_list respectively, properties in the RM, insert hops between the Pathsec server and itself. (The routingPolicy in the RM MUST be pre-set to loose_source_routing prior to channel construction.) Figure 4 illustrates the algorithm of Pathsec loose source (and record) routing by example. The recording of the route is done by properly updating hopList and routeCount, and incrementing routePointer in each hop. Hui Expires: March 2002 [Page 18] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 +-------+ | C | +-------+ routeLength = 3 | routePointer = 1 * | hopList = {I1,I2,S} | Pathsec sub-session TLS client = C | Pathsec sub-session TLS server = I1 v +-------+ | I1 | +-------+ routeLength = 3 | routePointer = 2 * | hopList = {I1,I2,S} | Pathsec sub-session TLS client = I1 | Pathsec sub-session TLS server = I2 v +-------+ | I2 | +-------+ routeLength = 3 | routePointer = 3 * | hopList = {I1,I2,S} | Pathsec sub-session TLS client = I2 | Pathsec sub-session TLS server = S v +-------+ | S | +-------+ routeLength = 3 routePointer = 4 hopList = {I1,I2,S} The hopList given to Pathsec client C is {I1,I2,S} where S is the Pathsec server; I1 and I2 are intermediaries; routeLength is 3; and routePointer is initially 1. Figure 3: Pathsec Strict Source (and Record) Routing Hui Expires: March 2002 [Page 19] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 +-------+ | C | +-------+ routeLength = 3 | routePointer = 1 * | hopList = {I1,I2,S} | Pathsec sub-session TLS client = C v Pathsec sub-session TLS server = I1 +-------+ | I1 | +-------+ routeLength = 3 | routePointer = 2 | hopList = {I1,I2,S} | I1 inserts I1a and I1b into hopList, then | routeLength = 5 | routePointer = 2 * | hopList = {I1,I1a,I1b,I2,S} | Pathsec sub-session TLS client = I1 v Pathsec sub-session TLS server = I1a +-------+ | I1a | routeLength = 5 +-------+ routePointer = 3 * | hopList = {I1,I1a,I1b,I2,S} | Pathsec sub-session TLS client = I1a v Pathsec sub-session TLS server = I1b +-------+ | I1b | routeLength = 5 +-------+ routePointer = 4 * | hopList = {I1,I1a,I1b,I2,S} | Pathsec sub-session TLS client = I1b v Pathsec sub-session TLS server = I2 +-------+ | I2 | routeLength = 5 +-------+ routePointer = 5 * | hopList = {I1,I1a,I1b,I2,S} | Pathsec sub-session TLS client = I2 v Pathsec sub-session TLS server = S +-------+ | S | routeLength = 5 +-------+ routePointer = 6 hopList = {I1,I1a,I1b,I2,S} The hopList given to Pathsec client C is {I1,I2,S} where S is the Pathsec server; I1 and I2 are intermediaries; I1a and I1b are intermediaries inserted by I1; routeLength is initially 3, and is changed to 5 by I1; and routePointer is initially 1. Figure 4: Pathsec Loose Source (and Record) Routing Hui Expires: March 2002 [Page 20] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 3.5 Pathsec Extended TLS ClientHello/ServerHello Pathsec adds "pathsec_rm" to the existing TLS extensions defined in [TLSX]. It is to be included in ServerHello or ClientHello as applicable. [Ref:3.4] The following list enumerates the TLS extension types defined in [TLSX] at the writing of this document, plus pathsec_rm: enum { dns_name(0), max_record_size(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5), pathsec_rm(6), /* new for Pathsec */ (65535) } ExtensionType; Origin servers, surrogates, proxies, and user agents that do not understand the pathsec_rm extension SHOULD simply ignore the extension. 3.6 Pathsec Extended TLS Alert The Pathsec Protocol extends the TLS Alerts data structure (defined in [TLS1]) to include an optional element: "extension." Pathsec also introduces a new alert level: "notification;" and a new alert type: "pathsec_signal." The notification level is for accommodating alerts that are difficult to precisely characterize as warning or fatal. The recipient MUST NOT ignore the alert, unless it does not support the alert type specified in the description field. The optional Alerts.extension is for piggy-backing supplemental data for alert processing. The sender and recipient(s) MUST cast the opaque Alerts.extension data into alert-type-specific data structure(s) for further processing. In the case of Pathsec, the extension data is cast into the PathsecAlert data structure defined in 3.6.1. *** Author's Note: *** [TLS1] did not script a forward compatibility note for alert *** extensions; so backward compatibility issues related to an *** extended TLS Alert struct are open at the writing of this *** document. Origin servers, surrogates, proxies, and user agents that do not support pathsec_signal SHOULD raise an unexpected_message alert to Hui Expires: March 2002 [Page 21] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 the pathsec_signal sender. The following describes the Pathsec extended TLS Alert data structure and enumerates TLS alerts, including pathsec_signal, which is an addition to the TLS alerts having been compiled in [TLSX], at the writing of this document: struct { AlertLevel level; AlertDescription description; opaque extension<0..2^16-1>; /* new for Pathsec */ } Alert; enum { warning(1), fatal(2), notification(3), /* new for Pathsec */ (255) } AlertLevel; enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed(21), record_overflow(22), decompression_failure(30), handshake_failure(40), certificate_unobtainable(41), /* new for TLSX */ bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110), /* new for TLSX */ bad_extension_order(111), /* new for TLSX */ unrecognised_domain(112), /* new for TLSX */ Hui Expires: March 2002 [Page 22] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 bad_ocsp_response(113), /* new for TLSX */ pathsec_signal(120), /* new for Pathsec */ (255) } AlertDescription; [Ref:TLS1,TLSX] 3.6.1 Pathsec Signals This section describes the Pathsec Signals. All Pathsec nodes MUST relay Pathsec signals downstream. A Pathsec signal affects all nodes in its path, including the end point(s) where it expires. A Pathsec signal is delivered in a pathsec_signal TLS alert, with a TLS alert extension that is to be cast into the PathsecAlert data structure defined as follows. struct { PathsecSignal pathsec_signal_type; opaque pathsec_signal_data<0..2^15-1>; } PathsecAlert; enum { pathsec_set_up_mc(1), pathsec_mc_set_up(2), pathsec_set_up_oc(3), pathsec_oc_set_up(4), pathsec_set_up_ic(5), pathsec_ic_set_up(6), pathsec_tear_down_mc(7), pathsec_mc_torn_down(8), pathsec_tear_down_oc(9), pathsec_oc_torn_down(10), pathsec_tear_down_ic(11), pathsec_ic_torn_down(12), pathsec_tear_down_all(13), pathsec_verify_request_start(14), pathsec_verify_request_end(15), pathsec_verify_response_start(16), pathsec_verify_response_end(17), pathsec_opt_out_oc(18), pathsec_opt_out_oc_ack(19), pathsec_opt_out_oc_nack(20), pathsec_opt_out_ic(21), pathsec_opt_out_ic_ack(22), pathsec_opt_out_ic_nack(23), pathsec_source_route_failed(24), pathsec_feature_unsupported(25), Hui Expires: March 2002 [Page 23] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 pathsec_ping(26), pathsec_echo(27), pathsec_echo_ok(28), (255) } PathsecSignal; pathsec_set_up_mc(1) The client or server may optionally send pathsec_set_up_mc to itself (for invoking a pathsec_set_up_mc callback, e.g.). Upon receipt of this signal, the client or server enters the SetUp-MC state (in the Pathsec State Machine). pathsec_mc_set_up(2) Either the client or server may optionally send or receive pathsec_mc_set_up upon exit of SetUp-MC, which is to be followed by SetUp-OC. pathsec_set_up_oc(3) The server sends this signal to the client via MC, and optionally to itself. The receiver of this signal MUST enter SetUp-OC. The pathsec_signal_data accompanying this signal contains a PathsecRoutingMetric, where routeDirection = outbound, i.e. an ORM. The client MUST start constructing the OC according to the ORM. The server MUST listen for an outstanding OC connection request, at the server port specified/implied in the ORM. pathsec_oc_set_up(4) The server sends pathsec_oc_set_up to the client via MC, and optionally to itself, upon the completion of SetUp-OC. pathsec_set_up_ic(5) The server sends this signal to the client via MC, and optionally to itself. The receiver of this signal MUST enter SetUp-IC. The pathsec_signal_data accompanying this signal contains a PathsecRoutingMetric, where routeDirection = inbound, i.e. an IRM. The client MUST start constructing the IC according to the IRM. The server MUST listen for an outstanding IC connection request, at the server port specified/implied in the IRM. The client MAY also send this signal to the server, enclosing in pathsec_signal_data an IRM with "client-side" hops. In such case, the server MAY optionally prepend "server-side" hops to the "client-side" hops, by inserting "server-side" nodes in front of Hui Expires: March 2002 [Page 24] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 the last node in hopList. For example, "cs1,cs2,svr" becomes "cs1,cs2,ss1,ss2,svr." The server then sends back to the client a pathsec_set_up_ic, with a newly negotiated IRM if applicable. pathsec_ic_set_up(6) The server sends pathsec_ic_set_up to the client via MC, and optionally to itself, upon the completion of SetUp-IC. pathsec_tear_down_mc(7) This signal SHOULD NOT be used, pending future specification. (If MC goes, so go all channels and the entire Pathsec session. Thus pathsec_tear_down_all seems to be more appropriate for virtually all foreseeable cases at the writing of this document.) pathsec_mc_torn_down(8) This signal SHOULD NOT be used, pending future specification. pathsec_tear_down_oc(9) The server MAY at any time send via OC the client pathsec_tear_down_oc, and vice versa. Both the signal sender and receiver must enter TearDown-OC immediately. Each intermediary en route MUST immediately forward the signal downstream, and then enter TearDown-OC itself. The server and client MUST notify their respective applications of this signal, and data pending for read/write MAY be flushed. pathsec_oc_torn_down(10) The server sends pathsec_oc_torn_down to the client via MC, and optionally to itself, upon the completion of TearDown-OC. pathsec_tear_down_ic(11) The server MAY at any time send via IC the client pathsec_tear_down_ic, and vice versa. Both the signal sender and receiver must enter TearDown-IC immediately. Each intermediary en route MUST immediately forward the signal downstream, and then enter TearDown-IC itself. The server and client MUST notify their respective applications of this signal, and data pending for read/write MAY be flushed. pathsec_ic_torn_down(12) The server sends pathsec_ic_torn_down to the client via MC, and Hui Expires: March 2002 [Page 25] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 optionally to itself, upon the completion of TearDown-IC. pathsec_tear_down_all(13) The server MAY at any time send via MC the client pathsec_tear_down_all, and vice versa. Both the signal sender and receiver must enter TearDown-All immediately. Pathsec_tear_down_all signals the imminent closure of the Pathsec session. All channels are to be torn down as soon as possible, with provision for I/O flushing as appropriate. The server and client MUST notify their respective applications of this signal, and data pending for read/write MAY be flushed. pathsec_verify_request_start(14) The server MAY send via MC the client, and vice versa, a pathsec_verify_request_start to initiate a process to verify the data fidelity in OC. pathsec_verify_request_end(15) The server MAY send via MC the client, and vice versa, a pathsec_verify_request_end to terminate the process of verifying the data fidelity in OC. pathsec_verify_response_start(16) The receiver of pathsec_verify_request_start responses with a pathsec_verify_response_start to signal that verification data is forthcoming. pathsec_verify_response_end(17) The receiver of pathsec_verify_request_end responses with a pathsec_verify_response_end to signal the end of verification data. pathsec_opt_out_oc(18) The server MAY send via MC the client, and vice versa, a pathsec_opt_out_oc to tear down OC. The signal sender SHOULD time out (with a pathsec_opt_out_oc_nack) if it does not receive a pathsec_opt_out_oc_ack in 10 seconds. pathsec_opt_out_oc_ack(19) The client or the server MUST send via MC pathsec_opt_out_oc_ack to acknowledge the receipt of pathsec_opt_out_oc, prior to Hui Expires: March 2002 [Page 26] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 entering TearDown-OC. Upon receiving pathsec_opt_out_oc_ack, the pathsec_opt_out_oc sender SHOULD enter TearDown-OC. pathsec_opt_out_oc_nack(20) Upon timing out of a pathsec_opt_out_oc, the pathsec_opt_out_oc sends itself and optionally the pathsec_opt_out_oc receiver a pathsec_opt_out_oc_nack, via MC. pathsec_opt_out_ic(21) The server MAY send via MC the client, and vice versa, a pathsec_opt_out_ic to tear down IC. The signal sender SHOULD time out (with a pathsec_opt_out_ic_nack) if it does not receive a pathsec_opt_out_ic_ack in 10 seconds. pathsec_opt_out_ic_ack(22) The client or the server MUST send via MC pathsec_opt_out_ic_ack to acknowledge the receipt of pathsec_opt_out_oc, prior to entering TearDown-OC. Upon receiving pathsec_opt_out_ic_ack, the pathsec_opt_out_oc sender SHOULD enter TearDown-IC. pathsec_opt_out_ic_nack(23) Upon timing out of a pathsec_opt_out_ic, the pathsec_opt_out_ic sends itself and optionally the pathsec_opt_out_ic receiver a pathsec_opt_out_ic_nack, via MC. pathsec_source_route_failed(24) This signal SHOULD NOT be used, pending future specification. A Pathsec intermediary, in case of locally fatal error, sends a pathsec_source_route_failed in both upstream and downstream directions. This signal is fatal to the channel. Upon receiving pathsec_source_route_faile, the server and the client SHOULD independently signal pathsec_tear_down_oc (or pathsec_tear_down_ic as applicable). The client and server applications MUST be notified of the source route failure. The channel torn down MAY be re-constructed, provide at least one application layered above Pathsec commands the server or the client to signal pathsec_set_up_oc (or pathsec_set_up_ic as applicable). pathsec_feature_unsupported(25) A Pathsec node is being requested (by the client or the server) to perform a task it does not support, then it sends a pathsec_feature_unsupported upstream, which will be relayed to the Hui Expires: March 2002 [Page 27] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 requester. pathsec_ping(26) & pathsec_echo(27) The server MAY send a pathsec_ping to the client, and vice versa, only via MC, for the purposes of: 1) the pinger inquiring the highest Pathsec version supported by the echo-er; and 2) the server authenticating a channel that might have been constructed without Client Authentication during TLS Handshake(s) earlier. (For example, a bogus last intermediary could gain "acquaintance" with a Pathsec server using replay attack with an intercepted channel ticket embedded in a ClientHello's plain-text serverRandom, if the server did not demand Client Authentication Handshake. Note that in Pathsec, the server by default does not demand Client Authentication Handshake, because the last intermediary may also be the Pathsec client (in a one-hop channel) which may happen to be a user agent, and it is not common practice that user agents are in possesion of certificates.) The pinger packs pathsec_signal_data with a PathsecPing (defined below). The echo-er copies (or cast) a PathsecPing into a PathsecEcho (also defined below), assigning proper values to echo_major and echo_minor, and then emits the PathsecEcho (in pathsec_signal_data) via the channel indicated by echo_channel_id. The PathsecPing sender (aka pinger) SHOULD time out, if the expected PathsecEcho fails to arrive within a reasonable time limit: 10 seconds * approximated-number-of-hops-in-echo-channel. All intermediaries relaying a PathsecEcho towards its destination, except the last intermediary next to the pinger in the echo channel, MUST NOT modify the content of a PathsecEcho. PathsecPing and PathsecEcho are defined as follows. struct { uint16 ping_id; uint16 echo_channel_id; uint8 ping_major; uint8 ping_minor; unit8 echo_major; uint8 echo_minor; opaque random[24]; } PathsecPing; struct { uint16 ping_id; uint16 echo_channel_id; uint8 ping_major; Hui Expires: March 2002 [Page 28] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 uint8 ping_minor; unit8 echo_major; uint8 echo_minor; opaque random[20]; } PathsecEcho; Ping_id is for tracking pings and echos. Its value is set by the pinger and MUST NOT be modified by the echo-er or relays. The value set is unique within an echo channel, and may wrap around. Echo_channel_id indicates the channel via which the PathsecEcho MUST travel. Its value is set by the pinger and MUST NOT be modified by the echo-er or relays. There are three permanently pre-defined values: 0 -- via MC; 1 -- via OC; 2 -- via IC. *** Forward Compatibility Note: *** Future Pathsec versions may support more than three channels. Ping_major and ping_minor indicate the highest major and minor numbers of the Pathsec version the pinger supports, starting from major 1, minor 0. The pinger MUST instantiate ping_major and ping_minor with correct values; and set echo_major and echo_minor to 0. Echo_major and echo_minor indicate the highest major and minor numbers of the Pathsec version the echo-er (of a PathsecPing) supports, starting from major 1, minor 0. The echo-er, who is the originater of a PathsecEcho in reply to a PathsecPing, MUST instantiate echo_major and echo_minor with correct values. Major number being 0 indicates the version is experimental. Experimental versions MUST have non-zero minor numbers. PathsecEcho.random contains 20 random bytes copied from EchosecPing.random, which was generated by the pinger, for the purpose of authenticating the echo channel. The last intermediary in the echo channel MUST reverse the byte sequence of PathsecEcho.random, i.e. the first byte becomes the last, the last byte becomes the first, and so on, prior to forwarding the PathsecEcho to its destination -- the server. pathsec_echo_ok(28) The pinger MUST keep a copy of the PathsecPing sent. Upon receipt of a PathsecEcho, the pinger MUST compare the ping_id and echo_channel_id in the PathsecPing and PathsecEcho for identical matches. Additionally, if the echo channel is not MC (i.e. echo_channel_id != 0), then the pinger MUST reverse the byte sequence in PathsecEcho.random and compare PathsecPing.random to Hui Expires: March 2002 [Page 29] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 PathsecEcho.random. If they are equal, then the echo channel is authenticated, and a pathsec_echo_ok signal is to be sent over MC to the echo-er, accompanied by the PathsecEcho with the PathsecEcho.random in original byte sequence (originally set by the pinger). Otherwise, the last intermediary is deemed an imposter, because it has failed to decipher the PathsecEcho (in order to reverse the bytes in PathsecEcho.random); and an "insufficient_security" TLS fatal alert MUST be raised. Application data SHOULD NOT travel in OC or IC unless the channel in question has been "certified" for use by a pathsec_echo_ok. The pinger MAY discard the PathsecPing copy it keeps after processing the corresponding PathsecEcho. 3.7 Pathsec Set-up The Pathsec Set-up involves three major steps of state transitions: Open/Re-open -> SetUp-MC -> SetUp-OC -> SetUp-IC -> In-Session [Ref:Fig 2] Step 1: the client, in SetUp-MC state, initiates connection to the server to establish the the Main Channel, using TLS handshake with Pathsec-extended ClientHello and ServerHello. [Ref:3.1,3.5;3.6.] In case of a fatal alert, the session -- server and client -- transits to the Close state; else, the session enters SetUp-OC. Step 2: the client, in SetUp-OC state, scans the ServerHello extensions for ORM. If one exists, then it proceeds to set up the Outbound Channel. Using the ORM embedded in a ServerHello extension as the guideline, it initiates connection to the first Outbound Intermediary (the OI1 designated in the ORM), which in turn initiates connection to the next OI (if one exists), and so on, eventually connecting to the server. [Ref:3.2] In case of a fatal error, the session -- client, server, and all intermediaries -- enters TearDown-All state; else, the session enters SetUp-IC state. Step 3: the client, in SetUp-IC state, scans the ClientHello extensions for IRM. If one exists, optionally sets up the Inbound Channel. Using the Inbound Routing Metric embedded in a ClientHello Extension, which the client has previously sent to the server while setting up the Main Channel, it (the client) initiates connection to the first Inbound Intermediary (i.e. the II1 designated in the IIM), which in turn initiates connection to the next II, and so on, Hui Expires: March 2002 [Page 30] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 eventually connecting to the server. [Ref:3.3] The successful completion of a Pathsec Set-up is always followed by In-Session state. [Ref:Fig 2] 3.8 Pathsec In-Session When a Pathsec session is in In-Session state, application data flow is guaranteed. Alerts and signals flow freely at any time. During In-Session, the server MAY at any time via MC send the client a pathsec_set_up_oc or a pathsec_set_up_ic signal to cause both the server and the client to enter SetUp-OC or SetUp-IC, respectively. During In-Session, the server MAY at any time via MC send the client, or vice versa, a pathsec_tear_down_oc or a pathsec_tear_down_ic signal to cause both the server and the client to enter TearDown-OC or TearDown-IC, respectively. During In-Session, the server MAY at any time via MC send the client, or vice versa, a pathsec_tear_down_all signal to cause both the server and the client to enter TearDown-ALL. The following signals always bring the Pathsec session back to In- Session: pathsec_oc_set_up, pathsec_ic_set_up, pathsec_oc_torn_down, and pathsec_ic_torn_down, During In-Session, the arrival of verify/audit and opt-out signals SHALL cause no state transition. [Ref:3.6.1] A multi-threaded implementation MAY, in the interest of optimizing application data throughput, off-load signal handling, which often requires the session to enter a new state (e.g. SetUp-IC) and then to return to In-Session. However, the implenmentor is responsible for synchronizing the In-Session thread with the off-loaded signal thread(s) such that there MUST NOT be dead-locking or inconsistency in payload presentatiion (to the application layered above Pathsec). 3.8.1 Pathsec Verify A Pathsec Verify is always initiated by the client. (If initiated by the server, then it is termed Pathsec Audit.) Hui Expires: March 2002 [Page 31] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 The client MAY at any time send a pathsec_verify_request_start signal to the server via MC, in order to verify the data fidelity in OC, per request from its appication above the Pathsec layer. The server MUST signal its own application layered above Pathsec to start a data verification process. The verification data, which is identical to the data that the server releases into OC, is transmitted over MC. The server, commanded by its application layered above, signals the client that verification data is forthcoming with a pathsec_verify_response_start. The server and client applications MUST device their own means for delimiting the data being verified, e.g. starting from the next HTTP response. The data verification request is in force until the client signals the server with a pathsec_verify_request_end. The data verification response is in force until the server signals the client with a pathsec_verify_response_end. 3.8.2 Pathsec Audit A Pathsec Audit is always initiated by the server. (If initiated by the client, then it is termed Pathsec Verify.) A Pathsec Audit may take one of two forms: 1) verifying the data fidelity in OC; or 2) authenticating IC or OC. The server MAY at any time send a pathsec_verify_request_start signal to the client via MC, in order to verify the data fidelity in OC, per request from its appication above the Pathsec layer. The client MUST signal its own application layered above Pathsec to start a data verification process. The verification data, which is the data that the client receives from OC, is transmitted over MC. The client, commanded by its application layered above, signals the server that verification data is forthcoming with a pathsec_verify_response_start. The server and client applications MUST device their own means for delimiting the data being verified, e.g. starting from the next HTTP response. The data verification request is in force until the server signals the client with a pathsec_verify_request_end. Hui Expires: March 2002 [Page 32] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 The data verification response is in force until the client signals the server with a pathsec_verify_response_end. [Ref:3.6.1] Refer to the pathsec_ping, pathsec_echo, and pathsec_echo_ok sub- sections in [3.6.1] for the details of authenticating an inbound/outbound channel without using certicate or password. 3.8.3 Pathsec Opt-out Either the client or the server MAY opt out of OC, or IC, or the entire Pathsec session, at any time, without cause, by raising pathsec_opt_out_oc, pathsec_opt_out_ic, or pathsec_tear_down_all, respectively. Refer to the raising pathsec_opt_out_oc, pathsec_opt_out_oc_ack, pathsec_opt_out_oc_nack, pathsec_opt_out_ic, pathsec_opt_out_ic_ack, pathsec_opt_out_ic_nack, pathsec_tear_down_all, respectively. and pathsec_tear_down_all sub-sections in [3.6.1] for the workings of opt-out signal processing. The opt-out feature is not available for intermediaries. A Pathsec implementation MUST provide the necessary API for applications layered above Pathsec to exercise opt-outs. 3.9 Pathsec Tear-down All nodes in an IC or OC receiving a pathsec_tear_down_ic or pathsec_tear_down_oc respectively MUST propagate the received signal downstream, and then proceed to close down its upstream and downstream connections. The server and the client should signal themselves with pathsec_ic_torn_down or pathsec_oc_torn_down as appropriate. 3.10 Pathsec Close The closure of a Pathsec session SHOULD be preceeded by the tear- downs of the channels, in strict sequence: IC, OC, and MC. 3.11 Pathsec Re-open A naturally closed Pathsec session, i.e. the closure was not due to a Hui Expires: March 2002 [Page 33] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 fatal alert, MAY be re-opened in manner similar to resuming a TLS session, using section ID as resumption hint. In order to support Re-open, both the client and the server MUST be able to cache the routing metrics of a resumable session off-line. 4 Pathsec Extensions to TLS Refer to sections 3.5 and 3.6. 5 Application Considerations Pathsec, co-locating with TLS (above the transport layer) of the OSI stack, is semantically indifferent to the payload it carries. Nonetheless, Pathsec is designed to be well suited for the request- response computing model where a client, a server, and zero or more intermediaries dot a linear processing path. Finite loops in a processing path are permissible, as they can be unfolded to form a linear pattern in a Pathsec Routing Metric. It is conceivable that Pathsec MAY be used by applications that involve value-added services provided by intermediaries trusted and verified by servers and clients. It MAY also be used by content delivery networks (CDNs) for transporting secured payloads, such as propagating secured resource updates, say, multicasting authenticated cache invalidation signals from an origin server to its caching proxies. (For reference of application models that are being discussed by IETF working groups and may find Pathsec relevant, consult literature in [OPES], [WEBI], [CDI].) It is conceivable that Pathsec may evolve into covering virtual end points -- in end-to-end simile -- which may be surrogates and proxies of origin servers or user agents, in a secured content processing context. 6 Security Considerations Unless stated otherwise, all failure modes discussed in this section are catastrophic, though variable in scope of damage. They all warrant fatal alerts, in spite some damaged sessions may be salvageable. The server MAY opt to NOT salvage a salvageable session without cause. Note that detection of failure modes discussed herein is outside the scope of the Pathsec protocol. All Pathsec practitioners (in implementation and in deployment) Hui Expires: March 2002 [Page 34] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 SHOULD be well acquainted with historic and up-to-date issues related to network, data, and system security. [Ref:DENNING,NICHOLS,RESCORLA,STARTLS,TLS1,TLSX] 6.1 Compromised Private Key If the private key of a Pathsec node is compromised, then the Pathsec Channel involving the compromised node is also compromised for good and MUST be torn down. If the compromised node is either the client or the server, then the session is compromised. All nodes in session MUST enter the TearDown-All state, to be followed by Close. The routing metric containing the compromised node is compromised indefinitely, until a new and valid private key is available. The server (and the client if applicable) MUST mark the routing metric unusable until proper key replenishment. If the compromised node is an intermediary, then the session may be salvageable, only by the server. If the compromised metric can be replaced by an alternative one or be repaired with a new private key, then the server MUST issue pathsec_tear_down_oc or pathsec_tear_down_ic as appropriate, and all nodes in the damaged channel MUST enter TearDown-OC (or TearDown-IC as appropriate), and then return to In-Session. After receiving a pathsec_oc_torn_down (or pathsec_ic_torn_down) from the client, the server MAY signal pathsec_set_up_oc (or pathsec_set_up_ic) to lead the session into SetUp-OC (or SetUp-IC), and In-Session next. Salvaging a private-key-compromised Pathsec Session without sufficient justification (which is outside the Pathsec scope) is NOT RECOMMENDED. 6.2 Compromised Sub-session Key If a sub-session key is compromised, then an attacker may conduct man-in-the-middle activities in the channel involving the compromised hop. The scopes of damage due to compromised sub-session key range from per sub-session to per session. However, keep in mind that compromised sub-session key may only be symptomatic to compromised private key(s), compromised master secret, or compromised pre-master secret. 6.3 Compromised Master Secret Hui Expires: March 2002 [Page 35] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 If the master secret, originated from the client during client-server handshake, is compromised, then an attacker may derive Sub-session Key(s) shared by any two adjacent Pathsec nodes using the publicly available key derivation function (KDF). (The KDF takes the captured master secret and two random blocks separately generated by the client and the server during handshake as input parameters.) Because the randoms are always transmitted in plain text in TLS, they are fairgames to network snoopers. The scope of damage due to compromised master secret is per session. 6.4 Compromised Pre-Master-Secret If the pre-master secret, originated from the client during client- server handshake, is compromised, then an attacker may derive the master secret (and thus sub-session key(s)) using the publicly available key derivation function (KDF). (The KDF takes the captured pre-master secret and two random blocks separately generated by the client and the server during handshake as input parameters.) Because the randoms are always transmitted in plain text in TLS, they are fairgames to network snoopers. The scope of damage due to compromised pre-master secret is per session. 6.5 Ciphersuite Degradation Each intermediary of an Outbound Channel or an Inbound Channel SHOULD support at least one ciphersuite that is functionally equivalent to and is at least as strong as the one deployed in the Main Channel. Otherwise, the session is vulernable to downgrade attack. 6.6 Perils of Sharing Master Secret Across Channels The sharing of a master secret (or pre-master secret in a similar vein) across-channel SHOULD NOT be allowed. For instance, the master secret of the Main Channel or the Inbound Channel MUST NOT be shared with the Outbound Channel. Otherwise, outbound intermediaries, say language translaters or ad inserters, may derive the necessary sub- session key(s) to snoop inbound traffic, which may contain passwords that outbound intermediaries are not privy to. All nodes of a Pathsec session MUST know that both the server and the client know the common master secrets of all channels. 6.7 Intermediary Weakness Hui Expires: March 2002 [Page 36] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 The data in transit to and from the call-outs and value-added services fashioned by a Pathsec intermediary MUST be secured with a cryptosystem that is at least as strong as the weakest link in the Pathsec channel in question. Otherwise, the session is vulernable to downgrade attack. The server and the client must realize that they, individually or jointly, have little control over the activities conducted by trusted intermediaries. Thus frequent audit, or certification if applicable, of trust-worthiness is RECOMMENDED. Each intermediary MUST excercise continuous diligence and self- discipline in securing its own premises in various aspects. It is possible for "conspiring" intermediaries to modify a routing policy -- e.g. adding or removing hops from a routing metric, practically executing loose source routing instead of strict source routing without the end points' knowledge -- even if the routing metric has been MACed by the server or the client. Some intermediaries that are genuinely trustworthy may find this "feature" a "door" to creative applications, and Pathsec is safe with this "door" unlocked so long as the intermediaries are genuinely trustworthy, albeit occasionally mischievous for their own good. However, there remains the challenge to make this "door" lockable by the server or the client. 6.8 Remote Execute Semantics for remote execute are not intrinsic to the Pathsec protocol. For example, support for dereferencing a Pathsec node identified as "www.funcity.bom:443/trojanhorse" SHALL NOT be RECOMMENDED. Both the server and the client SHOULD assume that intermediaries are very likely to execute remote procudures at their own discretion. Intermediaries that execute remote procedures MUST adhere to the guidelines set in 6.7. 7 I18N & L10N Considerations The hopList of a Pathsec Routing Metric is encoded using UTF-8 [UTF8]. Internationalization (I18N) and localization (L10N) should be considered only if future domain names are to be specified in text strings. Hui Expires: March 2002 [Page 37] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 8 Intellectual Property Rights The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this document. Please address the information to the IETF Executive Director. 9 Acknowledgments The author wishes to thank in advance his Digital Island and Cable & Wireless Global colleagues, and the IETF TLS Working Group chair and members for their comments and supports that shall contribute to the advancement of the Pathsec protocol from its current stage. Hui Expires: March 2002 [Page 38] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 10 References [CDI] Content Distribution/Delivery Internetworking Working Group, IETF. [DENNING] D. E. Denning, "Cryptography and Data Security," Addison-Wesley, 1982. [HMAC] H. Krawczyk, M. Bellare, and R. Canetti -- HMAC: Keyed-hashing for message authentication. IETF RFC 2104, February 1997. [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," IETF RFC 2616, June 1999. [IP] ISI, "Internet Protocol, DARPA Internet Program, Protocol Specification," IETF RFC 791, September 1981. [KWORD] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," IETF RFC 2119, March 1997. [NICHOLS] R.K. Nichols, "ICSA Guide to Cryptography," McGraw Hill, 1999. [OPES] Open Pluggable Edge Services Working Group, IETF. [RESCORLA] E. Rescorla, "SSL and TLS, Designing and Building Secure Systems," Addison-Wesley, 2001. [STARTLS] P. Hoffman, "SMTP Service Extension for Secure SMTP over TLS,"IETF RFC 2487, January 1999. [STEVENS] W.R. Stevens, "TCP/IP Illustrated, Vol 1" Addison Wesley, 1994. [TLS1] T. Dierks, and C. Allen, "The TLS Protocol - Version 1.0," IETF RFC 2246, January 1999. [TLSX] S. Blake-Wilson, M. Nystrom, D. Hopwood, and J. Mikkelsen, "TLS Extensions, draft-ietf-tls-extensions-00.txt," IETF Internet Draft Work-in-progress, June 2001. [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1998. [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646," Hui Expires: March 2002 [Page 39] INTERNET-DRAFT TLS Pathsec Protocol September 28, 2001 IETF RFC 2279, January 1998. [WEBI] Web Intermediaries Working Group, IETF. [XDR] R. Srinivasan, "XDR: External Data Representation Standard," IETF RFC 1832, March 1995. [XMPR] D.L. Mills, "An Experimental Multiple-Path Routing Algorithm," IETF RFC 981, March 1986. 11 Author's Address Joseph Hui Digital Island a Cable & Wireless company 225 W. Hillcrest Drive Thousand Oaks, CA 91360 USA Phone: +1 805 370 2165 Email: jhui@digisle.net Hui Expires: March 2002 [Page 40]