[AFS3-std] rxgk specification

[Jeffrey Hutzelman]

--On Friday, September 18, 2009 08:06:44 PM +0100 Simon Wilkinson 
<simon@sxw.org.uk> wrote:

>
> On 18 Sep 2009, at 19:41, Chaskiel Grundman wrote:
>
>> 1) Should the token format be a part of the formal spec? Only
>> servers sharing service keys need to agree on it.
>
> Its not clear to me where the token format belongs. If we're doing shared
> service keys for the AFS implementation of rxgk, then it definitely needs
> to be spec'd in the document describing the application of rxgk to AFS.
> However, there are other elements of the token format whose behaviour
> needs to be specified (for instance, the behaviour with CombineTokens,
> how the various lifetimes interact, etc). Those seem more appropriate in
> this document, than in an application specific one.
>
> One possibility might be define certain minimum attributes of the token
> format (enctype, K0, at least) and then have an opaque blob which is
> application specific.

The token format is meant to be opaque; clients only ever see it as an 
encrypted blob.  We only need to standardize it if we want to be able to 
have a group of cooperating servers which share tokens but are different 
implementations.

There are certain client-visible properties, such as enctype, key, and 
expiration, which are made available to the client separately and whose 
semantics need to be defined.  But this is separate from the format of 
tokens themselves, which I think can safely remain unspecified.


> One security concern of mine is that an attacker can happily combine
> tokens sniffed from the wire using the interface described here. They
> won't be able to use the combined tokens for anything, but they can make
> the server do the work.

IIRC, the combine-tokens operation required that one of its inputs be 
encrypted with a key derived from the other.  This requires that an 
attacker know at least one of the keys involved to cause the server to do 
any more work than decrypting a token.  I think that's a reasonable 
threshold, since an attacker can already cause servers to decrypt tokens 
even without this interface.

-- Jeff