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

[Simon Wilkinson]

On 1 Nov 2012, at 03:17, Benjamin Kaduk wrote:

> On Wed, 31 Oct 2012, Benjamin Kaduk wrote:
>=20
>> On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:
>>=20
>>> On Mon, 2012-10-29 at 16:57 -0500, Andrew Deason wrote:
>>=20
>> (This is 0309471e70d "Clarify CombineTokens' least-permissiveness", =
not 13a2d01b as might have appeared from the trimmed quoted text.)
>>=20
>>>> Also, should the combined token enctype really be set to the =
minimum of
>>>> the input tokens? Does the order of enctypes based on integer value
>>>> really mean anything? (should this maybe be "most preferable" =
enctype
>>>> based on the input enctypes, or something?)
>>=20
>> A good question! :)
>>=20
>> The old text applied simple logic to "all numerical fields", and one =
of the notes I dug up was to specify which fields those are.  Pulling =
from RXGK_ClientInfo, enctype is represented as 'int', which ... is hard =
to claim is non-numerical.  (RXGK_Level is an enum type, and I also =
listed it as "numerical".  Separate mail on that forthcoming.)

>=20
> Since we give explicit values for the enum RXGK_Level, it would seem =
to fall under a naive reading of "numerical type", and was included in =
the list in my commit 0309471e70db7a.  However, it seems like the =
"minimum of the values" may not be the right choice here, either. The =
right choice itself, however, is not immediately obvious to me.  A CM =
could certainly have one token per level and always combine with a user =
token using the same level ... but this requires knowing what level a =
particular token uses, and the token is supposed to be opaque. =20

The CM knows what level a token has, otherwise it can't protect the =
first packet to the server at the appropriate level. So, that's red =
herring. It's also worth nothing that this a generic CombineTokens =
operation. AFS has its own specific CombineTokens operation which is =
defined in the other document - so even considering cache managers here =
is a bit of a diversion.

=46rom a level perspective, I think a combined token should have the =
lower level of security of the two tokens=20
(where clear < auth < encrypt). We probably don't won't to express this =
as a numerical minimum.

=46rom an encryption type perspective, the intent was that the server =
should pick the enctype which appears highest within its preference =
list.

I think any discussion on negotiation should wait until we consider the =
AFSCombineTokens operation, as that opens an entire other can of worms.

Cheeers,

Simon=