[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ShrinkWrap draft -- comments ?




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]


Follow-Ups: