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?"
Kerberos is available outside the US hence avoiding export regs. Take a look at zedz.net (the guys formerly known as replay.com (based in the Netherlands I beleive). It's the best non-US crypto download site around IMHO
r os
ftp://ftp.zedz.net/pub/crypto/crypto/APPS/kerbe
Have Fun
I noticed this as it just became a debian package
While, I haven't used Heimdahl, the version of Kerberos IV which KTH produced was excellent, worlds better than the MIT release. I'd expect Heimdahl to be similar, although from what I've heard the current cuts are still a little rough.
If you want to use Kerberos IV you're almost certainly better off getting KTH Kerberos IV, which is much more up to date than that included in any of the BSDs (unless any of them have moved to KTH, last I knew they all used a derivitive of the original MIT release). You can get the KTH distribution at http://www.pdc.kth.se/kth-krb/
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
We're mostly on MIT krb5 v1.0.6. The full source distribution (including all the crypto parts) is available in the UK. See the Kerberos FAQ (can be found at http://www.lib.ox.ac.uk/internet/news/faq/archive/ kerberos-faq.general.html)
I haven't found 1.1 outside the US so far. But 1.0.6 is working very nicely for us (with a few tweaks that I keep meaning to put up for download).
Others have mentioned Heimdal. I investigated it about a year ago. But we were transitioning from a MIT Kerberos v4 installation, our site is moderately large (hundreds of machines, thousands of users), and at that time Heimdal did not seem to be up to the job, and the documentation was very sketchy. It might have improved though (I wish I had the time to keep up with its development).
David Wragg
dpw@doc.ic.ac.uk
That's just the beginning - the real power of Kerberos is that it defines an API which can be added to *any* application that wants strong mutual authentication between the client and server.
This means that kerberos-enhanced CVS allows the CVS server to identify you -- and you to be sure that your CVS server wasn't hijacked via DNS or TCP/IP attacks.
It allows your printer to confirm your identity... and you to confirm that your remote printer hasn't been hijacked by a competitor.
It allows you to know exactly what system is feeding your remote tape backup drive... or requesting to restore sensitive accounting information or source code.
It allows your database to know who is access it... and the user to know that the database hasn't been hijacked by a rogue site offering ludicrious information designed to drive your customers away... or you into backruptcy.
And all of these applications can negotiate session-based encryption.
I could continue, but my fingers are getting tired. The point should be clear: Kerberos packages, by themselves, are best viewed as enabling tools, not the final destination.
BTW, the best description I've seen of a fully Kerberized site is that it doesn't require a firewall -- all of the applications have been sufficiently armored that a firewall offers no additional benefit. That's a bit harsh, but it does reflect the conservative approach that the firewall should be the *last* thing added to your network security model, not the first.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Take a step back and consider not-so-distant history.
In the past, if someone wanted something like Kerberos they would have to *mail* a request to the authors and request physical media back. Even after web browsers became common, they had to email a request to the authors who would then explicitly decide whether to grant access.
In contrast, most crypto sites today allow you to fill out an online form and you are granted immediate access. However the license now adds that restrictive clause.
If people started openly violating the terms of the license the authors would not say "oh well, we didn't really care about it anyway." They would say "damn it!" and remove web access to the material. You want a copy of the source code, you'll have to mail a copy of your passport & and signed statement of intent to comply with the laws. The alternative is to have the Feds take it to court and have even stricter limits put on access to the material, e.g., the person must show up in person to get the material.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
MIT Kerberos may become exportable in the next few weeks; I'm sure the lawyers are looking at it. It's definitely "free software" and primarily uses DES encryption (56 bit symmetric keys).
Also, I have put up unofficial Debian packages on my web site, and I know that someone at the MIT site is looking at updating the "contrib" section to include the recent work.
So don't rule out MIT Kerberos yet... or packages you haven't heard about. I first offered my MIT Kerberos packages probably close to two years ago but my packages were rejected because 1) I'm an American and 2) Debian's maintainer process was beginning it's long descent until the innermost circle of Hell. Among other things, that means that I have a lot of experience with a Linux-based KDC (many other packagers are using foreign KDCs) and Kerberos-enhanced Linux packages. Top of my plate - either converted or soon to convert, are CVS, LPRNG, Postgresql, and possibly XDM (to acquire ticket but not set up MIT-KERBEROS-5 authentication.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
As a packager, and someone who lives in the same small town as Phil Zimmermann (Boulder, Colorado), let me be the first to congratulate you on being responsible for denying others Debian packages for MIT Kerberos for almost two years.
YOU can "take a stand" because it's not your fat ass on the line. The unfortunate fact is that if I make packages available when I know that some people plan to violate the law, I know that the feds can come after me. They DON'T have to actually file charges to make my life a living hell, and in fact they will do everything possible to *avoid* filing charges since certain legal protections only kick in to defendents, not people "merely" under investigation for committing a crime.
Since Phil Zimmermann lived in Boulder at the time (and may still live here, although I haven't seen him for awhile) the local press covered his story long after the national press dropped it. This is not an obscure risk that happened to someone, sometime, this is a concrete risk that happened to someone I (casually) know and which caused him a large amount of inconvenience and significant personal expense.
If you want to take a stand, grow some balls and take your own fscking stand. BUT DON'T ACT IN AN IRRESPONSIBLE MANNER THAT EXPOSES OTHERS TO SIGNIFICANT LEGAL RISK JUST SO YOUR SPINELESS SOUL CAN SLEEP WELL AT NIGHT!
Finally, never forget that your zealotry made it risky (even impossible) for many of us moderates to work from within the system. The Feds do not make examples out of well-financed opponents with good connections, they try to cut out the weaker members of the herd. That's why most of the court cases have focused on graduate students. We could have tried to quietly loosen our restrictions to the point that the government would realize that liberalization was a fait accompli, but because of European airheads we were never "out of the spotlight" enough to take big risks.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Downloadable implementations at Munitions! or at a faster UK mirror all outside the US.
- Ferric
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