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

[Simo Sorce]

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