Network Working Group A D Keromytis [U-Penn] Internet Draft W A Simpson [DayDreamer] expires in six months August 1997 SPKI: ShrinkWrap draft-simpson-spki-shrinkwrap-00.txt (B) Status of this Memo This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Distribution of this memo is unlimited. Abstract This protocol facilitates the use of Simple Public Key Infrastructure [SPKI] certificate chains with Internet Protocol Security [IPS] key management protocols. Keromytis & Simpson expires in six months [Page i] DRAFT SPKI ShrinkWrap August 1997 1. Raison d'etre Currently proposed session-key management protocols use UDP [RFC-768] for transport. Internet Protocol version 4 [RFC-791] restricts the maximum reassembled datagram to 576 bytes. Internet Protocol version 6 [RFC-1883] restricts the maximum reassembled datagram to 1500 bytes. Some SPKI certificate chains of delegation could be quite large. Should one of these session-key management protocols need to transmit a lengthy certificate chain, it is quite possible that the protocol will fail. SPKI allows the verifier to reduce a certificate chain to a single certificate. This ShrinkWrap protocol utilizes TCP [RFC-761, RFC-793] to transport long certificate chains, and request a single certificate for subsequent use. 1.1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119]. 1.2. Message Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 1 byte. This document defines the following values: 0 reserved 1 Delegation_Certificate 2 Reduction_Request 3 Reduction_Response 11 Resource_Limit 12 Verification_Failure 13 Message_Reject Counter 1 byte. Aids in matching requests and responses. The first value sent is 1. Thereafter, the value is monotonically increased for each message sent by the Keromytis & Simpson expires in six months [Page 1] DRAFT SPKI ShrinkWrap August 1997 prover. Value 2 bytes. An optional value field. Although the use of the field is optional, this field is always pre- sent to facilitate 32-bit alignment. The messages may have additional fields beyond the common header, as described later. 1.3. Protocol Overview The prover is responsible for obtaining any intermediate certificates to complete the delegation chain from the verifier to the target sub- ject. The prover sends the intermediate Delegation_Certificates to the verifier, followed by a Reduction_Request certificate for the target subject. The verification server (usually residing in the same machine as the key management daemon) listens for requests at TCP port XXX. The verifier will attempt to do the chain reduction specified in [SPKI], and return a Reduction_Response certificate or an error message. More than one reduction can be requested in the same session. The prover sends any additional Delegation_Certificates needed, inter- leaved by appropriate Reduction_Request certificates, and collects the Reduction_Responses from the verifier. When all desired reduced certificates have been obtained, the prover will close the connection. 1.4. Error Recovery The Counter limits the number of messages that may be sent. A maxi- mum of 254 intermediate delegations are supported in a single delega- tion chain. Whenever insufficient numbers remain for completion of the delegation chain, the prover MUST close the current connection, and open another connection. The Counter is required to be monotonically incremented. Whenever an invalid Counter (zero or out of order) is detected, the verifier MUST send a Message_Reject and close the connection. The verifier is not required to devote enough resources to support the maximum of 254 certificates in a single delegation chain. At any particular time, the verifier may not have sufficient resources Keromytis & Simpson expires in six months [Page 2] DRAFT SPKI ShrinkWrap August 1997 available to support reduction of any delegation chain. Whenever insufficient reqources are available, the verifier MUST send a Resource_Limit and close the connection. The verifier SHOULD set an idle timeout for receiving the next mes- sage (default 30 seconds). Following that, the verifier SHOULD close the connection. 2. Data Messages 2.1. Delegation_Certificate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Certificate ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 1 Counter 1 byte. The value is monotonically increased from the previous message sent. Reserved 2 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. Length 4 bytes. Indicates the number of bytes in the fol- lowing certificate. Certificate The certificate to use for verification. Any number of Delegation_Certificates may be sent by the prover prior to the Reduction_Request. Keromytis & Simpson expires in six months [Page 3] DRAFT SPKI ShrinkWrap August 1997 2.2. Reduction_Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Certificate ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 2 Counter 1 byte. The value is monotonically increased from the previous (Delegation_Certificate) message sent. Reserved 2 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. Length 4 bytes. Indicates the number of bytes in the fol- lowing certificate. Certificate The certificate to be verified and reduced. Sending the Reduction_Request triggers a Reduction_Response. 2.3. Reduction_Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Certificate ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 3 Counter 1 byte. Copied from the Reduction_Request. Reserved 2 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. Keromytis & Simpson expires in six months [Page 4] DRAFT SPKI ShrinkWrap August 1997 Length 4 bytes. Indicates the number of bytes in the fol- lowing certificate. Certificate The result certificate. Sent by the verifier to fulfill a Reduction_Request. 3. Error Messages 3.1. Resource_Limit +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 11 Counter 1 byte. Copied from the offending message. Reserved 2 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. This error message is sent by the verifier when too many certificates are included in a single transaction, a certificate is too large, too many other reduction sessions are in progress, or some other resource is unavailable. 3.2. Verification_Failure +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 12 Counter 1 byte. Copied from the offending message. Reserved 2 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. This error message is sent by the verifier when unable to fulfill a Reduction_Request. The counter indicates the particular certificate for which verification failed. Keromytis & Simpson expires in six months [Page 5] DRAFT SPKI ShrinkWrap August 1997 3.3. Message_Reject +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Counter | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 13 Counter 1 byte. Copied from the offending message. Reserved 2 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. Offset 4 bytes. The number of bytes from the beginning of the offending message where the unrecognized field starts. (0) indicates a bad Message number. (1) indicates an invalid Counter. Note that the Offset is 8 greater than a correspond- ing Certificate Length. This error message is sent by the verifier to indicate an unrecog- nized message or certificate format. Security Considerations These messages are likely to be used prior to establishing a security association between the parties. Thus, the messages rely upon the TCP synchronization handshake, and the security of the certificates themselves, to protect against attacks. There are several opportunities for Denial of Service attacks. The simplest is to swamp the verifier with certificates, exhausting the processing resources during verification. The TCP handshake assists in detecting the source of such attacks. Delegation_Certificates SHOULD NOT be verified until the Reduction_Request is received, pre- venting an indefinite stream of bogus certificates. Caching of active certificates will mitigate repetitive requests. An eavesdropper can insert valid TCP sequence numbers with invalid data. This invalid data will be detected by the recipient during certificate verification, but the other party will be locked out of Keromytis & Simpson expires in six months [Page 6] DRAFT SPKI ShrinkWrap August 1997 the TCP session. The receipt of TCP acknowledgments beyond the data sent MUST cause a reset of the TCP connection. Contacts Comments about this document should be discussed on the spki@c2.net mailing list. Questions about this document can also be directed to: Angelos D. Keromytis Distributed Systems Lab Computer and Information Science Department University of Pennsylvania 200 South 33rd Street Philadelphia, Pennsylvania 19104-6389 angelos@adk.gr angelos@dsl.cis.upenn.edu William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071-4818 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Keromytis & Simpson expires in six months [Page 7]