Security with Samba 3.0 and Kerberos

[Love]

Andrew Bartlett <abartlet at samba.org> writes:

Andrew Bartlett <abartlet at samba.org> writes:

>> (In MIT) its in a file, its parsed when the process starts and then written
>> the file (and stored in a hash) for each requst. Each request checks the
>> hash before inserting the request.
>> 
>> So, in a forked architeture you'll have problems if the process can handle
>> multiple requests.
>
> Yes, Samba can authenticated multiple users in a single smbd process.  

So, to use the replycache toda you need to register your own reply
operations, however. The only way to make the (mit) gssapi lib use the
registered reply cache ops are by setting the environment varible
KRB5RCACHETYPE to the cache type. So see below.

>> You can register your own reply cache operations in the kerberos lib,
>> however this is undocumented.
>> 
>> Heimdal includes a reply-cache, but it disable by default.
>
> How do you suggest we best deal with this?

Make sure you are protecxted agiast reply attacks by setting using data
ouside the connection that changes for each connection that that data is
signed/integrity check by a key in the authenticator.

Really, just using the kerberos ticket/authenticator as just a password
probably gives you problems with MITM attacks.

> Well, with CIFS we can probably play a few games here - if we are
> worried about reply attacks on a *signed* connection, we just need to
> generate 'random' vuids and tids.

(I assumes at a signed connection somehow uses information from the
kerberos/gssapi exchange to when signed the connection)

So is there any unsigned connection that you really care about and use
gssapi/kerberos.

> The client has to reply them, and
> this should be sufficient to throw it off.  (This is only an issue with
> kerberos connections, because with NTLM they would not get the same
> challenge.  Or does the kerberos server authenticator already include
> this kind of value?  

Not really, that what you use the replay cache to (if you are broken
protocol). Most protocols use the key inside the authenticator/ticket to
verify that the client knows some data outside the connection that changes.

I really need make sure the reply cache is enabled in Heimdal and that
there are some (replay cache) types for forked architetures (that works in
MIT and heimdal).

I need to think more about this.

Love