1*c18ec02fSPetter ReinholdtsenThis interface exists to provide a means of connecting to an IPMIv2 enabled 2*c18ec02fSPetter ReinholdtsenBMC. In some places, the IPMIv2 specification is either unclear or 3*c18ec02fSPetter Reinholdtseninconsistent, and interpretations of the intent of the specification had to 4*c18ec02fSPetter Reinholdtsenbe made at the discretion of the implementor. The purpose of this 5*c18ec02fSPetter Reinholdtsendocument is to make those decisions clear so that 1) they can be reviewed 6*c18ec02fSPetter Reinholdtsenby others and 2) so that the rationale for those decisions can be made 7*c18ec02fSPetter Reinholdtsenclear. 8*c18ec02fSPetter Reinholdtsen 9*c18ec02fSPetter Reinholdtsen* Though it's not stated explicitly with which algorithm the K1 and K2 keys 10*c18ec02fSPetter Reinholdtsenshould be generated, we chose to use the authentication algorithm. The 11*c18ec02fSPetter Reinholdtsenspecification states that K1 and K2 are generated with an HMAC algorithm, 12*c18ec02fSPetter Reinholdtsenand all of the authentication algorithms (except for "none") are HMAC 13*c18ec02fSPetter Reinholdtsenalgorithms, whereas the integrity algorithms are not all HMAC. See section 14*c18ec02fSPetter Reinholdtsen13.32 for details about K1 and K2, and section 15*c18ec02fSPetter Reinholdtsen 16*c18ec02fSPetter Reinholdtsen 17*c18ec02fSPetter Reinholdtsen* The IPMIv2 specification describes a key, Kg, that is the "BMC key". 18*c18ec02fSPetter ReinholdtsenThis key functions as a global key that is required to be known in addition 19*c18ec02fSPetter Reinholdtsento the user's key, by authenticating users. If the BMC has a null Kg, the 20*c18ec02fSPetter Reinholdtsenusers key, Kuid, is used in its place in algorithms where Kg is required, 21*c18ec02fSPetter Reinholdtsenper the specification section 13.33. A user can obtain the status of Kg by 22*c18ec02fSPetter Reinholdtsenquerying the BMC with the Get Channel Authentication Capabilities command. 23*c18ec02fSPetter ReinholdtsenCurrently, this implementation does not provide a way for a user to specify 24*c18ec02fSPetter ReinholdtsenKg for BMCs that require it. 25*c18ec02fSPetter Reinholdtsen 26*c18ec02fSPetter Reinholdtsen 27*c18ec02fSPetter Reinholdtsen* The specification is unclear as to which key is used for HMAC based 28*c18ec02fSPetter Reinholdtsenintegrity checking. One the one hand, section 13.28.4 states explicitly 29*c18ec02fSPetter Reinholdtsenthat HMAC integrity algorithms use the session integrity key as the HMAC 30*c18ec02fSPetter Reinholdtsenkey. Confusing that matter is a statement in section 13.32 regarding the 31*c18ec02fSPetter Reinholdtsencreation of additional keying material. In this section it is stated that 32*c18ec02fSPetter Reinholdtsen"all keying material for the RSP integrity and confidentiality algorithms 33*c18ec02fSPetter Reinholdtsenwill be generated by processing a pre-defined set of constants using HMAC 34*c18ec02fSPetter Reinholdtsenper [RFC2104], keyed by sik". And "For the mandatory-to-implement 35*c18ec02fSPetter Reinholdtsenintegrity and confidentiality algorithms defined in this specification, 36*c18ec02fSPetter Reinholdtsenprocessing the first two (2) constants will generate the require amount of 37*c18ec02fSPetter Reinholdtsenkeying material." We decided to use K1 as our HMAC key for the generation 38*c18ec02fSPetter Reinholdtsenof authentication codes (integrity checking). Furthermore, we are using 39*c18ec02fSPetter Reinholdtsenall 20 bytes of K1. 40*c18ec02fSPetter Reinholdtsen 41*c18ec02fSPetter Reinholdtsen 42*c18ec02fSPetter Reinholdtsen* IPMIv2 compliant BMCs are supposed to support 20 byte passwords, as well 43*c18ec02fSPetter Reinholdtsenstore metadata describing whether the password was stored as a 16 byte or 44*c18ec02fSPetter Reinholdtsen20 byte class password. We do not currently support 20 byte passwords. It 45*c18ec02fSPetter Reinholdtsenshould be noted that there are obvious mistakes in the SET USER PASSWORD 46*c18ec02fSPetter Reinholdtsencommand specification, as it mentions the ability to query for 16/20 byte 47*c18ec02fSPetter Reinholdtsenpassword status, but the packet format does not support this. 48*c18ec02fSPetter Reinholdtsen 49*c18ec02fSPetter Reinholdtsen 50*c18ec02fSPetter Reinholdtsen* The IPMIv2 specification describes a type of login called a "role only 51*c18ec02fSPetter Reinholdtsenlogin." This feature allows a user to login providing only a requested 52*c18ec02fSPetter Reinholdtsenprivilege level and a password. We do not currently support this feature. 53*c18ec02fSPetter ReinholdtsenSupporting this feature would only require the ability to specify 54*c18ec02fSPetter Reinholdtsenusername/privilege lookups in the RAKP 1 message sent from ipmitool. We 55*c18ec02fSPetter Reinholdtsencurrently specify the use of username only lookups for authentication. 56*c18ec02fSPetter Reinholdtsen 57*c18ec02fSPetter Reinholdtsen 58*c18ec02fSPetter Reinholdtsen* In the IPMIv2 packet description in table 13-8 of the IPMv2 59*c18ec02fSPetter Reinholdtsenspecification, there are two fields that are rather ambiguous in meaning. 60*c18ec02fSPetter ReinholdtsenThe fields are "Pad Length" and "Next Header". Although neither field is 61*c18ec02fSPetter Reinholdtsenlisted as belonging to the IPMIv2 packet format, we include/expect them 62*c18ec02fSPetter Reinholdtsenboth in our IPMIv2 packets. Are rationale is 1) the Next Headers field's 63*c18ec02fSPetter Reinholdtsencomment states what the value of that field should be for IPMIv2, and 2) 64*c18ec02fSPetter Reinholdtsenfor the most part the ASF and IPMIv2 fields seem to parallel each other, 65*c18ec02fSPetter Reinholdtsenand we feel that the Pad Length and Next Header fields were left out of the 66*c18ec02fSPetter ReinholdtsenIPMIv2 column by mistake. 67*c18ec02fSPetter Reinholdtsen 68*c18ec02fSPetter Reinholdtsen 69*c18ec02fSPetter Reinholdtsen* The GET CHANNEL CIPHER SUITES command documentation seems to have 70*c18ec02fSPetter Reinholdtsenmistakes. The "start of record" byte is stated to be either 0x30 or 0x31, 71*c18ec02fSPetter Reinholdtsenwhereas the detailed description in table 22-18 leads us to believe that 72*c18ec02fSPetter Reinholdtsenthis byte should really be 0xC0 or 0xC1. Also the description of bits 5:0 73*c18ec02fSPetter Reinholdtsenin the start of record byte should probably be 00_0000 rather than 00_000. 74*c18ec02fSPetter Reinholdtsen 75