Subject: RE: Comments: draft-williams-krb5-gssapi-domain-based-name

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Oct 2004 09:43:57 -0700

Nicolas Williams wrote:
> Is <DC name> a NetBIOS name?

No, we do not support ldap/<NETBIOS>/<domain>.

> And it has the benefit of looking different from hostbased names. 
> Or, at least, I thought it was a benefit.

I would rather design domain-based-service-names as a super-set of
host-based-service-names, such that a host-based service is just a
domain based service with the domain name being the default value, this
way you can use the existing service@host names at the place where
server@host@domain is needed.  This provides backward compatibility (as
it is an incremental change).

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, October 21, 2004 9:31 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Paul Leach
Subject: Re: Comments: draft-williams-krb5-gssapi-domain-based-name

On Thu, Oct 21, 2004 at 06:46:31AM -0700, Liqiang(Larry) Zhu wrote:
> 
> Windows 2000 has shipped services with the "domain based" names, but 
> the DC name is the second component, and the domain name is the third 
> component.
> 
> For example, the Kerberos principal name for our LDAP servers is in 
> the form of "ldap/<DC name>/<domain name>@<DOMAIN NAME>".

Is <DC name> a NetBIOS name?

> 
> If you do not have a good reason for what is in the current draft, 
> please adjust the order for interoperability and
backward-compatibility.

I didn't have a good reason for any one particular ordering of the
components.

> For consistency, please change the generic "domain based name" to 
> service@host@domain, when the domain name is absent, this can simply 
> be service@host (NOT service@host@).

The generic syntax has it as service@@host when the domain part is
missing.  This is only useful in query form (i.e., as an input to
GSS_Import_name()).

And it has the benefit of looking different from hostbased names.  Or,
at least, I thought it was a benefit.

Nico
-- 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Oct 2004 11:46:25 -0500

> it is an incremental change).

The application still requires changing though, to use the new name type
OID.  Or is there something about the SSPI that obviates the need for
name type OIDs?

Anyways, I don't feel strongly about this one way or the other.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Oct 2004 21:36:39 +0200 (MET DST)

> OID.  Or is there something about the SSPI that obviates the need for

The reality when dealing with SSPI's inconsistent naming in a mix of

(a) meta-knowledge
(b) heuristic trial-and-error
(c) dirty hacks

and the "traditional" SSPI calls (pre-W2K) don't tag names.

e.g. QueryCredentialsAttributes(NAMES) on a SSPI Kerberos credential will
return a correct Kerberos principal name (i.e. REALM name with correct case),
and similarly will QueryContextAttributes(NATIVE_NAMES) return *correct*
Kerberos principal names

However, the two newer SSPI calls, which actually have a parameter to
distinguish name types, namely GetUserNameEx() and TranslateName()
are broken in that they

 (a) do not work at all without an Active Directory

 (b) fail most of the time to produce the default Kerberos principal
     name when requesting "NameUserPrincipal" on most W2K+ platforms.

 (c) do not return correct Kerberos principal names, but instead
     return lookalikes with the lowercase DNS domain name following
     the @ character, which is obviously inconsistent with the semantics
     of QueryCredentialsAttributes(NAMES)
     and QueryContextAttributes(NATIVE_NAMES)

But if you open a command shell and look at the environment of
a Windows W2K+ machine joined to a W2K+ domain, then there is
the environment variable "USERDNSDOMAIN", containing the DNS domain
name in _all_uppercase_ -- which is kind of funny, because it happens
to be the correct spelling for the Kerberos REALM name, and *NOT* the
DNS domain name (I know that the DNS name is actually case-insensitive). 

:-/

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 21 Oct 2004 16:48:23 -0400

> DNS domain name (I know that the DNS name is actually case-insensitive). 

This value can also be found at:

   HKEY_CURRENT_USER\"Volatile Environment"  "USERDNSDOMAIN"

which is how MIT Kerberos obtains it when we can't obtain the realm 
(oops domain) name from LsaGetLogonSessionData().

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Oct 2004 17:07:40 -0500

> OID.  Or is there something about the SSPI that obviates the need for

Sorry I asked that.  I didn't mean to start a thread about bugs in an
implementation on this list.

So, let me rephrase: what is the benefit of changing the generic
domain-based name syntax as Larry requests?

To me it's almost six of one, half a dozen of the other.  Except for
this: service@@host instantly looks like a domain based name using a
default domain, to me, so I prefer it.

Nico
--