Samba4: Some GENSEC questions

[tridge at samba.org]

Kai,

The person you really want to ask is Andrew Bartlett, but right now he
is hiking in Tasmania. If you can wait a couple of weeks then I'm sure
he'd be happy to help.

 > I'm unclear what should go into *whole_pdu. For my test I just put the
 > same stuff there as *data.

It isn't really my area of expertise, but as I understand it the
reason for the separation of those two fields is that some of the
signing algorithms sign based on the whole packet, including the
header, whereas the encrypted data doesn't cover the header. This is
how its used for DCERPC, where we call:

		status = gensec_seal_packet(c->security_state.generic_state, 
					    mem_ctx, 
					    blob->data + DCERPC_REQUEST_LENGTH, 
					    payload_length,
					    blob->data,
					    blob->length - 
					    c->security_state.auth_info->credentials.length,
					    &creds2);

and DCERPC_REQUEST_LENGTH is the header length. The header itself is
not encrypted as otherwise you wouldn't know how to decrypt it :-)

The signing (which is often combined with sealing) does need to cover
the whole packet to protect against tampering, so you need two data
pointers to tell gensec about the separate signing/sealing ranges.

 > The call to gensec_seal_packet() in my test fails with
 > NT_STATUS_INVALID_PARAMETER, from which I gather that the
 > gensec_have_feature(gensec_security, GENSEC_FEATURE_SEAL) test on
 > gensec.c line 782. I requested the feature when setting up the gensec,
 > but maybe it's at the wrong place.

Do you know that the other end of the link accepted the negotiation of
sealing? For example, if you are using NTLMSSP then you need to look
at what capability bits came back from the other end, and if they
included sealing. If you up the debug level a little the gensec logs
should tell you whats going on.

Cheers, Tridge