Internet-Draft Tom Arnold (CyberSource)
Category: Application Jason Eaton (CyberSource)
March 19, 1999 Michael Jimenez (CyberSource)
Expires in six months Hubert Chen (CyberSource)
Simple Commerce Messaging Protocol (SCMP)
(draft-arnold-scmp-02.txt)
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Introduction
The Simple Commerce Messaging Protocol (SCMP) is a general-purpose
commerce transport protocol for secure, real-time communication of
a set of data from a sending agent's application to a receiving
agent's server. Additionally the response by the receiving agent's
sever to the sending agent is the reply from the request 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 requests in an environment where the sending partner
is fully authenticated, and the message cannot be repudiated.
The taxonomy of the SCMP message payload is not in the scope of this
document. The SCMP protocol does not specify payload definitions 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 non-standard payload format.
The only requirement on the message payload is that it be identified to
the receiver utilizing MIME naming and formatting [MIME] and is 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
encryption, authentication and handling, these other protocols
specify the contents of the message and details how a server is to
process and respond to a given message payload.
1.1. Document Overview
This document describes SCMP from the standpoint of how trading partners
would implement a client/server request processing system via an
untrusted network connection.
In a on-line, electronic commerce environment, trading partners require
a scalable, message handling system that will meet these minimum
requirements:
1.1.1 Real-time Request and Response
A single message containing all credential and payload data is
prepared by a sending agent and sent to a receiving agent. The
receiving agent, upon verification of sender's credentials, MUST
process the payload, format a reply, and respond to the sender as
the response to the inbound connection.
1.1.2 Message Privacy
Through use of cryptographic methods, the privacy of the sender's
message payload MUST be assured should a message payload be
intercepted.
1.1.2 Message Integrity
If a message arrives in an incomplete or tampered condition from a
sending agent, the receiving agent's server MUST detect the condition,
deny message payload processing, and respond with an appropriate
error message.
1.1.3 Authentication of Sending and Receiving Agents
Messages between trading partners, as represented by sending and
receiving agents, MUST contain attributes that assure a given request
could only be from a specific trading partner.
1.1.4 Non-repudiation
When a receiving agent's server receives a request to process a payload,
the receiving agent's application SHOULD guarantee that the sender
cannot, at some later time, refute having sent the request.
Non-repudiation is defined as, the inability of either trading partner
(sender or receiver) to refute the sending of an SCMP request or SCMP
reply.
An Electronic Commerce provider will typically provide financial based
functionality such as authorization, settlement, and crediting, of credit
card accounts and/or merchant accounts. This functionality requires that
the Electronic Commerce Provider execute financial transactions on behalf
of the merchant, or trading partner. Therefore it is desirable that the
transaction directives which are given in an SCMP message are
non-refutable.
1.1.5 Payload Independence
The messaging system MUST perform consistently for all payload formats.
1.1.6 Standards Based
The messaging protocol MUST be based on proven, existing cryptography
and Internet standards.
1.1.7 Use of Standard Credentials
Standard credential formats MUST be used to maximize interoperability of
common Public Key Infrastructures.
1.1.8 Transport Independent
The message MUST be transportable over the most common Internet transport
protocols.
1.1.9 Service Level Guarantee
The receiving agent MUST guarantee a response within the time designated by
the sender, or reject the message with an appropriate error message.
1.1.10 State Independence
There MUST be no state dependency by either a sender's or receiver's
application on the messaging protocol.
1.2. Terminology
Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT
are used in conformance 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
request processing where authentication,
privacy, integrity and non-repudiation of the
requests are important. Trading partners have
established a trusted relationship between each
other.
Client An application program that executes on a remote
system, used by a trading partner to request
services from a server via an untrusted 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.
Sending Agent An entity that operates or uses a Client for
requesting on-line services from a server.
Receiving Agent An entity that operates a Server, receives and
processes requests from a plurality of Clients.
Request 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.
Message An interchangeable term used to mean a Request.
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 [PKCS-7].
An SCMP compliant server SHOULD implement the three message types as
described in [SMIME], signed, enveloped, and signed/enveloped. A SCMP
compliant server MUST implement signed/envelope message type as
described in [SMIME].
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.
In addition to the standard MIME headers, a compliant implementation
MUST define "SCMP-protocol-version" and "SCMP-sender-name". These
headers added to the outer MIME entity, as described in [SMIME].
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.
2.1 SCMP Protocol Version
The SCMP-protocol-version header is used to designate the SCMP protocol
version. Server implementations MAY reject the request based upon
protocol version, before any message processing occurs.
An example SCMP-protocol-version header will be in this format:
SCMP-protocol-version: v2.0
The possible protocol versions MUST be agreed upon by the trading
partners.
2.2 SCMP Sender Name
The SCMP-sender-name header is used to designate the SCMP sender name.
Thereby the sender name can be accessed before any decryption of the
request is performed. Server implementations MAY reject the request
based upon sender name, before any message processing occurs.
An SCMP-sender-name header will be in this format:
SCMP-sender-name: CyberSource
The possible sender names MUST be agreed upon by the trading partners.
3. SCMP Payload-based Headers
This section describes the payload-based extensions that MUST be
implemented by both the client and server to insure correct and proper
request processing.
Setting the SCMP service headers is the responsibility of the sending
agent's client application. Processing the SCMP payload headers is the
responsibility of the receiving agent's server application processing
the request.
The following headers are described for the payload of the S/MIME
entity, and MUST be prepared as defined in [MIME]. Thus if the S/MIME
message type is signed/enveloped ( which is recommended ), then the
SCMP headers will be encrypted with the sender's message payload.
3.1. Request Time to Live
This describes the amount of actual processing time in seconds the
client expects the server to complete payload processing prior to
responding with an appropriate reply.
An SCMP server receiving a SCMP message MUST evaluate the request time
to live value and determine if it can execute the required service(s)
in the amount of time designated. Assuming the server believes it can
complete the work within the allowed time, it will accept the request.
If not, the server MUST return an error to the client stating it
could not accept the request.
Once a server has accepted a request, it MUST process it until the time
to live value has been reached or until completion. If the time to live
value is reached during execution, the server MUST return an error to
the client stating that a time-out has occurred.
Application functions to insure data consistency, integrity, or
rollback after the time to live value has been exceeded will be the
responsibility of the server application. A policy on what application
actions a server will take upon exceeding a time to live value SHOULD
be published by the receiving agent operating the server.
An example of a policy in this are would be one where a receiving
agent's server will continue processing the request after a request
time to live value has been exceeded. Given this policy, a client,
having received a time-out error message, would send a "request
status message" to the server, referencing the original
scmp-request-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
time to live metric.
The time to live header will be in this format:
SCMP-request-time-to-live: 0..n (seconds)
3.2. 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.
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 requests are processed.
3.3. Request ID
A value in the format described in [822] that identifies a
specific instance of a request. Request ID's MUST be generated
by the client application, thus assuring that the scmp-request-id
is available in the event that the request cannot be sent to
the server due to errors.
An example of a request scmp-request-id is:
scmp-request-id: 0917293049096167904518
The scmp-request-id MUST be unique in the domain of a client
application and SHOULD NOT be easy to predict so as to prevent a
potential replay attack.
A client application, when preparing the scmp-request-id, SHOULD
perform a random number generation with sufficient degrees of
randomness, to ensure unpredictability, and generate a client side
time value, to ensure uniqueness of the result. These two data items
together SHOULD form the resulting scmp-request-id.
Servers MAY use a scmp-request-id as a reference and handle to the
original request during server message processing.
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. Prior to establishing trading partner relationships, the
sender and receiver MUST acquire mutually acceptable public root
certificates from the agreed upon certificate authority or authorities.
Trading partners, upon receiving or exchanging public key certificates
for the first time, SHOULD validate the certificate and certificate
chain before processing an SCMP request.
Prior to performing any application functions on a SCMP request
payload, the receiving agent's server MUST verify that the request has
been made by an authorized sender and that the sender's certificate has
not been revoked.
A server certificate revalidation policy, related to the frequency
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 POST function.
electronic mail: This will support a queued batch processing service
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 request further.
7.1.1. Message Timestamp
The time a request was sent SHOULD be derived from the standard SMIME
date header. Clients and servers SHOULD be synchronized using [NTP]
or Secure NTP.
The sender of an SCMP message MUST place the time a message was
dispatched into the SMIME header in [MIME] format.
The message timestamp SHOULD be used, in combination with the
scmp-request-id, by the server to aid in detection of a potential
replay attack.
It is recommended that servers SHOULD run a client-visible NTP server
to allow SCMP client applications to synchronize clocks as required.
7.1.2 Support for Request Non-Repudiation
Support for non-repudiation SHOULD be included in any complete SCMP
implementation, as described in the following subsections. If the
message is of signed or signed/enveloped type, the receiving
agent's server MUST implement support for non-repudiation.
7.1.2.1 Establish Trusted Trading Relationship
Prior to exchanging messages, sending and receiving agents MUST
exchange public key certificates.
7.1.2.2 Client Private Key Storage
The sending agent, maintaining a SCMP client application, MUST
maintain the private key in a secure location. Should a sending
agent loose control of their private key, they MUST notify
the receiving agent at the earliest possible time.
7.1.2.3 Client Message Signing
The client application signs SCMP messages using their private
key as described in [SMIME].
7.1.2.4 Server Processing
The receiving agent's server application evaluates the digital
signature, thereby guaranteeing that the message payload has not been
altered in transit, and that the message was, in fact, signed by a
specific trading partner (client) who possess the proper credentials.
7.1.2.5 Server Accounting
The receiving agent's server application MUST store the original signed/
encrypted message in an unprocessed state along with the timestamp for
identifying when the message was received. As the server processes the
sending agent's message, a record describing the processing steps along
with the appropriate timestamp MUST be appended to a accounting log
for the sending agent's request.
7.1.2.6 Revokation
All messages signed by a sending agent's client application in accordance
with [SMIME] and sent to a receiving agent's server SHALL be considered
non-repudiable. Repudiation occurs when the sending agent notifies
the receiving agent that the sending agent's public key certificate is
revoked. The timestamp of this revokation event MUST be the current time
at the receiving agent's server. Should a receiving agent's server
receive a request after being notified that the public key certificate
used to evaluate the sending agent's digital signature has been revoked,
this request MUST be considered invalid.
7.2. Application issues
The server MUST 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 [SMIME]. In performing this authentication process, the server MUST
validate the senders certificate and verify that the sender's
certificate is not listed in any available revocation systems.
Assuming the SCMP message's signature is valid, the server will process
requests with the appropriate service designated by the SCMP-message-type
value.
7.2.1. Request Serialization
A server MAY NOT guarantee serialized request processing. If
requests 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.2. 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. Error Detection may vary based on specific
implementation.
A server MUST be capable of detecting a duplicate scmp-request-id
and reply to the sending client application with the reply of the
original request. Duplicate request detection MUST be based on the
scmp-request-id and the distinguished name of the signer to prevent
denial of service attacks.
In the event of a duplicate request being detected the server MUST:
1) lookup the prior request
2) verify the sender is the same
3) return an appropriate error message to the client.
In the event that the three above steps fail, the server MUST return
an appropriate SCMP error message.
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. SCMP errors
MUST NOT be encrypted to permit clients to process encryption related
errors.
The format of SCMP errors is:
SCMP <error number> <error message text>
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
time to live requested (due to unspecified server or network
failure) the client SHOULD re-send the request. Upon receipt of a
duplicate request the server will respond as described in 7.2.2.
Clients MUST NOT retry a request in an interval which is less than
the time to live value of the original request.
9. Author's Address
Tom Arnold
CyberSource Corporation
550 S. Winchester Blvd., #301
San Jose, CA 95128
E-mail: toma@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
Hubert Chen
CyberSource Corporation
550 S. Winchester Blvd., #301
San Jose, CA 95128
E-mail: hubertc@cybersource.com
Phone: 408-556-9100
10. Acknowledgements
The authors wish to recognize and thank several individuals
(listed in alphabetic order) who have and continue to
support the development of requirements and improvement of
this protocol.
Mike Agostino (Vulcan), Ron Bose (LitleNet), David Burdett (Mondex),
Leonard Cantor (IBM), Dan Corcoran (Equifax), Steve Crocker
(Crocker Assoc.), Tony Curwen (Ingram Micro), Donald Eastlake (IBM),
Richard Frank (Intertrust), James Gavin (Commercenet), Paul
Guthrie (VISA International), Bengamin Hipp (FUSA/Paymentech),
Andy Jeffrey (Sonnet Financial), Helle Jespersen (IBM),
"Sean Kiewiet" <skiewiet@hypercom.com>, Connie Lindgreen (IBM),
Michael Myers (VeriSign), Allan Ottosen (PBS), John Pettitt
(Beyond.com), Jesse Rendleman (CyberSource), Don Sloan
(Tech Data), Carl Stucke (Equifax), Frank Tyksen (Portland
Software), Huy Vu (VISA USA), Sean Youssefi (CobWeb)
11. References
[822] D. Crocker, "Standard for the format of ARPA Internet
text messages." RFC 0822, IETF, Aug. 1982.
[SMIME] S. Dusse, et. al, "S/MIME Version 2 Message
Specification", RFC 2311, IETF, March 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: Cryptograpic Message Syntax"
RFC 2315, IETF, March 1998.