Slashdot Mirror
Kerberos Outside the US?
v1z asks: "I'm administrating a small LAN with semi-public terminals and have been trying to locate a usable version of kerberos, that is available for use in Norway (ie outside the US). I've been looking for the bones, and e-bones package without success, and I'm wondering what I've missed? Is there no working kerberos.v5-like system available outside the US? Kerberos is appealing because it uses secret-key cryptocraphy within a good design, simplifying and removing many concerns with asymetric encryption, and because most ppl more easyily grasp the security-issues involved. On a side note: windows 2000 is said to incorporate kerberos.v5 - how does this relate to US-export-regualtions?"
OpenBSD has no (i think) export restrictions, as it is .CA based, not .US.
....
OpenBSD includes Kerberos, more info http://www.openbsd.org
However, it's not true that ssh is just a secure remote shell. Because of it's port forwarding features, ssh is a secure remote anything.
Its availible to non-us citizens too. Lots of info on it can be found at the url above, but basically, its a good thing(tm).
I use to have a funny sig, but slash cut it off, and I forgot what the punchline was.
I would recommend that you use Heimdal. It's a Kerberos V implementation made primarily in Sweden.
Kerberos provides strong mutual authentication, plus limited encryption. SSH provides strong encryption, but limited authentication. (SSH authenticates hosts during initial connection, and optionally users connecting to sshd, but not arbitrary client/server authentication.)
Kerberos uses three-party authentication - client, server and domain controller. SSH uses two-party authentication - client and server. (Prior to the government's attempts to escrow encryption keys and Phil Zimmermann's response, three-party authentication was the norm. With Kerberos, the KDC can be run by the employer,
university, or household!)
Local Kerberos security breaches (e.g., exposure of /etc/krb5.keytab) can be handled globally by a single change at the KDC. Local SSH security breaches (e.g., exposure of /etc/ssh/ssh_host_key) must be handled at each site which connects to it.
Global Kerberos security breaches (e.g., exposure of a */admin password) affect everyone within the domain, so good KDC security is crucial. Global SSH security breaches are impossible.
Kerberos uses DES session encryption by default, although some implementations support 3DES and IDEA. SSH uses IDEA (iirc), so SSH encryption is somewhat stronger "out of the box."
Kerberos does not support "tunneling". SSH does.
Kerberos PAM modules exist, but all I have seen to date violate the Kerberos security model and should never be used. I'm not sure if SSH PAM modules exist, but again I'm sure they violate the SSH security model and should never be used.
Kerberos access can be mediated by "digital certificates" and smart cards. I expect the same could be same of SSH, although I am not certain.
Finally, Kerberos-enhanced SSH exists although I am not familiar with the details of it. However, the important thing is that a site may use both SSH and Kerberos, if desired.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Kerberos 5 changed the protocol in a significant manner in order to prevent certain attacks, although I can't recall if was "man in the middle" off of the top of my head. That's why it's Kerberos 5, instead of 4.1. :-)
As for encryption, I've been using encrypted ktelnet, kftp, krlogin and cvs without any problems. It's possible that the package was built with user-level encryption turned off for some reason.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
But anyone who uses it violates the terms of the MIT license since it explicitly requires that the users be domestic (US and Canada) or have acquired it via a legal export.
It's easy to say "well, I don't care I'm gonna run it anyway!", but then where do you stop? Do you use GPL (not LGPL) libraries because you can? Do you reuse GPL source in your proprietary code?
If we want our licenses to be respected by others, we MUST respect the licenses ourself. Otherwise we'll find ourself in the same position as the proprietary software known to pirate other companies' software -- an obvious hyprocrite who has absolutely no moral grounds to complain when it's our ox being gored.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
First, a bit of background information that you may be missing. Kerberos *NEVER* sends any password across the network in plaintext, and only transmits the encrypted password when the password is actively changed. Kerberos uses an encrypted challenge/response technique between the user's host and the Kerberos domain controller, so any file-based approach like NIS distributed password files will never be kerberized.
One of the major changes in Kerberos 5 is support for X authentication "MIT-KERBEROS-5". This allows you to use Kerberos principal names to control access to your system, e.g.,
$ xhost +:krb5:coyote@LOCAL
This grants access to your system to a particular user regardless of location. The other authentication methods generally grant access to all users of a particular system, or require that you manually exchange authentication information.
Kerberos 5 XDM should also acquire Kerberos 5 credentials for you, if properly configured.
HOWEVER, before you run off and start recompiling xfree86 you should be aware that the current version has been "broken" for some time, at least with the current MIT Kerberos API. You might be able to get it to work with an older version, but that would force you to retain known security bugs as well.
Because of XFree86 4 and the changing US export rules some of us are revisiting the problem and XDM patches should be available soon. MIT-KERBEROS-5 support is a different matter, since one of the biggest items on everyone's wish list is the ability to specify Kerberos encryption on the wire. This would people working from home to use encrypted wire protocol when connecting to their office via xDSL or cable modems.
Kerberos 4 does not support MIT-KERBEROS-5 authentication, although it might be patched to collect a Kerberos credentials for you.
Finally, I'm sure it's possible to modify NIS to require Kerberos authentication (and encryption), but AFAIK nobody's done it. However, in this case NIS would be an application with Kerberos enhancements, not a Kerberos login mechanism.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I'm not entirely sure why, but Kerberos is dead in Europe. For secure connections at my ISP in Germany, we use SSH exclusively.
I would guess that it has something to do with license and/or export restrictions, although I frankly don't know what the conditions for using Kerberos are. SSH, on the other hand, was developed in Finland, and at least versions 1.x are free (as in both beer and speech).
Always keep a sapphire in your mind
Windows 2000 128 bit security can be downloaded from the WindowsUpdate web site, which is linked directly from the start menu (I'd provide a URL, but you can't see the site without using Win2k or forging your HTTP headers). It is restricted to US downloads. AFAIK, the same security is available in export copies at the 40 bit (or 56 bit?) level.
Of course, you can download the 128 bit version by just going through a US based proxy, but I don't know whether the resultant code would be legally usable in Norway. (I mention this only for completeness, and don't in anyway recommend or sanction that approach).
BTW, Win2k VPN security seems pretty good now--the old broken PPTP protocols have been completely replaced, as far as I can tell. Mind you, I'm sure Schneir (sp?) will find a way to break it within a couple of days of official release! (It is MS Encryption, after all...)
The Kerberos system authenticates individual users in a network environment. After authenticating yourself to Kerberos, you can use network utilities such as rlogin, rcp, and rsh without having to present passwords to remote hosts and without having to bother with .rhosts files. Note that these utilities will work without passwords only if the remote machines you deal with support the Kerberos system.
For more, read it online at http://www.openbsd.org/cgi-bi n/man.cgi?query=kerberos.
The latest versions of export-restricted code for FreeBSD (2.0C or later) (eBones and secure) are also being made available at the following locations. If you are outside the U.S. or Canada, please get secure (DES) and eBones (Kerberos) from one of the following foreign distribution sites:
South Africa
ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSD
ftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSD
Brazil
ftp://ftp.br.FreeBSD.ORG/pub/FreeBSD
Finland
ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt
Mea navis aericumbens anguillis abundat