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

[Michael B Allen]

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.

> 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"? 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).

> 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.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/