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

Simo Sorce simo at redhat.com
Wed Aug 24 16:06:12 EDT 2016


On Wed, 2016-08-24 at 15:55 -0400, Michael B Allen wrote:
> On Wed, Aug 24, 2016 at 3:12 PM, Simo Sorce <simo at redhat.com> wrote:
> > 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.
> 
> Ah, yes, I thought there was something like this. I suspect I am just
> recalling IAKERB but twisted into my own fantasy.
> 
> To be clear, the whole point of what I'm proposing is that the client
> would have ZERO dependencies. Being able to do proper auth and then
> get a TLS session that uses the crypto context established during auth
> instead of traditional certificate would be a big deal.
> 
> I don't see why giving the server access to the TGT would be any
> different from delegation. It could be "constrained" to just the HTTP
> server(s), Sharepoint, or whatever stuff requires impersonation.

Constrained delegation can be done without forwarding one's TGT.
Forwarding a TGT is bad because it is unbounded impersonation.

Simo.

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



More information about the Kerberos mailing list