On 12 Jan 2010, at 22:03, Derrick Brashear wrote: [ typos snipped ]
I'll fix the typos ...
Section 10: "Only RPCs issued over an rxgk protected connection should receive rxgk protected callbacks" I believe this should be a SHOULD. I can conceive of environments where one might wish to violate this.
If we want to relax this language, then we need to be much clearer about the identity requirements that come in to sending callback breaks. To securely send a callback break, you have to ensure that the entity you are sending the break to was a party to setting the callback in the first place. You need a cryptographically secure binding in order to do this, and I couldn't come up with any secure way of establishing such a binding to a client UUID, without requiring that UUIDs be manually registered as part of the client identity.
So, I was left with the binding being to one of the identities used to perform the RPC, and ensuring that there is a tight binding (the current draft requires equivalence) to the owner of the key used on the callback channel. So, you could do rxgk callbacks to rxkad RPCs, but only if you deliver the callback break over a connection secured with the user's (and not the client's) identity. You then need to take steps to avoid a malicious user from poisoning the cache.
Additionally, per offline discussion, section 4.3 should define a 100ns time type and use it for starttime, expirationtime and for consistency, lifetime. Likewise, the relationship between expirationtime-starttime and lifetime should be clarified.
I'll fix these, too. Cheers, Simon. _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
