Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

[Simo Sorce]

On Thu, 2016-08-25 at 13:26 -0400, Michael B Allen wrote:
> On Thu, Aug 25, 2016 at 10:09 AM, Simo Sorce <simo at redhat.com> wrote:
> > 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.
> 
> That's all true. Your response was very informative and it has changed
> my understanding of this topic.
> 
> But not completely ...
> 
> Clients should not be required to have access to KDCs directly.
> Ideally KDCs should be on a separate network. Then make a hole for
> just the HTTPS server. Being able to put something "behind" a server
> and, more generally, partition networks by function is more secure.
> 
> Also, another thing is ticket security. Kerberos in it's current form
> is efficient in that tickets are cached on the client but that creates
> the potential for those tickets to be used in unintended ways. What
> happened to the principle of least privilege? If you take Kerberos and
> flip it inside-out (or outside-in rather) and push work into the
> server and only give the client the bare minimum necessary to create
> the TLS session, use the service securely and without fully
> re-authenticating frequently, that would be more secure.

The TGT is used to avoid to cache the long term key, in gneral
experience says that w/o a TGT you would have users store they long term
password in the browsers instead, that's much worse that a TGT which
expires after X hours.

> > 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.
> 
> How could authentication be based on anything other than the user's
> credentials? Just to be clear about terminology, by "authentication"
> do you mean starting from scratch or is using a ticket which is a
> product of authentication that can be reused also considered
> "authentication"?

Well it really depends, if you have an established TLS channel
negotiated via "user credentials" (intentionally vague here) you should
not need any further authentication from the client.

However it is common deployment practice to use things like SSL
terminators in front of the actual servers that the user wants to
connect to as well as sometimes redirect users to other servers, so
there are "secondary authentications" involved sometimes. We do not
really need to discuss those here, as they are out of the purview of the
kerberos related authentication we are discussing here.

>  My scheme would be no different from Kerberos in
> this respect. You do full authentication and the client gets a 10 hour
> ticket for just the particular service. It never sees a TGT. The
> server would handle all of that (and maybe the server never sees a TGT
> either).

Interestingly enough this is something you can do with Kerberos. you can
use your long term secret (the user's password) to perform an AS request
to get a service ticket directly instead of a TGT.

But as I said above the direct consequence of asking the long term user
credentials is that you end up caching them in the browser ...

> > 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.
> 
> I am very much opposed to using cookies or JavaScript for security purposes.

Unfortunately this is what is common practice on the open web ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York