No subject

will give out a ticket for. Once the KDC gives up a ticket for a
service, I might was well try to use it unless the application protocol
tells me differently.

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

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

-----Original Message-----
From: Sam Hartman [mailto:hartmans at MIT.EDU] 
Sent: Tuesday, March 26, 2002 3:24 PM
To: John Brezak
Cc: Moore, Patrick; krbdev at MIT.EDU; John Brezak (E-mail); Nicolas
Williams; Matt Crawford
Subject: Re: disallow requests naming principal as a service


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

    John> However in many protocols, you haven't started your
    John> conversation with the server yet to know what it expects. In
    John> the normal Kerberos case as long as the KDC gives you a
    John> ticket, you know that the server must support Kerberos. The
    John> KDC is a trusted-third party that does play a role in
    John> defining the security policy of a realm.

In your environment this may be true.  In my environment it is not; I
have a bunch of hosts that I can get v5 tickets for but only using v4
services will actually work.

More over, there are likely cases when both u2u and normal operation
will be permitted by the KDC, but only one of them is appropriate at the
current time/for the current protocol.

My objection is not to the error return existing or even to the security
implications of using it.  My objection is to what I see as a bad
engineering decision in writing a protocol that does not provide some
authentication mechanism negotiation or that does not use that
negotiation to determine wwhether to use U2U or normal Kerberos.