| Folks,
PRL is alive and kicking, and there has been no "notice of redundancy"
whatsoever.
I am answering note 2712 in behalf of Patrick Baudelaire, Manager of
the Lab, who had to leave 2 minutes after seeing the 2 lines about PRL,
out of context, and I can testify that he was *mad*.
I expect that Dave Monahan will post swiftly a retraction of his
false comments about PRL's staff being fired.
By the way, there are indeed Cryptography experts at PRL, and we still
hold the world record for RSA encryption speed.
Looking forward to meeting any of you.
Henri Gouraud
|
| I apologise for misunderstandings that have arisen from .0.
It seems I misunderstood a leaflet posted round Valbonne by a trade
union regarding the situation at PRL. I have attempted to correct
this in the following.
ELIMINATION OF A CORE COMPETENCY
Data must be protected by a combination of physical and logical
security. Except in special cases both are required. Networked data cannot
usually be secured using only physical techniques. At one time expertise in
secure networking was one of our core competencies - a competency that only DEC
had, and that was a differentiating factor between us and other companies.
A couple of years ago we had the best story in the industry. We were
the only company to have an architecture for network security. It had been
published in IEEE presentations. We had our first product of that architecture
(DECdas for Ultrix) already in field test, and were working on a VMS version.
The code was all designed to be portable, so we could have quickly implemented
on other operating systems. Our Paris Research Labs (PRL) wrote the RSA
encryption code that it used, but the rest was written by the Secure Systems
Engineering group in the U.S..
We had been the major collaborators with MIT in the development of the
Kerberos system of local network security, and were shipping it bundled with
Ultrix. In fact we were the only company to be shipping it outside the U.S.
because it required some special packaging to meet U.S. export regulations.
Kerberos has been accepted as the security part of OSF DCE. DEC's work with MIT
had ensured that DSSA was upward compatible in application interfaces to
Kerberos V5, and it was being considered as a replacement for Kerberos in a
later version of OSF.
We had the only Ethernet encryption device on the market (the
DESNC), and were working on its replacement (code name TANDU). The ethernet
chip design was being done by a group in Israel, cooperating with the Hudson
plant for actual production. The DESNC was in demand all over Europe, but in
general could not be sold because of export licensing restrictions. TANDU was
to have an alternative algorithm that it was hoped would be exportable.
We had DCSA (Digital Cryptographic Security Agent) designed for
security in the banking industry, but applicable to any wide area network. This
was produced by an engineering group in the U.K.. With this and the DESNC/TANDU
products we could cover security on both LANs and WANs.
We had a Secure Systems Engineering group, with members internationally
respected in the industry and with published books on security techniques. They
had produced an A1 security kernel (highest level defined by U.S. government)
that was ready for evaluation by the U.S. government. They also provided the
focal point for all other security work being done within DEC. Senior engineers
in the group had been responsible for the design of our security architecture.
NREG (later to become Polycenter-AM) for secure management of users in
a wide area network was in its final stages of development. It used
cryptographic techniques between client and server to ensure secure updating of
accounts on remote nodes.
We had VAXencrypt V1.2 for VMS, and there was a project to port it to
Ultrix. This didn't directly address network security, but it did provide
callable encryption services for a network application. VAXencrypt V2.0 was
planned for VMS.
-----------------------------------------------------------------------------
Recently I reviewed what of the above still existed.
The DESNC,VAXencrypt and DCSA still existed as products.
The Paris Research Labs who had written the RSA encryption code that went
into DECdas were a reservoir of expertise. We still have Kerberos on
Ultrix, but are not actively selling it. We finally (after most other major
manufacturers) had the security component of DCE on OSF/1.
Everything else was gone.
The DECdas for Ultrix was cancelled after submission to SDC. One copy
escaped to a customer by accident. British Petroleum was a field test site and
would pay almost anything to buy the final version of the product. DECdas for
VMS was ready to go to field test when we fired the engineer responsible for
it. There is no current development on any component of DSSA.
TANDU appears to have been cancelled. The latest information is that
it would ship in August 1992, but since there is no longer an assigned product
manager it is a little difficult to ask about product slippages.
The Secure Systems Engineering group no longer exists, and we decided
not to proceed to evaluation of the A1 security kernel. Most of the best
respected members of that group have left DEC to Mitre Corp., or professorships
at MIT, etc.. With the cancellation of all products and ongoing work this
means the death of DSSA as an architecture.
NREG (Polycenter-AM) has officially been announced as retired.
VAXencrypt was never ported to Ultrix, and the proposed V2.0 of the VMS
version has never appeared. It seems stable at V1.2, and doesn't have a product
manager.
-----------------------------------------------------------------------------
Within the last few weeks it has been announced:-
1) That DCSA has been sold off to a third party, but DEC may get a
commission on sales.
2) The DESNC has officially been retired, and it is suggested that we
recommend customers that need that sort of thing to a company in
California, but a review of their product by someone in DEC
suggests that the product does not yet have the performance required
for it to be usable in local area clusters (LAVC) or in MOP
down-line loading.
Also, within the last few weeks, Novell have announced a consortium to
build a secure network architecture. This will use both public and private key
mechanisms, RSA and DES, exactly like DSSA. They expect to have products within
about 18 months. They have discovered that they are missing a core competency
in the network area - *secure* networks, and setting about remedying that.
I will be interested to see just how close to DSSA it turns
out to be. We deliberately made DSSA "open" and published details, with
the idea that we would be the leaders that others would follow. Maybe
DSSA is not dead, but it won't be DEC that has the products. Maybe in three
years time we can take the DECdas code out of the closet and give it a few
tweaks to make it compatible with Novell.
-----------------------------------------------------------------------------
Currently we have two products for sale.
VAXencrypt provides standard DES encryption, either on a whole file
basis, or as a shareable procedure library for use by applications. We use
this internally within applications that deal with financial or personnel
databases. This is a stable product. The latest (V1.2) release was more than
three years ago, and there are no known bugs.
DCSA (Digital Cryptographic Security Agent) was written by DEC in the
U.K. for the banking industry, though it has been sold in other areas. It
provides a simple and standard application interface to a range of
external hardware black boxes and modems. It relieves the application
of all responsibility for knowing about what hardware is used. The
application need know nothing about key management policies, etc..
We have recently sold the source code for this to another company, and
we would subcontract to them if any support or consultancy was required, even
for our own internal use.
Paris Research Labs is still there, though it has been hit by
redundancies as other parts of Digital.
Our current activities in the area of secure networking and
cryptography are :-
1) Attempting to influence the U.S. government to relax ITAR regulations
on cryptography.
2) Having finally (end of July) ported the security part of DCE to OSF we are
looking at porting it to NT and VMS. The client part for VMS should be
available some time next year, but there isn't even a date for a server.
There is nothing in this that would distinguish us from any other supplier
except that we are slower than most in porting the code supplied by OSF.
Note that this is just porting code available to all members of OSF. There
is no original work, or anything that could be described as a core competency.
-----------------------------------------------------------------------------
When I was giving non-disclosure presentations on DECdas to customers I
was getting comments such as the following.
"Our network is about half VMS and half Ultrix. As soon as the VMS version is
available we would like to put it across our whole network"
"It is the best story on security that we have got from any manufacturer. When
are you going to port it to Sun? We have about 40% Ultrix and 60% Sun".
"It's nice to see such an important product coming first on Ultrix rather than
VMS. For the first time it shows that DEC has a real commitment to the Unix
market".
Many customers were extremely interested, but most would have
waited until it was available on a second platform to be sure that we
were really serious about an architecture rather than a spot product
for Ultrix. Very wise of them, since we never even shipped the spot
product for Ultrix.
|
| re: -.1
I feel that I should respond to a couple of statements made in the
previous note.
>2) Having finally (end of July) ported the security part of DCE to OSF we are
>looking at porting it to NT and VMS. The client part for VMS should be
>available some time next year, but there isn't even a date for a server.
First of all, the word "finally" makes the situation sound a bit
worse than it is. We did ship our first release of DCE with security
a few months later than our major competitors, Hewlett-Packard (the
provider of DCE security) and IBM (the DCE integration contractor.)
The VMS port is making good progress and the runtime services should
ship in the first calendar quarter of 1994. The security server
will come along some months after that and Dave is correct in that
a firm date for that has not yet been made available. We are also
working actively on DCE security for Windows NT although, again,
no official date is available now.
>There is nothing in this that would distinguish us from any other supplier
>except that we are slower than most in porting the code supplied by OSF.
>Note that this is just porting code available to all members of OSF. There
>is no original work, or anything that could be described as a core competency.
I think this is unfair in a couple of dimensions. For one thing, the
implication here is that this is a simple and straightforward port,
just correct a few compiler errors and you have a product you can
ship to customers. OSF will tell you themselves that they ship "raw
materials" and *not* finished products. We have had to do a good
deal of work even on OSF/1. Porting code written for a UNIX(tm)
environment to OpenVMS is that much more difficult. And as for
being "slower than most" except for Gradient's port of DCE to
DOS/Windows our OpenVMS port will be the first port of DCE to a
non-UNIX(tm) platform. We will do this before IBM gets their port
to MVS out and they have a small army working on their project.
Further, thanks to the work done by John Williams and his team in
the OSF/1 development group in defining and implementing SIA our
DCE on OSF/1 has the first integrated login function for DCE, a
feature many of our customers are asking for. So we as a company
have done original work in the security space.
I'd like our DCE story to be better than it is but given our
contraints in terms of platform support required and resources
allocated I am very proud of the work that's been done by a wide
variety of people. We have nothing to hang our head about.
Brian Schimpf
DCE Project Manager
|