home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_s_z
/
draft-simpson-spki-shrinkwrap-00.txt
< prev
next >
Wrap
Text File
|
1997-08-28
|
15KB
|
439 lines
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]