disallow requests naming principal as a service

[Moore, Patrick]

[inline}

> -----Original Message-----
> >>Sam> From: Sam Hartman [mailto:hartmans at MIT.EDU] Sent: Tuesday, March
26, 2002 5:51 PM
> 
> >>>>> "Moore," == Moore, Patrick <pcmoore at sandia.gov> writes:
> 
>     Moore,> It's not required by our globus application, nor by U2U
>     Moore,> draft.  We use it if we get it, (and we get it today from
>     Moore,> DCE KDCs) and possibly save some round-trips. The U2U
>     Moore,> draft doesn't preclude in any way negotiating in advance
>     Moore,> whether U2U is required.  But supports that you MAY learn
>     Moore,> that from the KDC or from the server.
> 
> >>Sam> I tried to ask this in SLC (or wherever the U2U mechanism was last
> >>Sam> discussed) but apparently failed.
> 
I agree, the SLC ( 5 minute) discussion was rushed, especially
when MUST_USER2USER came up.  (The important resolution we got 
from SLC was that Kerberos did not need new message types to 
support the TGT-request and TGT-reply.)

> >>Sam> I'd like to see text in the U2u draft discussing negotiation and
> >>Sam> saying that protocol designers contemplating the use of the U2U
GSSAPI
> >>Sam> mechanism should provide a negotiation layer both to provide for
> >>Sam> negotiation of future authentication mechanisms and to provide for
> >>Sam> selection  of U2U vs normal Kerberos  in cases where both are 
> >>Sam> allowed or where the KDC does not communicate the info.
>
Good idea. We can add a section on that in front of the paragraphs
that discuss the options for handling cases where KDC policy or 
server policy may help a legacy or ported client resort to U2U.  
I think I can also clean up some verbiage in the draft so that
it's clearer that the KDC may refuse conventional tickets 
but allow dup_skey tickets without necessarily using a new 
error code or account flag.

> >>Sam> I don't have a problem with giving application designers an error
code
> >>Sam> to work with for legacy applications.  I do want to make sure we
> >>Sam> explain the issues to future protocol designers so that we don't
get a
> >>Sam> bunch of protocols that rely on the KDC returning some error code
when
> >>Sam> doing so will not work correctly even in cases where the KDC
> >>Sam> implements the error.