idnits 2.17.1 draft-ietf-ediint-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1979 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 61 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '... 3.2.6 SOME RECOMMENDED ENCRYPTION ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 40 has weird spacing: '...rements for i...' == Line 177 has weird spacing: '... use of the I...' == Line 188 has weird spacing: '...re, and vendo...' == Line 214 has weird spacing: '...ffering some ...' == Line 220 has weird spacing: '...ffering the a...' == (56 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Working Group Chuck Shih 2 Internet Draft Mats Jansson 3 Expires: 12/96 Rik Drummond 4 Lincoln Yarbrough 6 Requirements for Inter-operable Internet EDI 8 Please direct comments to drummond@onramp.net. 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. Internet-Drafts are draft documents 17 valid for a maximum of six months and may be updated, 18 replaced, or made obsolete by other documents at any 19 time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work 21 in progress." 23 To learn the current status of any Internet-Draft, 24 please check the "1id-abstracts.txt" listing contained 25 in the Internet-Drafts Shadow Directories on 26 ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 unnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 Any questions, comments, and reports of defects or 31 ambiguities in this specification may be sent to the 32 mailing list for the EDIINT working group of the IETF, 33 using the address . Requests to 34 subscribe to the mailing list should be addressed to 35 . 37 Abstract 39 This memo is an informational document discussing the 40 requirements for inter-operable EDI, with sufficient 41 background material to give an explanation for the EDI 42 community of the Internet-related issues. 44 Table of Contents 46 1.0 INTRODUCTION 4 48 1.1 THE AUDIENCE 4 50 2.0 THE INTERNET - A BRIEF HISTORY 5 52 2.1. THE INTERNET - MYTHS AND REALITY 6 54 2.2 INTERNET ROUTING 7 56 3.0 FUNCTIONAL REQUIREMENTS 9 58 3.1 INTRODUCTION AND DEFINITIONS 9 60 3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE 61 ENCRYPTION. 9 62 3.2.1 INTRODUCTION AND DESCRIPTION 9 63 3.2.2 SYMMETRIC ENCRYPTION 10 64 3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 10 65 3.2.4 NEEDS 11 66 3.2.5 ISSUES 11 67 3.2.6 SOME RECOMMENDED ENCRYPTION ALGORITHMS 11 69 3.3 KEY MANAGEMENT - SYMMETRIC KEYS 13 70 3.3.1 INTRODUCTION AND DESCRIPTION 13 71 3.3.2 NEEDS 15 72 3.3.3 ISSUES 15 73 3.3.4 RECOMMENDATION 15 74 3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 16 75 3.4.1 INTRODUCTION AND DESCRIPTION 16 76 3.4.2 PUBLIC KEYS 16 77 3.4.3 NEEDS 16 78 3.4.4 ISSUES 16 79 3.4.5 RECOMMENDATIONS 16 81 3.5 CONTENT INTEGRITY 17 82 3.5.1 INTRODUCTION AND DESCRIPTION 17 83 3.5.2 NEEDS 18 84 3.5.3 ISSUES 18 85 3.5.4 RECOMMENDATIONS 18 87 3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 18 88 3.6.1 INTRODUCTION AND DESCRIPTION 18 89 3.6.2 NEEDS 19 90 3.6.4 EDITOR'S RECOMMENDATIONS 20 92 3.7 SECTION: SIGNED RECEIPT OR NON REPUDIATION OF RECEIPT20 93 3.7.1 INTRODUCTION AND DESCRIPTION 20 94 3.7.2 NEEDS 21 95 3.7.3 RECOMMENDATIONS 21 97 3.8 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 22 98 3.8.1 INTRODUCTION AND DESCRIPTION 22 99 3.8.2 GATEWAY FUNCTIONS 22 101 3.9 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC 102 SERVICES 22 103 3.9.1 INTRODUCTION AND DESCRIPTION 22 104 3.9.2 NEEDS 22 105 3.9.3 ISSUES 23 106 3.9.4 RECOMMENDATION 23 108 4.0 TRACKING AND ERROR HANDLING BASICS 23 110 4.1 INTRODUCTION 23 112 4.2 SECTION: TRANSMISSION SUCCESSFULLY TRANSLATED FROM 113 INTERNAL FORMAT TO STANDARD EDI FORMAT 24 114 4.2.1 NEED 24 115 4.2.2 RECOMMENDATIONS 24 117 4.3 SECTION: TRANSMISSION SUCCESSFULLY ENCRYPTED, SIGNED 118 AND SENT 24 119 4.3.1 NEED 24 120 4.3.2 RECOMMENDATIONS 25 122 4.4 SECTION: TRANSMISSION SUCCESSFULLY RECEIVED 25 123 4.4.1 NEED 25 124 4.4.2 RECOMMENDATIONS 25 126 4.5 SECTION: TRANSMISSION SUCCESSFULLY TRANSLATED BY 127 RECEIVER 25 128 4.5.1 NEED 25 129 4.5.2 RECOMMENDATIONS 25 131 4.6 DETECTION AND RECOVERY OF DELAYED OR LOST 132 TRANSMISSIONS 25 133 4.6.1 NEED 25 134 4.6.2 RECOMMENDATIONS 26 136 4.7 DETECTION AND HANDLING OF DUPLICATE TRANSMISSIONS 26 137 4.7.1 NEED 26 139 APPENDIX A - A CONPARISON OF SECURITY PROTOCOLS 27 141 1.0 Introduction 143 Electronic Data Interchange (EDI) is a set of protocols 144 for conducting highly structured inter-organization 145 exchanges, such as for making purchases or initiating 146 loan requests. The initial RFC1767 defined the method 147 for packaging EDI X12 and UN/EDIFACT transaction sets in 148 a MIME envelope. However, several additional 149 requirements for obtaining multi-vendor, inter-operable 150 service, over and above how the EDI transactions are 151 packaged, have come to light since the effort concluded. 152 These currently revolve around security issues such as 153 EDI transaction integrity, confidentiality and non- 154 repudiation in various forms. Additional requirements 155 that mimic many of the heading fields found in X.435 EDI 156 messages (e.g., Interchange Sender, Interchange 157 Recipient, Interchange Control Reference, Communications 158 Agreement ID, and Syntax Identifier) are also needed to 159 support efficient exchanges by gateways and Value Added 160 Networks. Standards in these and other areas are 161 necessary to ensure inter-operability between EDI 162 packages over the Internet. Various technologies already 163 exist for these additional features and the primary 164 requirement is to review and select a common set of 165 components for use by the EDI community when it sends 166 EDI over the Internet. In effect, the effort is to 167 provide an EDI over the Internet Informational Document 168 and an Applicability Statement Document. 170 This document's current focus is on EDI MIME content 171 transported using SMTP (Simple Mail Transport Protocol), 172 the Internet's mail or messaging system. 174 Traditional VAN connectivity is slow and expensive. The 175 Internet promises lower cost usage and is more easily 176 accessible than traditional methods of communications. 177 The predominant problem with the use of the Internet 178 for EDI is interoperability between vendor products, 179 specifically in the areas of integrity, confidentiality, 180 signature, and non-repudiation. The EDIINT working 181 group's focus is to recommend solutions for each of 182 these areas using existing standards whenever possible. 184 1.1 The Audience 185 The audience for this document consists of persons 186 directly or indirectly involved in EDI communications 187 decisions, companies trading EDI documents today or in 188 the future, and vendors developing and marketing EDI 189 products. Also included in the audience for this 190 document, are people providing services and consulting 191 to the EDI community. 193 2.0 The Internet - A Brief History 194 The Internet is a world-wide collection of computers, 195 routers, and networks, connected together using the 196 TCP/IP suite of protocols. The Internet itself is not a 197 network, but a collection of networks. The Internet was 198 designed to be decentralized, with no single authority 199 needed to run it. All hosts on the Internet can 200 communicate with one another as peers, and all of the 201 communications protocols are "open" -- the standards are 202 in the public domain, and the standardization process is 203 open to anyone willing to put in the hard work to help 204 define them. 206 One consequence of this standards "openness" is that the 207 Internet can accommodate many different kinds of 208 machines (toasters for example). Its protocols -- the 209 TCP/IP suite - have therefore become the de facto 210 standards for heterogeneous computer networking. At one 211 level, the Internet is a physical collection of 212 computers connected by common protocols. At another 213 level though, the Internet can be thought of as a 214 distributed medium, offering some important advantages 215 for doing EDI: for instance, the Internet has hundreds 216 of thousands of connected global hosts, and tens of 217 millions of users. The Internet offers a flat rate, 218 volume and time-of-day independent pricing structure for 219 data transmission. The Internet is highly redundant, 220 offering the ability to route data along alternate 221 paths. The Internet's decentralized structure makes 222 adding new hosts relatively easy -- it scales well and 223 supports high bandwidth communications technologies. 225 2.1. The Internet - Myths and Reality 227 The Internet had its beginnings in 1969 as an 228 experimental U.S. Defense Department network called 229 ARPANET. The network was built to facilitate research on 230 how to construct networks that could withstand outages 231 to part of the network, but continue to function. 232 Network reliability was a fundamental design point when 233 developing the architecture and protocols associated 234 with the Internet. From the premise that the network was 235 inherently unreliable (parts of it could be destroyed at 236 any moment) emerged a design that was both robust and 237 reliable. Early on, the networks comprising the 238 Internet were primarily those from government agencies 239 and educational institutions. Access to the Internet was 240 pretty much available only to computer science 241 researchers, and government employees and their 242 contractors. 244 In 1986, the National Science Foundation, in order to 245 provide access to what was then a scarce resource, put 246 together an initiative to link five super-computer 247 centers together using the TCP/IP protocols. Two very 248 important results of the NSFNET initiative were the 249 upgrading of the Internet's infrastructure with ever 250 more powerful processors and higher speed links, and 251 expansion of access to a larger user community. The 252 1990's has seen the continual upgrading of the Internet 253 infrastructure and its expansion to new constituencies 254 outside the traditional government and university 255 research community. Commercial interests are now the 256 largest as well as the fastest growing segment of the 257 Internet. 259 Commercial Internet providers, such as Performance 260 Systems International (PSI), and UUNET (the Alternet 261 network), have emerged from the collection of 262 intermediate-level networks that came into being as a 263 result of the NSFNET initiative. The national long 264 distance carriers such as MCI, AT&T, and Sprint all 265 provide commercial Internet services. These commercial 266 providers, called Internet Service Providers or ISPs for 267 short, make available Internet connectivity and various 268 other Internet services to their clients. The perception 269 of the Internet as experimental, and primarily used by 270 and for educational and research activities is 271 rooted in its past, and does not reflect today's 272 situation. The growth in commercial access to the 273 Internet, along with the growth of the ISPs, is 274 radically changing the Internet's network composition. 276 The design and architecture underlying the Internet has 277 proven its robustness by scaling to unprecedented 278 proportions. The Internet is reliable from several 279 perspectives: 281 (1) Technologically, the TCP/IP suite of protocols and 282 the architecture underlying the Internet are stable and 283 mature. 285 (2) Product implementations based on the TCP/IP suite 286 are also stable and mature. 288 (3) Internet routing is dynamic, so packets sent through 289 the Internet get to their destinations even if there are 290 network outages along the way. 292 (4) The commercial ISP administered portions of the 293 Internet, provide essentially the same level of network 294 reliability, availability, monitoring, throughput, 295 implementation and support services as existing EDI 296 Value Added Networks (VANS), but at a lower cost and 297 with higher bandwidth. 299 Although the Internet is reliable, low-cost, highly 300 accessible, supports high bandwidth communications, and 301 is technically mature, there are still some valid 302 concerns relating to the use of the Internet for EDI. 303 These concerns revolve primarily around security, 304 message tracking, audit trails, and authorization. Some 305 of the concerns, encryption for instance, are of a 306 general nature and not specific to the Internet-- 307 encryption may be required regardless of what type of 308 network is traversed. Other concerns, such as tracking, 309 arise because they are required by EDI, and supported by 310 existing EDI Value Added Networks. 312 2.2 Internet Routing 313 By using a common network trace program called 314 Traceroute, the route traversed by a packet from a 315 source host to a destination host on the Internet may be 316 followed. Tracing routes on the Internet yield some 317 interesting characteristics. As expected, the routes 318 traversed go through the networks administered by the 319 ISPs of each of the trading partners. Each route 320 consists of multiple nodes through each network. The 321 route can vary but that is not the typical case. The IP 322 packets are delivered reliably, and within a specified 323 period of time. When a reputable commercial ISP is used, 324 none of the nodes in the route are administered by 325 government or educational entities. 327 By looking at Internet network traces, we can conclude 328 that the Internet does a very good job of getting 329 packets from a source to destination. However, between 330 the source and the destination, the packets are routed 331 through many intermediate nodes. It is at the 332 intermediate nodes where anyone on one of the machines 333 that handles the packets can re-assemble the packets 334 that make up the EDI Interchange and can read it, copy 335 it, alter it, or delete it. In the case where the EDI 336 Interchange is carried using an e-mail transport (SMTP), 337 the situation could arise where the message cannot be 338 delivered to the final recipient and the message must 339 be stored at the intermediate node. Once again, the 340 message is susceptible to any number of security 341 threats. 343 The likelihood of security attacks, (especially if going 344 through intermediate nodes administered by a quality 345 ISP) are quite low, and practically speaking, may be 346 quite difficult. Nonetheless, since the possibility 347 exists, it is a concern - particularly if the packets 348 contain high value or sensitive EDI, or electronic 349 commerce transactions. 351 The Internet is being singled out in this discussion 352 because our focus is EDI over the Internet, but the 353 possibility of security threats and administrative 354 glitches exist even if the EDI Interchanges go through 355 an EDI VAN. It really is a matter of management of the 356 machines that make up the intermediate nodes in any 357 network that is at issue. There are measures that can 358 be taken to defend against security concerns while an 359 EDI interchange is in transit. These security measures 360 are essential requirements when doing EDI over the 361 Internet. Each of the security measures is described, 362 issues are discussed, and recommended solutions given. 364 3.0 Functional Requirements 366 3.1 Introduction and Definitions 367 The following sections describe the functional and 368 inter-operability requirements, as well as some of the 369 practical considerations of sending and receiving EDI 370 transactions on the Internet. It is assumed that the 371 reader is generally familiar with EDI. 373 3.2 Standard Encryption Algorithms and World-Wide 374 Encryption. 375 3.2.1 Introduction and Description 376 The goal of encryption is to turn otherwise readable 377 text into something that cannot be read, and therefore 378 understood. By making the text unintelligible, 379 encryption discourages anyone from reading or copying 380 the EDI Interchange while it is in transit between the 381 trading partners. Encryption conveys confidentiality to 382 the EDI Interchange. Traffic analysis is always 383 possible, since many times, header information is not 384 encrypted. (Traffic analysis is the analysis of header 385 information in order to derive useful information from 386 it) 388 Encryption is based on two components: an algorithm and 389 a key. An algorithm is a mathematical transformation 390 that takes plain-text or other intelligible information 391 and changes it into unintelligible cipher text. The 392 inverse mathematical transformation, back to the 393 original from the cipher text is also done, and is 394 called decryption. In order to encrypt the plain text, a 395 key is used as input in conjunction with an encryption 396 algorithm. An algorithm can use one of any of a large 397 number of possible keys. The number of possible keys 398 each algorithm can support depends on the number of bits 399 in the key. For instance, if the key length is 40, then 400 2 to the n, where n is the number of bits in the key, 401 results in 1,000,000,000,000 possible key combinations, 402 with each different key causing the algorithm to produce 403 slightly different cipher output. 405 An encryption algorithm is considered secure if its 406 security is dependent only on the length of its key. 407 Security cannot be dependent on the secrecy of the 408 algorithm, the inaccessibility of the cipher or plain 409 text, or anything else--except the key length. If this 410 were true about a particular algorithm, then the most 411 efficient -- and only -- attack on that algorithm is a 412 brute-force attack, whereby all key combinations must 413 be tried in order to find the one correct key (this is 414 true for symmetric encryption algorithms, asymmetric 415 algorithms work a little differently, and are explained 416 in greater detail later). So, by specifying a long 417 enough key length n, even a brute-force attack on a 418 secure algorithm can be made completely non-feasible. 420 3.2.2 Symmetric Encryption 421 Encryption algorithms whereby two trading partners must 422 use the identical key to encrypt and decrypt the EDI 423 Interchange are called symmetric encryption algorithms. 424 Put another way, if an EDI Interchange is encrypted with 425 one key, it cannot be decrypted with a different key. 426 The key used in most symmetric encryption algorithms is 427 just a random bit string, n bits long. These keys are 428 often generated from random data derived from the source 429 computer. 431 The use of symmetric encryption simplifies the 432 encryption process, each trading partner does not need 433 to develop and exchange secret encryption algorithms 434 with one another (which incidentally would be a near 435 impossible task). Instead, each trading partner can use 436 the same encryption algorithm, and only exchange the 437 shared, secret key. 439 There are drawbacks however with symmetric encryption 440 schemes; a shared secret key must be agreed upon by both 441 parties. If a trading partner has n trading 442 relationships then n secret keys must be maintained, 443 one for each trading partner. Symmetric encryption 444 schemes also have the problem that origin or destination 445 authenticity (non-repudiation of origin, delivery and 446 receipt) cannot be proved. Since both parties share the 447 secret encryption key, any EDI Interchange encrypted 448 with a symmetric key, could have been sent by either of 449 the trading partners. By using what is called public key 450 cryptography, which makes use of asymmetric encryption 451 algorithms, the non-repudiation of origin, delivery and 452 non-repudiation of receipt issues can be solved. 454 3.2.3 Asymmetric Encryption - Public-key Cryptography 455 Public-key cryptography is based on the concept of a key 456 pair. Each half of the pair (one key) can encrypt 457 information that only the other half (one key) can 458 decrypt. The key pair is designated and associated to 459 one, and only one, trading partner. One part of the key 460 pair (the private key) is only known by the designated 461 trading partner; the other part of the key pair (the 462 public key) is published widely but is still 463 associated with the designated trading partner. 465 The keys are used in different ways for confidentiality 466 and digital signature. Both confidentiality and 467 signature depend on each entity having a key pair that 468 is identified only with them and each party keeping one 469 pair of their key pair secret from all others. 471 Signature works as follows: Trading Partner A uses her 472 secret key to encrypt part of a message, then sends the 473 encrypted message to Trading Partner B. B gets Trading 474 partner A's public key (anyone may get it) and attempts 475 to decrypt the encrypted part of Trading partner A's 476 message. If it decrypts, then Trading Partner B knows it 477 is from A--because only A's public key can decrypt a 478 message encrypted with A's private key, and A is the 479 only one who knows her private key. 481 Confidentiality applies the asymmetric key pair, but in 482 a different manner than signature. If Trading partner A 483 wishes to send a confidential message to Trading Partner 484 B she would apply the key pair as follows: Trading 485 partner A would retrieve Trading partner B's public key, 486 and encrypt the message with it. When Trading Partner B 487 receives the message, she would decrypt the message 488 with her private key. Only her private key can decrypt 489 information that was encrypted with her public key. In 490 other words, anything encrypted with B's public key can 491 only be decrypted with B's private key. 493 Since public-key encryption algorithms are considerably 494 slower than their symmetric key cousins, they are 495 generally not used to do the actual encryption of what 496 could be large EDI Interchanges. For instance, RSA Data 497 Securities, Inc. estimates that software encryption 498 using DES (a symmetric key algorithm) is 100 times 499 faster than software encryption using RSA (a public-key 500 encryption algorithm from RSA Data Securities, Inc.). 501 Hardware encryption using DES is anywhere from 1,000 to 502 10,000 times faster than hardware encryption using the 503 RSA asymmetric encryption algorithm. Instead of being 504 used for bulk encryption, public-key encryption 505 algorithms are used to encrypt symmetric encryption 506 keys. They are also used as an efficient means of 507 exchanging and managing symmetric encryption keys. 509 3.2.4 Needs 510 In order to provide confidentiality for EDI Interchanges 511 on the Internet, a standard encryption algorithm(s) and 512 key length(s) must be specified. For inter-operability 513 to occur between two trading partners, the encryption 514 algorithm and key lengths must be agreed upon either 515 before hand or within an individual transaction. 517 3.2.5 Issues 518 * When choosing an encryption algorithm, the following 519 criteria should be considered; how secure the algorithm 520 is; how fast implementations of the algorithm are; the 521 availability of the algorithms for international as well 522 as domestic use; the availability of APIs and tool kits 523 in order to implement the algorithms; and the frequency 524 of the use of the algorithm in existing 525 implementations. 527 * Sufficient key lengths must be chosen with regard to 528 the value of the EDI Interchange so that brute-force 529 attacks are not worth the time or effort compared to the 530 value of the Interchange. 532 3.2.6 Some Recommended Encryption Algorithms 533 DES: The most widely used commercial encryption 534 algorithm is DES. It is widely used in the banking 535 industry for Electronic Funds Transfer (EFT). DES is 536 also a U.S. government encryption standard. DES is in 537 the public domain, which means anyone can implement the 538 algorithm, including those in the international 539 community. DES was designed for, and is used for bulk 540 encryption of data. DES is prohibited by the U.S. 541 government for export. 543 The DES algorithm has been analyzed by cryptographers 544 since the mid-1970s, and is considered secure: in other 545 words, the security of DES is completely dependent on 546 the length of its key. DES specifies a 56 bit key, so 2 547 to the 56th or 10 to the 16th keys are possible. A 548 brute force attack, which means trying every single key 549 to decrypt 8 bytes of known cipher-text into its 550 corresponding 8 bytes of known plain-text is the best 551 attack on the algorithm. 553 The amount of time and money required to mount a 554 successful brute force attack varies with the processing 555 power used - and how lucky the attacker may be in 556 generating a key that is close to the one used to 557 encrypt the original EDI Interchange. Some estimates 558 which have been put forth claim that a $1 million dollar 559 hardware based, brute-force attack on DES would take 3.6 560 hours to recover the DES key. A corresponding $1 561 million dollar software based brute-force attack on DES 562 would however take 3 years. As the price/performance of 563 processors decrease, a 56 bit key becomes less and less 564 adequate in protecting EDI Interchanges of extreme 565 value. Triple-DES, an algorithm with longer key length 566 (discussed below) should be used in such cases. 568 Triple-DES is a variant on DES that encrypts the EDI 569 Interchange 3 times, with 2 independent 56 bit keys, 570 giving it an effective key length of 112 bits. This 571 makes a brute-force attack on Triple-DES not feasible. 572 DES and Triple-DES actually can be implemented in 3 573 different modes. It is recommended that DES and Triple- 574 DES be used in Cipher Block Chaining (CBC) mode, which 575 gives added protection by making each cipher-text block 576 depend on each other, so changes in the cipher-text can 577 be detected. 579 RC2 and RC4: RC2 and RC4 are proprietary symmetric 580 algorithms of RSA Data Security. RC2 and RC4 unlike DES 581 are variable-key length algorithms. By specifying 582 differing key lengths, RC2 and RC4 can be configured to 583 provide greater or lesser security. RC2 and RC4 are 584 alternatives to DES and have special export status, 585 whereby 40 bit versions of RC2 and RC4, and 56 bit 586 versions for foreign subsidiaries and overseas offices 587 of U.S. companies have expedited export approval from 588 the U.S. government. RSA claims that RC2 and RC4 are 589 faster than DES when implemented in software. Several e- 590 mail products such as Lotus Notes and Apple's Open 591 Collaboration Environment make use of these algorithms. 592 It is recommended that a key length of at least 128 bits 593 be used when using RC2 and RC4. A key length of 128 594 bits would make a brute-force attack impossible now and 595 for the foreseeable future. 597 IDEA: The International Data Encryption Algorithm was 598 published in 1991. The symmetric algorithm is an 599 iterated block cipher with a 64-bit block size and a 128- 600 bit key size. The key length of IDEA is over twice that 601 of DES and is longer than triple-DES. The IDEA algorithm 602 is patented in both the United States and abroad. The 603 IDEA algorithm in CBC mode is used by PGP (Pretty Good 604 Privacy - a popular electronic mail security program) 605 for encryption. Individual users of PGP have a royalty 606 free license to use the IDEA algorithm. 608 There are many encryption algorithms that are secure and 609 can provide confidentiality for an EDI Interchange. For 610 interchanges that carry less value, 40-bit RC2 or 56-bit 611 DES are probably adequate. For more valuable 612 interchanges, use of Triple-DES, IDEA, or longer key 613 length RC2 or RC4 is recommended. 615 DES is currently in wide-spread use, and Triple-DES is 616 projected to be in wide-spread use, as the 56-bit DES 617 key limitation becomes less and less adequate. The DES 618 algorithm is available for implementation outside the 619 U.S., and the DES algorithm has been studied for a long 620 time, and has been found to be secure. RC2 and RC4 are 621 useful because they allow the security of the 622 encryption - the key length specification, to be 623 configurable. (the RC2 and RC4 algorithms are 624 proprietary, they can be exported outside the U.S. IDEA 625 is a newer algorithm and has not been studied as much as 626 DES. It has an adequate key-length, though it is not 627 configurable. Indications are that IDEA is a secure 628 algorithm and its use in PGP makes it the most widely 629 used encryption algorithm for Internet electronic mail. 631 3.3 Key Management - Symmetric Keys 632 3.3.1 Introduction and Description 633 The use of symmetric encryption is based on a shared 634 secret. Two trading partners using a symmetric 635 encryption algorithm must be able to do the following; 636 generate a random symmetric key and agree upon its use; 637 securely exchange the symmetric key with one another; 638 set up a process to invalidate a symmetric key that has 639 been compromised or needs changing. Each trading partner 640 would then need to do this with each and every one of 641 their trading partners. Management and distribution of 642 symmetric keys can become an insecure and cumbersome 643 process. 645 Pure symmetric key management schemes also have the 646 problem that origin authenticity cannot be proved. Since 647 two parties share a secret encryption key, any EDI 648 Interchange encrypted with a symmetric key, could have 649 been sent by either of the trading partners who have 650 knowledge of the key. 652 Using public-key cryptography, the management of 653 symmetric keys is simplified and made more secure. 654 Trading partners do not need to agree on secret 655 symmetric keys as part of the trading partner 656 relationship. Public-key cryptography also solves the 657 origin authenticity problem that pure symmetric key 658 management schemes have. 660 By generating a unique symmetric encryption key for each 661 EDI Interchange, and using public key cryptography, 662 trading partners no longer need to secretly agree on a 663 shared symmetric key in the trading partner 664 relationship. A symmetric key can be randomly generated 665 by the software for each EDI Interchange between trading 666 partners. Since a unique symmetric key is generated for 667 each EDI Interchange, key maintenance is not needed. 668 Trading partners do not need to invalidate compromised 669 or expired keys. Each symmetric key is used only one 670 time. 672 Additional security is also realized using the method 673 described above; in the unlikely event that one of the 674 symmetric keys is compromised, only one EDI transaction 675 is affected, and not every transaction in the trading 676 partner relationship. Public-key encryption also 677 provides a secure way of distributing symmetric keys 678 between trading partners. Since only the receiving 679 trading partner has knowledge of her private asymmetric 680 key, she is the only one that can decrypt the symmetric 681 key encrypted with her public asymmetric key - and is 682 thus the only one who can use the symmetric key to 683 decrypt the EDI Interchange. 685 To impart confidentiality to an EDI Interchange which 686 trading partner ABC sends to trading partner XYZ, the 687 following steps would be performed: 689 1) The EDI Translator outputs the EDI Interchange. 691 2) A random symmetric key of the specified length 692 is generated. 694 3) The EDI Interchange is encrypted using the 695 randomly generated symmetric key with the chosen 696 encryption algorithm. 698 4) The random symmetric key is then encrypted 699 using 5) XYZ's, the destination's, public 700 asymmetric key. 702 The encrypted symmetric key and encrypted EDI 703 Interchange are then enveloped and sent to the 704 trading partner. 706 On the receiving side, the following steps would be 707 performed: 709 1) The symmetric key is decrypted using XYZ's 710 private asymmetric key. 712 2) The decrypted symmetric key is then used to 713 decrypt the EDI Interchange. 715 3) The decrypted EDI Interchange is then routed to 716 the EDI translator. 718 3.3.2 Needs 719 A method to manage the symmetric encryption keys used in 720 encrypting EDI Interchanges. The method should simplify 721 the generation, maintenance, and distribution of the 722 symmetric encryption keys. The method should also 723 provide a secure channel for distributing the symmetric 724 encryption keys between trading partners. 726 3.3.3 Issues 727 * Choose a public-key encryption algorithm that 728 facilitates key management of the symmetric 729 encryption keys. The symmetric encryption keys 730 should be generated on the fly for each EDI 731 Interchange. 733 * When choosing a public-key encryption algorithm, 734 the following criteria should be considered; how 735 secure the algorithm is; how fast implementations 736 of the algorithm are; the availability of the 737 algorithms for international as well as domestic 738 use; the availability of APIs and tool kits in 739 order to implement the algorithms; and the 740 frequency of the use of the algorithm in 741 existing implementations. 743 * Sufficient key lengths must be chosen with 744 regard to the value of the EDI Interchange so that 745 brute-force attacks are not worth the time or 746 effort compared to the value of the Interchange. 748 3.3.4 Recommendation 749 1) RSA is a public-key cryptography algorithm that has 750 become a de facto standard in its use for key 751 management. Its use is recommended in managing and 752 distributing symmetric encryption keys when doing EDI 753 over the Internet. The RSA public-key algorithm also 754 has the advantage that it can be used freely outside the 755 U.S. 757 2) The mathematics of RSA are complicated, but is based 758 on the difficulty in factoring large prime numbers. A 759 public-key is generated by multiplying two large prime 760 numbers together, deriving the private key from the 761 public key involves factoring the large prime number. If 762 the prime is large enough, this becomes an impossible 763 task. The RSA key length is configurable, and is 764 recommended to be at least 512 bits (154 digits long), 765 and preferably 1024 bits (or 308 digits long) or longer. 767 3.4 Key Management - Public and Private Keys 768 3.4.1 Introduction and Description 769 The use of public-key cryptography to simplify the 770 management of the symmetric encryption keys presents the 771 user with two problems; protecting the private key, and 772 binding a trading partner's identity to his public key. 773 Most likely the user will never know what his private 774 key is. The software will generate a random private key, 775 encrypt it, and store it in a file or database. The 776 private key is accessed indirectly by the user through 777 access to the software. User access to the software is 778 generally controlled by a password, pass-phrase, and/or 779 certain access rights. These are internal security 780 policies, and are company specific. It is important to 781 control the access to the private key since any 782 unauthorized access can lead eventually to the 783 revocation of the corresponding public key. 785 3.4.2 Public Keys 786 A public key is used by a originating trading partner 787 to encrypt a symmetric key, and as we'll discuss later, 788 by a receiving trading partner to do authentication and 789 non-repudiation of origin and receipt. Trading partners 790 exchange public keys using a public key certificate. 791 A public key certificate is defined in the X.509 792 standards, and is a binding of an entity's 793 distinguished name (a formal way for identifying someone 794 or something in the X.500 world, in our case it would be 795 a trading partner) to a public key. A certificate also 796 contains the digital signature of the issuer of the 797 certificate, the identity of the issuer of the 798 certificate, and an issuer specific serial number, a 799 validity period for the certificate, and information to 800 verify the issuer's digital signature. Certificate 801 issuers are called Certification Authorities, and are 802 trusted by both trading partners. In essence, a 803 certificate is a digitally notarized binding of trading 804 partner to public key. 806 3.4.3 Needs 807 Adoption of a trust model and use of Certification 808 Authorities for verifying public key certificates. 810 3.4.4 Issues 811 Lack of Certification Authorities. To date only Verisign 812 has stepped forward as a Certification Authority. The 813 U.S. Postal Service is interested in becoming a 814 Certification Authority but is in the process of 815 implementing the services. 817 3.4.5 Recommendations 818 Since there already exists a trust relationship between 819 EDI trading partners, until Certification Authorities 820 become more prevalent, and the formats and protocols for 821 interacting with Certification Authorities become 822 standardized, it is recommended that the trading 823 partners self-certify each other and exchange public 824 keys as part of the trading partner relationship. The 825 self-certified certificate should still be exchanged 826 between trading partners in X.509 v3 format, so 827 migration to exchange of notarized certificates is made 828 easier. 830 Since the formats and protocols for use in registering, 831 requesting, and revoking certificates have not been 832 standardized, the use of PCKS #10 and S/MIME is one 833 recommendation. Also, PGP with its circle of trust is 834 another valid option. We recommend that S/MIME be 835 tested for interoperability first, and that PGP v3.0 be 836 tested later. Implementation of the standards for 837 Certification Authority interactions being developed by 838 the IETF-pkix (public-key infrastructure X.509) work 839 group should eventually be adopted. 841 3.5 Content Integrity 842 3.5.1 Introduction and Description 843 Encryption guarantees the confidentiality of an EDI 844 Interchange. Content integrity guarantees that the 845 receiving trading partner gets the EDI Interchange in 846 its originally sent state. Content integrity assures 847 that no modifications - additions, deletions, or changes 848 - have been made to the EDI Interchange when it is in 849 transit between trading partners. 851 Content integrity is achieved if the sender includes 852 with the EDI Interchange, an integrity control value. 853 This value can be computed by using an appropriate 854 cryptographic algorithm to 'fingerprint' the EDI 855 Interchange. These cryptographic algorithms are called 856 one-way hash functions or message integrity checks. 857 Similar to encryption, a one-way hash function turns the 858 EDI intelligible plain-text into something 859 unintelligible. 861 Unlike encryption algorithms however, one-way hash 862 functions can't be decrypted. One-way hash functions 863 are constructed so the probability is infinitely small 864 that some arbitrary length piece of plain-text can be 865 hashed to a particular value, or that any two pieces of 866 plain-text can be hashed to the same value. One-way hash 867 values are usually from 112 to 160 bits long. The 868 longer the hash value, the more secure it is. 870 One-way hash functions don't require a key, and the 871 algorithm used must be agreed upon by the trading 872 partners. To insure content integrity, the sending 873 trading partner needs to calculate a one-way hash value 874 of the EDI Interchange. This value is unique and 875 'fingerprints' the EDI Interchange. The sending trading 876 partner sends the hash value along with the EDI 877 Interchange. The receiving trading partner using the 878 same one-way hash function calculates the hash value for 879 the received EDI Interchange. If the received hash value 880 matches the calculated hash value, then the receiving 881 trading partner knows that the EDI Interchange has not 882 been tampered with. 884 3.5.2 Needs 885 Choice of a one-way hash algorithm to calculate the hash 886 value required to insure content integrity. 888 3.5.3 Issues 889 The one-way hash algorithm should be secure, publicly 890 available, and should produce hash values of at least 891 128 bits. 893 3.5.4 Recommendations 894 MD5 is a one-way hash function that is publicly 895 available, produces a 128 bit hash value called a 896 Message Digest. It is widely used or recommended by most 897 e-mail security programs and specifications, such as 898 PEM, PGP, and S/MIME. 900 3.6 Authentication and Non-Repudiation of Origin 901 3.6.1 Introduction and Description 902 Encryption guarantees confidentiality. Applying a one- 903 way hash function guarantees content integrity. Both 904 authentication and non-repudiation of origin guarantee 905 the identity of the sender of the EDI Interchange. Non- 906 repudiation of origin, identifies the original sender, 907 and is the same as authentication when the EDI 908 Interchange is sent point-to-point, i.e. when there is 909 no forwarding involved. Authentication and non- 910 repudiation of origin discourages any spoofing attacks 911 that may occur while the EDI Interchange is in transit 912 between the trading partners. 914 Both authentication and non-repudiation of origin are 915 accomplished using digital signatures. A digital 916 signature is another application of public-key 917 cryptography, and is explained in more detail in the 918 following paragraphs. 920 Up to this point, a receiving trading partner's public- 921 key has been used to encrypt a symmetric key, and this 922 symmetric key could only be decrypted by the receiving 923 trading partner's private key. However the roles of the 924 private and public keys can be reversed, so that you 925 encrypt with the private key, and decrypt with the 926 public key. Again the keys are reciprocal, if encryption 927 is done with the private key, decryption can only be 928 done with the public key. 930 Since only trading partner ABC knows her own private- 931 key, only trading partner ABC can encrypt something with 932 that private-key. Encryption with a private key 933 therefore has the effect of uniquely identifying the 934 person or entity doing the encryption. It is in effect, 935 a digital signature. Since ABC's public-key is known to 936 all his trading partners, they can all decrypt something 937 encrypted with ABC's private-key. Decryption using ABC's 938 public-key therefore has the effect of authenticating 939 ABC as the trading partner that did the encryption, and 940 it in effect verifies ABC's digital signature. ABC also 941 cannot say that he did not do the encryption, since he 942 is the only one with knowledge of his private key. In 943 this way, non-repudiation of origin is achieved. 945 So what should a trading partner sign or encrypt with 946 his private-key to guarantee authentication and non- 947 repudiation of origin? Remember, public-key encryption 948 algorithms are not meant to encrypt something very 949 large, they are too slow for that. The symmetric key is 950 encrypted with a public-key, and encrypting this with a 951 private-key is not recommended, as this would allow 952 other than the authorized recipient to decrypt the EDI 953 Interchange. Since a one-way hash value is pretty small, 954 usually only between 112-160 bits long, it is a natural 955 choice for what can be digitally signed. If the message 956 integrity value was signed with a private key, then not 957 only could authentication and non-repudiation of origin 958 be guaranteed, but message integrity as well. 960 3.6.2 Needs 961 Choice of a digital signature algorithm. 963 3.6.3 Issues 965 When choosing a digital signature algorithm, the 966 following criteria should be considered; how secure the 967 algorithm is; how fast implementations of the algorithm 968 are; the availability of the algorithms for 969 international as well as domestic use; the availability 970 of APIs and tool kits in order to implement the 971 algorithms; and the frequency of the use of the 972 algorithm in existing implementations. 974 Sufficient key lengths must be chosen with regard to the 975 value of the EDI Interchange so that brute-force attacks 976 are not worth the time or effort compared to the value 977 of the Interchange. 979 3.6.4 Editor's Recommendations 980 In addition to using RSA to encrypt keys, it is 981 recommended that RSA also be used for digital 982 signatures. Again, the RSA algorithm has the advantage 983 that it can be used freely outside the U.S. 985 3.7 Section: Signed Receipt or Non Repudiation of Receipt 986 3.7.1 Introduction and Description 987 The signed receipt (or alternately Non Repudiation of 988 Receipt), is a receipt acknowledgment sent by the 989 receiving trading partner to the sending trading partner. 990 The receipt is used to solve the following issues when 991 doing EDI over the Internet: 993 * Lack of mailbox delivery notification within the 994 Internet standards, though these are currently 995 being addressed within RFCs 1891-1894. 997 * Provide the equivalent of VAN mailbox delivery 998 notification. 1000 * Provide the equivalent of VAN mailbox pick-up 1001 notification. 1003 * Provide the equivalent of VAN mailbox 1004 authentication. 1006 * Detect the situation where EDI Interchanges are 1007 maliciously deleted, or are not delivered by the 1008 transport. 1010 Receipt of a signed receipt is an implicit 1011 acknowledgment of successful mailbox delivery. It is 1012 also an explicit acknowledgment that the Interchange was 1013 retrieved from the mailbox--pick-up notification. By 1014 having the receiver sign the receipt, it authenticates 1015 that the intended receiver picked up the EDI Interchange- 1016 -mailbox authentication--and that the intended receiver 1017 verified the integrity of the EDI Interchange, and the 1018 identity of the sender. By returning the original one- 1019 way hash value (or original message) back in the signed 1020 receipt, the sender can reconcile the acknowledged EDI 1021 Interchange with what was sent. 1023 3.7.2 Needs 1024 Define the format and protocol for the signed receipt 1025 so that it provides the following: 1027 * Implicit acknowledgment of mailbox delivery of 1028 the EDI Interchange to the recipient. 1030 * Explicit acknowledgment that the receiver has 1031 authenticated the sender and verified the 1032 integrity of the sent EDI Interchange. 1034 * Guarantees non-repudiation of receipt when the 1035 receipt acknowledgment is digitally signed by the 1036 receiving trading partner. 1038 * Provide information in the signed receipt so 1039 it can be used for tracking, logging, and 1040 reconciliation purposes. 1042 The re-transmission timer, and retry count to detect 1043 lost Interchanges should be recommended, but needs to be 1044 configurable. Additionally, it should be specified what 1045 the receiver should do when it receives duplicate 1046 Interchanges, and what the sender should do when it 1047 receives duplicate receipt acknowledgments. The signed 1048 receipt should be applicable to more than just EDI. 1050 3.7.3 Recommendations 1051 The syntax for a signed receipt should not be specific 1052 to EDI, since many of the uses of a signed receipt can 1053 be broadly applied to other MIME encapsulated objects. 1054 It is recommended that the results of the IETF receipt 1055 working group be adopted for use as a signed receipt. 1056 The receipt working group has published an Internet 1057 draft--draft-ietf-receipt-mdn-01--which can be obtained 1058 off of the IETF World Wide Web site. The EDIINT working 1059 group is working with the receipt working group to 1060 specify additional disposition-field values, as well as 1061 specification of how the MDN (message disposition 1062 notification) should be used within an EDI environment. 1063 Specifically, within an EDI environment, requests for 1064 message disposition requests cannot be silently 1065 ignored. In addition, if non-repudiation of receipt is 1066 agreed to by the trading partners, the original message 1067 sent must be returned in the third component of the 1068 message disposition notification--digitally signed by 1069 the receiver of the EDI Interchange. The time-out and 1070 retry values for the message disposition notification 1071 should be recommended, but needs to be configurable. 1072 Duplicates should be checked by the UA and discarded. 1073 Until the receipt Internet draft is complete, a 1074 combination of RFC1847 and draft-ietf-receipts-mdn 1075 should be used to implement this functionality 1077 3.8 EDI Object Boundaries and Transaction Privacy 1078 3.8.1 Introduction and Description 1079 The specification by this work group applies to the EDI 1080 Interchange level, and not the group or document level. 1081 Any security services, packaging, transport, or non- 1082 repudiation services are assumed to be applied to an EDI 1083 Interchange. Unlike the X12.58 and UN/EDIFACT 9735-5 and 1084 9735-6 security standards, the security services cannot 1085 be applied at a group or document level. The purpose of 1086 the specification is to move these services out of the 1087 translator, and into the "communications" subsystem. The 1088 "communications" subsystem should know as little about 1089 the structure of the EDI data as possible. 1091 The entire EDI Interchange including the enveloping 1092 headers (ISA/IEA or UNA/UNB/UNZ) are also encrypted. 1093 Since the routing of the EDI Interchange is through the 1094 Internet, and not a VAN, the sender/receiver ids are not 1095 used in mailbox routing, so the EDI envelops can be 1096 encrypted when sending EDI over the Internet. 1098 Only one EDI Interchange is sent per e-mail message. 1100 3.8.2 Gateway Functions 1101 Situations exist whereby a VAN, or internal gateway, in 1102 order to route an EDI Interchange received on the 1103 Internet, will need to be able to access the information 1104 in the EDI envelope. The enveloping information as well 1105 as other useful gateway information may need to be 1106 copied and sent as a separate body part. It is proposed 1107 that additional fields be specified in RFC 1767 to 1108 accommodate EDI specific gateway routing requirements, 1109 and this be sent as a separate body part from the 1110 encrypted EDI Interchange. 1112 3.9 Syntax and Protocol for Specifying Cryptographic 1113 Services 1114 3.9.1 Introduction and Description 1115 Once cryptographic services are applied to EDI 1116 Interchanges, then the formats and protocols must be 1117 specified on how the cryptographic information is 1118 conveyed during the EDI message exchange. Encryption 1119 algorithm information, one-way hash algorithm 1120 information, symmetric keys, initialization vectors, one- 1121 way hash values, public-key certificates, need to be 1122 enveloped and sent along with the EDI Interchange. 1124 3.9.2 Needs 1125 Syntax and protocol for specifying EDI Interchanges that 1126 have had cryptography applied to it. Choose an existing 1127 standard and don't reinvent one. 1129 3.9.3 Issues 1130 The syntax should be transport independent so it can be 1131 used with different Internet transports. The standard 1132 should have broad support, and implementations should be 1133 available. Finally it should be international in nature. 1135 3.9.4 Recommendation 1136 The IETF EDIINT working group has put together a matrix 1137 comparing many of the different ways that EDI with 1138 cryptography applied to it can be transmitted. The use 1139 of S/MIME and PGP/MIME (version 3.0 with the elkins 1140 draft) are both viable alternatives. Each has its 1141 strengths and weaknesses as the comparison matrix brings 1142 out. 1144 The S/MIME specification allows signed, and encrypted 1145 and signed to be distinguished. The signatories in an 1146 S/MIME encrypted and signed message can be 1147 distinguished, which in certain EDI and electronic 1148 commerce situations is not acceptable. S/MIME specifies 1149 40 bit RC2 as the default encryption algorithm and key 1150 length. In some applications neither this default 1151 algorithm or key length are acceptable. S/MIME can 1152 accommodate other security algorithms and key lengths 1153 such as those recommended in section 3.3.2 however. 1155 PGP/MIME supports a set profile of security algorithms 1156 and some user configurable key lengths. PGP/MIME does 1157 not have the signatory problem as described above for 1158 S/MIME. However, PGP/MIME does not give the user as much 1159 flexibility in choosing algorithms and key lengths, 1160 although the security profile used by PGP/MIME is more 1161 than adequate to insure confidentiality, non-repudiation 1162 of origin, and message integrity. 1164 4.0 Tracking and Error Handling Basics 1166 4.1 Introduction 1167 It's important to recognize that traditional EDI via 1168 Value Added Networks have some inherent tracking 1169 mechanisms, that we have to either duplicate in Internet 1170 EDI, or decide we don't need. In Internet EDI, there is 1171 no third party to call to track a transmission after it 1172 has left one company, and before it has been received by 1173 the second company. Also, the move from VAN based EDI 1174 to Internet EDI changes the connectivity in other ways. 1175 From a more batch oriented store-and-forward technology 1176 to a more event driven routing technology. 1178 Aside from the communications between companies, 1179 "tracking" touches many other points within the trading 1180 companies. This is where the use of 997 functional 1181 acknowledgments come in, the EDIFACT CONTRL message, and 1182 the common translator tracking of sequential group 1183 control numbers. All of this needs to be considered in 1184 Internet EDI tracking. In addition, some recent 1185 developments within S/MIME warrant some analysis-- 1186 "positive acknowledgment", which refers to mail response 1187 not just if the delivery failed, but also if it 1188 succeeded. 1190 What tracking information do we really need, and where 1191 does the UA have a role in providing it? 1193 1) Transmission successfully translated from 1194 internal format to EDI standard format 1196 2) Transmission successfully encrypted and sent 1197 (The equivalence of transmission successfully 1198 forwarded to receiver's VAN mailbox.) 1200 3) Transmission successfully received by the 1201 intended receiver and successfully decrypted (The 1202 equivalence of a VAN acknowledgment that sent 1203 transmission has been picked up by the receiver.) 1205 4) Transmission successfully translated by the 1206 receiver (the EDI Interchange was determined to be 1207 syntactically correct.) 1209 5) Detection and recovery of delayed or lost 1210 transmissions. 1212 6) Detection and handling of duplicate 1213 transmissions. 1215 7) Detection and handling of out-of-sequence 1216 transmissions. 1218 The question of what the UA needs to track as compared 1219 to what the EDI translator tracks is addressed in the 1220 following sections. 1222 Needs, issues and recommendations will be discussed. 1224 4.2 Section: Transmission successfully translated from 1225 internal format to standard EDI format 1226 4.2.1 Need 1227 There needs to be a facility by which a sender can 1228 assure that the EDI transmission was correctly 1229 translated and prepared for outbound transmission. 1231 4.2.2 Recommendations 1232 This is standard functionality for most if not all EDI 1233 translators. This should NOT be required functionality 1234 in the UA. 1236 4.3 Section: Transmission successfully encrypted, signed and 1237 sent 1238 4.3.1 Need 1239 There needs to be a facility by which a sender can be 1240 assured that an EDI transmission was successfully 1241 encrypted, signed, and sent. 1243 4.3.2 Recommendations 1244 * This should be required functionality of the UA. 1246 * The UA needs to be able to identify the transmission 1247 by its interchange control #, AND a user defined value, 1248 if desired. 1250 4.4 Section: Transmission successfully received 1251 4.4.1 Need 1252 There needs to be a facility by which a sender of a 1253 transmission can be assured that the transmission was 1254 correctly received by the intended receiver. 1256 4.4.2 Recommendations 1257 1) The UA should track this, and provide the sender with 1258 signed receipts. 1260 2) The use of the MDN (message disposition notification) 1261 as described in Section 3.7.3, according to the Internet 1262 draft by Roger Fajman 1264 3) Note: This could theoretically be accomplished by 1265 using a 997 in place of the NRR, however, it's our 1266 recommendation to not do that for two reasons: 1268 * The implied success of the receiver's decryption 1269 through the receipt of a legible 997, binds the 1270 certificate to a control ID only (997) and not to 1271 the actual data (NRR). 1273 * Translators are very different, and we feel this 1274 RFC should define interoperability between UA's 1275 only, and still cover all angles. 1277 4.5 Section: Transmission successfully translated by 1278 receiver 1279 4.5.1 Need 1280 There needs to be a facility for the sender to be 1281 assured that the receiver could "understand" (in EDI 1282 terms) the transmission. 1284 4.5.2 Recommendations 1285 This should NOT be tracked by the UA, following our 1286 recommendation for object boundaries 1288 The Functional acknowledgment 997, and the EDIFACT 1289 CONTRL serve this exact purpose - this should be tracked 1290 by the EDI translator. 1292 4.6 Detection and recovery of delayed or lost transmissions 1293 4.6.1 Need 1294 There needs to be a facility by which a sender can 1295 detect sent transmissions that have not been 1296 acknowledged as correctly received, by a specified, 1297 configurable, period of time, and be able to configure 1298 actions accordingly. 1300 4.6.2 Recommendations 1301 1) The use of time stamps for each of the two events: 1303 * MIME message sent. 1305 * Signed Receipt received. 1307 2) The ability to automatically detect transmissions 1308 that have failed the time trigger. 1310 3) The ability to configure automatic actions based on 1311 failure. Actions may include: 1313 * Re-transmit. If re-transmitted, the receiving 1314 UA needs to be able to detect the second 1315 transmission as a duplicate and discard it (more 1316 on this below). 1317 * Alert/Report. 1318 * Ignore/delete (this option may be chosen by 1319 someone that has decided to track only at the EDI 1320 translator level through 997/CONTRL. 1322 4.7 Detection and handling of duplicate transmissions 1323 4.7.1 Need 1324 There needs to be a facility by which a receiver of EDI 1325 transmissions is able to detect different types of 1326 duplicate transmissions, and handle them the way they 1327 should be handled. First, translator initiated 1328 duplicates should NOT be halted in any way - we should 1329 assume that translators will handle that level. In 1330 other words, there should be no checking of ISA control 1331 numbers by the UA. Secondly, the use of a re- 1332 transmission feature in attempts to deliver 1333 transmissions quickly, should allow for a UA to identify 1334 duplicate transmissions generated by the sending UA, and 1335 discard of duplicate transmissions after the first has 1336 been received. 1338 4.7.1 Need 1339 The ability to pass through translator initiated re- 1340 transmissions to the receiving translator without a 1341 hitch. This means EDI related control numbers, such as 1342 the ISA control number, should not be checked by the UA. 1344 Appendix A - A Comparison of Security Protocols 1346 Version: 3.0 1348 Date: July 18, 1996 1350 Sources: 1352 EDIINT- EDI over Internet, Internet Mail Consortium Workshop 1353 data, Chuck Shih, Steve Dusse', David Darnell, Kent 1354 Landfield, David Chia, Rik Drummond, Jeff Cook, Alan Cox, 1355 Raph Levien, Russ Housley, and many others. 1357 1) Exportable Out Side Of The USA 1358 ------------------------------------ 1359 PGP V3.0 1360 * PGP is already outside the USA and except for 1361 countries that prohibit encrypted messages with long 1362 key lengths (instead of just restricting the import of 1363 long key length algorithms) PGP long key lengths 1364 messages can be read This is included in the PGP 1365 ViaCrypt documentation: 1366 * No since the encryption algorithm specified is IDEA. 1368 S/MIME 1369 * Has the 40 and 56 bit export restrictions if RC2 or 1370 RC4 is used for encryption 1372 MOSS 1373 * Not with full key length 1374 * Depends on the data encryption algorithm used. RFC 1375 1423 specifies DES in CBC mode, which is not 1376 exportable. Moss however allows the use of variety of 1377 cryptographic algorithms. 1379 MSP 1380 * Depends on the key management and data encryption 1381 algorithm used. MSP allows the use of variety of 1382 cryptographic algorithms. 1384 2) Easily Integrated Into Products In A User Transparent 1385 Manner 1386 ------------------------------------------------------------ 1387 PGP V3.0 1388 * Maybe in V.30. Not in earlier versions 1389 * There seems to be general disagreement on this one 1391 S/MIME 1392 * Yes 1394 MOSS 1395 * Do not know 1397 MSP 1398 * Yes. Support for signed receipts may require GUI 1399 enhancements. 1401 3) Fully Compatible With Like Versions World Wide 1402 ----------------------------------------------------- 1403 PGP V3.0 1404 * PGP version 2.6 is compatible with any earlier 1405 versions. Version 3.0 should be also. 1407 S/MIME 1408 * RSA has an active interoperability program in place 1409 * Implementations to the spec should guarantee 1410 interoperability. 1412 MOSS 1413 * Moss does not require any particular security 1414 algorithm. Moss provides the means to identify which 1415 algorithms are used for each message. A suite of 1416 algorithms is defined in RFC 1423. 1418 MSP 1419 * Implementations to the spec should guarantee 1420 interoperability when the same cryptography is used. 1422 4) Current Implementation Status 1423 ---------------------------------- 1424 PGP V3.0 1425 * Version 3.0 is out 3Q96 1426 * Version 2.6 is available 1427 * Qualcomm 1428 * Premail 1429 * Michael's PGPMIME 1431 S/MIME 1432 * Two companies have implemented several others have 1433 committed 1434 * Product is shipping 1436 MOSS 1437 * TIS, Innosoft and SupplyTech 1439 MSP 1440 * SPYRUS, Nortel, Xerox, LJL, BBN, and J. G. Van Dyke 1441 all have implementations. 1442 * Product is shipping. 1443 * In use for Military messages. 1445 5) Confidentiality 1446 ------------------ 1447 PGP V3.0 1448 * YesS/MIME * YesMOSS 1449 * Yes 1451 MSP 1452 * Yes 1454 6) Signature 1455 ------------ 1456 PGP V3.0 1457 * Yes 1459 S/MIME 1460 * Yes 1462 MOSS 1463 * Yes 1465 MSP 1466 * Yes 1468 7) Return Receipt 1469 ------------------ 1470 PGP V3.0 1471 * Via MIME extensions RFC1891-94 1473 S/MIME 1474 * Via MIME extensions RFC1891-94 1476 MOSS 1477 * Via MIME extensions RFC1891-94 1479 MSP 1480 * Yes.; supports non-repudiation with proof of delivery. 1482 8) Delivery Notification 1483 ------------------------- 1484 PGP V3.0 1485 * Via MIME extensions RFC1891-94 1487 S/MIME 1488 * Via MIME extensions RFC1891-94 1490 MOSS 1491 * Via MIME extensions RFC1891-94 1493 MSP 1494 * Via MIME extensions RFC1891-94 1496 9) Authentication 1497 ----------------- 1498 PGP V3.0 1499 * Yes 1501 S/MIME 1502 * Yes 1504 MOSS 1505 * Yes 1507 MSP 1508 * Yes 1510 10) Multimedia 1511 -------------- 1512 PGP V3.0 1513 * Yes 1515 S/MIME 1516 *Yes 1518 MOSS 1519 * Yes 1521 MSP 1522 * Yes 1524 11) Integrity 1525 ------------- 1526 PGP V3.0 1527 * Yes 1529 S/MIME 1530 * Yes 1532 MOSS 1533 * Yes 1535 MSP 1536 * Yes 1538 12) Trust Model (Key Management & Revocation) 1539 ------------------------------------------------- 1540 PGP V3.0 * PGP 3.0 will have hierarchical model of public-key 1541 certificates 1542 * RSA used for key management in current versions 1543 * Ad hoc key revocation. 1545 S/MIME 1546 * RSA based using X.509 all versions. 1547 * NT's Entrust will be usable with this product very 1548 soon. 1550 MOSS 1551 * Both RSA and DES based key management. 1553 MSP 1554 * X.509 all versions. 1556 13) Certificate (Information, Format, Distribution) 1557 ------------------------------------------------------ 1558 PGP V3.0 1559 * Yes using proprietary "Key rings". Not clear what V3 1560 will use 1562 S/MIME 1563 * Yes using X.509 -all versions 1565 MOSS 1566 * Yes with optional X.509 1568 MSP 1569 * Yes using X.509 1571 14) Infrastructure Overhead 1572 ---------------------------- 1573 PGP V3.0 1574 * Base 64 encoding 1576 S/MIME 1577 * ASN.1 - BER and DER encoding 1578 * Base 64 encoding 1580 MOSS 1581 * Base 64 encoding 1583 MSP 1584 * Base64 encoding and ASN.1 encoding 1586 15) Envelope Type 1587 ------------------ 1588 PGP V3.0 1589 * MIME/ ASCII 1591 S/MIME 1592 * PKCS #7 ASN.1 and MIME 1594 MOSS 1595 * MIME/ ASCII 1597 MSP 1598 * MIME /ASN.1 1600 16) Envelope / Structure Components (ASN1 Or ASCII) 1601 ------------------------------------------------------- 1602 PGP V3.0 1603 * ASCII 1605 S/MIME 1606 * ASN.1and ASCII 1608 MOSS 1609 * ASCII 1611 MSP 1612 * ASN.1 1614 17) Algorithms Supported (List Them: Encryption, Key 1615 Management, One Way Hash, Digital Signature, Key Lengths 1616 For Encryption) 1617 ------------------------------------------------------------ 1618 - 1619 PGP V3.0 1620 * RSA and IDEA in pre 3.0 1621 * Diffie Hellman and DSA in Ver. 3.0 1622 * I DEA in CBC 1623 * MD5 & RSA 1624 * A 384 for casual grade, 512 commercial grade, 2048 1625 military grade 1626 * A 128 bit IDEA key length 1628 S/MIME 1629 * RSA 1630 * RC2 / RC5 1631 * MD5 & RSA 1632 * SHA-V 1633 * Note: S/MIME like Moss is a format and allows any type 1634 of algorithm to be specified. RSA of course specifies 1635 their own algorithms 1636 * Triple-DES/RC5 1638 MOSS 1639 * DES in CBC 1640 * RSA or DES 1641 * MD2/MD5 and RSA 1642 * A 56 bit key lengths for DES 1643 * FORTEZZA 1644 * Note: Moss like S/MIME allows a variety of 1645 cryptographic algorithms to be used. The suite of 1646 algorithms defined above are found in RFC 1423. 1648 MSP 1649 * Algorithm independent. Implementations exist using: 1650 * RSA & DES 1651 * FORTEZZA (DSS SHA-1, KEA, Skipjack) 1653 18) Common Algorithms With EDIFACT AUTACK List Of Codes 1654 ----------------------------------------------------------- 1655 PGP V3.0 1656 * RSA (yes) 1657 * IDEA (yes) 1658 * DH (?) 1659 * DSA (yes) 1660 * MD5 (yes) 1662 S/MIME 1663 * RSA (yes) 1664 * RC2 and RC4 (yes) 1665 * DES (yes) 1666 * MD5 (yes) 1668 MOSS 1669 * RSA (yes) 1670 * DES (yes) 1671 * MD5 (yes) 1673 MSP 1674 * RSA (yes) 1675 * DES (yes) 1676 * MD5 (yes) 1677 * DSS (yes) 1678 * SHA-1 (yes) 1680 19) Coexistence With Others For Reception (signature not 1681 readable) Of MIME Multipart/Signed Data 1682 ------------------------------------------------------------ 1683 PGP V3.0 1684 * Yes V3.0 1686 S/MIME 1687 * Yes, but user selectable 1689 MOSS 1690 * Yes 1692 MSP 1693 * Yes, if used with MIME encapsulation (see 1696 20) Signed Message Body Readable By RFC822/ MIME Readers 1697 ------------------------------------------------------------ 1698 - 1699 PGP V3.0 1700 * Should be in V3.0 1702 S/MIME 1703 * Yes - if one of the options multipart/signed is used 1704 * Verify with RSA is it multipart/alternative and not 1705 /signed? 1707 MOSS 1708 * Yes 1710 MSP 1711 * Yes, if used with MIME encapsulation 1713 21) Signature Separate From Signed Document 1714 ---------------------------------------------- 1715 PGP V3.0 1716 * Yes 1718 S/MIME 1719 * Yes, optional 1720 * Verify with RSA 1722 MOSS 1723 * Yes 1725 MSP 1726 * Yes 1728 22) Backward Compatibility 1729 --------------------------- 1730 PGP V3.0 1731 * To PGP 1733 S/MIME 1734 * To PEM 1736 MOSS 1737 * To PEM 1739 MSP 1740 * No 1742 23) Uses Proprietary Algorithms? 1743 --------------------------------- 1744 PGP V3.0 1745 * Ver 3.0 will use Diffie-Hellman with expiring patents 1746 in 1997. Ver 3.0 will use DSA (Digital Signature 1747 Algorithm invented at the NSA) 1749 S/MIME 1750 * Yes 1752 MOSS 1753 * YES, but it supports different options in a coherent 1754 manner. 1756 MSP 1757 * It supports both standard (FIPS and X9) as well as 1758 proprietary algorithms. 1760 24) Adequate Security For EDI Purposes 1761 ----------------------------------------- 1762 PGP V3.0 1763 * Yes 1765 S/MIME 1766 * Yes. However one can tell the difference between an 1767 encrypted message and a signed/encrypted message. 1768 There is not consensus as to if this is a problem or 1769 not. 1771 MOSS 1772 * Yes 1774 MSP 1775 * Yes 1777 25) Scaleable 1778 ------------- 1779 PGP V3.0 1780 * No enough experience to tell. The current trust model 1781 will not scale well. 1783 S/MIME 1784 * No enough experience to tell 1786 MOSS 1787 * No enough experience to tell 1789 MSP 1790 * Yes 1792 26) Solid Mime Integration 1793 --------------------------- 1794 PGP V3.0 1795 * V3.0 -yes 1797 S/MIME 1798 * Yes - but it mixes PKCS technology with MIME. Internet 1799 purest do not seem to like the mix. 1801 MOSS 1802 * Yes 1804 MSP 1805 * Yes (see 1807 27) Variable Key Sizes Supported 1808 ---------------------------------- 1809 PGP V3.0 1811 S/MIME 1812 * Yes, 40- 128 bit 1813 * Symmetric 512-2048 bit RSA 1815 MOSS 1817 MSP 1818 * Yes 1819 * Symmetric (DES = 56 bits; SKIPJACK = 80 bits) 1820 * Signature (DSS = 512 .. 1024 bits; RSA = 512 .. 2048 1821 bits) 1822 * Key Management (KEA = 1024 bits; RSA = 512 .. 2048 1823 bits) 1825 28) Only X.509 Or Other Certificate Distribution Methods 1826 ------------------------------------------------------------ 1827 PGP V3.0 1829 S/MIME 1830 * X.509 any version 1832 MOSS 1834 MSP 1835 * X.509 any version 1837 29) Very Solid API And Took Kit 1838 --------------------------------- 1839 PGP V3.0 1840 * V3.0 Yes - anticipated 1842 S/MIME 1843 * Yes 1845 MOSS 1846 * No 1848 MSP 1849 * Yes. DISA is submitting an API to X/Open. 1850 * At least two tookkits for sale. 1852 30) Tool Kits Can Be Made Available To All Countries Not 1853 Under UN Embargo 1854 ------------------------------------------------------------ 1855 - 1856 PGP V3.0 1857 * Probably from alternate sources 1859 S/MIME 1860 * Export version probably to most countries 1862 MOSS 1863 * Export version probably to most countries (40 bit 1864 DES?) 1865 * Alternate sources probably yes 1867 MSP 1868 * Export version probably to most countries. Toolkits 1869 exported to many countries, including France. 1870 * Alternate source likely. 1872 31) Fit With Future Direction Of EDI 1873 --------------------------------------- 1874 PGP V3.0 1875 * Neutral 1877 S/MIME 1878 * Neutral 1880 MOSS 1881 * Neutral 1883 MSP 1884 * Neutral 1886 Author: 1888 Chuck Shih 1889 Phone: 415 937 3511 USA 1891 Chair: 1893 Rik Drummond 1894 Phone: 817 294 7339 USA