Session key extraction

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> 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.

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

    Greg> I could see a protocol having its own (ill-advised)
    Greg> constraints on how encryption or checksumming is done such
    Greg> 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.

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

My base concern is that this goes against the abstract model of
GSS-API, and what is generally accepted as reasonable abstract models
for key management in the security community.  I can try and defend
both of those, but ultimately, I will be very uncomfortable with this
interface even if I cannot come up with a concrete reason why it is
broken.

The structural argument applies to DES and potentially to exotic
crypto systems that provide provable security.  It seems unlikely that
we'd choose to use a block cipher that was exotic because their
performance tend to be horrible and because the assumptions you need
to make for AES seem acceptable to us today.  However I find the
structural argument interesting because GSS is a very generalized
framework.

However on the train yesterday, I realized that there is a significant
concern in how this key will be used.  The application needs to
understand the authentication mechanism and understand how the session
key is used by that mechanism in order to avoid breaking the security
guarantees of that mechanism.  As an example, if the Kerberos session
key from the ticket is returned for this value, then the application
needs to be very careful not to create an oracle for generating
ciphertext in that key.  Such an oracle could be used by an attacker
to forge tickets encrypted in the key.

In contrast, consider a mechanism that provided something like
Kerberos's subsession key.  If the application never uses the GSS
context after extracting the subsession key, then the application can
do whatever it wants with the subsession key because that key is only
cryptographically significant in the context of a security context
that will never be used.  (Actually even this is not true; a
sufficiently badly designed application could provide exposure of
information exchanged during the authentication process to an
attacker).  So, applications secure under this alternate mechanism
might not be secure for Kerberos.


These are some of the reasons why key management protocols generally
release keys only in a specific context and for a specific purpose.
Take a look at RFC 4962 for the sorts of requirements that the IETF is
placing on a protocol feature that hands keys over from one part of a
system to another.  That document is not as clear as we hoped it was
at time of publication; you might not be able to get that much from
it, but it is an example that my concerns are shared by others.


I'd be happy with a protocol feature that released a pseudo-random bit
string to an application for use in keying, guaranteeing that
bit string was cryptographically independent of the security of the
gss-api authentication and context.  I am happy (only because it is
historically necessary) with a mechanism that releases a Kerberos
session key to applications that understand they are getting a
Kerberos session key and presumably can be audited to make sure they
use that key in a manner that will not break the security of the
ticket.  I'm happy with a similar facility that gives applications an
NTLM key labeled as an NTLM key.  I even believe we might come up with
a set of security practices for a Windows SSPI session key that NTLM
and Kerberos session keys both meet and release keys to applications
in that context.  I don't want to do that work--writing up the
security practices for use of that key--in a vacuum.  I'd rather be
talking to consumers.  In the interests of minimizing my work, I'd
even rather specify a set of acceptable uses sufficient for the needs
of the consumers rather than specify a set of constraints.

--Sam