idnits 2.17.1 draft-ietf-tls-pathsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 585 has weird spacing: '...rSecret sha...' == Line 586 has weird spacing: '...HopList serve...' == Line 587 has weird spacing: '...HopList clien...' == Line 588 has weird spacing: '...HopList inter...' == Line 1233 has weird spacing: '... opaque rando...' == (1 more instance...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: MC MUST not share its pre-master and master secrets with OC. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '32' on line 589 -- Looks like a reference, but probably isn't: '64' on line 591 -- Looks like a reference, but probably isn't: '24' on line 1233 -- Looks like a reference, but probably isn't: '20' on line 1243 == Unused Reference: 'DENNING' is defined on line 1664, but no explicit reference was found in the text == Unused Reference: 'HMAC' is defined on line 1667, but no explicit reference was found in the text == Unused Reference: 'NICHOLS' is defined on line 1681, but no explicit reference was found in the text == Unused Reference: 'RESCORLA' is defined on line 1686, but no explicit reference was found in the text == Unused Reference: 'STARTLS' is defined on line 1689, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CDI' -- Possible downref: Non-RFC (?) normative reference: ref. 'DENNING' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'NICHOLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPES' -- Possible downref: Non-RFC (?) normative reference: ref. 'RESCORLA' ** Obsolete normative reference: RFC 2487 (ref. 'STARTLS') (Obsoleted by RFC 3207) -- Possible downref: Non-RFC (?) normative reference: ref. 'STEVENS' ** Obsolete normative reference: RFC 2246 (ref. 'TLS1') (Obsoleted by RFC 4346) == Outdated reference: A later version (-06) exists of draft-ietf-tls-extensions-00 ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. 'WEBI' ** Obsolete normative reference: RFC 1832 (ref. 'XDR') (Obsoleted by RFC 4506) ** Downref: Normative reference to an Unknown state RFC: RFC 981 (ref. 'XMPR') Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group TLS Pathsec Protocol Joseph Hui 3 INTERNET-DRAFT Digital Island 4 Expires March, 2002 September, 2001 5 Intended Category: Standards track 7 TLS Pathsec Protocol 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 31 Abstract 33 The TLS Pathsec Protocol (or Pathsec Protocol in short) extends the 34 TLS protocol into securing data in transit not only between two end 35 points, but also between the intermediaries en route, based on TLS 36 1.0 with appropriate extensions that include injecting source routing 37 policies above the Transport layer. 39 A typical Pathsec session comprises several sub-sessions, each of 40 which is a TLS session with Pathsec extended semantics. It involves a 41 client, a server, one or more intermediaries, and three individually 42 secured channels for data and signal transports. 44 Integral to the Pathsec protocol are audit and opt-out features. The 45 client or the server may selectively monitor the fidelity of the data 46 arriving at the destination after (the data) having undergone 47 purposed transformations performed by authorized and authenticated 48 intermediaries designated in a routing metric; and if either end 49 point finds the data exceedingly distorted, it may opt out 50 gracefully. 52 Table of Contents 54 1 Introduction .......................................... 4 55 1.1 Venue of Discourse .................................... 5 56 2 Terminology ........................................... 6 57 2.1 Key Word Convention ................................... 8 58 2.2 Data Type Convention .................................. 8 59 3 Pathsec Session ....................................... 9 60 3.1 Pathsec Main Channel ................................. 12 61 3.2 Pathsec Outbound Channel ............................. 12 62 3.3 Pathsec Inbound Channel .............................. 14 63 3.4 Pathsec Routing Metrics .............................. 14 64 3.4.1 Pathsec Strict Source (and Record) Routing ........... 17 65 3.4.2 Pathsec Loose Source (and Record) Routing ............ 18 66 3.5 Pathsec Extended TLS ClientHello/ServerHello ......... 21 67 3.6 Pathsec Extended TLS Alert ........................... 21 68 3.6.1 Pathsec Signals ...................................... 23 69 3.7 Pathsec Set-up ....................................... 30 70 3.8. Pathsec In-session ................................... 31 71 3.8.1 Pathsec Verify ....................................... 31 72 3.8.2 Pathsec Audit ........................................ 32 73 3.8.3 Pathsec Opt-out ...................................... 33 74 3.9 Pathsec Tear-down .................................... 33 75 3.10 Pathsec Close ........................................ 33 76 3.11 Pathsec Re-open ...................................... 33 77 4 Pathsec Extensions to TLS ............................ 34 78 5 Application Considerations ........................... 34 79 6 Security Considerations .............................. 34 80 6.1 Compromised Private Key .............................. 35 81 6.2 Compromised Sub-session Key .......................... 35 82 6.3 Compromised Master Secret ............................ 35 83 6.4 Compromised Pre-Master Secret ........................ 36 84 6.5 Ciphersuite Degradation .............................. 36 85 6.6 Perils of Sharing Master Secret Across Channels ...... 36 86 6.7 Intermediary Weakness ................................ 36 87 6.8 Remote Execute ....................................... 37 88 7 Internationalization Considerations .................. 37 89 8 Intellectual Property Rights ......................... 38 90 9 Acknowledgments ...................................... 38 91 10 References ........................................... 39 92 11 Author's Address ..................................... 40 94 1 Introduction 96 This document describes the TLS Pathsec Protocol (or Pathsec Protocol 97 in short) which extends the TLS protocol into securing data in 98 transit not only between two end points, but also between the 99 intermediaries en route. 101 Based on TLS 1.0 [TLS1] with extensions defined in [TLSX] and 102 inspired by IP source routing [IP,STEVENS,XMPR], Pathsec in general 103 emulates the well established end-to-end model, with augmentation for 104 injecting routing policy necessary for traversing designated 105 intermediaries where data may undergo authorized transformation. 106 Thus Pathsec, with security and robustness being the paramount goals, 107 embeds no more intelligence than what is necessary for securing the 108 payloads entrusted by both the client and its server during a secured 109 session. For example. In a Pathsec session, Pathsec uses routing 110 metrics for specifying the hops between end points and the orders of 111 traversal; but the construction of the metrics, such as by 112 provisioning or by discovery, is outside the scope of Pathsec. 114 Pathsec is designed to be well suited for the request-response 115 computing model where a client, a server, and zero or more 116 intermediaries dot a linear processing path. Finite loops in a 117 processing path are permissible, as they can be unfolded to form a 118 linear pattern in Pathsec Routing Metrics. 120 A typical Pathsec session comprises several sub-sessions, of which 121 each is a TLS session with Pathsec extended semantics. It involves a 122 client, a server, one or more intermediaries, and three individually 123 secured channels for data and signal transports. The server and all 124 intermediaries are individually authenticated according to the TLS 125 protocol. 127 Integral to the Pathsec protocol is an audit feature that allows the 128 client or the server to selectively verify the fidelity of the data 129 arriving at the destination. The feature is based on a "trust-but- 130 verify" principle, for monitoring whether the extent of data 131 distortion, which is the direct result of well-intended 132 transformations performed by authorized and authenticated 133 intermediaries designated in a routing metric, is within the limits 134 of tolerance. 136 Also integral to the Pathsec protocol is an opt-out feature that 137 allows the client or the server, during a session, at unilateral 138 discretion, gracefully, to opt out of Pathsec mode and switch into 139 the conventional TLS mode, or to opt out of the session entirely, 140 i.e. to abort the session in progress. 142 Not unlike TLS or any cryptosystem, a Pathsec session is susceptible 143 to catastrophic failure in the face of attacks aided by, for 144 instance, compromised session key, compromised private key, 145 compromised master secret, compromised pre-master secret, or security 146 negligence. 148 As a Pathsec session involves more hops than a conventional TLS 149 session does, it inevitably presents a larger target for attackers, 150 even though all hops are meant to be equally securable by design; 151 thus, it is imperative that Pathsec practitioners (in implementation 152 and in deployment) abide by the specification in strictest adherence. 154 It is conceivable that Pathsec may, with reference to the end-to-end 155 model, evolve into covering virtual end points, which may be 156 surrogates or proxies of origin servers or user agents, in a secured 157 content processing context. 159 To the TLS protocol semantics, Pathsec adds a "pathsec_signal(120)" 160 TLS alert, a "notification" alert level, an optional "extension" 161 element to the Alert struct (for piggy-backing supplemental data for 162 alert processing), and a pathsec_rm(6) extension to ClientHello and 163 to ServerHello (for facilitating Pathsec source routing). 165 IANA may be requested to assign a default port for Pathsec 166 Intermediaries. 168 1.1. Venue of Discourse 170 Please send comments on this document to the IETF TLF working group's 171 mailing list, at the writing of this document: 173 ietf-tls@lists.certicom.com , 175 or directly to the author if the sender prefers: 177 jhui@digisle.net . 179 2 Terminology 181 data fidelity 182 The quality of data arriving at the destination of a content 183 delivery path, measurable either quantitatively or qualitatively 184 against the data at the source of the same content delivery path, 185 for determining the extent of distortion. 187 data integrity 188 The quality of data arriving intact at the destination of a 189 content delivery path. That is. if measured in terms of data 190 fidelity, absolute data integrity means zero distortion. Message 191 Digests are usually used for verifying data integrity. 193 inbound/outbound 194 Inbound and outbound refer to the request and response paths for 195 messages: "inbound" means "traveling toward the origin server," 196 and "outbound" means "traveling toward the user agent." [HTTP] 198 In Pathsec, "inbound" means "traveling toward the Pathsec server, 199 which may be an origin server or its surrogate/proxy," and 200 "outbound" means "traveling toward the Pathsec client, which may 201 not necessarily be a user agent." 203 (Pathsec) Channels 204 There are three duplex communication channels in a Pathsec 205 Session: 1) the Main Channel; 2) the Outbound Channel; and 3) the 206 Inbound Channel. Ref: Figure 1. 207 *** Forward Compatibility Note: 208 *** Pathsec may in the future support multiple Outbound Channels. 210 (Pathsec) Client 211 An end point in a Pathsec session. A Pathsec client is usually a 212 user agent, but may also be some other application entity, such as 213 a caching proxy in a content delivery network. 215 (Pathsec) Hop 216 The direct path between two (Pathsec) nodes. 218 (Pathsec) Inbound Channel (IC) An inbound [HTTP] data channel from 219 the client to the server, with one or more intermediaries en 220 route. The hop connecting any two adjacent nodes is secured by a 221 Pathsec Sub-session, in the form of a TLS session. Thus, an 222 Inbound Channel is a chain of Pathsec Sub-sessions, starting at 223 the client and ending at the server. 225 (Pathsec) Inbound Intermediary (II) 226 An intermediary in an Inbound Channel, identifiable in an Inbound 227 Routing Metric. The numbering of Inbound Intermediaries always 228 starts from the client. For example, the first II immediately 229 next to the client is II1. 231 (Pathsec) Inbound Routing Metric (IRM) 232 An Inbound Routing Metric designates the hops from the client to 233 the server, using a strict/loose source routing policy. 235 (Pathsec) Main Channel (MC) 236 A Pathsec Sub-session, in the form of a TLS session, between the 237 client and the server, with no intermediaries involved. 239 (Pathsec) Node 240 A Pathsec client, server, or intermediary. 242 (Pathsec) Outbound Channel (OC) 243 An outbound [HTTP] data channel from the server to the client, 244 with one or more intermediaries en route. The hop connecting any 245 two adjacent hops is secured by a Pathsec Sub-session, in the form 246 of a TLS session. Thus, an Outbound Channel is a chain of Pathsec 247 Sub-sessions, starting at the server and ending at the client. 249 (Pathsec) Outbound Intermediary (OI) 250 An intermediary in an Outbound Channel, identifiable in an 251 Outbound Routing Metric. The numbering of Outbound Intermediaries 252 always starts from the client. For example, the first OI 253 immediately next to the client is OI1. 255 (Pathsec) Outbound Routing Metric (ORM) 256 An Outbound Routing Metric designates the hops from the server to 257 the client, using a strict/loose source routing policy. 259 (Pathsec) Routing Metrics 260 There are two types of Pathsec Routing Metrics: 1) Outbound 261 Routing Metrics; and 2) Inbound Routing Metrics. 263 (Pathsec) Server 264 An end point in a Pathsec Session. A Pathsec server is usually an 265 origin server but may also be some other application entity, such 266 as an origin server's surrogate (or proxy). 268 (Pathsec) Signal 269 A Pathsec Signal is issued by a client, a server, or an 270 intermediary in the form of a TLS alert. A Pathsec signal may be 271 accompanied by supplemental message(s), synchronously. 273 (Pathsec) Session and Sub-session 274 A Pathsec Session is comprised of one or more Pathsec Sub- 275 sessions, of which each is secured in the form of a TLS session 276 between two adjacent Pathsec nodes. 278 (Pathsec) Sub-session Key 279 The TLS session key set for a Pathsec Sub-session, shared by two 280 connecting Pathsec nodes. 282 relay 283 An intermediary that relays data or signal between client and 284 server. 286 upstream/downstream 287 Upstream and downstream describe the flow of a message: all 288 messages flow from upstream to downstream. [HTTP] 290 virtual end point 291 A virtual end point -- with reference to the end-to-end y -- is a 292 surrogate (or proxy) of a server or client. It is a terminal in a 293 processing path (that involves a client, a server, and zero or 294 more intermediaries). 296 2.1 Key Word Conventions 298 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 299 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 300 document are to be interpreted as described in RFC-2119 [KWORD]. 302 2.2 Data Type Conventions 304 All data types specified in this document are to be interpreted as 305 described in RFC-1832 [XDR] and RFC-2246 [TLS1]. 307 3 Pathsec Session 309 +-----------------------------------------------------------------+ 310 | Client (C) | 311 | if (verify(R,R'') > limit_of_tolerence) opt_out(); | 312 +-----------------------------------------------------------------+ 313 | ^ | ^ ^ | | ^ 314 | | | | | | |Q 8| 315 | | | | | | 3| |R'' 316 | | | | | | v | 317 | | | | | | +----------------+ +----------------+ 318 | | | | | | | Inbound | | Outbound | 319 | | | | | | | Intermediary 1 | | Intermediary 1 | 320 1| | | | | | | (II1) | | (OI1) | 321 | | | | | |12 +----------------+ +----------------+ 322 | |2 | | | | | ^ 323 | | | | | |R'' |Q' 7| 324 | | | | | | 4| |R' 325 | | | | 11| | v | 326 | | | | | | +----------------+ +----------------+ 327 | | | | A| | | Inbound | | Outbound | 328 | | | | | | | Intermediary 2 | | Intermediary 2 | 329 | | | |10 | | | (II2) | | (OI2) | 330 | | 9| | | | +----------------+ +----------------+ 331 | | | |R | | | ^ 332 | | V| | | | |Q'' 6| 333 | | | | | | 5| |R 334 v | v | | v v | 335 +-----------------------------------------------------------------+ 336 | Server (S) | 337 | if (audit(R,R'') > limit_of_tolerence) opt_out(); | 338 +-----------------------------------------------------------------+ 340 KEYS: 341 A -- Request (from server to client) to audit responses -- R vs. R''. 342 Q -- Original request/query from client. 343 Q' -- Result of transforming Q by Inbound Intermediary 1 (II1). 344 Q'' -- Result of transforming Q' by Inbound Intermediary 2 (II1). 345 R -- Original response from server. 346 R' -- Result of transforming R by Outbound Intermediary 2 (OI2). 347 R'' -- Result of transforming R' by Outbound Intermediary 1 (OI1). 348 V -- Request (from client to server) to verify responses -- R vs. R''. 349 Pathsec Main Channel encompasses paths: 1, 2, 9, 10, 11, and 12. 350 Pathsec Inbound Channel encompasses paths: 3, 4, and 5. 351 Pathsec Outbound Channel encompasses paths: 6, 7, and 8. 353 Figure 1: Pathsec Session Conceptual/Data Flow Diagram 355 +--------------+ 356 | | 357 | Open/Re-Open | 358 | | +--------+ 359 +--------------+ 16 | | 360 | /----------------------------->| Close! | 361 1| | | | 362 v | +--------+ 363 +----------+ | +-------------+ ^ 364 | | | | | | 365 | SetUp-MC |--------/ | TearDown-OC | | 366 | | | | | 367 +----------+ +-------------+ | 368 | | ^ | 369 2| 13| |12 | 370 v v | | 371 +----------+ 10 +-------------------------+ | 372 | |<------| | | 373 | SetUp-OC | | In-Session | |6 374 | |------>| |-----\ | 375 +----------+ 11 +-------------------------+ | | 376 | | | ^ | ^ | | 377 | | | | 14| |15 | | 378 | | | |4 v | | | 379 | | | | +-------------+ | | 380 | 3| 9| | | | |5 | 381 | | | | | TearDown-IC | | | 382 7| v | | | | | | 383 | +----------+ | | +-------------+ | | 384 | | |<-----/ | v | 385 | | SetUp-IC |--------/ 8 +--------------+ 386 | | |------------------------------>| | 387 | +----------+ | TearDown-All | 388 \------------------------------------------->| | 389 7 +--------------+ 390 KEYS: 391 Label Alert/Signal Label Alert/Signal 392 1 -- pathsec_set_up_mc*, or nill 10 -- pathsec_set_up_oc* 393 2 -- pathsec_set_up_oc* 11 -- pathsec_oc_set_up* 394 3 -- pathsec_set_up_ic* 12 -- pathsec_tear_down_oc* 395 4 -- pathsec_ic_set_up* 13 -- pathsec_oc_torn_down* 396 5 -- pathsec_tear_down_all* 14 -- pathsec_tear_down_ic* 397 6 -- close_notify#, or nill 15 -- pathsec_ic_torn_down* 398 7 -- pathsec_tear_down_all* 16 -- close_notify#, or nill 399 8 -- pathsec_tear_down_all* 400 9 -- pathsec_set_up_ic* # Existing TLS Alert * Pathsec Signal 401 ! Terminal State 402 Figure 2: Pathsec State Machine 404 Frequent referals to Figures 1 and 2 are deemed helpful for the 405 discussions throughout the document. 407 A Pathsec Session comprises one or more Pathsec Sub-session. A 408 Pathsec Sub-session, secured in the same manner as a conventional TLS 409 session with Pathsec-extended semantics, is held between two adjacent 410 nodes along a Pathsec Channel. 412 Architecturally, a Pathsec Session is conducted over three secured 413 communication channels: the Main Channel; the Outbound Channel; and 414 the Inbound Channel. The channels are constructed during a Pathsec 415 Set-up, which occurs at the start of the session, or in the middle of 416 the session at the cue of Pathsec signals. The Main Channel connects 417 the server and the client directly. The Outbound Channel carries 418 outbound data from the server to the client through one or more 419 intermediaries. Conversely, the Inbound Channel carries inbound data 420 from the client to the server through one or more intermediaries. 421 The existence of the Main Channel is mandatory. The Outbound and 422 Inbound channels are optional. In the absense of the Outbound 423 Channel, the Main Channel takes over its functionality in the secured 424 delivery of outbound data, e.g. server responses. In the absense of 425 the Inbound Channel, the Main Channel takes over its functionality in 426 the secured delivery of inbound data, e.g. client requests. In the 427 absense of both Outbound and Inbound Channels, the Pathsec session is 428 operating in TLS mode, i.e. just like a conventional TLS session, 429 with the exception that a Pathsec signal -- pathsec_set_up_oc or 430 pathsec_set_up_ic -- may switch the session into Pathsec mode. 432 Pathsec signals are carried individually in a Pathsec extended TLS 433 alert: pathsec_signal. 435 A Pathsec Session is always started by the client (at the Open/Re- 436 open state in the Pathsec State Machine. [Ref:Fig 2]). 438 A Pathsec Session is set up by the construction of the Main, 439 Outbound, and Inbound Channels, undergoing a series of state 440 transitions: SetUp-MC -> SetUp-OC -> SetUp-IC -> In-Session. [Ref:Fig 441 2] 443 While Pathsec is In-Session, either the client or the server MAY 444 signal its counterpart to tear down the OC or the IC, or to set up 445 the OC or the IC if none exists. In addition, Audit or Verify 446 signals MAY also be sent by the server or the client, respectively. 447 [Ref:3.8.1,3.8.2] 449 The closure of a Pathsec Session, either by natural ending or by 450 opt-out, is preceded by a TearDown-All process, which MUST 451 sequentially close down the Inbound Channel, the Outbound Channel, 452 and the Main Channel. [Ref:3.9,3.10] 454 A closed Pathsec Session MAY be re-opened in manner similar to 455 resuming a TLS session. [Ref:3.11] 457 3.1 Pathsec Main Channel 459 The Main Channel (MC) is defined by a Pathsec sub-session in the form 460 of a TLS session between the client and the server. 462 There MUST NOT be any intermediary in MC. 464 As a part of Pathsec Set-up, the construction of MC starts from the 465 client, in the same manner as starting a TLS handshake, whose 466 successful conclusion marks the establishment of MC, which MAY be 467 optionally milestoned by the server issuing to itself and to the 468 client a pathsec_mc_set_up signal. 470 All TLS alerts, including Pathsec signals, may travel bi- 471 directionally in MC. 473 In the absence of OC, outbound data, such as application server 474 responses, travel in MC. 476 In the absence of IC, inbound data, such as application client 477 requests, travel in MC. 479 The server's responses to a client's request to verify data fidelity 480 travel in MC. 482 The client's responses to a server's request to audit (data fidelity 483 e.g.) travel in MC. 485 A fatal alert affecting MC SHALL always result in the closure of the 486 entire Pathsec Session. 488 MC MUST not share its pre-master and master secrets with OC. 490 MC SHOULD NOT share its pre-master and master secrets with IC. 492 3.2 Pathsec Outbound Channel 494 The Outbound Channel (OC) is defined by a chain of Pathsec sub- 495 sessions in the form of hop-by-hop TLS sessions between the client 496 and the server, inclusively. 498 There SHOULD be one or more intermediaries in OC. There MAY also be 499 zero intermediary in OC, i.e. a single-hop OC where the client also 500 plays the role of OI1 and OIn. (OI1 is the intermediary that is next 501 to the client in OC. OIn is the intermediary that is next to the 502 server in OC.) The number of intermediaries is limited only by the 503 size of the hopList element in the PathsecRoutingMetric data 504 structure. [Ref:3.4] 506 Note that when speaking of source routing in Pathsec, the client is 507 always the source, where the channel construction (of hops eventually 508 linking to the server) starts, irrespective of the channel being OC 509 or IC. Once the channel has been set up, the concept of routing 510 ceases to exist in a Pathsec node, which cares only to read from 511 upstream and write to downstream. 513 The number and the sequence of hops, as well as other route 514 properties, are defined in an ORM. The client and the intermediaries 515 MAY or MAY NOT modify certain aspects of the ORM, dependent upon the 516 ORM properties specified by the server and the client. 518 The ORM is carried outbound (via MC) in a TLS ServerHello pathsec_rm 519 extension, or inbound (via OC) in a TLS ClientHello pathsec_rm 520 extension, or in pathsec_signal_data accompanying a pathsec_set_up_oc 521 signal (via MC). [Ref:3.4,3.6.1,TLSX] 523 All TLS alerts, including Pathsec signals, may travel in OC, in any 524 direction. 526 Outbound application data, such as application server responses, 527 travel in OC. 529 The construction of OC is hop-by-hop, with the first hop starting 530 from the client to OI1. During the client-OI1 TLS handshake, the ORM 531 is passed from the client to OI1. Upon completion of the first hop, 532 OI1 connects to the next intermediary, if any, designated in ORM, and 533 iterates the Pathsec-augmented TLS handshake with OI2, passing along 534 the ORM. The iteration ends at the last hop with the server as the 535 terminus. 537 The ShareMasterSecret property in ORM indicates if master secret is 538 shared. 540 If all nodes in OC are to share a common master secret, then the 541 client is responsible for propagating a fixed set of keying material 542 -- pre-master secret, client random, and server random towards the 543 server. All nodes belonging to the channel are to use such set of 544 keying material for sub-session key generation. 546 If the nodes in OC do not share a common master secret, then each 547 sub-session in OC holds its own keying secrets. 549 OC SHOULD NOT share its pre-master and master secrets with IC. 551 Prior to transporting application data in OC, the server MUST first 552 audit the channel, by sending the client via MC a pathsec_ping signal 553 that designates OC as the echo channel. The client MUST reply with a 554 pathsec_echo via OC. By comparing the PathsecPing and PathsecEcho 555 supplemental data accompanying the signals, the server is able to 556 authenticate the channel. Upon positive authentication, the server 557 sends the client a pathsec_echo_ok signal; otherwise, a fatal TLS 558 alert is raised. [Ref:3.6.1] 560 3.3 Pathsec Inbound Channel 562 The Outbound Channel semantics apply equally to the Inbound Channel. 563 (That is, 3.3 is an almost-identical twin of 3.2, substituting: 564 inbound for outbound; IC for OC; IRM for ORM; II1, II2, IIn for OI1, 565 OI2, OIn, respectively; "client requests" for "server responses;" and 566 pathsec_set_up_ic for pathsec_set_up_oc.) 568 Whereas OC SHOULD NOT share its pre-master and master secrets with 569 IC, IC MUST NOT share its pre-master and master secrets with OC. 571 3.4 Pathsec Routing Metrics 573 There are two types of Pathsec Routing Metrics (RMs): 1) Outbound 574 Routing Metrics (ORM), for routing application data from the server 575 to the client; and 2) Inbound Routing Metrics (IRM), for routing 576 application data from the client to the server. All Pathsec Routing 577 Metrics share an identical format and have same semantics, as in the 578 following: 580 struct { 581 RoutingPolicy routingPolicy; 582 RouteLength routeLength; 583 RoutePointer routePointer; 584 RouteDirection routeDirection; 585 ShareMasterSecret shareMasterSecret; 586 ServerMayModHopList serverMayModHopList; 587 ClientMayModHopList clientMayModHopList; 588 IntermMayModHopList intermMayModHopList; 589 opaque serverRandom[32]; /* also serves as 590 * channel ticket */ 591 opaque pathsecReserved[64]; 592 opaque hopList<1..2^14> 593 } PathsecRoutingMetric; 595 enum { 596 loose_source_routing(0x83), /* 0x83 & 0x89 are from IP */ 597 strict_source_routing(0x89) /* default */ 598 } RoutingPolicy; 600 typedef uint8 RouteLength; 602 typedef unit8 RoutePointer; 604 enum { 605 outbound(1), 606 inbound(2) 607 } RouteDirection; /* no default */ 609 enum { 610 dont_share_master_secret(0), 611 share_master_secret(1) /* default */ 612 } ShareMasterSecret; 614 enum { 615 server_may_not_modify_hop_list(0), 616 server_may_modify_hop_list(1) /* default */ 617 } ServerMayModRM; 619 enum { 620 client_may_not_modify_hop_list(0), 621 client_may_modify_hop_list(1) /* default */ 622 } ClientMayModRM; 624 enum { 625 interm_may_not_modify_hop_list(0), /* default */ 626 interm_may_modify_hop_list(1) 627 } IntermMayModRM; 629 hopList := hops 630 hops := hostport [ , hops ] 631 hostport := host [ : port ] 632 host := hostname | hostnumber 633 hostname := ialpha [ . hostname ] 634 hostnumber := digits . digits . digits . digits 635 port := digits 637 (Refer to [URI] for ialpha and digits.) 639 Pathsec server and intermediaries share with TLS the same default 640 port: 443. 641 *** Forward Compatibility Note: 642 *** IANA may be requested to assign a new default port for 643 *** Pathsec Intermediaries. 645 An examples of (comma-delimited) hopList: 647 "I1.x.com,I2.y.com:4567,server.z.com:7890" is a three-hop list 648 such that in an ORM, application data flow in the way of: 650 server.z.com:7890 -> I2.y.com:4567 -> I1.x.com -> client 652 and in an IRM, application data flow in the way of: 654 client -> I1.x.com -> I2.y.com:4567 -> server.z.com:7890 656 A Routing Metric (RM) may be carried in a pathsec_rm extension in a 657 ServerHello or a ClientHello. It may also be carried in the 658 pathsec_signal_data accompanying a pathsec_set_up_oc or 659 pathsec_set_up_ic signal, which is delivered in a TLS alert typed 660 pathsec_signal. 662 Either the server or the client MAY be the RM originator, whose 663 wishes (as specified in routingPolicy, routeDirection, 664 shareMasterSecret, serverMayModHopList, clientMayModHopList, 665 intermMayModHopList, and hopList) must be respected by all nodes in a 666 channel, with the following exceptions. The server MAY negotiate 667 loose_source_routing to strict_source_routing; the server MAY 668 negotiate server_may_not_modify_hop_list to 669 server_may_modify_hop_list; the server MAY negotiate the server MAY 670 negotiate interm_may_modify_hop_list to 671 interm_may_not_modify_hop_list; or the server MAY negotiate 672 share_master_secret to dont_share_master_secret. The client MUST NOT 673 perterb the "server-side" hops specified by the server, though it MAY 674 prepend "client-side" hops to hopList. The server SHOULD NOT perterb 675 the "client-side" hops specified by the client, though it MAY append 676 "server-side" hops to them. 678 RoutingPolicy is for the originator of an RM, usually the server but 679 sometimes the client, to specify the routing policy governing a 680 Pathsec channel: loose source routing, or strict source routing (the 681 default). RoutingPolicy, once set, SHOULD NOT be changed. All nodes 682 MUST execute the routing policy in the exact manner as described in 683 [3.4.1] and [3.4.2]. (Also refer to [IP,STEVENS] for the workings of 684 IP source routing.) 686 RouteLength specifies the number of hops in hopList, e.g. 3 for 687 three hops. 689 RoutePointer points at the destination node of the current hop. 690 RoutePointer increments by 1 per hop. 692 RouteDirection indicates if the route is for inbound or outbound 693 application data. For example, if routeDirection = outbound, then 694 the RM is for OC, i.e. ORM. 696 ShareMasterSecret indicates if all nodes belonging to the channel 697 that employs the RM are to share a common master secret for keying 698 purpose. 700 ServerMayModHopList indicates if the server may modify hopList. 702 ClientMayModHopList indicates if the client may modify hopList. 704 IntermMayModHopList indicates if the intermediaries may modify 705 hopList. 707 ServerRandom contains the server random for keying purpose, in case 708 of share_master_secret. 710 ServerRandom also serves as the channel ticket, by which the server, 711 which may face multiple connection requests, determines which channel 712 a connecting party belongs to during a TLS handshake. 714 PathsecReserved is a dummy at the writing of this document. 716 HopList contains the list nodes en route, in format defined above. 717 The first node is always II1 or OI1, and the last node is always the 718 server, because the construction of IC or OC always starts from the 719 client. All nodes in a channel must observe the rules set in: 720 serverMayModHopList, clientMayModHopList, and intermMayModHopList, 721 with few forementioned server exceptions. 723 3.4.1 Pathsec Strict Source (and Record) Routing 725 In Pathsec strict source (and record) routing (PSSRR), the client of 726 a Pathsec channel to be constructed is first given an RM, i.e. 727 PathsecRoutingMetric, either through a ServerHello pathsec_rm 728 extension or in the pathsec_signal_data accompanying a 729 pathsec_set_up_ic/pathsec_set_up_oc signal, where routingPolicy is 730 set to strict_source_routing. The RM is to be forwarded inbound 731 through a ClientHello pathsec_rm extension during the TLS handshakes 732 that will establish the sub-sessions in the channel. 734 Before forwarding the RM in a ClientHello, a Pathsec node MUST 735 increment routePointer by 1. 737 Each node (in the channel) uses routePointer as the locator for 738 determining its TLS server (in a Pathsec sub-session) to connect to, 739 only if routePointer is not greater than routeLength. For example, 740 if routePointer is 2, then the second node in hopList is the TLS 741 server of the sub-session to be established. If routePointer is 742 greater the routeLength, then the end of the route has been reached. 743 (Note that routePointer pointing at the Pathsec server does not 744 necessarily indicate the end of the route.) 746 An intermediary MUST be aware that if routeLength equals routePointer 747 in the RM given, then it is the last intermediary in the channel, 748 e.g. OIn, or IIn, and may be called upon to perform a special task 749 (such as flipping an authentication string) in channel authentication 750 later. [Ref:3.6.1-pathsec_echo] 752 Figure 3 illustrates the algorithm of Pathsec strict source (and 753 record) routing by example. 755 The recording of the route is done by leaving hopList alone and 756 incrementing routePointer properly in each hop. 758 3.4.2 Pathsec Loose Source (and Record) Routing 760 Pathsec loose source (and record) routing (PLSRR) works in similar 761 ways as PSSRR does, with the crucial exception that the client or an 762 intermediary may, if permitted by the client_may_modify_hop_list or 763 interm_may_modify_hop_list respectively, properties in the RM, insert 764 hops between the Pathsec server and itself. (The routingPolicy in 765 the RM MUST be pre-set to loose_source_routing prior to channel 766 construction.) 768 Figure 4 illustrates the algorithm of Pathsec loose source (and 769 record) routing by example. 771 The recording of the route is done by properly updating hopList and 772 routeCount, and incrementing routePointer in each hop. 774 +-------+ 775 | C | 776 +-------+ routeLength = 3 777 | routePointer = 1 * 778 | hopList = {I1,I2,S} 779 | Pathsec sub-session TLS client = C 780 | Pathsec sub-session TLS server = I1 781 v 782 +-------+ 783 | I1 | 784 +-------+ routeLength = 3 785 | routePointer = 2 * 786 | hopList = {I1,I2,S} 787 | Pathsec sub-session TLS client = I1 788 | Pathsec sub-session TLS server = I2 789 v 790 +-------+ 791 | I2 | 792 +-------+ routeLength = 3 793 | routePointer = 3 * 794 | hopList = {I1,I2,S} 795 | Pathsec sub-session TLS client = I2 796 | Pathsec sub-session TLS server = S 797 v 798 +-------+ 799 | S | 800 +-------+ routeLength = 3 801 routePointer = 4 802 hopList = {I1,I2,S} 804 The hopList given to Pathsec client C is {I1,I2,S} where S is the 805 Pathsec server; I1 and I2 are intermediaries; routeLength is 3; 806 and routePointer is initially 1. 808 Figure 3: Pathsec Strict Source (and Record) Routing 809 +-------+ 810 | C | 811 +-------+ routeLength = 3 812 | routePointer = 1 * 813 | hopList = {I1,I2,S} 814 | Pathsec sub-session TLS client = C 815 v Pathsec sub-session TLS server = I1 816 +-------+ 817 | I1 | 818 +-------+ routeLength = 3 819 | routePointer = 2 820 | hopList = {I1,I2,S} 821 | I1 inserts I1a and I1b into hopList, then 822 | routeLength = 5 823 | routePointer = 2 * 824 | hopList = {I1,I1a,I1b,I2,S} 825 | Pathsec sub-session TLS client = I1 826 v Pathsec sub-session TLS server = I1a 827 +-------+ 828 | I1a | routeLength = 5 829 +-------+ routePointer = 3 * 830 | hopList = {I1,I1a,I1b,I2,S} 831 | Pathsec sub-session TLS client = I1a 832 v Pathsec sub-session TLS server = I1b 833 +-------+ 834 | I1b | routeLength = 5 835 +-------+ routePointer = 4 * 836 | hopList = {I1,I1a,I1b,I2,S} 837 | Pathsec sub-session TLS client = I1b 838 v Pathsec sub-session TLS server = I2 839 +-------+ 840 | I2 | routeLength = 5 841 +-------+ routePointer = 5 * 842 | hopList = {I1,I1a,I1b,I2,S} 843 | Pathsec sub-session TLS client = I2 844 v Pathsec sub-session TLS server = S 845 +-------+ 846 | S | routeLength = 5 847 +-------+ routePointer = 6 848 hopList = {I1,I1a,I1b,I2,S} 850 The hopList given to Pathsec client C is {I1,I2,S} where 851 S is the Pathsec server; I1 and I2 are intermediaries; 852 I1a and I1b are intermediaries inserted by I1; 853 routeLength is initially 3, and is changed to 5 by I1; 854 and routePointer is initially 1. 856 Figure 4: Pathsec Loose Source (and Record) Routing 858 3.5 Pathsec Extended TLS ClientHello/ServerHello 860 Pathsec adds "pathsec_rm" to the existing TLS extensions defined in 861 [TLSX]. It is to be included in ServerHello or ClientHello as 862 applicable. [Ref:3.4] 864 The following list enumerates the TLS extension types defined in 865 [TLSX] at the writing of this document, plus pathsec_rm: 867 enum { 868 dns_name(0), 869 max_record_size(1), 870 client_certificate_url(2), 871 trusted_ca_keys(3), 872 truncated_hmac(4), 873 status_request(5), 874 pathsec_rm(6), /* new for Pathsec */ 875 (65535) 876 } ExtensionType; 878 Origin servers, surrogates, proxies, and user agents that do not 879 understand the pathsec_rm extension SHOULD simply ignore the 880 extension. 882 3.6 Pathsec Extended TLS Alert 884 The Pathsec Protocol extends the TLS Alerts data structure (defined 885 in [TLS1]) to include an optional element: "extension." Pathsec also 886 introduces a new alert level: "notification;" and a new alert type: 887 "pathsec_signal." The notification level is for accommodating alerts 888 that are difficult to precisely characterize as warning or fatal. The 889 recipient MUST NOT ignore the alert, unless it does not support the 890 alert type specified in the description field. The optional 891 Alerts.extension is for piggy-backing supplemental data for alert 892 processing. The sender and recipient(s) MUST cast the opaque 893 Alerts.extension data into alert-type-specific data structure(s) for 894 further processing. In the case of Pathsec, the extension data is 895 cast into the PathsecAlert data structure defined in 3.6.1. 897 *** Author's Note: 898 *** [TLS1] did not script a forward compatibility note for alert 899 *** extensions; so backward compatibility issues related to an 900 *** extended TLS Alert struct are open at the writing of this 901 *** document. 903 Origin servers, surrogates, proxies, and user agents that do not 904 support pathsec_signal SHOULD raise an unexpected_message alert to 905 the pathsec_signal sender. 907 The following describes the Pathsec extended TLS Alert data structure 908 and enumerates TLS alerts, including pathsec_signal, which is an 909 addition to the TLS alerts having been compiled in [TLSX], at the 910 writing of this document: 912 struct { 913 AlertLevel level; 914 AlertDescription description; 915 opaque extension<0..2^16-1>; /* new for Pathsec */ 916 } Alert; 918 enum { 919 warning(1), 920 fatal(2), 921 notification(3), /* new for Pathsec */ 922 (255) 923 } AlertLevel; 925 enum { 926 close_notify(0), 927 unexpected_message(10), 928 bad_record_mac(20), 929 decryption_failed(21), 930 record_overflow(22), 931 decompression_failure(30), 932 handshake_failure(40), 933 certificate_unobtainable(41), /* new for TLSX */ 934 bad_certificate(42), 935 unsupported_certificate(43), 936 certificate_revoked(44), 937 certificate_expired(45), 938 certificate_unknown(46), 939 illegal_parameter(47), 940 unknown_ca(48), 941 access_denied(49), 942 decode_error(50), 943 decrypt_error(51), 944 export_restriction(60), 945 protocol_version(70), 946 insufficient_security(71), 947 internal_error(80), 948 user_canceled(90), 949 no_renegotiation(100), 950 unsupported_extension(110), /* new for TLSX */ 951 bad_extension_order(111), /* new for TLSX */ 952 unrecognised_domain(112), /* new for TLSX */ 953 bad_ocsp_response(113), /* new for TLSX */ 954 pathsec_signal(120), /* new for Pathsec */ 955 (255) 956 } AlertDescription; 958 [Ref:TLS1,TLSX] 960 3.6.1 Pathsec Signals 962 This section describes the Pathsec Signals. All Pathsec nodes MUST 963 relay Pathsec signals downstream. A Pathsec signal affects all nodes 964 in its path, including the end point(s) where it expires. A Pathsec 965 signal is delivered in a pathsec_signal TLS alert, with a TLS alert 966 extension that is to be cast into the PathsecAlert data structure 967 defined as follows. 969 struct { 970 PathsecSignal pathsec_signal_type; 971 opaque pathsec_signal_data<0..2^15-1>; 972 } PathsecAlert; 974 enum { 975 pathsec_set_up_mc(1), 976 pathsec_mc_set_up(2), 977 pathsec_set_up_oc(3), 978 pathsec_oc_set_up(4), 979 pathsec_set_up_ic(5), 980 pathsec_ic_set_up(6), 981 pathsec_tear_down_mc(7), 982 pathsec_mc_torn_down(8), 983 pathsec_tear_down_oc(9), 984 pathsec_oc_torn_down(10), 985 pathsec_tear_down_ic(11), 986 pathsec_ic_torn_down(12), 987 pathsec_tear_down_all(13), 988 pathsec_verify_request_start(14), 989 pathsec_verify_request_end(15), 990 pathsec_verify_response_start(16), 991 pathsec_verify_response_end(17), 992 pathsec_opt_out_oc(18), 993 pathsec_opt_out_oc_ack(19), 994 pathsec_opt_out_oc_nack(20), 995 pathsec_opt_out_ic(21), 996 pathsec_opt_out_ic_ack(22), 997 pathsec_opt_out_ic_nack(23), 998 pathsec_source_route_failed(24), 999 pathsec_feature_unsupported(25), 1000 pathsec_ping(26), 1001 pathsec_echo(27), 1002 pathsec_echo_ok(28), 1003 (255) 1004 } PathsecSignal; 1006 pathsec_set_up_mc(1) 1008 The client or server may optionally send pathsec_set_up_mc to 1009 itself (for invoking a pathsec_set_up_mc callback, e.g.). Upon 1010 receipt of this signal, the client or server enters the SetUp-MC 1011 state (in the Pathsec State Machine). 1013 pathsec_mc_set_up(2) 1015 Either the client or server may optionally send or receive 1016 pathsec_mc_set_up upon exit of SetUp-MC, which is to be followed 1017 by SetUp-OC. 1019 pathsec_set_up_oc(3) 1021 The server sends this signal to the client via MC, and optionally 1022 to itself. The receiver of this signal MUST enter SetUp-OC. The 1023 pathsec_signal_data accompanying this signal contains a 1024 PathsecRoutingMetric, where routeDirection = outbound, i.e. an 1025 ORM. The client MUST start constructing the OC according to the 1026 ORM. The server MUST listen for an outstanding OC connection 1027 request, at the server port specified/implied in the ORM. 1029 pathsec_oc_set_up(4) 1031 The server sends pathsec_oc_set_up to the client via MC, and 1032 optionally to itself, upon the completion of SetUp-OC. 1034 pathsec_set_up_ic(5) 1036 The server sends this signal to the client via MC, and optionally 1037 to itself. The receiver of this signal MUST enter SetUp-IC. The 1038 pathsec_signal_data accompanying this signal contains a 1039 PathsecRoutingMetric, where routeDirection = inbound, i.e. an IRM. 1040 The client MUST start constructing the IC according to the IRM. 1041 The server MUST listen for an outstanding IC connection request, 1042 at the server port specified/implied in the IRM. 1044 The client MAY also send this signal to the server, enclosing in 1045 pathsec_signal_data an IRM with "client-side" hops. In such case, 1046 the server MAY optionally prepend "server-side" hops to the 1047 "client-side" hops, by inserting "server-side" nodes in front of 1048 the last node in hopList. For example, "cs1,cs2,svr" becomes 1049 "cs1,cs2,ss1,ss2,svr." The server then sends back to the client a 1050 pathsec_set_up_ic, with a newly negotiated IRM if applicable. 1052 pathsec_ic_set_up(6) 1054 The server sends pathsec_ic_set_up to the client via MC, and 1055 optionally to itself, upon the completion of SetUp-IC. 1057 pathsec_tear_down_mc(7) 1059 This signal SHOULD NOT be used, pending future specification. (If 1060 MC goes, so go all channels and the entire Pathsec session. Thus 1061 pathsec_tear_down_all seems to be more appropriate for virtually 1062 all foreseeable cases at the writing of this document.) 1064 pathsec_mc_torn_down(8) 1066 This signal SHOULD NOT be used, pending future specification. 1068 pathsec_tear_down_oc(9) 1070 The server MAY at any time send via OC the client 1071 pathsec_tear_down_oc, and vice versa. Both the signal sender and 1072 receiver must enter TearDown-OC immediately. Each intermediary en 1073 route MUST immediately forward the signal downstream, and then 1074 enter TearDown-OC itself. The server and client MUST notify their 1075 respective applications of this signal, and data pending for 1076 read/write MAY be flushed. 1078 pathsec_oc_torn_down(10) 1080 The server sends pathsec_oc_torn_down to the client via MC, and 1081 optionally to itself, upon the completion of TearDown-OC. 1083 pathsec_tear_down_ic(11) 1085 The server MAY at any time send via IC the client 1086 pathsec_tear_down_ic, and vice versa. Both the signal sender and 1087 receiver must enter TearDown-IC immediately. Each intermediary en 1088 route MUST immediately forward the signal downstream, and then 1089 enter TearDown-IC itself. The server and client MUST notify their 1090 respective applications of this signal, and data pending for 1091 read/write MAY be flushed. 1093 pathsec_ic_torn_down(12) 1095 The server sends pathsec_ic_torn_down to the client via MC, and 1096 optionally to itself, upon the completion of TearDown-IC. 1098 pathsec_tear_down_all(13) 1100 The server MAY at any time send via MC the client 1101 pathsec_tear_down_all, and vice versa. Both the signal sender and 1102 receiver must enter TearDown-All immediately. 1103 Pathsec_tear_down_all signals the imminent closure of the Pathsec 1104 session. All channels are to be torn down as soon as possible, 1105 with provision for I/O flushing as appropriate. The server and 1106 client MUST notify their respective applications of this signal, 1107 and data pending for read/write MAY be flushed. 1109 pathsec_verify_request_start(14) 1111 The server MAY send via MC the client, and vice versa, a 1112 pathsec_verify_request_start to initiate a process to verify the 1113 data fidelity in OC. 1115 pathsec_verify_request_end(15) 1117 The server MAY send via MC the client, and vice versa, a 1118 pathsec_verify_request_end to terminate the process of verifying 1119 the data fidelity in OC. 1121 pathsec_verify_response_start(16) 1123 The receiver of pathsec_verify_request_start responses with a 1124 pathsec_verify_response_start to signal that verification data is 1125 forthcoming. 1127 pathsec_verify_response_end(17) 1129 The receiver of pathsec_verify_request_end responses with a 1130 pathsec_verify_response_end to signal the end of verification 1131 data. 1133 pathsec_opt_out_oc(18) 1135 The server MAY send via MC the client, and vice versa, a 1136 pathsec_opt_out_oc to tear down OC. The signal sender SHOULD time 1137 out (with a pathsec_opt_out_oc_nack) if it does not receive a 1138 pathsec_opt_out_oc_ack in 10 seconds. 1140 pathsec_opt_out_oc_ack(19) 1142 The client or the server MUST send via MC pathsec_opt_out_oc_ack 1143 to acknowledge the receipt of pathsec_opt_out_oc, prior to 1144 entering TearDown-OC. Upon receiving pathsec_opt_out_oc_ack, the 1145 pathsec_opt_out_oc sender SHOULD enter TearDown-OC. 1147 pathsec_opt_out_oc_nack(20) 1149 Upon timing out of a pathsec_opt_out_oc, the pathsec_opt_out_oc 1150 sends itself and optionally the pathsec_opt_out_oc receiver a 1151 pathsec_opt_out_oc_nack, via MC. 1153 pathsec_opt_out_ic(21) 1155 The server MAY send via MC the client, and vice versa, a 1156 pathsec_opt_out_ic to tear down IC. The signal sender SHOULD time 1157 out (with a pathsec_opt_out_ic_nack) if it does not receive a 1158 pathsec_opt_out_ic_ack in 10 seconds. 1160 pathsec_opt_out_ic_ack(22) 1162 The client or the server MUST send via MC pathsec_opt_out_ic_ack 1163 to acknowledge the receipt of pathsec_opt_out_oc, prior to 1164 entering TearDown-OC. Upon receiving pathsec_opt_out_ic_ack, the 1165 pathsec_opt_out_oc sender SHOULD enter TearDown-IC. 1167 pathsec_opt_out_ic_nack(23) 1169 Upon timing out of a pathsec_opt_out_ic, the pathsec_opt_out_ic 1170 sends itself and optionally the pathsec_opt_out_ic receiver a 1171 pathsec_opt_out_ic_nack, via MC. 1173 pathsec_source_route_failed(24) 1175 This signal SHOULD NOT be used, pending future specification. A 1176 Pathsec intermediary, in case of locally fatal error, sends a 1177 pathsec_source_route_failed in both upstream and downstream 1178 directions. This signal is fatal to the channel. Upon receiving 1179 pathsec_source_route_faile, the server and the client SHOULD 1180 independently signal pathsec_tear_down_oc (or pathsec_tear_down_ic 1181 as applicable). The client and server applications MUST be 1182 notified of the source route failure. The channel torn down MAY 1183 be re-constructed, provide at least one application layered above 1184 Pathsec commands the server or the client to signal 1185 pathsec_set_up_oc (or pathsec_set_up_ic as applicable). 1187 pathsec_feature_unsupported(25) 1189 A Pathsec node is being requested (by the client or the server) to 1190 perform a task it does not support, then it sends a 1191 pathsec_feature_unsupported upstream, which will be relayed to the 1192 requester. 1194 pathsec_ping(26) & pathsec_echo(27) 1196 The server MAY send a pathsec_ping to the client, and vice versa, 1197 only via MC, for the purposes of: 1) the pinger inquiring the 1198 highest Pathsec version supported by the echo-er; and 2) the 1199 server authenticating a channel that might have been constructed 1200 without Client Authentication during TLS Handshake(s) earlier. 1201 (For example, a bogus last intermediary could gain "acquaintance" 1202 with a Pathsec server using replay attack with an intercepted 1203 channel ticket embedded in a ClientHello's plain-text 1204 serverRandom, if the server did not demand Client Authentication 1205 Handshake. Note that in Pathsec, the server by default does not 1206 demand Client Authentication Handshake, because the last 1207 intermediary may also be the Pathsec client (in a one-hop channel) 1208 which may happen to be a user agent, and it is not common practice 1209 that user agents are in possesion of certificates.) 1211 The pinger packs pathsec_signal_data with a PathsecPing (defined 1212 below). The echo-er copies (or cast) a PathsecPing into a 1213 PathsecEcho (also defined below), assigning proper values to 1214 echo_major and echo_minor, and then emits the PathsecEcho (in 1215 pathsec_signal_data) via the channel indicated by echo_channel_id. 1217 The PathsecPing sender (aka pinger) SHOULD time out, if the 1218 expected PathsecEcho fails to arrive within a reasonable time 1219 limit: 10 seconds * approximated-number-of-hops-in-echo-channel. 1220 All intermediaries relaying a PathsecEcho towards its destination, 1221 except the last intermediary next to the pinger in the echo 1222 channel, MUST NOT modify the content of a PathsecEcho. 1224 PathsecPing and PathsecEcho are defined as follows. 1226 struct { 1227 uint16 ping_id; 1228 uint16 echo_channel_id; 1229 uint8 ping_major; 1230 uint8 ping_minor; 1231 unit8 echo_major; 1232 uint8 echo_minor; 1233 opaque random[24]; 1234 } PathsecPing; 1236 struct { 1237 uint16 ping_id; 1238 uint16 echo_channel_id; 1239 uint8 ping_major; 1240 uint8 ping_minor; 1241 unit8 echo_major; 1242 uint8 echo_minor; 1243 opaque random[20]; 1244 } PathsecEcho; 1246 Ping_id is for tracking pings and echos. Its value is set by the 1247 pinger and MUST NOT be modified by the echo-er or relays. The 1248 value set is unique within an echo channel, and may wrap around. 1250 Echo_channel_id indicates the channel via which the PathsecEcho 1251 MUST travel. Its value is set by the pinger and MUST NOT be 1252 modified by the echo-er or relays. There are three permanently 1253 pre-defined values: 0 -- via MC; 1 -- via OC; 2 -- via IC. 1254 *** Forward Compatibility Note: 1255 *** Future Pathsec versions may support more than three channels. 1257 Ping_major and ping_minor indicate the highest major and minor 1258 numbers of the Pathsec version the pinger supports, starting from 1259 major 1, minor 0. The pinger MUST instantiate ping_major and 1260 ping_minor with correct values; and set echo_major and echo_minor 1261 to 0. 1263 Echo_major and echo_minor indicate the highest major and minor 1264 numbers of the Pathsec version the echo-er (of a PathsecPing) 1265 supports, starting from major 1, minor 0. The echo-er, who is the 1266 originater of a PathsecEcho in reply to a PathsecPing, MUST 1267 instantiate echo_major and echo_minor with correct values. 1269 Major number being 0 indicates the version is experimental. 1270 Experimental versions MUST have non-zero minor numbers. 1272 PathsecEcho.random contains 20 random bytes copied from 1273 EchosecPing.random, which was generated by the pinger, for the 1274 purpose of authenticating the echo channel. The last intermediary 1275 in the echo channel MUST reverse the byte sequence of 1276 PathsecEcho.random, i.e. the first byte becomes the last, the last 1277 byte becomes the first, and so on, prior to forwarding the 1278 PathsecEcho to its destination -- the server. 1280 pathsec_echo_ok(28) 1282 The pinger MUST keep a copy of the PathsecPing sent. Upon receipt 1283 of a PathsecEcho, the pinger MUST compare the ping_id and 1284 echo_channel_id in the PathsecPing and PathsecEcho for identical 1285 matches. Additionally, if the echo channel is not MC (i.e. 1286 echo_channel_id != 0), then the pinger MUST reverse the byte 1287 sequence in PathsecEcho.random and compare PathsecPing.random to 1288 PathsecEcho.random. If they are equal, then the echo channel is 1289 authenticated, and a pathsec_echo_ok signal is to be sent over MC 1290 to the echo-er, accompanied by the PathsecEcho with the 1291 PathsecEcho.random in original byte sequence (originally set by 1292 the pinger). Otherwise, the last intermediary is deemed an 1293 imposter, because it has failed to decipher the PathsecEcho (in 1294 order to reverse the bytes in PathsecEcho.random); and an 1295 "insufficient_security" TLS fatal alert MUST be raised. 1296 Application data SHOULD NOT travel in OC or IC unless the channel 1297 in question has been "certified" for use by a pathsec_echo_ok. 1299 The pinger MAY discard the PathsecPing copy it keeps after 1300 processing the corresponding PathsecEcho. 1302 3.7 Pathsec Set-up 1304 The Pathsec Set-up involves three major steps of state transitions: 1306 Open/Re-open -> 1307 SetUp-MC -> SetUp-OC -> SetUp-IC -> 1308 In-Session 1310 [Ref:Fig 2] 1312 Step 1: the client, in SetUp-MC state, initiates connection to the 1313 server to establish the the Main Channel, using TLS handshake with 1314 Pathsec-extended ClientHello and ServerHello. [Ref:3.1,3.5;3.6.] In 1315 case of a fatal alert, the session -- server and client -- transits 1316 to the Close state; else, the session enters SetUp-OC. 1318 Step 2: the client, in SetUp-OC state, scans the ServerHello 1319 extensions for ORM. If one exists, then it proceeds to set up the 1320 Outbound Channel. Using the ORM embedded in a ServerHello extension 1321 as the guideline, it initiates connection to the first Outbound 1322 Intermediary (the OI1 designated in the ORM), which in turn initiates 1323 connection to the next OI (if one exists), and so on, eventually 1324 connecting to the server. [Ref:3.2] In case of a fatal error, the 1325 session -- client, server, and all intermediaries -- enters 1326 TearDown-All state; else, the session enters SetUp-IC state. 1328 Step 3: the client, in SetUp-IC state, scans the ClientHello 1329 extensions for IRM. If one exists, optionally sets up the Inbound 1330 Channel. Using the Inbound Routing Metric embedded in a ClientHello 1331 Extension, which the client has previously sent to the server while 1332 setting up the Main Channel, it (the client) initiates connection to 1333 the first Inbound Intermediary (i.e. the II1 designated in the IIM), 1334 which in turn initiates connection to the next II, and so on, 1335 eventually connecting to the server. [Ref:3.3] 1337 The successful completion of a Pathsec Set-up is always followed by 1338 In-Session state. [Ref:Fig 2] 1340 3.8 Pathsec In-Session 1342 When a Pathsec session is in In-Session state, application data flow 1343 is guaranteed. 1345 Alerts and signals flow freely at any time. 1347 During In-Session, the server MAY at any time via MC send the client 1348 a pathsec_set_up_oc or a pathsec_set_up_ic signal to cause both the 1349 server and the client to enter SetUp-OC or SetUp-IC, respectively. 1351 During In-Session, the server MAY at any time via MC send the client, 1352 or vice versa, a pathsec_tear_down_oc or a pathsec_tear_down_ic 1353 signal to cause both the server and the client to enter TearDown-OC 1354 or TearDown-IC, respectively. 1356 During In-Session, the server MAY at any time via MC send the client, 1357 or vice versa, a pathsec_tear_down_all signal to cause both the 1358 server and the client to enter TearDown-ALL. 1360 The following signals always bring the Pathsec session back to In- 1361 Session: pathsec_oc_set_up, pathsec_ic_set_up, pathsec_oc_torn_down, 1362 and pathsec_ic_torn_down, 1364 During In-Session, the arrival of verify/audit and opt-out signals 1365 SHALL cause no state transition. 1367 [Ref:3.6.1] 1369 A multi-threaded implementation MAY, in the interest of optimizing 1370 application data throughput, off-load signal handling, which often 1371 requires the session to enter a new state (e.g. SetUp-IC) and then 1372 to return to In-Session. However, the implenmentor is responsible 1373 for synchronizing the In-Session thread with the off-loaded signal 1374 thread(s) such that there MUST NOT be dead-locking or inconsistency 1375 in payload presentatiion (to the application layered above Pathsec). 1377 3.8.1 Pathsec Verify 1379 A Pathsec Verify is always initiated by the client. (If initiated by 1380 the server, then it is termed Pathsec Audit.) 1381 The client MAY at any time send a pathsec_verify_request_start signal 1382 to the server via MC, in order to verify the data fidelity in OC, per 1383 request from its appication above the Pathsec layer. The server MUST 1384 signal its own application layered above Pathsec to start a data 1385 verification process. The verification data, which is identical to 1386 the data that the server releases into OC, is transmitted over MC. 1388 The server, commanded by its application layered above, signals the 1389 client that verification data is forthcoming with a 1390 pathsec_verify_response_start. 1392 The server and client applications MUST device their own means for 1393 delimiting the data being verified, e.g. starting from the next HTTP 1394 response. 1396 The data verification request is in force until the client signals 1397 the server with a pathsec_verify_request_end. 1399 The data verification response is in force until the server signals 1400 the client with a pathsec_verify_response_end. 1402 3.8.2 Pathsec Audit 1404 A Pathsec Audit is always initiated by the server. (If initiated by 1405 the client, then it is termed Pathsec Verify.) 1407 A Pathsec Audit may take one of two forms: 1) verifying the data 1408 fidelity in OC; or 2) authenticating IC or OC. 1410 The server MAY at any time send a pathsec_verify_request_start signal 1411 to the client via MC, in order to verify the data fidelity in OC, per 1412 request from its appication above the Pathsec layer. The client MUST 1413 signal its own application layered above Pathsec to start a data 1414 verification process. The verification data, which is the data that 1415 the client receives from OC, is transmitted over MC. 1417 The client, commanded by its application layered above, signals the 1418 server that verification data is forthcoming with a 1419 pathsec_verify_response_start. 1421 The server and client applications MUST device their own means for 1422 delimiting the data being verified, e.g. starting from the next HTTP 1423 response. 1425 The data verification request is in force until the server signals 1426 the client with a pathsec_verify_request_end. 1428 The data verification response is in force until the client signals 1429 the server with a pathsec_verify_response_end. 1431 [Ref:3.6.1] 1433 Refer to the pathsec_ping, pathsec_echo, and pathsec_echo_ok sub- 1434 sections in [3.6.1] for the details of authenticating an 1435 inbound/outbound channel without using certicate or password. 1437 3.8.3 Pathsec Opt-out 1439 Either the client or the server MAY opt out of OC, or IC, or the 1440 entire Pathsec session, at any time, without cause, by raising 1441 pathsec_opt_out_oc, pathsec_opt_out_ic, or pathsec_tear_down_all, 1442 respectively. 1444 Refer to the raising pathsec_opt_out_oc, pathsec_opt_out_oc_ack, 1445 pathsec_opt_out_oc_nack, pathsec_opt_out_ic, pathsec_opt_out_ic_ack, 1446 pathsec_opt_out_ic_nack, pathsec_tear_down_all, respectively. and 1447 pathsec_tear_down_all sub-sections in [3.6.1] for the workings of 1448 opt-out signal processing. 1450 The opt-out feature is not available for intermediaries. 1452 A Pathsec implementation MUST provide the necessary API for 1453 applications layered above Pathsec to exercise opt-outs. 1455 3.9 Pathsec Tear-down 1457 All nodes in an IC or OC receiving a pathsec_tear_down_ic or 1458 pathsec_tear_down_oc respectively MUST propagate the received signal 1459 downstream, and then proceed to close down its upstream and 1460 downstream connections. The server and the client should signal 1461 themselves with pathsec_ic_torn_down or pathsec_oc_torn_down as 1462 appropriate. 1464 3.10 Pathsec Close 1466 The closure of a Pathsec session SHOULD be preceeded by the tear- 1467 downs of the channels, in strict sequence: IC, OC, and MC. 1469 3.11 Pathsec Re-open 1471 A naturally closed Pathsec session, i.e. the closure was not due to a 1472 fatal alert, MAY be re-opened in manner similar to resuming a TLS 1473 session, using section ID as resumption hint. In order to support 1474 Re-open, both the client and the server MUST be able to cache the 1475 routing metrics of a resumable session off-line. 1477 4 Pathsec Extensions to TLS 1479 Refer to sections 3.5 and 3.6. 1481 5 Application Considerations 1483 Pathsec, co-locating with TLS (above the transport layer) of the OSI 1484 stack, is semantically indifferent to the payload it carries. 1486 Nonetheless, Pathsec is designed to be well suited for the request- 1487 response computing model where a client, a server, and zero or more 1488 intermediaries dot a linear processing path. Finite loops in a 1489 processing path are permissible, as they can be unfolded to form a 1490 linear pattern in a Pathsec Routing Metric. 1492 It is conceivable that Pathsec MAY be used by applications that 1493 involve value-added services provided by intermediaries trusted and 1494 verified by servers and clients. It MAY also be used by content 1495 delivery networks (CDNs) for transporting secured payloads, such as 1496 propagating secured resource updates, say, multicasting authenticated 1497 cache invalidation signals from an origin server to its caching 1498 proxies. (For reference of application models that are being 1499 discussed by IETF working groups and may find Pathsec relevant, 1500 consult literature in [OPES], [WEBI], [CDI].) 1502 It is conceivable that Pathsec may evolve into covering virtual end 1503 points -- in end-to-end simile -- which may be surrogates and proxies 1504 of origin servers or user agents, in a secured content processing 1505 context. 1507 6 Security Considerations 1509 Unless stated otherwise, all failure modes discussed in this section 1510 are catastrophic, though variable in scope of damage. They all 1511 warrant fatal alerts, in spite some damaged sessions may be 1512 salvageable. The server MAY opt to NOT salvage a salvageable session 1513 without cause. Note that detection of failure modes discussed herein 1514 is outside the scope of the Pathsec protocol. 1516 All Pathsec practitioners (in implementation and in deployment) 1517 SHOULD be well acquainted with historic and up-to-date issues related 1518 to network, data, and system security. 1519 [Ref:DENNING,NICHOLS,RESCORLA,STARTLS,TLS1,TLSX] 1521 6.1 Compromised Private Key 1523 If the private key of a Pathsec node is compromised, then the Pathsec 1524 Channel involving the compromised node is also compromised for good 1525 and MUST be torn down. 1527 If the compromised node is either the client or the server, then the 1528 session is compromised. All nodes in session MUST enter the 1529 TearDown-All state, to be followed by Close. The routing metric 1530 containing the compromised node is compromised indefinitely, until a 1531 new and valid private key is available. The server (and the client 1532 if applicable) MUST mark the routing metric unusable until proper key 1533 replenishment. 1535 If the compromised node is an intermediary, then the session may be 1536 salvageable, only by the server. If the compromised metric can be 1537 replaced by an alternative one or be repaired with a new private key, 1538 then the server MUST issue pathsec_tear_down_oc or 1539 pathsec_tear_down_ic as appropriate, and all nodes in the damaged 1540 channel MUST enter TearDown-OC (or TearDown-IC as appropriate), and 1541 then return to In-Session. After receiving a pathsec_oc_torn_down 1542 (or pathsec_ic_torn_down) from the client, the server MAY signal 1543 pathsec_set_up_oc (or pathsec_set_up_ic) to lead the session into 1544 SetUp-OC (or SetUp-IC), and In-Session next. 1546 Salvaging a private-key-compromised Pathsec Session without 1547 sufficient justification (which is outside the Pathsec scope) is NOT 1548 RECOMMENDED. 1550 6.2 Compromised Sub-session Key 1552 If a sub-session key is compromised, then an attacker may conduct 1553 man-in-the-middle activities in the channel involving the compromised 1554 hop. The scopes of damage due to compromised sub-session key range 1555 from per sub-session to per session. However, keep in mind that 1556 compromised sub-session key may only be symptomatic to compromised 1557 private key(s), compromised master secret, or compromised pre-master 1558 secret. 1560 6.3 Compromised Master Secret 1561 If the master secret, originated from the client during client-server 1562 handshake, is compromised, then an attacker may derive Sub-session 1563 Key(s) shared by any two adjacent Pathsec nodes using the publicly 1564 available key derivation function (KDF). (The KDF takes the captured 1565 master secret and two random blocks separately generated by the 1566 client and the server during handshake as input parameters.) Because 1567 the randoms are always transmitted in plain text in TLS, they are 1568 fairgames to network snoopers. The scope of damage due to 1569 compromised master secret is per session. 1571 6.4 Compromised Pre-Master-Secret 1573 If the pre-master secret, originated from the client during client- 1574 server handshake, is compromised, then an attacker may derive the 1575 master secret (and thus sub-session key(s)) using the publicly 1576 available key derivation function (KDF). (The KDF takes the captured 1577 pre-master secret and two random blocks separately generated by the 1578 client and the server during handshake as input parameters.) Because 1579 the randoms are always transmitted in plain text in TLS, they are 1580 fairgames to network snoopers. The scope of damage due to 1581 compromised pre-master secret is per session. 1583 6.5 Ciphersuite Degradation 1585 Each intermediary of an Outbound Channel or an Inbound Channel SHOULD 1586 support at least one ciphersuite that is functionally equivalent to 1587 and is at least as strong as the one deployed in the Main Channel. 1588 Otherwise, the session is vulernable to downgrade attack. 1590 6.6 Perils of Sharing Master Secret Across Channels 1592 The sharing of a master secret (or pre-master secret in a similar 1593 vein) across-channel SHOULD NOT be allowed. For instance, the master 1594 secret of the Main Channel or the Inbound Channel MUST NOT be shared 1595 with the Outbound Channel. Otherwise, outbound intermediaries, say 1596 language translaters or ad inserters, may derive the necessary sub- 1597 session key(s) to snoop inbound traffic, which may contain passwords 1598 that outbound intermediaries are not privy to. 1600 All nodes of a Pathsec session MUST know that both the server and the 1601 client know the common master secrets of all channels. 1603 6.7 Intermediary Weakness 1604 The data in transit to and from the call-outs and value-added 1605 services fashioned by a Pathsec intermediary MUST be secured with a 1606 cryptosystem that is at least as strong as the weakest link in the 1607 Pathsec channel in question. Otherwise, the session is vulernable to 1608 downgrade attack. The server and the client must realize that they, 1609 individually or jointly, have little control over the activities 1610 conducted by trusted intermediaries. Thus frequent audit, or 1611 certification if applicable, of trust-worthiness is RECOMMENDED. 1612 Each intermediary MUST excercise continuous diligence and self- 1613 discipline in securing its own premises in various aspects. 1615 It is possible for "conspiring" intermediaries to modify a routing 1616 policy -- e.g. adding or removing hops from a routing metric, 1617 practically executing loose source routing instead of strict source 1618 routing without the end points' knowledge -- even if the routing 1619 metric has been MACed by the server or the client. Some 1620 intermediaries that are genuinely trustworthy may find this "feature" 1621 a "door" to creative applications, and Pathsec is safe with this 1622 "door" unlocked so long as the intermediaries are genuinely 1623 trustworthy, albeit occasionally mischievous for their own good. 1624 However, there remains the challenge to make this "door" lockable by 1625 the server or the client. 1627 6.8 Remote Execute 1629 Semantics for remote execute are not intrinsic to the Pathsec 1630 protocol. For example, support for dereferencing a Pathsec node 1631 identified as "www.funcity.bom:443/trojanhorse" SHALL NOT be 1632 RECOMMENDED. Both the server and the client SHOULD assume that 1633 intermediaries are very likely to execute remote procudures at their 1634 own discretion. Intermediaries that execute remote procedures MUST 1635 adhere to the guidelines set in 6.7. 1637 7 I18N & L10N Considerations 1639 The hopList of a Pathsec Routing Metric is encoded using UTF-8 1640 [UTF8]. Internationalization (I18N) and localization (L10N) should 1641 be considered only if future domain names are to be specified in text 1642 strings. 1644 8 Intellectual Property Rights 1646 The IETF invites any interested party to bring to its attention any 1647 copyrights, patents or patent applications, or other proprietary 1648 rights which may cover technology that may be required to practice 1649 this document. Please address the information to the IETF Executive 1650 Director. 1652 9 Acknowledgments 1654 The author wishes to thank in advance his Digital Island and Cable & 1655 Wireless Global colleagues, and the IETF TLS Working Group chair and 1656 members for their comments and supports that shall contribute to the 1657 advancement of the Pathsec protocol from its current stage. 1659 10 References 1661 [CDI] Content Distribution/Delivery Internetworking 1662 Working Group, IETF. 1664 [DENNING] D. E. Denning, "Cryptography and Data Security," 1665 Addison-Wesley, 1982. 1667 [HMAC] H. Krawczyk, M. Bellare, and R. Canetti -- HMAC: 1668 Keyed-hashing for message authentication. IETF RFC 2104, 1669 February 1997. 1671 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 1672 P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- 1673 HTTP/1.1," IETF RFC 2616, June 1999. 1675 [IP] ISI, "Internet Protocol, DARPA Internet Program, Protocol 1676 Specification," IETF RFC 791, September 1981. 1678 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 1679 Requirement Levels," IETF RFC 2119, March 1997. 1681 [NICHOLS] R.K. Nichols, "ICSA Guide to Cryptography," 1682 McGraw Hill, 1999. 1684 [OPES] Open Pluggable Edge Services Working Group, IETF. 1686 [RESCORLA] E. Rescorla, "SSL and TLS, Designing and Building 1687 Secure Systems," Addison-Wesley, 2001. 1689 [STARTLS] P. Hoffman, "SMTP Service Extension for Secure SMTP over 1690 TLS,"IETF RFC 2487, January 1999. 1692 [STEVENS] W.R. Stevens, "TCP/IP Illustrated, Vol 1" Addison Wesley, 1693 1994. 1695 [TLS1] T. Dierks, and C. Allen, "The TLS Protocol - Version 1.0," 1696 IETF RFC 2246, January 1999. 1698 [TLSX] S. Blake-Wilson, M. Nystrom, D. Hopwood, and J. Mikkelsen, 1699 "TLS Extensions, draft-ietf-tls-extensions-00.txt," 1700 IETF Internet Draft Work-in-progress, June 2001. 1702 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1703 Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1704 1998. 1706 [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646," 1707 IETF RFC 2279, January 1998. 1709 [WEBI] Web Intermediaries Working Group, IETF. 1711 [XDR] R. Srinivasan, "XDR: External Data Representation Standard," 1712 IETF RFC 1832, March 1995. 1714 [XMPR] D.L. Mills, "An Experimental Multiple-Path Routing Algorithm," 1715 IETF RFC 981, March 1986. 1717 11 Author's Address 1719 Joseph Hui 1720 Digital Island 1721 a Cable & Wireless company 1722 225 W. Hillcrest Drive 1723 Thousand Oaks, CA 91360 1724 USA 1726 Phone: +1 805 370 2165 1728 Email: jhui@digisle.net