Subject: Re: [nfsv4] Updated: checksum extensions I-D

From: [email-masked]
Date: Tue, 16 May 2006 12:08:16 -0400 (EDT)

> And the "Introduction" section of the I-D accepts that
> right? -
> 
>     The standard NFS protocol (without Kerberos) has historically relied
>     on the underlying transport for data integrity and it itself does not
>     make an attempt to ensure data integrity.  Kerberised NFS provides
>     data integrity via the use of krb5i.
> 
> Really, the use case we're considering is protection in
> the absense of RPCSEC_GSS, and absense of RPCSEC_GSS because
> security mechanisms like Kerberos are hard to configure.

I think there are two different questions here.
1 - Is RPCSEC_GSS with Integrity sufficient or is some other checksumming
    required when this is in use?
2 - When krb5i isn't usable (due to site configuration, ...) is it better
    to solve that problem with a different RPCSEC_GSS Mechanism or to
    introduce a non-RPCSEC_GSS checksumming technique?

Just my $0.00 worth, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Alok Aggarwal <[email-masked]>
Date: Tue, 16 May 2006 11:06:59 -0600 (MDT)

> I think there are two different questions here.

Thank you for focussing the discussion, Rick.

>    required when this is in use?

As Nico reminded me as well, the current krb5i protection
via the RPCSEC_GSS mechanism doesn't ensure end-to-end
integrity.

So, a different mechanism with some of the following
characteristics is what's desired -

. Should enable end-to-end integrity where the client
   application generated checksums are transmitted all
   the way to server media (with appropriate checksum
   verification at various points).

. Should provide integrity protection without the need
   to setup, say Kerberos for example.

The question becomes what should this mechanism be. Should
it be this proposal to start with and be enhanced as we go on?
Or, should it rather be a different RPCSEC_GSS mechanism to 
accomplish the same thing?

Again, I should mention the above in the I-D.

>    introduce a non-RPCSEC_GSS checksumming technique?

Yep, that's the question provided it fulfills the above
criteria.

Alok

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 May 2006 12:27:14 -0500

>   verification at various points).

It hasn't been established that this is indeed desirable.  The argument
has been made, and I'm willing to believe that CPU/memory errors are
enough of a problem in some environments, but if you want to convince
others it looks like data would help.

> accomplish the same thing?

RPCSEC_GSS can't provide application<->storage end-to-end integrity
protection -- it can only provide client<->server end-to-end integrity
(if we're going to talk about end-to-end anything we should clarify what
the ends are or should be).

Also, let's be careful with terminology.  The proposal on the table
doesn't provide integrity protection in the security sense.  It does
provided application<->storage end-to-end file contents error detection.
The moment we start talking about this vs. RPCSEC_GSS the terminology
we use becomes a problem.

Mind you, I think application<->storage end-to-end cryptographic
(integrity and/or confidentiality) protection can be very useful -- in a
threat model where the attacker has the run of the server/storage.  But
that's not what you're proposing.

And in any case, there's the metadata issue; I don't know what to do
about that, other than possibly giving up on that (but then I've not
thought about the problem enough).

Nico
--