On Fri, 2 Nov 2012, Jeffrey Hutzelman wrote:
On Fri, 2012-11-02 at 15:50 -0400, Benjamin Kaduk wrote:
[Attempting to combine Jeff's two latest mails into one reply]
On Thu, 1 Nov 2012, Jeffrey Hutzelman wrote:
On Wed, 2012-10-31 at 22:59 -0400, Benjamin Kaduk wrote:
On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:
It also may present something of a future-proofing problem: currently, we
pass two tokens in and get a token out. If we need to start passing more
information back, we might get into trouble if an application has
app-specific data into the token that also needs information passed back.
If we can keep the interface as tokens-in, tokens-out only, that situation
is much cleaner.
Though, if we're going to be defining app-specific RPCs anyway
(AFSCombineTokens), maybe this is not a huge concern.
Well, note that when you get a token in the first place, you necessarily
get some additional information along with it, such as the enctype and
the key itself. In this case, we don't need to transport the key
because it is derived using the PRF; that's useful because the nature of
the operation means that none of the existing keys can be fully trusted.
Right.
However, that doesn't mean we can't pass other information required to
make the token usable, and even use the new key to protect it (with
appropriate key usage, of course).
True. My concern is basically about whether we can pass that other
information in a general-enough fashion to not paint ourselves into a
corner. Attempting to enumerate the "additional information" one gets
along with a token makes me wonder if the enumeration is complete, or even
can be complete given the possibility of application-specific data.
The caller should be able to assert any identity ordering, presumably by
the order in which the input tokens are provided. That is, if Alice and
Bob "combine forces", the caller gets to decide whether the identity
expressed by the output token is [Alice,Bob] or [Bob,Alice], and the
spec says how to do so. Of course, the meaning of multiple identities
in a token is up to the application, and in any case, might end up being
considerably more complex than just a list.
Do I need to go read brashear-afs3-pts-extended-names to have context for
this
No. As above, the point is that there is an ordering, and it can
matter. For example, in the cache manager case, the user's token might
belong to [email protected], and the CM's token might belong to
host/[email protected]. You want the resulting
token to confer all of the rights Alice has, and possibly also rights
granted to users of your-workstation.example.com (the equivalent of an
IP address ACL, but actually secure). But you don't want to include
rights granted to the workstation's host principal -- there's a
difference between the y-w.example.com and "people accessing AFS from
y-w.example.com". Also, you want to use Alice's ID as the owner of new
files and as the recorded author of changes.
So, when I write [Alice,Bob], I just mean whatever potentially-complex
identity and authorizations the application confers when the tokens are
combined _in that order_.
Fair enough.
It's not clear what reading to apply to a "combined combined token", that
is, a Tn where one of the source T0 or T1 was already the result of a
CombineTokens() operation.
"list of identities is the union of those in the original tokens" would
seem to imply that there is not a concept of nested list/pairs, just a
flat space. Actually, "union" would seem to imply a set-theoretic
concept, *without* order. So given your above interpretation, that would
be a bug in the spec.
Choice of enctype should be by selecting the strongest available
enctype, where "available" means those enctypes both supported by the
server and known to be supported by the client, and "strongest" is up to
the server to determine. The list of enctypes could be taken from all of
the provided tokens, but I think it would be better for the caller to
provide an explicit list, as this allows upgrade to an enctype that is
supported by the caller and server but may not have been supported by
the original token issuers (or by the clients that got the tokens).
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.
I'm going to defer the discussion of levels to another message, both
because I want to get to dinner and because I need more time to think
about it.
The above discussion of combined identities probably renders some of my
analysis incorrect. I look forward to your thoughts.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
