INTERNET-DRAFT Brian Tung draft-tung-transsec-sts-00.txt ISI expires September 30, 1997 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 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 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, and expires September 30, 1997. 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 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, 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 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 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 can more properly be called transaction-level security--that is, security for individual objects. In this approach, each object is handled under a separate security context. These protocols are, however, specific to a given transaction protocol: S-HTTP is designed around security HTTP, and the other two around securing electronic mail. The protocol proposed in this document is designed to provide transaction-level security in a generic fashion, so that all transaction-oriented protocols can make use of it. It does so by providing two services. First, given any object as input, it produces a MIME object as output, which encapsulates that input object and performs any of a number of security operations on it, 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, 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 be used to distribute these session keys, such as RSA, Diffie-Hellman, and Kerberos. 3. Message Syntax STS takes any object and produces a object with MIME type "application/sts"; 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===" The input object itself (possibly encrypted) "===End STS Secure Object===" If the input object is a MIME object, then relevant headers are to be included within the "STS Secure Object" delimiters. 3.1. STS Header Syntax The standard format for an STS header is as follows: X-STS-Service-Header: sense=%d; protocol-id=%s; [service-dependent arguments] where "Service" is replaced by the name of a defined STS service. Currently defined services are Payment, Integrity, Authentication, and Encryption. The sense field is a three-digit integer. The first digit indicates the criticality 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. The second digit is the originator digit. If it is 1, the parameters of this field govern this message. The third digit is the receiver digit. If it is 1, the receiver should reply with the parameters 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 supporting the service in question (e.g., "DESSHA1" for a data integrity header). 3.2. In-Band Key Distribution If sender and receiver either share a conventional key, or possess 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; [sign-key-id=%s;] id-life-sig=%s; key-data=%s The key-id is a one-time identifier that will be used to identify this key in this message (and optionally later ones). The key-life is a string that indicates the lifetime during which the key is to be considered valid. A value of "0" indicates that it is valid for this message only. A string "+%d" indicates that it is 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 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 public key. Then the sign-key-id refers to the public key 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: key-id=%s; key-life=%s with leading and trailing whitespace deleted is SHA1 hashed, and signed (with the shared key enc-key-id if it is a symmetric key, or the sign-key-id if that field is present). Then this is BASE64 encoded and placed in the id-life-sig field. The key-data field is derived from the following ASN.1 structure: KeyDataPlain ::= SEQUENCE { key EncryptionKey, nonce INTEGER, timestamp KerberosTime } This structure 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 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 The key-id field is either identical to that in the request, or includes it as a prefix. The key-life field, roughly speaking, must be less than that presented in the request. Specifically, a 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 4.1. Authentication An authentication 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 the authentication-data field is simply a KRB-AP-REQ (as defined in RFC 1510), BASE64 encoded. The session key contained in this request is denoted by the value of the key-id field. (Note 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 are omitted and the receiver is requested to authenticate his reply. 4.2. Integrity A data integrity header has the 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, 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 in the header field. If the second digit of the sense field is 0, then the last two fields are omitted and the receiver is requested 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 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 are omitted and the receiver is requested to encrypt his reply. 5. Error Return If an STS header of a request fails, then the receiver returns an error reply. This error takes the form of a single header: X-STS-Error: %s where the currently defined errors are: Header verification failed. Header rejected. Key verification failed. Key rejected. 6. Expiration Date This draft expires on September 30, 1997. 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