Subject: Re: Clarifications draft

From: Jeffrey Altman <[email-masked]>
Date: Wed, 31 Mar 2004 17:52:16 -0500

why is item 2 a topic for discussion of Clarifications and not Extensions?

Jeffrey Altman

Liqiang(Larry) Zhu wrote:

>Two comments:
>
>1) Is the following "MUST" too strong.
>
>In section 6.2.1:
>
>      The principal identifier for a server on a host will generally be
>      composed of two parts: ... the name of the host MUST be lower   
>      case...
>
>Can a server NOT on a host, or do we want to say the server is running
>as the local host here? Secondly it says the name is "generally"
>composed of two parts, would that imply everything follows it can not be
>more than a "SHOULD"? Thirdly, since name types do not partition the
>name space, does it imply all host names used as the instance must be
>lowercase? 
>
>Can we consider using a "SHOULD" here? I do not know if I missed
>anything elsewhere in the draft that would also imply host names MUST be
>lowercase.
>
>
>2) we would like to request a new ticket flag "delegated" to be assigned
>to us. Here are the details:
>
>      TicketFlags     ::= KerberosFlags
>              << cut >>
>              -- ok-as-delegate(13),
>              -- delegated (14)
>
>The "delegated" ticket flag is used for service tickets only and when it
>is present, it indicates that the ticket was obtained via delegation,
>such as the "constrained delegation" mechanism shipped in windows server
>2003. 
>
>With constrained delegation, you can obtain a service ticket with an
>alternative cname provided via either a PA data or an additional ticket
>(we call it the evidence ticket). The local policy on the KDC is used to
>decide whether such delegated ticket is issued. 
>
>After discussing with Luke, and later with Sam, we think it is desirable
>to expose the fact that the ticket was obtained via delegation and it
>should be done via in a mandatory field. What immediately came up was a
>new ticket flag.  Note that the server identity used to obtain the
>delegated ticket is recorded in the PAC.
>
>
>We would like to get a consensus in the working group to get the above
>possible changes into the final draft. 
>
>Thanks, 
>
>Larry
>
>
>
>
>

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 31 Mar 2004 14:43:02 -0800

Two comments:

In section 6.2.1:

Thanks, 

Larry

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2004 17:11:42 -0600

On Wed, Mar 31, 2004 at 04:57:17PM -0600, Nicolas Williams wrote:
> I had a request for a new flag (I forget what it was, though I'm sure
> I'll remember as soon as I send this) and Sam insisted that
> authorization data would be better for that.

Predictably, I remember now.  I'd brought this up at the first interim
WG meeting at MIT.  I'd wanted a flag that the KDC could use to say
"treat the client principal as anonymous."  This is like splitting the
policy checked flag into two so we could express a policy like: "this
path is ok and you can use this ticket for session protection, but this
path is not quite so good so don't trust the client principal name."

The idea being that this would be useful in large internetworks that use
hierarchical cross-realm trust relations.

I think such a flag would be best implemented as authorization data, as
would the flag that MS proposes.

Nico
--