Session key extraction

Sam Hartman hartmans at MIT.EDU
Tue Dec 23 09:47:16 EST 2008


>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:

    Jeffrey> My opinion is as follows: regardless of whether you think
    Jeffrey> its a good idea or a bad idea, there are protocols that
    Jeffrey> Microsoft implemented that are widely deployed and for
    Jeffrey> which it is impossible to implement the security
    Jeffrey> solutions that Microsoft developed as a incrementally
    Jeffrey> better idea than what came previously.

Completely agreed.

    Jeffrey> In order to implement this class of protocols it is
    Jeffrey> necessary that the session key be exported after gss
    Jeffrey> session establishment.

Completely agreed.

    Jeffrey> The protocols are now publicly documented by Microsoft on
    Jeffrey> their developers web site.  In order for the Consortium's
    Jeffrey> distribution to be used out of the box by third parties
    Jeffrey> to implement these protocols they need this
    Jeffrey> functionality.  That isn't to say that it should not come
    Jeffrey> with a note perhaps indicating that the functionality is
    Jeffrey> only for Microsoft compatibility and should not be used
    Jeffrey> when designing any new protocols.

Completely agreed.

    Jeffrey> I do not believe that it would be wise to restrict the
    Jeffrey> usage to only Microsoft implemented key types.  It is
    Jeffrey> impossible to say what might be implemented in the
    Jeffrey> future.

I'm not sure how I feel about this.

    Jeffrey> I believe the functionality should be provided.

I mostly agree with you here.  I believe that we should work with
people who have plans to implement these protocols with our code base
and come up with a mutually acceptable interface.  For example I
prefer a Kerberos-specific interface to a GSS mechanism-independent
interface.  I think wemay want an interface that can be shared by an
NTLM mechanism.

I think that discussion is far easier if held with someone doing
actual implementation than held in a vacuum beforehand.



--Sam



More information about the krbdev mailing list