INET Conferences


Conferences


INET


NDSS

Other Conferences


[INET'98] [ Up ][Prev][Next]

Merging of EDI Security Requirements with Internet Security Technologies

Kenneth W. COPELAND <kcopelan@acm.org>
U.S. Department of Veterans Affairs and Southwest Texas State University
USA

C. Jinshong HWANG <ch01@swt.edu>
Southwest Texas State University
USA

Abstract

This paper looks at the current state of protocols and standards for doing Electronic Data Interchange (EDI) over the Internet. The paper examines the work done by the second EDI working group of the Internet Engineering Task Force (IETF) as well as the work they are intending to do. The paper is significant because it allows the reader to come abreast of the latest developments in Internet protocols relating to EDI as well as learn the direction that the protocols and specifications are heading in the near term.

In February 1996 an e-mail Birds of a Feather (BOF) session was started which resurrected EDI as a topic within the IETF. The death of the previous EDI working group was not for lack of interest, but more for lack of consensus on how to proceed. The new BOF became chartered as the Electronic Data Interchange - Internet Integration (EDIINT) working group.

The paper also discusses the IETF meetings that have occurred over the life of the working group and the status of the deliverables over this timeline.

Then the Internet drafts that have been produced by the working group are discussed with particular emphasis on the requirements for accomplishing EDI over the Internet. Included is a model of the process flow for accomplishing the required security to do EDI over the Internet.

"Requirements for Inter-operable Internet EDI" was the first Internet draft produced by the EDIINT working group. This document is a functional specification, discussing the requirements for inter-operable EDI, with sufficient background material to give an explanation for the EDI community of the Internet and security-related issues.

The second Internet draft, produced by the working group, describes how to securely exchange EDI documents using MIME and public key cryptography. The document entitled "MIME-based Secure EDI" is briefly examined and discussed.

Finally, the paper briefly mentions the third Internet draft, which the working group has produced, entitled "HTTP Transport for Secure EDI." This document describes how to exchange EDI documents securely using HTTP transport for EDI data that is packaged in MIME messages using public key security body parts.

Contents

Introduction

Electronic Data Interchange (EDI) has been used in proprietary formats since the 1960s when GM, Sears, and Kmart began providing their suppliers and stores with mandated software and formats to use when doing business with them. The evolution of the EDI technologies over the past 30 years has allowed the standardization of EDI data formats to occur. Today, if two trading partners can agree on which version of which standard to use and then agree on communications protocols, they begin testing with each other and tweak their systems so that they can accomplish the required business. Each trading partner accomplishes the translation of files into standard EDI transaction formats and then transmits its EDI transactions to the other trading partner, who receives the data and translates the data from the EDI format into a user-defined format for use with existing programs. Value Added Networks (VANs) have become major players in traditional EDI, providing translation, security, communications, and storage functions for trading partners who do not want to shoulder the cost or technical difficulties of accomplishing these tasks. Until recently, the traditional method of handling EDI telecommunications had been with bisynchronous modem connections.

If a business has many trading partners, the telecommunications cost of doing business can be cumbersome. If the business sets up and maintains telecommunications with every trading partner, then the business has direct telecommunications cost and must keep technical personnel on hand who have the skills to establish and maintain the telecommunications links. If the business uses a VAN service for telecommunications, it loses some of these costs, but then the business has the additional cost of paying for each transaction that is sent through the VAN. Sometimes these transactional costs can be large. With the advent of the World Wide Web and the general awareness of the ease of using Internet telecommunications and the low costs involved in sending data over the Internet, more and more businesses are interested in the possibility of doing EDI over the Internet.

The initial interest in merging EDI and the Internet led to the formation of an EDI working group within the Internet Engineering Task Force (IETF). The working group was chartered to produce two deliverables: a technical document specifying the enveloping of EDI transaction sets in MIME envelopes and a usage document explaining how EDI should be used across the Internet.

The EDI working group of the IETF was disbanded when it made no significant progress on the second of the two deliverables that were incorporated into its charter. The EDI working group did produce RFC 1767 which was a specification of MIME content types for EDI data. The EDI working group was not able, however, to make significant progress on the second deliverable, a usage document for EDI usage on the Internet. The inability to produce this document led to the disbanding of the working group in late 1995.

It remained apparent that work still needed to be done to address the issues of security for EDI transactions over the Internet. Once security of EDI transaction sets was achieved, the issues of interoperability would still need to be addressed so that the secure transactions that were created could be used across multiple platforms and products.

Thus came about the formation of the second EDI working group. This working group has been very successful and as of this date has produced three Internet drafts that are currently progressing through the standards track to eventual status as an accepted Internet standard. The group has been in existence for 27 months and is still going strong. It recently identified a fourth deliverable that is needed and has started work on that. The HL7 contingent of the working group has also indicated that they will produce a fifth deliverable directed at the health care industry.

Charter

An IETF working group needs a charter in order to be officially sanctioned by the IETF. To this end a mailing list was started in mid-February 1996. The only deliverable that was discussed was to define the use of security and associated processes for exchanging EDI transactions in MIME in a manner that supports core, functional, transport services requirements.

The original charter proposal that was submitted to the Internet Engineering Steering Group (IESG) called for this single deliverable to be completed by the working group. The deliverable was a Requirements Document for EDI over the Internet. The IESG rejected the original charter and requested that it be changed to support the policy that proposed standards are Applicability Statements, not Requirements Documents. Compounding the problem was the fact that the Requirements Document being worked on had become lengthy and laden with background material whereas traditional IETF Applicability Statements tend to be short and concise.

In June 1996 the original charter for the Electronic Data Interchange -- Internet Integration (EDIINT) working group was accepted and the mailing list became a formal working group. The working group was assigned three deliverables as follows:

  • An Informational Document describing the requirements for interoperable EDI, with sufficient background material to give an explanation for the EDI community of the Internet-related issues;
  • An Applicability Statement describing how current Internet standards can be used to achieve this functionality for MIME and SMTP; and
  • An Applicability Statement describing how current Internet standards can be used to achieve this functionality for FTP and HTTP.

Since the first charter was approved in June 1996, it has been amended to match the interests and direction of the members of the working group. The third deliverable has been changed to reflect the fact that the real interest is not specifically in FTP or HTTP as a protocol to be used, but that real-time EDI needs to be addressed. In addition, it is felt by the members of the working group that security issues need to be addressed for EDI being done between different organizations across the Internet. The current charter as amended lists four deliverables as follows:

  • An Informational Document describing the requirements for interoperable EDI, with sufficient background material to give an explanation for the EDI community of the Internet-related issues;
  • An Applicability Statement describing how current Internet standards can be used to achieve this functionality for MIME and SMTP;
  • An Applicability Statement describing how current Internet standards can be used to achieve this functionality for FTP and HTTP; and
  • Security Issues for interorganizational EDI over the Internet.

Meeting progress

The EDIINT working group began as a mailing list in February 1996, and interest in the work was established in the IETF community immediately. The working group learned from the mistakes of the first EDI working group and strove to keep its tasks simple, focused, and manageable from the beginning. The EDIINT working group was chartered in June 1996 and although they had been scheduled to meet as a BOF session at the 36th IETF meetings in Montreal, Canada, in June 1996, their first meeting was held as an officially chartered working group.

The first meeting included over 50 interested people, which is very good for an initial meeting of this type. The basic work had already been accomplished for the first deliverable, and interoperability tests based on this deliverable were already being scheduled for October 1996. The interoperability tests were to take place under the auspices of CommerceNet, the industry consortium that promotes and develops electronic commerce solutions.

The second meeting occurred at the 37th IETF meetings in San Jose, California, in December 1996. By this time the working group had finalized the first two deliverables and had discussed the initial requirements for the third deliverable. Several issues were decided upon in San Jose and taken back to the mailing list for consensus opinion:

  • The examples showing the structure of the EDI MIME message for both S/MIME and PGP/MIME would be moved from the Applicability Statement for Secure MIME to the Requirements Document. Applicability Statements are supposed to be clear and concise and this adjustment would move 11 pages from Deliverable 2 to Deliverable 1; and
  • Try to recommend an existing protocol for adoption or extension to handle process-to-process EDI. The feeling was that the working group did not have the experience or the knowledge within the group itself to develop a protocol from scratch. If developing a new protocol became the only option, major help would be needed from more experienced IETF workers.

The EDIINT working group met for the third time at the 38th IETF meetings held in Memphis, Tennessee in April 1997. The three chartered deliverables were discussed and a fourth topic was brought to the floor as a possible area of interest that could produce a fourth deliverable.

The first deliverable, the Requirements Document, was a pretty stable document with few comments or changes being requested in the past several months. At this meeting there were no new comments on the Requirements Document. It was decided that this document was ready to be passed along as an Internet Draft.

The second deliverable, the Applicability Statement regarding secure MIME (AS#1), was also fairly stable. The only issue brought up regarding AS#1 had to do with the message disposition notification (MDN) which is being handled by the receipt working group. The MDN is the Internet messaging format used to convey a receipt. Basically, the MDN is the mechanism being recommended by the EDIINT working group to convey signed receipts.

The third deliverable, the Applicability Statement regarding secure HTTP (AS#2), had a lot of work to be done on it. Although HTTP was the protocol most generally associated with AS#2, the general consensus was that process-to-process EDI was more indicative than HTTP when trying to categorize the direction of this work. FTP needed to be examined for the possibility of transferring very large files. Although HTTP most generally comes to mind as the protocol most likely to be able to handle real-time transactions, HTTP through firewalls presents security problems. This discussion stimulated interest on what began to become a fourth topic area, interorganizational security issues.

The working group did not meet at the 39th IETF meetings in Munich, Germany.

The EDIINT working group met for the fourth time at the 40th IETF meetings held in Washington, DC in December 1997. By this time the working group had three Internet Drafts in the standards track, those being the first three deliverables that were chartered. It was also pointed out that there was a problem with the first two deliverables because they both reference S/MIME and there is an unresolved issue in that there is not yet any standards track message security technology that can be referenced as mandatory to implement. Because of this, the first two deliverables were sent to the experimental request for comments (RFC) track as a holding action until the S/MIME issue is resolved one way or another.

Attendees representing the health care industry (HL7) brought up the work that is being done specific to that industry. The HL7 people indicated that they would soon have an Internet Draft for this working group relating to the health care industry.

A presentation was made on the work being done to finalize the third deliverable, Secure HTTP. The draft standard closely paralleled the SMTP draft with changes made only in sections where change was necessary and a test implementation of Secure HTTP was ongoing. A serious problem that was being noted in the implementation of Secure HTTP was that the Microsoft Exchange servers tend to time-out if the response takes too long. This may make the HTTP protocol inappropriate for process-to-process EDI.

Internet Drafts

The EDIINT working group currently has three standards track deliverables that are in Internet Draft status. Although the fact that the documents are in draft status indicates that they are fairly stable, it is not recommended that drafts be referenced when writing papers or doing research because they are highly likely not to be in final form. Drafts have a maximum expiration date of six months; if the draft is not updated by the expiration date, it is deleted. After having been in draft status and commented on for a sufficient period, drafts will be promoted to RFC status or deleted as the case requires.

Requirements for interoperable Internet EDI

Encryption

Encryption is required to provide confidentiality of the data being transmitted. Pricing information, bids, proprietary information, and the like are examples of information that a trading partner may want to guard from its competitors or even from casual readers. During transport on the Internet, any transmitted data may travel through multiple hops to reach its destination. At each one of these hops the data actually passes through a node (computer) on the Internet and is routed to the next hop. At any given node, it is possible to read and/or copy the data that passes through the node. The idea behind encryption is to put the data into an unreadable form while the data is being transported between trading partners. If the data is read or copied en route, it will be impossible for the transgressor to understand the encrypted data.

The recommended methodology for use of encryption is to use symmetric key encryption for confidentiality of the EDI transaction set itself. A symmetric key should only be used one time, for one EDI transmission, and then discarded. The reason for the choice of symmetric keys for bulk encryption is that symmetric key algorithms are considerably faster than asymmetric key algorithms. The larger the data file to be encrypted, the more the savings by using symmetric key algorithms. Once the EDI transaction set is encrypted, asymmetric keys can then be used to encrypt the symmetric key, to encrypt the Message Integrity Check (MIC), and to apply the digital signature.

Several symmetric encryption algorithms are recommended for use in EDI applications over the Internet. DES, Triple DES, RC2, RC5, and IDEA are all recommended for commercial use, depending on the circumstances and needs of the user. The key to the encryption requirement is that both trading partners in an EDI exchange must agree upon the encryption algorithm and the key lengths beforehand or within an individual transaction.

Key management: symmetric keys

The recommended method for managing symmetric keys is to generate a symmetric key for each EDI transaction. Public key cryptography is then applied to manage the symmetric keys. RSA is the de facto standard for a public-key encryption algorithm and is recommended for use in managing symmetric keys.

Key management: public and private keys

The RSA encryption algorithm has already been recommended for encrypting symmetric keys, but here the requirement is added that support of 512-bit to 1024-bit variable key lengths is a must when using the RSA encryption algorithm. It is recommended that for EDI transactions requiring the use of RSA encryption to protect symmetric keys that at least a 768-bit RSA encryption key be used. For high-value transactions it is recommended that at least a 1024-bit key be used.

Private keys are protected by internal policies that are specific to the organization generating the private keys. Any unauthorized access to private keys means that the value of the key is lost and the corresponding public key needs to be revoked.

Management of public keys is a more difficult problem to solve. Long-term solutions will slowly be developed and as standards develop for public key management and digital certificates, they need to be integrated into the Internet EDI standards. Over the short term, EDI trading partners will need to use self-certification methods to ensure that public keys can be exchanged. This will normally become a part of the process of establishing a trading partnership. It is still recommended that trading partners acquire a X.509v3 certificate from a certificate authority trusted by both parties. It is also recommended that trading partners exchange certificates using the formats and protocols specified by "certificate-only" PKCS7 when using S/MIME, and PGP certificate formats when using PGP/MIME.

Content integrity

Content integrity is required to assure the receiving trading partner that the EDI Interchange received is exactly as it was when it was sent with no changes. This is normally accomplished by a Message Integrity Check (MIC), which is simply the result of a one-way hash algorithm applied to the EDI Interchange and the MIME content headers. The resultant MIC is then sent to the trading partner along with the EDI Interchange. The receiving trading partner then applies the same one-way hash algorithm to the EDI Interchange and MIME content headers to produce a second MIC. The two MICs are then compared and if they are identical, the content integrity has been maintained.

The only real issue is which one-way hash algorithm is to be used to provide adequate security. It is understood that the algorithm must be publicly available and it should produce a hash value of at least 128 bits.

The recommendation for EDI over the Internet is that all new implementations use the Secure Hash Algorithm (SHA-1). Since many existing implementations already use the MD5 algorithm, existing implementations that support MD5 should continue this practice.

Authentication and nonrepudiation of origin

A digital signature can be used to authenticate the sender of a given message. Digital signatures require the application of a private key to a message to produce an encrypted message. The encrypted message can then be decrypted only by the user's public key. Anyone who uses a public key to decrypt the message has then proven the identity of the person who encrypted the message. Since the only person who has the private key is the owner of the private key, nonrepudiation of origin is accomplished on any message encrypted by a private key and decrypted with the public key.

It is recommended that the RSA public-key algorithm be used for digital signatures. The recommended key length for keys to accomplish the digital signature is 768 bits. For high value transactions the recommended key length is 1024 bits.

Signed receipt and nonrepudiation of receipt

Digitally signed receipts are necessary to establish nonrepudiation of receipt. The digitally signed receipt establishes that the EDI Interchange was in fact received, the sender was authenticated, and the integrity of the message was verified. When the sender verifies the identity of the signature in the receipt, nonrepudiation of receipt has been established.

The EDI community has a legal need to track and log transactions so that audit trails can be followed in the event a dispute arises. For that reason, the signed receipt can be used for tracking, logging, and reconciliation purposes. By returning the message ID and a MIC in the signed receipt, the receiver also can acknowledge to the sender that the message contents are correct.

Since a receipts working group already exists within the IETF, the EDIINT working group will work with the receipts working group to ensure that the needs for EDI receipts are met. This work will then be adopted as the basis for the implementation of signed receipts in EDI over the Internet.

Signed receipt implementations will need to incorporate configurable retransmission timers and retry counters to detect lost EDI Interchanges. Any duplicates should then be discarded by the software.

The implementation of the signed receipt must incorporate a MIME multipart/signed type/subtype with the MDN for the first part of the content of the multipart/signed. An MIC is then calculated over the MDN and the MIC is digitally signed and returned as the required second part of the multipart/signed.

Syntax and protocol for specifying cryptographic services

Encryption algorithm information, symmetric keys, one-way hash algorithm information, initialization vectors, one-way hash values, and public key certificates need to be enveloped and sent along with EDI Interchanges that have security applied to them. Both S/MIME and PGP/MIME fulfill the requirements assigned by the EDIINT working group. If using S/MIME, then it is required that multipart/signed formats of S/MIME be supported. The S/MIME signedData format is only recommended for sending EDI through known gateways that do not honor 7-bit transfer encoding.

Security methodologies covered by the EDIINT working group

The following is a step-by-step methodology to clarify what is covered in the Internet Draft. This section is not included in the draft but helps to clarify the way the security items all come together.

Sender

  1. Apply SHA-1 one-way hash to message to produce a MIC to provide content integrity.
  2. Encrypt the MIC with the sender's private key to provide a digital signature for authentication and nonrepudiation of origin.
  3. Encrypt the digitally signed MIC and the message text using a symmetric key to provide confidentiality.
  4. Obtain the recipient's public key and verify the digital certificate with an agreed-upon CA providing proof that only the recipient can decode what is coded with the public key.
  5. Encrypt the symmetric key with the recipient's public key so that only the recipient can decode the message.
  6. Package the security pieces and the request for a signed receipt to establish nonrepudiation of receipt.

Recipient

  1. Unpackage the security pieces and the receipt request.
  2. Decrypt the encrypted symmetric key with the recipient's private key.
  3. Use the decrypted symmetric key to decrypt the encrypted message and the encrypted MIC.
  4. Obtain the sender's public key and verify the digital certificate with an agreed-upon CA guaranteeing the identity of the sender.
  5. Decrypt the MIC with the sender's public key, establishing authentication and nonrepudiation of origin.
  6. Apply the SHA-1 one-way hash algorithm to the message, generating an MIC.
  7. Compare the just-generated MIC with the MIC that was generated by the sender, establishing content integrity.
  8. Package the MDN as the first part and then the SHA-1 one-way hash value of the MDN, encrypted with the recipient's private key, as the second part of a MIME multipart/signed type/subtype. This will guarantee that the message was received and produce a digitally signed receipt.

Sender

  1. Using the recipient's public key, decrypt the MIC that is in part two of the multipart/signed, establishing nonrepudiation of receipt.
  2. Generate an MIC over the MDN contained in part one of the multipart/signed.
  3. Compare the just-generated MIC with the MIC sent by the recipient to establish content integrity.

MIME-based secure EDI

This document describes how to securely exchange EDI documents using MIME and public key cryptography.

The security needs of EDI over the Internet should allow for users to send EDI data in any combination of the following:

  • Encrypted or unencrypted data
  • Signed or unsigned data
  • Use of receipt or not

Allowing for all eight possible combinations of those choices leaves the following possible security configurations:

  1. Sender sends unencrypted and unsigned data and does NOT request a receipt.
  2. Sender sends unencrypted and unsigned data and requests a signed or unsigned receipt. The receiver sends back the signed or unsigned receipt.
  3. Sender sends unencrypted and signed data and does NOT request a receipt.
  4. Sender sends unencrypted and signed data and requests a signed or unsigned receipt. The receiver sends back the signed or unsigned receipt.
  5. Sender sends encrypted and unsigned data and does NOT request a signed or unsigned receipt.
  6. Sender sends encrypted and unsigned data and requests a signed or unsigned receipt. Receiver sends back the signed or unsigned receipt.
  7. Sender sends encrypted and signed data and does NOT request a signed or unsigned receipt.
  8. Sender sends encrypted and signed data and requests a signed or unsigned receipt. Receiver sends back the signed or unsigned receipt.

The remainder of this Internet Draft discusses how to attain those possible configurations by addressing the encryption and signature issues with existing RFCs and Internet Drafts. The receipt issues are also addressed, including how to request a signed receipt, the format of the MDN, and MDN processing.

HTTP transport for secure EDI

This Internet Draft describes how to exchange EDI documents securely using HTTP transport for EDI that is packaged in MIME messages using public key security body parts. This draft follows closely the SMTP draft, making changes only when they are necessary to convert the SMTP-based recommendations to the HTTP protocol.

Conclusion

This working group has accomplished far more in its 25 months of existence than the first EDI working group accomplished in 22 months. This working group has always scoped its e-mail list activity and its goals to manageable size and proceeded from one topic to the next in a timely and organized manner. The working group is still going strong with three standards track documents already published as Internet Drafts and at least two more coming soon. The technical work has also built on existing technical standards rather than trying to reinvent the wheel. This approach has allowed the working group to be very productive even though the working group as a whole is not an experienced one. The marriage with CommerceNet to test the standards has proven to be beneficial to the standards process.

References

  1. Internet Engineering Task Force, Proceedings of Meetings, http://www.ietf.org/proceedings/
  2. Internet Engineering Task Force, Working Groups, http://www.ietf.org/html.charters/wg-dir.html
  3. Internet Engineering Task Force, Archived EDIINT Working Group E-mail Listings, February 1996 - December 1996, http://www.imc.org/ietf-ediint/archive1/
  4. Internet Engineering Task Force, Archived EDIINT Working Group E-mail Listings, January 1997 - Present, http://www.imc.org/ietf-ediint/mail-archive/

[INET'98] [ Up ][Prev][Next]