Internet-Draft Tom Arnold (CyberSource) Category: Security Jason Eaton (CyberSource) August 31, 1998 Michael Jimenez (CyberSource) Expires in six months Simple Commerce Messaging Protocol (SCMP) (draft-arnold-scmp-00.txt) Version 1 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 working groups. 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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Introduction The Simple Commerce Messaging Protocol (SCMP) is a general-purpose commerce transport protocol for securely communicating a set of data from a sending agent's application to a receiving agent's server. And, where the response by the receiving agent's sever to the sending agent is, in fact, the reply from the transaction represented by the set of data in the message's payload. The intent of this protocol is to define a method where trading partners can perform on-line business transactions in an environment where the sending partner is fully authenticated, and the message cannot be repudiated. The SCMP message content, hereinafter referred to as message payload, is not intended to be defined or specified. SCMP does not specify payload contents or how trading partners are expected to process the payload, beyond basic server-level functions related to processing SCMP-headers.This intent is to permit trading partners the flexibility to implement either a standard commerce message format as in ANSI-X12 Electronic Data Interchange (EDI) or some other proprietary transaction format. The only requirement on the message payload is that it be identified to the receiver utilizing MIME naming and formatting [MIME] and used to identify the type of payload contained in the SCMP data area. In this manner, SCMP fundamentally differs from many emerging commerce message protocols. Beyond specifying the method for transport, encryption, authentication and handling, these other protocols specify the contents of the message and details how a server is to process and respond to the message payload. SCMP is intended as both an on-line and batch protocol. The exact content of the message and the processing constraints are specified in SCMP-headers. 1.1. Document Overview This document describes SCMP from the standpoint of how trading partners would implement a client/server transaction processing system where a sending agent requests services via an untrusted network connection from a server-based receiving agent. In this environment, the typical requirements for authentication, non- repudiation, message integrity, and privacy as discussed in [SMIME] and assured by the proper use of the Secure/Multipurpose Internet Mail Extensions [SMIME]. Beyond this, the trading partners require service- based extensions to standard MIME and SMIME security services. These service-based extensions are described within this document, while it is assumed the trading partner will implement MIME and SMIME services as described in [MIME] and [SMIME] respectively. 1.2. Terminology Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are used in conformances to the definitions in [MUSTSHOULD]. 1.3. Definitions Several terms will be used when specifying SCMP. Trading Partners Two entities wishing to perform some on-line transaction processing where authentication, privacy, integrity and non-repudiation of the transactions are important. Client An application program that executes on a remote system, used by a trading partner to request services from a server via an un-trusted or publicly switched packet network, like the Internet. Server An application program used to process SCMP messages received from a client, and generate appropriate replies which are sent back to the client. Transaction A discrete unit of service embodied in a single SCMP message/reply pair. Payload The meaningful content provided by a client to a server, encapsulated in an SCMP message. Similarly the meaningful content provided by a server to a client, encapsulated in an SCMP message. Request An SCMP message sent from a client to a server. Reply An SCMP message sent from a server to a client. Services Algorithms implemented by the server application which are executed as designated by the payload. Each available algorithm is a service. 2. Payload Encapsulation The payload of an SCMP message MUST be prepared as a standard MIME entity as defined in the [MIME] specification. The [SMIME] document describes how the resulting MIME entity SHOULD be cryptographically enhanced according to [CMS], which is derived from PKCS #7, [PKCS-7]. An SCMP compliant server MUST implement three message types as described in [SMIME], signed, enveloped, and signed/enveloped. This document does not designate specific encryption algorithms or SMIME message types. However, it is recommended, for non-repudiation concerns that the trading partners SHOULD exchange signed or signed/enveloped SCMP message types. It is also recommended that strong enough cryptographic methods be used to insure authenticity, integrity, non-repudiation, and privacy of the payload. But, if the trading partners form a private agreement, clear data or signed-only data MAY be exchanged. However, an SCMP compliant server MUST support encryption even if encryption is not being used. 3. SCMP Service-based Headers This section describes the service-based extensions that MUST be implemented by both the client and server to insure correct and proper transaction processing. Processing the SCMP service headers is the responsibility of the application processing the request. 3.1. Quality of Service: This describes the amount of actual processing time in seconds the client expects the server to fully complete payload processing prior to responding with and appropriate error message, or reply. An SCMP server receiving a SCMP message MUST evaluate the quality of service value and determine if it can execute the required service(s) in the amount of time designated by the quality of service header. Assuming the server believes it can complete the work within the allowed time, it will accept the job. If not, it MUST return an error to the client stating it could not accept the transaction. Once a server has accepted a job, it MUST process it until the quality of service value has been reached or until completion. If the quality of service value is reached during execution, the server MUST return an error to the client stating that a timeout has occurred. Measures to ensure data integrity after the quality of service value has been exceeded will be the responsibility of the implementation. The quality of service header will be in this format: SCMP-quality-of-service: [batch | {0..n seconds}] An SCMP-quality-of-service value of "batch" MUST cause the server to respond with an acknowledgement reply to the client. The server SHOULD then process the message according to an appropriate schedule and respond to the client as appropriate after completing the actual processing. Additionally, "batch" designates that there are no "real-time" quality of service requirements for that SCMP message. 3.2 Return Path: This describes the method used to respond to the client after completion of a "batch" request. The client will not be notified upon "batch" request completion if the return path is empty. Return Path is specified as follows: SCMP-return-path: "[protocol]:[destination]" The list of protocols supported MUST be furnished via a private agreement between trading partners. Destination MUST be a valid value relative to the specified protocol. For example: SCMP-return-path: smtp/someone@host.domain 3.3. Message Type: This value specifies the type of payload that is contained in the SCMP message. The intent of this header is to provide a meta-level description of the message payload and allow a receiving server to decide which services or associated algorithms to use in processing the payload. The message type value SHOULD NOT be the sole specifier of the services being requested by a client from a server. The list of services to be performed on a specific payload SHOULD be included in the message payload. Message type is specified as follows: SCMP-message-type: "[service-name]/[version-number]" The assignment of service names MUST be provided by the server to a client at the time a service is published. For instance, if a service was published called "CommerceService", the SCMP-message-type might be represented as: "SCMP-message-type: CommerceService/1.0" It is assumed that trading partners will agree on service names before transactions are processed. Additionally servers MUST allow service names to be configurable, reguardless of what the algorithm which implements the service does. 3.4. Transaction ID: A value in the format described in [822] for the Message-ID header with the left part constrained to be a numeric value "message-number @host.domain". Transaction ID's MUST be generated by the client application. The Transaction-ID of the reply will be the inbound Transaction-ID with a "Reply-" pre-appended. An example of a request Transaction-ID is: SCMP-transaction-id: 123456789@host.somewhere.com A corresponding example reply Transaction ID would be: SCMP-transaction-id: Reply-123456789@host.somewhere.com The message-number portion of a Transaction ID's SHOULD (except as required for error recovery) be unique and SHOULD NOT be easy to predict to prevent a potential denial of service attack. A client application when preparing the message-number portion should perform a random number generation with sufficient degrees of randomness so as to insure uniqueness and unpredictability of the result. Servers MAY use a Transaction-ID as a reference and handle to the original transaction. 3.5. Additional Header Information: In addition to to the payload (inside MIME entity) headers stated in sections 3.1-3.4, use of the remaining standard SMIME (outside MIME entity) headers are assumed. This includes any additional implementation-specific headers. These headers will most likely be ones that need to be processed prior to payload decryption. 4. SCMP Data Block (Message Payload) The payload or data block can be any arbitrary data type in the format as specified by the SCMP-message-type. This payload forms the content of the SMIME message as described in [SMIME]. 5. Certificates Every trading partner implementing SCMP MUST exchange certificates that have been issued and signed by one or more mutually trusted certificate authorities (CA). These certificates are used to guarantee the authenticity of public keys. Prior to establishing trading relationships on the basis of SCMP transactions, sender and receiver MUST have acquired mutually acceptable trusted public root certificates in a trusted, secure, out-of-band manner. Trading partners, upon receiving or exchanging public key certificates for the first time, SHOULD validate the certificate and certificate chain before processing an SCMP transaction. It is also recommended that the trading partners re-validate any certificates and certificate chains on a scheduled basis. Upon establishing a relationship between trading partners, the recipient of a new certificate (the server in most cases) SHOULD validate the certificate as soon as is practically possible. Certificate re- validation policy, related to the frequency known certificates are revalidated against a certificate authority's certificate revocation list, is not specified by SCMP. This matter is left as a policy decision for the operator of the SCMP server. 6. Transport Implementations SCMP can be implemented using any variety of transport methods as agreed between trading partners. Here are a few examples. http: This delivers a SCMP message to a server URL and should use a PUT function. electronic mail: This will support a queued batch processing service diskette: SCMP message as a text file 7. Receiving Server Functions This section describes minimal server functions required to implement SCMP. 7.1. General A SCMP server receives a message from a client, processes the message and generates a reply. If the message type is signed or signed/enveloped the server initially validates the outer signature. If the outer signature is not valid the server MUST NOT process the transaction further. 7.1.1. Message Timestamp The time a transaction was sent will be derived from the standard SMIME date header. If a client is specifying a quality of service other than "batch", the client SHOULD be synchronized using [NTP] or Secure NTP. The sender of an SCMP message will place the time a message was dispatched into the SMIME header in [MIME] format. The message timestamp SHOULD be included in the SCMP payload if possible and used, in combination with the transaction ID, by the server to prevent a replay attack. It is recommended that servers run a client-visible NTP server to allow sending agents running SCMP client applications to synchronize clocks as required. 7.2. Application issues The server SHOULD evaluate the signature of the message, (if the message is of signed or signed/enveloped type ), prior to processing the message payload. Within this process the server SHOULD obtain the senders certificate via. the distinguished name in the certificate as described in [HOUSLEY]. Assuming the SCMP message's signature is valid, the server will process transactions based on the SCMP-message-type value. Transactions may be processed on-line or in batch mode, depending on the value of the SCMP-quality-of-service header. 7.2.1. Quality of Service and Time Assuming the SCMP-quality-of-service header is integer representing a number of seconds (i.e., not "SCMP-quality-of-service: batch"), the receiving server MUST determine if the quality of service is attainable. In this function, the server will evaluate if sufficient time has been allotted for the application functions to be completed. Assuming the server determines the quality of service time allotted is attainable, the server will begin processing the transaction. Once a server has started processing a transaction, the server MUST NOT terminate due to inability to meet the quality of service time value. In the event the server is unable to complete and reply within the quality of service time value, the server MUST reply to the client with a time-out error message. The server will finish processing the transaction and continue processing the next SCMP message. A client, having received a time-out error message, SHOULD send a "request status message" to the server, referencing the original SCMP-transaction-id (from the message that timed out) in the message payload. The server's reply to this status message would be the reply that would have been sent had the processing time not exceeded the quality of service metric. 7.2.2. Transaction Serialization A server may not guarantee serialized transaction processing. If transactions must be serialized, it is expected that all of the serialized transactions will be received in a single message payload or that other content specific serialization systems will be used. 7.2.3. Server Errors A server may encounter several classes of error conditions. The server MUST be capable of reporting an error as described in section 8 of this document. Detection may vary based on specific implementation. A server MUST be capable of detecting a duplicate SCMP-transaction-id and notify the sending client application of the duplicate transaction. Duplicate transaction detection MUST be based on the SCMP-transaction- id and the distinguished name of the signer to prevent denial of service attacks. Servers MUST take steps to prevent error conditions in which transaction retries overlap the original transaction processing. In this case the server MUST NOT respond to the retry until the original result is available. In the event of a duplicate transaction being detected the server MUST: 1) lookup the prior transaction 2) verify the sender is the same; and 3) return an appropriate error message to the client. 8. Protocol Level Error Messages In general SCMP does not concern itself with application level errors. Such errors MUST be returned in an SCMP reply with appropriate application specific formatting. 8.1. Format SCMP error messages are returned by a server as signed data. Errors MUST NOT be encrypted to permit clients to process encryption related errors. The format of SCMP errors is: SCMP-Error: [To do - Need to define error numbers/error message text or domains of error numbers -something like http? ] 8.2. Client Application Error Handling Client action in the case of error return is error specific and not defined. If the server fails to return any reply within twice the quality of service requested (due so unspecified server or network failure) the client SHOULD re-send the transaction. Upon receipt of the duplicate transaction the server will respond as described in 7.1.3. clients MUST NOT retry transactions in less than the quality of service interval of the original transaction. A server MAY want to provide the function to allow a client application to send a status request referencing the original transaction-ID. In this situation, a server SHOULD return the values of the reply from the original transaction request (identified by the transaction-ID). 9. Author's Address Tom Arnold CyberSource Corporation 550 S. Winchester Blvd., #301 San Jose, CA 95128 E-mail: dptom@cybersource.com Phone: 408-556-9100 Jason Eaton CyberSource Corporation 550 S. Winchester Blvd., #301 San Jose, CA 95128 E-mail: jeaton@cybersource.com Phone: 408-556-9100 Michael Jimenez CyberSource Corporation 550 S. Winchester Blvd., #301 San Jose, CA 95128 E-mail: mjimenez@cybersource.com Phone: 408-556-9100 10. Acknowledgements Several persons (in alphabetic order) have contributed, and continue to contribute significantly through their participation in an industry- based EMAP (Electronic products Messaging and Protocol) committee. Through their participation and continued support SCMP will continue to develop into a functioning, on-line Internet commerce messaging protocol. Their contributions are greatly appreciated. Ron Bose (LitleNet), Len Cantor (IBM), Hubert Chen (CyberSource), Tony Curwen (Ingram Micro), Mike Myers (Verisign), John Pettitt (Beyond.com), Jesse Rendleman (CyberSource), Don Sloan (Tech Data), Frank Tyksen (Portland Software) 11. References [822] D. Crocker, "Standard for the format of ARPA Internet text messages." RFC 0822, IETF, Aug. 1982. [SMIME] Blake Ramsdell, "S/MIME Message Specification", work in progress, IETF Internet Draft, draft-ietf- smime-msg-05.txt, Aug. 1998. [CMS] R. Housley, "Cryptograpic Message Syntax", work in progress, IETF Internet Draft,draft-ietf- smime-cms-06.txt, June. 1998. [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: Conformance Criteria and Examples", RFC 2049, IETF. [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, IETF. [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, September 1989. [PKCS-7] B. Kaliski, "PKCS 7: Cryptographic Message Syntax Version 1-5", IETF, March 1998.