Subject: RE: Clarifications draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 2 Apr 2004 00:54:13 -0800

> Nicolas Williams wrote:
> IMO, this is a lame way to address architecture problems or legacy
issues in Windows.

We were trying to expose the fact that the ticket is delegated to native
GSSAPI callers. Native SSPI callers can just use the transited services
in the PAC.

> I think you should seek a different approach, even if it means more
work.

> I don't see this as all that bad, even though it means KDC
implementors will have to do more 
> work in order to support interesting extensions.

Luke spoke up what he wanted and the ticket flag proposal emphasized on
end-end-scenarios rather than protocol designs.

If the working group consensus is to use AD, this new AD shouldn't be
critical, that is you should not have to upgrade all the application
servers in order to accept the delegated tickets, but once you upgrade
you can restrict the use of such tickets based on your local policy.
What would be the arguments to consider it critical?

Thanks,

larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, April 01, 2004 8:11 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; Jeffrey Altman; [email-masked]; JK Jaganathan;
[email-masked]
Subject: Re: Clarifications draft

IMO, this is a lame way to address architecture problems or legacy
issues in Windows.

I think you should seek a different approach, even if it means more
work.

Folks, improper implementation of authorization data in deployed systems
is the thing that'll force KDCs to know more about what extensions are
supported by what [service] principals.  I don't see this as all that
bad, even though it means KDC implementors will have to do more work in
order to support interesting extensions.

More below.

On Thu, Apr 01, 2004 at 01:28:44PM -0800, Liqiang(Larry) Zhu wrote:
>  
> > Sam Hartman wrote:
> > Why is the proxied flag inappropriate?  I know we discussed this on
> the phone, but it seems
> > like a question worth answering for the group's benefit.
> 
> a proxied ticket is obtained with the proof of the client credentials 
> initially but you do not need the client credentials to get the 
> delegated tickets, if via the "constrained delegation" mechanism.
> 
> I thought we came out the phone conversation with the plan to ask the 
> working group for a new flag, if denied, we will fall back to use the 
> proxy flags.

I object to the re-use of the proxy flag, even if it is basically
useless.  At the very least I'd want to see a full explanation of how it
solves what problem without introducing interop problems.

> > Clifford Neuman wrote:
> > If you really want a name with a non lower case hostname as the 
> > second
> component, you are
> > still welcome to do so, but the name type would be PRINCIPAL, i.e. 
> > it
> conveys only its
> > uniqueness (oh, and by the way, it falls upon you to ensure its
> uniqueness).  I do not
> > recommend doing this, but it is perfectly valid from the description
> in the document (just
> > don't give it a name type of HST - because it doesn't follow those
> guidelines).
> 
> Yes, the main reason I brought this up was because I felt the 
> description confusing, particularly because the draft constrains 
> NT-HST nametype while stating the name-type does not partition the
name space:
> "Ignoring the name type, no two names can be the same".

Right, but what the "MUST be lowercase" text amounts to is a preview of
the approach to IDN that we settled on at the 58th IETF.  I don't care
to revisit either matter.

> Thanks for clarifying it and this "MUST" makes it possible to derive 
> the name from what is known, therefore I withdraw my objection.
> 
> > Adding a delegate flag now would only serve to further confuse this
> set of mechanisms.
> 
> Just to clarifying my original intention: we wanted to expose it via 
> the ticket flag, because there is already API exposing the ticket 
> flags to application servers. We do not know how we expose the 
> transited services to GSS-API callers at this point. Granted we should

> design the protocol regardless what we can do with GSS-API, though 
> this proposal is definitely meant to be a short term solution and it 
> was requested by Luke.

I object to this approach.  See above.

Cheers,

Nico
--