[00:31:00] --- Rasmus Kaj has become available [00:41:01] --- haba has left [01:15:32] --- jaltman has become available [01:22:29] --- haba has become available [01:43:04] --- haba has left [01:43:06] --- haba has become available [02:30:44] --- dev-zero@jabber.org has left [03:20:55] --- abo has become available [04:35:38] --- haba has left [04:43:39] --- haba has become available [04:57:01] --- Jeffrey Altman has become available [04:57:11] --- jaltman has left: Replaced by new connection [04:57:12] --- jaltman has become available [05:35:47] --- pod has become available [05:50:10] --- Jeffrey Altman has left [06:15:02] --- dev-zero@jabber.org has become available [06:55:45] --- deason has become available [07:12:40] --- Simon Wilkinson has become available [07:13:16] Let's see if that fixes our jetty problem, then. [07:15:45] --- jaltman has left: Disconnected [08:25:40] --- Simon Wilkinson has left [08:26:48] --- Simon Wilkinson has become available [09:16:17] --- haba has left [09:34:16] --- reuteras has left [09:36:52] --- Rasmus Kaj has left [10:18:07] --- shadow@gmail.com/owl1B3CD396 has left [10:18:49] --- shadow@gmail.com/owlF11A81EF has become available [10:49:47] --- haba has become available [11:30:27] --- Russ has become available [11:35:21] --- Rasmus Kaj has become available [11:40:17] --- shadow@gmail.com/owlF11A81EF has left [11:42:59] --- shadow@gmail.com/owl61F80D53 has become available [12:43:31] --- stevenjenkins has left [12:47:16] --- stevenjenkins has become available [12:54:47] --- stevenjenkins has left [12:55:07] --- stevenjenkins has become available [13:15:14] --- pod has left [13:16:08] --- pod has become available [13:39:00] --- dev-zero@jabber.org has left [13:39:08] --- dev-zero@jabber.org has become available [15:06:14] --- dev-zero@jabber.org has left [15:28:12] Is it realistic to require that a cache manager always has a connection 'as itself' (that is, without using a users tokens) to a fileserver? [15:43:33] --- deason has left [15:51:43] --- dev-zero@jabber.org has become available [15:53:25] Cache managers pretty much always have such connections; they use them for probing. [15:53:56] Those are rxnull connections, but I don't think it's that much of a stretch to require an authenticated one, depending on why. [15:54:23] --- dev-zero@jabber.org has left: Replaced by new connection [15:54:24] --- dev-zero@jabber.org has become available [15:54:51] The why is that I'm thinking of ways of using rxgk to provided an authenticated callback channel. [15:55:34] One possibility is to use a key for the callback channel that's derived from a key that's been used by the cache manager - in a world with keyed cache managers, of course. [15:57:11] Yeah; if you do that right, the cache manager doesn't actually need a long-term key; it can make one up at startup. I think we even talked about such a possibility in earlier rxgk design talks. [15:57:37] --- stevenjenkins has left [16:00:02] The CM uses anonymous PKINIT or PKU2U to get an rxgk token, which it then uses to get authenticated VLDB and anyuser fileserver responses, to combine with users' tokens for authenticated fileserver connections, and to provide a way for the fileserver to authenticate callbacks. [16:00:19] Presumably the last is done by having the CM make an RPC in which it provides the fileserver with an rxgk token. [16:01:15] Some of it is going to be a bit hairy, but you seem to have time to think about it. [16:01:21] You can do that explicitly. Or the fileserver can use the tokens that it sees from the client, and select one that only contains the CM identity. [16:01:32] --- stevenjenkins has become available [16:02:02] The layering gets to be exciting, though. [16:02:52] I have some time to think about it, but not a lot of time to elapse. This all needs to be wrapped up by next August. [16:03:03] Possibly. If the fileserver's going to just-pick-one, it doesn't actually matter which one it picks. Any token containing the CM identity is sufficient, since no user will know the key. That probably means it can just use the first token it sees, or something. [16:04:08] Yes. You just need to be careful about lifetimes and expiration, and making sure that both sides know which key they're using. [16:04:43] Hm. Except I think from a layering standpoint, and possibly for other reasons, it's best if the fileserver is handed a token it can use to talk to the CM. Note that in this case, the callback channel could actually be authenticated using a different class than the forward conns. [16:05:41] --- dev-zero@jabber.org has left [16:05:50] That's true. It just means that the token service becomes still more complex ... [16:17:06] --- dev-zero@jabber.org has become available [16:22:20] How so? The token service is unnecessary here; the CM simply conses up a token (presumably rxgk would provide an API for that) and hands it to the fileserver, which can then use it directly, as if it had been obtained via the usual GSS-API-authenticated exchange. [16:32:00] --- deason has become available [16:37:10] Which key would this token be encrypted by? [16:44:24] The one authenticating the RPC by which the CM transmits the token to the fileserver. [16:45:07] I'm not sure I like that, because it muddies our key classes. [16:45:49] Currently, the keys and algorithms that are used from token signing are completely separate from those used in the rest of rxgk. [16:46:12] s/signing/encryption/ [16:46:29] Token encryption is a purely AFS feature. [16:48:08] Huh? Oh, you dislike just sending a token as the argument of an authenticated RPC? To me, the ability to do that is a feature. [16:48:36] Though I admit, it does present the problem of not providing an obvious place to do algorithm and parameter negotiation. [16:48:48] I don't mind sending tokens as RPC arguments. [16:48:56] Although, negotiation is tricky. [16:49:17] That's what I was proposing. It's protected because it's transferred via a protected RPC. [16:49:37] Maybe you were asking a different question. [16:49:48] No, I think I was misunderstanding. [16:49:55] The token's "service key" is one the CM makes up for that purpose. No one else has to know it. [16:50:35] I thought you were proposing sending a token in terms of an opaque, encrypted, blob. [16:50:53] If it's sending the contents of that blob, protected by the current transport key, then that seems fine. [16:53:08] (The difference to me is where things like encryption type get embedded. Which still has to be resolved for tokens - they're going to need some kind of key version number in order to permit algorithm agility, and key rollover) [17:11:48] The rollover problem is somewhat easier for CM's; a CM that wishes to continue getting callbacks is simply require to periodically send a new token to the fileserver. :-) [17:59:36] --- Russ has left: Disconnected [21:14:20] --- jaltman has become available [22:02:32] --- reuteras has become available [22:20:54] --- deason has left [22:21:05] --- shadow@gmail.com/owl61F80D53 has left [22:22:38] --- shadow@gmail.com/owl61F80D53 has become available [23:07:22] --- Rasmus Kaj has left