[nfsv4] Upcoming discussion of draft-adamson-nfsv4-multi-domain-access-03.txt on Fed FS call.

["William A. (Andy) Adamson" <[e-mail]>]

The draft-adamson-nfsv4-multi-domain-access-03 ID will be discussed
(along with other items) during the FedFS call this Thursday, October
28th.

FedFS call:
 Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
        303-218-2659 (international)
    Id: 2354843

The mulit-domain access draft is intended to (eventually) work well
with the general PAC described in
draft-sorce-krbwg-general-pac--00.txt, a new krb-wg draft. The general
PAC being the Kerberos version of the RPCSEC_GSS PAC described in the
mutli-domain draft. Currently, the issues that arise combining the two
IDs are being discussed on the KRB-WG.

The NFSv4 WG may or  may not be the appropriate group to discuss the
Kerberos/GSS-API PAC issues, still, I suggest reading
draft-sorce-krbwg-general-pac-00.txt and to checkout the thread about
it on KRB-WG:
https://lists.anl.gov/pipermail/ietf-krb-wg/2010-October/thread.html

Here are some issues to discuss on the call. Other issues/questions welcome.

Section 5
This section includes an informative discussion of  local
representations of global identity and the use of LDAP naming services
and ID mapping to provide multi domain capabilities for local-domain
only POSIX ID local representations (32bit UID/GID).

Issues:
a) LDAP as required-to-implement
b) Mandating how to configure the base DN, and how it is mandated

Our thinking is to REQUIRE to implement the above but allow OPTIONAL
methods for dealing with domains with base DNs that don't conform, for
NIS, SAML, ... instead of LDAP, ...

Section 6
This section discusses how to map an RPCSEC_GSS principal to a local
identity representation plus file access authorization information
including a set of local group representations.

Issues:
a) What is the Global ID form referred to in the RPCSEC_GSS
Authorization Context: Is it an SID? a
UUID(draft-sorce-krbwg-general-pac-00.txt)? some other form?
b) For global ID construction,  we need to identify domains by ID. How
do we identify domains by ID, and how do we enforce domain ID
uniqueness?

One suggestion is that each federation should run a minimal directory
of its own to contain such things as the names and IDs of member
domains and to provide resolution of those items.  By making this
minimal it can be easily replicated (and needn't even be an LDAP
directory).

Section 6.3
User Group Membership Determination

Issue for discussion from Nico:

This came up recently in the ABFAB WG / moonshot community, and it is
related to an issue that came up at KITTEN WG a few years ago:
depending on the terms of federation membership it may not be possible
to determine any attributes about a initiator principal other than a)
those asserted by their home domain, b) those asserted by the acceptor
principal's domain.  That is, it may not be possible to determine all
of a user's group memberships across a federation.  Moreover, you may
only get the attributes that the principal's home domain is willing to
assert, which may not be all of them -- privacy reasons.

This has implications for DENY ACL entries, namely: you must not add
DENY ACEs for groups unless you have an agreement that will be able to
determine memberships in those groups.  Typically this will mean that
only groups in the acceptor principal's home domain can be used for
DENY ACEs.

Another implication is that if there might be any DENY ACEs, not only
must we limit them to groups whose memberships we stand a chance to
resolve, but also we need to knoe when the authorization context
resolution process has any transient failures, so that we can then
decide to reject authorization altogether (if, indeed, an ACL has DENY
ACEs).

Besides, for scalability reasons we couldn't have systems doing O(N)
searches, where N is the number of domains in the federation, in order
to fully determine the authorization context of a principal.

The only workaround I see: have one federation-wide directory to hold
federation-wide groups and their memberships (but not users).  Then
servers will be able to lookup users' group memberships in
federation-wide groups (including via group nesting).  And servers
could then have DENY ACEs with federation-wide groups, groups from the
acceptor principals' domains, local groups, and users from anywhere in
the federation.

-->Andy