[releng] Issue #8012: Self-contained change proposal: krb5 crypto modernization

[Robbie Harwood]

rharwood reported a new issue against the project: `releng` that you are following:
``
* Describe the issue

Mandatory check with rel-eng is required for Fedora 30 change proposal [krb5 crypto
modernization](https://fedoraproject.org/wiki/Changes/krb5_crypto_moderni....  I
don't expect any impact, but that's why we do these checks.

* When do you need this? (YYYY/MM/DD)

Change submission deadline is 2019-01-29 for self-contained changes

* When is this no longer needed or useful? (YYYY/MM/DD)

Beta freeze is 2019-03-05, but I think it really should be done before the submission
deadline of 2019-01-29.

* If we cannot complete your request, what is the impact?

I'm not actually sure and policy doesn't really say.  I think it goes forward
anyway without your input?  Maybe it doesn't get accepted?  Hopefully this isn't
an issue.

``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012

[Raphael Groner]

raphgro added a new comment to an issue you are following:
``
Although not sure if it's the right place to discuss contents of the wiki page, can
you please drop the following sentence?

" It's now so bad that it can be entirely broken in 13 hours for $300:
<link>"

We shouldn't advertise any commercial service (here especially from 3rd party) to
crack others' belongings.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012

[Jeffrey Altman]

jaltman added a new comment to an issue you are following:
``
The risk from using weak encryption types for session keys is very different than the risk
from use for long-term secrets whether client principals or service principals.   Cracking
of the long-term secrets is what
http://www.openafs.org/pages/security/OPENAFS-SA-2013-003.txt addressed.  Weak encryption
type long term secrets are at significant risk because they often remain unchanged for
months if not years; and might co-exist with stronger encryption type secrets derived from
the same password.  

Weak session keys on the other hand have a much shorter lifespan and pose a much smaller
risk.   Not for lack of effort but there are many organizations that still have not purged
their Kerberos realms of DES and 3DES keys.  Not to mention the many AFS cells that have
yet to upgrade all servers to OpenAFS 1.6.6 or later OR AuriStorFS and as a result are not
capable of using AES256-CTS-HMAC-SHA1-96 encryption types for long term secrets.  OpenAFS
does not support AES256-CTS-HMAC-SHA512-384 at all.    Even when the long term secrets for
service principals have been upgraded to strong encryption types, the application
protocols might still require a DES key.  OpenAFS 1.6.6 or later and AuriStorFS do support
https://tools.ietf.org/id/draft-kaduk-afs3-rxkad-k5-kdf-00.html but there are still many
deployed clients in the world that do not.  Sites are likely to be reluctant to cut off
these older clients just so they can say they are DES free when the AFS rxkad security
class is going to derive a 56-bit DES compatible key for use with fcrypt no matter what. 
It is for this reason that Heimdal Kerberos decided that even if DES was disabled it would
still permit the generation of DES encryption types for session keys. 

Similar issues are present for many Java Kerberos implementations and for protocols such
as telnet and ftp. 

Here are some other things to ponder when a KDC is upgraded to a version without DES /
3DES functionality:

1. How will a DES or 3DES long term master key for the KDB be replaced if there is no DES
and 3DES?

2. How will client and service principals that only have DES and/or 3DES keys behave? 

3. How will an end user whose client principal has only DES and/or 3DES change the
password if there is no DES and/or 3DES implementation?

It seems to me that it would be wiser to leave the DES implementation in place but to
disable the support for selection of weak keys for long term service principal secrets. 
Thereby ensuring that if a service principal has the ordered key list DES, 3DES, AES256
that the AES256 key will now be selected in preference to DES or 3DES.

It also seems to me that disabling DES and 3DES long term secrets for client principals
that have a stronger encryption type makes sense.

As well as treating any client principal that only has DES and/or 3DES long term secrets
as if the password had expired in order to force a password change which would as a result
generate a stronger encryption type secret.

Finally, I would leave the session key functionality alone.  

This set of changes is much less likely to leave end users in a no-win situation.


``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012

[Jeffrey Altman]

jaltman added a new comment to an issue you are following:
``
>  Although not sure if it's the right place to discuss contents of
> the wiki page, can you please drop the following sentence?
>  " It's now so bad that it can be entirely broken in 13 hours for $300:
> <link>"
>  We shouldn't advertise any commercial service (here especially from 3rd party) to
> crack others' belongings.
>  
While I appreciate the notion that a commercial service should not be advertised I believe
that it is important that reviewers understand the ease by which DES keys can be brute
forced.  This is especially true since the estimated time to brute force a Kerberos v5
service ticket encryption key was approximately 24 hours just five years ago. 

What I would like to see is a reference to where the 13 hours and $300 numbers came from.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012

[Robbie Harwood]

rharwood added a new comment to an issue you are following:
``
Hmm, I don't want to advertise (no affiliation with them, obviously) but I also do
want a citation - do you have a language suggestion?  I could also add a note like
"citation withheld so as not to advertise; ask rharwood if you need it"

@jaltman, the exact numbers come from their [price page](https://crack.sh/get-cracking/)
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012

[Mohan Boddu]

mohanboddu added a new comment to an issue you are following:
``
RelEng doesn't need to do any work for this change, but I will leave the ticket open
for the ongoing discussion.

Thanks for filing the ticket.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012

[Suzanne Yeghiayan]

The status of the issue: `Self-contained change proposal: krb5 crypto modernization` of
project: `releng` has been updated to: Closed as Fixed by syeghiay.

https://pagure.io/releng/issue/8012

[Suzanne Yeghiayan]

syeghiay added a new comment to an issue you are following:
``
Releng work is complete. Closing as fixed.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012