Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07

[Chuck Lever <[e-mail]>]

> On Oct 29, 2019, at 2:23 PM, Craig Everhart <[e-mail]> wrote:
>> 
>> inline
>> 
>> On Tue, Oct 29, 2019 at 1:59 PM Chuck Lever <[e-mail]> wrote:
>> 
>> 
>> > On Oct 29, 2019, at 12:10 PM, Craig Everhart <[e-mail]> wrote:
>> > 
>> > I think the reason it’s difficult for me to endorse this is that I can’t play in the understanding of integrity, and I’d like to understand any weaknesses.
>> 
>> > Apparently it uses something like what I loosely described, but I have no visibility into it or how it works.
>> 
>> You do have visibility. You can go and look at the references cited
>> by the document. In fact there's a USENIX paper that explains the
>> architecture and provides the analysis you are looking for. There's
>> an open implementation that is available as a prototype and proof of
>> concept.
> 
> If you've added a reference in the last round or two that actually explains this, I'll have a look.  Last time I did, there wasn't anything suitable, IIRC.

   [SAILER]   Sailer, R., Zhang, X., Jaeger, T., and L. van Doorn,
              "Design and Implementation of a TCG-based Integrity
              Measurement Architecture", Proceedings of the 13th USENIX
              Security Symposium, August 2004.


> I don't want to reverse-engineer an implementation, and I don't want to expose myself to the possibility of "taint" by looking into GPL'ed source.

There are well-understood ways to avoid IP taint in cases like this.

Reverse-engineering in this case would also not be difficult: it's
an HMAC signed by a private key. There are only so many ways that
can be done.

The more difficult aspect is constructing the logic that applies
policy to those hashes.


>> But I don't see that kind of analysis as pertinent to whether a file
>> system can store a blob of metadata. The questions you are asking are
>> related to whether you want to implement an appraiser on your non-
>> Linux system. I'm suggesting that's something that can and should
>> be decided independently.
> 
> I want to understand what is being proposed so that I can judge whether it is worth building structure around it.  I want to evaluate the proposal's security properties.  I want to be able to create and verify my own integrity assertions.
> 
> The simple version that I've roughly sketched permits that kind of analysis and deployment.

That's fine, but that's what you need to do to build an appraiser.
Just moving the IMA metadata around does not require that kind of
deep analysis.


>> > Is it using a private key in an HMAC?  If there’s validation of certificates involved, how are they described or registered?  What is the domain of these putative certifications?  Is it meaningful for an NFS server to receive an integrity assertion from one Linux machine and expect that assertion to be validated by a separate Linux machine?
>> 
>> > I know that Chuck doesn’t believe that an NFS server should be able to validate an integrity assertion.  I wonder why not.
>> 
>> That's a needlessly provocative mischaracterization.
> 
> I agree; I didn't mean it to be.  I should have forgone names and asked "Why not?"  Why is it not a valid exercise for an NFS server?

I've said only that it is optional. The document itself explains
that there are reasons why an NFS server might or might not imple-
ment appraisal, and provides examples of interoperation in both
cases.

Claiming that "it is not valid" is a misapprehension on your part.


> At the same time, the previous paragraph contains four questions, which you've ignored.  I wonder what the answers are.

I've repeatedly referred you to the cited documents to answer those
questions. The document itself has some explanation of those elements.
I don't feel the need to repeat all that again.


>> IMA does not trust data storage. The only really meaningful appraisal
>> is done at the time of content consumption. Any other appraisals are
>> just gravy.
> 
> OK, fine.  Some people like gravy.
>  
> 
>> Note that content consumption typically does not occur on servers --
>> certainly not on NetApp filers, for example -- and consumption
>> happens after control of the content has passed from the NFS client
>> implementation to the operating system. The file system is no longer
>> involved when appraisal actually occurs.
>> 
> I understand the current habit.  I want to know if there is a reason why it must be that way.

See the SAILER paper. That's how the architecture and the prototype
are designed: appraisal is separate from data storage. My sense is
that it must be this way because data storage is considered untrusted.


>> For IMA, NFS client and server implementations are simply links in the
>> chain between the content provider and content consumers. Validating an
>> integrity assertion on each link in that chain is OPTIONAL. The only
>> value added by the extra assertions is identifying at which link the
>> file content might have been corrupted.
> 
> This is one piece of value. 
> 
>> If you believe that it is the NFS server's job to avoid handing out
>> corrupted data, then your NFS server should perform appraisal before
>> it honors READ requests. That's a valid point of view. In the Linux
>> world, the NFS server does have an appraisal engine and policy that
>> is applied before data is served to NFS clients.
> 
> Kinda proves the point, no?

Which point? The proposal does not prevent server-side appraisal, but
neither does it fully define a mechanism to do it. I'm not sure what
you mean -- I think the document is actually agnostic on server-side
appraisal.


>> Eventually other NFS servers can have this too. Just not today, because
>> the Linux IMA appraisal metadata format is not yet standardized.
>> 
>> The NFS client implementation is not involved in appraisal either. This
>> is because the mechanism of appraisal is common to all file systems. It
>> would be foolish to have an appraisal mechanism in each file system
>> implementation, because they all do exactly the same thing.
> 
> You must be considering "all file systems" within a Linux box.  Clearly, my (e.g.) FreeBSD client isn't running the same code as your Linux box.

File system implementation - code that implements a particular on-disk
format

File system instance - an on-disk set of data laid out in a particular
recognized format

I'm saying that all file system implementations in an operating
system would share the same IMA appraiser module. Each operating
system would have its own implementation of an IMA appraiser.

Maybe we are agreeing here.


>> All I'm saying is that appraisal is separate from transporting and
>> storing IMA metadata. The question of whether a non-Linux system can
>> perform appraisal is valid, but orthogonal to whether IMA metadata can
>> get from point A to point B.
>> 
>> 
>> > The NFS wg may have previously allowed client-only attributes into the space of an NFS specification.  I don’t think that it’s right to do that here.  There are too many touch points for an integrity proof.
>> 
>> Again, I'm asking for just a narrow piece of the puzzle: transport. I
>> am not proposing a complete solution, because the transport is all
>> that is necessary for NFS, as a file storage system, to play in this
>> architecture. This is the case for every local file system.
> 
> And local file systems don't have to answer questions about whether metadata valid on one machine is valid also on another machine.  For instance, a particular UID value may mean something on machine X and mean something very different on machine Y.

UIDs are not involved. The example in the document shows HMACs signed
using private keys of global entities, not identities local to one
machine.

The architecture assumes that if an appraiser is to work, it needs
to have public keys that match private keys used to sign the HMACs.
Those public keys are supplied out of band. If they are not supplied,
then the appraiser cannot verify the signatures. Local policy
determines whether users are permitted to access a file's content in
that case.

[ at risk of being even more confusing, in a deployment of a single
air-gapped system, the public and private keys could be present there
and used for both signing HMACs and verifying them. That's not a
typical deployment scenario, however. ]

Does the document need to state explicitly that it assumes PK
infrastructure to manage these keys, perhaps?


> As far as I know, there is nothing suggesting that IMA's architecture doesn't share exactly the same kind of problem.  So that it would even be possible for one machine to evaluate an IMA block generated on another machine.

That's right: the matching public keys would be distributed to all the
systems that have appraisers. That's the same whether the IMA metadata
is stored in local file systems on each of those machines, or they all
mount the same NFS server that exposes IMA metadata.


> Or, for instance, whether the IMA architecture made similar implicit assumptions that IMA objects were not to be transported across some authentication domain boundaries, for example.

You've lost me here. Why would such an assumption be necessary? IMA
metadata is not private. If it needs to be private, it could be
encrypted as it is signed, I would think.

The only thing that the appraiser needs is a public key that matches
the signing key. Without that, it cannot verify the signature. I
suppose that lack of an appropriate public key might constitute an
authentication domain boundary.


> If NFS were to support Trip Wire or some other proprietary data
> integrity monitoring and appraisal system, would the nfsv4 WG have the
> same qualms about allocating a FATTR4 attribute for it?
> 
> Is Trip Wire a published mechanism for which answers to these kinds of questions were known? 

I'm asking what if the format was not public, but was widely used?

Is there some BCP or RFC somewhere that documents this restriction
against NFS supporting proprietary data formats in metadata?


--
Chuck Lever