Hi,
I'm just updating the rxgk specification to match the implementation I have
produced for OpenAFS. In doing so, I've run in to a few questions, that I'm
going to raise here. I'll use a different email for each, in the hopes of
keeping the threads manageable.
In the current spec, I have included a "version" field in the XDR-marshalled
Challenge and Response structures - the idea of which was to provide an upgrade
path to newer versions of rxgk. However, having this field within an XDR
marshalled structure doesn't actually help provide an upgrade path. If the
structure is different, then the XDR unmarshalling will fail. An implementation
that wishes to take advantage of the version field needs to either "peek" into
the XDR structure, or base its decision on the structures size (as rxkad does
currently). So, this version field doesn't seem useful in its current form.
I'm intending on removing the version field entirely from the Response, and
just specifying that a response must always match the version contained in the
Challenge. This leaves the question of what to do with the Challenge version
There are a number of solutions that I can see here
1/ Leave the version field, and expect implementations to peek into the first
32 bytes of the XDR structure
2/ Move the version field out of the structure, and define a challenge as 4
octets of version information, followed by an XDR encoded structure
3/ Remove the version field, and expect clients to use structure length to
determine the version (which works as long as there are never variable length
elements in the challenge)
4/ Rewrite the challenge definition in terms of either the proposed new
afs-union structure (which seems to me to break abstraction layers), or as a
struct RXGK_ChallengeContainer {
afs_int32 version;
opaque challenge;
}
What are other peoples thoughts on this?
Cheers,
Simon.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
