disallow requests naming principal as a service

John Brezak jbrezak at windows.microsoft.com
Tue Mar 26 18:19:00 EST 2002

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.

More information about the krbdev mailing list