>>> 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.
>>
>> Well, it needs to be the "most preferred" one. That pretty much has to
>> mean one of three things:
>>
>> 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.
>>
>
> I'll accept that as a complete list.
>
>> 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.
>>
>> (*) without loss of generality
>
> 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,
IN RXGK_CombineOptions *options,
OUT RXGK_Data *new_token,
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.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
