After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Weijun Wang
Hi Greg

Now that RFC 8429 is published and 3DES and RC4 are deprecated, is there any plan to remove them from etype list of KDC-REQ?

Maybe they will be covered by "allow_weak_crypto"?

Thanks
Max


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Greg Hudson
On 11/01/2018 10:30 AM, Weijun Wang wrote:
> Now that RFC 8429 is published and 3DES and RC4 are deprecated, is there any plan to remove them from etype list of KDC-REQ?

For RC4, I would like Microsoft to take the lead.  3DES is our
responsibility, and is probably not in nearly as much use (although I'd
have to at least check if we're still using it internally at MIT), so it
is probably not as painful to deprecate.

There is some ambiguity in how weak an enctype needs to be to qualify
for being affected by allow_weak_crypto.  The primary concerns about
des3-cbc-sha1 are its 64-bit block size and the fast speed of its
string-to-key operation; both of these are far less problematic than the
practical ability to recover a random single-DES key.  It would also be
a shame if administrators wound up enabling DES in order to make DES3
work (or RC4).
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Derek Atkins-2
Greg Hudson <[hidden email]> writes:

> On 11/01/2018 10:30 AM, Weijun Wang wrote:
>> Now that RFC 8429 is published and 3DES and RC4 are deprecated, is
>> there any plan to remove them from etype list of KDC-REQ?
>
> For RC4, I would like Microsoft to take the lead.  3DES is our
> responsibility, and is probably not in nearly as much use (although I'd
> have to at least check if we're still using it internally at MIT), so it
> is probably not as painful to deprecate.
>
> There is some ambiguity in how weak an enctype needs to be to qualify
> for being affected by allow_weak_crypto.  The primary concerns about
> des3-cbc-sha1 are its 64-bit block size and the fast speed of its
> string-to-key operation; both of these are far less problematic than the
> practical ability to recover a random single-DES key.  It would also be
> a shame if administrators wound up enabling DES in order to make DES3
> work (or RC4).

Maybe we need an "allow_very_weak_crypto" in addition to the
"allow_weak_crypto"?

> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

-derek

--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Benjamin Kaduk-2
On Mon, Nov 05, 2018 at 10:57:50AM -0500, Derek Atkins wrote:

> Greg Hudson <[hidden email]> writes:
>
> > On 11/01/2018 10:30 AM, Weijun Wang wrote:
> >> Now that RFC 8429 is published and 3DES and RC4 are deprecated, is
> >> there any plan to remove them from etype list of KDC-REQ?
> >
> > For RC4, I would like Microsoft to take the lead.  3DES is our
> > responsibility, and is probably not in nearly as much use (although I'd
> > have to at least check if we're still using it internally at MIT), so it
> > is probably not as painful to deprecate.
> >
> > There is some ambiguity in how weak an enctype needs to be to qualify
> > for being affected by allow_weak_crypto.  The primary concerns about
> > des3-cbc-sha1 are its 64-bit block size and the fast speed of its
> > string-to-key operation; both of these are far less problematic than the
> > practical ability to recover a random single-DES key.  It would also be
> > a shame if administrators wound up enabling DES in order to make DES3
> > work (or RC4).
>
> Maybe we need an "allow_very_weak_crypto" in addition to the
> "allow_weak_crypto"?

Perhaps ... though what is keeping us from biting the bullet and just not
exposing single-DES at all (forcing sites that need it to stay on an old
software branch)?

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Simo Sorce-3
On Mon, 2018-11-05 at 10:04 -0600, Benjamin Kaduk wrote:

> On Mon, Nov 05, 2018 at 10:57:50AM -0500, Derek Atkins wrote:
> > Greg Hudson <[hidden email]> writes:
> >
> > > On 11/01/2018 10:30 AM, Weijun Wang wrote:
> > > > Now that RFC 8429 is published and 3DES and RC4 are deprecated, is
> > > > there any plan to remove them from etype list of KDC-REQ?
> > >
> > > For RC4, I would like Microsoft to take the lead.  3DES is our
> > > responsibility, and is probably not in nearly as much use (although I'd
> > > have to at least check if we're still using it internally at MIT), so it
> > > is probably not as painful to deprecate.
> > >
> > > There is some ambiguity in how weak an enctype needs to be to qualify
> > > for being affected by allow_weak_crypto.  The primary concerns about
> > > des3-cbc-sha1 are its 64-bit block size and the fast speed of its
> > > string-to-key operation; both of these are far less problematic than the
> > > practical ability to recover a random single-DES key.  It would also be
> > > a shame if administrators wound up enabling DES in order to make DES3
> > > work (or RC4).
> >
> > Maybe we need an "allow_very_weak_crypto" in addition to the
> > "allow_weak_crypto"?
>
> Perhaps ... though what is keeping us from biting the bullet and just not
> exposing single-DES at all (forcing sites that need it to stay on an old
> software branch)?

This or we turn allow_weak_crypto from a boolean to a list of weak
algos you want to re-enable with the value "true" turned to a default
list.

In general DES is something we should really drop for default builds
going forward, just like MD5, I do not think it is right for the
majority of people to be made so vulnerable just for a few holdouts.

Holdouts can simply recompile their library and add back all the broken
crypto they want, until we drop the code completely, at which point
they can add downstream patches if they really insist using a bleeding
edge release with ancient crypto (what's the point ?).

Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos

Robbie Harwood
In reply to this post by Benjamin Kaduk-2
Benjamin Kaduk <[hidden email]> writes:

> On Mon, Nov 05, 2018 at 10:57:50AM -0500, Derek Atkins wrote:
>> Greg Hudson <[hidden email]> writes:
>>> On 11/01/2018 10:30 AM, Weijun Wang wrote:
>>>
>>>> Now that RFC 8429 is published and 3DES and RC4 are deprecated, is
>>>> there any plan to remove them from etype list of KDC-REQ?
>>>
>>> For RC4, I would like Microsoft to take the lead.  3DES is our
>>> responsibility, and is probably not in nearly as much use (although
>>> I'd have to at least check if we're still using it internally at
>>> MIT), so it is probably not as painful to deprecate.
>>>
>>> There is some ambiguity in how weak an enctype needs to be to
>>> qualify for being affected by allow_weak_crypto.  The primary
>>> concerns about des3-cbc-sha1 are its 64-bit block size and the fast
>>> speed of its string-to-key operation; both of these are far less
>>> problematic than the practical ability to recover a random
>>> single-DES key.  It would also be a shame if administrators wound up
>>> enabling DES in order to make DES3 work (or RC4).
>>
>> Maybe we need an "allow_very_weak_crypto" in addition to the
>> "allow_weak_crypto"?
>
> Perhaps ... though what is keeping us from biting the bullet and just
> not exposing single-DES at all (forcing sites that need it to stay on
> an old software branch)?
I've started some of this work, but haven't looked at it in a while.
Among other things, srvtab and krb4 support need to go.  I don't think
there should be any attachment to any of its dependencies of course,
just that it is more to do.

I would be very happy to see the single-DES code removed.

Thanks,
--Robbie

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (847 bytes) Download Attachment