Subject: RE: todo list for RFC3010: Callback authentication

From: "Corbett, Peter" <[email-masked]>
Date: Thu, 24 May 2001 11:11:12 -0700

This is just a thought, and I don't think it will go very far, but it would be very convenient if we didn't have to do a separate authentication for server callbacks.  Here is the argument:

The server, according to section 3.4, should authenticate with the client using whatever security flavor the client used for the SETCLIENTID operation.  The set client id operation is performed by the client under its own auspices, not under any user identity.  If the client uses a secure protocol such as kerberos to perform the set client id operation, the server must use the same protocol for all callback operations to that client.  However, it must be the case that the client and server share a session key once the client has authenticated to the server.  So, it would be very convenient if the server could simply use the same session key to perform the callbacks.

I think that the only impediment to doing that (and its a big one) is that RPCSEC_GSS does not allow server initiated operations.  I think this could be solved by a very simple extension to the RPCSEC_GSS data exchange that would have no impact on the existing client to server protocol, or on the session create or destroy.  The extension is that the server and client would share a second sequence number sequence, for use in server initiated transactions.  The sequence window would always be 1, since no multithreading is needed.  The sequence number in RPCSEC_GSS is used primarily as salt to differentiate the contents of the cryptographically checksummed headers from one request to the next.  Without interfering with the progression of the existing client to server sequence number, the server to client sequence number could be used for all callback requests, in rpcsec_gss data request packets formatted by the server.  The client would respond with rpcsec_gss data response pac!
kets, returning the checksum of the sequence number sent to it by the server in the callback request.

Unfortunately, I don't think we can do this, as it would require an extension to a different rfc (2203).  But I do think that such balanced two way interaction is allowed by the GSS_API once a session is established.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 2:29 PM
To: [email-masked]
Subject: todo list for RFC3010

You will find pointers to the "todo" list and a version of RFC3010
that is the base document for our updates at:

http://www.nfsv4.org/rfc3010updates/index.html