From: Mike Eisler (mike@eisler.com)
Date: 01/16/03-02:23:43 PM Z
Message-ID: <3E2714CF.8040804@eisler.com>
Date: Thu, 16 Jan 2003 12:23:43 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: NFSv4 security model
>
>
>
>>>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:46 AM Z CST