From: Shaya Potter (spotter@cs.columbia.edu)
Date: 01/16/03-02:39:37 PM Z
Subject: Re: NFSv4 security model From: Shaya Potter <spotter@cs.columbia.edu> Message-Id: <1042749577.32408.331.camel@zaphod> Date: 16 Jan 2003 15:39:37 -0500 thanks for the response, gives me what to think about. On Thu, 2003-01-16 at 15:23, Mike Eisler wrote: > > > > > > > >>>also a simple question. Is the security model made in a way that allows > >>>one to authenticate the entire client machine i.e. get the security one > >>>would get from running current NFS over ipsec, but w/o the ipsec > >>>requirement. (uid/gid pair of process of client determines access > >>>rights) > >>> > >>NFSv4 mandates the implementation of RPCSEC_GSS > >>w/ Kerberos V5, SPKM-3, and LIPKEY. > >>Like AUTH_DH, the mandatory security mechanisms are oriented toward > >>authenticating individual users, and not > >>client machines. There's nothing preventing one from deploying > >>security mechanisms for NFSv4 that authenticate machines, but > >>since those mechanisms are not mandatory, the in theory the chances of > >>achieving interoperability are lower. That said, I'm sad to say > >>that AUTH_SYS and its de-facto trusted client model are likely > >>to be used with NFSv4 for a long time, simply because it > >>it is trivial to set up compared to anything that is actually > >>secure. > >> > > > >ok, this might be a stupid question, but it seems accepted that AUTH_SYS > >doesn't provide any real security (except if one is using IPSEC or has > >extreme physical security) as one could easily impersonate a machine, so > > > > Even if running IPsec, AUTH_SYS still doesn't prevent Mallet from > impersonating > Alice. Trivial ways include: > Mallet, who knows the root password, su's to Alice > Mallet, who knows how to use rpcgen, produces a user level > NFS client in a matter of hours, and accesses Alice's data. > (Or Mallet simple uses google to find a user level NFS client > source code). > > > > > >why wasn't their any middle ground taken, such as an AUTH_SYS that > >supported secrecy/privacy and integrity, much like the RPCSEC_GSS module > >does. > > > > Several things in no particular order: > - Those NFS developers among us who were involved with or aware of > the activities around adding AUTH_DH and then AUTH_KERB > (Kerberos V4), got fed up with cryptographers publishing papers > sooner after telling the world that the crypto system was too > weak. We wanted to build file access protocols, not rewrite our > implementations to add yet another security flavor. With > RPCSEC_GSS, we've got a generic flavor that is flexible > enough to add stronger crypto without changing the NFS > implementation again. > > So if one wants something equivalent to AUTH_SYS with privacy and > integrity without IPsec, one can still use RPCSEC_GSS. > Just design and implement a security mechanism plug in (call it > "mech_sys_plus" for the GSS-API, and it will all "just work". > But for the reasons that follow, that wasn't consider sufficient. > > - as noted above, AUTH_SYS with IPsec or its own > integrity/privacy still doesn't provide > authentication at the granularity of the user. > > - For some people, host granularity integrity/privacy might not be enough. > Since all traffic for all users uses the same IPsec session key, that > offers Mallet more ciphertext to perform cryptanalysis with. > > - AUTH_SYS uses 32 bit uids, and is limited to 16 > groups. These limits may ultimately may force the move from AUTH_SYS > to the mandated security mechanisms which: > - uses string based principal names, hence allow an infinite number > of users. > - don't send group ids on the wire, so the server maps the principal > tp whatver groups the user is in. >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:47 AM Z CST