disallow requests naming principal as a service

Sam Hartman hartmans at MIT.EDU
Tue Mar 26 18:58:01 EST 2002

>>>>> "John" == John Brezak <jbrezak at windows.microsoft.com> writes:

    John> From a threat perspective, I want to limit the principals
    John> that a KDC will give out a ticket for. Once the KDC gives up
    John> a ticket for a service, I might was well try to use it
    John> unless the application protocol tells me differently.

Completely agreed.  I also assert that the application protocol should
tell you either to use U2U or normal Kerberos.

    John> But when the KDC determines that it will not return a
    John> ticket, I will have to go into an extended
    John> negotiation. Prehaps SPNEGO should be relied upon to
    John> indicate that the server is willing to do user2user (because
    John> it has a TGT for the service principal) - I can understand
    John> that.

My argument is that for GSSAPI, either SPNEGO or some
application-layer thing like the GSSAPI key exchange negotiation
should be used.

    John> However there as been resistance to using negotiation
    John> protocols (SPNEGO) to determine what Kerberos sub-protocols
    John> should be used.

Is this resistance within the IETF?  If so I'd like to know who I need
to convince.

I certainly understand the desire for having the error return and
don't object to it.  I just want to make sure it is not required for
any IETF protocols and that where appropriate we encourage people to use negotation.

If some other organization doesn't provide a negotiation step, then
relying on the error return seems like the best that can be done.

More information about the krbdev mailing list