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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
