Bug 1489832

Summary:	[RFE] krb5kdc: should follow the policies of system-wide crypto policy
Product:	[Fedora] Fedora	Reporter:	Nikos Mavrogiannopoulos <nmavrogi>
Component:	krb5	Assignee:	Robbie Harwood <rharwood>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	rawhide	CC:	abokovoy, j, nalin, npmccallum, rharwood, sbose, ssorce
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-06 17:50:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1179209

Description Nikos Mavrogiannopoulos 2017-09-08 12:34:33 UTC

As it is now KDC configuration is hard coded and the administrator is responsible for doing any changes to it, and in case of software upgrades to keep up-to-date the list of ciphers allowed, parameters etc.

It would be simpler for KDC to follow the system-wide crypto policy [0] by default and unless the administrator changes the configuration the policies will be kept up to date and will be consistent with the policies followed in other parts of the system.

The simplest approach for that would be for Kerberos to be able to include a file in its default configuration files, and thus include a file which has been auto-generated.

That would also simplify an administrators job by not requiring to review configuration settings as recommended by: https://bettercrypto.org/static/applied-crypto-hardening.pdf

[This is a proposal for collaboration, please let me know whether that can be done in our current setup of kerberos and how, and if not the steps that are required to achieve that goal]

[0]. http://fedoraproject.org/wiki/Changes/CryptoPolicy

Comment 1 Robbie Harwood 2017-09-08 14:54:45 UTC

We've discussed this previously.  For completeness, here's what I said in that discussion (it's now out of date since we have sha2 ciphers, which are appropriately prioritized):

The two additional values I think we want to control are:                                                
                                                                                                         
- master_key_type                                                                                        
  Currently, this defaults to aes256-cts-hmac-sha1-96 which seems the                                    
  most reasonable, but it might be nice to put a config handle in for                                    
  this for futureproofing.                                                                               
                                                                                                         
- supported_enctypes                                                                                     
  This controls key/salt settings for realm principals.  Unfortunately                                   
  the default value includes arcfour/md5 and not camellia, so we want a                                  
  handle for this.  Based on what we're setting for permitted_enctypes,                                  
  I would guess we want this to be:                                                                      
  aes256-cts-hmac-sha1-96:normal camellia256-cts-cmac:normal aes128-cts-hmac-sha1-96:normal              
camellia128-cts-cmac:normal des3-cbc-sha1:normal                                                         
                                                                                                         
There's a problem here though.  Those are both set in the [realms]                                       
section, and the way that section works means that they're set on a                                      
per-realm basis.  So I don't see a way to control these from                                             
crypto-policies right now.                                                                               
                                                                                                         
This is not the end of the world.  master_key_type has a good default.                                   
Additionally, while the KDC may generate some keys we don't like as per                                  
its supported_enctypes, it won't actually use any of the enctypes not                                    
present in permitted_enctypes.  (Side note - settings for KDC/kadmin                                     
portions of krb5 can be found in both krb5.conf and kdc.conf.)                                           
                                                                                                         
Some significant refactoring would be needed to make default values                                      
(i.e., set outside of a specific realm) for these settings work.  We may                                 
undertake it at some point, but probably not in the near future.

Comment 2 Simo Sorce 2017-10-03 12:28:59 UTC

The reason we excluded camellia is that it caused issues in some configurations and it is generally redundant with AES.
So I would still keep camellia off by default, then add the sha2 variants of AES on top.
We also probably want to drop des3 ?

For the realm based section I think we can include the crypto policy file from there ?
It will be on admins to keep it right, but all we need is probably to add some comments in the kdc.conf/krb5.conf file to that effect.

Comment 3 Robbie Harwood 2017-10-03 15:13:57 UTC

(In reply to Simo Sorce from comment #2)
> For the realm based section I think we can include the crypto policy file
> from there ?
> It will be on admins to keep it right, but all we need is probably to add
> some comments in the kdc.conf/krb5.conf file to that effect.

File/directory includes (i.e., include/includedir) are top-level only in krb5 configuration.

Comment 4 Robbie Harwood 2017-10-06 17:50:38 UTC

Summary of mailing list discussion:

- The impact of hypothetically supporting this in the KDC would be low, since clients already have crypto-policies support for what ciphers they accept.

- Due to passwords not being stored on KDCs, we have no way to add new enctypes to a principal.  So for an existing installation, there is no *benefit* to adding new enctypes, since they can't be used, and we run the risk of locking some principals out entirely if all their enctypes are removed.

- A weaker impact of above: removing supported enctypes can break use in existing keytabs and ccaches.

- There is no way to apply crypto-policies to the KDC at the moment due to the way the configuration files are structured.

- Adjusting the format is a large undertaking, and upstream is not excited about doing this.

I understand that all of this is sub-optimal from the crypto-policies point of view.  However, something both we and upstream are keen on is wholesale removal of broken algorithms, starting with single-DES support.  Please file a bug if this something you think that should be prioritized.