ipmi password storage

Vernon Mauery vernon.mauery at linux.intel.com
Tue Apr 21 00:29:42 AEST 2020


On 16-Apr-2020 06:04 AM, Joel Stanley wrote:
>On Tue, 14 Apr 2020 at 22:43, Vernon Mauery
><vernon.mauery at linux.intel.com> wrote:
>>
>> On 14-Apr-2020 05:03 PM, Joseph Reynolds wrote:
>> >
>> >
>> >On 4/14/20 11:46 AM, Vernon Mauery wrote:
>> >>On 14-Apr-2020 10:50 AM, Patrick Williams wrote:
>> >>>On Mon, Apr 13, 2020 at 04:00:15PM -0700, Vernon Mauery wrote:
>> >>>
>> >>>Vernon,
>> >>>
>> >>>Is there some background pointers on why IPMI needs to store passwords
>> >>>in a reverable way?  I never understood that.
>> >>
>> >>Sure. I think this is most clearly described in section 13.31 "RMCP+
>> >>Authenticated Key-Exchange Protocol (RAKP)" in the IPMI v2 1.1 spec.
>> >
>> >This may be a bit naive....  Is it possible to expand the RCMP+ spec
>> >with a new cipher suite or similar, to use a mechanism more like HTTPS
>> >or SSH that does not require the server to be able to produce a clear
>> >text password?  Given that IPMI will be used for many years, this
>> >seems worthwhile, and would solve the current problem.
>>
>> While IPMI will not likely be abandoned for many years to come, there
>> are not any plans to update the specification. Redfish is supposed to be
>> the answer, but like IPv4 was supposed to be supplanted by IPv6 long
>> ago, full adoption is still dragging its feet.
>>
>> That being said, I am not opposed to creating a new de-facto standard.
>> In the name of security, I would not be opposed to using modern crypto
>> protocols to establish secure IPMI sessions. This would likely cause the
>> adoption of redfish to be even slower, because the biggest detractor of
>> IPMI would be fixed.
>
>This is a great suggestion.

Thanks! Here is a design doc I wrote up.
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548

--Vernon

>> We have the maintainer of ipmitool as a member of the OpenBMC community,
>> (Alexander Amelkin) so we could even implement both ends of this new
>> de-facto standard. I would suggest a DTLS connection on UDP 623, fully
>> replacing RCMP+.


More information about the openbmc mailing list