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-tung-transsec-sts-01.txt < prev    next >
Text File  |  1997-08-01  |  11KB  |  278 lines
  1.  
  2. INTERNET-DRAFT                                                Brian Tung
  3. draft-tung-transsec-sts-01.txt                                       ISI
  4. expires January 31, 1998
  5.  
  6.                    Simple Transaction Security (STS)
  7.  
  8. 0.  Status of this Memo
  9.  
  10.     This document is an Internet-Draft.  Internet-Drafts are working
  11.     documents of the Internet Engineering Task Force (IETF), its areas,
  12.     and its working groups.  Note that other groups may also distribute
  13.     working documents as Internet-Drafts.
  14.  
  15.     Internet-Drafts are draft documents valid for a maximum of six
  16.     months and may be updated, replaced, or obsoleted by other
  17.     documents at any time.  It is inappropriate to use Internet-Drafts
  18.     as reference material or to cite them other than as "work in
  19.     progress."
  20.  
  21.     To learn the current status of any Internet-Draft, please check the
  22.     "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  23.     Directories on ds.internic.net (US East Coast), nic.nordu.net
  24.     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  25.     Rim).
  26.  
  27.     The distribution of this memo is unlimited.  It is filed as
  28.     draft-tung-transsec-sts-01.txt, and expires January 31, 1998.
  29.     Please send comments to the authors.
  30.  
  31. 1.  Abstract
  32.  
  33.     This document describes Simple Transaction Security (STS), a
  34.     protocol for specifying services and protocols used to secure an
  35.     enclosed message.  The framework is flexible enough to allow a wide
  36.     variety of protocols to be used, at the cost of some negotiation and
  37.     the optimizations present in protocols such as S-HTTP.
  38.  
  39. 2.  Introduction and Motivation
  40.  
  41.     STS provides some of the same services as existing protocols, such
  42.     as MOSS and S-HTTP.  However, STS was developed for use in the LSAM
  43.     (Large Scale Active Middleware) project, which involves a variety of
  44.     protocol modifications to enhance web performance, and both MOSS and
  45.     S-HTTP exhibit limitations that make them less than perfectly suited
  46.     for this application.  In this section, we will describe these
  47.     protocols and their limitations in some detail.
  48.  
  49. 2.1.  MOSS
  50.  
  51.     MIME Object Security Services (MOSS) is a protocol that applies
  52.     digital signature and encryption services to MIME objects.  As such,
  53.     it is more general than S-HTTP (see below).  These services are
  54.     provided through the use of end-to-end cryptography between two
  55.     participants at the application layer.
  56.  
  57.     It requires participants to have at least one public/private key
  58.     pair, unlike S-HTTP, which allows the services to be specified in
  59.     relation to symmetric keys (which may be exchanged out of band).
  60.     In scenarios in which components are in close collaboration, the
  61.     requirement that keys be exchanged using public key cryptography is
  62.     an extensive performance liability.
  63.  
  64.     MOSS places no inherent limitations on which services it can
  65.     provide support for, but currently only the multipart/signed and
  66.     multipart/encrypted MIME types have been defined.  No definitions
  67.     have been made for simple transport of security components which do
  68.     not directly affect the content of the message (e.g., payment
  69.     instruments or authorization tokens).
  70.  
  71. 2.2.  S-HTTP
  72.  
  73.     Secure HTTP (S-HTTP) is a message-oriented communications protocol
  74.     for securing messages sent using HTTP.  It allows applications to
  75.     independently apply security services for transaction
  76.     confidentiality, data integrity, and non-repudiation.  S-HTTP
  77.     emphasizes flexibility in the choice of algorithms by supporting
  78.     option negotiation for each transaction.
  79.  
  80.     S-HTTP is designed to operate in a general environment, where
  81.     components are not necessarily known to support S-HTTP or its
  82.     associated security services.  Much of the negotiation supported in
  83.     S-HTTP is thus unrequired overhead in cooperative situations in
  84.     which trusted components have agreed on a security context, and
  85.     where the transaction need only be secured against external
  86.     attackers (including spoofers).
  87.  
  88.     S-HTTP also only applies to HTTP transactions.  Many of the headers
  89.     defined in the S-HTTP draft apply specifically to HTTP constructs.
  90.     It also does not attempt to provide secure transport for security
  91.     components.
  92.  
  93. 3.  Protocol Specification
  94.  
  95.     An STS message consists of a primary, divided into a preamble and a
  96.     body, and an appendix.  The preamble contains parameters relating to
  97.     the securing of this message.  The body contains the payload of the
  98.     message, and may be encrypted or unencrypted.  The appendix contains
  99.     a signature of the message, though this signature may be computed
  100.     using a null algorithm.  In this section, we describe the syntax for
  101.     each of these sections.
  102.  
  103. 3.1.  Primary
  104.  
  105.     The primary is structured as follows:
  106.  
  107.         --BEGIN STS PRIMARY--
  108.         Version: 1.0
  109.  
  110.         --BEGIN STS PREAMBLE--
  111.         ...
  112.         --END STS PREAMBLE--
  113.  
  114.         --BEGIN STS BODY--
  115.         ...
  116.         --END STS BODY--
  117.  
  118.         --END STS PRIMARY--
  119.  
  120. 3.1.1.  Preamble
  121.  
  122.     The header fields in the preamble are formatted as per RFC 822, and
  123.     are limited to the following:
  124.  
  125.         Association-ID:
  126.         Certificate:
  127.         In-Band-Key:
  128.         Encryption-Key:
  129.         Auxiliary:
  130.  
  131.     The Association-ID field is mandatory and defines a unique
  132.     identifier for this association.  The value of this field is
  133.     implementation-defined.
  134.  
  135.     The syntax of the Certificate field is as follows:
  136.  
  137.         Certificate: Key-ID=<String>; Type=<String>; Encoding=<String>;
  138.                 <Certificate>
  139.  
  140.     The Key-ID subfield defines the identifier to be used to refer to
  141.     this key.  The Type (e.g., X.509) and Encoding define the format for
  142.     the certificate.
  143.  
  144.     The syntax of the In-Band-Key field is as follows:
  145.  
  146.         In-Band-Key: Key-ID=<String>; Distribution-Algorithm=<String>;
  147.                 [Encrypting-Key-ID=<String>;] Encoding=<String>
  148.                 <Distributed-Key>
  149.  
  150.     The Key-ID subfield defines the identifier to be used to refer to
  151.     this key.  The Distribution-Algorithm defines the algorithm used in
  152.     distributing this key.  If key distribution is based on encryption
  153.     using a key established elsewhere (possibly in this preamble), then
  154.     the optional Encrypting-Key-ID subfield contains the key used to
  155.     encrypt the distributed key.  Otherwise, if the distribution is
  156.     based on a trusted third party, then the Distributed-Key is simply
  157.     the credentials supplied by that third party (e.g., Kerberos ticket
  158.     and authenticator).  In either case, the key is encoded using the
  159.     algorithm defined in the Encoding subfield.
  160.  
  161.     The syntax of the Encryption-Key field is as follows:
  162.  
  163.         Encryption-Key: Key-ID=<String>; Encryption-Algorithm=<String>;
  164.                 Encoding=<String>
  165.  
  166.     The Key-ID subfield identifies the key (if any) to be used to
  167.     encrypt the body.  The Encryption-Algorithm subfield defines the
  168.     algorithm used to encrypt the body.
  169.  
  170.     The Encoding field defines the encoding mechanism for the body of
  171.     the message.  This field is mandatory, even if encryption is not
  172.     used.
  173.  
  174.     The Auxiliary field is used for miscellaneous related payload, such
  175.     as authorization or payment.  The syntax for this field will be
  176.     described later.
  177.  
  178. 3.1.2.  Body
  179.  
  180.     The body of the message is constructed as follows.  The payload is
  181.     first optionally encrypted using the parameters described in the
  182.     Encryption-Key field in the preamble.  Then it is encoded using the
  183.     algorithm identified in the Encoding field in the preamble.  Then it
  184.     is enclosed in the delimiters described above.
  185.  
  186. 3.2.  Appendix
  187.  
  188.     The appendix is structured as follows:
  189.  
  190.         --BEGIN STS APPENDIX--
  191.         Version: 1.0
  192.         Association-ID | Key-ID: <Value>
  193.         [Algorithm-ID: <Value>]
  194.         [Encoding: <Value>]
  195.  
  196.         <Signature>
  197.         --END STS APPENDIX--
  198.  
  199.     If the signature is to be based on an established association, then
  200.     the second header is the Association-ID field, and its value is
  201.     implementation-defined.  If, instead, the signature is based on a
  202.     key distributed in the preamble, then the second header is the
  203.     Key-ID field, and its value is the identifier assigned to the key in
  204.     the preamble.
  205.  
  206.     Normally, the Association-ID determines the signature algorithm and
  207.     encoding; if it does not, then the algorithm and encoding are named
  208.     in the optional Algorithm-ID and Encoding fields.  These two fields
  209.     are not optional in the case of in-band key distribution.
  210.  
  211.     The Signature begins with the first non-white-space character
  212.     following the last appendix header value, and ends with the last
  213.     non-white-space character before the end of the appendix.  The
  214.     structure of the Signature is dependent on the algorithm and
  215.     encoding used.
  216.  
  217. 4.  Response
  218.  
  219.     Normally, the response is sent to the initiator of the transaction
  220.     in the same way as the request.  However, this is not possible if
  221.     the STS wrapping could not be properly decoded.  In this case, the
  222.     reply indicates the error discovered in decoding the STS request.
  223.  
  224. 4.1.  Error Reply
  225.  
  226.     The STS error reply is structured exactly as the request, except
  227.     that an additional field is used to indicate the error:
  228.  
  229.         Error-ID:
  230.  
  231.     If applicable, additional information about the error is enclosed in
  232.     the body of the primary.  Currently defined errors are as follows:
  233.  
  234.         Key(s) not recognized.  (List of Key-IDs.)
  235.  
  236.         Certificate type(s) not recognized.  (List of Types.)
  237.  
  238.         Can't decode certificate(s).  (List of Key-IDs.)
  239.  
  240.         Can't extract key(s).  (List of Key-IDs.)
  241.  
  242.         Distribution algorithm(s) not supported.  (List of Algorithms.)
  243.  
  244.         Encoding(s) not supported.  (List of Encodings.)
  245.  
  246.         Body doesn't decrypt.
  247.  
  248.         Can't verify signature.
  249.  
  250.     Where shown, the message body contains the listed information.
  251.  
  252. 5.  Supported Algorithms and Types
  253.  
  254.     Currently supported certificate formats are X.509.
  255.  
  256.     Currently supported encryption algorithms are DES and RSA.
  257.  
  258.     Currently supported signature algorithms are MD5-DES, MD5-RSA,
  259.     SHA-DES, and SHA-RSA.
  260.  
  261.     Currently supported key distribution algorithms are KerberosV5.
  262.  
  263.     Currently supported encodings are BASE64, 7-BIT, and 8-BIT.
  264.  
  265. 6.  Expiration Date
  266.  
  267.     This draft expires on January 31, 1998.
  268.  
  269. 7.  Author
  270.  
  271.     Brian Tung
  272.     USC Information Sciences Institute
  273.     4676 Admiralty Way Suite 1001
  274.     Marina del Rey CA 90292-6695
  275.     Phone: +1 310 822 1511
  276.     Fax: +1 310 823 6714
  277.     E-mail: brian@isi.edu
  278.