[AFS3-std] rxgk application-specific behavior for rxgk-afs

[Benjamin Kaduk]

Hi all,

I went through draft-wilkinson-afs3-rxgk-10 and made a list of places 
where behavior is left as "application-specific", "application defined", 
or similar, with the goal of making sure that we don't leave anything out 
of rxgk-afs that needs to be specified.

We have:

(1) The token format

We do currently specify a token format, to be shared between dbserver 
tokens and fileserver tokens (though the current form is interpreted 
differently for the two, and is still under discussion).

Our introductory text talks about "rxgk tokens for AFS take the form of 
[...]", but later on we say only "the above structure is used for both 
database server tokens and file server tokens".  The document does admit 
the existence of non-file, non-database server services related to AFS 
(that might want to use rxgk), but disavows applicability to such other 
services.  In terms of token format and interoperability, this is probably 
okay, because things like bos are only on a single server and will be the 
only things producing tokens for their consumption, so the token format 
remains ~arbitrary, as it is left in the core rxgk document.  I don't 
really think any changes to the document are needed for this issue, but I 
also expect that the token format we define will likely be reused as 
convenient.

(2) The location of the key-negotiation service

We specify that database server tokens are obtained from the rxgk key 
negotiation service on the vlserver, on its port and the rxgk service ID. 
File server tokens are obtained via AFSCombineTokens against the vlserver, 
and we say nothing about running the RXGK_ package on file server 
endpoints.  It might be a little bit of a gray area in the core spec 
whether the file server is obligated to provide an rx server that listens 
on the rxgk key negotiation service ID; however, if such a service exists 
it is forbidden from issuing file server tokens ("AFSCombineTokens is the 
only way to obtain a valid file server token"), so the question seems 
pretty irrelevant.

I am slightly concerned that we specify the database server package names 
explicitly as PR and VL, omitting, e.g., BUDB_.  While the latter is not a 
core AFS-3 service, it is a database server shipped with OpenAFS, and I 
would expect that it would use function as a database server for the 
purposes of the token format and token-encrypting key in this document.  I 
don't know how to reword things to accomodate this (or similar) usage, 
though.

(3) Potential application-specific knowledge of the key negotiation GSS 
acceptor identity

We do specify afs-rxgk@_afs.<cellname> (GSS_NT_HOSTBASED_SERVICE) for the 
vlserver endpoint.  File server endpoints will not be functional, so the 
default <service name>@<hostname> (GSS_NT_HOSTBASED_SERVICE) is perfectly 
adequate.

(4) The constant RXGK_MAXDATA

We do not specify a value for this constant.  Leaving it as 
implementation-defined is (sort of) asking for interoperability problems, 
so we should probably pick something.

(5) The contents of the opaque in/out parameters of GSSNegotiate()

These are given as "application-specific", but since all calls to 
GSSNegotiate() in a given context negotiation loop MUST be on the same rx 
connection, I think it is actually "implementation defined".  That is, we 
don't actually need to specify anything for them, though arguably to be 
pedantically correct we should explicitly say that the 
application-specific behavior is that the behavior is 
implementation-defined.

(6) Token combination behavior of application-specific data fields

Application-specific fields are those other than 'enctype', 'level', 
'expiration', lifetime', 'bytelife', and the identity list (and the master 
key, of course).  For our current token format, that means just 
start_time.

We do not currently specify what is used to populate the start_time of a 
combined token (BUG!).  Off the top of my head, I would say that the 
server should just insert the current time of when it performs the 
combination.

(6) Token combination behavior of identity information

We specify that the lists are concatenated, in order.

If we do move to a separate "CM identities" field in the token format, we 
will need to specify the behavior of CombineTokens and AFSCombineTokens 
separately.

(7) The authenticator 'appdata' field

We specify this, as [what boils down to] the CM UUID.

This declaration appears to apply equally to the use of fileserver tokens 
and database server tokens, which seems fine.  I think that we only 
propose using this UUID for extended callbacks (i.e., fileservers), but 
(a) didn't look very hard and (b) don't see value in adding a difference 
between client behavior talking to fileservers and dbservers, here.


I think that's it for behavior left up to the application by the core rxgk 
spec.

-Ben