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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
