[AFS3-std] draft-wilkinson-afs3-rxgk-afs-01 comments

[Matt W. Benjamin]

Hi Simon,

This does make sense.  It has been understood that extended callback invocations other than "cancel" must be restricted to a secure channel  (when this security model is in force, Jeff Altman has mentioned another profile which might be used in restricted circumstances, I don't know if that is still under consideration).  Since "cancel" is nothing more than BCB with another name, there is no benefit to using the extended callback interface, except potentially for implementation convenience.

Regards,

Matt

----- "Simon Wilkinson" <simon@sxw.org.uk> wrote:

> 
> Only RPCs which are authenticated with identities on this list would
> be eligible for extended callbacks. RPCs with different client
> identities, or which are issued over non-rxgk security classes, would
> not receive extended callbacks. Where we have callbacks for the same
> object requested by multiple different client identities, the key of
> the most recent identity used would be used to encrypt the callback.
> 
> Making all of this work complicates things significantly at the
> client, which must now maintain an rxgk token signing service, so that
> it can issue a proper token to the server for each key that it has in
> play, such that it can then pull the key out of that token.
> 
> Does that make sense?
> 
> Cheers,
> 
> Simon.
> 
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309