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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to