HP & Export of DCE

Well, if Leahy passes, DCE is exportable.  Anyone know if the
'SecureRPC' in  DCE is the one BAL broke years back?  I asked a few
DCE supporters this, and never got an answer, so I suspect they're
still shipping bogus crypto.

Adam


----- Forwarded message from Anonymous -----

As I sit, somewhere not in North America, I can see a CD-Rom from
Hewlett-Packard, which I've had since last year. Recently I received the
following letter. I've attempted to retype its contents accurately.

---------8<--------8<--------8<--------8<--------8<--------8<--------8<

					[HP Logo]
Hewlett-Packard Company
Software and Information Delivery Operation, SST
690 East Middlefield Road
Mountain View, California 94043
415/968-9200


Dear HP-UX Support Customer,

Hewlett-Packard has uncovered a bundling problem in the DCE-Core fileset
that is on the October HP-UX Application Release 10.0 s700/800
Application CDs. These products were bundled such that they are not
compliant with U.S. Government export regulations. The part numbers for
the affected CDs and products are listed below.

Adam Shostack writes:
> Well, if Leahy passes, DCE is exportable.  Anyone know if the
> 'SecureRPC' in  DCE is the one BAL broke years back?

No, they broke Sun's Secure RPC, which is different.

I must admit that I've never done a serious security analysis of DCE
RPC, though...

Perry

Perry E. Metzger wrote:

| Adam Shostack writes:
| > Well, if Leahy passes, DCE is exportable.  Anyone know if the
| > 'SecureRPC' in  DCE is the one BAL broke years back?
| 
| No, they broke Sun's Secure RPC, which is different.

I wasn't aware there were multiple things masquerading under the name
Secure RPC.  In any event, does the crypto in DCE stand up to the
LaMacchia/Odlyzko attacks?  (And did Sun ever upgrade what they ship?)


Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

On Wed Mar 27, 1996, Martin Janzen wrote:

    Another "RPC" comes from the Open Software Foundation, who
    unfortunately chose the same acronym for the remote procedure calling
    mechanism in their Distributed Computing Environment (DCE).  This DCE
    is a part of the OSF/1 operating system, but implementations are
    available for many versions of UNIX, often as a separate product or
    option.

This is a semi-common misconception, there is no relationship between DCE
and OSF/1.  OSF/1 was one of the reference platforms during the original
DCE development, but so was SVR4, AIX and HP/UX.

Except for parts of DFS (the distributed file system), all of DCE is
user-mode code and ports easily between un*x platforms.

Dave

Adam Shostack writes:
> | Adam Shostack writes:
> | > Well, if Leahy passes, DCE is exportable.  Anyone know if the
> | > 'SecureRPC' in  DCE is the one BAL broke years back?
> | 
> | No, they broke Sun's Secure RPC, which is different.
> 
> I wasn't aware there were multiple things masquerading under the name
> Secure RPC.  In any event, does the crypto in DCE stand up to the
> LaMacchia/Odlyzko attacks?

They are attacks against Diffie-Hellman. I don't know if DCE uses D-H
in a similar manner. The main problem was too small a (fixed) modulus.

> (And did Sun ever upgrade what they ship?)

I don't believe so.

Perry

On Wed Mar 27, 1996, Perry E. Metzger wrote:

    Adam Shostack writes:

    > | Adam Shostack writes:
    > | > Well, if Leahy passes, DCE is exportable.

DCE is exported today, although without the ability to encrypt application
traffic.  Authentication and message integrity are in the export version.

    They are attacks against Diffie-Hellman. I don't know if DCE uses D-H
    in a similar manner. The main problem was too small a (fixed) modulus.
    
DCE RPC uses Kerberos V5 to establish DES session keys.

Dave

On Wed Mar 27, 1996, Perry E. Metzger wrote:

      Adam Shostack writes:

      > | Adam Shostack writes:
      > | > Well, if Leahy passes, DCE is exportable.

  DCE is exported today, although without the ability to encrypt application
  traffic.  Authentication and message integrity are in the export version.

Yes, but lest we miss the point, Anon's posting
was about FULL DCE, with the end-to-end security
option, unless I'm very much mistaken.

Greg.

Greg Rose               INTERNET: greg_rose@sydney.sterling.com  
Sterling Software       VOICE:  +61-2-9975 4777    FAX:  +61-2-9975 2921
28 Rodborough Rd.       http://www.sydney.sterling.com:8080/~ggr/
French's Forest         35 0A 79 7D 5E 21 8D 47  E3 53 75 66 AC FB D9 45
NSW 2086 Australia.     co-mod sci.crypt.research, USENIX Director.

-----BEGIN PGP SIGNED MESSAGE-----

[To: Adam Shostack <adam@lighthouse.homeport.org>]
[cc: perry@piermont.com, cypherpunks@toad.com]
[Subject: Re: HP & Export of DCE ]
[In-reply-to: Your message of Wed, 27 Mar 96 11:18:49 EST.]
             <199603271619.LAA08716@homeport.org> 

Adam Shostack <adam@lighthouse.homeport.org> shaped the electrons to type:
>I wasn't aware there were multiple things masquerading under the name
>Secure RPC.  In any event, does the crypto in DCE stand up to the
>LaMacchia/Odlyzko attacks?  (And did Sun ever upgrade what they ship?)

DCE security (including RPC) is Kerberos based, somewhere between V4 and
V5, and appears to be about as strong as DES lets it be.

Chris McAuliffe <cmca@alpha.c2.org> (No, not that one.)

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBMVm++YHskC9sh/+lAQE4JgP/dbXJoUnpx/RyiYTvRe6Zrek5j+h5B6QX
nusogJioZdAts2SjEjIOVfEdAtoZ/MGVyn8p750np6UttvUCfFfiCZ7uIydMEQEm
IZAZ1ep3MpyaAKgpGrqyDz47ic/Kk0iit2WwEXjvkN8c+PoXrvKPjkW7ugjHqQgf
4EkPBSlI+f8=
=iZQA
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

Adam Shostack writes:
> | > Well, if Leahy passes, DCE is exportable.  Anyone know if the
> | > 'SecureRPC' in  DCE is the one BAL broke years back?
> | 
> | No, they broke Sun's Secure RPC, which is different.
>
> I wasn't aware there were multiple things masquerading under the name
> Secure RPC.

Yes, there are.  The term "RPC" is sometimes used generically, to refer
to any remote procedure calling mechanism, but also refers to at least
two distinct implementations.


The first "RPC" was produced by Sun's Open Network Computing group.  This
is still the most commonly used, as Sun made the source code available
at no cost [1].  Many vendors (including HP) now provide it as a
standard part of their UNIX distribution [2].  A transport-independent
version, TI-RPC, was later produced, but this doesn't appear to be quite
as widely used, though I think it is in Solaris.  (Sorry, I don't know
of an archive site for this; try Alta Vista et al.)

Sun's version of "Secure RPC" includes Unix (uid-based) and (in North
America) DES authentication.  The basic mechanism can support other
authentication schemes as well, though I've never actually heard of any
alternative implementations.  This is the "Secure RPC" whose key exchange
was cryptanalyzed by LaMacchia and Odlyzko [3].


Another "RPC" comes from the Open Software Foundation, who unfortunately
chose the same acronym for the remote procedure calling mechanism in their
Distributed Computing Environment (DCE).  This DCE is a part of the OSF/1
operating system, but implementations are available for many versions of
UNIX, often as a separate product or option.  The DCE Security Services
are discussed a bit in the DCE FAQ [4], and O'Reilly has an entire book
on the subject [5].


To confuse matters further, it now seems that Microsoft has added an "RPC"
mechanism to Windows NT and 95.  This is sort of compatible with OSF DCE
RPC, but not entirely; see [4].


In short, it would help to avoid massive confusion if people were more
specific: refer to "DCE RPC", "ONC RPC" (or "Sun RPC", if you must :),
or "Microsoft RPC", not just to "RPC".

- --
Martin Janzen           janzen@idacom.hp.com
Pegasus Systems Group   c/o Hewlett-Packard, IDACOM Telecom Operation



[1] Try ftp://bcm.tmc.edu/nfs or ftp://wuarchive.wustl.edu/systems/sun/
sun-exchange/rpc4.0, or a comp.sources.unix archive site.

[2] To see if you have it, type "man rpc", or search your C library
using something like "nm /lib/libc.a | grep clnt".  If it's installed,
you should see functions like "clnttcp_create", "clntudp_create", etc.
If not, look for a separate librpc.a in /lib, /usr/lib, /usr/local/lib,
or what have you -- or ftp it from the archive sites and build your own.

[3] Here's the reference, courtesy of Matt Blaze:

@article{nfscrack,
   author = {Brian A. LaMacchia and Andrew M. Odlyzko},
   journal = {Designs, Codes, and Cryptography},
   pages = {46--62},
   title = {Computation of Discrete Logarithms in Prime Fields},
   volume = {1},
   year = {1991},
}

Brian also has a home page, http://www.swiss.ai.mit.edu/~bal/bal-home.html
but as my Net connection is flaky right now, I can't tell whether this
article is available there.

[4] The DCE FAQ is at http://www.osf.org/dce/faq-mauney.html or
ftp://ftp.dstc.edu.au/pub/DCE/FAQ.

[5] "DCE Security", Wei Hu, O'Reilly, ISBN 1-56592-134-8.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMVm1GG3Fsi8cupgZAQHKkwP/QQaKNEuwuvNo5E+8Myu2P/Dv70Ha4p88
RhtEH11oBH4IjMksqL0J+o8qSOwiBA/bcciW6y8ef1gSgwFxmdbEqGmLftSGjYNU
D6r8C5LmSkmmtQuLcXUE+QVEBLIXmnYC0tIwbqprGGm0soQpW0GbzZtgXtrECm0H
Vi1bsJ+LEJQ=
=3e3P
-----END PGP SIGNATURE-----

Martin Janzen writes:
> The first "RPC" was produced by Sun's Open Network Computing group.

Not even remotely the case -- RPC predates Sun Microsystems by a lot.

> Another "RPC" comes from the Open Software Foundation, who unfortunately
> chose the same acronym for the remote procedure calling mechanism in their
> Distributed Computing Environment (DCE).

I'm not sure its so bad, given that there are at least a dozen RPCs
out there or more.

> In short, it would help to avoid massive confusion if people were more
> specific: refer to "DCE RPC", "ONC RPC" (or "Sun RPC", if you must :),
> or "Microsoft RPC", not just to "RPC".

Probably the case...

Perry

On Wed Mar 27, 1996, Perry E. Metzger wrote:

> Adam Shostack writes:
> > I wasn't aware there were multiple things masquerading under the name
> > Secure RPC.  In any event, does the crypto in DCE stand up to the
> > LaMacchia/Odlyzko attacks?
> 
> They are attacks against Diffie-Hellman. I don't know if DCE uses D-H
> in a similar manner. The main problem was too small a (fixed) modulus.

It doesn't.  DCE uses Kerberos v5.

Howard

-- 

Howard R. Melman              ___   ___   ___            Voice: 617-621-8989
Open Software Foundation     /  /  /__   /__               Fax: 617-621-2782
11 Cambridge Center         /__/  ___/  /              mailto:melman@osf.org
Cambridge, MA  02142                             http://www.osf.org/~melman/

On Wed Mar 27, 1996, Martin Janzen wrote:

> Another "RPC" comes from the Open Software Foundation, who unfortunately
> chose the same acronym for the remote procedure calling mechanism in their
> Distributed Computing Environment (DCE).  This DCE is a part of the OSF/1
> operating system, but implementations are available for many versions of
> UNIX, often as a separate product or option.  The DCE Security Services
> are discussed a bit in the DCE FAQ [4], and O'Reilly has an entire book
> on the subject [5].

The product is called DCE RPC and the RPC is used
generically as you stated in the beginning of your note.
There are many RPCs in the world, aside from the ones you
listed.  DCE RPC is also known as ISO RPC as the standard is
based on DCE.  MS RPC is also based on DCE RPC as you
stated. 

DCE is not part of OSF/1 but is middleware supporting
distributed computing which is available on virtually all
platforms: (Unixes, Windows, Cray, MVS, VMS, Mac is in beta,
etc.)  Yes, one of the reference ports was OSF/1.  We sell
the source code separately.

We are now seeing OSs bundled with DCE client software.
The most recent versions of HP/UX and AIX for example.

For more info on DCE see http://www.osf.org/dce/ 

Howard

-- 

Howard R. Melman              ___   ___   ___            Voice: 617-621-8989
Open Software Foundation     /  /  /__   /__               Fax: 617-621-2782
11 Cambridge Center         /__/  ___/  /              mailto:melman@osf.org
Cambridge, MA  02142                             http://www.osf.org/~melman/