using keys service for wireless

using keys service for wireless

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

Hi all,

Months later... I finally thought about whether we should be using the
key service (Documentation/keys.txt) for wireless. I think I've decided
against that but want to present my thoughts here just in case someone
jumps in to tell me where I'm wrong :)

So let me start with an analysis of how we currently use keys. Normally,
when we set up an encrypted wireless connection, we do two things at the
same time: we tell the driver (or mac80211 stack) to use encryption and
hand it a key. There are keys of various types based on which we decided
what kind of encryption userspace is trying to set up.

After the key has been set we encrypt all frames that go out with that
key. Oh, there's an issue with group keys vs. pairwise keys which means
that a single connection can have multiple keys and for outgoing packets
we choose one of them to do the encryption with, same for incoming
packets.

For master mode (access point), we have a key per station and possibly
some more keys, but the basic principle is the same: we hand the
stack/driver a key and it uses it for en- and decryption.

There's basically no lifetime management going on, the key is usually
valid until removed by userspace. In some cases there needs to be key
renegotiation, but this is handled entirely in userspace anyway.

Looking at this, I notice that if we wanted to use the key service we'd
still have to tell the stack/driver about the encryption type [1] we
want to use as well as when to start using it. Since we have no lifetime
issues here, using the key service doesn't seem to really gain us
anything and makes the userspace interface more complicated (the actual
key data would be transported out of band while the command to use it
still is in nl80211)

Does anybody have a differing opinion? If not, I'll add the required
primitives to nl80211.

johannes

[1] we could of course use many many key types or the key description
for this

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: using keys service for wireless

[David Howells]

Johannes Berg <johannes@sipsolutions.net> wrote:

> Oh, there's an issue with group keys vs. pairwise keys which means that a
> single connection can have multiple keys and for outgoing packets we choose
> one of them to do the encryption with, same for incoming packets.

Sounds messy:-)

> Looking at this, I notice that if we wanted to use the key service we'd
> still have to tell the stack/driver about the encryption type [1] we
> want to use as well as when to start using it.

Surely you have to tell it that anyway at some level.  And can you not embed
it in the key payload?

As an example, I've just been reimplementing my in-kernel RxRPC (AFS) service
to provide (a) a socket interface so userspace can use it, and (b) security.
The way I do things is that userspace adds a key to its session keyring with a
description of that name of the AFS cell (by calling the klog program).

The type of security required (kerberos4 is currently the only option) is
embedded within the key.  When a userspace AFS client program wants to use a
secured RxRPC socket, it nominates the name of the key it wants by a socket
option:

	char cell[] = "afs@CAMBRIDGE.REDHAT.COM";
	ret = setsockopt(client, SOL_RXRPC, RXRPC_SECURITY_KEY,
			 cell, strlen(cell));
	OSERROR(ret, "key");

and the kernel then calls request_key() on that description to get the key,
which it can then retain attached to the socket structure in the kernel.

The server side of things I've done by giving the server AF_RXRPC socket a
keyring with the server's secret list attached as keys:

	keyring = add_key("keyring", "AFSkeys", NULL, 0,
			  KEY_SPEC_PROCESS_KEYRING);
	OSERROR(keyring, "add_key/ring");

	const char secret[8] = { 0xa7, 0x83, 0x8a, 0xcb, 0xc7, 0x83, 0xec,
				 0x94 };

	key = add_key("rxrpc_s", "52:2", secret, 8, keyring);
	OSERROR(key, "add_key");

	ret = setsockopt(server, SOL_RXRPC, RXRPC_SECURITY_KEYRING,
			 "AFSkeys", 7);
	OSERROR(ret, "set keyring");

The keys in the keyring are named for the RxRPC service ID (52 - Volume
Location Service) being provided and the security type (2 - kerberos).  This
permits the server to add and remove keys without pestering the socket.

Using the keytype's match() function, it would be possible to have a key
named, say, "afs@cambridge.redhat.com:52:2" and match the bit I wanted
depending on the pattern given to match().  For RxRPC, however, the keys are
very different, so it doesn't actually make any sense to do that.


Now this analogy may or may not help you.  I'll leave that up to you.

David