Here is a long explanation of this problem. The TL;DR is, IMHO, disabling IPMI cipher suite privilege levels is extremely dangerous and can potentially disable access to the BMC’s IPMI interface completely, and additionally does not secure the BMC.
Details:
While only the Lenovo BMC engineers know exactly why the BMC behaves the way it does, this may be a result of misinterpretation of the IPMI spec.
References are to the latest version “IPMI v2.0, rev. 1.1 markup for Errata 7, April 21, 2015”
The relevant part of the spec to this issue is Table 23-4, LAN Configuration parameters. The important parameters are #23 (“RMCP+ Messaging Cipher Suite Entries”) and #24 (“Messaging Cipher Suite Privilege Levels”). Parameter 23 returns an array of cipher suite IDs that the channel supports, from 0-16 supported cipher suite ids. Parameter 24 allows getting, or setting, the mask of the maximum privilege level allowed for each cipher suite.
The Lenovo BMC engineers may have interpreted the parameter 24 mask as corresponding to the array of cipher suite IDs provided by parameter 23. That’s certainly a fair interpretation, and it makes sense. Unfortunately, that isn’t the interpretation of some other BMC manufacturers, and is not the way the mask is handled by both the ipmitool and freeipmi-tools utilities. Instead, the interpretation is that the mask applies to the cipher suite ID numbers. To be fair to the original BMC implementors, the first IPMI v2 spec only defined 15 cipher suite IDs, so the mask size covered all possible currently-existing cipher suites.
This is most simply demonstrated with the ipmitool ‘lan print’ command, as well as the ‘lan set cipher_privs’ command. The ‘lan set cipher_privs’ command allows setting the mask, and
the ‘lan print’ command prints the output of all lan configuration params, including 23 and 24, e.g.:
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXXXXXXXX
In that example, depending on the interpretation of the IPMI spec, either cipher suite 3 or 6 might be enabled for administrator access; if one interprets the mask as indexing the array of supported suites, the mask has cipher suite 6 enabled, while if one interprets the mask as referencing cipher suites by id number, the mask has suite 3 enabled.
This example comes from a Supermicro box, and their interpretation is that the mask shown enables cipher suite 3, not 6.
Unfortunately (or maybe fortunately), some BMC implementors seem to have chosen the simple approach of simply listing all defined cipher suites in order, so there is no difference between the “RMCP+ Cipher Suites” array and the list of defined suites, e.g.:
In that case, there is no ambiguity; the spec can be interpreted either way, and the result is the same. This is the case for several systems I tested:
Lenovo/IBM System x3650 M5
RMCP+ Cipher Suites : 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
There are also some bizarre system in our lab:
This system allows access only using cipher suites 0-3, and no others, with the current config:
Lenovo ThinkServer RD240 (with mainboard Tyan Tank GT20):
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12,0,0,0,0,0,0,0,0
Cipher Suite Priv Max : XXXaXXXXaXXXaXX
This one only allows access with cipher suites 2 and 3 (not 1 or 4) with the current config:
Lenovo System x3650 M2
RMCP+ Cipher Suites : 1,2,3,4
Cipher Suite Priv Max : XaaaXXXXXXXXXXX
Turning to the IPMI tooling code, as mentioned above, both the ipmitool and freeipmi code takes the suite-id interpretation, meaning the mask does not correspond to the list of supported suites.
So, there is no “safe” way to tell if disabling/enabling any specific cipher suite on any random box’s IPMI will actually do what you want. The closest thing to “safe” is likely to test the applied config from the local machine during enlistment/comissioning to verify that the applied mask correctly allows access using the desired suite(s).
Additionally, disabling the cipher suites makes no difference if no tool actually was using those suites; by default, ipmitool and freeipmi use cipher suite 3, which is secure (or at least “secure” in terms of the IPMI spec).
Also, the BMC also can be “insecure” in other ways; e.g. if telnet access is enabled, or if IPMI v1.5 access enabled (at best, this is as secure as the least secure IPMI v2 cipher suites), or if HTTP is used to access the BMC web GUI.
Finally, there is no way for maas to know if anything else was actually using any of the cipher suite(s) that maas disables. Some maas users might have their BMC network secured, and need (for whatever reason) to use a cipher suite other than 3, 8, 12, or 17; if maas disables all suites besides those, this may break existing external applications.
Here is a long explanation of this problem. The TL;DR is, IMHO, disabling IPMI cipher suite privilege levels is extremely dangerous and can potentially disable access to the BMC’s IPMI interface completely, and additionally does not secure the BMC.
Details:
While only the Lenovo BMC engineers know exactly why the BMC behaves the way it does, this may be a result of misinterpretation of the IPMI spec.
The ipmi spec is available at: /www.intel. com/content/ www/us/ en/servers/ ipmi/ipmi- technical- resources. html
https:/
References are to the latest version “IPMI v2.0, rev. 1.1 markup for Errata 7, April 21, 2015”
The relevant part of the spec to this issue is Table 23-4, LAN Configuration parameters. The important parameters are #23 (“RMCP+ Messaging Cipher Suite Entries”) and #24 (“Messaging Cipher Suite Privilege Levels”). Parameter 23 returns an array of cipher suite IDs that the channel supports, from 0-16 supported cipher suite ids. Parameter 24 allows getting, or setting, the mask of the maximum privilege level allowed for each cipher suite.
The Lenovo BMC engineers may have interpreted the parameter 24 mask as corresponding to the array of cipher suite IDs provided by parameter 23. That’s certainly a fair interpretation, and it makes sense. Unfortunately, that isn’t the interpretation of some other BMC manufacturers, and is not the way the mask is handled by both the ipmitool and freeipmi-tools utilities. Instead, the interpretation is that the mask applies to the cipher suite ID numbers. To be fair to the original BMC implementors, the first IPMI v2 spec only defined 15 cipher suite IDs, so the mask size covered all possible currently-existing cipher suites.
This is most simply demonstrated with the ipmitool ‘lan print’ command, as well as the ‘lan set cipher_privs’ command. The ‘lan set cipher_privs’ command allows setting the mask, and
the ‘lan print’ command prints the output of all lan configuration params, including 23 and 24, e.g.:
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXXXXXXXX
In that example, depending on the interpretation of the IPMI spec, either cipher suite 3 or 6 might be enabled for administrator access; if one interprets the mask as indexing the array of supported suites, the mask has cipher suite 6 enabled, while if one interprets the mask as referencing cipher suites by id number, the mask has suite 3 enabled.
This example comes from a Supermicro box, and their interpretation is that the mask shown enables cipher suite 3, not 6.
Unfortunately (or maybe fortunately), some BMC implementors seem to have chosen the simple approach of simply listing all defined cipher suites in order, so there is no difference between the “RMCP+ Cipher Suites” array and the list of defined suites, e.g.:
RMCP+ Cipher Suites : 0,1,2,3, 4,5,6,7, 8,9,10, 11,12,13, 14
In that case, there is no ambiguity; the spec can be interpreted either way, and the result is the same. This is the case for several systems I tested:
Dell PowerEdge R730xd 4,5,6,7, 8,9,10, 11,12,13, 14
Dell PowerEdge T610
RMCP+ Cipher Suites : 0,1,2,3,
HP ProLiant SL390s G7
HP ProLiant DL360e Gen8
HP ProLiant DL360 Gen9
HP ProLiant DL380 Gen10
RMCP+ Cipher Suites : 0,1,2,3
Cisco UCSC-C220-M3L 4,5,6,7, 8,9,10, 11,12,13, 14,128
RMCP+ Cipher Suites : 0,1,2,3,
However, here are systems which don’t take that approach, and clearly do take the “traditional” interpretation of the format of parameter 24:
Supermicro Power9
Supermicro Super Server
Supermicro X8DTH
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXaXXXaXX
Quanta S910-X31E
RMCP+ Cipher Suites : 0,1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXaXXXaXX
But, there are systems which take the opposite interpretation, which causes the problem in this bug:
Fujitsu PRIMERGY RX1330 M4 6,7,8,11, 12,15,16, 17
Fujitsu PRIMERGY RX2530 M5
Fujitsu PRIMERGY RX2540 M5
RMCP+ Cipher Suites : 0,1,2,3,
Cipher Suite Priv Max : XaaaaaaaaaaaXXX
Lenovo/IBM System x3650 M5 5,6,7,8, 9,10,11, 12,13,14, 15,16
RMCP+ Cipher Suites : 1,2,3,4,
There are also some bizarre system in our lab:
This system allows access only using cipher suites 0-3, and no others, with the current config:
Lenovo ThinkServer RD240 (with mainboard Tyan Tank GT20): 7,8,11, 12,0,0, 0,0,0,0, 0,0
RMCP+ Cipher Suites : 1,2,3,6,
Cipher Suite Priv Max : XXXaXXXXaXXXaXX
This one only allows access with cipher suites 2 and 3 (not 1 or 4) with the current config:
Lenovo System x3650 M2
RMCP+ Cipher Suites : 1,2,3,4
Cipher Suite Priv Max : XaaaXXXXXXXXXXX
Turning to the IPMI tooling code, as mentioned above, both the ipmitool and freeipmi code takes the suite-id interpretation, meaning the mask does not correspond to the list of supported suites.
The ipmitool code to get and print the mask can be seen here: /github. com/ipmitool/ ipmitool/ blob/master/ lib/ipmi_ lanp.c# L847 /github. com/ipmitool/ ipmitool/ blob/master/ lib/ipmi_ lanp.c# L1159
https:/
And set the mask here:
https:/
Note that ipmitool’s code does not appear to have been updated since the initial IPMI v2.0 spec release; it doesn’t support cipher suites over 15.
The freeipmi code even has a helpful comment to clarify the parameter 24 mask does not map to the supported ciphers array: git.savannah. gnu.org/ cgit/freeipmi. git/tree/ ipmi-config/ ipmi-config- category- core-rmcpplus- conf-privilege- section. c#n352
http://
And you can check the code to see it does use the cipher suite id, not index into the supported suite array: git.savannah. gnu.org/ cgit/freeipmi. git/tree/ ipmi-config/ ipmi-config- category- core-rmcpplus- conf-privilege- section. c#n429
http://
The fact that both tools interpret the specification this way is trivially checkable:
ddstreet@thorin:~$ ipmi-config -u ADMIN -p $PW -D LAN_2_0 -h dwalin.bmc --checkout -S Rmcpplus_ Conf_Privilege | grep Maximum_ Privilege_ Cipher_ Suite_Id Privilege_ Cipher_ Suite_Id_ 1 Unused Privilege_ Cipher_ Suite_Id_ 2 Unused Privilege_ Cipher_ Suite_Id_ 3 Administrator Privilege_ Cipher_ Suite_Id_ 6 Unused Privilege_ Cipher_ Suite_Id_ 7 Unused Privilege_ Cipher_ Suite_Id_ 8 Unused Privilege_ Cipher_ Suite_Id_ 11 Unused Privilege_ Cipher_ Suite_Id_ 12 Unused
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan print | grep 'Cipher Suite.*:'
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXXXXXXXX
ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan set 1 cipher_privs XXXaXXXXXXXXaXX Conf_Privilege | grep Maximum_ Privilege_ Cipher_ Suite_Id Privilege_ Cipher_ Suite_Id_ 1 Unused Privilege_ Cipher_ Suite_Id_ 2 Unused Privilege_ Cipher_ Suite_Id_ 3 Administrator Privilege_ Cipher_ Suite_Id_ 6 Unused Privilege_ Cipher_ Suite_Id_ 7 Unused Privilege_ Cipher_ Suite_Id_ 8 Unused Privilege_ Cipher_ Suite_Id_ 11 Unused Privilege_ Cipher_ Suite_Id_ 12 Administrator
ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan print | grep 'Cipher Suite.*:'
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXXXXXaXX
ddstreet@thorin:~$ ipmi-config -u ADMIN -p $PW -D LAN_2_0 -h dwalin.bmc --checkout -S Rmcpplus_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
Maximum_
ddstreet@thorin:~$ ipmi-config -u ADMIN -p $PW -D LAN_2_0 -h dwalin.bmc --commit -e Rmcpplus_ Conf_Privilege: Maximum_ Privilege_ Cipher_ Suite_Id_ 8=Administrator
ddstreet@thorin:~$ ipmitool -U ADMIN -P $PW -I lanplus -H dwalin.bmc lan print | grep 'Cipher Suite.*:'
RMCP+ Cipher Suites : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max : XXXaXXXXaXXXaXX
So, there is no “safe” way to tell if disabling/enabling any specific cipher suite on any random box’s IPMI will actually do what you want. The closest thing to “safe” is likely to test the applied config from the local machine during enlistment/ comissioning to verify that the applied mask correctly allows access using the desired suite(s).
Additionally, disabling the cipher suites makes no difference if no tool actually was using those suites; by default, ipmitool and freeipmi use cipher suite 3, which is secure (or at least “secure” in terms of the IPMI spec).
Also, the BMC also can be “insecure” in other ways; e.g. if telnet access is enabled, or if IPMI v1.5 access enabled (at best, this is as secure as the least secure IPMI v2 cipher suites), or if HTTP is used to access the BMC web GUI.
Finally, there is no way for maas to know if anything else was actually using any of the cipher suite(s) that maas disables. Some maas users might have their BMC network secured, and need (for whatever reason) to use a cipher suite other than 3, 8, 12, or 17; if maas disables all suites besides those, this may break existing external applications.