Date: Tue, 12 Nov 1996 11:58:19 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: freebsd-security@freebsd.org Subject: Secure RPC revisited Message-ID: <199611121658.LAA22844@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
Okay, I just have to ask this. We (that is, myself and Mark Murray, basically) held back on incorporating Secure RPC into the base FreeBSD distribution for the following reasons: - Secure RPC uses DES. - Secure RPC also uses Diffie-Hellman key exchange, which is subject to a patent until some time in late 1997. Note that excluding the above two problems, Secure RPC itself is not subject to any export restrictions since it doesn't actually encrypt any data in RPC transactions: it encrypts only timestamps for authentication purposes. This is how Sun and the other big vendors can legally export their OSes out of the country. (They do not export the actual DES support however: you need to obtain a kit for that, meaning that while you may have Secure RPC, it may not actually work properly until the encryption kit is installed.) The DES problem can be dealt with (in an admittedly messy fashion) by providing a dummy crypto library that exports a fake _des_crypt() function. (What the fake function would do is open for debate. Anything from simple bit inversion to rot13 is acceptable.) This would prevent Secure RPC from working with anything besides another FreeBSD machine until the real crypto library is installed, but unless our government wakes up and smells the toast burning, we'll just have to deal with it. The Diffie-Hellman issue is another matter. My understanding (which may in fact be totally wrong) is that it's not possible to use code which implements Diffie-Hellman without paying a licensing fee to RSA (or whoever it is this week). But the patent in question is supposed to expire in 1997, thus we bide our time, all the while plotting to overthrow the earth and cackling maniacally to ourselves. (Alright, maybe it's just me.) But now I'm confused. Recently, the multimedia network lab decided to buy a copy of Redhat Linux (version 3.0.3) for some project or another. (Yes, I argued FreeBSD's case, but I was shot down. Just wait until I rule the world: then I'll show 'em...) Anyway, I poked around in it a bit and what did I find? Yes, you guessed it: Secure RPC support. They even have a stripped down DES implementation just to make it work. Now, I don't think that Redhat has seperate export and domestic versions of their CDs, so whatever they ship here, they must ship overseas. And I'm pretty sure they're based in the US. So could somebody please explain to me: how is it that Redhat can ship Secure RPC support right now and we can't? Did they just do it and hope nobody would notice (or care)? Did they pay money to RSA? Do they just happen to know the secret handshake? Somebody please tell me yes or no: are we allowed to ship Secure RPC (minus DES, if necessary) with FreeBSD? (Note that suggesting that I look at a web page somewhere does not qualify as a yes or no answer.) I'm bringing this up again since it has direct bearing on NIS+, which needs AUTH_DES to be at all useful. I want very much to merge AUTH_DES support into FreeBSD so that NIS+ can basically drop right in (when I finally finish it). This would also imply importing a dummy crypto library. There was some talk of this back when the Secure RPC issue was first raised, but like most things that get talked about, nothing much ever came of it. While I'm on the subject, I also want to add support for an AF_UNIX socket transport. This would make it possible for processes on the same host to communicate without using IP, thus removing the threat of IP spoofing. I faked up something for this in rpc.yppasswdd, but it would be nice to have it integrated into the RPC library. Keyserv and possibly portmap would benefit a great deal from a 'local only' transport. It would be analagous to the loopback transport in TI-RPC on Slowlaris, but done with AF_UNIX sockets since we don't have STREAMS/TLI. (The TI-RPC loopback transport has what appears to be a bit of an advantage over unix domain sockets, which is that it is possible using t_getinfo() to determine the UID of the caller on the other end of the link. With sockets, all you can do is set the ownership and permissions of the socket special file in the filesystem to restrict access to certain people, which isn't as flexible.) So! Secure RPC integration! Legal bogosities! Discuss! -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611121658.LAA22844>