disallow requests naming principal as a service

[John Brezak]

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

Back to the error response. If the MUST-USE-USER2USER (or
S_PRINC_UNKNOWN+TD-USER2USER) has a checksum of the kerb-error response
in the e-data signed with the TGT session key, the client can take the
suggested action from the KDC.

-----Original Message-----
From: Sam Hartman [mailto:hartmans at MIT.EDU] 
Sent: Tuesday, March 26, 2002 3:13 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> Since the response is not authenticated, the client should
    John> not wholely depend on the KDC to guide its action.

    John> Ultimately, the client's policy should determine what action
    John> to take when the KDC is not able to provide a ticket for the
    John> requested service.  However, it would become very
    John> inefficient for the client to always try user2user if the
    John> KDC failed to return a service ticket.


My argument is that you shouldn't design a protocol that requires the
client to depend on the KDC.  By the time the client asks for a Kerberos
ticket it should already be committed to the non-u2u or U2U protocol.

In the case of SASL or GSSAPI applications, the server should offer the
normal krb5 mechanism only when it has a service key, and a U2U
mechanism only when it has a TGT.