idnits 2.17.1 draft-simpson-spki-shrinkwrap-01.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 (2024-04-19) 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) 2024 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. ** 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. == 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 Introduction 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 an Authors' Addresses Section. ** There are 34 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([SPKI]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 129: '...hain, the prover MUST close the curren...' RFC 2119 keyword, line 134: '... order) is detected, the verifier MUST...' RFC 2119 keyword, line 139: '... are available, the verifier MUST send...' RFC 2119 keyword, line 142: '... The verifier SHOULD set an idle tim...' RFC 2119 keyword, line 143: '...lowing that, the verifier SHOULD close...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (September 1997) is 9713 days in the past. Is this intentional? 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? 'U-Penn' on line 1 looks like a reference -- Missing reference section? 'DayDreamer' on line 2 looks like a reference -- Missing reference section? 'SPKI' on line 105 looks like a reference -- Missing reference section? 'RFC-768' on line 41 looks like a reference -- Missing reference section? 'RFC-791' on line 42 looks like a reference -- Missing reference section? 'RFC-1883' on line 44 looks like a reference -- Missing reference section? 'RFC-2119' on line 62 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A D Keromytis [U-Penn] 2 Internet Draft W A Simpson [DayDreamer] 3 expires in six months September 1997 5 SPKI: ShrinkWrap 6 draft-simpson-spki-shrinkwrap-01.txt (A) | 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Europe) 27 ds.internic.net (US East Coast) 28 ftp.isi.edu (US West Coast) 29 munnari.oz.au (Pacific Rim) 31 Distribution of this memo is unlimited. 33 Abstract 35 This protocol facilitates the use of Simple Public Key Infrastructure 36 [SPKI] certificate chains with Internet Protocol Security key manage- | 37 ment protocols. 39 1. Raison d'etre 41 Currently proposed session-key management protocols use UDP [RFC-768] 42 for transport. Internet Protocol version 4 [RFC-791] restricts the 43 maximum reassembled datagram to 576 bytes. Internet Protocol version 44 6 [RFC-1883] restricts the maximum reassembled datagram to 1500 45 bytes. 47 Some SPKI certificate chains of delegation could be quite large. 48 Should one of these session-key management protocols need to transmit 49 a lengthy certificate chain, it is quite possible that the protocol 50 will fail. 52 SPKI allows the verifier to reduce a certificate chain to a single 53 certificate. This ShrinkWrap protocol utilizes TCP [RFC-761, 54 RFC-793] to transport long certificate chains, and request a single 55 certificate for subsequent use. 57 1.1. Terminology 59 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 60 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 61 described in [RFC-2119]. 63 byte An 8-bit quantity; also known as "octet" in stan- + 64 dardese. + 66 1.2. Message Header 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 69 | Message | Counter | Value | 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 Message 1 byte. This document defines the following values: 74 0 reserved 75 1 Delegation_Certificate 76 2 Reduction_Request 77 3 Reduction_Response 78 11 Resource_Limit 79 12 Verification_Failure 80 13 Message_Reject 82 Counter 1 byte. Aids in matching requests and responses. 84 The first value sent is 1. Thereafter, the value is 85 monotonically increased for each message sent by the 86 prover. 88 Value 2 bytes. An optional value field. Although the use 89 of the field is optional, this field is always pre- 90 sent to facilitate 32-bit alignment. 92 The messages may have additional fields beyond the common header, as 93 described later. 95 1.3. Protocol Overview 97 The prover is responsible for obtaining any intermediate certificates 98 to complete the delegation chain from the verifier to the target sub- | 99 ject. The prover sends the intermediate Delegation_Certificates to 100 the verifier, in the correct order, followed by a Reduction_Request | 101 certificate indicating the target subject. 103 The verification server (usually residing in the same machine as the 104 key management daemon) listens for requests at TCP port 358. The | 105 verifier will attempt to do the chain reduction specified in [SPKI], | 106 and return a Reduction_Response self-signed certificate (or an error | 107 message). The prover checks the response. 109 More than one reduction can be requested in the same session. The 110 prover sends any additional Delegation_Certificates needed, 111 interleaved by appropriate Reduction_Request certificates, and col- 112 lects the Reduction_Responses from the verifier. | 114 When multiple delegation chains exist with different authorizations, | 115 the prover sends only those certificates needed to establish the | 116 desired delegation chain from the verifier to the target subject. | 117 Even when a Delegation_Certificate has been previously sent in a ses- | 118 sion, it is necessary to repeat the same certificate in the correct | 119 order for every Reduction_Request. 121 When all desired reduced certificates have been obtained, the prover 122 will close the connection. 124 1.4. Error Recovery 126 The Counter limits the number of messages that may be sent. A maxi- 127 mum of 254 intermediate delegations are supported in a single delega- 128 tion chain. Whenever insufficient numbers remain for completion of 129 the delegation chain, the prover MUST close the current connection, | 130 open another connection, and send the delegation chain from its | 131 beginning. 133 The Counter is required to be monotonically incremented. Whenever an 134 invalid Counter (zero or out of order) is detected, the verifier MUST 135 send a Message_Reject and close the connection. 137 At any particular time, the verifier may not have sufficient - 138 resources available to support reduction of any delegation chain. 139 Whenever insufficient reqources are available, the verifier MUST send 140 a Resource_Limit and close the connection. 142 The verifier SHOULD set an idle timeout for receiving the next mes- 143 sage (default 30 seconds). Following that, the verifier SHOULD close 144 the connection. 146 2. Data Messages 147 2.1. Delegation_Certificate 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Message | Counter | Reserved | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 ~ Certificate ~ 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Message 1 161 Counter 1 byte. The value is monotonically increased from 162 the previous message sent. 164 Reserved 2 bytes. For future use; MUST be set to zero when 165 transmitted, and MUST be ignored when received. 167 Length 4 bytes. Indicates the number of bytes in the fol- 168 lowing certificate. 170 Certificate The certificate to use for verification. 172 Any number of Delegation_Certificates may be sent by the prover prior 173 to the Reduction_Request. However, the verifier is not required to + 174 devote enough resources to support the maximum of 254 certificates in + 175 a single delegation chain. Each verifier will support at least one + 176 Delegation_Certificate followed by one Reduction_Request. 178 2.2. Reduction_Request 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Message | Counter | Reserved | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 ~ Certificate ~ 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Message 2 192 Counter 1 byte. The value is monotonically increased from 193 the previous (Delegation_Certificate) message sent. 195 Reserved 2 bytes. For future use; MUST be set to zero when 196 transmitted, and MUST be ignored when received. 198 Length 4 bytes. Indicates the number of bytes in the fol- 199 lowing certificate. 201 Certificate The certificate to be verified and reduced. 203 Sending the Reduction_Request triggers a Reduction_Response. 205 2.3. Reduction_Response 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Message | Counter | Reserved | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 ~ Certificate ~ 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Message 3 219 Counter 1 byte. Copied from the Reduction_Request. 221 Reserved 2 bytes. For future use; MUST be set to zero when 222 transmitted, and MUST be ignored when received. 224 Length 4 bytes. Indicates the number of bytes in the fol- 225 lowing certificate. 227 Certificate The result certificate. 229 Sent by the verifier to fulfill a Reduction_Request. 231 3. Error Messages 232 3.1. Resource_Limit 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Message | Counter | Reserved | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Message 11 240 Counter 1 byte. Copied from the offending message. 242 Reserved 2 bytes. For future use; MUST be set to zero when 243 transmitted, and MUST be ignored when received. 245 This error message is sent by the verifier when some resource is | 246 unavailable. The counter indicates the particular Delega- | 247 tion_Certificate for which resources failed. | 249 When too many other reduction sessions are in progress, the counter | 250 will indicate the first Delegation_Certificate. | 252 When too many certificates are included in a single transaction, the | 253 counter will indicate the unacceptable Delegation_Certificate. If | 254 the same reduction is attempted at a later time, the prover SHOULD | 255 divide the reduction into multiple transaction sessions, each with | 256 fewer delegation certificates. 258 3.2. Verification_Failure 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Message | Counter | Reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Message 12 266 Counter 1 byte. Copied from the offending message. 268 Reserved 2 bytes. For future use; MUST be set to zero when 269 transmitted, and MUST be ignored when received. 271 This error message is sent by the verifier when unable to fulfill a 272 Reduction_Request. The counter indicates the particular certificate 273 for which verification failed. 275 3.3. Message_Reject 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Message | Counter | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Offset | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Message 13 285 Counter 1 byte. Copied from the offending message. 287 Reserved 2 bytes. For future use; MUST be set to zero when 288 transmitted, and MUST be ignored when received. 290 Offset 4 bytes. The number of bytes from the beginning of 291 the offending message where the unrecognized field 292 starts. 294 (0) indicates a bad Message number. 295 (1) indicates an invalid Counter. 297 Note that the Offset is 8 greater than a correspond- 298 ing Certificate Length. 300 This error message is sent by the verifier to indicate an unrecog- | 301 nized message or certificate format, and when any single message is | 302 too large to process. 304 Security Considerations 306 These messages are likely to be used prior to establishing a security 307 association between the parties. Thus, the messages rely upon the 308 TCP synchronization handshake, and the security of the certificates 309 themselves, to protect against attacks. 311 There are several opportunities for Denial of Service attacks. The 312 simplest is to swamp the verifier with certificates, exhausting the 313 processing resources during verification. The TCP handshake assists 314 in detecting the source of such attacks. + 316 Delegation_Certificates SHOULD NOT be verified until the Reduc- 317 tion_Request is received, preventing an indefinite stream of bogus 318 certificates. Only those certificates necessary for fulfilling the + 319 Reduction_Request are examined and verified. Caching of active cer- 320 tificates will mitigate repetitive requests. 322 An eavesdropper can insert valid TCP sequence numbers with invalid 323 data. This invalid data will be detected by the recipient during 324 certificate verification, but the other party will be locked out of 325 the TCP session. The receipt of TCP acknowledgments beyond the data 326 sent MUST cause a reset of the TCP connection. 328 Contacts 330 Comments about this document should be discussed on the spki@c2.net 331 mailing list. 333 Questions about this document can also be directed to: 335 Angelos D. Keromytis 336 Distributed Systems Lab 337 Computer and Information Science Department 338 University of Pennsylvania 339 200 South 33rd Street 340 Philadelphia, Pennsylvania 19104-6389 342 angelos@adk.gr 343 angelos@dsl.cis.upenn.edu 345 William Allen Simpson 346 DayDreamer 347 Computer Systems Consulting Services 348 1384 Fontaine 349 Madison Heights, Michigan 48071-4818 351 wsimpson@UMich.edu 352 wsimpson@GreenDragon.com (preferred) 353 bsimpson@MorningStar.com