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

Simo Sorce simo at redhat.com
Wed Aug 24 15:12:54 EDT 2016


On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote:
> On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein <rick at openfortress.nl> wrote:
> > Hey Mike,
> >
> >> But it would be even better if the client could (or had the option to)
> >> do authentication with the service directly and thus eliminate the
> >> numerous dependencies for clients (DNS, KDC access, stale tickets,
> >> time sync...).
> >
> > I doubt you could use Kerberos without these components involved.
> > You might forego DNS if you configured your client (which is certainly
> > not everyone's favourite solution).  You need the KDC to obtain a
> > short-lasting credential, which is pretty much a cornerstone of
> > Kerberos security.  The stale tickets and time sync come with that.
> 
> I'm proposing clients use the server as a surrogate for the KDC. So
> the server would get a TGT on behalf of the client as well as a
> service ticket (for itself) and return it to the client. The client
> would then use that service ticket as normal. I understand that this
> would all warrant new commands and logic.

The IAKERB mechanism was built for this scenario, but it seem like it
didn't really pick up, it worked by tunneling AS requests/replies, so it
is not the server that gets your TGT, which would be quite bad in the
general case.

> Yes, this is all tangential to what you're doing.
> 
> >> I'm not sure if that is possible with HTTP being
> >> stateless, but if is, it could be the basis for proper Internet
> >> website security as well.
> >
> > It sounds to me like you are asking about preshared keys, which
> > are accepted to be far less secure than the Kerberos road.
> 
> Unfortunately I don't know all the nomenclature so I'll duck this one.

The problem is name resolution is still a problem in 2016, mostly
because of bad practices everywhere and a DNS system that has always
been hard to use for the general public.

Simo.

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



More information about the Kerberos mailing list