[Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created

[Tomas Babej]

On 09/11/2013 09:12 PM, Alexander Bokovoy wrote:
> On Wed, 11 Sep 2013, Simo Sorce wrote:
>> On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote:
>>> On Sat, 07 Sep 2013, Simo Sorce wrote:
>>> >On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote:
>>> >> On Sat, 07 Sep 2013, Simo Sorce wrote:
>>> >> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote:
>>> >> >> On Sat, 07 Sep 2013, Simo Sorce wrote:
>>> >> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote:
>>> >> >> >> +       enctypes = KERB_ENCTYPE_DES_CBC_CRC |
>>> >> >> >> + KERB_ENCTYPE_DES_CBC_MD5 |
>>> >> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 |
>>> >> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 |
>>> >> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96;
>>> >> >> >
>>> >> >> >Why are we hardcoding support for *DES* enctype, we disable 
>>> DES by
>>> >> >> >default and also Windows never uses it by default.
>>> >> >> This is actually a copy of the same statement from
>>> >> >> fill_pdb_trusted_domain().
>>> >> >>
>>> >> >> Should I remove it?
>>> >> >
>>> >> >Yes please remove DES types, is there any chance we can make 
>>> this list
>>> >> >configurable ? (not a hard requirement, only if ti is something 
>>> easy to
>>> >> >do, maybe as a further enhancement down the road).
>>> >> If you can point me to some place in cn=config or $SUFFIX that 
>>> could be
>>> >> read by cifs/fqdn on ipa-sam module init, I can look in fetching 
>>> that.
>>> >> But I suspect it is much harder to deduce exact list of supported 
>>> types.
>>> >
>>> >Look in:
>>> >cn=REALM.NAME,cn=kerberos,$SUFFIX
>>> >
>>> >there we have 2 lists:
>>> >krbDefaultEncSaltTypes  <- use this
>>> >krbSupportedEncSaltTypes
>>> >
>>> >in util/ipa_krb5.c we have then the funciton 
>>> parse_bval_key_sal_tuples()
>>> >that can covert strings to enctypes.
>>> >
>>> >> >> RC4 enctype will be the only one available for
>>> >> >> Windows 2003 trusts then...
>>> >> >
>>> >> >It's the only one 2003 enables by default anyway and the only 
>>> one that
>>> >> >we can use as DES is disabled on FreeIPA.
>>> >> Since admin could enable DES on FreeIPA manually, right now ipa-sam
>>> >> would allow using DES to Windows 2003. If we remove DES enctypes
>>> >> unconditionally, it would not be possible.
>>> >
>>> >If you look at the attributes I pointed you at above, then you have a
>>> >way to support DES by simply changing the defaults and restarting
>>> >FreeIPA.
>>> >
>>> >DES is dead anyway and not sufficiently secure for cross-realm keys
>>> >anymore, even if we do not support it at all I think we are just fine.
>>> Ok, attached three patches 0114-0116 is a new revision that 
>>> implements also
>>> fetching encryption types from the Kerberos configuration container.
>>>
>>> The patches depend on each other in that order.
>>>
>>
>> I think you should explictly add cn=<REALM.NAME> to the filter when
>> seraching the kerberos container in the 3rd patch.
>> But beyond that the patches look sane to me (I haven't tested them
>> though).
> I'm already searching on cn=<REALM.NAME>,cn=kerberos,$SUFFIX with a base
> scope so this is pretty tight, no need to expand the filter.
>
> (Simo agreed to this argument on IRC)
>

ACK

-- 
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org