Subject: RE: Gss Context and sequence window

From: "Corbett, Peter" <[email-masked]>
Date: Wed, 30 Oct 2002 12:41:08 -0800

wait a minute.
that makes perfect sense, but it's not what the rfc says.  in fact, the rfc
says that it is illegal to specify the qop during the connect phase, and
that the qop can only be specified on data rpcs, and must be specified on
each data rpc.  It is definitely implied, if not explicitly stated, that the
client can change it on each rpc, and that the server must check anew.

I had a problem with this because, while sun was specifying qop on
rpcsec_gss connect ops, hummingbird was not, in accordance with the spec.
So, I had to change code to pick qop out of the data requests, and check the
qop against the allowed values for the export on each such request.

looks like a good candidate to include in a revised rfc.  Mike?
One possibility would be to allow qop and service to be specified in the
connect interaction, and if so specified, not allow any data request to use
a lower qop or service combination on any data request.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2002 3:29 PM
To: William A.(Andy) Adamson; [email-masked]
Subject: Re: Gss Context and sequence window

One other thing ... the RPCSEC_GSS context, once created, is typically
"locked down" by the server so that the client can't substitute a weaker
service (authentication, integrity) or quality of protection (QOP) for an
exported hierarchy that requires stronger QOPs or services. This was done in
the Solaris server to minimize the costs of checking this stuff on each NFS
access. So the client should not assume that it can vary the service and qop
for a created rpcsec_gss context.

	-mre
 
Mike Eisler wrote:
> 
> "William A.(Andy) Adamson" wrote:
> >
> > Is the GSS context negotiated for a user on one mount 
> > point/communication channel supposed to be shared with all other 
> > mount points/communication channels for that user on that server? 
> > The question at issue is whether or not it is possible to have 
> > multiple contexts for a given user against a given server in order 
> > to avoid having a global serialization w.r.t. the sequence number.
> >
> > Cheers,
> >   Andy, Bruce, Trond
> 
> The client can do whatever makes sense for it. The server, especially 
> an NFSv4 server needs to be able to accept the context through all 
> exported directories. It also must accept multiple contexts from the 
> same user. This is critical for performance; most client do read ahead 
> and write behind and in the case of the Solaris client, 8-9 contexts 
> per user/mount pair get created.
> 
> (As an implementation aside, if you are using the MIT krb5 code, 
> you'll note that its context creation path is not re-entrant ... 
> simulataneus context creations are likely to crash. So you'll need to 
> serialize context creation or make the code re-entrant).
> 
> It is indeed possible and expect for a given user to have lots of 
> contexts against a given server.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Wed, 30 Oct 2002 15:50:54 -0500

wait a minute indeed! insisting that the user (client) create a new context 
(or 8-9 new contexts !!!) per mount point because the server does't bookeep in 
a sensible manner is silly. the gss context is designed to be used for 
multiple qop/service combinations.

it makes more sense to use the same context, and allow multiple sequence 
number streams than to require multilple (expensive to obtain) contexts to be 
created.

-->Andy

---

From: Mike Eisler <[email-masked]>
Date: Wed, 30 Oct 2002 12:53:55 -0800

> client can change it on each rpc, and that the server must check anew.

sure, in general, rpcsec_gss clients can do that. however
there's nothing that says a given RPC service can't limit the
flexibility.

> qop against the allowed values for the export on each such request.

right, and since the qop/service on exported directory typically
doesn't change often, locking the context down makes sense.

The Solaris server does the lock down on the first post RPCSEC_GSS
initialization request it gets so there's no need to inspect the
initialization time parameters.

> a lower qop or service combination on any data request.

I'm only telling v4 client implementors what they can expect. 

I don't think we need to revise the RPCSEC_GSS specification, but
might want to clarify the nfsv4 specification down the road.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 30 Oct 2002 13:06:31 -0800

> (or 8-9 new contexts !!!) per mount point because the server does't bookeep in
^^^^^^^^^

Andy if you know how to make krb5/gss contexts MT safe, go for it, and
use one per user. But not everyone knows how, and raising barriers to
entry is not a good thing IMHO.

> a sensible manner is silly. the gss context is designed to be used for

As for per the per mount point/per export point issue, it made sense to us
6 years ago, as we weren't expecting that in practice the sys admin would
have myriad combinations of security flavors on exports.

The QOP is buried in the packet, not necessarily convenient to pull out.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Wed, 30 Oct 2002 18:07:07 -0500

> entry is not a good thing IMHO.

well, thats true enough. of course, a server that only gives a seq window of 5 
does not inspire one to figure out how to run with one context ;)

> have myriad combinations of security flavors on exports.

i can't wait until we begin exporting spkm3 and lipkey as well - talk about 
context hell!!

> The QOP is buried in the packet, not necessarily convenient to pull out.

perhaps we should explore an rpcsec_gss call that lets a client start a new 
seq number stream + qop on an existing context.

-->Andy