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