Ceph authentication/authorization paradignms

Ceph authentication/authorization paradignms

[Christopher R. Hertel]

Ceph Folks:

Hi.  I am new to Ceph but I've been around in the Open Source world for a
while, working on a variety of different projects (mostly Windows Interop
stuff).  I was asked to take a look at the authentication mechanisms used in
Ceph, focusing on two key areas:

  * Calamari
  * Ceph client authentication to the Ceph cluster.

I am purposefully avoiding anything to do with the internal
service-to-service authentication/authorization system (that is, Cephx) for
two reasons.  The first is that Cephx is specifically designed for Ceph's
many-to-many environment, and the second is that it is sufficiently isolated
that I don't believe it needs to be modified to work with new external
authentication mechanisms.

Below is a quick overview of my thoughts on this topic.


Ceph and Calamari Authentication Expansion
==========================================

I'll keep this quick and simple.  It's a summary of what I've learned
and where I'm headed on this topic.

Adding LDAP Authentication to Calamari
--------------------------------------

  This should be easy, as the Django modules to do this already exist.  The
  trick will be creating accounts in Django and mapping those to existing
  LDAP accounts.  We can't just grant access to anyone who has a valid LDAP
  account, so access control would still be handled by Django and LDAP would
  be limited to authentication only.

  I just need to test this to see how the pieces fall together.

Adding Roles to Calamari
------------------------

  There was a discussion of setting up roles for Calamari, such that
  different roles would have different levels of control over the Ceph
  cluster.

  Django already supports the concept, in a variety of ways.  The first step
  here is to define sensible roles that will work within Django.  I have
  seen a couple of proposals.  The simplest one would be a ReadOnly role and
  a FullControl role.

Adding Kerberos and/or LDAP Auth for Ceph Clients
-------------------------------------------------

  I have set up a FreeIPA server so that I can have something to test
  against.  FreeIPA provides both LDAP and Kerberos authentication.

  There are different opinions regarding the priority of LDAP vs. Kerberos.
  I'll aim to get done first what I can get done first, and work from
  there.

  Right now, I have working LDAP authentication code using the simplest form
  of LDAP authentication.  My next step is to ensure that the authentication
  is encrypted.

  Note that the FreeIPA folks, who are keenly interested in helping us out
  on this project, are adising against trying to get LDAP auth working and
  recommend going directly to their tools.  I am still open to providing
  both mechanisms, assuming that LDAP auth can be made to work securely
  without too much end-user overhead.

FreeIPA and SSSD
----------------

  FreeIPA bundles LDAP and Kerberos support, and can integrate with Active
  Directory.  Also, the folks who work on it are friends and
  colleagues...folks I know fairly well.  They are interested in this
  project, and I want to better understand how integrating with FreeIPA can
  simplify authentication setup.  One key advantage of integrating with
  FreeIPA is that FreeIPA already handles a lot of gnasty compatibility,
  failover, and general complexity issues that people run into when trying
  to make use of existing authentication systems.

  SSSD is the client-side piece.  It maintains credentials in a secure
  fashion, so that users don't have to re-authenticate every time they
  connect to a new service (that uses the same authentication service).
  Integrating with SSSD is a longer-term goal.

Active Directory
----------------

  This is basically Kerberos or LDAP authentication, with some twists.
  Microsoft, for instance, believes in case-insensitivity.  Not so for
  standard Kerberos.  Once we have extended authentication working, we can
  address the specifics of AD.  Again, FreeIPA may help us solve some of
  this.

Chris -)-----

Re: Ceph authentication/authorization paradignms

[Gregory Farnum]

On Thu, Aug 14, 2014 at 10:10 AM, Christopher R. Hertel <crh@redhat.com> wrote:
> Ceph Folks:
>
> Hi.  I am new to Ceph but I've been around in the Open Source world for a
> while, working on a variety of different projects (mostly Windows Interop
> stuff).  I was asked to take a look at the authentication mechanisms used in
> Ceph, focusing on two key areas:
>
>   * Calamari
>   * Ceph client authentication to the Ceph cluster.
>
> I am purposefully avoiding anything to do with the internal
> service-to-service authentication/authorization system (that is, Cephx) for
> two reasons.  The first is that Cephx is specifically designed for Ceph's
> many-to-many environment, and the second is that it is sufficiently isolated
> that I don't believe it needs to be modified to work with new external
> authentication mechanisms.

I'm a little confused here. CephX is how clients authenticate to the
Ceph cluster...how are we going to add Kerberos auth or whatever
without getting involved in that?
Perhaps I'm misunderstanding the scope of what you're trying to do.
-Greg

Re: Ceph authentication/authorization paradignms

[Christopher R. Hertel]

[At end...]
----- Original Message -----
> From: "Gregory Farnum" <greg@inktank.com>
> To: "Christopher R. Hertel" <crh@redhat.com>
> Cc: ceph-devel@vger.kernel.org
> Sent: Tuesday, August 19, 2014 4:57:59 PM
> Subject: Re: Ceph authentication/authorization paradignms
> 
> On Thu, Aug 14, 2014 at 10:10 AM, Christopher R. Hertel <crh@redhat.com>
> wrote:
> > Ceph Folks:
> >
> > Hi.  I am new to Ceph but I've been around in the Open Source world for a
> > while, working on a variety of different projects (mostly Windows Interop
> > stuff).  I was asked to take a look at the authentication mechanisms used
> > in
> > Ceph, focusing on two key areas:
> >
> >   * Calamari
> >   * Ceph client authentication to the Ceph cluster.
> >
> > I am purposefully avoiding anything to do with the internal
> > service-to-service authentication/authorization system (that is, Cephx) for
> > two reasons.  The first is that Cephx is specifically designed for Ceph's
> > many-to-many environment, and the second is that it is sufficiently
> > isolated
> > that I don't believe it needs to be modified to work with new external
> > authentication mechanisms.
> 
> I'm a little confused here. CephX is how clients authenticate to the
> Ceph cluster...how are we going to add Kerberos auth or whatever
> without getting involved in that?
> Perhaps I'm misunderstanding the scope of what you're trying to do.
> -Greg
> 

CephX, as I understand it, is one of two mechanisms used to do two jobs.

The first job is to allow the client to log in to the cluster to access
cluster services (storage, basically).  The second is the message validation
that goes on between the various services within the cluster (MONitor, MDS,
OSD...).

The other auth mechanism that is used is, basically, none.  In a secure
environment, it's safe to let your clients connect to your cluster, and
your cluster components communicate, without any ongoing validation.

Anyway, the idea here is to perform the initial logon using Kerberos (or
LDAP), but then have CephX continue to handle the internal message validation.
That avoids any need for changing the deeper internals of Ceph, which is
particularly important because CephX is designed for the many-to-many Ceph
environment.

Chris -)-----

Re: Ceph authentication/authorization paradignms

[Gregory Farnum]

On Wed, Aug 20, 2014 at 3:20 PM, Christopher R. Hertel <crh@redhat.com> wrote:
> [At end...]
> ----- Original Message -----
>> From: "Gregory Farnum" <greg@inktank.com>
>> To: "Christopher R. Hertel" <crh@redhat.com>
>> Cc: ceph-devel@vger.kernel.org
>> Sent: Tuesday, August 19, 2014 4:57:59 PM
>> Subject: Re: Ceph authentication/authorization paradignms
>>
>> On Thu, Aug 14, 2014 at 10:10 AM, Christopher R. Hertel <crh@redhat.com>
>> wrote:
>> > Ceph Folks:
>> >
>> > Hi.  I am new to Ceph but I've been around in the Open Source world for a
>> > while, working on a variety of different projects (mostly Windows Interop
>> > stuff).  I was asked to take a look at the authentication mechanisms used
>> > in
>> > Ceph, focusing on two key areas:
>> >
>> >   * Calamari
>> >   * Ceph client authentication to the Ceph cluster.
>> >
>> > I am purposefully avoiding anything to do with the internal
>> > service-to-service authentication/authorization system (that is, Cephx) for
>> > two reasons.  The first is that Cephx is specifically designed for Ceph's
>> > many-to-many environment, and the second is that it is sufficiently
>> > isolated
>> > that I don't believe it needs to be modified to work with new external
>> > authentication mechanisms.
>>
>> I'm a little confused here. CephX is how clients authenticate to the
>> Ceph cluster...how are we going to add Kerberos auth or whatever
>> without getting involved in that?
>> Perhaps I'm misunderstanding the scope of what you're trying to do.
>> -Greg
>>
>
> CephX, as I understand it, is one of two mechanisms used to do two jobs.
>
> The first job is to allow the client to log in to the cluster to access
> cluster services (storage, basically).  The second is the message validation
> that goes on between the various services within the cluster (MONitor, MDS,
> OSD...).
>
> The other auth mechanism that is used is, basically, none.  In a secure
> environment, it's safe to let your clients connect to your cluster, and
> your cluster components communicate, without any ongoing validation.
>
> Anyway, the idea here is to perform the initial logon using Kerberos (or
> LDAP), but then have CephX continue to handle the internal message validation.
> That avoids any need for changing the deeper internals of Ceph, which is
> particularly important because CephX is designed for the many-to-many Ceph
> environment.

Right. But you'll either need to plug Kerberos into the client<->mon
authentication pathways, or (this would be my naive choice) have some
sort of agent that Kerberos authenticates and then gives the client
its CephX shared secret for authenticating with the monitors (without
the users having to get involved). Either way, there's at least a
little CephX integration going on, right?
Or am I completely off the mark with what you're trying to do here?

Re: Ceph authentication/authorization paradignms

[Sage Weil]

On Thu, 21 Aug 2014, Gregory Farnum wrote:
> On Wed, Aug 20, 2014 at 3:20 PM, Christopher R. Hertel <crh@redhat.com> wrote:
> > [At end...]
> > ----- Original Message -----
> >> From: "Gregory Farnum" <greg@inktank.com>
> >> To: "Christopher R. Hertel" <crh@redhat.com>
> >> Cc: ceph-devel@vger.kernel.org
> >> Sent: Tuesday, August 19, 2014 4:57:59 PM
> >> Subject: Re: Ceph authentication/authorization paradignms
> >>
> >> On Thu, Aug 14, 2014 at 10:10 AM, Christopher R. Hertel <crh@redhat.com>
> >> wrote:
> >> > Ceph Folks:
> >> >
> >> > Hi.  I am new to Ceph but I've been around in the Open Source world for a
> >> > while, working on a variety of different projects (mostly Windows Interop
> >> > stuff).  I was asked to take a look at the authentication mechanisms used
> >> > in
> >> > Ceph, focusing on two key areas:
> >> >
> >> >   * Calamari
> >> >   * Ceph client authentication to the Ceph cluster.
> >> >
> >> > I am purposefully avoiding anything to do with the internal
> >> > service-to-service authentication/authorization system (that is, Cephx) for
> >> > two reasons.  The first is that Cephx is specifically designed for Ceph's
> >> > many-to-many environment, and the second is that it is sufficiently
> >> > isolated
> >> > that I don't believe it needs to be modified to work with new external
> >> > authentication mechanisms.
> >>
> >> I'm a little confused here. CephX is how clients authenticate to the
> >> Ceph cluster...how are we going to add Kerberos auth or whatever
> >> without getting involved in that?
> >> Perhaps I'm misunderstanding the scope of what you're trying to do.
> >> -Greg
> >>
> >
> > CephX, as I understand it, is one of two mechanisms used to do two jobs.
> >
> > The first job is to allow the client to log in to the cluster to access
> > cluster services (storage, basically).  The second is the message validation
> > that goes on between the various services within the cluster (MONitor, MDS,
> > OSD...).
> >
> > The other auth mechanism that is used is, basically, none.  In a secure
> > environment, it's safe to let your clients connect to your cluster, and
> > your cluster components communicate, without any ongoing validation.
> >
> > Anyway, the idea here is to perform the initial logon using Kerberos (or
> > LDAP), but then have CephX continue to handle the internal message validation.
> > That avoids any need for changing the deeper internals of Ceph, which is
> > particularly important because CephX is designed for the many-to-many Ceph
> > environment.
> 
> Right. But you'll either need to plug Kerberos into the client<->mon
> authentication pathways, or (this would be my naive choice) have some
> sort of agent that Kerberos authenticates and then gives the client
> its CephX shared secret for authenticating with the monitors (without
> the users having to get involved). Either way, there's at least a
> little CephX integration going on, right?
> Or am I completely off the mark with what you're trying to do here?

My thought is the former.  We'd add a new CEPH_AUTH_* type, the client 
side would call into kerberos and get a kerberos ticket to pass to the 
mon, and the mon would call into kerberos to authenticate it.  That would 
authenticate the session.

I assume there will then be some futzing around to make things behave so 
that the mon will provide the client cephx tickets for interactions with 
the rest of the cluster so that *only* the mon is doing non-cephx 
authentication.  The focus now is just to make the first step work, 
though...

sage

Re: Ceph authentication/authorization paradignms

[Matt W. Benjamin]

This approach/family of approaches is certainly the one taken by all classical Kerberized file sharing systems, including AFS, DCE, and NFSv4.

There's a lot of new work just coming to fruition now in both the AFS and NFSv4 communities (rxgk and RPCSEC_GSS, respectively) that are specifically designed to handle important next-generation multi-party authorization scenarios, and which I think we would be wise to at least have a look at.

Regards,

Matt

> > 
> > Right. But you'll either need to plug Kerberos into the
> client<->mon
> > authentication pathways, or (this would be my naive choice) have
> some
> > sort of agent that Kerberos authenticates and then gives the client
> > its CephX shared secret for authenticating with the monitors
> (without
> > the users having to get involved). Either way, there's at least a
> > little CephX integration going on, right?
> > Or am I completely off the mark with what you're trying to do here?
> 
> My thought is the former.  We'd add a new CEPH_AUTH_* type, the client
> 
> side would call into kerberos and get a kerberos ticket to pass to the
> 
> mon, and the mon would call into kerberos to authenticate it.  That
> would 
> authenticate the session.
> 
> I assume there will then be some futzing around to make things behave
> so 
> that the mon will provide the client cephx tickets for interactions
> with 
> the rest of the cluster so that *only* the mon is doing non-cephx 
> authentication.  The focus now is just to make the first step work, 
> though...
> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309 

Re: Ceph authentication/authorization paradignms

[Matt W. Benjamin]

Sorry, s/RPCSEC_GSS/RPCSEC_GSSv3/.

----- "Matt W. Benjamin" <matt@linuxbox.com> wrote:

> This approach/family of approaches is certainly the one taken by all
> classical Kerberized file sharing systems, including AFS, DCE, and
> NFSv4.
> 
> There's a lot of new work just coming to fruition now in both the AFS
> and NFSv4 communities (rxgk and RPCSEC_GSS, respectively) that are
> specifically designed to handle important next-generation multi-party
> authorization scenarios, and which I think we would be wise to at
> least have a look at.
> 
> Regards,
> 
> Matt
> 
> > > 
> > > Right. But you'll either need to plug Kerberos into the
> > client<->mon
> > > authentication pathways, or (this would be my naive choice) have
> > some
> > > sort of agent that Kerberos authenticates and then gives the
> client
> > > its CephX shared secret for authenticating with the monitors
> > (without
> > > the users having to get involved). Either way, there's at least a
> > > little CephX integration going on, right?
> > > Or am I completely off the mark with what you're trying to do
> here?
> > 
> > My thought is the former.  We'd add a new CEPH_AUTH_* type, the
> client
> > 
> > side would call into kerberos and get a kerberos ticket to pass to
> the
> > 
> > mon, and the mon would call into kerberos to authenticate it.  That
> > would 
> > authenticate the session.
> > 
> > I assume there will then be some futzing around to make things
> behave
> > so 
> > that the mon will provide the client cephx tickets for interactions
> > with 
> > the rest of the cluster so that *only* the mon is doing non-cephx 
> > authentication.  The focus now is just to make the first step work,
> 
> > though...
> > 
> > sage
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> ceph-devel"
> > in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Matt Benjamin
> The Linux Box
> 206 South Fifth Ave. Suite 150
> Ann Arbor, MI  48104
> 
> http://linuxbox.com
> 
> tel.  734-761-4689 
> fax.  734-769-8938 
> cel.  734-216-5309 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309 

Re: Ceph authentication/authorization paradignms

[Christopher R. Hertel]

----- Original Message -----
> From: "Sage Weil" <sweil@redhat.com>
> To: "Gregory Farnum" <greg@inktank.com>
> Cc: "Christopher R. Hertel" <crh@redhat.com>, ceph-devel@vger.kernel.org
> Sent: Thursday, August 21, 2014 11:02:51 AM
> Subject: Re: Ceph authentication/authorization paradignms
> 
> On Thu, 21 Aug 2014, Gregory Farnum wrote:
> > On Wed, Aug 20, 2014 at 3:20 PM, Christopher R. Hertel <crh@redhat.com>
> > wrote:
> > > [At end...]
> > > ----- Original Message -----
> > >> From: "Gregory Farnum" <greg@inktank.com>
> > >> To: "Christopher R. Hertel" <crh@redhat.com>
> > >> Cc: ceph-devel@vger.kernel.org
> > >> Sent: Tuesday, August 19, 2014 4:57:59 PM
> > >> Subject: Re: Ceph authentication/authorization paradignms
> > >>
> > >> On Thu, Aug 14, 2014 at 10:10 AM, Christopher R. Hertel <crh@redhat.com>
> > >> wrote:
> > >> > Ceph Folks:
> > >> >
> > >> > Hi.  I am new to Ceph but I've been around in the Open Source world
> > >> > for a
> > >> > while, working on a variety of different projects (mostly Windows
> > >> > Interop
> > >> > stuff).  I was asked to take a look at the authentication mechanisms
> > >> > used
> > >> > in
> > >> > Ceph, focusing on two key areas:
> > >> >
> > >> >   * Calamari
> > >> >   * Ceph client authentication to the Ceph cluster.
> > >> >
> > >> > I am purposefully avoiding anything to do with the internal
> > >> > service-to-service authentication/authorization system (that is,
> > >> > Cephx) for
> > >> > two reasons.  The first is that Cephx is specifically designed for
> > >> > Ceph's
> > >> > many-to-many environment, and the second is that it is sufficiently
> > >> > isolated
> > >> > that I don't believe it needs to be modified to work with new external
> > >> > authentication mechanisms.
> > >>
> > >> I'm a little confused here. CephX is how clients authenticate to the
> > >> Ceph cluster...how are we going to add Kerberos auth or whatever
> > >> without getting involved in that?
> > >> Perhaps I'm misunderstanding the scope of what you're trying to do.
> > >> -Greg
> > >>
> > >
> > > CephX, as I understand it, is one of two mechanisms used to do two jobs.
> > >
> > > The first job is to allow the client to log in to the cluster to access
> > > cluster services (storage, basically).  The second is the message
> > > validation
> > > that goes on between the various services within the cluster (MONitor,
> > > MDS,
> > > OSD...).
> > >
> > > The other auth mechanism that is used is, basically, none.  In a secure
> > > environment, it's safe to let your clients connect to your cluster, and
> > > your cluster components communicate, without any ongoing validation.
> > >
> > > Anyway, the idea here is to perform the initial logon using Kerberos (or
> > > LDAP), but then have CephX continue to handle the internal message
> > > validation.
> > > That avoids any need for changing the deeper internals of Ceph, which is
> > > particularly important because CephX is designed for the many-to-many
> > > Ceph
> > > environment.
> > 
> > Right. But you'll either need to plug Kerberos into the client<->mon
> > authentication pathways, or (this would be my naive choice) have some
> > sort of agent that Kerberos authenticates and then gives the client
> > its CephX shared secret for authenticating with the monitors (without
> > the users having to get involved). Either way, there's at least a
> > little CephX integration going on, right?
> > Or am I completely off the mark with what you're trying to do here?
> 
> My thought is the former.  We'd add a new CEPH_AUTH_* type, the client
> side would call into kerberos and get a kerberos ticket to pass to the
> mon, and the mon would call into kerberos to authenticate it.  That would
> authenticate the session.

That seems to me to be the most logical approach, and it will also provide
the framework we would need to add other authentication mechanism if such
prove desirable.

> I assume there will then be some futzing around to make things behave so
> that the mon will provide the client cephx tickets for interactions with
> the rest of the cluster so that *only* the mon is doing non-cephx
> authentication.  The focus now is just to make the first step work,
> though...

Yep.  One advantage of that approach is that we won't have to worry about
re-authentication.  Once the initial authentication has been done (against
Kerberos) cephx takes over and the existing rules apply.

Chris -)-----

Re: Ceph authentication/authorization paradignms

[Christopher R. Hertel]

Matt:

Thanks for the pointers.  I'm currently knee-deep in traditional
Kerberos authentication code and trying to crack the FreeIPA PAM
API.

I'm a community-oriented developer.  Any deeper dive you can
provide would be encouraging.  :)

Chris -)-----

----- Original Message -----
From: "Matt W. Benjamin" <matt@linuxbox.com>
To: "Sage Weil" <sweil@redhat.com>
Cc: "Christopher R. Hertel" <crh@redhat.com>, ceph-devel@vger.kernel.org, "Gregory Farnum" <greg@inktank.com>
Sent: Thursday, August 21, 2014 11:43:02 AM
Subject: Re: Ceph authentication/authorization paradignms

This approach/family of approaches is certainly the one taken by all classical Kerberized file sharing systems, including AFS, DCE, and NFSv4.

There's a lot of new work just coming to fruition now in both the AFS and NFSv4 communities (rxgk and RPCSEC_GSS, respectively) that are specifically designed to handle important next-generation multi-party authorization scenarios, and which I think we would be wise to at least have a look at.

Regards,

Matt

> > 
> > Right. But you'll either need to plug Kerberos into the
> client<->mon
> > authentication pathways, or (this would be my naive choice) have
> some
> > sort of agent that Kerberos authenticates and then gives the client
> > its CephX shared secret for authenticating with the monitors
> (without
> > the users having to get involved). Either way, there's at least a
> > little CephX integration going on, right?
> > Or am I completely off the mark with what you're trying to do here?
> 
> My thought is the former.  We'd add a new CEPH_AUTH_* type, the client
> 
> side would call into kerberos and get a kerberos ticket to pass to the
> 
> mon, and the mon would call into kerberos to authenticate it.  That
> would 
> authenticate the session.
> 
> I assume there will then be some futzing around to make things behave
> so 
> that the mon will provide the client cephx tickets for interactions
> with 
> the rest of the cluster so that *only* the mon is doing non-cephx 
> authentication.  The focus now is just to make the first step work, 
> though...
> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309 

Re: Ceph authentication/authorization paradignms

[Matt W. Benjamin]

Hi Chris,

----- "Christopher R. Hertel" <crh@redhat.com> wrote:

> Matt:
> 
> Thanks for the pointers.  I'm currently knee-deep in traditional
> Kerberos authentication code and trying to crack the FreeIPA PAM
> API.
> 
> I'm a community-oriented developer.  Any deeper dive you can
> provide would be encouraging.  :)
> 
> Chris -)-----


The two efforts I am aware of are rxgk (OpenAFS) and RPCSEC_GSSv3 (NFSv4).

The older of the two efforts I believe is rxgk, and had dual goals of addressing the AFS "cache poisoning" problem, and secondarily introducing support for separately managed (file) servers.  I believe RPCSEC_GSSv3 was initially conceived (by Nico Williams) as a means of addressing the NFSv4 equivalent of the cache poisoning problem, but the current work on it (by Andy Adamson) is as a dependency of NFSv4.2 server-side copy.  (Apologies to the participants if I am mis-reporting any of the history.)

The IETF discussion of these efforts is on Kitten and NFSv4.  There's interesting recent discussion on the Kitten WG alias.

Pointers:

http://www.ietf.org/internet-drafts/draft-wilkinson-afs3-rxgk-afs-06.txt
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3

-- 
Matt Benjamin
CohortFS, LLC.
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://cohortfs.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309