On Wed, 2012-10-03 at 11:03 -0700, Chuck Lever wrote:
> On Oct 3, 2012, at 10:49 AM, Simo Sorce wrote:
> > On Wed, 2012-10-03 at 13:26 -0400, Steve Dickson wrote:
> >> Hello,
> >> 
> >> These issues were found at this Fall's Bake-a-ton... 
> >> 
> >> On 03/10/12 13:02, Chuck Lever wrote:
> >>> 
> >>> Free IPA does not support weak crypto
> >>>  https://bugzilla.linux-nfs.org/show_bug.cgi?id=229
> > 
> > DES support is disabled on purpose, IETF also has an RFC approved that
> > finally says DES *should* not be made available anymore.
> SHOULD NOT means the IETF acknowledges that there are still legitimate 
> reasons to allow des-crc-cbc in some cases.

Yes, that is why DES can still be re-enabled, but is off by default
(will eventually be purged completely from MIT libraries though, in due
time, but not in RHEL6/7 lifetime I think).

> > DES can be cracked in a matter of hours these days which makes its use
> > questionable.
> We know that des-crc-cbc is garbage, fwiw.  The point is there are
> plenty of legacy implementations that have to co-exist with Free IPA
> and with implementations that use only known-secure encryption types.

Yep, still we do not want to enable DES by default, we have docs for
that, see Rob's message.

> > DES can be re-enabled manually by twisting a bunch of knobs if you
> > really want to. (including enable weak crypto in krb5.conf)
> That wasn't enough for us, it was enabled on both the NFS server and
> client.  Yes, we could have been "doing it wrong." :-)
> We think backwards compatibility is one reason to continue to make the
> use of des-crc-cbc a first-class use case.

Sorry, it is simply a too big security liability this days to keep it as
a default. RHEL (starting with 6) and Fedora in general have DES support
disabled (the default for weak keys is 'false' in krb5.conf)
We do not want to prevent you from being able to enable it, but it
should be a conscious decision by the admins involved.

'Just works' in this case is a bad trade-off as it means 'We are broken
by default'.

> > So I would close as NOTABUG.
> > 
> >>> Confusing debugging output when configuring NFS over Kerberos 
> >>>  https://bugzilla.linux-nfs.org/show_bug.cgi?id=230
> > 
> > Not much we (FreeIPA) can do about this one. GSSAPI error codes can be
> > cryptic at time, but they are returned by libgssapi not FreeIPA.
> > Maybe you can add more meat to the debug on the rpc.svcgssd side by
> > printing out what principal you tried to use.
> > If you can identify for sure what causes the error we can open a bug
> > against MIT and see if there is a chance GSSAPI can properly identify
> > the error. Unfortunately it doesn't help that there are many abstraction
> > layers involved here and sometimes error messages get mangled/lost in
> > the process :-/ (Basically KDC errors -> krb5 protocol level error ->
> > libkrb5 level error -> libgssapi level error -> application)
> Agree, we are trying to document these issues by filing bugs like this one.

Note that I fully share your pain, we have the same problem in FreeIPA
at times, however the only way to make return messages more clear is to
attack them one by one by describing the situation and then hoping
GSSAPI/libkrb5/etc can be improved. Unfortunately in some cases the
libraries/protocol simply do not have enough information on the
'intentions' of the application to be able to give a better error

> Thanks for your comments.



Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to