disallow requests naming principal as a service
pcmoore at sandia.gov
Wed Mar 27 13:55:01 EST 2002
> -----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
> >>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
> >>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
> >>Sam> bunch of protocols that rely on the KDC returning some error code
> >>Sam> doing so will not work correctly even in cases where the KDC
> >>Sam> implements the error.
More information about the krbdev