Subject: [nfsv4] more on weak callback authentication

From: [email-masked]
Date: Fri, 31 Oct 2003 11:55:17 -0500 (EST)

[Mike said]
> 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.

All true although, since I see a Revocation as a last resort for the
server, I'd prefer to know if the weak authentication would work before
handing out a delegation, to minimize the likelyhood of a delegation the
server can't recall.

[Bruce said]
> 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

Yep, although I think the attack is non-trivial, something along the lines of:
- fake client injects packets to break server->client callback TCP
  connection
- fake client spoofs real client's IP#, accepts connection on correct
  port#
(did I get this about right?)
all to report bogus size and change attributes for file(s) that
happen to be write delegated to the real client at that time.
I guess it depends on the server, but for some (like mine), it just means
other clients will see bogus attributes until the delegation is recalled.
(Note that I am assuming the real client authenticated to the server
 ok when it did SetClientID and used at least svc_integrity, so the
 IP callback address is legit.)

> 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

Yep, and if the client cares it can either:
- have a keytab entry so the callback authentication works
or
- ignore the truncate flag on recall requests and push writes to the
  server anyhow

Sound about right? rick

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 31 Oct 2003 14:01:38 -0500

> (did I get this about right?)

Sounds right, but this is exactly the sort of thing rpcsec_gss is
supposed to protect against.

> other clients will see bogus attributes until the delegation is recalled.

Playing with the changeattr could mess up the other clients' caches,
couldn't it?  Also, what about acl's and mode bits?

> - ignore the truncate flag on recall requests and push writes to the

Sure.

Can someone do damage by intercepting callbacks and forging succesful
replies?  Or does just blocking the callbacks (which krb5 can't do anything
about) have the same effect already?

--Bruce Fields