rxgk CombineTokens and enctypes (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

On Sat, 3 Nov 2012, Simon Wilkinson wrote:

>>> 1) Whichever one the server picks from the client-provided list.
>>
>> Okay.  I would pick (1) from that, and prefer that the client indicates its preferences.
>
> If we're doing this (and I have no objection to doing so, as it's

I think this is the least bad way to get to a fully/usefully specified 
CombineTokens operation.  (That is, I think we should do it.)

> necessary for AFSCombineTokens, in any case) then we need to change the 
> signature of CombineTokens to something like:
>
> struct RXGK_CombineOptions {
>    RXGK_Enctypes enctypes;
>    RXGK_Levels levels;

I don't think we have an array RXGK_Levels typedef in the document at the 
moment, and adding one in addition to the non-plural RXGK_Level enum might 
be confusing.  So I would put this as 'RXGK_Level levels<>' to 
match StartParams.  (Sorry, nitpicking.)

> };
>
> struct RXGK_TokenInfo {
>    RXGK_Enctype enctype;
>    RXGK_Level   level;
>    uint32  	 lifetime;
>    uint32  	 bytelife;
>    rxgkTime   	 expirationtime;
> };
>
> CombineTokens(IN RXGK_Data *token0, IN RXGK_Data *token1,
>              IN RXGK_CombineOptions *options,
> 	      OUT RXGK_Data *new_token,
> 	      OUT RXGK_TokenInfo *info);

Do we want a way for the server to indicate a problem with the request? A 
zero-length new_token would indicate failure, but there might be some 
sense in reusing the RXGK_ClientInfo errorcodes here.  It would give the 
server a way to explicitly indicate that the client's suggested values are 
not acceptable, which seems useful.

>
> This is roughly similar to what is done with AFSCombineTokens in order 
> to support departmental fileservers and solve the first packet problem. 
> Strictly speaking, I don't think we need lifetime and bytelife in 
> CombineTokens, as they can be programatically determined - but we do 
> need them for AFSCombineTokens, so I'm leaving them here.

I don't mind leaving them here.  (When I am writing an application, I 
will sanity-check such returned values, of course.)

That said, I don't think that the rxgk-afs printout I have handy reflects 
the quoted text.

>
> The question here is whether the TokenInfo structure needs to be 
> protected in some way. If the enctype is wrong, then the PRF will fail, 
> and we won't be able to use the token. If the level is faked, then we 
> won't be able to use the token to establish a security context. If the 
> lifetime and bytelife are false, then the server will still rekey the 
> connection, although the client won't (or may rekey too frequently). If 
> the expirationTime is faked, then the client won't realise that the 
> token is going to expire ahead of time - but the server will still 
> reject attempts to use expired tokens. So, I'm leaning towards the 
> protection that's provided by performing this operation over an AUTH (or 
> higher) connection being sufficient.

I don't see any flaws in this reasoning at first reading, but note that it 
would be easy to mic with Kn if desired.  I'm not suggesting adding a mic 
at this time, though.

-Ben