Christopher Kranz <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> wrote:
>> 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. > Why not have the login server create the authenticator on behalf of the > person sitting behind the web client? That's exactly what we do. The problem is that the authenticator is portable, so in order to prevent someone from stealing it, it has to be protected with encryption. If we had control over the surrounding protocol and could modify the nature of HTTP, we could use regular GSSAPI authentication, which deals with this issue and wouldn't require the rest of the session to be encrypted. That's exactly the world that I want to live in long-term, but the underlying assumption of WebAuth is that we needed to add authentication to web sessions without requiring any software on the client other than a standard web browser with SSL and cookie support, and that we couldn't change anything about the HTTP protocol itself. The authenticator that the WebKDC hands back is specific to a particular application server, but it's not specific to a particular client. We could have locked it to an IP address (the whole Kerberos addressless ticket debate), but not only is the level of security that provides somewhat dubious, you immediately create huge problems for yourself given NAT and similar network environments. (Bear in mind that the WebKDC, the application server, and the client may all disagree about the client's IP address depending on the NAT environment the client is sitting behind.) Does that make sense? One other thing to keep in mind here is that you want to put the authenticator, eventually, into a cookie. However, one web server cannot securely set a cookie for another web server; the best that you can do is set a cookie for the whole domain, which is obviously problematic since then you'd be handing the authenticator out to everyone. So what the WebAuth weblogin server does is create a very short-lived authenticator, embeds it in a URL at the application server, and then sends the browser to that URL. The application server then receives and decodes that authenticator, validates it, and then creates a cookie containing a more persistant authenticator just for that service. That cookie is, however, now that user's identifier with respect to that service, and if someone steals that cookie, they could masquerade as the user to that service, so the cookie has to be protected. Hence SSL. The short-lived identifier times out after a minute or two, so even though it ends up in the browser history, the security vulnerability there is fairly low. (It's still not ideal, and there are alternatives that are slightly better from a security standpoint. For example, the user could be required to use POST to send the authenticator back to the application server. But embedding it in the URL has significant advantages from an ease of use perspective, so we took that branch of the security vs. ease of use tradeoff for this.) > The concept I'm envisioning is split the functionality of the > traditional Kerberos client between the web browser and the login > server. The web browser is the credentials cache and the login server > contacts the KDC and does the computations required by the client. Right, this is basically what we do. > So the only link that need to be encrypted is the one from the web > client to the login server. It turns out, though, that this doesn't work because it would allow people to steal the authenticator, particularly the persistant authenticator that lives in the cookie. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
