svn commit: samba r21903 - in branches/SAMBA_3_0/source/libsmb: .

[Luke Howard]

Jeremy,

For NTLM, it sounds like you're doing effectively
what is done for DCE RPC in NTLMv2 (AEAD).

>For the krb5 case I'm just going to call into the 
>system provided gss_seal/gss_unseal entry points
>and let that level sort it out :-). So for the
>krb5 gss encryption case it'll probably only sign the
>payload, not the header as there's no way to
>tell gss to sign a different part of the packet
>than it seals.

Yes, this is why years ago I proposed gss_wrap variants
for AEAD:

http://www1.ietf.org/mail-archive/web/kitten/current/msg00024.html

But we'll probably never see this in standard Kerberos
distributions, and rolling your own encryption routines
is generally asking for trouble so, yes, I think you
don't have a choice here.

>But as we'll just drop the connection on detecting
>tampering anyway I don't see this as being too
>much of a problem.

An attacker could tamper with the header (a classic
example in the DCE RPC case is changing the opcode;
I don't know enough about the SMB PDU layout to know
what attacks are possible, but you may be providing
the user with a false sense of security if you only
integrity protect the payload).

Anyway, your hands are pretty much tied if you want to
use the deployed GSS-API. FWIW I haven't seen any
evidence that MS use AEAD in DCE RPC for Kerberos,
even though they do for NTLMv2.

BTW, I heard some murmurings about Vista just tunnelling
SMB in TLS but haven't confirmed it myself...

regards,

-- luke

--
www.padl.com | www.lukehoward.com