Subject: [nfsv4] WG work item for Multi Domain Access

From: Spencer Shepler <[email-masked]>
Date: Thu, 3 Sep 2009 09:28:23 -0500

All,

As was discussed during the Stockholm IETF meeting, a proposal
was made to make Andy and Kevin's I-D

http://tools.ietf.org/id/draft-adamson-nfsv4-multi-domain-access-00.txt

a WG work item.

I am working on text for charter update.  In support of that, please
send me email as to your support (or not) of the work and if you
will be able to spend time in review or other input during the process.

For Andy and Kevin, please provide me the timeline that you can
commit to for completion of this item (document completion, wg last  
call, etc.)

Thanks,
Spencer

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 3 Sep 2009 14:35:26 -0400

Kevin and I are finishing up
draft-adamson-nfsv4-multi-domain-access-01.txt which should be out
next week.

Comments on draft-adamson-nfsv4-multi-domain-access-00 and on
draft-adamson-nfsv4-multi-domain-access-01 when it is out are both
most welcome.

-->Andy

On Thu, Sep 3, 2009 at 10:28 AM, Spencer Shepler<[email-masked]> wrote:
> commit to for completion of this item (document completion, wg last call,
> etc.)
>
> Thanks,
> Spencer
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 13:56:52 -0500

At first glance this document is confused.  Kerberos and other realm
names have nothing _directly_ to do with the name@domain user/group
representation that NFSv4 uses on the wire.

Solaris handles multi-domain access[*] just fine, thank you.  How to do
it turns out to be a local problem, not a protocol problem (though, of
course name service protocols are involved, just no additional protocol
work is necessary).  I would be happy to work on a document that
describes one or more methods for _locally_ dealing with multiple
domains.

Nico

[*] OpenSolaris supports N Windows domains, all in one forest or forest
    of forests, where N >= 0 and can be as large as resources allow, and
    1 Unix domain.  The latter restriction would be relatively simple to
    remove.  I've blogged about tihs and related matters at:

    http://blogs.sun.com/nico/entry/can_we_map_ids_between
    http://blogs.sun.com/nico/entry/more_on_the_design_and
    http://blogs.sun.com/nico/entry/sids_part_2
    http://blogs.sun.com/nico/entry/dealing_with_windows_sids_in

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 3 Sep 2009 15:36:36 -0400

> representation that NFSv4 uses on the wire.

Agreed.

> work is necessary).
>  I would be happy to work on a document that

That would be great!

-->Andy

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 8 Sep 2009 02:55:30 -0500

> describes one or more methods for _locally_ dealing with multiple

Thanks for the offer, Nico.  Do you have an idea of timeline?
Andy had asked to move his document to a WG draft and I would
like to ensure we respond to that in a timely manner.  There will
be a small update to the charter to include the work and would
like to have an individual I-D in which we have some consensus
before moving forward.

Thanks,
Spencer

---

From: James Lentini <[email-masked]>
Date: Tue, 8 Sep 2009 10:17:00 -0400 (EDT)

> commit to for completion of this item (document completion, wg last call,

Spencer, 

I support adding this topic to the charter. I will review and provide 
input on future drafts.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Sep 2009 11:56:25 -0500

On Tue, Sep 08, 2009 at 02:55:30AM -0500, Spencer Shepler wrote:
> >Solaris handles multi-domain access[*] just fine, thank you.  How to
> >do it turns out to be a local problem, not a protocol problem
> >(though, of course name service protocols are involved, just no
> >additional  protocol work is necessary).  I would be happy to work on
> >a document that describes one or more methods for _locally_ dealing
> >with multiple domains.
> 

I can provide an outline and let someone else work on getting it into
RFC shape.  A rough outline follows.

There are two aspects to the multi-domain problem:

1) How to represent user and group IDs from multiple domains in one
   filesystem;

and

2) How servers determine a user's group memberships for authorization
   purposes.

Both involve the use of standard name service protocols for user/group
name<->ID resolution services, as well as non-standard name service
protocols where necessary for interop.  Both also involve some mapping
function onto a local namespace -- this is really a local problem, and
could be left out of scope, but it's also the most interesting problem,
and there are pitfalls, so it should be described in at least enough
detail to avoid the pitfalls.

The mapping function could be as simple as: the identity function
applied to "name@domain", with the results stored on disk.  But this
approach imposes a significant constraint on the administrators of these
domains: user and group names must never be reused.  There's no
realistic way to keep name@domain on disk up to date with user/group
renames (which happen quite often in real life), particularly on a
remote domain's NFSv4 servers (real-time employee join/leave data may be
considered privileged, and remote servers may not be sufficiently
privileged).

A better mapping function would be to use the domain-local numeric ID
assigned to each user/group in their domain, qualified with that domain.
I.e., lookup <name> at <domain> to find some ID local to <domain>, then
store <ID>@<domain> on disk.  This function still has a renaming problem
with respect to domain renames, but that is a realistically manageable
problem.

Even better: assign a unique ID to each domain and publish that, so you
can store <user-/group-ID>@<domain-ID> on disk.

Of course, the next problem is: how to store <user-/group-ID>@<domain>
or <user-/group-ID>@<domain-ID> on disk when you have a filesystem that
can only store 32-bit user and group IDs (there are many such
filesystems!).  This is really a local problem.  One could keep a local
database for dynamically assigning a local ID to every <ID>@<domain-ID>,
or one could do that only for remote domains, reserving only a small
part of the local 32-bit ID namespace for remote domains' users/groups.

Or one could change the filesystem implementation to store larger ID
fields, so that one could store a full <ID>@<domain-ID>.  This last was
our choice on Solaris.  (Warning: I've no idea if any of this is
patented or the subject of any patent application, whether by Sun or
anyone else.  I've described many details of the Solaris solution on my
blog, and since many of the details are purely local, I will leave them
out of this post.)

Yet another option is to have a distributed directory for dynamically
assigning domain-local 32-bit IDs to remove users/groups.  I believe
Samba has taken this approach.  Such assignments need to be performed
atomically, which creates some problems, but is probably not a big deal
should the WG want to specify this scheme as an _option_.  (Also, IIRC
this was part of an I-D I wrote on this subject some six years ago,
before we actually implemented a solution in Solaris.)

You can see that there's a fairly large range of local solutions to the
multi-domain ID representation problem.  Some of those solutions have
undesirable negative externalities, but even excluding those there's at
least two or three possible local approaches.

This leaves the user group membership determination problem to solve,
where "user" is the authenticated subject ID in any NFSv4 RPC.  I.e.,
the client principal.  Note that any implementation that has a local
"gsscred" DB notion already solves this problem, though that is not a
great solution -- user group membership determination needs to be
distributed, not local.  And though one could distribute the gsscred DB,
a better solution is desirable.  An RFC could reasonably leave user
group membership determination as a local matter, but it'd be more
satisfactory to describe at least one interoperable solution.

Here one can simply ask the user's home domain, and zero or more other
domains, for the user's group memberships.  Each domain should be able
to list *only* the user's memberships in groups in _that_ domain.

Consider an example with three "federated" domains: a.example,
b.a.example, and c.example.  Suppose [email-masked] is trying to access
files on some file server in that "federation".  The server could look
up "joe" in a.example's name servers to find that Joe has an ID, local
to a.example, of, say, 12345.  Then the server looks up Joe's group
memberships in a.example, then it looks up any additional group
memberships for [email-masked] in b.a.example and c.example.

You can see that this doesn't scale well (the server ends up having to
do as many group membership searches as there are domains in the
federation, and while these searches can all be parallelized, the work
adds up in a large federation).  But you can also see that one can
reasonably limit the group membership searches to just two domains (the
user's home domain and the server's home domain) by using groups that
allow groups to be members.  One can also take the "global catalog"
approach that Active Directoy has.

One can also use the DCE/Active Directory idea of having the directory
servers in the file server's home domain furnish all of the remote
user's group memberships, as an optimization.  This can be done via an
RPC, via user authentication credentials (Kerberos Ticket authorization
data, PKIX certificate extensions, attribute certificates, SAML
assertions, ...).  These are desirable _optimizations_, but only
optimizations.  A GSS-API-mechanism neutral user group membership lookup
solution can and should be obtained where the only GSS detail to enter
the picture is the client principal name and a function for mapping that
onto a username -- this is the only place where the word "realm" should
enter the picture.

Truly interoperable servers should be able to use name services
directly, for group membership lookups.  To do so and remain scalable we
_should_ (not _must_) pursue a simple extension to RFC2307, for
allowing: a) groups to contain groups (including remote groups), b)
groups to contain remote users.  (b) arguably would be just a
convention: usernames containing an '@' should be considered remote and
should be of user-ID@domain-ID or user-ID@domainname.  We should also to
define an operational attribute for storing a domain's ID in the
domain's root DSE.  (a) should consist of a new attribute, most likely.

One could also do the same for NIS, though I doubt there will be any
interest in standardizing that.

(Implementors should probably also be prepared to support the AD schema
and/or RPCs and/or Kerberos Ticket PAC, though these would probably all
be considered out of scope for/by this WG.)

Note that Windows user/group "SIDs" are already in the form user/group-
ID-qualified-with-a-domain-ID.

I think that should be enough for now.  A design team / document editor
should be able to run with that.

Nico
--

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Wed, 9 Sep 2009 14:50:13 -0400

> with respect to domain renames, but that is a realistically manageable

This solution requires lookup access to a name service in another domain?

> part of the local 32-bit ID namespace for remote domains' users/groups.

This is what our draft proposed, except with a distributed database.

> Here one can simply ask the user's home domain,

What is a user's home domain?

> and zero or more other
> b.a.example, and c.example.

What is a federated domain?

> Suppose [email-masked] is trying to access
> files on some file server in that "federation".

Explain to me how the server knows the @a.example portion of [email-masked]?

The user joe performs a GSS context creation with the server, and the
GSS export name is associated with a local representation on the
server.... But what is the association between the GSS export name and
[email-masked] and how is the @a.example determined?

-->Andy

> The server could look

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 14:45:50 -0500

> This solution requires lookup access to a name service in another domain?

Effectively.  You can provide a front-end service that does the name
service lookups, but in the end name service lookups in other domains
are necessary.

> This is what our draft proposed, except with a distributed database.

We considered that, and in the end decided to make such a mapping
ephemeral and local-only.  On disk we only store {<user-/group-ID>,
<domain-ID>}.  Persistent dynamically-allocated mappings, whether
local-only or distributed, has to make assignments atomic and durable,
and more importantly, it needs to recover from failures.  I.e., you
can't lose the mapping DB!

We considered a large number of ways to help w.r.t. atomicity,
durability, and recovery.  In the end it was simpler to go with
local-only, ephemeral mappings.

I do believe there is some, but limited value in a distributed,
persistent mapping DB, but above all the atomicity/durability/recovery
issues must be addressed.  Perhaps the simplest way to do that is to a
priori assign contiguous chunks of UID/GID namespace to congruous,
contiguous chunks of each domain's UID/GID/RID namespace, and within
each chunk-pair do algorithmic ID mapping.  That way you can atomically
and durably allocate all those chunks _before_ they are actually needed
(and thus with plenty of time to make the allocations atomic, durable,
of small overall size, and replicated widely).

Such a service should be OPTIONAL.  Such mappings are really local
matters except where mapped UIDs/GIDs leak onto the wire, or onto
persistent storage that must be able to move from one place to another
(e.g., backups).  The first problem would only happen in the case of
NFSv3 or NFSv4 with stringified UIDs/GIDs, but there's no value in the
NFSv3 case unless other clients and servers can also map back to names
(and legacy ones just aren't going to be able to), and NFSv4 has a
better answer (name@domain).  The latter problem we solved by using
actual SIDs or name@domain in backup file formats, and by storing
{<user-/group-ID>, <domain-ID>} on disk in ZFS.

> What is a user's home domain?

I meant the home domain of the RPCSEC_GSS client principal.  How that is
determined will typically be mechanism-specific.

For example, in an environment where the KDCs include Windows-style
"PACs" in Kerberos Tickets, then the home domain of the client principal
will be one whose SID is the prefix of the user's SID.

If the KDCs don't include PACs in Tickets, then you need something else.
A mapping of client principal to home domain is also feasible, either
via a database (think of the "gsscred" DB), by application of
pre-configured mapping rules, or application of mapping conventions
(such as that Kerberos V5 realm names correspond by trivial
transformation to DNS domainnames, though there are I18N issues here in
that Kerberos V5 has not yet been I18Nized).

The right thing to do here might be to use a GSS-API naming extension
(see draft-ietf-kitten-gssapi-naming-exts-05) by which mechanisms can
export a client principal "domain" to applications, when one is
available.  GSS-API naming extension were meant to, and should provide a
useful abstraction to access client principal information such as that
which comes with the PAC.

See also http://k5wiki.kerberos.org/wiki/Projects/VerifyAuthData

> What is a federated domain?

I used quotes for a reason :)  But to be specific: federated in this
context means that file servers (and possibly clients, and...) in each
of the three domains in the example can do ID<->name lookups in the
other three domains.

> Explain to me how the server knows the @a.example portion of [email-masked]?

See above.

Nico
--

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Wed, 9 Sep 2009 16:29:11 -0400

> determined will typically be mechanism-specific.

Is the user@homedomain required to be unique? What would happen in a
multi-domain name space if there were more than one valid
user@homedomain?

> via a database

This is the purpose of the GSSAuthName to NFSv4Name mappings in our draft.

> (think of the "gsscred" DB), by application of

Pointer to I18N ? (The first google hit is "New Jersey Route 18N !)

> other three domain

OK - Thanks

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 15:34:07 -0500

> multi-domain name space if there were more than one valid

Again, if you're using something like the AD PAC, then the principal
name doesn't even enter the picture.

Yes, of course I think name@domain and user@domain must be unique.  LDAP
(with RFC2307bis+ and/or AD schemas), NIS, NIS+, NetInfo, ... -- all
require that user and group names be unique within a domain.

> This is the purpose of the GSSAuthName to NFSv4Name mappings in our draft.

Ah.  OK, sorry that I misread that (I did say it was a cursory look).

> Pointer to I18N ? (The first google hit is "New Jersey Route 18N !)

I18N == Internationalization.  L10N == localization.  G11N == globalization.

Nico
--

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 10 Sep 2009 09:47:11 -0400

> name doesn't even enter the picture.

Right, and the Kerberos AD PAC example is an excellent one.  We also
need to clarify the relationship between a GSS export name and the
user@homedomain for other GSS security mechanisms (PKU2U) and other
directory services.

> require that user and group names be unique within a domain.

OK. When there are multiple DNS domains associated with a GSS export
name, one DNS domain is chosen as the 'home domain"? For example, a
Kerberos realm that services multiple DNS domains, there is only one
DNS domain chosen as the homedomain?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 10:28:02 -0500

> user@homedomain for other GSS security mechanisms (PKU2U) and other

But if you can push the responsibility for that to the mechanisms
themselves, by using the GSS-API naming extensions, that's even better.
You then get to avoid having to parse mechanism-specific principal names
in NFSv4.  You don't have to use the GSS-API naming extensions -- I just
recommend it (and note that MIT will be getting an implementation soon).

> DNS domain chosen as the homedomain?

Yes.

Say you have FOO.EXAMPLE, and foo.example, and several sub-domains, but
no sub-realms.  Then all principals in FOO.EXAMPLE must have names that
are unique to FOO.EXAMPLE, and by convention, foo.example.  That
convention isn't universal (though it ought to be), but I think that's
OK.

As I said, I'd rather such conventions be encoded in the mechanism
itself.  This is because then you can implement a variety of rules,
including configurable rules, and use the PAC when it's present, all in
the mechanism rather than in the application, and then you can re-use
that in other applications (CIFS, WebDAV, ...).

Nico
--

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 10 Sep 2009 13:25:07 -0400

> that in other applications (CIFS, WebDAV, ...).

OK. Now for the sake of argument, let's consider a file server that
exports with both Kerberos and PKU2U. Should an NFSv4 user of this
file server have the same user@homedomain whether or not that user
authenticated with Kerberos or PKU2U?

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 12:34:26 -0500

> authenticated with Kerberos or PKU2U?

Yes, they should.  The specific way in which their certificate subject
name or altnames are mapped to a single to that username in that domain
may well be very domain-specific, or it may adhere to some common
convention.  The application ought not have to be aware of those
details, which is why putting them in the mechanism and accessing that
via a naming extension makes sense.

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 10 Sep 2009 13:55:10 -0400

> via a naming extension makes sense.

OK. Now for the sake of argument let's consider a file server that
exports a u32 uid based file system with Kerberos realm REALM-1.
Another Kerberos realm REALM-2 as a cross domain trust with REALM-1,
and REALM-1, and REALM-2 share a name translation service. (this
exists at UMICH, on the grid, ....).

Should an NFSv4 user of this file server have the same user@homedomain
whether or not that user authenticated from REALM-1 or REALM-2?

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 13:59:30 -0500

> exists at UMICH, on the grid, ....).

That's a very odd setup.  I grant that it exists.  And that UMICH is not
unique, for example: here we have an official realm, SUN.COM, and
additional lab realms, with a one-way trust so that we can reach lab
machines, but the lab realms often have users defined which are also in
SUN.COM.

> whether or not that user authenticated from REALM-1 or REALM-2?

Off-the-shell, no.  It should be possible to specify rules that allow
for that.  The evaluation of such rules, is best left as a mechanism-
specific detail abstracted by the GSS-API naming extensions.

The only reasonable rule to apply off-the-shelf is a straightforward
realm->domainname mapping rule (for all-ASCII realm names that rule
would be simply "tolower()"; for non-ASCII realm names such a rule
cannot yet be defined).  Even this is best abstracted via GSS-API naming
extensions.

Let's outline the work item(s) then:

 - One I-D/section to cover ID mapping, possibly including an optional
   protocol for consistently mapping {remote ID, domain ID} onto a local
   small integer namespace.

 - One I-D/section per-GSS-API mechanism to cover cover client principal
   -> {username, domain} and/or client principal -> authorization data
   (user and group IDs, possibly privileges and other relevant data).

    - This should include any Kerberos realm -> domain name and PKIX CA
      -> domain name conventions, recommendations for ways to add
      realm-specific rules, possibly the format of such rules (to make
      it possible to portably define such rules).

 - One I-D/section to cover username@domain -> authorization data
   lookups.  (This part is generic, and can be referenced by the
   previous item.)

 - One I-D/section to put it all together for NFSv4.  (The others are
   not really specific to NFS...)

Does that make sense?

Nico
--

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 10 Sep 2009 17:20:35 -0400

>   not really specific to NFS...)

That sounds right, a good approach. BTW: in
draft-adamson-nfsv4-multi-domain-access-00 we introduce the concept of
the NFSv4 Domain and NFSv4 Domain name (section 3). The NFSv4 Domain
Name is the same as the homedomain.

At the end of the day, Kevin and I thought it was important to have
this restriction for NFSv4 multi-domain access:

'there is only one user@domain NFSv4 user in the whole federated (or
multi domain) namespace'

The above discussion WRT GSS security mechanisms and mappings to
homedomain basically enforces this. I think that the section that you
decribe above to 'put it all together for NFSv4'  should insist on
this.

I think we also need to specify what happens with AUTH_SYS, because it
will be used.

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 16:33:31 -0500

On Thu, Sep 10, 2009 at 05:20:35PM -0400, William A. (Andy) Adamson wrote:
> > [...]

I don't think we need to define a concept of an "NFSv4 Domain".  NFSv4
already has a concept of "domain" in its representation of identities on
the wire.  What we need is to say how the representation of identities
on the wire relates to entities such as "users" and "groups" in existing
directories.

> 'there is only one user@domain NFSv4 user in the whole federated (or

Why couldn't I have two equivalent accounts?

What we should want to say, I think, is that every user and group must
have a canonical name@domain, and that whatever ID mapping scheme is
used, if any, it must remain possible to return the canonical
name@domain for any identity referred to on disk.

> I think we also need to specify what happens with AUTH_SYS, because it

See my RPCSEC_GSSv3 proposal.  One of the modes of operation it supports
is a modernized form of AUTH_SYS:

 - use the GSS-API to authenticate the client (corresponding, roughly,
   to the AUTH_SYS source port < 1024 "authentication")

 - and have the client assert the user's identity and even authorization
   data such as groups, in name@domain form.

Death to AUTH_SYS :)

Nico
--