Subject: [nfsv4] [LNFS] Discussion items for the next meeting

From: Thomas Haynes <[email-masked]>
Date: Fri, 22 Apr 2011 17:06:26 -0500

1) One of the agenda items I'd like to discuss next week is
how the server is going to notify the client that there
has been an object label change.

If the client does not have a file opened, then the server
is not responsible for notifying the client. The client
might have its hands on the label, say via a READDIR,
but the client should be able to handle this like
any other stale attribute.

If the client does have a file opened, then if the object
label changes, the server needs to inform the client
that a change has occurred.

A question I have is how often does an object label change?

If it is not often (as I suspect) then we should be able to
simply use the CB support to inform the client.

Nico has a second proposal, which involves volatile FHs,
but I have a concern that not enough implementations
have VFH support.

2) The second item I want to discuss is how does LNFS
work with pNFS?

I view the object label as being metadata and argue it
can only be checked by the MDS. We have precedent in that
to check whether a client has either access rights or
permissions to a file, the DS is responsible for validating
the stateid with the MDS. So along with sending the
fh and stateid to the MDS, the DS could also send the
subject label.

Note that if a default label needs to be constructed, the
security systems on each DS SHOULD have the same
heuristics as the MDS.

Nico also has a different proposal, again involving
VFHs. I'll leave it to him to bring it up.

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Apr 2011 17:52:36 -0500

> but I have a concern that not enough implementations

My proposal isn't quite volatile FHs.  It is superficially similar,
but NOT the same.  Specifically, in my proposal there's no "re-open by
path", nor any re-open at all -- that is, none of what makes volatile
FHs painful applies to my proposal.

The only thing in common between volatile FHs and my proposal is the
fact that the client has to recover from an FH becoming stale.  Not
even the actual error code need be the same as in volatile FHs, though
keeping it the same helps.

My proposal is to have a very simple recovery: the client asks the
server to give it a new FH that is semantically equivalent to the old
one in every way except for: it's not stale.  The server can say no,
if MAC policy by then prohibits the client/user from accessing that
file in that way.

This _does_ imply a cryptographic capability being embedded in the FH.
 We could make the capability explicit, and the FH would stay the same
as it ever was.  I'd be happy either way.

So, to summarize, I propose either:

a) an implicit cryptographic capability buried in the FH, with a
single new operation to refresh stale FHs,

or

b) an explicit cryptographic capability (still with server-defined
format) and a PUTCAPABILITY/GETCAPABILITY pair of operations (to match
PUTFH/GETFH).

Pretty simple.  Also: not Earth shaking.  Folks, cryptographic
capabilities in filesystems are nothing new, much less scary.  PLEASE
do not confuse any of this with volatile FHs any longer as that does
you and the WG a tremendous disservice (since you might then ignore an
obviously good solution for want of avoiding an unrelated
non-solution).

> fh and stateid to the MDS, the DS could also send the

This is very, very, very much related to (1).  It is NOT separate.  A
cryptographic capability approach solves (2), though the MDS still has
to talk to the DSes to tell them about revoked capabilities.  Of
course, we don't want to store copies of ACLs on DSes because that's a
pain, but doing that for labels may be sufficiently easier that we
wouldn't mind that -- something to consider.

> security systems on each DS SHOULD have the same

If you use capabilities + revocation only then the DSes don't need to
know jack about the LFS nor DOIs.  Of course, as long as DS
implementations are closely tied to MDS implementations because of
matters left specifically unspecified, then this is a minor advantage.
 But I'm certain that some implementors will want to be able to pursue
a capability-based approach, probably all of them will.

> VFHs. I'll leave it to him to bring it up.

Arghhhhh. Please don't ever say it involves VFHs again, I beg, I beg!
:)  (It really doesn't...)

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 22 Apr 2011 18:27:41 -0500

> keeping it the same helps.

Nico,

I don't understand why the FH has to become stale. Does the
fact that the object label has changed make this stale?

Also, what issues if any are there if the server reboots and
a client presents one of your FHs?

> This _does_ imply a cryptographic capability being embedded in the FH.

I really do not want to be in the business of dictating the format
of the FH to the servers. How much space is needed by this capability?

> format) and a PUTCAPABILITY/GETCAPABILITY pair of operations (to match

I'm assuming that the client would do a GETCAPABILITY with the MDS and
then present it to the DS with a PUTCAPABILITY?

If implicit capabilities can be built by the server (remember that the
FH is opaque and the client cannot use it) and explicit capabilities
are not passed around in the FH, why can we not have implicit
capabilities which are not passed in the FH?

Or in other words, the MDS creates an implicit capability. It has
a tuple of <client, FH, stateid, capability>. If the DS wants to know
the capability, it can query the MDS by passing in the <client, FH, stateid>.

Also, in this case, there is no cost to encrypt the capabilities.

> capabilities in filesystems are nothing new, much less scary.  

This is not my issue. Quite simply, we already have a working
approach to solve the second item for DAC and it is easy enough to
extend for MAC. As for the first item, it also falls into well understood
approaches we've already solved.

A tangent is whether there are other uses for capabilities?

And please provide a good reference on capabilities.

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Apr 2011 19:50:59 -0500

> fact that the object label has changed make this stale?

My proposal is for cryptographic capabilities, either embedded in the FH or
explicit.

When the label changes, which is to say: when access is *revoked* (this is
key, see below), the access capability (token, if it helps you) becomes
stale or otherwise no longer capable of granting access.

> a client presents one of your FHs?

Implementation-specific.  Quite possibly none (that is, you can easily make
it none).

> of the FH to the servers. How much space is needed by this capability?

The format wouldn't get dictated.  See Spencer's earlier reply to you on
this matter.

> then present it to the DS with a PUTCAPABILITY?

Correct!  Though the client also could use the capabilities at the MDS.

> capabilities which are not passed in the FH?

The client *never* interprets the contents of FHs, and I do not propose
changing this, nor do I imply it.  Explicit capabilities by definition are
not _in_ the FH (I hadn't said that, er, explicitly, but I thought it'd be
clear that an explicit capability is not embedded in an FH but used in
parallel PUTCAPABILITY ops).

> the capability, it can query the MDS by passing in the <client, FH,
stateid>.

No stateid, none, no, never, no, categorically no :)  Not in the
capability.  In the post where I described a possible implementation choice
I had no stateid in there, and never did I even imply that one should put
one there.

> Also, in this case, there is no cost to encrypt the capabilities.

I don't follow.

> approaches we've already solved.

You don't have revocation in the DAC case because POSIX semantics have an
anti-requirement regarding revocation.  MAC is different in this respect.
If there's no need for revocation then there's no need for refreshing
capabilities.  This be the crux of the matter.

> A tangent is whether there are other uses for capabilities?

Quite.  It's how pNFS should have worked from the word go.  But no one
listened or noticed when I proposed it back then.  Or maybe capabilities
make no sense or introduce undesirable complexity, but at least now we will
have a good debate on this.

> And please provide a good reference on capabilities.

Later.  I'm posting from my phone... :)  A search for "cryptographic
capabity filesystem", ignoring uses of the word capability in the sense of
"ability", yields results.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 24 Apr 2011 21:56:25 -0500

> "ability", yields results.

As promised...

Searching for comp. sci. authors famous in the 80s finds various
things.  For example, a search for "capability tanenbaum" finds things
like:

Tanenbaum, Mullender, and van Renesse, Using Sparse Capabilities in a
Distributed Operating System.
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBUQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.56.3350%26rep%3Drep1%26type%3Dpdf&rct=j&q=capability%20tanenbaum&ei=4Nq0TYXsKoKctwelkZTqDg&usg=AFQjCNGElWWOLzOgE4bO38qlnxM5g0KH8A&cad=rja

Tanenbaum and Mullender, The Design of a Capability-Based Distributed
Operating System. 1986
http://comjnl.oxfordjournals.org/content/29/4/289.abstract

There's much more in that vein.

A search for '"cryptographic capability" (but note that capabilities
need not be cryptographic, as explained below) distributed filesystem'
turns up quite a few much more recent papers on the subject:

Gobioff, Gibson, and Tygar. Security for network attached storage devices
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.123.5060

Gobioff, H.B., Security for a High Performance Commodity
Storage Subsystem. 1999, Carnegie Mellon University.
http://www.pdl.cmu.edu/PDL-FTP/NASD/hbg_thesis.pdf

Leung, A.W. and E.L. Miller. Scalable security for large,
high performance storage systems ACM Workshop on
Storage Security and Survivability. 2006

Sivathanu and Zaki, Flexible Security for theWiND Filesystem.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.131.5991&rep=rep1&type=pdf

Also, there's the Tahoe Least Authority Filesystem:

http://tahoe-lafs.org/~zooko/lafs.pdf
http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem
http://sourceforge.net/projects/tahoelafs/

If you spend enough time researching this I think you'll find that the
subject goes back to at least the  early 80s, and probably earlier.
There's two distinct veins, roughly:

  - Operating system capabilities (NOT to be confused with what Linux
very, very, very annoyingly calls "capabilities").  Here 'capability'
refers to a kind of token the possession of which (in the virtual
memory address space of a process, say) indicates that the subject has
access to some resource.  For example, in Unix a file descriptor is a
simplistic sort of capability, simplistic because it's just an index
into a kernel-mode table, as compared with a cryptographic capability
as used in other systems.

 - Distributed operating system capabilities -- the same concept as in
operating system capabilities, really, and, indeed, an outgrowth of OS
capabilities as applied to distributed operating systems.  Filesystems
are just a related subject -- the primary sub-subject of distributed
operating systems that has made the big-time.

In a capability system we have subjects, objects, authorities (issuers
of capabilities), relying parties, and capabilities (I'm simplifying
and using terminology more likely to be recognized in our context).  A
capability is a token, an octet blob, whose purpose is to indicate to
relying parties that the subject presenting it has access to some
object or objects, and which is issued by an authority.  Here, in
pNFS, the relying parties are the data servers, the authorities are
the meta-data servers, and the subjects are the clients.

A capability has to be protected from spoofing or guessing by
subjects.  There are several methods of accomplishing this, not all of
them requiring the use of cryptography.

Note that my proposal (either variant, with capabilities embedded in
FHs or as separate from FHs) does NOT dictate whether capabilities are
cryptographic, pre-shared (via a private MDS->DS channel), or to be
validated (via a private DS->MDS channel).  It was only my own
preference for the use of crypto here that led me to use crypto in an
earlier example.

Nor does my proposal dictate the format of FHs.

As for the FH/capability refresh/renew operation in my proposal, it is
desirable for a number of reasons, such as to support revocation, to
support key rollover (if the capabilities are cryptographically
protected), and probably other reasons.

The current pNFS protocol does support capabilities, just not
cryptographic ones, but ones validated or pre-shared via private
MDS<->DS protocols.  All that's missing is a capability refresh
operation, then cryptographic capabilities will be feasible.  pNFS
requires or allows for various unspecified (therefore
non-interoperable) MDS<->DS protocols, and I imagine that some
implementors might want to use cryptographic capabilities, as those
might well, for them, have desirable benefits over the alternatives,
but they may not for the necessary refresh operation is missing from
the protocol.  Is there _any_ good technical reason not to include
such an operation in 4.2??

Cheers,

Nico
--

---

From: Jim Rees <[email-masked]>
Date: Mon, 25 Apr 2011 07:52:47 -0400

Nico Williams wrote:

I worked on one such system at the University of Washington in the early
1980s, the Eden system:

http://portal.acm.org/citation.cfm?id=800216.806603

They were quite fashionable at the time.

---

From: Cary Gray <[email-masked]>
Date: Mon, 25 Apr 2011 13:13:19 +0000

The classic definition of "capability" should be found in any decent first-semester OS textbook, in the context of slicing the authorization matrix into either access control lists or capability lists.  The classic reference is

Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE 63,9 (September 1975), 1278-1308.

If you want something more recent, see chapter 11 of Saltzer and Kaashoek's _Principles of Computer System Design_, Morgan Kaufmann, 2009.  Actually, ch 11 is in the online supplement, which can be found at
  http://ocw.mit.edu/Saltzer-Kaashoek

(The idea and vocabulary pre-date the paper; in the early 70s there were a number of efforts at treating hardware addresses as capabilities.)

Cary

On Apr 24, 2011, at 9:56 PM, Nico Williams wrote:

On Fri, Apr 22, 2011 at 7:50 PM, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:
On Apr 22, 2011 7:27 PM, "Thomas Haynes" <[email-masked]<mailto:[email-masked]>> wrote:
And please provide a good reference on capabilities.

Later.  I'm posting from my phone... :)  A search for "cryptographic
capabity filesystem", ignoring uses of the word capability in the sense of
"ability", yields results.
... later references elided.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Apr 2011 11:23:10 -0500

On Mon, Apr 25, 2011 at 8:13 AM, Cary Gray <[email-masked]> wrote:
> The classic definition of "capability" should be found in any decent
> first-semester OS textbook, in the context of slicing the authorization
> matrix into either access control lists or capability lists.  The classic
> reference is

Yes, that's what I had in mind.  But I couldn't find the relevant
textbook (it's been a while!).

Thanks to you and Jim Rees for the additional references.  I dare say
we have more than enough for the WG to properly consider an option for
capabilities.  The key trade-off to make regarding
non-capability-based approaches is a {latency and/or complexity of
MDS<->DS comms} versus {crypto complexity and MDS<->DS comms to handle
keying}.  Given how much of MDS<->DS communications is left to
implementors, I think NFSv4.2 ought to give implementors the option of
using capabilities.

> (The idea and vocabulary pre-date the paper; in the early 70s there were a
> number of efforts at treating hardware addresses as capabilities.)

I thought as much, but I didn't put enough effort into my research to
reach that far back :)  Thanks!

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 25 Apr 2011 12:36:04 -0500

On Apr 22, 2011, at 7:50 PM, Nico Williams wrote:

> Implementation-specific.  Quite possibly none (that is, you can easily make it none).
> 

Currently, it is well understood what the server needs to do if presented
with either a persistent or variable FH. I'd hate to lose that property.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Apr 2011 12:44:51 -0500

> with either a persistent or variable FH. I'd hate to lose that property.

Clearly it'd be in the server's implementor's interest to make it so
that clients can trivially recover from server reboots, either because
the capabilities just work or because the client can refresh them
without issue.

Clearly, too, it should be quite easy for implementors to achieve
this, since it's just a matter of constructing capabilities such that
they can be used across reboots, which, in the case of cryptographic
capabilities, only requires retaining the relevant cryptographic key
material in persistent storage.  (Whereas for non-cryptographic
capabilities there'd be much more material to store persistently,
which would not be realistic, thus you see one major benefit of
applying cryptography here.)

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 25 Apr 2011 12:50:32 -0500

On Apr 25, 2011, at 11:23 AM, Nico Williams wrote:

> capabilities.  

I don't have an issue with us considering adding capabilities. But I'd rather
we have an I-D that provides that motivation.

I'm not convinced that adding it as a specific solution in this context is
a sufficient scoping of all of the issues we would encounter.

> The key trade-off to make regarding

Nothing prevents an implementation from using capabilities in MDS<->DS
communication.

Nothing prevents an implementation from embedding capabilities into
a volatile FH (in full acknowledgement that this different from what you
propose) and using that framework to handle revoking a client access.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Apr 2011 14:17:11 -0500

> we have an I-D that provides that motivation.

I'm a volunteer.  The WG is already getting free labor from me in the
form of RPCSEC_GSSv3.  What I proposed regarding capabilities is so
bloody trivial that publishing an I-D just to get text folded into 4.2
would be overkill.  The most I'll do is furnish some text for you to
edit into 4.2.  If the WG doesn't like that, then forget it, and so
will I.

> a sufficient scoping of all of the issues we would encounter.

I'm not trying to convince _you_.  On Thursday we'll see if I can
convince the participants I'm aiming to convince.  If not, well, that
will mean less volunteer work for me to do.

> Nothing prevents an implementation from using capabilities in MDS<->DS

How many times must I explain why there is something missing from the
protocol regarding capabilities?  That something missing is: an
operation to refresh capabilities based on something other than
rebuilding open file state by path (i.e., something other than
volatile FHs).

> propose) and using that framework to handle revoking a client access.

VFH is a disaster that exists only to cope with filesystems that don't
index filesystem objects by anything other than name (i.e.,
filesystems that lack anything remotely like an inode number).  No
server implementor should be happy to use VFHs to approximate
capabilities.  You know this, and IIRC you've said as much at some
point in one of these threads (no, I won't go find a quote because
there's too much chaff to wade through just to find it and life is
just too short).

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 25 Apr 2011 14:33:20 -0500

On Apr 22, 2011, at 7:50 PM, Nico Williams wrote:

> My proposal is for cryptographic capabilities, either embedded in the FH or explicit.
> 
> When the label changes, which is to say: when access is *revoked* (this is key, see below), the access capability (token, if it helps you) becomes stale or otherwise no longer capable of granting access.
> 
> The format wouldn't get dictated.  See Spencer's earlier reply to you on this matter.
> 
> 

If you add capabilities to a FH for LNFS, then you are dictating that FHs have
capabilities. You may not be dictating where in the FH, but it is a requirement
that they have them present.

Implementations might have existing limits to how much information that they
can embed in a FH. Adding capabilities might bump them over that limit.

Another issue is that when LNFS is enabled on a server, it might have
clients accessing files with the old filehandles. How does the server
detect a client presenting the old filehandles? 

By the way, what happens if a filesystem is migrated? Is there a requirement
that the FHs are still honored?

Is there also a restriction about whether or not we can migrate a filesystem
from a LNFS aware server to a non-LNFS aware server?

A key concern I have here is not the addition of capabilities, but why we need
to expose them to the client, whether implicitly across the FH or explicitly
with the new ops. A new mechanism is being proposed for the flow of
information between the MDS and DS and I don't see sufficient rational
for why we should abandon the old method.

If the capabilities are stored on the MDS, then we avoid a host of issues
(i.e., the questions I have raised about how this new FH type survives
reboot, migration, etc).

> The client *never* interprets the contents of FHs, and I do not propose changing this, nor do I imply it.  Explicit capabilities by definition are not _in_ the FH (I hadn't said that, er, explicitly, but I thought it'd be clear that an explicit capability is not embedded in an FH but used in parallel PUTCAPABILITY ops).
> 
> 

The issue isn't whether or not the client interprets the contents of
the FH, but rather whether the capabilities ever need to be presented
to the client to pass from the MDS to the DS?

> No stateid, none, no, never, no, categorically no :)  Not in the capability.  In the post where I described a possible implementation choice I had no stateid in there, and never did I even imply that one should put one there.
> 
> 

This is something completely different than your possible implementation
choice and not embedded in the filehandle. In your proposal, the stateid
is being explicitly carried by the READ or WRITE ops that are going to
the DS.

What I am trying to do is restate the discussion in 13.11 of RFC 5661:

   Fencing works as follows.  As described in Section 13.1, in COMPOUND
   procedure requests to the data server, the data filehandle provided
   by the PUTFH operation and the stateid in the READ or WRITE operation
   are used to ensure that the client has a valid layout for the I/O
   being performed; if it does not, the I/O is rejected with
   NFS4ERR_PNFS_NO_LAYOUT.  The server can simply check the stateid and,
   additionally, make the data filehandle stale if the layout specified
   a data filehandle that is different from the metadata server's
   filehandle for the file (see the nfl_fh_list description in
   Section 13.3).

In order to validate a client's requests, we need to know the client,
the FH, and the stateid. Given those three pieces of information, we
can uniquely identify the capabilities assigned to a client for a file.

But really, this is exactly my proposal. The DS sees a request from
the client. It already has to query the MDS for the following:

1) A valid layout
2) DAC permissions
3) Export level access

At this point, it could also query for MAC permissions.

> > Also, in this case, there is no cost to encrypt the capabilities.

If the MDS and DS are communicating directly, then capabilities
do not need to be sent on the wire. Either an index will suffice or
the subject label can be transmitted. Therefore you remove the
cost to encrypt.

> You don't have revocation in the DAC case because POSIX semantics have an anti-requirement regarding revocation.  MAC is different in this respect.  If there's no need for revocation then there's no need for refreshing capabilities.  This be the crux of the matter.
> 
> 

But you do have revocation either because the export policy changed
on the MDS or the MDS fenced the client off.  See above.

> Quite.  It's how pNFS should have worked from the word go.  But no one listened or noticed when I proposed it back then.  Or maybe capabilities make no sense or introduce undesirable complexity, but at least now we will have a good debate on this.
> 
>

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 25 Apr 2011 18:38:02 -0500

On Apr 25, 2011, at 2:51 PM, Nico Williams wrote:

> On Mon, Apr 25, 2011 at 2:33 PM, Thomas Haynes <[email-masked]> wrote:
> Your continuing failure to understand relatively simple matters, and
> your willingness to subsequently make wild assertions based on your
> misunderstandings, in this thread is nothing short of astounding.

You've pulled out part of what I replied and left off the key point.

While the NFSv4.x specification does not cap the length of a file
handle, some server implementations might do so. What I pointed
out was the requirements to add an unbounded (in so far as I
have seen no proposal to limit the size) capability to the FH
might cause it to become too large.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Apr 2011 14:51:21 -0500

Your continuing failure to understand relatively simple matters, and
your willingness to subsequently make wild assertions based on your
misunderstandings, in this thread is nothing short of astounding.  If
you were trying to find the point at which my patience runs out, well,
congratulations, you have found it.  I don't understand what led you
to make the above assertion, but you've misunderstood so much that I
won't try to understand why.  Others will have to tell me if the
problem lies in my being unable to communicate clearly -- if the fault
lies with me then I might be unable to realize that myself, in which
case consider this a preemptive apology from me.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 25 Apr 2011 18:54:06 -0500

On Apr 25, 2011, at 2:17 PM, Nico Williams wrote:

> form of RPCSEC_GSSv3.

I'm not asking that you be the author. I'll do it if it turns out we need the
new feature.

What I was trying to drive towards is that even though the concept might
be easy to understand, there are plenty of open issues with regards to
deploying them in terms of the protocol.  What I am asking for here is that
we scope out those ramifications before we commit to doing capabilities.

>  What I proposed regarding capabilities is so

The issues at hand are:

1) A DS verifying that a client has an appropriate subject label to access the
object label of the file being accessed.

2) If a server modifies the object label for a file that a client has open, then
the server needs to communicate that back to the client.

Both of these issues can be solved without adding capabilities.

Why then should we add capabilities? Why should we add complexity
when a simpler approach, which extends what we currently do, solves
the problem?

> rebuilding open file state by path (i.e., something other than

You have misunderstood my proposal here, which has nothing to do with
the NFSv4.x protocol and everything to do with the Control Protocol. And
that is totally undefined by the WG.

What I did present here was an approach by which the MDS and DS could
share capabilities without any modifications to the protocol.

Let me ask the question again, if the MDS knows the capabilities for 
a client to access an open file, why does the MDS have to communicate that
back to the client such that the client can then communicate those
capabilities to the DS?

Cannot the MDS and DS cut out the middle man?

If the capabilities are cryptographically secured, how is the client anything
but a middle man in this scenario?

> there's too much chaff to wade through just to find it and life is

With the current definitions of persistent versus volatile FH, the approach
of embedding capabilities falls under the definition of a volatile FH (see
section 4.2.2 and 4.2.3 of RFC 5661).

We would have to add a new enumerated value, probably FH4_VOL_MAC_CHANGE.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Apr 2011 19:52:10 -0500

> might cause it to become too large.

You continue to make misrepresentations.  Rather than take the time to
understand, you jump to conclusions.  How do you reach the conclusion
that capabilities are unbounded in size?  If they necessarily had to
so be then they'd have failed as an idea in Computer Science not long
after being first conceived of.  This subject goes back to the 70s.
Cryptographic capabilities go back at least to the late 80s.

Nor ahouls anything I wrote here have led you to think that
capabilities must be unbounded in size.

As I've explained more than once by now, nothing that I've proposed
implies or forces any particular FH or capability
format/layout/contents.  Nothing.  You don't show how anything I wrote
might so imply; you simply assert that what I've written so implies.
I do not appreciate argument by assertion.

And because pNFS leaves MDS<->DS protocols unspecified, it would be
inappropriate for me to try to specify what the format of an FH or
capability ought to be.  I can only discuss possible implementation
choices so as to demonstrate that the protocol changes are workable.
Indeed, I had an example, and nothing in that example should have led
you to conclude that capabilities are of unbounded size.

Let's make a few things super-clear.  First, capabilities would be
optional.  Second, capabilities need not add that much to the length
of an FH: a key version number and a MAC, if using group key sharing,
or a key version number and a small-ish elliptic curve crypto
signature; the key version number could be a single bytes, and the MAC
could be truncated to 64- or 96-bits -- hardly Earth shaking stuff
here.  An implementor might want to add more information.  And we
might need a way to allow implementors to be able to issue
per-{client, user} capabilities as well (to prevent sharing without
having the MDS make access control decisions), in which case
capabilities would _sign_, and _possibly_ bear the names of the client
and user, but this is most certainly bounded if just signed, and
hardly unbounded if carried, not just signed in the capability.
Third, there are a lot of _implementation_ choices here, most, if not
all reasonable such choices resulting in BOUNDED additions to the
length of the FH (or external capability).

Nico
--