- Email: [email protected]
Security in value added networks - security requirements for EDI
Computer Standards & Interfaces 12 (1991) 23-33 North-Holland
23
Security in value added networks- security requirements for EDI Borka Jerman-Blazic lnstitut Jozef Stefan, Jamova 39, Ljubljana, Yugoslavia
Abstract Jerman-Blazic, B., Security in value-added networks-security requirements for EDI, Computer Standards & Interfaces 12 (1991) 23-33 The paper describes the security requirements for Electronic Data Interchange (EDI) Service. The development of EDI today is based on the m o d e m communication methods as are X.400 and FTAM. Joint working groups (ISO JTC1 and CCITT WG VII) are working on the development of the EDI Conceptual model based on the store-and-forward exchange of data. The group has decided to define the EDI service and the EDI Conceptual Model analogously to the Interpersonal Messaging System in order to preserve compatibility with X.400. Special attention in the Conceptual Model of EDI is devoted to the mechanisms that counter the vulnerability of the EDI services. In this paper the existing security services and mechanisms of X.400 are evaluated in the view of EDI security requirements. New specific security services which appear to be a necessary part of the EDI model are briefly described. The work presented in this paper is based on the security concepts in the I S O / I E C J T C 1 / S W G - E D I Documents.
Keywords: Open systems; ISO OSI; security; EDI; EDI conceptual model; value added networks.
1.
I n t r o d u c t i o n
Value Added Networks (VANs) do not have to own a wide area network, but they generally will. At its simplest they might just provide point-topoint packet switching. At a more advanced level they may also offer protocol conversion to support a wide range of different equipment. Overall, their aim is to provide full connectivity between all the equipment and systems that their customers need. Every VAN is different in its structure and the services it offers. Some of the services are very generalized and some are extremely specialised. A comprehensive VAN is likely to have the following general components [1]: - basic network generic services - transaction relay application enabling information databases network management and help desk. Generic services are general purpose services needed by a wide range of customers rather than being application- or industry-specific. The main
examples are electronic mail, bulk data transfer, electronic data interchange and decision support facilities for managers and professionals. Electronic Data Interchange (EDI) is a generic term covering a number of different categories of interchange. It can be defined as " t h e electronic transfer from one computer to another of computer processable data using an agreed standard to structure the data" [2]. EDI is not electronic mail and is not the information provided by the growing number of linked database services sometimes called electronic trading. EDI is paperless trading of the following types: (1) transaction data interchange, which can be subdivided into two categories: - g e n e r a l - normally related to a business or administrative transaction such as invoice, purchase order, credit note, payment instruction, freight booking, waybill, customers entry; - specific-developed for a particular and special need. Electronic fund transfer, used widely in the banking industry is a good example;
0920-5489/91/$03.50 ~3 1991 - Elsevier Science Publishers B.V. (North-Holland)
24
B. Jerrnan-Blazic
(2) t e c h n i c a l d a t a i n t e r c h a n g e , used in design and engineering projects such as C A D / C A M . The first generation of EDI reflects the existing means of information exchange which basically can be treated as a postal service, and uses either interactive mode of interchange (telex, virtual terminal), direct connect (FTAM) or store and forward (Message Handling Service, e.g.X.400). The early designers of EDI took a very pragmatic view towards the computer-to-computer communication required for transmission of processable data. All of them have designed document encoding methods (ANSI X.12, EDIFACT, U N / TDI . . . . ) which could be implemented using the 25-year old IBM 2780 batch transfer protocol. Working with this conservative communication methods leads inevitably to problems concerned with error control process, recovery/restart procedures, etc. The current analyses of EDI application in use have shown that further development of EDI should be based on the modern communication methods such as X.400 and FTAM. Recently, a joint working group (ISO JTC1 and CCITT WG VII) agreed to work on the development of the EDI Conceptual Model based on the store-andforward exchange of data. A decision has been taken that a single solution for the EDI service should be defined analogously to the Interpersonal Messaging System in order the basic compatibility with X.400 to be preserved. In the course of development of the EDI Conceptual Model a special attention has been devoted to the vulnerability of the EDI services. This paper discusses the defined security services and elements of MHS according to X.400 recommendations, evaluates their adequacy for EDI and presents the main features of the Security Model and Services developed for EDI.
2. Open networks and security An open network does not need to be based on protocols which adhere to OSI standards, and in proprietary protocols there are often some facilities for message handling security services and network management. However, there is an increasing trend towards using vendor-independent protocols based on the Open Systems Interconnection Standard ISO 7498 [3]. The OSI Security
Architecture Draft International Standard 7498/2 is the main basis for building a secure open networking software environment. The term 'security' in ISO 7498/2 is defined as a means of 'minimizing the vulnerabilities of assets and resources'. Security is against the threats to the assets. Threats are encountered by security services available at layer and user interfaces. The security services are provided by security mechanisms. Their realization in the protocols is by addition security protocol elements. Some mechanisms prevent attacks, other detect attacks, some of the latter provide recovery of an unmanipulated state. Some important security services defined in ISO 7498/2 are listed below: - A u t h e n t i c a t i o n . Provides for the authentication of a communication peer entity and the source of data. - A c c e s s control. Provides protection against unauthorized use of the resource accessible via OSI. - D a t a c o n f i d e n t i a l i t y . Provides for the protection of data from unauthorized disclosure, D a t a i n t e g r i t y . Counters active threats and may take different forms including recovery, N o n - r e p u d i a t i o n . Provides the recipient of data with proof of the origin of data, a protection against any attempts by the sender to falsely deny sending the data or its content. The variety of mechanisms may be used to provide the capabilities of the services listed. They are: encipherment, digital signature mechanisms, access control mechanisms (e.g. closed user groups), authentication exchange mechanism (e.g. exchange of password), data integrity mechanisms (e.g. use of redundancy checks), traffic padding (i.e sending spurious data to disguise the length and number of transmitted service-data-units), routing control (e.g. selecting only secure communication paths), notarization (i.e. use of a trusted third party as a rely), ensuring trusted functionality of software and hardware, incorporation of event detection (e.g. local and remote reporting of unusual events), provision for audit trails (e.g. logging all events), incorporation of security recovery (e.g. actions taken after reporting of real or suspected breeches of security). Security services may be provided by different layers and different protocols depending on the application requirements. The approach which could be taken in defining the security mecha-
25
Securi(v in value-added networks
nisms for a particular application is usually based on the following items: identification of the vulnerabilities of the application definition of security policies - definition of security model - choice of security services, and - placement of the security services in a particular protocol. The identification of the vulnerabilities of the application is related to the model of the application and its environment. The conceptual model developed for EDI introduces EDI as a Message Handling Application called EDI Messaging System or EDIMS. The main features of the EDIMS Conceptual Model follow.
3. E D I ED!
messaging
conceptual
system
- an introduction
to the
model
3.1. The EDI service ED1 is defined as computer-to-computer exchange of structured business data, such as invoices and purchase orders. The EDI Service provides a user with features to assist in communicating with other service users. The EDI service uses capabilities of the Message Transfer Service for receiving and sending EDI messages. The EDI Service is provided by the EDI Messaging System (EDIMS). EDIMS by functionality resembles to IPMS (Interpersonal Messaging System) as defined in Recommendation X.400. In some cases the EDI Service can be used to transmit an EDI interchange to a physical rendition system, such as Telex, facsimile or printing.
Fig. 1. EDI messaging environment.
EDI Messaging System users. The structure of the E D I M E is depicted in Fig. 1.
3.3. The E D I messaging system The EDI Messaging System (EDIMS) is the functional object by means of which all users communicate with one another in EDI Messaging. A user may access EDIMS through an Access Unit. One type of Access Unit is the Physical Delivery Access Unit. The other Access Unit can be a telex access unit, facsimile access units or CTR terminal. The structure of the E D I M S is depicted in Fig. 2. As shown in the Figure, E D I M S UAs are the objects by which the EDIMS provides service to the users. An EDI Messaging System user agent (EDIMS UA) is a UA tailored so as to better assist a single user to engage in EDI Messaging. It helps that the user originates and receives messages. The EDIMS contains any number of EDIMS UA. The UAs (User Agents) in the EDIMS comprise a specific class of cooperating UAs. The Physical Delivery Access Unit (PDAU) allows EDI users to send messages to users outside the EDIMS.
3.2. The E D I messaging environment EDIMS model comprises EDI User Agent, EDI Message Stores and Physical Delivery Access Units, all supported by the Message Transfer Service. The environment in which EDI messaging takes place can be modeled as a functional object which is referred to as the EDI Messaging Environment EDIME. The E D I M E can be seen to comprise lesser objects referred to as the primary objects of EDI Messaging. They include a single central object, the EDI Messaging System (EDIMS) and numerous peripheral objects called
Fig. 2. EDI messaging system.
26
B. Jerman-Blazic
An EDI Messaging System message store ( E D I M S MS) is an MS tailored so as to better assist a single UA engaged in E D I Messaging. It helps that the UA submits, takes delivery of, stores, and retrieves messages containing EDIMs. The Message Stores used in E D I M S have specific related functions and can be optionally used by E D I users to take delivery of messages on their behalf, i.e to the Telematic Access Unit. The Message Transfer Service (MTS) conveys messages between UAs, or between a UA and an Access Unit. The E D I M S contains a single MTS. Fig. 3 shows the principal information flows in the E D I Messaging System.
3. 4. Structure of E D I messages The EDI class of UAs creates messages containing contents specific to the EDI Messaging
0
)IFACT
Service. The specific content that is sent from one EDI UA to another is a result of an originator, which is generally an application process, composing and sending a message, called an E D I Message. The EDI Message will carry the EDI Interchange. Only one interchange is present in an E D I Message. E D I M S U A generates E D I Heading and submits envelope and other information in EDI package to the MTS. The receiver identification is mapped into an X.400 O / R Address. The E D I Message is conveyed with the envelope when being transferred through the MTS. Like an IPMS message, the E D I M S message also contains a heading made up of multiple fields. Most of these are mapped directly from equivalent fields in the lead segment of the EDI interchange ( E D I F A C T , U N / T D I or ANSI X12), the primary intent being to make this information accessible to the message store for retrieval purposes. Additional body parts
EDI APPLICATION
ANSI x 1
UN/TD EDI standard packa.geincluding InterchangeControl Information
UNA
OR UNZ
i|
OR
, IEA
EDI Messoge System EDIMS UA
E-
MTs
P Fig. 3. Information flow in the EDI messaging system.
ETC --ira,.
Security in oalue-added networks
are provided to carry information supplementing that of the EDI interchange, e.g. engineering drawings of specification related to an order of complex machine parts. The key fields from the EDI Interchange header are duplicated in the E D I M header, and therefore MTAs and Uas do not need to know the EDI syntax in use. On deliverly from MTS EDIMS UA extracts EDI package and passes it to EDI application.
3.5. The EDI responsibility notification A new feature in EDI Messaging Service is the EDI Responsibility Notification. The purpose of introducing the concept of EDIMS Responsibility is primary to provide a method for confirming the passing of messages amongst UAs. In EDIMS a user or user application can request a notification of responsibility of a message by a recipient or recipient application. This notification is requested by an originating UA and is generated by a recipient UA taking responsibility for the message. The acceptance of responsibility by a UA for an EDI Message is when the EDI Interchange leaves the UA and passes to the EDI application. Responsibility implies that the message received is either available to the EDIMS user, or that it is forwarded with changes. One notification serves to carry both the positive response above and the negative response. The negative response means that the message referred to will not be processed by an EDI application. The same service element can forward the received EDI Message unchanged and pass the obligation to respond to the responsibility notification request to the forward recipient, or intermediate recipients, who then must respond to the originator of the message. When an EDI Message is forwarded, then the complete message, and optionally its envelope, is packed into a new body part, which becomes the only body part of a new EDI Message which is submitted by the forwarding UA to its MTA. The envelope must be included if certain security features are present. Changes are not allowed to the body. However, body parts may be added to a forwarded message.
4. T h r e a t s a n d a t t a c k s i n m e s s a g e
transfer systems
The resources of the communication systems, i.e. the local machines, relays and information
27
conveyed are targets of different threats. The threats can be oriented towards the communication network itself or towards unauthorized access to a local system where the communication network is used only as a medium of access. In Message Transfer Systems the following threats are concerned to be crucial: - masquerade - data manipulation, modification of information - message loss - repudiation of action or service - denial of service. The vulnerabilities of EDI applications compared to those of MHS are considered to be as serious as in the MHS environment. However, there are other additional factors within EDI which increase the vulnerability of E D I M S to failure, error or fraud, i.e the low level of direct human intervention and interpretation and the increased system integration. The vulnerability of EDI in the context of MHS is discussed below. Masquerade. The mutual validation of the message transfer agent (MTA) is by the exchange of the MTA names in plain text. An unknown MTA (e.g. in the testing procedure) may be interconnected with some operational MTA by sending one of the known MTA names. This is a typical masquerade of identity with the intention to steal working resources or information. The vulnerability of the EDIMS environment to masquerade is considered at least as serious as in the IPMS environment. Data manipulation. Any kind of unauthorized modification of data which violates their integrity. The managing of addresses is also in some sense a violation of integrity, accidentally caused by bad maintenance. The vulnerability of the E D I M S environment to modification of data is considered at least as serious as in the MHS environment. Further vulnerability of the service is present in the interchange of EDI messages. This vulnerability includes manipulation of a message content in the originator's local store after non-repudiation of submission a n d / o r manipulation of message contents in the recipient's store after non-repudiation of deliverly. Message loss. Messages get lost or get cut off their bodies. Vulnerability to message loss is considered critical in the E D I M S environment. Two types of message loss may be distinguished: - failure of UA, MS or MTA
28
B. Jerman-Blazic
- loss of individual message(s) due to security violation. Another very important issue is the transfer of messages between responsibility domains: - from the originating E D I M S user domain - between relaying domain - the recipient E D I M S user domain. The transfer of messages between responsibility domains requires protection for service providers in addition to that for end users. Repudiation of action or service. Repudiation of origin, submission, or delivery of information is extremely painful if contracts or other business documents are considered. How to trust an invoice received by an EDI service? Vulnerability to repudiation is considered to be even more critical in the E D I M S environment than in the IPMS environment. Such vulnerability may be increased by the use of certain MHS services such as auto-
forwarding and redirection. Here again an important issue is the transfer of messages between responsibility domains. Denial of services. Denial of services is due to accidental interruption caused by local system failures or by nonconformant components in cooperating systems, such as erroneous entries in address routing or name mapping tables. Intentional interruptions are normal for maintenance purposes. The availability of the E D I M S environment is considered to be a crucial issue for this type of service.
5. Security in MHS The security services in MHS are defined in C C I T T X.400 Recommendations and the Docu-
Table 1 The security classes and services in MHS
Message Transfer Security
Services
I"
"F
I
UAIUA MSIMTA MTAIMS MTAIUA l l UAIMS UAIMTA MTAIMTA MSIUA l
I I SERVICE
•I" . e - ORIGIN AUTHENTICATION . . . . I I I Message Origin Authentication I Probe Origin Authentication I Report Origin Authentication I I Proof of Submission I I Proof of Del.ivery I +-SECURE ACCESS MANAGEMENT--+ I Peer Entity Authentication I I Security Context I + - DATA CONFIDENTIALITY . . . . . . . iI Connection Confidentiality I I Content Confidentiality I I Message Ftow Confidentiality I
. . . . . . . . .
"
*
I *
. . . .
.
.
.
.
,
. . . . . *
.
I
.
I
*
I
. . . . . .
Note
I
P
• • * *
+ - DATA INTEGRITY SERVICES . . . . I Connection Integrity
+ J
I Content Integrity I Message Sequence Integrity +- NON- REPUDIATION . . . . . . . . . . . I Non-repudiation of Origin I Non-repudiation of Submission [ Non-repudiation of Delivery ÷-, MESSAGE SECURITY LABELLING - I Message Security Labelling
I * I * + ....... [ I " I * ,+I *
+ - SECURITY M A N A G E M E N T
"
P
•~,
.!-
.It-
*
,It.
.11-
ak
-W-
Nit"
"11"
"1"
"It"
~
"11"
*k
~
.It-
-1-
il-
Nit-
%
Q
I
Q
•
•
Q
I
I
Q
Q
Q
Q
Q
•
•
•
t
•
•
-!-
-X.
-It-
~
,,~
.!1-
*
I I I I I 1-
• I
+
SERVICES +
I Change CredentiaLs
J
~1-
•
~-
-It-
"11-
I Register
I
ak
•
ak
•
•
I MS Register
I
t
I
•
I
Security in value-added networks
ment X.402 defines the Security Model in MHS in particular. The aim of the model is to provide security features independently of the communication services provided by other lower entities. The security features in the model are an optional extension of the MHS application. The security services in the model are extensively defined with the intention of supporting a wide range of security policies which extend beyond the confines of the MHS itself. A security policy defines how the risk to and exposure of assets can be reduced to an acceptable level. The Security Model allows a lot of flexibility in the choice of algorithms and service elements. The services selected among those listed in the model and the threats addressed depend on the individual MHS application and levels of trust in the parts of the system. As each application is a subject to its own overall security policy, covering more than just the MHS, a bilateral agreement on interworking between two applications seems to be necessary. This must be defined not to conflict with the security policies for either application and effectively becomes part of the overall security policy for each application. Message Transfer security services in the MHS Security Model fall into several broad classes. These classes and the services in each are listed in Table 1. An asterisk (*) under the heading of the form X / Y indicates that the service can be provided from a functional object of type X to one of type Y. In many cases the broad classes of threats in an MHS application may be covered by the services listed in Table 1. The particular choice of service and service element depends on the adopted security policy. For example, to counter masquerade the following services may be applied: Message Origin Authentication, Secure Access Management, Proof of delivery, Proof of submission. The services to counter message loss could be provided in the form of MHS detection of message loss by applying Message Security Labelling. The Message Sequence Integrity is a service which cares for the integrity of the conveyed data, Connection Integrity and Content Integrity provide protection against modification of the message content. Additional protection may be provided by use of double enveloping, i.e. with encrypted checksum on the outer envelope.
29
6. Security. model and services in E D I M S
6.1. Security model The Security Model of EDIMS is still not properly defined but some adopted guidelines within different working groups give enough idea about the main features of the model. The model is envisaged as a framework of classified security functions and their management. The security functions which are a part of the model are planned to be defined as mandatory or optional. The main feature of the model is its flexibility which allows extensions of the security services and mechanisms if they are recognized as useful and necessary. The specific feature of the model which is not part of the current MHS Security Model is the concept of responsibility for messages at each stage of the message path. In an EDI context, the increased possibility of a number of service providers offering commercial services requires the transfer of responsibility to be clearly identified and assured to provide protection not only to the end users but also to the service providers. The concept of responsibility in EDI is related to the Information Management Domain (IMD). IMD is an abstract characteristic of a specific class of organization, one which participates in an EDI interchange. EDIMS user environment, ED1MS UA, MTS Management Domain and the Message Store are parts of an IMD. I M D principals define the security policy and ED1MS acts in an operational capacity to implement policy. For easier understanding of the IMDs role, the security in EDI may be referenced in several levels or zones (see Fig. 4) where an IMD is represented as a system of components. The core components are the processes invoked within EDIMS. The Directory is a component which provides addresses and the mapping from the internal format. The Directory may be synchronized with an OSl X.500 directory service. Operation rules and state tables are the logical components containing rules for EDI transactions. Business Contracts and Trading Partner Profiles are components providing rules based on the legal term and conditions of Business Contracts and of Trading Partner Profiles. The Business Forms and Messages component is related to renditions of messages in standardized business forms. Interface
30
B. Jerman-Blazic
Mon(~gemeo ~..-"
iil ~ /
/
L , ~ ~ t o t e
"
User Apptication
t
"
/
nary
Security Level 3
\,,n"',,,
/ ~
APVs
N~gZi'22"~,4\
/
~
\
Tobles~Operot,onM~age / ~ - ~ - '
/-. . . . . . ~ ~ ' K
~
, . o o~
Directory ( X. 5~0"]-.
Level 2
PROCESSES
.
.
.
.
.
Leveli
.
interface to CS
.
Communication Services
Level 0
OSi Reference Mode{ Media I Other
Fig. 4. Security levels in an IMD. Level 0: This level of security relates to the interface level of security. It applies to the specific communication service and its
functional capabilities (end-to-end transfer of message and data). Level l: This level of security relates to the operating system capability to secure system access via communications or physical media device (i.e authentication). Level 2: This level of security is implemented specifically for the EDI components such as EDI Message Store, Operation Rules, Management, etc. Level 3: This level of security is specific to application implementations a n d / o r may be tied to user's interfaces with no ties to the EDI model. This level of security may take various aspects, but the c o m m o n feature is that security functions within this level cannot be realized in EDIMS but have to be arranged within contractual regulations between IMDs.
API provides for invocation of services for system specific applications. Binary objects is a component by which EDI messages can carry other standardized data formats as part of a an EDI Interchange. EDI Data Store is a place for storing EDI Messages. The component for Statistics and Audit Trail provides activity reports for all transactions. The dictionary component contains information about data elements and data sets that are used in EDI transactions.
6.2. Security services The provision of the security services and mechanisms within the model must be based on the identified vulnerabilities. The areas identified in Section 3 may be used as the starting point for identification of security services in EDI, however, some additional vulnerabilities which may appear in E D I M S environment and which are not currently identified in X.402 have to be taken into
account. Some of the vulnerabilities within EDI may be more appropriately countered by security services outside the model, i.e. in Level 3. (a) Masquerade. The services defined in M H S Security Model which counter this type of vulnerability may be used in E D I M S environment. They are: Authentication (i.e Strong Authentication according to X.509), Secure Access Management, including Security Labelling, Proof of Delivery and Proof of Submission. Security Audit Trail may also be the appropriate function for recording of the user actions on the Message Store (MS). (b) Protection against Data Manipulation may be provided by the Security Services, Connection Integrity and Content Integrity. Double enveloping could provide additional protection. (c) Message loss could occur over any peer-topeer communication link or by the failure or incorrect behaviour. The following categories of message loss are distinguished: - catastrophic message loss
Security in oalue-added networks
loss of individual messages in the MS - MTS message loss. Failure of the UA is outside this level of security. Failure of MS is potentially catastrophic and desirably needs some protection, at least in terms of detection. This should be provided by an offline archive to hold all submitted and delivered messages. Failure of any component in the MTS may similarly be catastrophic and can be protected by offline archiving messages. Loss of individual messages in the Message Store requires provision of a Secure Audit Trail to enable detection of such a loss. The service could be provided to the EDIMS user and to the MS management. Secure MS Audit Trail could be realised as a pervasive mechanism or as a part of Security Management Services. Loss of individual messages in the MTS requires provision of a Secure Audit Trail to enable detection of such a loss. Such service seems also to be useful for the EDIMS user and the I M D management. Again this service may be realised as specific in MTA Security Management Services or as a pervasive mechanism. Notification of message loss is very useful service for the user, but the connectionless nature of the MHS environment makes automatic action difficult. The Message Sequence Integrity service in the MHS Security Model does not guarantee detection of message loss since it relies on the provision of an integer value by the originator. Message stores (MS) which are outside EDIMS user domain cannot necessarily be trusted by that domain. Provision of such services to a recipient is complicated by the fact that messages may originate from a number of sources. In practice, effective operation of this service would require a common code of practice or common security policy between IMDs. The MHS services which can provide some kind of notification of message loss are confined to services offered to the originating E D I M S user. The existing services Proof of Submission and Delivery, which provide some assurance, do not operate end-to-end and do not take care if the recipient E D I M S UA and Message Store are colocated or not. Therefore, a service for Proof of Receipt (by the recipient UA) seems to be a necessary feature of the Model. (d) Denial of Ser~#ce is treated as an important vulnerability and some of the services required in the MTA Management and MTA failure protec-
31
tion could also be appropriate to counter this vulnerability in EDIMS. (e) Services which offer protection against repudiation in the EDIMS environment are concerned with formalising the transfer of responsibility. The existing MHS services non-repudiation of origin non-repudiation of submission non-repudiation of delivery proof of submission - proof of delivery cover only some areas of transfer between responsibility domains which could be of significance in an EDIMS environment, i.e. between E D I M S user domains (i.e. end-to-end) between MTS Management Domains between a Message Store and a recipient EDIMS user. An additional service definition seems to be appropriate for covering N o n - r e p u d i a t i o n / P r o o f of Transfer. Possible mechanisms for realisation of this service could be archiving of relaying information. N o n - R e p u d i a t i o n / P r o o f of Delivery do not provide protection in the case of delivery to a Message Store which is not part of the recipient EDIMS user's environment. Therefore a service for N o n - R e p u d i a t i o n / P r o o f of Retrieval service may be necessary to care for the transfer of responsibility to the recipient E D I M S UA and a protection of the MS management. Proof of Retrieval may be realised by Secure MS Audit Trail to record EDIMS user actions on the MS. Non-repudiation/ Proof of Receipt appears to be necessary for covering the transfer of responsibility to the the recipient E D I M S UA, in case the protection of the originating ED1MS user is required. Such services are relevant in case of autoforwarding, redirection, in the case when a delivery to an untrusted Message Store is present. They protect the sender from the threat that the recipient might, for his own financial advantage, choose to ignore an unwelcome message (demand for payment, for example). To counter the vulnerability of manipulation of information by the E D I M S user it may be desirable to have a service for n o n - r e p u d i a t i o n / P r o o f of Content. The MHS environment could potentially provide assistance for this service in terms of notarization services. Such notarization services could be achieved by forwarding messages via a mutually trusted third party. The transfer of re-
-
32
B. Jerrnan-Blazic
Trusted Funcliona[ity t............................
Trusted Funciionality • ...........................
i
4 ........
[
1,
+ . . . . . . . . . . . . . . . .
J EDIMS
UAII 4
Applicationl I
t- .......
JEDIMS UAII
PROOF OF RECEIPT
[
~[ RETRIEVAL
,
PROOF OF SUBMISSION
I
I
J
Domain A
I
Domain B 4
PROOF OF TRANSFER
I •
Domain C
PROOF OF TRANSFER
Key .....
Responsibility transfer boundary Ill
Security service
Fig. 5. Transfer of responsibility within EDIMS. sponsibility within E D I M S is illustrated in Fig. 5. The use of other Security Services of MHS such as Connection Confidentiality, Content Confidentiality and Message Flow Confidentiality as well as Security Access Management and Security Labelling are also applicable in the E D I M S environment, for example for leakage of information. The double enveloping could also provide some protection against traffic analysis. A summirised overview of the additionally required Security Services in an E D I M S environment gives rise to the following list of services and pervasive mechanisms: N o n - r e p u d i a t i o n / P r o o f of receipt N o n - r e p u d i a t i o n / P r o o f of retreival N o n - r e p u d i a t i o n / P r o o f of transfer N o n - r e p u d i a t i o n / P r o o f of content Secure MS Audit Trail Secure MT Audit Trail MS Archive M D Archive Security of MTA management and routing information. The list is not exhaustive and its final content will depend on the different security policies adopted among the participating entities and the
other aspects as well, i.e. management in connection to the objectives of the third party notarization or certification bodies involved.
7. Conclusion
In the course of development of the EDI Conceptual Model a special attention has been devoted to the vulnerability of the EDI services. The vulnerability of the EDI services as well as the specific mechanisms and services required to counter the threats to E D I M S are complementary to the existing security services as defined in the Recommendation X.402. Some additional security services for E D I M S have been proposed as well as enhancement of some existing services. The security Model and the proposed Security Services would need to be constantly updated to reflect changes in technology and user requirements. It is expected that the user's primary concern will be a cost-effective solution to security. The cost of security has to be in accordance with the nature of the transferred message. In the present networks there is a reasonable correspondence between the network service provider and the type of
Securt(v in value-added networks
message conveyed. The users are o r g a n i s e d in user g r o u p s a n d the networks are relatively closed. This c o r r e s p o n d e n c e will d i s a p p e a r with a wider variety of users a n d the use of an o p e n EDI. The presented Security M o d e l c o n t a i n s an exhaustive n u m b e r of services and a lot of freedom, e n a b l i n g the b u i l d i n g up of a secure o p e n E D I in accord a n c e with the cost-effective r e q u i r e m e n t s of the users and service providers.
References [1] R. Reardon (ed.), London, 1989) 85.
Future Networks (Blenheim Online,
33
[2] M. Oifkins and D. Hitchcock, eds, The EDI Handbook (Blenheim Online, London, 1988) 4. [3] ISO/OSI Reference Model 7498/2. [4] I S O / I E C JT('I SWG-EDI documents.
Dr. Jerman-Bla~i~ graduated from the Technical University in Skopje (Yugoslavia) and holds a PhD from the University of Zagreb. She joined the ('ompurer Science Department at Jozef Stefan Institute in 1971 and since then she has been involved in computing. She is now head of a project group working in the field of computer networking and is the project manager of Y U N E T (Yugoslav Academic Network). For the last eight years she has been involved in standardization work in the field of information interchange.
23
Security in value added networks- security requirements for EDI Borka Jerman-Blazic lnstitut Jozef Stefan, Jamova 39, Ljubljana, Yugoslavia
Abstract Jerman-Blazic, B., Security in value-added networks-security requirements for EDI, Computer Standards & Interfaces 12 (1991) 23-33 The paper describes the security requirements for Electronic Data Interchange (EDI) Service. The development of EDI today is based on the m o d e m communication methods as are X.400 and FTAM. Joint working groups (ISO JTC1 and CCITT WG VII) are working on the development of the EDI Conceptual model based on the store-and-forward exchange of data. The group has decided to define the EDI service and the EDI Conceptual Model analogously to the Interpersonal Messaging System in order to preserve compatibility with X.400. Special attention in the Conceptual Model of EDI is devoted to the mechanisms that counter the vulnerability of the EDI services. In this paper the existing security services and mechanisms of X.400 are evaluated in the view of EDI security requirements. New specific security services which appear to be a necessary part of the EDI model are briefly described. The work presented in this paper is based on the security concepts in the I S O / I E C J T C 1 / S W G - E D I Documents.
Keywords: Open systems; ISO OSI; security; EDI; EDI conceptual model; value added networks.
1.
I n t r o d u c t i o n
Value Added Networks (VANs) do not have to own a wide area network, but they generally will. At its simplest they might just provide point-topoint packet switching. At a more advanced level they may also offer protocol conversion to support a wide range of different equipment. Overall, their aim is to provide full connectivity between all the equipment and systems that their customers need. Every VAN is different in its structure and the services it offers. Some of the services are very generalized and some are extremely specialised. A comprehensive VAN is likely to have the following general components [1]: - basic network generic services - transaction relay application enabling information databases network management and help desk. Generic services are general purpose services needed by a wide range of customers rather than being application- or industry-specific. The main
examples are electronic mail, bulk data transfer, electronic data interchange and decision support facilities for managers and professionals. Electronic Data Interchange (EDI) is a generic term covering a number of different categories of interchange. It can be defined as " t h e electronic transfer from one computer to another of computer processable data using an agreed standard to structure the data" [2]. EDI is not electronic mail and is not the information provided by the growing number of linked database services sometimes called electronic trading. EDI is paperless trading of the following types: (1) transaction data interchange, which can be subdivided into two categories: - g e n e r a l - normally related to a business or administrative transaction such as invoice, purchase order, credit note, payment instruction, freight booking, waybill, customers entry; - specific-developed for a particular and special need. Electronic fund transfer, used widely in the banking industry is a good example;
0920-5489/91/$03.50 ~3 1991 - Elsevier Science Publishers B.V. (North-Holland)
24
B. Jerrnan-Blazic
(2) t e c h n i c a l d a t a i n t e r c h a n g e , used in design and engineering projects such as C A D / C A M . The first generation of EDI reflects the existing means of information exchange which basically can be treated as a postal service, and uses either interactive mode of interchange (telex, virtual terminal), direct connect (FTAM) or store and forward (Message Handling Service, e.g.X.400). The early designers of EDI took a very pragmatic view towards the computer-to-computer communication required for transmission of processable data. All of them have designed document encoding methods (ANSI X.12, EDIFACT, U N / TDI . . . . ) which could be implemented using the 25-year old IBM 2780 batch transfer protocol. Working with this conservative communication methods leads inevitably to problems concerned with error control process, recovery/restart procedures, etc. The current analyses of EDI application in use have shown that further development of EDI should be based on the modern communication methods such as X.400 and FTAM. Recently, a joint working group (ISO JTC1 and CCITT WG VII) agreed to work on the development of the EDI Conceptual Model based on the store-andforward exchange of data. A decision has been taken that a single solution for the EDI service should be defined analogously to the Interpersonal Messaging System in order the basic compatibility with X.400 to be preserved. In the course of development of the EDI Conceptual Model a special attention has been devoted to the vulnerability of the EDI services. This paper discusses the defined security services and elements of MHS according to X.400 recommendations, evaluates their adequacy for EDI and presents the main features of the Security Model and Services developed for EDI.
2. Open networks and security An open network does not need to be based on protocols which adhere to OSI standards, and in proprietary protocols there are often some facilities for message handling security services and network management. However, there is an increasing trend towards using vendor-independent protocols based on the Open Systems Interconnection Standard ISO 7498 [3]. The OSI Security
Architecture Draft International Standard 7498/2 is the main basis for building a secure open networking software environment. The term 'security' in ISO 7498/2 is defined as a means of 'minimizing the vulnerabilities of assets and resources'. Security is against the threats to the assets. Threats are encountered by security services available at layer and user interfaces. The security services are provided by security mechanisms. Their realization in the protocols is by addition security protocol elements. Some mechanisms prevent attacks, other detect attacks, some of the latter provide recovery of an unmanipulated state. Some important security services defined in ISO 7498/2 are listed below: - A u t h e n t i c a t i o n . Provides for the authentication of a communication peer entity and the source of data. - A c c e s s control. Provides protection against unauthorized use of the resource accessible via OSI. - D a t a c o n f i d e n t i a l i t y . Provides for the protection of data from unauthorized disclosure, D a t a i n t e g r i t y . Counters active threats and may take different forms including recovery, N o n - r e p u d i a t i o n . Provides the recipient of data with proof of the origin of data, a protection against any attempts by the sender to falsely deny sending the data or its content. The variety of mechanisms may be used to provide the capabilities of the services listed. They are: encipherment, digital signature mechanisms, access control mechanisms (e.g. closed user groups), authentication exchange mechanism (e.g. exchange of password), data integrity mechanisms (e.g. use of redundancy checks), traffic padding (i.e sending spurious data to disguise the length and number of transmitted service-data-units), routing control (e.g. selecting only secure communication paths), notarization (i.e. use of a trusted third party as a rely), ensuring trusted functionality of software and hardware, incorporation of event detection (e.g. local and remote reporting of unusual events), provision for audit trails (e.g. logging all events), incorporation of security recovery (e.g. actions taken after reporting of real or suspected breeches of security). Security services may be provided by different layers and different protocols depending on the application requirements. The approach which could be taken in defining the security mecha-
25
Securi(v in value-added networks
nisms for a particular application is usually based on the following items: identification of the vulnerabilities of the application definition of security policies - definition of security model - choice of security services, and - placement of the security services in a particular protocol. The identification of the vulnerabilities of the application is related to the model of the application and its environment. The conceptual model developed for EDI introduces EDI as a Message Handling Application called EDI Messaging System or EDIMS. The main features of the EDIMS Conceptual Model follow.
3. E D I ED!
messaging
conceptual
system
- an introduction
to the
model
3.1. The EDI service ED1 is defined as computer-to-computer exchange of structured business data, such as invoices and purchase orders. The EDI Service provides a user with features to assist in communicating with other service users. The EDI service uses capabilities of the Message Transfer Service for receiving and sending EDI messages. The EDI Service is provided by the EDI Messaging System (EDIMS). EDIMS by functionality resembles to IPMS (Interpersonal Messaging System) as defined in Recommendation X.400. In some cases the EDI Service can be used to transmit an EDI interchange to a physical rendition system, such as Telex, facsimile or printing.
Fig. 1. EDI messaging environment.
EDI Messaging System users. The structure of the E D I M E is depicted in Fig. 1.
3.3. The E D I messaging system The EDI Messaging System (EDIMS) is the functional object by means of which all users communicate with one another in EDI Messaging. A user may access EDIMS through an Access Unit. One type of Access Unit is the Physical Delivery Access Unit. The other Access Unit can be a telex access unit, facsimile access units or CTR terminal. The structure of the E D I M S is depicted in Fig. 2. As shown in the Figure, E D I M S UAs are the objects by which the EDIMS provides service to the users. An EDI Messaging System user agent (EDIMS UA) is a UA tailored so as to better assist a single user to engage in EDI Messaging. It helps that the user originates and receives messages. The EDIMS contains any number of EDIMS UA. The UAs (User Agents) in the EDIMS comprise a specific class of cooperating UAs. The Physical Delivery Access Unit (PDAU) allows EDI users to send messages to users outside the EDIMS.
3.2. The E D I messaging environment EDIMS model comprises EDI User Agent, EDI Message Stores and Physical Delivery Access Units, all supported by the Message Transfer Service. The environment in which EDI messaging takes place can be modeled as a functional object which is referred to as the EDI Messaging Environment EDIME. The E D I M E can be seen to comprise lesser objects referred to as the primary objects of EDI Messaging. They include a single central object, the EDI Messaging System (EDIMS) and numerous peripheral objects called
Fig. 2. EDI messaging system.
26
B. Jerman-Blazic
An EDI Messaging System message store ( E D I M S MS) is an MS tailored so as to better assist a single UA engaged in E D I Messaging. It helps that the UA submits, takes delivery of, stores, and retrieves messages containing EDIMs. The Message Stores used in E D I M S have specific related functions and can be optionally used by E D I users to take delivery of messages on their behalf, i.e to the Telematic Access Unit. The Message Transfer Service (MTS) conveys messages between UAs, or between a UA and an Access Unit. The E D I M S contains a single MTS. Fig. 3 shows the principal information flows in the E D I Messaging System.
3. 4. Structure of E D I messages The EDI class of UAs creates messages containing contents specific to the EDI Messaging
0
)IFACT
Service. The specific content that is sent from one EDI UA to another is a result of an originator, which is generally an application process, composing and sending a message, called an E D I Message. The EDI Message will carry the EDI Interchange. Only one interchange is present in an E D I Message. E D I M S U A generates E D I Heading and submits envelope and other information in EDI package to the MTS. The receiver identification is mapped into an X.400 O / R Address. The E D I Message is conveyed with the envelope when being transferred through the MTS. Like an IPMS message, the E D I M S message also contains a heading made up of multiple fields. Most of these are mapped directly from equivalent fields in the lead segment of the EDI interchange ( E D I F A C T , U N / T D I or ANSI X12), the primary intent being to make this information accessible to the message store for retrieval purposes. Additional body parts
EDI APPLICATION
ANSI x 1
UN/TD EDI standard packa.geincluding InterchangeControl Information
UNA
OR UNZ
i|
OR
, IEA
EDI Messoge System EDIMS UA
E-
MTs
P Fig. 3. Information flow in the EDI messaging system.
ETC --ira,.
Security in oalue-added networks
are provided to carry information supplementing that of the EDI interchange, e.g. engineering drawings of specification related to an order of complex machine parts. The key fields from the EDI Interchange header are duplicated in the E D I M header, and therefore MTAs and Uas do not need to know the EDI syntax in use. On deliverly from MTS EDIMS UA extracts EDI package and passes it to EDI application.
3.5. The EDI responsibility notification A new feature in EDI Messaging Service is the EDI Responsibility Notification. The purpose of introducing the concept of EDIMS Responsibility is primary to provide a method for confirming the passing of messages amongst UAs. In EDIMS a user or user application can request a notification of responsibility of a message by a recipient or recipient application. This notification is requested by an originating UA and is generated by a recipient UA taking responsibility for the message. The acceptance of responsibility by a UA for an EDI Message is when the EDI Interchange leaves the UA and passes to the EDI application. Responsibility implies that the message received is either available to the EDIMS user, or that it is forwarded with changes. One notification serves to carry both the positive response above and the negative response. The negative response means that the message referred to will not be processed by an EDI application. The same service element can forward the received EDI Message unchanged and pass the obligation to respond to the responsibility notification request to the forward recipient, or intermediate recipients, who then must respond to the originator of the message. When an EDI Message is forwarded, then the complete message, and optionally its envelope, is packed into a new body part, which becomes the only body part of a new EDI Message which is submitted by the forwarding UA to its MTA. The envelope must be included if certain security features are present. Changes are not allowed to the body. However, body parts may be added to a forwarded message.
4. T h r e a t s a n d a t t a c k s i n m e s s a g e
transfer systems
The resources of the communication systems, i.e. the local machines, relays and information
27
conveyed are targets of different threats. The threats can be oriented towards the communication network itself or towards unauthorized access to a local system where the communication network is used only as a medium of access. In Message Transfer Systems the following threats are concerned to be crucial: - masquerade - data manipulation, modification of information - message loss - repudiation of action or service - denial of service. The vulnerabilities of EDI applications compared to those of MHS are considered to be as serious as in the MHS environment. However, there are other additional factors within EDI which increase the vulnerability of E D I M S to failure, error or fraud, i.e the low level of direct human intervention and interpretation and the increased system integration. The vulnerability of EDI in the context of MHS is discussed below. Masquerade. The mutual validation of the message transfer agent (MTA) is by the exchange of the MTA names in plain text. An unknown MTA (e.g. in the testing procedure) may be interconnected with some operational MTA by sending one of the known MTA names. This is a typical masquerade of identity with the intention to steal working resources or information. The vulnerability of the EDIMS environment to masquerade is considered at least as serious as in the IPMS environment. Data manipulation. Any kind of unauthorized modification of data which violates their integrity. The managing of addresses is also in some sense a violation of integrity, accidentally caused by bad maintenance. The vulnerability of the E D I M S environment to modification of data is considered at least as serious as in the MHS environment. Further vulnerability of the service is present in the interchange of EDI messages. This vulnerability includes manipulation of a message content in the originator's local store after non-repudiation of submission a n d / o r manipulation of message contents in the recipient's store after non-repudiation of deliverly. Message loss. Messages get lost or get cut off their bodies. Vulnerability to message loss is considered critical in the E D I M S environment. Two types of message loss may be distinguished: - failure of UA, MS or MTA
28
B. Jerman-Blazic
- loss of individual message(s) due to security violation. Another very important issue is the transfer of messages between responsibility domains: - from the originating E D I M S user domain - between relaying domain - the recipient E D I M S user domain. The transfer of messages between responsibility domains requires protection for service providers in addition to that for end users. Repudiation of action or service. Repudiation of origin, submission, or delivery of information is extremely painful if contracts or other business documents are considered. How to trust an invoice received by an EDI service? Vulnerability to repudiation is considered to be even more critical in the E D I M S environment than in the IPMS environment. Such vulnerability may be increased by the use of certain MHS services such as auto-
forwarding and redirection. Here again an important issue is the transfer of messages between responsibility domains. Denial of services. Denial of services is due to accidental interruption caused by local system failures or by nonconformant components in cooperating systems, such as erroneous entries in address routing or name mapping tables. Intentional interruptions are normal for maintenance purposes. The availability of the E D I M S environment is considered to be a crucial issue for this type of service.
5. Security in MHS The security services in MHS are defined in C C I T T X.400 Recommendations and the Docu-
Table 1 The security classes and services in MHS
Message Transfer Security
Services
I"
"F
I
UAIUA MSIMTA MTAIMS MTAIUA l l UAIMS UAIMTA MTAIMTA MSIUA l
I I SERVICE
•I" . e - ORIGIN AUTHENTICATION . . . . I I I Message Origin Authentication I Probe Origin Authentication I Report Origin Authentication I I Proof of Submission I I Proof of Del.ivery I +-SECURE ACCESS MANAGEMENT--+ I Peer Entity Authentication I I Security Context I + - DATA CONFIDENTIALITY . . . . . . . iI Connection Confidentiality I I Content Confidentiality I I Message Ftow Confidentiality I
. . . . . . . . .
"
*
I *
. . . .
.
.
.
.
,
. . . . . *
.
I
.
I
*
I
. . . . . .
Note
I
P
• • * *
+ - DATA INTEGRITY SERVICES . . . . I Connection Integrity
+ J
I Content Integrity I Message Sequence Integrity +- NON- REPUDIATION . . . . . . . . . . . I Non-repudiation of Origin I Non-repudiation of Submission [ Non-repudiation of Delivery ÷-, MESSAGE SECURITY LABELLING - I Message Security Labelling
I * I * + ....... [ I " I * ,+I *
+ - SECURITY M A N A G E M E N T
"
P
•~,
.!-
.It-
*
,It.
.11-
ak
-W-
Nit"
"11"
"1"
"It"
~
"11"
*k
~
.It-
-1-
il-
Nit-
%
Q
I
Q
•
•
Q
I
I
Q
Q
Q
Q
Q
•
•
•
t
•
•
-!-
-X.
-It-
~
,,~
.!1-
*
I I I I I 1-
• I
+
SERVICES +
I Change CredentiaLs
J
~1-
•
~-
-It-
"11-
I Register
I
ak
•
ak
•
•
I MS Register
I
t
I
•
I
Security in value-added networks
ment X.402 defines the Security Model in MHS in particular. The aim of the model is to provide security features independently of the communication services provided by other lower entities. The security features in the model are an optional extension of the MHS application. The security services in the model are extensively defined with the intention of supporting a wide range of security policies which extend beyond the confines of the MHS itself. A security policy defines how the risk to and exposure of assets can be reduced to an acceptable level. The Security Model allows a lot of flexibility in the choice of algorithms and service elements. The services selected among those listed in the model and the threats addressed depend on the individual MHS application and levels of trust in the parts of the system. As each application is a subject to its own overall security policy, covering more than just the MHS, a bilateral agreement on interworking between two applications seems to be necessary. This must be defined not to conflict with the security policies for either application and effectively becomes part of the overall security policy for each application. Message Transfer security services in the MHS Security Model fall into several broad classes. These classes and the services in each are listed in Table 1. An asterisk (*) under the heading of the form X / Y indicates that the service can be provided from a functional object of type X to one of type Y. In many cases the broad classes of threats in an MHS application may be covered by the services listed in Table 1. The particular choice of service and service element depends on the adopted security policy. For example, to counter masquerade the following services may be applied: Message Origin Authentication, Secure Access Management, Proof of delivery, Proof of submission. The services to counter message loss could be provided in the form of MHS detection of message loss by applying Message Security Labelling. The Message Sequence Integrity is a service which cares for the integrity of the conveyed data, Connection Integrity and Content Integrity provide protection against modification of the message content. Additional protection may be provided by use of double enveloping, i.e. with encrypted checksum on the outer envelope.
29
6. Security. model and services in E D I M S
6.1. Security model The Security Model of EDIMS is still not properly defined but some adopted guidelines within different working groups give enough idea about the main features of the model. The model is envisaged as a framework of classified security functions and their management. The security functions which are a part of the model are planned to be defined as mandatory or optional. The main feature of the model is its flexibility which allows extensions of the security services and mechanisms if they are recognized as useful and necessary. The specific feature of the model which is not part of the current MHS Security Model is the concept of responsibility for messages at each stage of the message path. In an EDI context, the increased possibility of a number of service providers offering commercial services requires the transfer of responsibility to be clearly identified and assured to provide protection not only to the end users but also to the service providers. The concept of responsibility in EDI is related to the Information Management Domain (IMD). IMD is an abstract characteristic of a specific class of organization, one which participates in an EDI interchange. EDIMS user environment, ED1MS UA, MTS Management Domain and the Message Store are parts of an IMD. I M D principals define the security policy and ED1MS acts in an operational capacity to implement policy. For easier understanding of the IMDs role, the security in EDI may be referenced in several levels or zones (see Fig. 4) where an IMD is represented as a system of components. The core components are the processes invoked within EDIMS. The Directory is a component which provides addresses and the mapping from the internal format. The Directory may be synchronized with an OSl X.500 directory service. Operation rules and state tables are the logical components containing rules for EDI transactions. Business Contracts and Trading Partner Profiles are components providing rules based on the legal term and conditions of Business Contracts and of Trading Partner Profiles. The Business Forms and Messages component is related to renditions of messages in standardized business forms. Interface
30
B. Jerman-Blazic
Mon(~gemeo ~..-"
iil ~ /
/
L , ~ ~ t o t e
"
User Apptication
t
"
/
nary
Security Level 3
\,,n"',,,
/ ~
APVs
N~gZi'22"~,4\
/
~
\
Tobles~Operot,onM~age / ~ - ~ - '
/-. . . . . . ~ ~ ' K
~
, . o o~
Directory ( X. 5~0"]-.
Level 2
PROCESSES
.
.
.
.
.
Leveli
.
interface to CS
.
Communication Services
Level 0
OSi Reference Mode{ Media I Other
Fig. 4. Security levels in an IMD. Level 0: This level of security relates to the interface level of security. It applies to the specific communication service and its
functional capabilities (end-to-end transfer of message and data). Level l: This level of security relates to the operating system capability to secure system access via communications or physical media device (i.e authentication). Level 2: This level of security is implemented specifically for the EDI components such as EDI Message Store, Operation Rules, Management, etc. Level 3: This level of security is specific to application implementations a n d / o r may be tied to user's interfaces with no ties to the EDI model. This level of security may take various aspects, but the c o m m o n feature is that security functions within this level cannot be realized in EDIMS but have to be arranged within contractual regulations between IMDs.
API provides for invocation of services for system specific applications. Binary objects is a component by which EDI messages can carry other standardized data formats as part of a an EDI Interchange. EDI Data Store is a place for storing EDI Messages. The component for Statistics and Audit Trail provides activity reports for all transactions. The dictionary component contains information about data elements and data sets that are used in EDI transactions.
6.2. Security services The provision of the security services and mechanisms within the model must be based on the identified vulnerabilities. The areas identified in Section 3 may be used as the starting point for identification of security services in EDI, however, some additional vulnerabilities which may appear in E D I M S environment and which are not currently identified in X.402 have to be taken into
account. Some of the vulnerabilities within EDI may be more appropriately countered by security services outside the model, i.e. in Level 3. (a) Masquerade. The services defined in M H S Security Model which counter this type of vulnerability may be used in E D I M S environment. They are: Authentication (i.e Strong Authentication according to X.509), Secure Access Management, including Security Labelling, Proof of Delivery and Proof of Submission. Security Audit Trail may also be the appropriate function for recording of the user actions on the Message Store (MS). (b) Protection against Data Manipulation may be provided by the Security Services, Connection Integrity and Content Integrity. Double enveloping could provide additional protection. (c) Message loss could occur over any peer-topeer communication link or by the failure or incorrect behaviour. The following categories of message loss are distinguished: - catastrophic message loss
Security in oalue-added networks
loss of individual messages in the MS - MTS message loss. Failure of the UA is outside this level of security. Failure of MS is potentially catastrophic and desirably needs some protection, at least in terms of detection. This should be provided by an offline archive to hold all submitted and delivered messages. Failure of any component in the MTS may similarly be catastrophic and can be protected by offline archiving messages. Loss of individual messages in the Message Store requires provision of a Secure Audit Trail to enable detection of such a loss. The service could be provided to the EDIMS user and to the MS management. Secure MS Audit Trail could be realised as a pervasive mechanism or as a part of Security Management Services. Loss of individual messages in the MTS requires provision of a Secure Audit Trail to enable detection of such a loss. Such service seems also to be useful for the EDIMS user and the I M D management. Again this service may be realised as specific in MTA Security Management Services or as a pervasive mechanism. Notification of message loss is very useful service for the user, but the connectionless nature of the MHS environment makes automatic action difficult. The Message Sequence Integrity service in the MHS Security Model does not guarantee detection of message loss since it relies on the provision of an integer value by the originator. Message stores (MS) which are outside EDIMS user domain cannot necessarily be trusted by that domain. Provision of such services to a recipient is complicated by the fact that messages may originate from a number of sources. In practice, effective operation of this service would require a common code of practice or common security policy between IMDs. The MHS services which can provide some kind of notification of message loss are confined to services offered to the originating E D I M S user. The existing services Proof of Submission and Delivery, which provide some assurance, do not operate end-to-end and do not take care if the recipient E D I M S UA and Message Store are colocated or not. Therefore, a service for Proof of Receipt (by the recipient UA) seems to be a necessary feature of the Model. (d) Denial of Ser~#ce is treated as an important vulnerability and some of the services required in the MTA Management and MTA failure protec-
31
tion could also be appropriate to counter this vulnerability in EDIMS. (e) Services which offer protection against repudiation in the EDIMS environment are concerned with formalising the transfer of responsibility. The existing MHS services non-repudiation of origin non-repudiation of submission non-repudiation of delivery proof of submission - proof of delivery cover only some areas of transfer between responsibility domains which could be of significance in an EDIMS environment, i.e. between E D I M S user domains (i.e. end-to-end) between MTS Management Domains between a Message Store and a recipient EDIMS user. An additional service definition seems to be appropriate for covering N o n - r e p u d i a t i o n / P r o o f of Transfer. Possible mechanisms for realisation of this service could be archiving of relaying information. N o n - R e p u d i a t i o n / P r o o f of Delivery do not provide protection in the case of delivery to a Message Store which is not part of the recipient EDIMS user's environment. Therefore a service for N o n - R e p u d i a t i o n / P r o o f of Retrieval service may be necessary to care for the transfer of responsibility to the recipient E D I M S UA and a protection of the MS management. Proof of Retrieval may be realised by Secure MS Audit Trail to record EDIMS user actions on the MS. Non-repudiation/ Proof of Receipt appears to be necessary for covering the transfer of responsibility to the the recipient E D I M S UA, in case the protection of the originating ED1MS user is required. Such services are relevant in case of autoforwarding, redirection, in the case when a delivery to an untrusted Message Store is present. They protect the sender from the threat that the recipient might, for his own financial advantage, choose to ignore an unwelcome message (demand for payment, for example). To counter the vulnerability of manipulation of information by the E D I M S user it may be desirable to have a service for n o n - r e p u d i a t i o n / P r o o f of Content. The MHS environment could potentially provide assistance for this service in terms of notarization services. Such notarization services could be achieved by forwarding messages via a mutually trusted third party. The transfer of re-
-
32
B. Jerrnan-Blazic
Trusted Funcliona[ity t............................
Trusted Funciionality • ...........................
i
4 ........
[
1,
+ . . . . . . . . . . . . . . . .
J EDIMS
UAII 4
Applicationl I
t- .......
JEDIMS UAII
PROOF OF RECEIPT
[
~[ RETRIEVAL
,
PROOF OF SUBMISSION
I
I
J
Domain A
I
Domain B 4
PROOF OF TRANSFER
I •
Domain C
PROOF OF TRANSFER
Key .....
Responsibility transfer boundary Ill
Security service
Fig. 5. Transfer of responsibility within EDIMS. sponsibility within E D I M S is illustrated in Fig. 5. The use of other Security Services of MHS such as Connection Confidentiality, Content Confidentiality and Message Flow Confidentiality as well as Security Access Management and Security Labelling are also applicable in the E D I M S environment, for example for leakage of information. The double enveloping could also provide some protection against traffic analysis. A summirised overview of the additionally required Security Services in an E D I M S environment gives rise to the following list of services and pervasive mechanisms: N o n - r e p u d i a t i o n / P r o o f of receipt N o n - r e p u d i a t i o n / P r o o f of retreival N o n - r e p u d i a t i o n / P r o o f of transfer N o n - r e p u d i a t i o n / P r o o f of content Secure MS Audit Trail Secure MT Audit Trail MS Archive M D Archive Security of MTA management and routing information. The list is not exhaustive and its final content will depend on the different security policies adopted among the participating entities and the
other aspects as well, i.e. management in connection to the objectives of the third party notarization or certification bodies involved.
7. Conclusion
In the course of development of the EDI Conceptual Model a special attention has been devoted to the vulnerability of the EDI services. The vulnerability of the EDI services as well as the specific mechanisms and services required to counter the threats to E D I M S are complementary to the existing security services as defined in the Recommendation X.402. Some additional security services for E D I M S have been proposed as well as enhancement of some existing services. The security Model and the proposed Security Services would need to be constantly updated to reflect changes in technology and user requirements. It is expected that the user's primary concern will be a cost-effective solution to security. The cost of security has to be in accordance with the nature of the transferred message. In the present networks there is a reasonable correspondence between the network service provider and the type of
Securt(v in value-added networks
message conveyed. The users are o r g a n i s e d in user g r o u p s a n d the networks are relatively closed. This c o r r e s p o n d e n c e will d i s a p p e a r with a wider variety of users a n d the use of an o p e n EDI. The presented Security M o d e l c o n t a i n s an exhaustive n u m b e r of services and a lot of freedom, e n a b l i n g the b u i l d i n g up of a secure o p e n E D I in accord a n c e with the cost-effective r e q u i r e m e n t s of the users and service providers.
References [1] R. Reardon (ed.), London, 1989) 85.
Future Networks (Blenheim Online,
33
[2] M. Oifkins and D. Hitchcock, eds, The EDI Handbook (Blenheim Online, London, 1988) 4. [3] ISO/OSI Reference Model 7498/2. [4] I S O / I E C JT('I SWG-EDI documents.
Dr. Jerman-Bla~i~ graduated from the Technical University in Skopje (Yugoslavia) and holds a PhD from the University of Zagreb. She joined the ('ompurer Science Department at Jozef Stefan Institute in 1971 and since then she has been involved in computing. She is now head of a project group working in the field of computer networking and is the project manager of Y U N E T (Yugoslav Academic Network). For the last eight years she has been involved in standardization work in the field of information interchange.