ipmi password storage

[Joel Stanley]

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.

> 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+.