Subject: [nfsv4] Fwd: New Version Notification for draft-adamson-nfsv4-multi-domain-access-04

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Tue, 22 Mar 2011 10:26:16 -0400

FYI

A new version of the multi-domain access draft has been posted.  It
responds to comments on version 03, as well as incorporating the new
KRB WG general-pac draft.

-->Andy

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 13, 2011 1:19:21 PM EDT
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: New Version Notification for draft-adamson-nfsv4-multi-domain-access-04
>
>
> A new version of I-D, draft-adamson-nfsv4-multi-domain-access-04.txt has been successfully submitted by Andy Adamson and posted to the IETF repository.
>
> Filename:      draft-adamson-nfsv4-multi-domain-access
> Revision:      04
> Title:                 NFSv4 Multi-Domain Access
> Creation_date:         2011-03-13
> WG ID:                 Independent Submission
> Number_of_pages: 24
>
> Abstract:
> The Network File System, version 4 (NFSv4) uses a representation of
> identity that allows the use of users and groups from multiple,
> distinct administrative domains, and NFSv4 allows the use of security
> mechanisms that authenticate principals from multiple, distinct
> administrative domains.  This document describes methods by which
> NFSv4 clients and servers can handle principals, users, groups from
> multiple administrative domains.
>
>
>
> The IETF Secretariat.
>
>

---

From: Andy Adamson <[email-masked]>
Date: Tue, 22 Mar 2011 09:47:48 -0400

FYI

A new version of the multi-domain access draft has been posted.  It responds to comments on version 03, as well as incorporating the new KRB WG general-pac draft.

-->Andy

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 22 Mar 2011 11:35:11 -0500

Abstract

   This document describes methods by which
   NFSv4 clients and servers can handle principals, users, groups from
   multiple administrative domains.
users, and groups

----

Introduction

   NFSv4 supports multiple
   authentication methods, each authenticating an "initiator principal"
   (typically representing a user) to an "acceptor principals" (always
   corresponding to the server).
to an "acceptor principal"

--------

Terminology

I'd define POSIX IDs and Windows SIDs before "Local representation of identity"

---

The form of a SID is: S-1-<authority>-<RID_0>-<RID_1>-<RID_n> By
becomes

The form of a SID is: S-1-<authority>-<RID_0>-<RID_1>-<RID_n>. By
---

ID mapping: {remote domain, remote domain-local ID} to {local
      representation of ID} mappings.
I know what you mean here, but I don't know if remote domain-local ID works
for me.

I think this is better:
ID mapping: {domain, domain-local ID} to {local
      representation of ID} mappings.
I.e., a domain is always remote to the local system. The question is whether
you are also defining a local domain (so local domain-local ID) and
one or more remote domain.

And you do just that in the next section. :->

I'd consider ID mapping to apply to any mapping from domain identity to local
identity. That certainly fits how it is used today.

------

5.3 ID Mapping

   between <remote user ID, local user IDs> and <remote
   group IDs, local group IDs>.  We call this an "ID mapping service".
"remote user IDs"

and since you already have a Terminology section, do you need to
provide a definition again?

I like what is there, except for the last sentence, so perhaps:

   Such systems may need to use a ID mapping
   service to map between <remote user IDs, local user IDs> and <remote
   group IDs, local group IDs>.
------

5.4 Use of Name Services

   The Network Information
   Service [NIS] and the Lightweight Directory Access Protocol [RFC4511]
   are the two broadly deployed distributed directory service protocols
   used for this purpose.  LDAP is used instead of NIS in environments
   where scalabilty, security and/or extensibility are desired.

You need to explicitly state that LDAP is a requirement for this work. Or is the
plan to support NIS as well?

---

5.4.1

   Domains with base DNs that do not
   match this convention MAY be used, but their domainname-to-base-DN
   mappings must be published where NFSv4 clients and servers may find
   them; we provide no conventions for publishing such mappings.  We
   RECOMMEND that LDAP referrals be used to publish such mappings (e.g.,
   the client does an LDAP search using "DC=foo,DC=example" as the base
   DN and gets a referral that includes the correct non-standard base DN
   for "foo.example").

   Client and server implementations MUST support the use of LDAP
   referrals to find LDAP servers authoritative for any given base DN.

The text states " we provide no conventions" to "We RECOMMEND", to "MUST support".

I find that to be inconsistent messaging to the implementor.

----

5.4.3

   1.  Just use SIDs, first asking MSFT to allocate a suitable authority
       for non-Windows domain SIDs.

What is a MSFT?

---

  2.  - Store 96-bit numeric IDs which means we:
Either use a number or a symbol, not both

----

6

   including a local ID, a set of local group IDs and other local user
   privileges meaningful to the file system being exported.
needs a comma, to get to:

   including a local ID, a set of local group IDs, and other local user
   privileges meaningful to the file system being exported.
---

   e.g. a directory service in the client
   principals NFS domain.

The editors here prefer to have "e.g.," and "i.e.,".

---

   There are several methods the cross-domain authoritative
   authorization information can be obtained:

methods in which the 

---

6.1

   The credential authorization data contains the user and group IDs
   corresponding to the client principal, in global representation of
   identity form.  Note that the server may need to map the global IDs
   to local IDs as described in Section 5.3.
I found that while I thought I understood what you meant by "global", it was
inconsistent with the both the definitions in Terminology and Section 5.3.

---

6.2

   "privilege attribute certificate" (PAC)
   listing the principal's user and group "security identifiers" (SIDs).
This is the second place we see these acronyms defined. SIDs is in Terminology,
but PAC is not (also defined in item 1 of Section 6).

NOTE: Also see PAC and SID defined in 6.2.1.

----

   principal's user and group "universal user identifiers" (UUIDs)
Is this a mix of terms, i.e., isn't UUID normally an "Universally Unique IDentifier"?

Also, couldn't we use UUIDs to provide the multi-domain access? Very gross,
but an UUID should be unique across all domains.

----

6.2.1.

    Some KDCs (will) issue Kerberos Tickets w
I don't understand the need for '(will)' here.

----

6.3.2

   Name services such as the Solaris gsscred database where the local
   identity is looked up in a database keyed by the GSS exported name
   token, or LDAP with the extension described in Section 8.2, can be
   used to map principal names to user accounts.
I found this very hard to parse. At a minimum, a comma is needed after "database".

----

8

information described in section Section 6 can require a directory
remove 'section'.

----

8.3

   To avoid this, site administrators may wish to maintain local caches of
   remote domains' name services such that LDAP searches for users/
   groups in remote domains can be satisfied locally for some set of key
   attributes (such as naming and ID attributes), with referrals used in
   all other cases.
What is meant by "referrals" here?

-----

   LDIF delta feeds by which to maintain cached LDAP contents up to
   date.The LDAP DN hierarchy described in Section 5.4.1 has the
space needed between "date.The"

----

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Mar 2011 15:10:53 -0500

> identity. That certainly fits how it is used today.

In my mind a local namespace is only distinguished from a domain-local
namespace by weak usage conventions only one system uses the former,
while many use the latter -- but who's to say that the former can't be
upgraded to domain-status?  Still, granting such conventions for the
sake of argument, you're right, the word "remote" does appear to be
redundant.

> provide a definition again?

Well, the definition needs expansion.

> plan to support NIS as well?

Baby steps...  I think this document should be seen as a framework.
Documents should be published separately to specify how to use LDAP
and Simo's "PAD" (PAC-like Kerberos ticket authorization-data) to fit
in this framework.

> I find that to be inconsistent messaging to the implementor.

What's confusing?  Each of the unspecified, recommended, and required
behaviors relate to very different matters.  Base DN construction?
Cannot be specified, but we can make a recommendation (use DC for each
label of a DNS domainname).  And we can use referrals for providing
the glue, so we want to mandate support for referrals.  OTOH, you're
correct, the recommendation is really to the folks deploying this, not
to the implementor, thus the text does need some cleanup -- I just
object to any notion that we can't mix optional, recommended, and
required features, even in the same sentence.

>       for non-Windows domain SIDs.

Microsoft.

> inconsistent with the both the definitions in Terminology and Section 5.3.

I'm not sure what you mean.  But if the issue is the text that says
"in global representation of identity form", then I agree that that
text really should be stricken.

> but PAC is not (also defined in item 1 of Section 6).

Oversight.

> Is this a mix of terms, i.e., isn't UUID normally an "Universally Unique IDentifier"?

That has got to be a typo.

> but an UUID should be unique across all domains.

a) collisions should be practically non-existent, modulo RNG quality
(which means they might be more common that one might expect!);
b) with something like a SID you know where to go to resolve it back
to a name, but with a UUID you do not, since there's nothing in the
UUID to identify any authority;
c) because of (a) and (b) both there may be aliases, without any way
to determine which name is canonical.

We could ignore (a).  (b) can be seen as a privacy featur, or as a
bug, depending on one's point of view.  Of course, protocols could
operate in such a way that whenever a new UUID is seen then a relying
party that cares should ask the peer to provide a name which can then
be shown to resolve to that UUID.  (c) is primarily a user interface
issue, but it's a fairly significant one, IMO.

The intention was to have some debate on this.  I suspect that the end
result will be a desire to support both, SIDs and UUIDs, in both cases
due to their widespread use and their useful semantics.

> I don't understand the need for '(will)' here.

Dunno why it's there.  Should be removed.

> I found this very hard to parse. At a minimum, a comma is needed after "database".

I don't really think a comma helps.  A parenthetical might help more.
To me it's utterly clear.

> information described in section Section 6 can require a directory

Yes.  (I really wish that xml2rfc could correctly capitalize or not
capitalize the word "section" in internal xref rendering...)

> What is meant by "referrals" here?

Imagine an LDAP server that only serves cached content, and in the
case of cache misses returns only a referral.  But I agree, this seems
like a useless behavior.  This text should be changed or removed.  I
think the original intention was to provide for caching LDAP servers
that also include referrals to the authoritative servers.

Thanks for the comments,

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 22 Mar 2011 15:29:08 -0500

> text really should be stricken.

What I meant is earlier, we use domain or remote to refer to what is
being called global here. I'd like to either see a consistent term or
global being defined earlier as an other form of remote.