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