On Wed, 2016-08-24 at 22:05 -0400, Michael B Allen wrote: > But, again, the point is that the client would not be "joined" to a > domain, it would not be required to have network access to a KDC, time > on the client would not matter, the user would not necessarily have to > run the client application in the context of the principal (meaning > they would not have to "login" as a specific user first), the client > would not have to do fancy SRV queries to find the right KDC and the > client would not submit huge tickets with every single request.
It seem most of this is thought in the context of an Active Directory-like setup. In the general kerberos case you do not have to be joined to a domain or to login as a specific user to your local machine to perform an AS request and get a TGT. You do have to locate a KDC to do it though, but with IAKERB you can defer that to the server (at least if your user and the server have identities in the same REALM, might get complicated, but still possible, if not). If supported directly in the browser you could also have multiple different identities, all you need is for the client to keep track of which identity to use with each server, so it can select the right credentials/REALM to construct the AS request. Finally, there is no requirement to send huge tickets with each request, because we are talking about TLS this means you maintain an HTTP 1.1 or HTTP/2 connection for multiple requests, this is something you always want to do when using HTTPS and if this authentication is integrated with TLS that's what you'd do to avoid expensive secure channel establishment exchanges anyway. So the TLS layer would always keep track of who the user is on the other side and provide that information to the server. In cases where TLS connections are terminated early (by some sort of load balancer for example) and you want to "tunnel the user's identity" you can use additionally other techniques: * the server provides a secure cookie (a bearer token of some sort) that is provided at authentication time, but it is kind of useless given the above. * exchange a session key and provide a mush smaller proof of possession than sending the whole ticket, again kind of pointless in the case you base your TLS authentication on the user's credentials. These could be backed in browser through a standard or implemented entirely as a server controlled mechanism via normal cookies and/or javascript code running on the client. Also for the "big tickets" problem of the Active Directory case you could simply request a TGT/ticket w/o the MS-PAC (it's an option in AS and TGS requests IIRC), you'd just have to make sure the server knows how to get the additional data in a different way, or not rely on it at all. Two constrains remain in any case. - The server and the KDC have a shared secret between them. - The user and the KDC have a share secret between them. The user's KDC does not need to be the same as the server's KDC as long as there is a way to create a trusted path between the two KDCs. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
