Supporting insecure protocols in RMCP+

[Vernon Mauery]

> Patch Set 4:
>
>> Given that RMCP+ is already insecure, unless it is a requirement to 
>> support 1, 2, 15, and 16, you may just want to support 3 and 17.
>
> 1,2,3 are marked as mandatory in the specification. It should be a 
> community decision to revoke support for 1,2. If the community is ok, 
> it will need additional code changes.

tl;dr IPMI is old; let's drop the most insecure parts

Opening this up to a wider audience. I would like some community 
consensus on how we should deal with parts of specifications that don't 
make sense anymore.

Tables in section 13.28:
(authentication algorithm support)
00h: RAKP-none        Mandatory (recommend dropping support)
01h: RAKP-HMAC-SHA1   Mandatory (good, but not best; keep for now)
02h: RAKP-HMAC-MD5    Optional (not implemented; do not implement)
03h: RAKP-HMAC-SHA256 Optional (implemented; best available)

(integrity algorithm support)
00h: none             Mandatory (recommend dropping support)
01h: HMAC-SHA1-96     Mandatory (good, but not best; keep for now)
02h: HMAC-MD5-128     Optional (not implemented; do not implement)
03h: MD5-128          Optional (not implemented; do not implement)
04h: HMAC-SHA256-128  Optional (implemented; best available)

(confidentiality algorithm support)
00h: none             Mandatory (recommend dropping support)
01h: AES-CBC-128      Mandatory (implemented; best available)
02h: xRC4-128         Optional (not implemented; do not implement)
03h: xRC4-40          Optional (not implemented; do not implement)

The IPMI spec was written in a time when computing resources were 
minimal and before some of the real security awareness started. And as 
such, it contains some legacy stuff that should really be dropped or at 
the very least deprecated.

The IPMI spec only says that we must implement certain authentication, 
integrity, and confidentiality algorithms, it does not explicitly say 
what cipher suites must be implemented. But, if we implement every 
cipher suite that is available with the required algorithms, we would 
implement cipher suites 0, 1, 2, and 3. And if we added in sha256 
integrity and authentication, we add in 15, 16, and 17.

Just for comparison, DCMI 1.5 requires only 3, with 17 as recommended 
and 8 as optional. This is a step up from IPMI's security 
recommendations, but still not best. I would say that 3 and 17 should be 
required, with the recommendation that 3 be deprecated (or disabled at 
runtime) in favor of 17 only.

I think we can all agree that cipher suite 0 is poison. It is a gaping 
open door with bright lights saying, "Hack me!" I would argue that 
cipher suites 1 and 2 are not much better. We have the computing 
resources to perform better security, so we should do it. As web 
browsers move along, they deprecate and then disable old versions of 
SSL/TLS. We should do the same. Just because at one point in history it 
was fine to authenticate with plaintext passwords, does not mean we 
should continue to do so. If you know better, do better.

Even if end users come to us and say that they MUST have cipher suite 1 
or 2, I would argue that we should tell them to update their 
infrastructure rather than re-implement old insecure protocols.


--Vernon