Re: Internet Security

[PETER_MCKINNEY@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

Item Subject: Internet Security
     Dale,
     
     These are very good thoughts.
     
     I share many of these ideas. It is very to me and my customers that 
     any new Internet 'standard proposal' be as open as possible.
     
     As you may have noticed, the distinction between EDI and EMail is not 
     always understood. As well, X.400 terminologies and technologies get 
     mixed up in a discussion where they do not apply. In an SMTP world, 
     X.400 is a non-starter, as in X.435
     
     Your question about why the need to add additional security on MIME 
     strikes hoem, because it the question I have been trying to get 
     answered for awhile now.
     
     After all, as you point out, withthe contents secured, it does not 
     matter of the ISA/GS information is altered, since the process of 
     decryption will fail once the ISA/GS information fails to give to 
     correct information that would allow a successful decryption, and if 
     the digital signature option of X12.58 is used, then that won't work 
     either.
     
     
     While your work has primarily been in banking, where I have done some 
     work, the experiences do transfer to other industries.
     
     Best regards,
     
     Peter


______________________________ Reply Separator _________________________________
Subject: Internet Security
Author:  Non-HP-owner-ietf-ediint (owner-ietf-ediint@imc.org) at 
HP-Boise,mimegw2
Date:    5/21/96 8:18 AM


Hi there,
     
I have been reading your e:mail discussions over the last month and I 
thought it was time to express my views.
     
MY BACKGROUND....
     
I am female ... even though my name is Dale.
     
I worked for Sterling Commerce (formally Sterling Software) developing EDI 
data security software for 4 years and have implemented both the X12.58 and 
the X12.42 (version 3040 - prior to public key)  standards defined by ANSI 
X12.  I have also been part of the work groups developing these standards 
"X12-C committee Task group 6 - Data Security" and have been involved with 
the public key changes made to the standards  ((just a note - I have 
recently changed jobs but I am still active in data security))
     
I have also worked with IBM to interface their black-box security solution 
into Sterlings EDI security software to provide a greater level of security.
     
During this time I worked closely with the banks in the U.S. to implement 
security solutions for EDI.
     
E:MAIL VS EDI....  
     
I don't think that you can come up with the same solution for both E:Mail 
(or other internet information) and EDI.  
     
EDI is exchanged between trading partners who have a trading partner 
agreement and have identified what type of relationship they will have. 
They have defined the transaction sets they will be exchanging and which
segments and elements they will be using.  When they use security, they will 
still have a trading partner agreement which defines the relationship.
Banks are the only organizations who seem to be implementing EDI security 
(although other companies are discussing it because the banks are forcing 
them to).  The banks usually have a security officer who sets up security 
ID's and defines key values (DES) and exchanges them with their trading 
partners.  This will not change when using public key no matter which 
algorithm they use because banks tend to be security nuts (for good reason). 
This means that  the algorithm that EDI, sent though the internet, uses 
should be flexible so that way these trading partners can choose the 
algorithm that they feel comfortable with (ie. RSA, PGP etc).   The X12.58 
standards allows for the use of may different types of algorithms for this 
reason.  
     
Question:   If security is applied by an EDI security software/hardware 
solution (ANSI or EDIFACT) prior to 
                    exchange on the internet  why do we need to worry about
adding more security in MIME?
                    Is there something I am missing?
     
E:Mail information will be sent to anyone, rather then just trading 
partners, and should be more defined to allow you to send confidential 
information without having to worry about the algorithm which was used. 
According to your Charter this is not be decided in this work group.
     
I agree that we must be careful that nothing is proprietary.
     
ANSI X12 VS EDIFACT....
     
There has also been discussion in this group on the ANSI X12 vs EDIFACT 
standards.  Does it matter which one is used?  If both standards allow for 
different algorithms to be used then I do not see what the issue is.  Once 
the EDI message has been secured and sent over the internet, then the 
translator security product at the receivers site should be able to handle 
the data prior to EDI translation.
     
The way the ANSI X12 standards work is that after the EDI transaction set has 
been generated by the translator, security segments are imbedded into the 
transaction set when security is applied (S1S/S2S/S1A/S2A).  These security 
segments define what algorithm was used, if a session key was used and the 
digital signature (with lots of other information... to long to type in).
     
SECURITY IS STILL SLOW TO TAKE OFF...
     
I have found that security is still something that companies and people in 
general have not thought about.  In Canada (where I live) one of the banks 
is allowing customers to apply for loans over the internet.  They send all 
their confidential information (i.e. home address, credit card numbers, how 
much they make) to the bank using the internet and their credit application 
will be processed and approved/denyed within 24 hours.
     
INTERNATIONAL SECURITY.....
     
International security is still something which needs to be addressed.  I 
know that the U.S.government has a real issue about this.  The DES algorithm 
is used world wide, although it cannot be exported in software (I am not 
sure if it is only sold software) without approval from the U.S. government. 
This approval must be obtained for each country you are sending the software 
too.  Each approval costs approximately $10,000 and it can only be sent to a 
financial organization in the approved country.  (I know this because I was 
involved in this when I worked at Sterling).  The current gov't 
adminstration in the U.S. was trying to setup a Certification Agency 
(Nov/95)  which would maintain all private key values for all citizens in 
the U.S.   That way they could break the encryption if they needed too.   
     
     
Thanks for you time... Dale
     
     

.......................................................................

TO: drickards@livgroup.com,
    owner-ietf-ediint@imc.org