Subject: WGLC for domain-based service principal names?

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Mar 2006 14:54:08 -0600

Are they ready?  Anybody want to review them again?

The NFSv4 WG seems to be reaching consensus on a method for discovering
a domain's "root" NFSv4 servers based on DNS SRV RRs, and this requires
either the use of DNSSEC or domain-based service principal names.  It
might be useful to the NFSv4 WG to have proposed standard docs for
domain-based service principal names that can be referenced from that
I-D.

The domain-based service principal name I-Ds have been reviewed in the
past, but not particularly recently.  Should we do a WGLC?  Exhort
participants to review them [again, in some cases]?

Nico
-- 

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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 02 Mar 2006 17:38:00 -0500

> participants to review them [again, in some cases]?

I agree that we would like to provide the NFSv4 as well as LDAP the
ability to use domain service principals.  Here are the drafts for
reference

http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-domain-based-names-01.txt

There was significant discussion prior to the publication of the
drafts and no discussion on the list afterwards.  The primary concern
before publication was that the specification be compatible with
that used by Microsoft.

I will request that people review these documents in the next couple
of days.  If there is nothing jumping out at people, I will issue a
WGLC.  However, I will require positive signs of support in order to
successfully conclude the WGLC.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Mar 2006 16:43:22 -0600

On Thu, Mar 02, 2006 at 05:38:00PM -0500, Jeffrey Altman wrote:
> WGLC.

Thanks.

>        However, I will require positive signs of support in order to

Of course.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 3 Mar 2006 11:45:25 +1100

>before publication was that the specification be compatible with

The Kerberos principal name format appears to be compatible with that
used by MS. I guess Larry should take a look though.

-- Luke

--

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Thu, 2 Mar 2006 17:04:54 -0800

the initial draft was not compatible with the deployed base, and I
raised the objection and Nico changed it to be compatible, but I would
take a look at the latest version again, report back if there is any red
flag. Thx.

-----Original Message-----
From: Luke Howard [mailto:[email-masked]] 
Sent: Thursday, March 02, 2006 4:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: WGLC for domain-based service principal names?

>before publication was that the specification be compatible with that 
>used by Microsoft.

-- Luke

--

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 3 Mar 2006 01:10:09 -0800

The name representations seems unchanged after the initial discussion.

"not necessarily and Internat domain name"

s/and/an/

I am not sure the following claims are fully justified/demonstrated.

  If there were other LDAP directories, then
   clients could not tell which service is authorized to serve which
   directory, not without assuming a secure method for finding LDAP
   servers (e.g., DNSSEC).  This is a significant, and oft-unstated
   restriction on users of LDAP.

   Domain based names can eliminate this problem by allowing LDAP
   service names to indicate which LDAP directory they are authorized to
   serve.

I would personally believe some facelifting such as the removal of the
word TBD help make these ready for WGLC.
-- Larry

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: Thursday, March 02, 2006 2:38 PM
To: [email-masked]
Subject: Re: WGLC for domain-based service principal names?

Nicolas Williams wrote:
> The NFSv4 WG seems to be reaching consensus on a method for 
> discovering a domain's "root" NFSv4 servers based on DNS SRV RRs, and 
> this requires either the use of DNSSEC or domain-based service 
> principal names.  It might be useful to the NFSv4 WG to have proposed 
> standard docs for domain-based service principal names that can be 
> referenced from that I-D.
> 

http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-base
d-names-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-domain
-based-names-01.txt

There was significant discussion prior to the publication of the drafts
and no discussion on the list afterwards.  The primary concern before
publication was that the specification be compatible with that used by
Microsoft.

I will request that people review these documents in the next couple of
days.  If there is nothing jumping out at people, I will issue a WGLC.
However, I will require positive signs of support in order to
successfully conclude the WGLC.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 11:30:02 -0600

> The name representations seems unchanged after the initial discussion.

No?  I'll dig up the e-mails and double check.

>    restriction on users of LDAP.

Which part of this is not justified?

Given a client that has no idea who its LDAP servers are but which does
have Kerberos V credentials, how can it tell if the LDAP servers
discovered through a DNS SRV RR lookup are the ones it should be talking
to?

With a priori configuration, particularly of trust anchors and/or
self-signed cert pre-sharing, sure, the client can throw out fake
(spoofed) results.  But using only Kerberos V and only host-based
service principal naming it cannot tell the difference between two
legitimate LDAP servers only one of which is legitimate as a DS for the
domain.  I have seen environments where there is one set of LDAP servers
for the domain's DIT and other sets of LDAP servers for entirely
different purposes, but still in the same domain.

You might ask "but what administrator would give such other LDAP servers
ldap service principal accounts?" -- and that leads to a workaround, but
that workaround does not work for NFSv4, where we want to have lots and
lots of NFSv4 servers in some large domain, but very few "root" NFSv4
servers.

>    service names to indicate which LDAP directory they are authorized to

Is there anything wrong with this?

Of course.

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 3 Mar 2006 09:59:31 -0800

> Which part of this is not justified?

It is unclear to me how can we leverage the domain based name to obviate
DNSSEC, can you elaborate on that?

>    restriction on users of LDAP.

Also I think the word "domain" already has specific meanings, how about
"replicated service name" instead, that is more accurate or more
specific, isn't it?

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 9:30 AM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Altman; [email-masked]
Subject: Re: WGLC for domain-based service principal names?

Of course.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 12:07:35 -0600

> DNSSEC, can you elaborate on that?

Sure.  Let me give two examples, one using NFSv4 and one using LDAP.

With NFSv4 there might be three replicated root servers for, say,
sun.com, and hundreds of non-root servers.  All of these get
nfs/[email-masked] principal names, but only the root servers get
domain-based service principal names for the 'nfs' service and the
'sun.com' domain.  If a client's DNS SRV lookup for sun.com's root NFSv4
servers gets spoofed in an attempt to re-direct the client then the
client will not be able to obtain tickets for the non-root servers it is
being re-directed to because those servers would not have domain-based
service principal accounts for nfs and sun.com.

In the case of LDAP sun.com might have one set of LDAP servers for the
enterprise, and several unrelated LDAP servers for various purposes,
e.g., test, development, meta-directories, etc...  Clients configured to
use LDAP as a name service should only use the first set, and only that
set should have domain-based service principal names for the 'ldap'
service and the 'sun.com' domain.  The same logic as above protects the
client against spoofs.  Clients of the other LDAP servers have to be
configured to securely find them using something other than DNS SRV RRs.

> "replicated service name" instead, that is more accurate or more

Yes, "domain" is a bit overloaded.  The DNS sense of the word suffices
here, I think.

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 3 Mar 2006 10:50:46 -0800

Ok, I am happy with the examples. The text in the ID is terse, but
otherwise seems to be fine. 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 10:08 AM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Altman; [email-masked]
Subject: Re: WGLC for domain-based service principal names?

On Fri, Mar 03, 2006 at 09:59:31AM -0800, Liqiang(Larry) Zhu wrote:
> It is unclear to me how can we leverage the domain based name to 
> obviate DNSSEC, can you elaborate on that?

> Also I think the word "domain" already has specific meanings, how 
> about "replicated service name" instead, that is more accurate or more

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 13:02:58 -0600

> otherwise seems to be fine. 

Thanks.  I'll wordsmith it.

Of course, one might wonder if we don't need something else beyond
domain-based service principal names, something like "instance-based"
service principal names.  The LDAP example, in particular, makes me
wonder about that.

Care to comment on whether we need "instance-based" service principal
naming?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Mar 2006 17:15:21 -0500

> Care to comment on whether we need "instance-based" service principal

Maybe, but that's a different name type.  For domain-based SPN's, you can 
use the traditional domain-to-realm mapping to choose a realm name.  At the 
GSSAPI layer, this means you can pass in 'service@host@domain' or whatever 
it is, and the krb5 mech can determine the right realm, just as it does for 
host-based service names today.  For an instance-based service name, with 
or without a separate hostname part, there is no way for a krb5 mechanism 
to choose a correct realm.  More generally, for any service using a 
non-domain-based instance name, the application is going to have to define 
some independent way to figure out where the server is.

It seems to me that instance-based service names at the GSSAPI level are of 
marginal use, if any.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Mar 2006 16:25:17 -0600

On Mon, Mar 06, 2006 at 05:15:21PM -0500, Jeffrey Hutzelman wrote:
> Maybe, but that's a different name type.

Of course.

>                                           For domain-based SPN's, you can 

I think a host part would always be needed, and clients could determine
the realm of the service from the realm of the host, but that's clearly
not ideal.  Excellent point.  I'll leave the crossing of the
instance-based service principal naming bridge for whoever comes to it.

Thanks.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Mar 2006 17:46:16 -0500

On Monday, March 06, 2006 04:25:17 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

> not ideal.

I don't think that helps at all, in fact.

If you have a domain-based service name "service@host@domain", the realm 
_must_ be determined from the domain part, not the host part, because you 
don't know the host part authoritatively.

If you have an instance-based name "service/instance", you have to somehow 
know the realm; domain-realm mapping doesn't help you.

If you have an instance-based name with host "service/host/instance", you 
still have to know the realm; domain-realm mapping on the host doesn't help 
you because you don't know the host authoritatively.

Now, I can see a few cases where instance-based krb5 principal names with 
hosts might be insteresting, but they are all cases where we currently use 
instance-based names without hosts, but would like not to have to manage a 
service key shared between hosts (because that's annoying).

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Mar 2006 17:00:04 -0600

> don't know the host part authoritatively.

Yes, which is what we decided to do with domain-based service principal
naming.  That wouldn't be possible for instance-based SPNs unless they
were an extension of domain-based SPNs.

Anyways, you've certainly convinced me that this is not something for
KITTEN WG to tackle now :)

Nico
--