Session key extraction

[Luke Howard]

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

SMB uses it for SMB signing and application-layer encryption with RC4.  
DRS uses it for encrypting directory attributes with RC4 (with derived  
keys). See [MS-DRSR] 4.1.10.5.10, [MS-KILE] 3.1.1.2 and [MS-SMB]  
3.1.1.2.

>> 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:

I agree it's a bad idea but it is a requirement for Windows  
interoperability. Otherwise vendors will need to fork Kerberos (as  
Novell has done with DSfW), build their own GSS implementation (as  
Samba 3 has done) or use an alternative Kerberos distribution (as  
Samba 4 has done).

> 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?

Windows from memory uses the parity bits.

-- Luke