disallow requests naming principal as a service

Moore, Patrick pcmoore at sandia.gov
Tue Mar 26 19:31:01 EST 2002

> >>>> Sam> == From: Sam Hartman [mailto:hartmans at MIT.EDU] Sent: Tuesday,
March 26, 2002 4:57 > >>>>> "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.
> Sam> Completely agreed.  I also assert that the application protocol
> Sam> 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.
> Sam> My argument is that for GSSAPI, either SPNEGO or some
> Sam> application-layer thing like the GSSAPI key exchange negotiation
> Sam> should be used.

There will be cases where you need to port a GSS-API application
to K5, and you won't have the option of re-engineering the app
so that it does this negotiation. This was the case in Globus.
Globus had no need to negotiate U2U vs conventional service,
the distinction doesn't even exist in Grid Security's X509/PKI

>     John> However there as been resistance to using negotiation
>     John> protocols (SPNEGO) to determine what Kerberos sub-protocols
>     John> should be used.
> Sam> Is this resistance within the IETF?  If so I'd like to know who I
> Sam> to convince.
> Sam> I certainly understand the desire for having the error return and
> Sam> don't object to it.  I just want to make sure it is not required for
> Sam> any IETF protocols and that where appropriate we encourage 
> Sam> people to use negotation.

It's not required by our globus application, nor by U2U draft. 
We use it if we get it, (and we get it today from DCE KDCs)
and possibly save some round-trips. The U2U draft doesn't
preclude in any way negotiating in advance whether U2U is required.
But supports that you MAY learn that from the KDC or from the server.

> 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