[AFS3-std] rxgk implementation notes

[Jeffrey Hutzelman]

On Thu, 2013-02-28 at 17:05 -0500, Benjamin Kaduk wrote:

> It's hard to get the logic right for when to terminate a GSS negotiation 
> loop

Yes; getting this right can be quite tricky.  Someone should probably go
back and review the document to make sure we're correctly describing
what implementations should do and covering all the bases.

Better yet, this logic is basically the same for all GSS-API
applications.  Someone should write up an I-D describing the correct way
to handle both the initiator and acceptor sides of context
establishment, including what all the termination conditions are, and
get it published as an RFC.  I wouldn't be surprised if such a thing
were well-received in the KITTEN WG.


> Additionally, the gssapi libraries shipped with some OSes do not support 
> the pseudo-random functions that we need.  This is just something that 
> implementations will have to deal with.

This is actually hard to work around.  The PRF operation is
mech-specific and generally requires access to key material that is not
visible through the API.  So, if your OS's GSS-API library doesn't
support it, you basically just can't use that library.




> Relatedly, there's not an obvious error code to return when such encoding 
> fails or we can't allocate memory for the new object.  I've been using, 
> e.g., RXGEN_SS_MARSHAL for now, but I wonder if there are more RXGK error 
> codes waiting to be added, here.  There's also some temptation to make 
> things like BADLEVEL apply to the authentication step as well as just 
> token negotiation; that would probably warrant changing the associated 
> error string.

There should be some generic rx-level error codes that are appropriate.
The rxgen-level codes are appropriate, I think, for handling data sent
and received as RPC arguments, but challenge/response ought not to
generate those, and they're probably also not appropriate for cases
where the encrypted part of a token doesn't decrypt successfully.  So
yet, there may be room for another error or two here.



> The transport key is derived from the master key and a few pieces of 
> information that are sent from client to server in the clear; it therefore 
> seems that the utility of the transport key for avoiding key sharing 
> mostly comes into play when large quantities of data are being conveyed. 

Also when the same token is used for multiple connections, no?



> Endianness conversion routines for 64-bit quantities (i.e., rxgkTime) do 
> not seem to be universally available; an incorrect hand-rolled 
> implementation could lead to interoperability issues.

True, but note that OpenAFS should have routines for this, and if AFS
XDR doesn't have a data type for this, we should add one.


> It's a bit awkward to include call number information in the authenticator 
> (read: feels like a layering violation), and it's not clear to me what 
> benefit is gained from doing so.

Integrity-protecting call number information is important because the
current call numbers are part of the connection state.  Recall that
servers receiving a packet that is part of a connection they've never
seen before will "recover" the connection, copying some of that state
from the incoming packet.  So, IIRC, protecting call numbers is
necessary to help defend against replays.  It'll take me a bit to
reconstruct the reasoning here, but I'm pretty sure I did successfully
do so (for rxkad) back in the early stages of rxgk design.


-- Jeff