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

[Simon Wilkinson]

>>> I agree that there is sense in allowing an enctype other than the =
two
>>> present in the provided tokens, but it's not imeediately/obviously =
clear
>>> that it must always be the stronger one.
>>=20
>> Well, it needs to be the "most preferred" one.  That pretty much has =
to
>> mean one of three things:
>>=20
>> 1) Whichever one the server picks from the client-provided list.
>> 2) Whichever one comes first(*) in the client-provided list.
>> 3) Whichever one comes first(*) on a standardized fixed list.
>>=20
>=20
> I'll accept that as a complete list.
>=20
>> I certainly don't want (3), and I don't think anyone else does, =
either.
>> Both of (1) or (2) are in common use, and either would be acceptable =
to
>> me.  Note that in the case of (1), you can still say that the client
>> list is sorted by preference, without requiring the server to agree.
>>=20
>> (*) without loss of generality
>=20
> 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 =
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;
};

struct RXGK_TokenInfo {
    RXGK_Enctype enctype;
    RXGK_Level   level;
    uint32  	 lifetime;
    uint32  	 bytelife;
    rxgkTime   	 expirationtime;
};

CombineTokens(IN RXGK_Data *token0, IN RXGK_Data *token1,=20
              IN RXGK_CombineOptions *options,=20
	      OUT RXGK_Data *new_token,=20
	      OUT RXGK_TokenInfo *info);

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.

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.

Cheers,

Simon.