Session key extraction

[Tom Yu]

Luke Howard <lukeh at padl.com> writes:

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

Is this proposed API for session key extraction meant to be similar to
the SSPI QueryContextAttributes function with the
SECPKG_ATTR_SESSION_KEY attribute?  The implementation currently
committed to mskrb-integ returns a buffer with the raw bytes of the
session key.  This give the caller no information about the encryption
algorithm, which could cause problems.

Is there any plan to implement the equivalent of the
SECPKG_ATTR_KEY_INFO attribute, which in SSPI provides information
about the encryption algorithm associated with the context?  Having
this information gives callers at least a chance of using the session
key with the correct encryption algorithm.