--On Friday, September 18, 2009 08:06:44 PM +0100 Simon Wilkinson
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
