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

Michael B Allen ioplex at gmail.com
Wed Aug 24 15:55:14 EDT 2016


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.

Mike


More information about the Kerberos mailing list