Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-02.txt

[Chuck Lever <[e-mail]>]

> On Oct 8, 2018, at 1:40 PM, Everhart, Craig <[e-mail]> wrote:
> 
> Hi Chuck, thanks for the quick reply.
> 
> On 10/8/18, 12:43 PM, "nfsv4 on behalf of Chuck Lever" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    Hi Craig -
> 
>> On Oct 8, 2018, at 11:48 AM, Everhart, Craig <[e-mail]> wrote:
>> 
>> In the "1. Introduction", the opaque provenance information is described as including a "keyed hash, such as an HMAC [RFC2104]" without any indication as to the management of the key information.  Must that information, also, be taken on faith?  What's the basis for this claim?  Is it required for all provenance information, or just for some?
> 
>    The Introduction describes that as "out of scope" but suggests key
>    management can be done via another distribution channel and stored
>    locally in a Trusted Platform Module.
> 
>    Section 1.1:
>       A Trusted Platform Module [TPM-SUM] can seal the key material used to
>       sign and verify file content.  Distributing and protecting such key
>       material is outside the scope of the OPTIONAL extension specified in
>       this document.
> 
> Are we talking about a keyed hash or signing/verifying the content (as in encrypting a hash)?  They're similar, but different, kinds of operations.

A TPM can be used on end-points to store public keys that can be
used for provenance assessment. This would be typical for a mobile
device using an IMA-protected root file system, for instance, or
on systems where a strong guarantee that the key material is not
tampered with is required.


>> There's an effort made in this draft to distinguish participating/non-participating clients and servers.  Because this draft really talks about only one kind of provenance information, what is to be done with clients or servers that participate in one but not all kinds of provenance information?
> 
>    The Introduction states that "participating" clients have to agree on
>    using the same provenance assessor.
> 
>    Section 1.1:
>       NFS acts as a conduit by which file provenance information and file
>       content move between storage on an NFS server and the provenance
>       assessor where that content is to be accessed.  NFS peers accessing a
>       set of shared files must all agree on the at-rest file provenance
>       information format.  The format is specified by the provenance
>       assessor and is therefore not described in this document.
> 
> So, NFS, as an interchange protocol, is not being tasked with even the little bit of interoperability necessary to identify which kind of provenance information is in use?

No it is not. FPI interoperability is handled (or not) by the
provenance assessor.


>    The document later states that provenance assessors have to be prepared
>    to encounter unrecognized provenance information.
> 
> Recognized how?

Given that the provenance assessor is responsible for interoperability,
I don't see how that question is relevant to NFS or this document.

If you have a problem with this part of the architecture, that is
really about the provenance assessment mechanism, not about the way
NFS transports the FPI. You should take that up with the IMA
community (or whomever is developing your favorite provenance
assessor).

It's outside of the IETF's purview to maintain a registry of FPI
types, especially because there are no FPI types defined by any
standards.


>    Section 5.3:
>       A provenance assessor on an NFS version 4.2 peer needs to be prepared
>       to deal with file provenance information it does not recognize or
>       cannot parse.  Typically its policy treats this case as a provenance
>       verification failure.
> 
>    Again, I'm struggling to see the purpose of deploying multiple
>    incompatible FPI schemas concurrently. Do you have something specific in
>    mind?
> 
> I bring up the issue because NFS can transit multiple storage domains.  Think of it as having multiple authentication domains.  It's the job of the communication protocol not only to deal with how the happy path works, but what happens when it isn't the happy path.

FPI is end-to-end. It doesn't matter how many different copies of
the file there are or on how many NFS servers a protected file
might have resided before an application on a client sees it. FPI
is not a local at-rest checksum. It is not replaced every time a
fresh copy of a file is written on a new server; it is copied
along with the content.

The provenance information and the content must match before the
content is used by an application or OS, end of story. The file
system, whether it is a local FS like ext4, or one that has lots
of distributed moving parts, like CephFS, does not get a say in
whether the content is usable at its end-point.


>> Apparently, the updating of file content must be done in conjunction with updating of provenance information.  What can be done to make such operations mutually atomic?
> 
>    I don't believe these "race conditions" are consequential, typically.
>    While the provenance information does not match the content, assessors
>    will prevent access to that content.
> 
>    Moreover, attaching FPI is usually a final step before content distri-
>    bution, performed separately via a tool. The tool, not the file system
>    stack, has access to the private signing key.
> 
> 
>> What's to be done with a server that wants to vet provenance information, but notices that the stored provenance information is not correct with respect to the stored file content?  Surely there are other, similar, race-like conditions.
> 
>    NFS servers do not vet the provenance information during remote access
>    of content. A provenance assessor on the server may prevent access only
>    to local accessors.
> 
>    Section 5.3:
>       Note that an NFS version 4.2 server may use a provenance assessor to
>       prevent access by local users to protected files.  To enable NFS
>       version 4.2 clients to do their own assessment, an NFS version 4.2
>       server should never prevent remote access to clients if local
>       provenance assessment fails.
> 
>    If the content and FPI are out of sync, local assessment on the server
>    prevents only local access to that content.
> 
>    Because FPI is meant to be end-to-end protection, the goal here is to
>    perform provenance assessment immediately before the content is to be
>    used. Because it is typically expensive, assessment should be done as
>    few times as needed (once?) to guarantee protection. No point in having
>    the server do it and then the client do it again.
> 
> So, finally, a piece of architecture accidentally falls out: you couldn't have the server do assessment once and for all, for all its clients, for all future uses of a file.

See above: FPI is assessed at point of use, not point of storage. No
part of the storage subsystem or file system plays any part in
provenance assessment decisions.


> You're declaring that kind of interaction to be not well-defined.  Why?

This is precisely because the file system plays no part in provenance
assessment.

If you want the server to do the assessment for all clients that access
it, there's no need to expose FPI via NFS. A trust relationship must
exist between the clients and server, of course, and there would need
to be a strong guarantee that the network between the server and clients
is of very high integrity. Perhaps the use of a GSS integrity service
would be required in such a use case.

I could weaken the statement to "a server should not prevent access to
_participating_ clients."


--
Chuck Lever
[e-mail]