Subject: Re: Clarifications draft

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 01 Apr 2004 08:35:50 -0600

After looking at all the messages from last night, I have some comments
on this. 

(First the message should have been two seperate messages.)

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

I would say the wording is appropriate. It says a "server on a host"
You are proposing a "server NOT on a host" So your scenario is not covered by this.
What this is saying as others have pointed out that NT-SRV-HST and  
GSS_C_NT_HOSTBASED_SERVICE would be used here. 

These flags say the instance will be the FQDN in lowercase. 

If you server is not host based, then don't use NT-SRV-HST or
GSS_C_NT_HOSTBASED_SERVICE. 

So I don't see why you need a change. 

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

This should be in extensions if at all.

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

But the PAC is not Kerberos, it is Microsoft only. So if you are implying that 
if the flag is set, then one should check the PAC to see if it is acceptable,
then this in not Kerberos!

As someone else pointed out you could use the AD-IF-RELEVANT container.
This falls with in Clarifications. It could have your flag, and the 
service name which you say is in the PAC. It would also allow other
Kerberos implementations to check this without hainvg to look at the PAC. 

Is there some reason you cant set this flag using AD-IF-RELEVANT?

> 
> We would like to get a consensus in the working group to get the above
> possible changes into the final draft.

I think it is too late in the process to be adding changes like this to 
clarifications. We can look at consensus later in the week as more people 
get to read this thread. 

> Thanks,
> Larry

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Apr 2004 17:00:08 +0200 (MET DST)

I think that the MUST lowercase for the hostname is a GOOD THING and
should remain.  (DNS-)Hostnames are case-insensitive, and this is
not going to change.  Since the traditional Kerberos authentication
is name-based and case-sensitive, a canonicalization of the hostname
part should be required.  MUST lowercase is a transformation that
can be performed locally and does not need a network roundtrip.

---

From: Luke Howard <[email-masked]>
Date: Fri, 2 Apr 2004 01:35:44 +1000

>Is there some reason you cant set this flag using AD-IF-RELEVANT?

I'd initially brought this up with Sam and Larry because it seemed to
me that conveying that delegation was used should be critical. Because
Windows encloses the PAC in AD-IF-RELEVANT, it is effectively non-
critical. (A service that does not examine the PAC will have no idea
that constrained delegation was used.)

But, as Nico has pointed out, an additional ticket flag also implies
non-criticality. Given this apparent lack of difference, it probably
boils down to semantics: if the IETF do not wish to reserve another
ticket flag, then perhaps a new authorization data type (to be enclosed
in AD-IF-RELEVANT and AD-KDCIssued) should be defined.

Indeed, this could probably just be the transited service list included
in the MS PAC, encoded in ASN.1 instead of NDR:

AD-TransitedServices ::= SEQUENCE {
        proxy-name[0]           PrincipalName,          -- target service
        transited-services[1]   SEQUENCE OF Principal   -- transited services
}

-- Luke

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 01 Apr 2004 11:06:05 -0600

> that constrained delegation was used.)

Section 1.4.1 says: 

      One of the primary uses
      of authorization data is to restrict the use of the ticket. If the
      service cannot determine whether the restriction applies to that
      service then a security weakness may result if the ticket can be
      used for that service. Authorization elements that are optional
      SHOULD be enclosed in the AD-IF-RELEVANT element.
 
Iif Microsoft feels it is critical that these tickets not be used without
exmaining the information, then either split the information out of from 
the PAC, and give it its own AD type not enclosed in AD-IF-RELEVANT,
or don't enclose the PAC in AD-IF-RELEVANT in some situations. 

I prefer the former, The PAC is not Kerberos, and so should be considered
optional.    

I don't think trying to change the deffinition of the PAC from "optional"
to "critical" is a good thing to do. If there is something (new?) in the PAC 
that needs to be in the Kereberos protocal so non Miccosoft code 
can use it, then lets get it out of the PAC and into its own AD type. 
This could be a seperate draft. 

So this sounds like Microsoft it trying to list all the principals
involved in any delegation? If so that is commendable and IMHO
needs to be in Extensions in some form or another. 

With the use SSH and delegation, there are to many places a TGT 
could get stolen and misused. This would allow for tracing of this
at least and maybe of controlling the use of these TGTs. I server
could reject a ticket if it did not like some system in the
delegated list. (very similiar to the realm transited list, but
on a server bases.)

>         transited-services[1]   SEQUENCE OF Principal   -- transited services

Yes something like this would make it accessable to other Kerberos 
implementations. 

--

---

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

On Thu, Apr 01, 2004 at 11:06:05AM -0600, Douglas E. Engert wrote:
> to "critical" is a good thing to do.

It means that the KDC has to know more about the target principals of
KDC-REQs so that it can know whether and how to include some authz-data
type or even whether to issue the ticket at all.

Nico
--

---

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

> Can a server NOT on a host, or do we want to say the server is running
               ^^^^^^^^^^^^^
Can't parse this.

> anything elsewhere in the draft that would also imply host names MUST be

I think we've already agreed on an IDN strategy and that should inform
us with respect to non-IDNs: wherever hostnames (domainnames) are used
as components of principal names their domain labels MUST be lower-case
if they are ASCII (i.e., non-IDN cases).  Anything else may not interop.

As for host-based hostnames, I believe RFC1964 and CFX are the
controlling authority here: you can use host-based principal names that
don't have exactly two components (<service> / <hostname>) only in
non-GSS contexts (or, for that matter, only in contexts where clients
know what to do), else you'll have interop problems.

Cheers,

Nico
--

---

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

On Wed, Mar 31, 2004 at 05:52:16PM -0500, Jeffrey Altman wrote:
> why is item 2 a topic for discussion of Clarifications and not Extensions?

More to the point: why use new ticket flags where authorization data
would do?

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.

Also, I thought that new flags were not to be critical.  New critical
flags might cause problems, which makes the use of authorization data
for this all the more appropriate since criticality is fully under
control in authorization data.

Sam?

Nico
-- 

> Liqiang(Larry) Zhu wrote: