Continuing a side track started in today's meeting... Could someone explain in a step-by-step manner, how Kerberos authentication works? No need to be too long. People mention a lot of jargon, talk about tickets and such, but how do users get them in the first place? It took me forever to understand how RADIUS worked, since everyone just says `we use RADIUS,' and leave it at that. I'm having similar problems with Kerberos.. I was very unimpressed when I saw it in (in)action while implementing a firewall for wireless access where I work. First, it took forever for me to actually get access to the RADIUS server. The IP address of our firewall had to be allowed in, and we were given a shared secret key used for encrypting traffic. Both the client and the server use the same key. I guess we were at least given a unique key, so no other IP address could use the same secret and get away with it. However, RADIUS is a UDP protocol, and is probably a lot easier to spoof than most authentication methods out there. From what I saw, the client sends one packet out containing the username (plaintext) and the password (encrypted). A packet is supposed to come back from the server, saying whether the user was authenticated or not (not sure if that packet has to be encrypted or not -- I hope so). Due to some problem as yet unknown, that packet never made it back to my firewall. Anyway, in the course of solving the RADIUS problems, I was informed of the University's cookieauth system [http://www1.umn.edu/cookieauth/], which seemed useless at first glance (it uses web cookies! Eww!). However, it makes me think about how authentication systems could be improved. When using RADIUS, the system you log into has to have your password in plaintext, if only briefly. If that host were compromised, it would be pretty easy to get your password. The nice thing about cookieauth is that I don't have to care about the user's password at all. If a connecting web browser doesn't have a cookie, or the cookie's out of date, the connection gets forwarded to https://www.umn.edu/login -- a secure web page -- where the user is asked to login. If they get authenticated, a cookie is sent to the browser and the browser is redirected back to where it was originally connecting. Again, the web server checks for a cookie. Now that it's there, the cookie is sent off by the web server to a TCP port (either plaintext or SSL) on x500.umn.edu. If the cookie is valid, the user can be considered to be authenticated. The data returned also contains the username, and the IP address of the user's system, which the web server should verify. The two joyful things for me were that I didn't have to ask anyone to use that service, and that it was extremely easy to implement. I was using a PHP web page, and it took me less than two hours to get it going. PHP doesn't seem to make SSL socket connections very easy, but for the time being, sending the cookie to be verified in plaintext works like a charm. I suspect this is pretty similar to how Kerberos works, but you guys will have to enlighten me on that one. The whole point here is that it's possible to get authentication working with untrusted systems by forwarding the actual authentication to somewhere else and using things like cookies or tickets. Sorry, this is more than I thought I'd write. I hope it's readable and understandable.. -- _ _ _ _ _ ___ _ _ _ ___ _ _ __ Error: Brainwaves received / \/ \(_)| ' // ._\ / - \(_)/ ./| ' /(__ in analog. Please re-think \_||_/|_||_|_\\___/ \_-_/|_|\__\|_|_\ __) in digital. [ Mike Hicks | http://umn.edu/~hick0088/ | mailto:hick0088 at tc.umn.edu ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20011103/8cf4acd1/attachment.pgp