disallow requests naming principal as a service

[John Brezak]

This is a good point. It does let the requestor know that if it goes
through the u2u exchange with the server, that it may be able to get a
ticket.

We are still left with the possibility that a MITM has modified the
krb-error. But worse case, it will cause the client/server to do extra
work to get authenticated or no work (DOS).

-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: Wednesday, March 27, 2002 4:58 AM
To: Sam Hartman
Cc: John Brezak; Moore, Patrick; krbdev at mit.edu; John Brezak (E-mail);
Nicolas Williams; Matt Crawford
Subject: Re: disallow requests naming principal as a service


I would look at this a little differently. The
KDC_ERR_MUST_USE_USER2USER flag's name is misleading. What the KDC is
saying, is it won't issue a normal service ticket for this principal,
but it could issue a u2u ticket. This is advising the client that if it
wants a service ticket, this is the only way to get one. Maybe the flag
should be called 
KDC_ERR_NO_NORMAL_SRV_TICKET_BUT_USER2USER_MIGHT_WORK :-)
 

Sam Hartman wrote:
> 
> >>>>> "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.
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev

-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444