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

[Nicolas Williams <[e-mail]>]

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

> > 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
we don't either a) require TLS with confidentiality protection and
server certs, 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.)

> > 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).

Nico
--