Christopher Kranz <[EMAIL PROTECTED]> writes: > Why not just pass the TGT, the session ticket, and the authenticator as > cookies? Let Kerberos do the hard stuff. Kerberos was designed to be > able to securely authenticate someone over an insecure network. This way > you don't have to create new types of tokens or require that the > connection between the web client and the web application server be > encrypted.
No, you still have to require that the connection between the web client and the web application server be encrypted. The thing that you're missing is that doing regular Kerberos involves a computational step on the client when it constructs an authenticator for the remote service. Since you can't get that computational step into the web browser without doing evil things that are unlikely to be portable, you have to generate the authenticator remotely and pass it around. This means that the network link has to be encrypted. This was a topic of much discussion during the WebAuth design meetings, and we unfortunately couldn't find any way around it. This is one reason why we didn't just use pure Kerberos -- pure Kerberos assumes that the client will do work, rather than just being a completely passive ticket store the way that a browser's cookie jar is. However, if you look at the details of the WebAuth protocol, you'll see that it's *almost* Kerberos; the cookies are basically Kerberos tickets, just issued by the weblogin server (what we call the WebKDC) instead of a regular Kereros KDC. The protocol design is almost identical, just with some minor adjustments for the nature of the web. We thankfully had a Kerberos expert to help us with the design and to do the initial implementation. :) You could potentially get even closer to Kerberos by using the pure TGTs and the like from Kerberos rather than doing a Kerberos-like thing inside the WebKDC, but the difficulty there is that you then irrevocably tie the authentication system to Kerberos. One of the goals for the WebAuth redesign was that we be able to support other authentication mechanisms down the road if we need to and if the world changes, so we isolated the reliance on Kerberos to two locations (application server to WebKDC and internal to the weblogin server). It would be entirely feasible, and indeed should be fairly easy, to replace Kerberos with a smartcard system, client-side certificates, or whatever else is your authentication mechanism du jure. We're happy with Kerberos, so we've not done that work, but the protocol was designed to allow for it in anticipation that other sites may wish to use other mechanisms. I'm hoping to eventually find the time to put more of our design decisions and initial requirements up on the web site, but haven't had a chance yet. We did an evaluation of the various other WebISO projects available at the time before we started WebAuth v3 (to replace an earlier WebAuth system that worked somewhat similarly but was far more limited that we wrote many years ago), but none of them could meet all of our requirements (in particular, we hope to make extensive use of proxy authentication down the road). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
