wdiff draft-tung-transsec-sts-00.txt draft-tung-transsec-sts-01.txt

INTERNET-DRAFT Brian Tung
draft-tung-transsec-sts-00.txt
draft-tung-transsec-sts-01.txt ISI
expires September 30, 1997 January 31, 1998

Simple Transaction Security (STS)

0. Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working 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 inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work "work in
progress.''
progress."

To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt''
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).

The distribution of this memo is unlimited. It is filed as
draft-tung-transsec-sts-00.txt,
draft-tung-transsec-sts-01.txt, and expires September 30, 1997. January 31, 1998.
Please send comments to the authors.

1. Abstract

This document describes Simple Transaction Security (STS), a
set of RFC-822 style headers that specify the
protocol for specifying services and protocols used to secure an
enclosed message. These headers
can be used to both indicate and request particular security
services, as well as to distribute per-session keys. The framework is flexible enough to allow a wide
variety of protocols to be subsumed, used, at the cost of some negotiation and
the type of optimizations present in protocols such as S-HTTP.

2. Introduction and Motivation

Much network traffic today can be characterized as transactions.
Examples

STS provides some of this include HTTP and FTP. With the increased placement
of sensitive information comes a correspondingly increased need for
transaction security.

Some recent protocols have been introduced to address this need.
Protocols same services as existing protocols, such
as SSL (Secure Socket Layer) provide a security
context MOSS and S-HTTP. However, STS was developed for end-to-end communications, use in which all messages are
encrypted under this common context. This approach, however, does
not provide object-level granularity--all objects are given the
same security measures.

Other protocols, such as S-HTTP, PEM/MIME, LSAM
(Large Scale Active Middleware) project, which involves a variety of
protocol modifications to enhance web performance, and MOSS, address what
can more properly be called transaction-level security--that is,
security both MOSS and
S-HTTP exhibit limitations that make them less than perfectly suited
for individual objects. this application. In this approach, each object section, we will describe these
protocols and their limitations in some detail.

2.1. MOSS

MIME Object Security Services (MOSS) is
handled under a separate security context. These protocols are,
however, specific protocol that applies
digital signature and encryption services to a given transaction protocol: S-HTTP MIME objects. As such,
it is
designed around security HTTP, and more general than S-HTTP (see below). These services are
provided through the other use of end-to-end cryptography between two around securing
electronic mail.

The protocol proposed
participants at the application layer.

It requires participants to have at least one public/private key
pair, unlike S-HTTP, which allows the services to be specified in this document is designed
relation to provide
transaction-level security symmetric keys (which may be exchanged out of band).
In scenarios in a generic fashion, so which components are in close collaboration, the
requirement that all
transaction-oriented protocols can make use of it. It does so by
providing two services. First, given any object as input, keys be exchanged using public key cryptography is
an extensive performance liability.

MOSS places no inherent limitations on which services it
produces a can
provide support for, but currently only the multipart/signed and
multipart/encrypted MIME object as output, types have been defined. No definitions
have been made for simple transport of security components which encapsulates that input
object and performs any do
not directly affect the content of the message (e.g., payment
instruments or authorization tokens).

2.2. S-HTTP

Secure HTTP (S-HTTP) is a number of message-oriented communications protocol
for securing messages sent using HTTP. It allows applications to
independently apply security operations on it,
such as encryption, services for transaction
confidentiality, data integrity, and authentication. This
framework non-repudiation. S-HTTP
emphasizes flexibility in the choice of algorithms by supporting
option negotiation for each transaction.

S-HTTP is designed to operate in a general enough environment, where
components are not necessarily known to allow for arbitrary user-defined support S-HTTP or its
associated security services.

Secondly, Much of the negotiation supported in
S-HTTP is thus unrequired overhead in cooperative situations in
which trusted components have agreed on a security context, and
where the proposed protocol allows for in-band key distribution,
so that short-term session keys can be established for this transaction and, if desired, following transactions as well. A wide
variety of methods may need only be used secured against external
attackers (including spoofers).

S-HTTP also only applies to distribute these session keys,
such as RSA, Diffie-Hellman, and Kerberos. HTTP transactions. Many of the headers
defined in the S-HTTP draft apply specifically to HTTP constructs.
It also does not attempt to provide secure transport for security
components.

3. Message Syntax Protocol Specification

An STS takes any object message consists of a primary, divided into a preamble and produces a object with MIME type
"application/sts";
body, and an appendix. The preamble contains parameters relating to
the securing of this object is ordered as follows:

In-band key exchange headers (see Section 3.2)
STS security headers (see Section 4)
A blank line.
"===Begin STS Secure Object===" message. The input object itself (possibly encrypted)
"===End STS Secure Object==="

If body contains the input object is payload of the
message, and may be encrypted or unencrypted. The appendix contains
a MIME object, then relevant headers are to signature of the message, though this signature may be included within computed
using a null algorithm. In this section, we describe the "STS Secure Object" delimiters. syntax for
each of these sections.

3.1. STS Header Syntax Primary

The standard format for an STS header primary is structured as follows:

X-STS-Service-Header: sense=%d; protocol-id=%s;
[service-dependent arguments]

where "Service" is replaced by the name of a defined

--BEGIN STS service.
Currently defined services PRIMARY--
Version: 1.0

--BEGIN STS PREAMBLE--
...
--END STS PREAMBLE--

--BEGIN STS BODY--
...
--END STS BODY--

--END STS PRIMARY--

3.1.1. Preamble

The header fields in the preamble are Payment, Integrity, Authentication, formatted as per RFC 822, and Encryption.
are limited to the following:

Association-ID:
Certificate:
In-Band-Key:
Encryption-Key:
Auxiliary:

The sense Association-ID field is mandatory and defines a three-digit integer. unique
identifier for this association. The first digit indicates
the criticality value of the header field. If this digit is 1, the field is
critical: that is, if the receiver does not understand the field, it
must reject the message and return an appropriate error message (if
applicable). If it is 0, the receiver may continue to process the
message, ignoring this particular field.
implementation-defined.

The second digit is the originator digit. If it is 1, the parameters syntax of this field govern this message. The third digit is the receiver
digit. If it Certificate field is 1, the receiver should reply with as follows:

Certificate: Key-ID=<String>; Type=<String>; Encoding=<String>;
<Certificate>

The Key-ID subfield defines the parameters
specified in this field. At least one of these digit must be 1. In
particular, both digits MAY identifier to be 1. used to refer to
this key. The protocol-id field is a string indicating the name of the protocol
supporting the service in question Type (e.g., "DESSHA1" for a data
integrity header).

3.2. In-Band Key Distribution

If sender X.509) and receiver either share a conventional key, or possess
public key pairs, then Encoding define the sender may include a key, format for
the
purposes certificate.

The syntax of this message, in the message itself. This key In-Band-Key field is
expressed as follows:

X-STS-Session-Key: key-id=%s; key-life=%s; enc-key-id=%s;
[sign-key-id=%s;] id-life-sig=%s; key-data=%s

The key-id is a one-time

In-Band-Key: Key-ID=<String>; Distribution-Algorithm=<String>;
[Encrypting-Key-ID=<String>;] Encoding=<String>
<Distributed-Key>

The Key-ID subfield defines the identifier that will to be used to identify refer to
this key key. The Distribution-Algorithm defines the algorithm used in
distributing this message (and optionally later ones).

The key-life key. If key distribution is based on encryption
using a string that indicates key established elsewhere (possibly in this preamble), then
the lifetime during which optional Encrypting-Key-ID subfield contains the key is used to be considered valid. A value of "0" indicates that it
is valid for this message only. A string "+%d" indicates that it
encrypt the distributed key. Otherwise, if the distribution is
valid for
based on a trusted third party, then the specified number of seconds. A string "%d" indicates
that it Distributed-Key is valid until simply
the specified number of seconds after
midnight 1/1/1970. A value of "connect" indicates credentials supplied by that it third party (e.g., Kerberos ticket
and authenticator). In either case, the key is valid
for encoded using the length of
algorithm defined in the connection (to be determined on a
protocol-by-protocol basis). Encoding subfield.

The enc-key-id syntax of the Encryption-Key field is as follows:

Encryption-Key: Key-ID=<String>; Encryption-Algorithm=<String>;
Encoding=<String>

The Key-ID subfield identifies the key being (if any) to be used to
encrypt the
key; its value is a key-id string that has previously been agreed
upon by the sender and receiver (either out of band or in band). body. The sign-key-id field is only present when enc-key-id points to a
public key. Then Encryption-Algorithm subfield defines the sign-key-id refers
algorithm used to encrypt the public key
corresponding to body.

The Encoding field defines the private key used to sign encoding mechanism for the session key.
(When a conventional key body of
the message. This field is mandatory, even if encryption is not
used.

The Auxiliary field is used for the enc-key-id, there is no
need to sign the session key.) miscellaneous related payload, such
as authorization or payment. The id-life-sig syntax for this field will be
described later.

3.1.2. Body

The body of the message is derived constructed as follows. The following string:

key-id=%s; key-life=%s

with leading and trailing whitespace deleted payload is SHA1 hashed, and
signed (with
first optionally encrypted using the shared key enc-key-id if it is a symmetric key,
or parameters described in the sign-key-id if that
Encryption-Key field is present). in the preamble. Then this it is BASE64 encoded and placed using the
algorithm identified in the id-life-sig field.

The key-data Encoding field is derived from in the following ASN.1 structure:

KeyDataPlain ::= SEQUENCE {
key EncryptionKey,
nonce INTEGER,
timestamp KerberosTime
}

This structure preamble. Then it
is DER encoded, optionally signed, then encrypted,
and finally BASE64 encoded before being inserted into the key-data
field. Where applicable, these operations are performed under the
guidelines specified enclosed in PKCS #1 and #7.

The receiver acknowledges this session key by returning the
following header in its reply:

X-STS-Session-Key-Ack: key-id=%s; key-life=%s delimiters described above.

3.2. Appendix

The key-id field appendix is either identical to that in the request, or
includes it structured as a prefix. The key-life field, roughly speaking,
must be less than that presented in follows:

--BEGIN STS APPENDIX--
Version: 1.0
Association-ID | Key-ID: <Value>
[Algorithm-ID: <Value>]
[Encoding: <Value>]

<Signature>
--END STS APPENDIX--

If the request. Specifically, a
reply key-life value of "0" signature is always permitted; additionally, if
either to be based on an integer lifetime or expiration time is given, a smaller
integer in established association, then
the same format is also permitted.

4. Message Semantics

4.1. Authentication

An authentication second header has the following format:

X-STS-Authentication-Header: sense=%d; protocol-id=%s;
[key-id=%s; authentication-data=%s]

The only currently defined authentication protocol is KerberosV5.
It is assumed that the sender knows the receiver's principal name.
The contents of Association-ID field, and its value is
implementation-defined. If, instead, the authentication-data field signature is simply based on a KRB-AP-REQ
(as defined in RFC 1510), BASE64 encoded. The session
key contained distributed in this request the preamble, then the second header is denoted by the
Key-ID field, and its value of is the key-id field. (Note
that this interpretation of identifier assigned to the key-id field is different from that key in Sections 4.2 and 4.3.)

If
the second digit of preamble.

Normally, the sense field is 0, Association-ID determines the signature algorithm and
encoding; if it does not, then the last algorithm and encoding are named
in the optional Algorithm-ID and Encoding fields. These two fields
are omitted and not optional in the receiver is requested to authenticate his reply.

4.2. Integrity

A data integrity header has case of in-band key distribution.

The Signature begins with the first non-white-space character
following format:

X-STS-Integrity-Header: sense=%d; protocol-id=%s;
[key-id=%s; integrity-data=%s]

Currently defined integrity protocols are DESMD5 and DESSHA1. In
either case, the appropriate one-way hash function (either MD5 or
SHA1) is applied to the data, last appendix header value, and then signed (encrypted) ends with the
key specified by key-id. The key-id refers either to a key
exchanged in band as described in Section 3.2, or to a key that
has been agreed upon previously. If this key has been exchanged
out of band, then it is assumed that the receiver knows how to
interpret this field.

The resulting ciphertext is then BASE64 encoded last
non-white-space character before being placed
in the header field.

If end of the second digit appendix. The
structure of the sense field Signature is 0, then dependent on the last two fields
are omitted algorithm and
encoding used.

4. Response

Normally, the receiver response is requested sent to integrity protect his
reply.

4.3. Encryption

An encryption header has the following format:

X-STS-Encryption-Header: sense=%d; protocol-id=%s;
[key-id=%s]

Currently defined protocols are DES and IDEA. The key-id refers
either to a key exchanged initiator of the transaction
in band the same way as described in Section 3.2, or
to a key that has been agreed upon previously. If the request. However, this key has
been exchanged out of band, then it is assumed that not possible if
the receiver
knows how to interpret STS wrapping could not be properly decoded. In this field.

If case, the second digit of
reply indicates the sense field is 0, then error discovered in decoding the last two fields
are omitted and STS request.

4.1. Error Reply

The STS error reply is structured exactly as the receiver request, except
that an additional field is requested used to encrypt his reply.

5. Error Return indicate the error:

Error-ID:

If an STS header of a request fails, then applicable, additional information about the receiver returns an error reply. This error takes is enclosed in
the form body of a single header:

X-STS-Error: %s

where the currently primary. Currently defined errors are:

Header verification failed.
Header rejected.
Key verification failed.
Key rejected. are as follows:

Key(s) not recognized. (List of Key-IDs.)

Certificate type(s) not recognized. (List of Types.)

Can't decode certificate(s). (List of Key-IDs.)

Can't extract key(s). (List of Key-IDs.)

Distribution algorithm(s) not supported. (List of Algorithms.)

Encoding(s) not supported. (List of Encodings.)

Body doesn't decrypt.

Can't verify signature.

Where shown, the message body contains the listed information.

5. Supported Algorithms and Types

Currently supported certificate formats are X.509.

Currently supported encryption algorithms are DES and RSA.

Currently supported signature algorithms are MD5-DES, MD5-RSA,
SHA-DES, and SHA-RSA.

Currently supported key distribution algorithms are KerberosV5.

Currently supported encodings are BASE64, 7-BIT, and 8-BIT.

6. Expiration Date

This draft expires on September 30, 1997. January 31, 1998.

7. Author

Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
Fax: +1 310 823 6714
E-mail: brian@isi.edu