Reading the paper, I had some thoughts: Overall, most of the concerns are less about the fundamentals of IPMI and more about the general state of service processors in general.
I think RAKP is a bit mischaracterized in the paper. AFAIK it is never about persistent key data, but about the transient privacy/integrity key agreement. In terms of persistent key management, you have to use the set user password and set security keys commands. Since the persistent keys are all shared secret based, bootstrap of those credentials must be done via some other mechanism. Commonly the presumption is some guy tediously keying it into the 'Setup' screen one by one. In xCAT we are providing an option where initial key agreement is only done after a node proves its physical presence to have an x509 certificate granted and then requiring that before we divulge or generate a shared secret for the BMC (the latter option has unique keys per BMC, but no one ever enables it because they care too much about the manual interactive case and know they can't remember unique keys per BMC). I think the challenge is pretty fundamental and ubiquitous to everything in IT security: initial establishment of trust in highly automated environments. The reality is that most shops auto-accept host keys rendering many security assumptions invalid unless that problem is fixed. "The reusable passwords used for IPMI authentication are saved in clear text in flash memory" True, but it is a shared secret mechanism that permits the client to never have to transmit the password on the wire (which might be debated to be a more vulnerable place). It also provides for implicit mutual authentication if the client is strict enough in what it will accept from an IPMI device. One-way hashed passwords have their own problems, notably that a spoofed server has a pretty high chance of acquiring secrets through MITM. Ideally, you correctly have everything private-public key based (which admittedly has no consideration in the IPMI spec), the gap in practice is that the host public key is frequently taken at face value. Shared secret at least makes the admin unwittingly set up mutual authentication. The shared secret scenario is troublesome as it limits the security for those that know and care about security, but has some tendency to instill better practices for those that care or know less, but do at least care enough to 'set a password'. My desire in this front would be an additional public/private key based auth mechanism to allow diligent users and software to implement something more unambiguously secure. However, such diligent users can limit shared secret scope already through unique key data everywhere (though no one seems willing). "If you have the IPMI password for a single system, you have the password for all the computers in that IPMI managed group" Nothing inherent about IPMI influencing one way or another. You can have unique keys per user-bmc combo and for Kg limiting the exposure of any single key compromise, just as you can have unique local root passwords in /etc/shadow. Just like /etc/shadow, the tendency is for people to reuse the credential more than is required. "it has to ask a potentially compromised BMC to answer truthfully." This can be controlled vendor to vendor. E.g. an IBM IMMv2 has the entire boot process and filesystem signed in such a way that malicious attempts to manipulate it are thwarted. This exacerbates the 'precludes customer for applying fixes prior to the vendor' issue, but it does mean that commands shall work as intended by the manufacturer. The key here being to pay attention to how the vendor protects the integrity of their implementation. "Man-in-the-Middle attacks ... traffic going to-and-from the BMC aren't encrypted or protected against this type of attack" So long as you avoid IPMI 1.5 "straight" and ipmi 2.0 cipher suite 0, this isn't the case. Even with IPMI 1.5 without encryption for privacy, you still have HMAC with MD5 for integrity assurance. The confidentiality is not protected, but the integrity is. It's of course optimal to apply the higher security of IPMI 2.0, but 1.5 already has MITM resistant strategy in place. In general, my recommendation would be for environments worried about security to stop caring so much about direct human interaction and let higher order software manage unique keys everywhere there is a desire to use 'passwords' today. Someone recovers the BMC password off an ebay discarded box? No big deal, the scope of that key was unique. Someone tricks the security framework responsible for key coordination into divulging a new key? No heightened privilege, but perhaps a way to remove all access to a BMC which is less bad. From: dan farmer <zenf...@gmail.com> To: Jarrod B Johnson/Raleigh/IBM@IBMUS Cc: "ipmitool-devel@lists.sourceforge.net" <ipmitool-devel@lists.sourceforge.net> Date: 02/19/2013 10:57 AM Subject: Re: [Ipmitool-devel] ipmi configuration security best practices Thanks for the feedback - a quick reply: On Feb 18, 2013, at 10:24 AM, Jarrod B Johnson <jbjoh...@us.ibm.com> wrote: Seems mostly sensible. -Gratuitious arp: agreed, but some BMC implementations cannot manage to get ARP requests to the BMCs. I presume this is why such a request is in the spec at all. I'd avoid such implementations like the plague for reasons beyond security though, just be aware that if an implementation enables that by default it may not work at all once disabled without static arp tables everywhere. That's a good way of putting it, I'll put something to that effect. -Avoid shared network: That's a pretty costly recommendation in some environments. An adequately secured BMC is relatively low risk to exist on the network. -Use VLANs. I'd say that, security wise, this adds very little. If someone has enough access on a host in the network, they can tcpdump to discovery your management vlan id and vconfig their way onto it. It may make sense for non-security reasons, but I'd rather not people get a false sense of security because they enabled tagged vlan id to BMC. I mostly agree about VLANs, although it does stop *some* from doing things. More complexity than it's worth in my mind, and they're almost always misconfigured in ways that people don't understand. The other… well, that's the basic disagreement between us, since I don't think BMCs may be adequately secured in general (I write at length about this in my paper, not trying to convince anyone, and there may be exceptions.) And the cost of a compromised BMC can at lest potentially vastly outweigh the cost of a server compromise. I would say that putting a server between it and the attacker is at least adding a bit of friction to the attacker's ride, but certainly not a panacea. I've compromised BMCs with very little effort by attacking them from the server side; my sample is very small (I've all of 3 different servers from as many vendors, and got 2/3), but it is certainly possible. Strictly security wise (not ops or cost) it makes sense to minimize exposure. All that said, you know far more about IPMI+ and how it's deployed than I do. I've talked to big vendors who also have different final conclusions but don't disagree with my basic points; I suppose it's not a black-n-white thing, but presumably over time we shall learn more. dan
<<inline: graycol.gif>>
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel