Network Working Group A D Keromytis [U-Penn]
Internet Draft W A Simpson [DayDreamer]
expires in six months September 1997
SPKI: ShrinkWrap
draft-simpson-spki-shrinkwrap-01.txt (A) |
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 key manage- |
ment protocols.
Keromytis & Simpson expires in six months [Page i]
DRAFT SPKI ShrinkWrap September 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].
byte An 8-bit quantity; also known as "octet" in stan- +
dardese. +
Keromytis & Simpson expires in six months [Page 1]
DRAFT SPKI ShrinkWrap September 1997
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
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, in the correct order, followed by a Reduction_Request |
certificate indicating the target subject.
The verification server (usually residing in the same machine as the
key management daemon) listens for requests at TCP port 358. The |
verifier will attempt to do the chain reduction specified in [SPKI], |
and return a Reduction_Response self-signed certificate (or an error |
message). The prover checks the response.
More than one reduction can be requested in the same session. The
prover sends any additional Delegation_Certificates needed,
Keromytis & Simpson expires in six months [Page 2]
DRAFT SPKI ShrinkWrap September 1997
interleaved by appropriate Reduction_Request certificates, and col-
lects the Reduction_Responses from the verifier. |
When multiple delegation chains exist with different authorizations, |
the prover sends only those certificates needed to establish the |
desired delegation chain from the verifier to the target subject. |
Even when a Delegation_Certificate has been previously sent in a ses- |
sion, it is necessary to repeat the same certificate in the correct |
order for every Reduction_Request.
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, |
open another connection, and send the delegation chain from its |
beginning.
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.
At any particular time, the verifier may not have sufficient -
resources 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.
Keromytis & Simpson expires in six months [Page 3]
DRAFT SPKI ShrinkWrap September 1997
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. However, the verifier is not required to +
devote enough resources to support the maximum of 254 certificates in +
a single delegation chain. Each verifier will support at least one +
Delegation_Certificate followed by one Reduction_Request.
Keromytis & Simpson expires in six months [Page 4]
DRAFT SPKI ShrinkWrap September 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 5]
DRAFT SPKI ShrinkWrap September 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 some resource is |
unavailable. The counter indicates the particular Delega- |
tion_Certificate for which resources failed. |
When too many other reduction sessions are in progress, the counter |
will indicate the first Delegation_Certificate. |
When too many certificates are included in a single transaction, the |
counter will indicate the unacceptable Delegation_Certificate. If |
the same reduction is attempted at a later time, the prover SHOULD |
divide the reduction into multiple transaction sessions, each with |
fewer delegation certificates.
Keromytis & Simpson expires in six months [Page 6]
DRAFT SPKI ShrinkWrap September 1997
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.
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, and when any single message is |
too large to process.
Keromytis & Simpson expires in six months [Page 7]
DRAFT SPKI ShrinkWrap September 1997
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 Reduc-
tion_Request is received, preventing an indefinite stream of bogus
certificates. Only those certificates necessary for fulfilling the +
Reduction_Request are examined and verified. Caching of active cer-
tificates 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
the TCP session. The receipt of TCP acknowledgments beyond the data
sent MUST cause a reset of the TCP connection.
Keromytis & Simpson expires in six months [Page 8]
DRAFT SPKI ShrinkWrap September 1997
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 9]