On November 9th, 1995 the DCE Users Group of Michigan met at the University of Michigan's Center for Information Technology Integration (CITI). The meeting was sponsored by the Client/Server Exchange, a jointpartnership of IBM and the University of Michigan promoting open, client/server computing.
Hosting the meeting was Janani Janakiraman of U-M/CITI.
Attendees: Brad Smart - Northern Telecom, Diana Noble - U-M,Mark Pettovello - Ford, Bob Brandt - Ford,Lisa Wyatt - EDS, Robert Duncan - Northern Telecom, Becky Priebe -CITI, Brian Minnebo - Oakland State Univ., Mark Kolakowski -Deloitte and Touche, Roland Schemers - Sunsoft, David Richardson -CITI, Janani Janakiraman - CITI.
The agenda of the meeting was as follows:
The next meeting will be on Thursday, January 11th, 1-4pm.
The TENTATIVE agenda is:
Two versions of DCE code are sold from Transarc (this holds true for many DCE implementors), an international version and a domestic version. The domestic version contains full DES encryption and the international version contains DES encryption for all but privacy level encryption. Privacy level encrypts all data on the network. The lower protection levels generally only encrypt data relating to authentication between between client and server.
If you are interested in using the domestic version (full data encryption) internationally, you will need to obtain an Individually Validated License (IVL) through the State Department. This license typically takes about 6-8 weeks to obtain and is good for four years. When obtaining an IVL, you need to explicitly identify what countries you want to export to and define your reasons for doing so. The State Department also maintains two lists of countries that restrict export use of DES. A list of absolutely prohibited countries and a list of proscribed countries that allows limited export depending on who the end-user is and what the need is. Ken had this list and was willing to make it available upon request.
To summarize, if you have a need to use DCE internationally, you have two choices. You can either use an "International" version of DCE that removes the ability to do full user data encryption (privacy level protection), or obtain an IVL and use the "Domestic" version of DCE including privacy level protection.
In past conversations I have had with Ken, I recall him telling me that not all DCE implementors may create international versions in the same way. Therefore you may want to verify that your international versions of DCE work together on different hardware platforms.
Two questions came up after the teleconference ended:
Question - A clarification of using DCE internationally if DCE can be obtained locally through the individual countries.
Answer - I spoke with Ken after the meeting to clarify this issue and found out the following. Transarc only sells international versions to companies in countries other than the United States. If a company in a foreign country requested a copy of the domestic version they would first have to obtain an IVL and then Transarc would sell it to them. An exception is that Transarc will do the work through the State department on behalf of that company for a fee.
Question - If DCE was being bundled in an application and distributed internationally, is an IVL required?
Answer - An IVL is not required if the DCE being distributed is an international version. If not, then an IVL will need to be obtained as usual.
Ken graciously gave out his email address for any further questions on this topic.
Object Management Group -
- a large, diverse industry consortia.
- Best known for CORBA, but responsible for a broad
distributed
object architecture.
- An uneasy relationship with DCE ...
Differences between CORBA/DCE
- Abstract specification vs. reference implementation
- Easy substitution of different CORBA implementations is
a long
way off.
- Interoperability is very complicated
>> not just a communication specification, but also
an
interpretation of object references, TypeCodes,...
>> Security features unclear
>> Interoperability spec. only recently completed.
- Not all object services provided by each vendor.
>> Services may be implemented in different ways.
- CORBA better supports object oriented programming
- a very natural model
- Object features such as inheritance supported
throughout.
- IDL is used with an emphasis on design of interfaces,
not just as a communication description.
- There will be implementations of CORBA on top of DCE
- IBM, HP, DEC
- Possibility of internetworking through Network OLE?
For more information see the web page, which has a copy ofthe slides.
This talk was about the pluggable authentication
module in DCE
(OSF-RFC 86.0).
Deficiencies of the current system
- the authentication system is hardcoded and there is no
easy way to
add new authentication systems.
PAM(Pluggable authentication module) introduced in
Solaris 2.3 as
a Sun-private interface.
Sample implementation delivered to CDE in September '95.
Developed sample implementations for
- Unix
- ONC+ Secure RPC
- DCE
- kerberos
- S/key
- ruserok() based remote authentication
- dialpass port based authentication
Paper on PAM accepted by Third ACM conference on Computer
Communications
and Security.
PAM provides a generic way to authenticate the user to
the system
entry applications.
PAM supports multiple authentication systems.
PAM enables single-passwd login with multiple mechanisms
and provides
framework for single login.
PAM enables implementation of a machine and application
specific policy.
PAM enables addition of new authentication technologies
very easy.
Multi vendor support
Lots of excited customers.
DCE Users Group of Michigan (DUGM)
Author: Janani
Janakiraman
Revised: 06/14/96
URL: http://www.citi.umich.edu/dugm