Session key extraction

[Greg Hudson]

On Mon, 2008-12-22 at 15:39 -0500, Sam Hartman wrote:
> Windows has this feature where you can get a session key from any SSPI context.    According to Luke, some windows protocols such as SMB need this.

I can confirm from reading SSPI docs that Windows has the feature.  You
get the session key as an opaque counted array of unsigned char.

I could see a protocol having its own (ill-advised) constraints on how
encryption or checksumming is done such that it would want to pull out
the key.

> I'm very uncomfortable with this concept: using a session key without
> knowing what kind of key it is or what structure it is seems kind of
> dangerous.

I'd be interested in exploring these risks before deciding the interface
is a bad idea.  In another medium, Sam mentioned:

1. DES keys are not uniformly distributed.  This could be addressed by
removing the DES key "structure" (the parity bits) to yield a 56-bit
key.  Are there other conventional cryptosystems which have key
structures which are not so easy to remove?

2. Using one cryptosystem's keys with another cryptosystem might create
vulnerabilities.  Presumably we're talking about vulnerabilities more
subtle than "the application's cryptosystem is so weak that it reveals
the key, compromising the mechanism's cryptosystem."

Thinking about it briefly: in some cases, even using the key with the
same cryptosystem, but without any associated state, could be a problem.
For instance, if the cryptosystem uses the key to produce a PRNG stream
which is XOR'd with the plain text, using the same key to encrypt two
messages with the same stream position could reveal both plaintexts.

I can also think of exotic cases where a provider might not be able to
come up with a key.  For instance:

  * A mechanism draws from a large body of previously negotiated
one-time-pad data to encrypt data.  (Both sides share a secret, but it's
a very large secret, and it can't be used for any other purpose, so if
you were to answer the application's query for session key data you
would have to coordinate that with the other party--something the API
doesn't really allow for.)

  * A mechanism uses public-key crypto operations for all messages.
(Ruinously expensive today, but perhaps that won't always be true, or
perhaps the mechanism is only used for small amounts of message data and
the users are highly concerned with mathematical provability.)  In this
case the two parties may not ever negotiate a shared secret.

Such exotic cases might be covered by allowing the mechanism to return a
0-byte session key.