Re: [nfsv4] [FedFS] Meeting Minutes, 12/03/2009

[James Lentini <[e-mail]>]

On Thu, 3 Dec 2009, Nicolas Williams wrote:

> On Thu, Dec 03, 2009 at 05:32:35PM -0500, James Lentini wrote:
> > > As for SASL... you have these choices:
> > > 
> > 
> > What about these other SASL authentication mechanisms:
> > 
> > http://www.iana.org/assignments/sasl-mechanisms
> 
> They are clearly not applicable:
> 
>  - KERBEROS_V4 is obsolete.
>  - SKEY is obsolete.
>  - EXTERNAL means "look at the secure channel we're using, likely TLS"
>  - CRAM-MD5 is of limited applicability, and anyways fails to be useful
>    here for the same reasons as DIGEST-MD5 and SCRAM
>  - ANONYMOUS clearly doesn't help
>  - OTP doesn't help
>  - GSS-SPNEGO isn't relevant (you don't want to use it, ever)
>  - SECURID clearly doesn't help
>  - NTLM is like Kerberos, but with obviously much more limited
>    applicability
>  - NMAS_* -- I've no clue what they are, and I doubt they are
>    applicable, and they are listed as having LIMITED use
>  - 9798-* are for authenticating clients, while we want to authenticate
>    servers
>  - KERBEROS_V5 is not really in use, and anyways we have "GSSAPI" and
>    GS2-KRB5 (see previous e-mail), which are applicable

Thanks for the rundown.

> > > So we really only have two choices for server authentication:
> > > 
> > >  - TLS with server certs (and TA mgmt, since we're NOT going to have a
> > >    global PKI)
> > > 
> > >  - Kerberos V5 (via SASL/GSSAPI or SASL/GS2-KRB5)
> > 
> > This is great information, but we were discussing a different question 
> > than what security mechanism are possible.
> 
> You have to take into account what's actually available.  And my post
> did address the issue of what properties are desired.
> 
> > In the current Admin protocol, the client can request a fileserver to 
> > create a junction but does not have a mechanism for indicating the 
> > authentication,integrity,and privacy mechanisms to use when resolving 
> > the junction. The question is therefore, should the Admin protocol's 
> > JUNCTION_CREATE arguments include a parameter that indicates how the 
> > junction should be resolved in the future?
> 
> To me it makes no sense to talk about TA mgmt in the ADMIN protocol if

Agreed. This is why we discussed how a fileserver decides to the 
security properties of an NSDB connection.

> we don't either a) require TLS with confidentiality protection and
> server certs, 

For (a), do you mean that TLS would be required for all NSDB 
connections? That sounds too restrictive. I'd rather allow 
administrators to choose the security mechanism that makes the most 
sense for their situation and SASL is also very popular in the LDAP 
world (as we discussed below regarding Active Directory).

> or b) make NSDB LDAP connection security parameters configurable via 
> the ADMIN protocol.  To me this is an obvious yes. (I've not 
> actually reviewed the ADMIN protocol in detail though.)

Yes, this is one of the options we discussed. The arguments to 
FEDFS_CREATE_JUNCTION would be a natural place to include such a 
parameter and perhaps the appropriate security context as well.

> > > By far the most likely case in actual federated deployments will be "TLS
> > > with server certs".  It's just simpler (e.g., no need to talk to
> > > Kerberos realm administrators).
> > 
> > Doesn't Active Directory use SASL with Kerberos? 
> 
> That's one way to use it (you have to in order to access non-public data
> -- object attributes that have ACLs that don't grant read permission to
> Everyone).

This would be an argument for supporting SASL with Kerberos.