On Wed, 2016-08-24 at 15:55 -0400, Michael B Allen wrote: > On Wed, Aug 24, 2016 at 3:12 PM, Simo Sorce <s...@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 <r...@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos