[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?


>> +#ifdef KV5M_ALT_METHOD
>>  				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

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...


-- Luke

Luke Howard | PADL Software Pty Ltd | www.padl.com

More information about the samba-technical mailing list