[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AS3 Discusion - Overview
Open for discussion
2.0 Overview
2.1 Overall Operations
A FTP upload operation is used to send appropriately-packaged EDI,
XML, or other business data. The receiving application will poll
the FTP server for inbound messages, unpackage and handle the message
data and generate a reply for the originator that contains a
message disposition acknowledgement within a multipart/report that is
signed or unsigned. This request/reply transactional interchange
provides secure, reliable, and authenticated transport for EDI or
other business data using FTP. The security protocols and structures
Harding, Scott [Page 3]
INTERNET DRAFT FTP Transport Data for EDIINT April 2005
used also support auditable records of these transmissions.
2.2 Purpose of a security guideline for MIME EDI
The purpose of these specifications is to ensure interoperability
between B2B Electronic Commerce user agents, invoking some or all of
the commonly expected security features. This document is also NOT
limited to strict EDI use, but applies to any electronic commerce
application where business data needs to be exchanged over the
Internet in a secure manner.
2.3 Definitions
2.3.1. Terms
EDI Electronic Data Interchange
EC Business to Business Electronic Commerce
B2B Business to Business
Receipt The functional message that is sent from a
receiver to a sender to acknowledge receipt of
an EDI/EC interchange.
Signed Receipt A receipt containing a digital signature.
Message Disposition The Internet messaging format used to convey a
Notification (MDN) receipt. This term is used interchangeably with
receipt. A MDN is a receipt.
Non-repudiation of NRR is a "legal event" that occurs when the
receipt (NRR) original sender of an EDI/EC interchange has
verified the signed receipt coming back from the
receiver. NRR IS NOT a functional or a technical
message.
S/MIME A format and protocol for adding Cryptographic
signature and/or encryption services to Internet
MIME messages.
NOTE: While the S/MIME specification describes
more than one format for a signed message,
all signed messages or receipts used with
AS3 MUST utilize the multipart/signed
format.
SHA-1 A secure, one-way hash algorithm used in
conjunction with digital signature. SHA-1 is the
recommend algorithm for AS3.
MD5 A secure, one-way hash algorithm used in
conjunction with digital signature. This
algorithm is acceptable but not recommended
due to its short key length and known weaknesses.
Harding, Scott [Page 4]
INTERNET DRAFT FTP Transport Data for EDIINT April 2005
MIC The message integrity check (MIC) is a
representation of the message digest, which
results from the application of the selected hash
algorithm to the content to be signed. Of
particular interest is the the digital signature,
which includes an encrypted copy of the digest.
Additionally, an MDN containing a
Received-Content-MIC" header will also contain
(as that header's value) a base-64 encoded
representation of the digest.
User Agent (UA) The application that handles and processes the
AS3 request.
STL Secure Transmission Loop, described in the next
section
2.3.2 The Secure Transmission Loop
This document's focus is on the formats and protocols for exchanging
EDI/EC content to which security services have been applied using
the File Transmission Protocol (FTP) as the transport.
The "Secure Transmission Loop" (STL) comprises the following two
steps:
a) The originator sends a signed and encrypted document with a
request for a signed receipt.
b) The recipient decrypts the document, verifies the signature,
and returns a signed receipt to the sender.
In other words, the following events occur during the execution of
the
STL:
- The organization sending EDI/EC data signs and encrypts the data
using S/MIME. In addition, the message will request a signed
receipt to be returned to the sender of the message.
- The receiving organization decrypts the message and verifies the
signature, resulting in verified integrity of the data and
authenticity of the sender.
- The receiving organization then returns a signed receipt, as
requested to the sending organization in the form of a message
disposition notification. This signed receipt will contain the
hash of the signature from the received message, indicating to
the sender that the received message was verified and/or
decrypted properly.
The above describes functionality which, if implemented, will
satisfy all security requirements and provide non-repudiation of
receipt for the exchange. While trading partners will usually want
to utilize the STL, this specification does not require it.
2.3.3 Definition of Receipts
Harding, Scott [Page 5]
INTERNET DRAFT FTP Transport Data for EDIINT April 2005
The term used for both the functional activity and the message for
acknowledging delivery of an EDI/EC interchange is "receipt" or
"signed receipt". The term receipt is used if the acknowledgment
is for an interchange resulting in a receipt which is NOT signed.
The term signed receipt is used if the acknowledgment is for an
interchange resulting in a receipt which IS signed. A term often
used in combination with receipts is non-repudiation of receipt.
NRR refers to a legal event which occurs only when the original
sender of an interchange has verified the signed receipt coming back
from the recipient of the message. Note that NRR is not possible
without signatures.
For additional information on formatting and processing receipts
in AS3, refer to section 7.
2.4 Operational assumptions and options
2.4.1 EDI/EC process assumptions
- Encrypted object is an EDI/EC Interchange
This specification assumes that a typical EDI/EC interchange is the
lowest level object that will be subject to the application of
security services.
Specifically, for EDI ANSI X12, the entire document (including
the ISA and IEA segments) is the atom to which security is applied.
For EDIFACT, the corresponding definition includes segments UNA/UNB
and UNZ. In other words, EDI/EC interchanges including envelope
segments remain intact and unreadable during secure transport.
- EDI envelope headers are encrypted
Congruent with the above statement, EDI envelope headers are
NOT visible in the MIME package. In order to optimize routing
from existing commercial EDI networks (called Value Added Networks
or VANs) to the Internet, work may need to be done in the future to
define ways to extract some elements of the envelope to make
them visible; however, that is beyond the scope of this
specification.
- X12.58 and UN/EDIFACT security considerations
The most common EDI standards bodies, ANSI X12 and EDIFACT, have
defined internal provisions for security. X12.58 is the security
mechanism for ANSI X12 and AUTACK provides security for EDIFACT.
This specification DOES NOT dictate use or non-use of these
security
standards. They are both fully compatible, though possibly
redundant, with this specification.
2.4.2 Process options
2.4.2.1 Security options
- Encrypted or un-encrypted data
Harding, Scott [Page 6]
INTERNET DRAFT FTP Transport Data for EDIINT April 2005
This specification allows for EDI/EC message exchange where the
EDI/EC data can be either un-protected or protected by means of
encryption.
- Signed or unsigned data
This specification allows for EDI/EC message exchange with or
without digital signature of the original EDI transmission.
- Use of receipt or not
This specification allows for EDI/EC message transmission with or
without a request for receipt notification. If a signed receipt
notification is requested however, a MIC value is REQUIRED as
part of the returned receipt, unless an error condition occurs
which
results in the inability to compute a valid digest. (Such a case
would result, for instance, if an encrypted message could not be
decrypted.) Under such circumstances, an unsigned receipt (MDN)
SHOULD be returned with the correct "disposition modifier" error
value.
- Security Formatting
This specification relies on the guidelines set forth in
RFCs 2630 [9] and 2633 [10]. The first of these RFCs describes the
Cryptograpic Message Syntax (CMS) and the second contains the
S/MIME
Version 3 Message Specification describing a MIME container for
CMS objects. Whenever the term S/MIME is used in this document,
it refers to Version 3 as described therein.
- Hash function, message digest choices
When a signature is used, it is RECOMMENDED that the SHA-1 hash
algorithm be used for all outgoing messages; however, both MD5
and SHA-1 MUST be supported for incoming messages.
- Permutation Summary
In summary, the following twelve security permutations are possible
in any given trading relationship:
1. Sender sends un-encrypted data, does NOT request a receipt.
2. Sender sends un-encrypted data, requests an unsigned receipt.
The receiver sends back the unsigned receipt.
3. Sender sends un-encrypted data, requests a signed receipt. The
receiver sends back the signed receipt.
4. Sender sends encrypted data, does NOT request a receipt.
5. Sender sends encrypted data, requests an unsigned receipt. The
receiver sends back the unsigned receipt.
6. Sender sends encrypted data, requests a signed receipt. The
Harding, Scott [Page 7]
INTERNET DRAFT FTP Transport Data for EDIINT April 2005
receiver sends back the signed receipt.
7. Sender sends signed data, does NOT request a receipt.
8. Sender sends signed data, requests an unsigned receipt.
Receiver
sends back the unsigned receipt.
9. Sender sends signed data, requests a signed receipt. Receiver
sends back the signed receipt.
10. Sender sends encrypted and signed data, does NOT request a
receipt.
11. Sender sends encrypted and signed data, requests an unsigned
receipt. Receiver sends back the unsigned receipt.
12. Sender sends encrypted and signed data, requests a signed
receipt. Receiver sends back the signed receipt. This case
represents the Secure Transmission Loop described above.
2.4.2.2 Compression options
The AS3 specification supports compression of transmitted data
directly
through the application of RFC 3274. Implementation details may be
found in that RFC and in Harding's draft, "Compressed Data for
EDIINT",
currently on a parallel standards track.
Terry Harding
Cyclone Commerce Inc.