win2000 actually will work with standard Kerberos services, to an extent. For instance, I set up a win2k workstation to authenticate logons against a unix KDC. You can also do some other small things, like ticket management while using a standard Kerberos KDC. But that is about the extent of their support for standard kerberos, at least as far as I know. The telnet and FTP clients are not Kerberized, and nothing in internet explorer is as far as I could tell.
The problem raised in this article I think is that in order for their SMB client (ie, microsoft networking) to use Kerberos authentication when connecting to an SMB file server, it requires the use of their proprietary extension to kerberos, the priveledge attribute certificate - PAC. Apparently the Samba developers ran into this problem while trying to add kerberos support to samba and make it work with windows 2000 (using Kerberos authentication. Samba will still work with win2k using the older auth methods).
So win2k does support standard kerberos, but not in enough applications (like file sharing, telnet, ftp, IE) for users to actually do anything usefull when working with a unix KDC. I suppose they might have just added this support so they could say win2k is compliant with that standard. If they ever do implement kerberos in any of their other apps, some of which I mentioned, it will probably be equally broken.
I really don't think the most important issue here is them using a proprietary client to spam their users, it's that they are flat out lying to every person who uses this network. This garbage about requiring this proprietary client to prevent flood attacks and "maintaining a clean, safe, well-lit environment" and such is just a pretty looking excuse to place ads on people's screens.
As any 15 year old (no offense) with some network experience can tell you, the concept of trusting some proprietary software on the client side to provide security is uttery foolish. The protocol can be reverse engineered, the application can be reverse engineered. When people download this program, they can do anything they like with it. It would probably not be too difficult to analyze the network traffic the program emits, reverse-engineer the protocol and find out how it differs from IRC.
So either their entire technical staff is comprised of chimpanzees, or this statement about needing a proprietary client for security reasons is a complete lie and a very deceptive way of spamming their users.
I can accept that they might need to raise some revenue, and they chose to do that by requiring proprietary clients, but lying to everyone to make this look more user-beneficial, I cannot.
Folks, this article about w2k Kerberos incompatibility untrue. I have set up a Win2k RC2 workstation last month at my job for testing purposes. We have a Unix KDC on the network running the standard MIT Kerberos distribution. I configured the win2k workstation to authenticate against the unix KDC - and it worked perfectly. As a matter of fact, I configured the workstation using microsoft's own step by step instructions for doing so, which can be found at http://support.microsoft.com/support/kb/articles /Q232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0. See the part entitled "Using an MIT KDC with a Windows 2000 Workstation".
This article may be confusing everything with earlier verions of win2k betas (AKA NT5) which microsoft had openly said would not be fully compliant with the kerberos standard. However, they changed this around the RC2 release I believe. You can find an outdated article with more details on this here: http://www.usenix.org/publications/login/1997-11 /embraces.html.
This older stuff is probably what they're talking about, but they have definitely changed w2k to make it fully compliant with the existing Kerberos standard...
"I am baffled by this assertion. I just downloaded srp-1.5.1. The LICENSE file in the docs subdirectory explicitly states that the license is akin to X11. The license also states that srp is "free for both commercial and non-commercial use.""
Sorry, that's my mistake. Not sure why I thought it was GPLed. Thanks for the info.
SSH is a little more versatile in that it can do port forwarding to make arbitrary TCP connections secured. It can even be used to support secure PPP tunnels. SRP on the otherhand is less versatile. Only telnet and ftp seem to be supported. Someone please correct me if I'm wrong, but as far as I know SRP does not have any sort of connection forwarding like SSH does.
Another major difference is in licensing. SRP is under the GPL. No official version of SSH is under a real open source licesense. SSH2 forbids any sort of commercial use, even internally. SSH1 is slightly less restrictive in that it allows for commercial use without paying them, but you can only use it internally. These license restrictions are the reason SSH isn't found in most linux distros.
However, there is an open source implementation of SSH being developed by the OpenBSD people at http://www.openssh.org. It is ususably stable in its current version.
The main thing SRP and SSH have in common is that they require no infrastructure to be secure. In otherwords, you do not need any sort of key distribution centers, or any other sort of software besides the daemon itself and the client program to make everything work. Compare this to say, Kerberos. Using kerberos, you can have secure connectivity to a machine, however, there's a lot of additional infrastructure and complexity thrown in, (such as KDC machines). You'll want to use Kerberos if you have a lot of machines that will share a common user/password database. Kerberos will let you log into one machine, say a kerberized workstation, and you'll be able to securely log into any other machine (via telnet, rlogin, rsh, rcp, ssh, ftp, pop3...) that's part of the same Kerberos realm without ever having to type your password (assuming your client software supports Kerberos authentication).
SRP is arguably more secure than SSH, however SSH is a little more widely implememnted and can be used for more things. If all you need is a secure telnet and FTP, and the existing clients are suitable for you and you can trust it (SRP is a litte newer), I'd give it a try.
As some one else noted, this is not the first time Id has done this type of thing. A while back they had a back door in the quake2 server that would allow instant administrative access to any player coming from id's subnet. Carmack apologized and claimed the backdoor was placed there for debugging purposes and was not supposed to be in the release version. A patch to remove the backdoor was summarily released. The entry detailing this from Carmack's.plan can be found on this page:
Arg. I can't believe AOL is engaging in this stupidity. AIM was presumably removed in an attempt to keep their protocol propreitry and hidden. At any rate, I've put my Tik distribution on my web server. In case anyone is still looking for it you can grab it here:
Not sure what version that is, but I downloaded it within the past month, so it is quite new. Get it while you still can.
Something tells me that we're going to need an open source messaging system that uses open protocols real soon. We obviously can't count on these companies to do the right thing anymore.
Slashdot Mirror
win2000 actually will work with standard Kerberos services, to an extent. For instance, I set up a win2k workstation to authenticate logons against a unix KDC. You can also do some other small things, like ticket management while using a standard Kerberos KDC. But that is about the extent of their support for standard kerberos, at least as far as I know. The telnet and FTP clients are not Kerberized, and nothing in internet explorer is as far as I could tell.
The problem raised in this article I think is that in order for their SMB client (ie, microsoft networking) to use Kerberos authentication when connecting to an SMB file server, it requires the use of their proprietary extension to kerberos, the priveledge attribute certificate - PAC. Apparently the Samba developers ran into this problem while trying to add kerberos support to samba and make it work with windows 2000 (using Kerberos authentication. Samba will still work with win2k using the older auth methods).
So win2k does support standard kerberos, but not in enough applications (like file sharing, telnet, ftp, IE) for users to actually do anything usefull when working with a unix KDC. I suppose they might have just added this support so they could say win2k is compliant with that standard. If they ever do implement kerberos in any of their other apps, some of which I mentioned, it will probably be equally broken.
I really don't think the most important issue here is them using a proprietary client to spam their users, it's that they are flat out lying to every person who uses this network. This garbage about requiring this proprietary client to prevent flood attacks and "maintaining a clean, safe, well-lit environment" and such is just a pretty looking excuse to place ads on people's screens.
As any 15 year old (no offense) with some network experience can tell you, the concept of trusting some proprietary software on the client side to provide security is uttery foolish. The protocol can be reverse engineered, the application can be reverse engineered. When people download this program, they can do anything they like with it. It would probably not be too difficult to analyze the network traffic the program emits, reverse-engineer the protocol and find out how it differs from IRC.
So either their entire technical staff is comprised of chimpanzees, or this statement about needing a proprietary client for security reasons is a complete lie and a very deceptive way of spamming their users.
I can accept that they might need to raise some revenue, and they chose to do that by requiring proprietary clients, but lying to everyone to make this look more user-beneficial, I cannot.
Folks, this article about w2k Kerberos incompatibility untrue. I have set up a Win2k RC2 workstation last month at my job for testing purposes. We have a Unix KDC on the network running the standard MIT Kerberos distribution. I configured the win2k workstation to authenticate against the unix KDC - and it worked perfectly. As a matter of fact, I configured the workstation using microsoft's own step by step instructions for doing so, which can be found ats /Q232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0. See the part entitled "Using an MIT KDC with a Windows 2000 Workstation".
1 /embraces.html.
http://support.microsoft.com/support/kb/article
This article may be confusing everything with earlier verions of win2k betas (AKA NT5) which microsoft had openly said would not be fully compliant with the kerberos standard. However, they changed this around the RC2 release I believe. You can find an outdated article with more details on this here:
http://www.usenix.org/publications/login/1997-1
This older stuff is probably what they're talking about, but they have definitely changed w2k to make it fully compliant with the existing Kerberos standard...
"I am baffled by this assertion. I just downloaded srp-1.5.1. The LICENSE file in the docs subdirectory explicitly states that the license is akin to X11. The license also
states that srp is "free for both commercial and non-commercial use.""
Sorry, that's my mistake. Not sure why I thought it was GPLed. Thanks for the info.
SSH is a little more versatile in that it can do port forwarding to make
arbitrary TCP connections secured. It can even be used to support secure PPP
tunnels. SRP on the otherhand is less versatile. Only telnet and ftp seem to
be supported. Someone please correct me if I'm wrong, but as far as I know
SRP does not have any sort of connection forwarding like SSH does.
Another major difference is in licensing. SRP is under the GPL. No official
version of SSH is under a real open source licesense. SSH2 forbids any sort
of commercial use, even internally. SSH1 is slightly less restrictive in
that it allows for commercial use without paying them, but you can only use
it internally. These license restrictions are the reason SSH isn't found in
most linux distros.
However, there is an open source implementation of SSH being developed by
the OpenBSD people at http://www.openssh.org. It is ususably stable in its
current version.
The main thing SRP and SSH have in common is that they require no
infrastructure to be secure. In otherwords, you do not need any sort of key
distribution centers, or any other sort of software besides the daemon
itself and the client program to make everything work. Compare this to say,
Kerberos. Using kerberos, you can have secure connectivity to a machine,
however, there's a lot of additional infrastructure and complexity thrown
in, (such as KDC machines). You'll want to use Kerberos if you have a lot of
machines that will share a common user/password database. Kerberos will let
you log into one machine, say a kerberized workstation, and you'll be able
to securely log into any other machine (via telnet, rlogin, rsh, rcp, ssh,
ftp, pop3...) that's part of the same Kerberos realm without ever having to
type your password (assuming your client software supports Kerberos authentication).
SRP is arguably more secure than SSH, however SSH is a little more widely
implememnted and can be used for more things. If all you need is a secure
telnet and FTP, and the existing clients are suitable for you and you can
trust it (SRP is a litte newer), I'd give it a try.
As some one else noted, this is not the first time Id has done this type of thing. A while back they had a back door in the quake2 server that would allow instant administrative access to any player coming from id's subnet. Carmack apologized and claimed the backdoor was placed there for debugging purposes and was not supposed to be in the release version. A patch to remove the backdoor was summarily released. The entry detailing this from Carmack's .plan can be found on this page:
m it.x=25&submit.y=4
http:// news.planetquake.com/pqsearch.asp?search=rcon&sub
http://www.rhythm.cx/dvd
There is a list of other mirrors there as well. Well there will be as soon as people start mirroring it :).
Thanks.Third pig has been violating the GPL for quite some time now. www.thirdpig.com... this was posted before but with an incorrect URL.
If you're still looking for a copy of TiK and would rather not put up with AOL's stupidity, I've placed a copy on my webserver.
http://www.rhythm.cx/tik.tar.gz(sorry if this is a repeat post, I think my previous comment got lost somehow).
Arg. I can't believe AOL is engaging in this stupidity. AIM was presumably removed in an attempt to keep their protocol propreitry and hidden. At any rate, I've put my Tik distribution on my web server. In case anyone is still looking for it you can grab it here:
http://www.rhythm.cx/tik.tar.gzNot sure what version that is, but I downloaded it within the past month, so it is quite new. Get it while you still can.
Something tells me that we're going to need an open source messaging system that uses open protocols real soon. We obviously can't count on these companies to do the right thing anymore.