[AFS3-std] rxgk implementation notes

[Benjamin Kaduk]

On Thu, 28 Feb 2013, Jeffrey Hutzelman wrote:

> 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.

We're not; we knew this a while ago, but I haven't gotten around to 
writing the new text yet.

> 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.

Hmm, plausible.  -00 submissions are cutoff at the moment, though.

>> 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.

We have SEALED_INCON and BADCHALLENGE and BAD_TOKEN.  I guess I 
can make a list of some of the places that seem hard.  It's tempting to 
use ENOMEM in quite a few places, but that's not exactly a wire error 
code...

>> 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?

To some extent, sure.

>> 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.

There's an xdr_afs_int64 which is used by the rxgkTime en/decoder; I am 
saying that it is a lot of overhead to invoke the XDR encoder when 
preparing the seed for PRF+.

>> 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.

I was wondering whether it gave some resistance to replay attacks, but had 
not reasoned through it very far.  Presumably the papers to which Simon 
referred will help with that.

-Ben