Subject: RE: Clarifications draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 1 Apr 2004 13:28:44 -0800

> 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.

> 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".

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.

Thanks,

Larry

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

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Mar 31, 2004 at 06:12:03PM -0600, Nicolas
    Nicolas> Williams wrote:
    >> On Wed, Mar 31, 2004 at 04:06:44PM -0800, Liqiang(Larry) Zhu
    >> wrote: > This new flag ("delegated") is not critical, and
    >> application servers may > not process it.
    >> 
    >> As long as it's not critical I don't see why it couldn't be
    >> added.
    >> 
    >> Adding it in clarifications though, is another story -- I'll
    >> defer to the WG chairs on that matter.

    Nicolas> To clarify my position: if you want this non-critical
    Nicolas> flag then you should specify it in a separate document --
    Nicolas> there's no need to delay clarifications.  If you change
    Nicolas> your mind and decide that you want a critical flag then
    Nicolas> you must specify this feature through authorization data.

I think that other document should be extensions.

If you want to start using the flag today, get working group consensus
on the flag, get Cliff to give you a flag number, and start using it now
ever though extensions is not finalized.

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.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Apr 2004 22:11:23 -0600

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.

> working group for a new flag, if denied, we will fall back to use the

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.

> "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.

> definitely meant to be a short term solution and it was requested by

I object to this approach.  See above.

Cheers,

Nico
--