idnits 2.17.00 (12 Aug 2021) /tmp/idnits21801/draft-ietf-wts-shttp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 46 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1420 has weird spacing: '...n) and the n...' -- 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) -- Missing reference section? 'RFC-2068' on line 1858 looks like a reference -- Missing reference section? 'CMS' on line 1821 looks like a reference -- Missing reference section? 'MOSS' on line 85 looks like a reference -- Missing reference section? 'RFC-2069' on line 1862 looks like a reference -- Missing reference section? 'RFC-822' on line 1823 looks like a reference -- Missing reference section? 'RFC-1847' on line 1848 looks like a reference -- Missing reference section? 'RFC-1848' on line 1852 looks like a reference -- Missing reference section? 'FIPS-81' on line 1795 looks like a reference -- Missing reference section? 'VANO95' on line 1872 looks like a reference -- Missing reference section? 'RFC2104' on line 1866 looks like a reference -- Missing reference section? 'KRAW96b' on line 1813 looks like a reference -- Missing reference section? 'DH' on line 785 looks like a reference -- Missing reference section? 'PKCS-1' on line 799 looks like a reference -- Missing reference section? 'FIPS-186' on line 1801 looks like a reference -- Missing reference section? 'RFC-1319' on line 1826 looks like a reference -- Missing reference section? 'RFC-1321' on line 1828 looks like a reference -- Missing reference section? 'FIPS-180' on line 1798 looks like a reference -- Missing reference section? 'XXXX' on line 821 looks like a reference -- Missing reference section? 'JOHN93' on line 1808 looks like a reference -- Missing reference section? 'HAST96' on line 1466 looks like a reference -- Missing reference section? 'BELL96' on line 1788 looks like a reference -- Missing reference section? 'FIPS-46-1' on line 1791 looks like a reference -- Missing reference section? 'HAST86' on line 1804 looks like a reference -- Missing reference section? 'LAI92' on line 1815 looks like a reference -- Missing reference section? 'PKCS-6' on line 1818 looks like a reference -- Missing reference section? 'RFC-1421' on line 1830 looks like a reference -- Missing reference section? 'RFC-1422' on line 1834 looks like a reference -- Missing reference section? 'RFC-1485' on line 1838 looks like a reference -- Missing reference section? 'RFC-1521' on line 1841 looks like a reference -- Missing reference section? 'RFC-1738' on line 1845 looks like a reference -- Missing reference section? 'RFC-1864' on line 1855 looks like a reference -- Missing reference section? 'SHTML' on line 1869 looks like a reference -- Missing reference section? 'X509' on line 1875 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla, A. Schiffman 3 INTERNET-DRAFT Terisa Systems, Inc. 4 June 1998 (Expires December-98) 6 The Secure HyperText Transfer Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 25 (US West Coast). 27 This document describes S-HTTP version 1.4. Previous versions of S- 28 HTTP numbered 1.0, 1.1, 1.2, and 1.3 have also been released as 29 Internet-Drafts. A companion draft, draft-ietf-wts-shtml-05.txt, 30 describes extensions to HTML to bind S-HTTP negotiation options to 31 HTML anchors. 33 Abstract 35 This memo describes a syntax for securing messages sent using the 36 Hypertext Transfer Protocol (HTTP), which forms the basis for the 37 World Wide Web. Secure HTTP (S-HTTP) provides independently applica- 38 ble security services for transaction confidentiality, authenticity/ 39 integrity and non-repudiability of origin. 41 The protocol emphasizes maximum flexibility in choice of key manage- 42 ment mechanisms, security policies and cryptographic algorithms by 43 supporting option negotiation between parties for each transaction. 45 1. Introduction 47 The World Wide Web (WWW) is a distributed hypermedia system which has 48 gained widespread acceptance among Internet users. Although WWW 49 browsers support other, preexisting Internet application protocols, 50 the native and primary protocol used between WWW clients and servers 51 is the HyperText Transfer Protocol (HTTP) [RFC-2068]. The ease of 52 use of the Web has prompted its widespread employment as a 53 client/server architecture for many applications. Many such applica- 54 tions require the client and server to be able to authenticate each 55 other and exchange sensitive information confidentially. The original 56 HTTP specification had only modest support for the cryptographic 57 mechanisms appropriate for such transactions. 59 Secure HTTP (S-HTTP) provides secure communication mechanisms between 60 an HTTP client-server pair in order to enable spontaneous commercial 61 transactions for a wide range of applications. Our design intent is 62 to provide a flexible protocol that supports multiple orthogonal 63 operation modes, key management mechanisms, trust models, crypto- 64 graphic algorithms and encapsulation formats through option negotia- 65 tion between parties for each transaction. 67 1.1. Summary of Features 69 Secure HTTP is a secure message-oriented communications protocol 70 designed for use in conjunction with HTTP. It is designed to coexist 71 with HTTP's messaging model and to be easily integrated with HTTP 72 applications. 74 Secure HTTP provides a variety of security mechanisms to HTTP clients 75 and servers, providing the security service options appropriate to 76 the wide range of potential end uses possible for the World-Wide Web. 77 The protocol provides symmetric capabilities to both client and 78 server (in that equal treatment is given to both requests and 79 replies, as well as for the preferences of both parties) while 80 preserving the transaction model and implementation characteristics 81 of HTTP. 83 Several cryptographic message format standards may be incorporated 84 into S-HTTP clients and servers, particularly, but in principle not 85 limited to, [CMS] and [MOSS]. S-HTTP supports interoperation among a 86 variety of implementations, and is compatible with HTTP. S-HTTP 87 aware clients can communicate with S-HTTP oblivious servers and 88 vice-versa, although such transactions obviously would not use S-HTTP 89 security features. 91 S-HTTP does not require client-side public key certificates (or pub- 92 lic keys), as it supports symmetric key-only operation modes. This is 93 significant because it means that spontaneous private transactions 94 can occur without requiring individual users to have an established 95 public key. While S-HTTP is able to take advantage of ubiquitous 96 certification infrastructures, its deployment does not require it. 98 S-HTTP supports end-to-end secure transactions, in contrast with the 99 original HTTP authorization mechanisms which require the client to 100 attempt access and be denied before the security mechanism is 101 employed. Clients may be "primed" to initiate a secure transaction 102 (typically using information supplied in message headers); this may 103 be used to support encryption of fill-out forms, for example. With 104 S-HTTP, no sensitive data need ever be sent over the network in the 105 clear. 107 S-HTTP provides full flexibility of cryptographic algorithms, modes 108 and parameters. Option negotiation is used to allow clients and 109 servers to agree on transaction modes (e.g., should the request be 110 signed or encrypted or both -- similarly for the reply?); crypto- 111 graphic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypt- 112 ing, etc.); and certificate selection (please sign with your "Block- 113 buster Video certificate"). 115 S-HTTP attempts to avoid presuming a particular trust model, although 116 its designers admit to a conscious effort to facilitate multiply- 117 rooted hierarchical trust, and anticipate that principals may have 118 many public key certificates. 120 S-HTTP differs from Digest-Authentication, described in [RFC-2069] in 121 that it provides support for public key cryptography and consequently 122 digital signature capability, as well as providing confidentiality. 124 1.2. Changes 126 This document describes S-HTTP/1.4. It differs from the previous 127 draft in that it differs from the previous draft in its support of 128 the Cryptographic Message Syntax (CMS) [CMS], a successor to PKCS-7; 129 and hence now supports the Diffie-Hellman and the (NIST) Digital Sig- 130 nature Standard cryptosystems. CMS used in RSA mode is bits on the 131 wire compatible with PKCS-7. 133 1.3. Processing Model 135 1.3.1. Message Preparation 137 The creation of an S-HTTP message can be thought of as a a function 138 with three inputs: 140 1. The cleartext message. This is either an HTTP message or some 141 other data object. Note that since the cleartext message is 142 carried transparently, headers and all, any version of HTTP 143 can be carried within an S-HTTP wrapper. 144 2. The receiver's cryptographic preferences and keying material. 145 This is either explicitly specified by the receiver or subject 146 to some default set of preferences. 147 3. The sender's cryptographic preferences and keying material. 148 This input to the function can be thought of as implicit 149 since it exists only in the memory of the sender. 151 In order to create an S-HTTP message, then, the sender integrates the 152 sender's preferences with the receiver's preferences. The result of 153 this is a list of cryptographic enhancements to be applied and keying 154 material to be used to apply them. This may require some user inter- 155 vention. For instance, there might be multiple keys available to sign 156 the message. (See Section 3.2.4.9.3 for more on this topic.) Using 157 this data, the sender applies the enhancements to the message clear- 158 text to create the S-HTTP message. 160 The processing steps required to transform the cleartext message into 161 the S-HTTP message are described in Sections 2 and 3. The processing 162 steps required to merge the sender's and receiver's preferences are 163 described in Sections 3.2. 165 1.3.2. Message Recovery 167 The recovery of an S-HTTP message can be thought of as a function of 168 four distinct inputs: 170 1. The S-HTTP message. 171 2. The receiver's stated cryptographic preferences and keying 172 material. The receiver has the opportunity to remember what 173 cryptographic preferences it provided in order for this document 174 to be dereferenced. 175 3. The receiver's current cryptographic preferences and keying 176 material. 177 4. The sender's previously stated cryptographic options. 178 The sender may have stated that he would perform certain 179 cryptographic operations in this message. (Again, see sections 180 4 and 5 for details on how to do this.) 182 In order to recover an S-HTTP message, the receiver needs to read the 183 headers to discover which cryptographic transformations were per- 184 formed on the message, then remove the transformations using some 185 combination of the sender's and receiver's keying material, while 186 taking note of which enhancements were applied. 188 The receiver may also choose to verify that the applied enhancements 189 match both the enhancements that the sender said he would apply 190 (input 4 above) and that the receiver requested (input 2 above) as 191 well as the current preferences to see if the S-HTTP message was 192 appropriately transformed. This process may require interaction with 193 the user to verify that the enhancements are acceptable to the user. 194 (See Section 6.4 for more on this topic.) 196 1.4. Modes of Operation 198 Message protection may be provided on three orthogonal axes: signa- 199 ture, authentication, and encryption. Any message may be signed, 200 authenticated, encrypted, or any combination of these (including no 201 protection). 203 Multiple key management mechanisms are supported, including 204 password-style manually shared secrets and public-key key exchange. 205 In particular, provision has been made for prearranged (in an earlier 206 transaction or out of band) symmetric session keys in order to send 207 confidential messages to those who have no public key pair. 209 Additionally, a challenge-response (``nonce'') mechanism is provided 210 to allow parties to assure themselves of transaction freshness. 212 1.4.1. Signature 214 If the digital signature enhancement is applied, an appropriate cer- 215 tificate may either be attached to the message (possibly along with a 216 certificate chain) or the sender may expect the recipient to obtain 217 the required certificate (chain) independently. 219 1.4.2. Key Exchange and Encryption 221 In support of bulk encryption, S-HTTP defines two key transfer 222 mechanisms, one using public-key enveloped key exchange and another 223 with externally arranged keys. 225 In the former case, the symmetric-key cryptosystem parameter is 226 passed encrypted under the receiver's public key. 228 In the latter mode, we encrypt the content using a prearranged ses- 229 sion key, with key identification information specified on one of the 230 header lines. 232 1.4.3. Message Integrity and Sender Authentication 234 Secure HTTP provides a means to verify message integrity and sender 235 authenticity for a message via the computation of a Message Authenti- 236 cation Code (MAC), computed as a keyed hash over the document using a 237 shared secret -- which could potentially have been arranged in a 238 number of ways, e.g.: manual arrangement or 'inband' key management. 239 This technique requires neither the use of public key cryptography 240 nor encryption. 242 This mechanism is also useful for cases where it is appropriate to 243 allow parties to identify each other reliably in a transaction 244 without providing (third-party) non-repudiability for the transac- 245 tions themselves. The provision of this mechanism is motivated by our 246 bias that the action of "signing" a transaction should be explicit 247 and conscious for the user, whereas many authentication needs (i.e., 248 access control) can be met with a lighter-weight mechanism that 249 retains the scalability advantages of public-key cryptography for key 250 exchange. 252 1.4.4. Freshness 254 The protocol provides a simple challenge-response mechanism, allowing 255 both parties to insure the freshness of transmissions. Additionally, 256 the integrity protection provided to HTTP headers permits implementa- 257 tions to consider the Date: header allowable in HTTP messages as a 258 freshness indicator, where appropriate (although this requires imple- 259 mentations to make allowances for maximum clock skew between parties, 260 which we choose not to specify). 262 1.5. Implementation Options 264 In order to encourage widespread adoption of secure documents for the 265 World-Wide Web in the face of the broad scope of application require- 266 ments, variability of user sophistication, and disparate implementa- 267 tion constraints, Secure HTTP deliberately caters to a variety of 268 implementation options. See Section 8 for implementation recommenda- 269 tions and requirements. 271 2. Message Format 273 Syntactically, Secure HTTP messages are the same as HTTP, consisting 274 of a request or status line followed by headers and a body. However, 275 the range of headers is different and the bodies are typically cryp- 276 tographically enhanced. 278 2.1. Notational Conventions 280 This document uses the augmented BNF from HTTP [RFC-2068]. You should 281 refer to that document for a description of the syntax. 283 2.2. Request Line 285 In order to differentiate S-HTTP messages from HTTP messages and 286 allow for special processing, the request line should use the special 287 Secure" method and use the protocol designator "Secure-HTTP/1.4". 288 Consequently, Secure-HTTP and HTTP processing can be intermixed on 289 the same TCP port, e.g. port 80. In order to prevent leakage of 290 potentially sensitive information Request-URI should be "*". For 291 example: 293 Secure * Secure-HTTP/1.4 295 When communicating via a proxy, the Request-URI should be consist of 296 the AbsoluteURI. Typically, the rel path section should be replaced 297 by "*" to minimize the information passed to in the clear. (e.g. 298 http://www.terisa.com/*); proxies should remove the appropriate 299 amount of this information to minimize the threat of traffic 300 analysis. See Section 7.2.2.1 for a situation where providing more 301 information is appropriate. 303 2.3. The Status Line 305 S-HTTP responses should use the protocol designator "Secure- 306 HTTP/1.4". For example: 308 Secure-HTTP/1.4 200 OK 310 Note that the status in the Secure HTTP response line does not indi- 311 cate anything about the success or failure of the unwrapped HTTP 312 request. Servers should always use 200 OK provided that the Secure 313 HTTP processing is successful. This prevents analysis of success or 314 failure for any request, which the correct recipient can determine 315 from the encapsulated data. All case variations should be accepted. 317 2.4. Secure HTTP Header Lines 319 The header lines described in this section go in the header of a 320 Secure HTTP message. All except 'Content-Type' and 'Content-Privacy- 321 Domain' are optional. The message body shall be separated from the 322 header block by two successive CRLFs. 324 All data and fields in header lines should be treated as case insen- 325 sitive unless otherwise specified. Linear whitespace [RFC-822] should 326 be used only as a token separator unless otherwise quoted. Long 327 header lines may be line folded in the style of [RFC-822]. 329 This document refers to the header block following the S-HTTP 330 request/response line and preceding the successive CRLFs collectively 331 as "S-HTTP headers". 333 2.4.1. Content-Privacy-Domain 335 The two values defined by this document are 'MOSS' and 'CMS'. CMS 336 refers to the privacy enhancement specified in section 2.6.1. MOSS 337 refers to the format defined in [RFC-1847] and [RFC-1848]. 339 2.4.2. Content-Type for CMS 341 Under normal conditions, the terminal encapsulated content (after all 342 privacy enhancements have been removed) would be an HTTP message. In 343 this case, there shall be a Content-Type line reading: 345 Content-Type: message/http 347 The message/http content type is defined in RFC-2068 349 If the inner message is an S-HTTP message, then the content type 350 shall be 'application/s-http'. (See Appendix for the definition of 351 this) 353 It is intended that these types be registered with IANA as MIME con- 354 tent types. 356 The terminal content may be of some other type provided that the type 357 is properly indicated by the use of an appropriate Content-Type 358 header line. In this case, the header fields for the encapsulation of 359 the terminal content apply to the terminal content (the 'final 360 headers'). But in any case, final headers should themselves always be 361 S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are 362 never passed unenhanced. 364 S-HTTP encapsulation of non-HTTP data is a useful mechanism for pass- 365 ing pre-enhanced data (especially presigned data) without requiring 366 that the HTTP headers themselves be pre-enhanced. 368 2.4.3. Content-Type for MOSS 370 The Content-Type for MOSS shall be an acceptable MIME content type 371 describing the cryptographic processing applied. (e.g. 372 multipart/signed). The content type of the inner content is described 373 in the content type line corresponding to that inner content, and for 374 HTTP messages shall be 'message/http'. 376 2.4.4. Prearranged-Key-Info 378 This header line is intended to convey information about a key which 379 has been arranged outside of the internal cryptographic format. One 380 use of this is to permit in-band communication of session keys for 381 return encryption in the case where one of the parties does not have 382 a key pair. However, this should also be useful in the event that the 383 parties choose to use some other mechanism, for instance, a one-time 384 key list. 386 This specification defines two methods for exchanging named keys, 387 Inband, Outband. Inband indicates that the session key was exchanged 388 previously, using a Key-Assign header of the corresponding method. 389 Outband arrangements imply that agents have external access to key 390 materials corresponding to a given name, presumably via database 391 access or perhaps supplied immediately by a user from keyboard input. 392 The syntax for the header line is: 394 Prearranged-Key-Info = 395 "Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID 396 CoverKey-ID = method ":" key-name 397 CoveredDEK = *HEX 398 method = "inband" | "outband" 400 While chaining ciphers require an Initialization Vector (IV) [FIPS- 401 81] to start off the chaining, that information is not carried by 402 this field. Rather, it should be passed internal to the cryptographic 403 format being used. Likewise, the bulk cipher used is specified in 404 this fashion. 406 should be the name of the block cipher used to encrypt 407 the session key (see section 3.2.4.7) 409 is the protected Data Encryption Key (a.k.a. transaction 410 key) under which the encapsulated message was encrypted. It should be 411 appropriately (randomly) generated by the sending agent, then 412 encrypted under the cover of the negotiated key (a.k.a. session key) 413 using the indicated header cipher, and then converted into hex. 415 In order to avoid name collisions, cover key namespaces must be main- 416 tained separately by host and port. 418 Note that some Content-Privacy-Domains, notably likely future revi- 419 sions of MOSS and CMS may have support for symmetric key management. 421 The Prearranged-Key-Info field need not be used in such cir- 422 cumstances. Rather, the native syntax is preferred. Keys exchanged 423 with Key-Assign, however, may be used in this situation. 425 2.4.5. MAC-Info 427 This header is used to supply a Message Authenticity Check, providing 428 both message authentication and integrity, computed from the message 429 text, the time (optional -- to prevent replay attack), and a shared 430 secret between client and server. The MAC should be computed over the 431 encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that 432 MACs should be computed using the following algorithm ('||' means 433 concatenation): 435 MAC = hex(H(Message||[