< draft-tung-transsec-sts-00.txt		draft-tung-transsec-sts-01.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-tung-transsec-sts-00.txt ISI		draft-tung-transsec-sts-01.txt ISI
	expires September 30, 1997		expires January 31, 1998
	Simple Transaction Security (STS)		Simple Transaction Security (STS)
	0. Status of this Memo		0. Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its		documents of the Internet Engineering Task Force (IETF), its areas,
	areas, and its working groups. Note that other groups may also		and its working groups. Note that other groups may also distribute
	distribute working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other
	at any time. It is inappropriate to use Internet-Drafts as		documents at any time. It is inappropriate to use Internet-Drafts
	reference material or to cite them other than as ``work in		as reference material or to cite them other than as "work in
	progress.''		progress."
	To learn the current status of any Internet-Draft, please check		To learn the current status of any Internet-Draft, please check the
	the ``1id-abstracts.txt'' listing contained in the Internet-Drafts		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net		Directories on ds.internic.net (US East Coast), nic.nordu.net
	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific		(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
	Rim).		Rim).
	The distribution of this memo is unlimited. It is filed as		The distribution of this memo is unlimited. It is filed as
	draft-tung-transsec-sts-00.txt, and expires September 30, 1997.		draft-tung-transsec-sts-01.txt, and expires January 31, 1998.
	Please send comments to the authors.		Please send comments to the authors.
	1. Abstract		1. Abstract
	This document describes Simple Transaction Security (STS), a		This document describes Simple Transaction Security (STS), a
	set of RFC-822 style headers that specify the services and		protocol for specifying services and protocols used to secure an
	protocols used to secure an enclosed message. These headers		enclosed message. The framework is flexible enough to allow a wide
	can be used to both indicate and request particular security		variety of protocols to be used, at the cost of some negotiation and
	services, as well as to distribute per-session keys. The		the optimizations present in protocols such as S-HTTP.
	framework is flexible enough to allow a wide variety of
	protocols to be subsumed, at the cost of some negotiation and
	the type of optimizations present in protocols such as S-HTTP.
	2. Introduction and Motivation		2. Introduction and Motivation
	Much network traffic today can be characterized as transactions.		STS provides some of the same services as existing protocols, such
	Examples of this include HTTP and FTP. With the increased placement		as MOSS and S-HTTP. However, STS was developed for use in the LSAM
	of sensitive information comes a correspondingly increased need for		(Large Scale Active Middleware) project, which involves a variety of
	transaction security.		protocol modifications to enhance web performance, and both MOSS and
			S-HTTP exhibit limitations that make them less than perfectly suited
			for this application. In this section, we will describe these
			protocols and their limitations in some detail.
	Some recent protocols have been introduced to address this need.		2.1. MOSS
	Protocols such as SSL (Secure Socket Layer) provide a security
	context for end-to-end communications, 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, and MOSS, address what		MIME Object Security Services (MOSS) is a protocol that applies
	can more properly be called transaction-level security--that is,		digital signature and encryption services to MIME objects. As such,
	security for individual objects. In this approach, each object is		it is more general than S-HTTP (see below). These services are
	handled under a separate security context. These protocols are,		provided through the use of end-to-end cryptography between two
	however, specific to a given transaction protocol: S-HTTP is		participants at the application layer.
	designed around security HTTP, and the other two around securing
	electronic mail.
	The protocol proposed in this document is designed to provide		It requires participants to have at least one public/private key
	transaction-level security in a generic fashion, so that all		pair, unlike S-HTTP, which allows the services to be specified in
	transaction-oriented protocols can make use of it. It does so by		relation to symmetric keys (which may be exchanged out of band).
	providing two services. First, given any object as input, it		In scenarios in which components are in close collaboration, the
	produces a MIME object as output, which encapsulates that input		requirement that keys be exchanged using public key cryptography is
	object and performs any of a number of security operations on it,		an extensive performance liability.
	such as encryption, data integrity, and authentication. This
	framework is general enough to allow for arbitrary user-defined
	services.
	Secondly, the proposed protocol allows for in-band key distribution,		MOSS places no inherent limitations on which services it can
	so that short-term session keys can be established for this		provide support for, but currently only the multipart/signed and
	transaction and, if desired, following transactions as well. A wide		multipart/encrypted MIME types have been defined. No definitions
	variety of methods may be used to distribute these session keys,		have been made for simple transport of security components which do
	such as RSA, Diffie-Hellman, and Kerberos.		not directly affect the content of the message (e.g., payment
			instruments or authorization tokens).
	3. Message Syntax		2.2. S-HTTP
	STS takes any object and produces a object with MIME type		Secure HTTP (S-HTTP) is a message-oriented communications protocol
	"application/sts"; this object is ordered as follows:		for securing messages sent using HTTP. It allows applications to
			independently apply security services for transaction
			confidentiality, data integrity, and non-repudiation. S-HTTP
			emphasizes flexibility in the choice of algorithms by supporting
			option negotiation for each transaction.
	In-band key exchange headers (see Section 3.2)		S-HTTP is designed to operate in a general environment, where
	STS security headers (see Section 4)		components are not necessarily known to support S-HTTP or its
	A blank line.		associated security services. Much of the negotiation supported in
	"===Begin STS Secure Object==="		S-HTTP is thus unrequired overhead in cooperative situations in
	The input object itself (possibly encrypted)		which trusted components have agreed on a security context, and
	"===End STS Secure Object==="		where the transaction need only be secured against external
			attackers (including spoofers).
	If the input object is a MIME object, then relevant headers are to		S-HTTP also only applies to HTTP transactions. Many of the headers
	be included within the "STS Secure Object" delimiters.		defined in the S-HTTP draft apply specifically to HTTP constructs.
			It also does not attempt to provide secure transport for security
			components.
	3.1. STS Header Syntax		3. Protocol Specification
	The standard format for an STS header is as follows:		An STS message consists of a primary, divided into a preamble and a
			body, and an appendix. The preamble contains parameters relating to
			the securing of this message. The body contains the payload of the
			message, and may be encrypted or unencrypted. The appendix contains
			a signature of the message, though this signature may be computed
			using a null algorithm. In this section, we describe the syntax for
			each of these sections.
	X-STS-Service-Header: sense=%d; protocol-id=%s;		3.1. Primary
	[service-dependent arguments]
	where "Service" is replaced by the name of a defined STS service.		The primary is structured as follows:
	Currently defined services are Payment, Integrity, Authentication,
	and Encryption.
	The sense field is a three-digit integer. The first digit indicates		--BEGIN STS PRIMARY--
	the criticality of the header field. If this digit is 1, the field is		Version: 1.0
	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.
	The second digit is the originator digit. If it is 1, the parameters		--BEGIN STS PREAMBLE--
	of this field govern this message. The third digit is the receiver		...
	digit. If it is 1, the receiver should reply with the parameters		--END STS PREAMBLE--
	specified in this field. At least one of these digit must be 1. In
	particular, both digits MAY be 1.
	The protocol-id field is a string indicating the name of the protocol		--BEGIN STS BODY--
	supporting the service in question (e.g., "DESSHA1" for a data		...
	integrity header).		--END STS BODY--
	3.2. In-Band Key Distribution		--END STS PRIMARY--
	If sender and receiver either share a conventional key, or possess		3.1.1. Preamble
	public key pairs, then the sender may include a key, for the
	purposes of this message, in the message itself. This key is
	expressed as follows:
	X-STS-Session-Key: key-id=%s; key-life=%s; enc-key-id=%s;		The header fields in the preamble are formatted as per RFC 822, and
	[sign-key-id=%s;] id-life-sig=%s; key-data=%s		are limited to the following:
	The key-id is a one-time identifier that will be used to identify		Association-ID:
	this key in this message (and optionally later ones).		Certificate:
			In-Band-Key:
			Encryption-Key:
			Auxiliary:
	The key-life is a string that indicates the lifetime during which		The Association-ID field is mandatory and defines a unique
	the key is to be considered valid. A value of "0" indicates that it		identifier for this association. The value of this field is
	is valid for this message only. A string "+%d" indicates that it is		implementation-defined.
	valid for the specified number of seconds. A string "%d" indicates
	that it is valid until the specified number of seconds after
	midnight 1/1/1970. A value of "connect" indicates that it is valid
	for the length of the connection (to be determined on a
	protocol-by-protocol basis).
	The enc-key-id field identifies the key being used to encrypt the		The syntax of the Certificate field is as follows:
	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).
	The sign-key-id field is only present when enc-key-id points to a		Certificate: Key-ID=<String>; Type=<String>; Encoding=<String>;
	public key. Then the sign-key-id refers to the public key		<Certificate>
	corresponding to the private key used to sign the session key.
	(When a conventional key is used for the enc-key-id, there is no
	need to sign the session key.)
	The id-life-sig field is derived as follows. The following string:		The Key-ID subfield defines the identifier to be used to refer to
			this key. The Type (e.g., X.509) and Encoding define the format for
			the certificate.
	key-id=%s; key-life=%s		The syntax of the In-Band-Key field is as follows:
	with leading and trailing whitespace deleted is SHA1 hashed, and		In-Band-Key: Key-ID=<String>; Distribution-Algorithm=<String>;
	signed (with the shared key enc-key-id if it is a symmetric key,		[Encrypting-Key-ID=<String>;] Encoding=<String>
	or the sign-key-id if that field is present). Then this is BASE64		<Distributed-Key>
	encoded and placed in the id-life-sig field.
	The key-data field is derived from the following ASN.1 structure:		The Key-ID subfield defines the identifier to be used to refer to
			this key. The Distribution-Algorithm defines the algorithm used in
			distributing this key. If key distribution is based on encryption
			using a key established elsewhere (possibly in this preamble), then
			the optional Encrypting-Key-ID subfield contains the key used to
			encrypt the distributed key. Otherwise, if the distribution is
			based on a trusted third party, then the Distributed-Key is simply
			the credentials supplied by that third party (e.g., Kerberos ticket
			and authenticator). In either case, the key is encoded using the
			algorithm defined in the Encoding subfield.
	KeyDataPlain ::= SEQUENCE {		The syntax of the Encryption-Key field is as follows:
	key EncryptionKey,
	nonce INTEGER,
	timestamp KerberosTime
	}
	This structure is DER encoded, optionally signed, then encrypted,		Encryption-Key: Key-ID=<String>; Encryption-Algorithm=<String>;
	and finally BASE64 encoded before being inserted into the key-data		Encoding=<String>
	field. Where applicable, these operations are performed under the
	guidelines specified in PKCS #1 and #7.
	The receiver acknowledges this session key by returning the		The Key-ID subfield identifies the key (if any) to be used to
	following header in its reply:		encrypt the body. The Encryption-Algorithm subfield defines the
			algorithm used to encrypt the body.
	X-STS-Session-Key-Ack: key-id=%s; key-life=%s		The Encoding field defines the encoding mechanism for the body of
			the message. This field is mandatory, even if encryption is not
			used.
	The key-id field is either identical to that in the request, or		The Auxiliary field is used for miscellaneous related payload, such
	includes it as a prefix. The key-life field, roughly speaking,		as authorization or payment. The syntax for this field will be
	must be less than that presented in the request. Specifically, a		described later.
	reply key-life value of "0" is always permitted; additionally, if
	either an integer lifetime or expiration time is given, a smaller
	integer in the same format is also permitted.
	4. Message Semantics		3.1.2. Body
	4.1. Authentication		The body of the message is constructed as follows. The payload is
			first optionally encrypted using the parameters described in the
			Encryption-Key field in the preamble. Then it is encoded using the
			algorithm identified in the Encoding field in the preamble. Then it
			is enclosed in the delimiters described above.
	An authentication header has the following format:		3.2. Appendix
	X-STS-Authentication-Header: sense=%d; protocol-id=%s;		The appendix is structured as follows:
	[key-id=%s; authentication-data=%s]
	The only currently defined authentication protocol is KerberosV5.		--BEGIN STS APPENDIX--
	It is assumed that the sender knows the receiver's principal name.		Version: 1.0
	The contents of the authentication-data field is simply a KRB-AP-REQ		Association-ID | Key-ID: <Value>
	(as defined in RFC 1510), BASE64 encoded. The session key contained		[Algorithm-ID: <Value>]
	in this request is denoted by the value of the key-id field. (Note		[Encoding: <Value>]
	that this interpretation of the key-id field is different from that
	in Sections 4.2 and 4.3.)
	If the second digit of the sense field is 0, then the last two fields		<Signature>
	are omitted and the receiver is requested to authenticate his reply.		--END STS APPENDIX--
	4.2. Integrity		If the signature is to be based on an established association, then
			the second header is the Association-ID field, and its value is
			implementation-defined. If, instead, the signature is based on a
			key distributed in the preamble, then the second header is the
			Key-ID field, and its value is the identifier assigned to the key in
			the preamble.
	A data integrity header has the following format:		Normally, the Association-ID determines the signature algorithm and
			encoding; if it does not, then the algorithm and encoding are named
			in the optional Algorithm-ID and Encoding fields. These two fields
			are not optional in the case of in-band key distribution.
	X-STS-Integrity-Header: sense=%d; protocol-id=%s;		The Signature begins with the first non-white-space character
	[key-id=%s; integrity-data=%s]		following the last appendix header value, and ends with the last
			non-white-space character before the end of the appendix. The
			structure of the Signature is dependent on the algorithm and
			encoding used.
	Currently defined integrity protocols are DESMD5 and DESSHA1. In		4. Response
	either case, the appropriate one-way hash function (either MD5 or
	SHA1) is applied to the data, and then signed (encrypted) 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 before being placed		Normally, the response is sent to the initiator of the transaction
	in the header field.		in the same way as the request. However, this is not possible if
			the STS wrapping could not be properly decoded. In this case, the
			reply indicates the error discovered in decoding the STS request.
	If the second digit of the sense field is 0, then the last two fields		4.1. Error Reply
	are omitted and the receiver is requested to integrity protect his
	reply.
	4.3. Encryption		The STS error reply is structured exactly as the request, except
			that an additional field is used to indicate the error:
	An encryption header has the following format:		Error-ID:
	X-STS-Encryption-Header: sense=%d; protocol-id=%s;		If applicable, additional information about the error is enclosed in
	[key-id=%s]		the body of the primary. Currently defined errors are as follows:
	Currently defined protocols are DES and IDEA. The key-id refers		Key(s) not recognized. (List of Key-IDs.)
	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.
	If the second digit of the sense field is 0, then the last two fields		Certificate type(s) not recognized. (List of Types.)
	are omitted and the receiver is requested to encrypt his reply.
	5. Error Return		Can't decode certificate(s). (List of Key-IDs.)
	If an STS header of a request fails, then the receiver returns an		Can't extract key(s). (List of Key-IDs.)
	error reply. This error takes the form of a single header:
	X-STS-Error: %s		Distribution algorithm(s) not supported. (List of Algorithms.)
	where the currently defined errors are:		Encoding(s) not supported. (List of Encodings.)
	Header verification failed.		Body doesn't decrypt.
	Header rejected.
	Key verification failed.		Can't verify signature.
	Key rejected.
			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		6. Expiration Date
	This draft expires on September 30, 1997.		This draft expires on January 31, 1998.
	7. Author		7. Author
	Brian Tung		Brian Tung
	USC Information Sciences Institute		USC Information Sciences Institute
	4676 Admiralty Way Suite 1001		4676 Admiralty Way Suite 1001
	Marina del Rey CA 90292-6695		Marina del Rey CA 90292-6695
	Phone: +1 310 822 1511		Phone: +1 310 822 1511
	Fax: +1 310 823 6714		Fax: +1 310 823 6714
	E-mail: brian@isi.edu		E-mail: brian@isi.edu
End of changes. 61 change blocks.
	185 lines changed or deleted		188 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/