[PATCH] Mutual authentication, keytabs, and SMB session keys
Luke Howard
lukeh at PADL.COM
Mon Feb 24 01:31:50 GMT 2003
Hi Andrew,
>Given the non-invasive nature of this patch, I'll add it without the
>#ifdef. Would it be possible for you to add 'write' support to this?
>(Changing the password and storing it into that keytab).
Shouldn't be too hard: note, though, we don't store the cleartext password
in the keytab (although that would be possible by defining a new enctype)
so it may only be useful in a limited set of circumstances.
>Any chance we can implement this in our client code? This would
>certainly help in testing.
Do you mean "any chance I can implement this in our client code?" :-) I
could certainly take a look; in the mean time, I would expect that it
would ignore the AP_REP (given that Windows 2000 appears to always do
mutual authentication on SMB).
>Have you looked at SMB signing with this key? Or how SMB signing is
>done on a kerberos connection?
No. I expect SMB signing uses GSS_Wrap() and GSS_Unwrap(). This need not
necessarily use an RC4 key, but the "SMB session key" (for want of a
better phrase) must be an RC4 key.
>> Caveats: I haven't tested for MIT compat (although I have tried to avoid
>> any obvious breakage), and because ENCTYPE_ARCFOUR_HMAC_MD5 is an enum
>> in Heimdal, it should really be tested for in configure...
>
>Yes - can you knock up such a test?
OK.
>> +#ifdef KV5M_ALT_METHOD
>> case KRB5_KPASSWD_INITIAL_FLAG_NEEDED:
>> return KRB5KDC_ERR_BADOPTION;
>> /* return KV5M_ALT_METHOD; MIT-only define */
>> break;
>> +#endif
>
>I'm not quite sure what you are doing here...
KV5M_ALT_METHOD was not defined for Heimdal but, I see, you've noticed that
too, I hadn't updated the patch :-)
>Firstly - can we have a configure test for the Heimdal name. Secondly -
>why is this restricted to the type 23 key? If we do a login without a
>type 23 key, why can't we use some other session key? Or will the
>client indicate what session key to use?
The ticket includes a session key. The ticket session key may be used as
the SMB session key for encrypting passwords in SamrSetInformationUser(),
for example.
>Secondly, I'm not quite sure why this isn't in kerberos_verify.c? Or if
>we can also use this client-side, can you add that? It would greatly
>assist in testing...
I put it in clikrb5.c for portability; didn't want to put tests for MIT
or Heimdal specific functionality in kerberos_verify.c
>This needs to be 'False', as FALSE isn't a portable define.
Ouch, I always forget that.
>Doesn't the kerberos deal with the byte order? Or shouldn't we create a
>asn1_write function to do this?
The token ID is not ASN.1. Read RFC 1964.
>Can we have a name for this magic number? A define in asn_1.h or
>similar?
Again, see RFC 1964. Actually, they probably shouldn't be little-
endian shorts; my bad (but they certainly weren't ASN.1 booleans! :-))
Better to do:
#define TOK_ID_KRB_AP_REQ "\x01\x00"
#define TOK_ID_KRB_AP_REP "\x02\x00"
I'll knock up another patch later today...
cheers,
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
More information about the samba-technical
mailing list