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?"
You might also look at SESAME at http://www.esat.kuleuven.ac.be/cosic/sesame.html It an european project , somehow similar to Kerberos.
You'll find KRB4 at http://www.pdc.kth.se/kth-krb/ and KRB5 at http://www.pdc.kth.se/heimdal/.
There is rxtelnet and kx. kx is an authenticating proxy and is really simple to use through the shell script rxtelnet. It does not require any changes to the X server. It comes with KTH-KRB. I think it works with Heimdal as well.
This whole topic started because someone was confused about what type of thing Kerberos is. Kerberos is a PROTOCOL, not a PRODUCT. It's a set of rules describing how systems communicate in order to achieve certain security goals. The question "can Kerberos be exported" is meaningless. The question can only be "can implementation XXX of Kerberos be exported". By analogy, we never ask "is TCP/IP copyright". We might ask "is the Trumpet TCP/IP stack" copyright. Hope this clarifies things.
Is it just a way for encrypting passwords? Does it compete with RSA, or does it use RSA?
Or is it a competitor to SSH? Or is this something SSH could use?
OpenBSD comes with Kerberos out of the box, ie. part of the standard install
Unfortunately Canada follows the same rules as the US for exporting encryption software. IOW if you export something to a country that the U.S has deemed naughty then you could face legal repercussions.
I agree with most of what you said with exception to the firewall comment. Kerberos can't protect agains denial of service attacks
MIT-KERBEROS-5 is used for authentication of display access only,
not for the encryption of session.
BTW, all of the packages are already kerberized. (k-1.0.5)
What is URL of your site?
I am catching up late on this... Why do you say that PAM modules for kerberos violate kerberos security model? Just interested in knowing... Thanks. Michele
i am catching up late on this... Why do you say that PAM modules for kerberos violate kerberos security model? Just interested in knowing... Thanks. -Mike
This is somethjing I've been wondering myself. BTW what is Kerberos exactly???
yep, you're right! in the export version here, all a poor bastard gets for encryption is single des 56-bit... Triple DES and other goodies seems to be removed due to those g** d*** export regulations....
see the script rxtelnet that comes with kth-krb http://www.pdc.kth.se/kth-krb/
i guess it /is/ a kind of export...
Just curious is there such a way using kerberos on X environment? or perhaps using kerberos with NIS?
In terms of running Kerberized client software there is probably no advantage of one operating system over another. As for running a Kerberos keyserver, I would say OpenBSD is likely to be a superior choice than most (if not all) other operating systems. This is because the keyserver is the major weak link in the Kerberos chain: if the key server is compromised then all user's passwords are also immediately compromised. Therefore a system like OpenBSD which attains a very high level of security is probably better than other general purpose systems, even if these systems (like Linux and FreeBSD) can be made quite secure.
Ralf
The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.
-Bertrand Russel
--
--
"Insert witty quote here."
Win2k U.S Edition (128bit) encryption has been tested with MIT Kerberos 5 but I havent seen any info about the international encryption version. But with the recent developments in the US crypto policy there might no longer exist.
As for the myth that Windows 2000 "supports" kerberos... it doesn't. It uses kerberos as its main authenthication method...
'It's kind of fun to do the impossible.'
'It's kind of fun to do the impossible.'
- Walt Disney
--thi
I don't want to join one side of the fight or the other, but how is it that Kerberos is more suited to being implented on OpenBSD rather than FreeBSD? Kerberos is apart from the OS, afterall, and any information as to how in implement it on any OS should be treated equally. Yeah, OpenBSD is more secure out of the box, but that's about it in terms of how applicable this is to that...
DAMN! bout time I found this. I was wondering what ever happened to replay. I went to the site one day and sure enough I got the replay tv thing. It really pissed me off too ;) Thanks for this link.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
Kerberos V5 authentication
Kerberos V5 is the primary security protocol for authentication within a domain. The Kerberos V5 protocol verifies both the identity of the user and network services. This dual verification is known as mutual authentication.
How Kerberos V5 works
The Kerberos V5 authentication mechanism issues tickets for accessing network services. These tickets contain encrypted data, including an encrypted password, that confirms the user's identity to the requested service. Except for entering a password or smartcard credentials, the entire authentication process is invisible to the user.
An important service within Kerberos V5 is the Key Distribution Center (KDC). The KDC runs on each domain controller as part of Active Directory, which stores all client passwords and other account information.
The Kerberos V5 authentication process works as follows:
Kerberos V5 interoperability
Windows 2000 supports two types of Kerberos V5 interoperability:
For more information on interoperability between the MIT-based versions of the Kerberos protocol and the Windows 2000 implementation of the Kerberos protocol, see the Windows 2000 Resource Kit.
Heimdal is very good. It would, of course, have been illegal for the MIT Kerberos team to have given them any source, but there's nothing wrong with seeing whether two packages will talk to one another...and the folks at MIT spent considerable time doing such testing with the Heimdal team.
Incidentally, don't bother with single-DES Kerberos; it can be cracked in real time. 3DES is good. It may implement other encryption as well -- I'm not sure.
--
Some keywords for the NSA in the Lord of the Rings universe: One Ring bind find Sauron quest Nazgul freedom
what i would like to see is
does anyone know how good this is handled in kerberos 5?
greetings from vienna, austria.
mond
OpenBSD? FreeBSD?
It's an install option with FreeBSD. (OpenBSD too, probably.)
(8-DCS)
FreeBSD does ship with Kerberos on the CDs IIRC. it should be in /cdrom/des/, and is available as an install time option or can later be installed from /stand/sysinstall. Even thought they ship international, they put it on CDs. Apparently there's some precedent for allowing this in the part of California where Walnut Creek is, and they've supposedly consulted lawyers on this issue a number of times. Can anyone provide a link to the legal issue perhaps?
Q:Doctor, how many autopsies have you performed on dead people?
A:All my autopsies have been performed on dead peop
I thought SSH only dealt with secure remote shells, while Kerberos provides a programmatic API.
Kerberos is used as an optional authentication component with various database vendors, transaction processors, etc. I've never seen mention of SSH as an option for any of the tools I've used.
Does anyone have examples of open and commercial source products that use SSH for centralized authentication the way Kerberos is?
I do not fail; I succeed at finding out what does not work.
I recommend that anybody interested in seamless IP encryption that supports any IP application without any changes look into IPSec. There's a free implementation called FreeS/WAN for linux. For PCs and Macs there are free client-side implementations availible in the form of PGP Freeware's PGPNet module.
IPSec can easily be set up to support an entire Internet subnet, where it encrypts all data between IPSec-enabled gateways, or encryption and authentication directly between two IPSec configured hosts.
As an added bonus, the Internet Engineering Task Force has included IPSec in the IPv6 specification, so there's a very high chance the protocol will become widely adopted in the near future.
FreeS/WAn can be found here and PGP Freeware here.
Nice summary. I don't suppose you could be convinced to take over the
ODP Kerberos page? It's at www.dmoz.org and could do with a well-informed editor...
what do you think law is about without legal philosophy? In the absence of reasonable law the ciitzenry will select what they can live with and ignore the rest. That is a lesson of history. It is pointless to beat people up verbally for doing this. There is a large difference between fighting tyranny and ripping off other developers.
Perhaps the Kerberos incorporation in win2000 is
only downloadable as a software update from within the US. I believe the same goes for FreeBSD.
There's a large difference between licenses put on a product by the creators, and licenses forced on a product by the government.
OpenBSD notes on the Canadian Export Control List
Here is a link to where Marc Plumb has drawn some general conclusions about exporting crypto from Canada
It appears that crypto that is public domain has absolutely no restriction as far as the Canadian Government is concerned, but if it originated from the USA, then it has to be approved, and if its not public domain (free) then a permit must be acquired. Interesting to see that the US gov has charged people for exporting crypto from Canada. (Canadian and american?)
Oh, and I'm a high tax paying Canadian myself.
Lars -
Perhaps there is a philosphical difference...
But a license violation is not a question of philosophy, unless you can get the judge to listen to arguments about whether the rule of law should prevail (fat chance!).
Many in the Open Source community seem to take pride in holding the moral high ground over closed/proprietary development efforts. As if to say "my code is so much better than yours that I'm willing to subject it to peer review -- and give it away for little or no money" implies and automatically confers some sort of moral superiority.
Well, I happen to agree that contributing to the welfare of a community is a noble undertaking. However, if 'members' of the community behave in dishonorable ways towards others, whether or not those others are part of the community, it reflects poorly on all of us. Not only that, but it sets a precedent within the community, and can begin to spread. If we can ignore the license restrictions of an application that 'had a [draconian] license forced onto it by the government', why can't we ignore the license of software that's 'too expensive', or software who's manufacturer 'is too rich', or who's author you've never met (so he'll never know the difference)? In other words, if the line is not exactly where the copyright holder's license says it is, then where is it, and when have we stepped across?
Judicious application of the Golden Rule (i.e., treat others as I would like to be treated) might give you a different perspective. Instead of proclaiming 'Everyone does it, why shouldn't I?!', try asking 'what if everyone did it, and it was my property being misappropriated?'
If appearance and essence were the same thing, there would be no need for science -- Dr. Michio Kaku
An arbitrary set of rules that we must either live by or be prepared for the consequences of violating. I wish that we (in the U.S.) lived in a system where a sound and consistent philosphy prevailed.
An interesting point. History also shows that unreasonable law can be turned back upon the citizenry. How many millions have been slaughtered in the 20th century under the auspices of 'unreasonable' laws? Should we not work to change laws that are unreasonable? If you don't agree with a law, work to change it from within the system. Civil disobedience should be considered a tool to bring out when other actions within the system turn out to be ineffectual. But applied in a manner where others suffer the consequences, civil disobedience is irresponsible.
My intent was to discourse, not to assault.
I agree wholeheartedly. Illegal use of software, in direct violation of its license, is a far cry from fighting tyrrany.
If appearance and essence were the same thing, there would be no need for science -- Dr. Michio Kaku
I think you will find that canada was excluded from export controls. But in any case the old export controls regime has just been replaced. Please see for details. http://204.193.246.62/public.nsf/docs/60D6B47456BB 389F852568640078B6C0
Here at KTH we use Kerberos all the time, and we don't have any firewalls. That makes things a lot easier for me; being able to access the site from outside is really useful.
-- Oddity - AFS and Kerberos in his Linux box
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
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 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