s3-rpc: Decrypt with the proper session key in CreateTrustedDomainEx2.

[Alexander Bokovoy]

On Tue, Mar 13, 2012 at 22:53, Andrew Bartlett <abartlet at samba.org> wrote:
> On Tue, 2012-03-13 at 11:28 -0700, Jeremy Allison wrote:
>> On Tue, Mar 13, 2012 at 12:24:03PM +0100, Andreas Schneider wrote:
>> > The branch, master has been updated
>> >        via  7d4ed89 s3-rpc: Decrypt with the proper session key in CreateTrustedDomainEx2.
>> >       from  e25f830 selftest: samba3.smbtorture_s3.LOCAL-TALLOC-DICT works now
>> >
>> > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
>> >
>> >
>> > - Log -----------------------------------------------------------------
>> > commit 7d4ed899831a853ec2eef8dcd82d74fdbf568f0e
>> > Author: Alexander Bokovoy <ab at samba.org>
>> > Date:   Fri Mar 2 16:18:16 2012 +0200
>> >
>> >     s3-rpc: Decrypt with the proper session key in CreateTrustedDomainEx2.
>> >
>> >     On LSA and SAMR pipes session_key is truncated to 16 byte when doing encryption/decryption.
>> >     However, this was not done for trusted domain-related modifying operations.
>> >
>> >     As result, Samba 4 client libraries do not work against Samba 3 while working
>> >     against Windows 2008 r2.
>> >
>> >     Solved this by introducing "session_extract_session_key()" function that allows to specify
>> >     intent of use of the key.
>> >
>> >     Signed-off-by: Andreas Schneider <asn at samba.org>
>> >
>> >     Autobuild-User: Andreas Schneider <asn at cryptomilk.org>
>> >     Autobuild-Date: Tue Mar 13 12:23:44 CET 2012 on sn-devel-104
>>
>> I think this one needs to be in 3.6.x also.
>
> It shouldn't be needed.  My understanding is that this came up as a
> side-effect of the change to use real GSSAPI.  When we use real GSSAPI,
> we have the chance to negotiate an improved security cipher during the
> exchange, and so while we only store arcfour-hmac-md5 keys with the KDC,
> we can get an AES session key (which is > 16 bytes long).
That's one part, yes. In this case samba4 client was always using 16
byte long part of the session key and Samba3 server never bothered to
cut what it has provided as a session key to the client. This was
triggered by explicitly using GSSAPI authentication between samba4
client and samba3 server.

> What happened apparently is that our session key, SAMR and LSA
> testsuites didn't cover the right kerberos-enabled environments (indeed,
> we may need to add a FreeIPA-mode environment).  I'll work with Andreas
> to run those existing tests against these additional environments
> shortly.
My current FreeIPA v3 tree that exhibits this behavior is at
http://fedorapeople.org/gitweb?p=abbra/public_git/freeipa.git;a=shortlog;h=refs/heads/adwork.
I'm not sure whether it would be possible to add an autobuild based on
that environment but we can at least have a build farm host that
explicitly tests such setup.
-- 
/ Alexander Bokovoy