Re: Internet Security

[Robert Moskowitz <rgm3@xxxxxxxxxxxx>]

At 11:18 AM 5/21/96 -0400, Dale Rickards wrote:
>
>name is Dale.

Hi 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 can't really speak well to the guts of EDI. My colleagues are EDI people,
I am a protocols and security person.  Thus enveloping and layers are
important to me.

>During this time I worked closely with the banks in the U.S. to implement
>security solutions for EDI.

Banks are different than manufacturing.

>E:MAIL VS 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.  

I have looked a little at our trading partner arrangements.  The security
today is login, ie authentication.  Authentication is the key concern over a
3780 network.  But on a packet network like IP, packet-wise authentication
and integrity become important.  IE digital signatures.

If you add up the trading partner #s for the big 3 you get over 14K.  I
doubt that.  Heck, I hear that Chrysler is GM's largest supplier after
Delphi automotive and GM is Chrysler's largest supplier :)

A commonized identity system, perhaps run through the auspusis of our trade
organization (AIAG) will bring admin into line.  Maintaining 5,000 keys at
each OEM does not make good business sense.

>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?

The X.12, EDIFACT docs tend to show that all attachments are within the EDI
packet.  The STEP people sure don't see it that way!  And I do not think
that is the way it is held by many of my colleagues, PROVIDED that a strong
alternative is given.  In fact, if attachments like wordproccessing and
spreadsheets are kept outside the EDI packet, there might be better
synergisms with other systems.  Just a strong hunch.  Like I said, STEP
already has their one bilateral two-way authentication within the STEP
format.  It is thus already out of hand.  None of this stuff should be
anymore in the application propriety envelope, but in a generalized common
envelope.  (or is that utopia?)

For this, Multi-Part/Secure could work real well.  It could even use MIME
recursive as to what is secured how.  Ah there I go into typical security
thought mode of onion layers and how well MIME is suited for that.

>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.

Becuase security has been viewed unidirectional.  Everyone knows that 3780
links are naturally secure ;)  Wearing another hat (for those of you not
aware of this I am on the IAB), we are working on a security architecture
and my submission shows security as a pyramid: privacy, authenticy, and
integrity as the base with trust being the vertical.  With this view, any
slice of the pyramid reflects some level of security concern.  So you will
see it soon, if done right.

>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.

For various reasons I will not address this issue at this time.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212