INTERNET DRAFT EXPIRES OCT 1998 INTERNET DRAFT J. Cruellas & T. Dosdale INTERNET-DRAFT UPC & Axiom Services Category: Informational April 1998 Expires 31 October 1998 EDIFACT-S [EDIFACT Security (Batch)] 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 its 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." 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). Distribution of this document is unlimited. Abstract The aim of this document is to raise awareness about the built in security features of batch EDIFACT, for use when transmitted over any type of network. It is not intended to reproduce the syntax, which is documented elsewhere, nor is it intended to be a full tutorial on EDIFACT, data security, or EDIFACT security. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved # Cruellas & Dosdale Informational [Page 1] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 Table of Contents 1. Overview............................................................2 2. EDI Security Requirements...........................................3 3. EDI over the Internet...............................................3 4. EDIFACT Security....................................................4 4.a Security Header and Trailer Groups.................................5 4.b AUTACK Message.....................................................6 4.c KEYMAN Message.....................................................7 5. Summary.............................................................8 6. Security Considerations.............................................9 7. References..........................................................9 8. Authors' Addresses..................................................9 9. Full Copyright Statement...........................................10 # Cruellas & Dosdale Informational [Page 2] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 1. Overview Electronic Data Interchange For Administration, Commerce And Transport (EDIFACT) is an ISO standard syntax (ISO 9735) for transferring structured data between organisations [1]. In batch mode, data is transmitted in an interchange which is composed of one or more messages conveying the individual transactions in each message body. Additionally, messages may be arranged into groups within an interchange, which may be used for internal routing within an organisation. EDIFACT may be used by any organisation to design application messages according to the syntax. The United Nations has a trade group which specifically develops messages for international use. These messages and their component parts (segments, composite data elements, simple data elements and codes) are published on a regular basis in a directory, and referred to as UN/EDIFACT. There are currently over 200 messages defined in UN/EDIFACT, covering a wide variety of enterprise. As the EDIFACT syntax progressed different versions of the ISO standard were released. Version 1 was defined in 1988, a minor amendment appeared as version 2 in 1990, and character sets were extended by a new annex published in 1992 as version 3. During this time, business requirements for cryptographic security were identified, and the security group of UN/EDIFACT developed a draft security standard for use with version 3 [2], which was approved by the UN trade group for trial use in 1994. It has been used successfully by many organisations internationally in the intervening period. Based upon the experience and feedback from version 3 security implementations, security structures have been incorporated into the new version 4 of the EDIFACT syntax, due to be released as an ISO standard during 1998. The purpose of this document is to describe at a high level the features of EDIFACT version 4 batch security. The latest copies of these documents may be found at http://www.email.demon.co.uk/sjwg/sjwg.htm. The new version of the syntax also incorporates a syntax for interactive EDI, in which two interleaved interchanges create a session between two organisations, following which messages may be exchanged interactively. Security is also in an advanced state of development for this part of the syntax, but is in a later phase of the standard and is not described here. # Cruellas & Dosdale Informational [Page 3] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 2. EDI Security Requirements The security requirements for batch EDI are similar to those for any data in transmission between a sender and a recipient. Security services must be available to counter a number of threats: Threat Service Messages may be intercepted and modified Integrity Messages may be lost or replayed Sequence Integrity Messages may be read by a third party Confidentiality A third party may masquerade as the sender Authentication The sender may deny sending a message Non-repudiation of origin The recipient may deny receiving a message Non-repudiation of receipt These services need to be supported by a cryptographic key and certificate management service. It should be noted that EDIFACT security provides only the mechanism to carry security information, using existing security techniques. It does not constitute any new techniques or algorithms. 3. EDI over the Internet There are several mechanisms to carry EDI information over the Internet. It may be carried simply as the contents of an email, since the most commonly used character set consist only of printable ASCII characters. It may also be carried as a MIME message of content-type eg Application/EDIFACT [3][4], or UUENCODEd. FTP may be used to transfer files containing EDI interchanges, and EDI interchanges can be generated and transmitted by web browsers from suitable web pages containing web forms and/or program code. Such transmissions may, of course, be secured by any of the Internet security mechanisms such as S/MIME, PEM [5] or MOSS [6] for email, or SSL or S-HTTP for HTML. It is not the intention here to compare these security mechanisms with those built into EDIFACT. Each will have its uses depending on the usage scenario. Rather the features of EDIFACT security are presented so that potential users are well informed of its capabilities. # Cruellas & Dosdale Informational [Page 4] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 4. EDIFACT Security The new version 4 of the EDIFACT syntax is split into several parts. Part 1 presents syntax rules common to all parts, whilst Part 2 deals with rules specific to batch EDI and Part 3 with rules specific to interactive EDI. Part 4 defines the CONTRL message, which is used to acknowledge or reject, with error indication, elements of the syntax. Part 8 defines the syntactical method for carrying what is referred to as associated data objects(ie binary or other data which does not conform to the EDIFACT syntax) in packages within the EDIFACT interchange. The remaining parts deal with security, and are described in more detail in the following sub-sections. The security services identified as requirements in section 2 may be provided the following security structures: Integrity Security Header and Trailer Groups * Sequence Integrity Security Header and Trailer Groups * Confidentiality Security Header and Trailer Groups Authentication Security Header and Trailer Groups * Non-repudiation of origin Security Header and Trailer Groups * Non-repudiation of receipt AUTACK Message Key and certificate management KEYMAN Message * The AUTACK message may also be used, where there are business or other requirements, to provide separately these security services. All encryption and compression algorithms, modes of operation, parameters and padding mechanisms are identified by code values, and no recommendation is made regarding the use of these. The existing code lists are quite extensive, and new techniques may be added as they become available. Apart from data encrypted for confidentiality (and objects), any binary values which do not belong to the character set of the interchange must be filtered to produce valid interchange characters, and these filter functions are also identified by a code value. Certificates used to authenticate public keys used in asymmetric cryptography may be X.509 or the EDIFACT certificates used in the EDIFACT community today, as well as the peer level certificates for PGP. Because they consist of parseable EDIFACT segments, EDIFACT certificates may accompany the data being protected or they may be conveyed using the KEYMAN message (see section 5). X.509 or PGP certificates may be carried as binary objects in EDIFACT packages. Any type of certificate may also be conveyed using other mechanisms or networks. # Cruellas & Dosdale Informational [Page 5] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 4.a Security Header and Trailer Groups Part 5 of the syntax describes the use of groups of segments (EDIFACT building blocks consisting of related data elements) as security headers and trailers at interchange, group (ie groups of messages) and message levels. These header and trailer groups are the core of EDIFACT security and provide the security services of: - authentication - integrity - sequence integrity - non-repudiation of origin. Part 7 of the syntax describes the use of additional data encryption header and trailer segments at interchange, group (ie groups of messages) and message levels. These header and trailer segments provide the security service of: - confidentiality. In BNF notation, these security header and trailer groups occur as follows: Interchange = [Service_string_advice], Interchange_header, [Security_header_group, Data_encryption_header], 99*[Security_header_group], (Group, {Group} | (Message | Package), {Message | Package}), 99*[Security_trailer_group], [Data_encryption_trailer, Security_trailer_group], Interchange_trailer; Group = Group_header, [Security_header_group, Data_encryption_header], 99*[Security_header_group], (Message | Package), {Message | Package}, 99*[Security_trailer_group], [Data_encryption_trailer, Security_trailer_group], Group_trailer; Message = Message_header, [Security_header_group, Data_encryption_header], 99*[Security_header_group], Message_body, 99*[Security_trailer_group], [Data_encryption_trailer, Security_trailer_group], Message_trailer; Package = Object_header, [Security_header_group, Data_encryption_header], 99*[Security_header_group], # Cruellas & Dosdale Informational [Page 6] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 Object, 99*[Security_trailer_group], [Data_encryption_trailer, Security_trailer_group], Object_trailer; The security header group identifies the security service being provided, its scope (for example two digital signatures may each independently apply to the same message, or the second may sign both the message and the first signature), whether a secure acknowledgement is required, the security parties involved, a security sequence number, a security date and time, and the security techniques being used. Many of these elements are optional. Additionally, the security header group may convey one or two certificates or certificate references relating to the security sender and/or recipient. The security trailer group carries the cryptographic result, such as a digital signature or Message Authentication Code (MAC), relating to the technique and service described in the corresponding security header group. There may be up to 99 such security header/trailer group pairs, allowing, for example, multiple digital signatures on one message, such as might be found with multiple human signatures on a high value corporate cheque in the paper world. The data encryption header contains the length of the encrypted data and, optionally, the number of padding bytes used. The length of encrypted data is needed since the information is no longer parseable by an EDIFACT translator. The data may have been compressed before encryption, and may be filtered after encryption, if the transmission network is not capable of conveying 8 bit binary information. The data encryption header must be preceded by a security header group describing the security service, as well as the techniques and parties involved and any other relevant details. The data encryption trailer also contains the length of the encrypted data. It must be followed by a security trailer group, which will contain only the reference to the corresponding security header group. 4.b AUTACK Message Part 6 of the syntax describes the use of this EDIFACT service message to provide the non-repudiation of receipt security service identified as a requirement in section 2. The AUTACK message consist of two types of segment, the first of which identifies the EDIFACT interchange, group, message or package being acknowledged, whilst the second (repeated up to 9 times) contains the corresponding original cryptographic result(s). These segments may be repeated up to 9999 times, allowing many acknowledgements in one AUTACK message. This message is then digitally signed by the original recipient using the standard security header and trailer groups, and # Cruellas & Dosdale Informational [Page 7] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 send back to the original sender to provide them with non-repudiation of receipt. Similarly receipt authentication may be provided by using a MAC instead of a digital signature. Negative acknowledgement may also be provided, if appropriate, in the case of a security error, and the error may be identified, again if appropriate. The AUTACK message has an auxiliary use where there are business or other requirements to provide separately the security services of integrity, authentication or non-repudiation of origin for an interchange, group, message or package. For example, some banks transmit payment data overnight, when telecommunications rates are low, then authorise, and consequently authenticate, the transactions the next day. In this case, the first of the AUTACK segments refers to the original transmission, and the second segment(s) carries the related cryptographic results(s). The normal security header groups carry all the information relevant to obtaining the corresponding cryptographic result(s), whilst the security trailer groups carry no cryptographic results. Again, up to 9999 references may be made in one AUTACK message. 4.c KEYMAN Message Part 9 of the syntax describes the use of this EDIFACT service message to provide key and certificate management to support the security services identified in section 2. The KEYMAN message consists of a number of segments which identify the key or certificate management function being carried out, identify the status of a key or certificate, and convey keys or certificates. The whole message can be protected by the normal security header and trailer segment groups, where appropriate. It should be noted the message exists only to carry information relating to the management of keys and certificates, and does not constitute any new key or certificate management methodology. The management functions available for certificates cover: - certificate request - certificate path (of up to 9 certificates) request - renewal request - replacement request - revocation request - certificate delivery - certificate path (of up to 9 certificates) delivery - certificate revocation list delivery. The management functions available for keys cover: - key request - key discontinuation # Cruellas & Dosdale Informational [Page 8] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 - key delivery. Other management function are available, for example relating to: - registration - certificate alert - certificate revocation confirmation - key discontinuation acknowledgement. There may be up to 999 occurrences of functions within a KEYMAN message, and up to 99 certificate revocation lists, each with up to 9999 certificates. 5. Summary EDIFACT security addresses all the major requirements for EDI security, including non-repudiation of receipt, multiple digital signatures and compression before encryption. The method is independent of any underlying network and protocols, and secured EDIFACT data can be sent intact over any combination of diverse networks. It also provides a mechanism for carrying the information relating to the management of the corresponding keys and certificates. EDIFACT security permits the protection of the contents of an interchange, but also the contents of individual messages or groups, with the possibility of using different (or no) security on each one. EDIFACT security stays with the data up to the input to the security module of the EDIFACT translator, and can therefore be audited together with the data it protects, at message level if it is required to audit each transaction separately. # Cruellas & Dosdale Informational [Page 9] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 6. Security Considerations This entire document is about security. 7. References [1] ISO 9735 : 1988-92 Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules [2] UN/TRADE/WP.4/R.1026 : 1994 Security for UN/EDIFACT message transfer [3] RFC 1521-2 : 1993 MIME (Multipurpose Internet Mail Extensions) [4] RFC 1767 : 1995 MIME encapsulation of EDI objects [5] RFC 1421-4 : 1993 Privacy enhancement for Internet electronic mail [6] RFC 1848 : 1995 MIME Object Security Services 8. Authors' Addresses Prof. Juan-Carlos Cruellas-Ibarez Universitat Politecnica deCatalunya c/. Gran Capita, s/n - Modul D6.105 Barcelona Spain Phone: +34 3 401 6790 Fax: +34 3 401 7055 EMail: cruellas@ac.upc.es Dr. Terry Dosdale Axiom Services Limited 3 Holt Park Rise Leeds LS16 7QZ UK Phone: +44 113 230 1910 Fax: +44 113 230 1910 EMail: axiom@email.demon.co.uk # Cruellas & Dosdale Informational [Page 10] INTERNET-DRAFT EDIFACT Security (Batch) April 1998 9. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." INTERNET DRAFT EXPIRES OCT 1998 INTERNET DRAFT