Subject: RE: [nfsv4] weak callback authentication

From: Mike Eisler <[email-masked]>
Date: Thu, 30 Oct 2003 18:02:08 -0800

> -----Original Message-----
 > From: [email-masked]
 > [mailto:[email-masked]]
 > Sent: Thursday, October 30, 2003 5:24 PM
 > To: [email-masked]
 > Subject: [nfsv4] weak callback authentication
 >
 >
 > 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 can't see any flaws in your logic. With that assumption, I like
it.

A client wants protected SETCLIENTID, because otherwise, a rogue
client could blow away an innocent's state. If it doesn't want to do machine
creds, then it will have unprotected callbacks.

Protected SETCLIENTID in tandem with unprotected callback
still beats unprotected SETCLIENTID in tandem with
unprotected callback.

 > 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:-)

It's the client's choice though. The sys admin that doesn't want
to deal with 1000s of client side keytab files can make
an informed tradeoff.

 > 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.

Assuming the client won't allow weak authentication on
callback, then when the first callback fails due to authentication
problems the server will have to revoke the delegation. As to whether
the server permits future delegations depends on implementation
preference. If the callbacks worked previously, then perhaps there
is a transient problem. The server can temporarily ban that clientid from \
delegations, and remove the ban under probation at some time in the
future.

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

---

From: "Lever, Charles" <[email-masked]>
Date: Fri, 31 Oct 2003 08:14:57 -0800

> [W]ouldn'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.

it would be a nice indirect attack against the server -- a malicious
entity could cause all the clients to purge their caches constantly,
flooding the server with fresh READs, slowing down everyone, and
potentially overloading server and network.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 31 Oct 2003 10:55:28 -0800

> From: Lever, Charles
 > Sent: Friday, October 31, 2003 8:15 AM
 > To: J. Bruce Fields
 > Cc: [email-masked]
 > Subject: RE: [nfsv4] weak callback authentication
 >
 >

This is a good argument for the server enforcing a level of security
in SECINFO.

While NFS4ERR_WRONGSEC is not a legal error for SECINFO responses (in NFSv4.0)
it is a legal for the server to return a weak authentication RPC error
to the client.