Subject: [nfsv4] weak callback authentication

From: [email-masked]
Date: Thu, 30 Oct 2003 20:24:14 -0500 (EST)

Looking at the bigger picture, what about weakly authenticated callbacks?
(I'm not particularily fond of AUTH_NONE for SetClientId, but AUTH_NONE
 or AUTH_SYS (same thing, really) for the callbacks, doesn't sound so
 bad to me.)

I suppose a naughty fake server could overload a client with CBGetattr
calls or force premature Recall of the delegations, but in many environments,
that might not be a big problem. (As a server writer, I don't care about
the clients:-)

The problem I see is, "What the server should do when the GSS authentication
attempt fails?". Should it disable callbacks/delegations? Unfortunately, I
don't see a way within RFC3530 that it can test to see if the client will
allow weaker authentication for callbacks, unless it first issues a
delegation, without being sure it can recall it.

One yucky possibility would be to have clients ignore CBNull calls with
weaker authentication than they are willing to accept for CBGetattr and
CBRecall (I know, ugly, but...).

Anyhow, just a thought, rick

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

---

From: Trond Myklebust <[email-masked]>
Date: 30 Oct 2003 23:42:27 -0500

>>>>> " " == rick  <[email-masked]> writes:

     > Looking at the bigger picture, what about weakly authenticated
     > callbacks?  (I'm not particularily fond of AUTH_NONE for
     > SetClientId, but AUTH_NONE
     >  or AUTH_SYS (same thing, really) for the callbacks, doesn't
     >  sound so bad to me.)

     > I suppose a naughty fake server could overload a client with
     > CBGetattr calls or force premature Recall of the delegations,
     > but in many environments, that might not be a big problem. (As
     > a server writer, I don't care about the clients:-)

As far as the clients are concerned, it would be an inconvenience, but
never a showstopper, since the client is not ever allowed to assume
that it will keep a delegation indefinitely.

I therefore agree with you and Mike: this should be perfectly
acceptable. Given that the recall is not complete until the
DELEGRETURN call has been issued, there should be no exploitable
loopholes here.

Cheers,
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 31 Oct 2003 10:13:48 -0500

>  or AUTH_SYS (same thing, really) for the callbacks, doesn't sound so

The server would no longer be able to trust the responses it got to
CB_GETATTR.  Isn't that a problem?  Also, wouldn't a CB_RECALL with the
truncate flag set could cause the client to throw away data when it
shouldn't have?  I suppose that's the client's problem, not the
server's, though.--Bruce Fields