[OpenAFS-devel] [LKML] Re: In-kernel Authentication Tokens (PAGs)

[Kyle Moffett]

On Jul 14, 2004, at 18:20, Jeffrey Hutzelman wrote:

> OK, but what's a "key" ?
> What value do I get to use to associate authentication context
> with things like credentials, cached connections, rights
> metadata, and so on?  Bear in mind that these structures are
> not only fairly complex, but may belong to a user-mode
> process.  So, it won't work to just make them be part of the "key".

A "key" is a generic object with a name (Think Kerberos principal),
a type (Kerberos service ticket, AES key, etc), and a binary blob of
data.  The infrastructure itself doesn't much care what's _in_ the
key, it only sets up some complex associations from a process to
a set of "keys" that can be searched in a predefined order.

I am not completely familiar with all of the metadata that AFS
needs to maintain, but with the key system it is possible to have
many different sets of keys accessible.  Perhaps AFS could just
add an extra connection "key" blob that expires when whatever
connection used ceases to exist.  If I have only received the
initial Kerberos AFS ticket and have not actually tried to access
the /afs tree, I won't have a "connection" key, but once I have, I
get one.

The key subsystem will have provisions for kernel modules that
implement "key" types (Types that begin with a "+"), so that they
can receive notifications when keys are created, deleted, expire
are renewed, etc.

> Basically, I need some sort of label I can use in these structures.  
> It must be the case that the meaning of a particular value of that 
> label cannot change without my receiving a notification, so I don't 
> end up with a cached connection established with one user's 
> credentials that is labelled with a label that now belongs to another 
> user.

Here are the structure's that I'm using right now:

struct key {
	struct key_type *type;
	
	spinlock_t lock;
	atomic_t refs;
	
	void *user_lock_owner;
	unsigned long user_lock_level;
	
	/* Undecided stuff here for key expiration */
	
	char *desc;
	void *blob;
	size_t blob_len;
	
	/* More permissions stuff here, not decided yet */
};

struct key_type {
	char *name;
	
	int (*will_create)(char **desc, void **blob, size_t *blob_len);
	void (*did_create)(struct key *key, const char *desc, const void 
*blob, size_t blob_len);
	
	int (*will_change_desc)(struct key *key, const char *old, char **new);
	void (*did_change_desc)(struct key *key, const char *old, const char 
*new);
	
	int (*will_change_blob)(struct key *key, const char *old, size_t 
old_len, char **new, size_t *new_len);
	void (*did_change_blob)(struct key *key, const char *old, size_t 
old_len, const char *new, size_t new_len);
	
	void (*will_destroy)(struct key *key);
};

There is also a key_handle type, but I haven't quite finalized
all the aspects of how it should work yet.

> Similarly, it is important to have notification when the credentials 
> themselves change -- if you set a new token, I need to throw away 
> cached connections established with the old token.

Let's assume 2 objects, a generic "Kerberos service ticket" with
no in-kernel handling, and an "AFS connection token" that has
all the AFS metadata and a cached copy of the ticket used in
that connection.  When a user runs the new and improved
"aklog", their "afs/realm@REALM" Kerberos service ticket (type
"+kerberos_v5_service" is searched for.  If found, its contents
are copied along with any necessary metadata into the
"afs/realm@REALM" token of type "+openafs_connection".
AFS can store whatever it needs to have for the duration of the
session, and run on the assumption that when their token is
not needed it will lose all references and be deleted.

> It also must be the case that a user cannot "forge" a label.
> So, it pretty much has to be a kernel-defined property of the
> key, rather than a user-supplied value.

I don't know exactly what you mean by "forging" a label, but
as far as the implementation goes, user-space can _ask_
for whatever description (like kerberos principal name) that
it wants, with whatever blob it wants.  It's up to the kernel
module to actually implement data checking on any blobs.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------