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)]
<draft-rfced-info-cruellas-00.txt>
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