Subject: Re: NFSv4 security model

From: Shaya Potter <[email-masked]>
Date: 15 Jan 2003 21:43:44 -0500

(apologies in advance if this is the wrong forum for these questions)

I'm trying to understand the NFSv4 Security model, and am wondering if
anyone has any good pointers (beyond the RFC) on it (papers, talk
slides...)

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)

thanks,

shaya potter

---

From: Mike Eisler <[email-masked]>
Date: Thu, 16 Jan 2003 09:51:34 -0800

>(apologies in advance if this is the wrong forum for these questions)

This is the correct forum.

>anyone has any good pointers (beyond the RFC) on it (papers, talk
At www.connectathon.org there are talks from 1995 onward
that deal with security for NFS and RPC. Authors of interest include
Dan Nessett, Lin Ling, Ram Marti, Jack Kabat, and Mike Eisler. There's
nothing specific about the security model because the model
is essentially that of NFS over AUTH_DES (since renamed to AUTH_DH,
and now deprecated). The white paper by Goldberg and
Taylor from the Summer 1986 USENIX Conference has a clean description
of the model.

>requirement. (uid/gid pair of process of client determines access

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.

    -mre

---

From: Shaya Potter <[email-masked]>
Date: 16 Jan 2003 13:34:22 -0500

> Taylor from the Summer 1986 USENIX Conference has a clean description

thanks, I'll take a look.

> it is trivial to set up compared to anything that is actually

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

Is the reason nothing like this has been done because "if you want that,
just use AUTH_SYS with IPSEC" or is there a different reason.

thanks,

shaya potter

---

From: Mike Eisler <[email-masked]>
Date: Thu, 16 Jan 2003 12:23:43 -0800

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

>supported secrecy/privacy and integrity, much like the RPCSEC_GSS module

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.

---

From: Shaya Potter <[email-masked]>
Date: 16 Jan 2003 15:39:37 -0500

thanks for the response, gives me what to think about.