6.9.1 ‘Anonymous Login’ Convention
6.11 IPMI Sessions
Authenticated IPMI communication to the BMC is accomplished by establishing a session. Once established, a session is identified by a Session ID. The Session ID may be thought of as a handle that identifies a connection between a given remote user and the BMC, using either the LAN or Serial/Modem connection.
The specification supports having multiple active sessions established with the BMC. It is recommended that a BMC implementation support at least four simultaneous sessions. This number is shared between the LAN and Serial/Modem interfaces.
The specification also allows a given endpoint (identified by an IP address) on the LAN to open more than one session to a BMC. The capability is allowed to allow a single system to serve as a proxy to provide BMC LAN sessions for other systems. It is not intended for one system to use this provision to open multiple sessions to the BMC for that system’s sole use.
An IPMI messaging connection to the BMC fits one of three classifications, session-less, single-session, or multi-session.
6.11.1 Session-less Connections
A session-less connection is unauthenticated. There is no ‘user login’ required for performing IPMI messaging.
The System Interface and IPMB are examples of session-less connections.
6.11.2 Single-session Connections
A single-session connection has a user authentication phase that precedes IPMI messaging. This is accomplished using the Get Session Challenge and Activate Session commands. A single-session connection is intended for a physically secure link. Therefore, individual packets are not signed. The serial/modem Basic Mode is an example of a single-session connection.
6.11.3 Multi-session Connections
A multi-session connection has user authentication and supports multiple interleaved sessions (multiple users).
The multi-session connection is specified to support communication on a shared medium, such as LAN, where there may be a mix of IPMI and non-IPMI traffic. In order to support multiple sessions, and protect against attempts to circumvent authentication (such as replay attacks), multi-session packets have a session header in addition to the IPMI message. The session header carries information to identify the particular session, as well as other fields such as session sequence numbers and authentication type fields. The LAN and PPP Mode connections are examples of multi-session IPMI messaging connections.
6.11.4 Per-Message and User Level Authentication Disables
Typically, each packet in a multi-session connection is authenticated (with the exception of the packets for certain ‘pre-session’ commands such as Get Channel Authentication Capabilities, and Get Session Challenge.) In some cases however, the connection medium is considered to be trusted even though multiple user sessions are allowed. Once a session has been activated, the computational overhead of authenticating each packet may not be necessary.
Thus, there are two options to enable performance improvements in environments where the link is considered to be secure. The options are to disable ‘Per-Message Authentication’, and to disable ‘User Level
Authentication’. If Per-Message Authentication is disabled, the only packets that are required to be authenticated are the ones for the Activate Session request and response. Once the session is activated, the remaining packets will be accepted with the Authentication Type set to NONE. Since the Authentication Code (signature) is not
provided in the packet when the Authentication Type is NONE, this enables a performance improvement in two ways: fewer bytes are transmitted, and the authentication algorithm doesn’t need to be run.
In many cases, there is little concern about whether User Level commands are authenticated, since the User privilege allows status to be retrieved, but cannot be used to cause actions such as platform resets, or change platform configuration. Thus, an option is provided to disable authentication just for User Level commands. If User Level Authentication is disabled, then User Level messages will be accepted that have the Authentication Type set to NONE.
The BMC will always verify any authenticated packets (Authentication Type not NONE) that it receives, regardless of whether Per-Message Authentication and/or User Level Authentication is disabled. Authenticated packets will be silently discarded if the signature (AuthCode) is invalid, or the Authentication Type does not match the authentication type that was negotiated when the session was activated. This is necessary to allow remote console software to deliver authenticated messages to the Receive Message Queue via the Send Message command.
Both the Per-Message Authentication and User Level Authentication disable options are configured via the Set Channel Access command.
6.11.5 Link Authentication
Sometimes connections offer authentication protocols that are applied as part of establishing the communication link to the BMC. For example, PPP supports authentication protocols such as PAP and CHAP that are part of link establishment.
Link Authentication is a global characteristic associated with the connection mode for the channel. Link
Authentication is enabled/disabled via the serial/modem configuration parameters. When Link Authentication is enabled, it is necessary to identify one or more users that will serve as the source of the username (peer ID) and password information for the link. This is accomplished by setting an ‘Enable User for Link Authentication’ bit in the Set Channel Access command.
For physically secure connections, these ‘Link Authentication’ protocols may be all that’s considered needed to authenticate the user. Thus, the BMC supports enabling Link Authentication for PPP using common PPP authentication algorithms. If Link Authentication is enabled, the Per-Message Authentication Disable, and User Level Authentication Disable options may be used to improve performance.
6.11.6 Summary of Connection Characteristics
The following table summarizes the key characteristics that differentiate session-less, single-session, and multi-session connections:
Table 6-6, Session-less , Single-session and Multi-session Characteristics
Multi- Session Single- Session Session-less Session Header Authenticated Access Per Message Authentication Disable User Level Authentication Disable Link Authentication
LAN X X X X X
Serial/Modem:
PPP Mode X X X X X X
Basic Mode X X
Terminal Mode X X[1]
IPMB X
ICMB X
PCI Management Bus X
1. Terminal mode only supports ‘straight password’ authentication
6.11.7 Session Activation and IPMI Challenge-Response
A session must be activated before general IPMI messaging can occur. The mechanism for accomplishing this is via a set of IPMI commands that are used to perform an “IPMI Challenge-Response”. The session activation process involves three IPMI commands: Get Channel Authentication Capabilities, Get Session Challenge, and Activate Session. Of these three commands, the Get Channel Authentication Capabilities and Get Session Challenge command must be executable before the session is set up. Therefore, these commands can be thought of as always being ‘unauthenticated’. The Activate Session command is the first, and in some cases only, authenticated command for a session.
Figure 6-1, Session Activation
Activate Session, Rq Get Session Challenge, Rq
Get Session Challenge, Rs
Activate Session, Rs
Remote Console Managed System
Get Channel Authentication Capabilities, Rq
Get Channel Authentication Capabilities, Rs
6 1
2
3
4
5
Referring to Figure 6-1, Session Activation, the following presents the general steps for activating a session:
1. The Remote Console issues a Get Channel Authentication Capabilities request to the BMC.
2. The BMC returns a Get Channel Authentication Capabilities response that contains which authentication types (authentication algorithms) it supports.
3. The Remote Console sends a Get Session Challenge request to the BMC. The command selects which of the BMC-supported authentication types the Remote Console would like to use, and a username that selects which set of user information should be used for the session. This is the only place where the username is used during the process.
4. The BMC looks up the user information associated with the username. If the user is found and allowed access via the given channel, the BMC returns a Get Session Challenge response that includes a randomly generated Challenge String and a temporary Session ID. The BMC keeps track of the username associated with the Session ID so that it can use the Session ID to look up the user’s information in the next step. In some algorithms, the BMC will store challenge string, or a seed that was used to generate the challenge, for later lookup as well.
5. The Remote Console then issues an Activate Session request. The request contains the temporary Session ID plus the authentication information based on the type of authentication that was selected.
For example, a LAN packet would typically include a signature using an authentication algorithm run
on elements such as the challenge string, user password/key, IPMI message fields, Session ID, etc.
while a serial/modem connection may only pass a simple clear-text password in the activate session data. The authentication format for different authentication types is specified in the description of the Activate Session command. For multi-session connections, the starting Outbound session sequence that the BMC is to use when sending packets to the remote console is also passed in the request. (Session sequence numbers are explained in the next section.)
6. The BMC uses the temporary Session ID to look up the information for the user that was identified in the Get Session Challenge request. The BMC looks up the user’s password/key data, and potentially other data such as a stored copy of the earlier challenge string, and uses it to verify that the packet signature or password is correct. If so, the BMC issues an Activate Session response that provides the Session ID to use for the remainder of the session. For multi-session connections, the Activate Session response is itself authenticated (signed). The BMC will also deliver the starting Inbound session sequence that the Remote Console is to use when sending packets to the BMC.
From this point, whether individual packets for the session are authenticated or not is based on settings such as the Per User Authentication and User Level Authentication parameters. Refer back to 6.11.4, Per-Message and User Level Authentication Disables.
6.11.8 Session Sequence Numbers
The session sequence number is a 32-bit, unsigned, value. The session sequence number is not used for matching IPMI requests and responses. The IPMI Sequence (Seq) field is used for that purpose. The session sequence number is solely for protecting against replay attacks.
There are two Session Sequence Numbers: the Inbound Session Sequence Number and the Outbound Session Sequence Numbers. The inbound and outbound directions are defined with respect to the BMC. Inbound messages are from the remote console to the BMC, while outbound messages are from the BMC to the remote console.
Inbound messages use the inbound session sequence number, while outbound messages use the outbound session sequence number.
6.11.9 Session Sequence Number Generation
Session sequence numbers are generated on a per-session basis. The inbound and outbound sequence numbers are updated and tracked independently. The BMC and the remote console independently select the starting session sequence number for the messages they receive.
The remote console sets the starting values for the outbound session sequence number when it sends the first Activate Session command for an authenticated session.
The Activate Session response is the first authenticated outbound (BMC to remote console) message. This response message uses the initial outbound session sequence number value that the remote console delivered in the prior Activate Session command request. The BMC must increment the outbound session sequence number by one (1) for each subsequent outbound message from the BMC.
The first authenticated inbound message uses the initial inbound (remote console to BMC) session sequence number value that was returned by the BMC in the response to the Activate Session command. The remote console must increment the inbound session sequence number by one (1) for each subsequent message it sends to the BMC.
6.11.10 Inbound Session Sequence Number Tracking and Handling
Session sequence numbers are tracked on a per-session basis. At a minimum, the BMC is required to track that the inbound sequence number is increasing, and to silently discard the packet if the sequence number is eight
counts or more from than the last value received. (An implementation is allowed to contain a proprietary configuration option that enables a larger sequence number difference, as long as the standard of +eight can be restored.)
An implementation can elect to terminate the session if it receives a number of sequence numbers that are more than eight counts from the last value received.
Valid packets (packets with good data integrity checks and signature) to a given session that have the same inbound sequence number as an earlier packet are considered to be duplicate packets and are silently discarded (even if the message content is different).
6.11.11 Out-of-order Packet Handling
In order to avoid closing a session because a packet was received out-of-order, the BMC must implement one of two options:
Option 1: Advancing eight-count (or greater) window. Recommended. Track which packets have been received that have sequence numbers up to eight counts less than the highest last received sequence number, tracking which of the prior eight sequence numbers have been received. Also accept packet with sequence numbers that are up to eight counts greater than the last received sequence number, and set that number as the new value for the highest sequence number received. This option is illustrated in Appendix A - Previous Sequence Number Tracking.
Option 2: Drop any packets with sequence numbers that are lower than the last valid value received. While simpler than option 1, this option is not recommended except for resource-constrained implementations due to the fact that any out-of-order packets will require the remote console to timeout and retransmit.
Sequence number wrap-around must be taken into account for both options. When a sequence number advances from FFFF_FFFFh to 0000_0000h, the value FFFF_FFFFh represents the lesser sequence number.
6.11.12 Outbound Session Sequence Number Tracking and Handling
The remote console is required to handle outbound session sequence number tracking in the same manner as the BMC handles the inbound session sequence number, except that Option 2 (above) should not be used as a means of handling out-of-order packets.
6.11.13 Session Inactivity Timeouts
A session is automatically closed if no new, valid, message has been received for the session within the specified interval since the last message. The session must be re-authenticated to be restored. A remote console can optionally use the Activate Session command to keep a session open during periods of inactivity.
Note that only an active session will keep the Session Inactivity Timeout from expiring. IPMI message activity that occurs outside of an active session has no effect. This is to prevent someone from keeping a phone connection indefinitely while trying to guess different passwords to activate a session.
The BMC only monitors for inactivity while the connection is switched over to the BMC. Note that closing a session is not always the same as hanging up a modem connection. Serial/modem sessions are also automatically closed when the connection is switched over to the system, but the phone connection remains active. The BMC only terminates the phone connection if a session is closed due to an inactivity timeout while the serial
connection is routed to the BMC.
The timeout and tolerance values are specified for the management controller (BMC) that will timeout and close the session. System software should take this tolerance into account, plus any additional delays due to media transmission times, etc.
An implementation can provide an option to allow the timeout to be configurable via a parameter in the configuration parameters for the given channel type.
Table 6-7, Default Session Inactivity Timeout Intervals
Session Type Default Expiration
Interval
Tolerance Notes
LAN 60 seconds +/- 3 seconds
Direct Connect Mode Serial 60 seconds +/- 3 seconds
Modem Mode Serial 60 seconds +/- 3 seconds The Inactivity Timeout Interval starts whenever a connection is established with, or switched to, the BMC. The Phone connection gets terminated if inactivity timeout occurs while serial connection is routed to BMC.
6.11.13.1 Avoiding ‘Slot Stealing’
It is highly recommended that an implementation provide a mechanism for protecting against someone accidentally or maliciously 'claiming' all the session slots and subsequently locking out access to the BMC. For example, this could occur by an errant program repeatedly issuing Get Session Challenge commands without successfully activating a session - causing all available resources for tracking pending sessions to be used up.
One possible solution is to use an LRU algorithm that drops the session ID for the oldest session ID that has a pending 'Activate Session'. That way, the only way to ‘permanently’ use up slots is by activating and maintaining sessions for all session slots. A minor refinement may be to provide a few seconds of delay on returning the response to the Get Session Challenge in order to give opportunity for a well-behaved application to get a Challenge and return an Activate Session command before the errant software re-issued another Get Session Challenge. (This is only an improvement for errant applications that wait for the response to the Get Session Challenge before issuing the request again.)
6.11.14 Additional Session Specifications and Characteristics
• At least four simultaneous sessions should be supported on a given channel.
• By default, sessions are automatically closed if no valid activity is detected within the Session Inactivity Timeout Interval, or if the connection or link is terminated. Valid activity is defined as the receipt of a valid IPMI message for that session while the connection is routed to the BMC.
• At least four pending bridged requests should be supported for each bridged interface that requires the BMC to track pending responses. See 6.12, BMC Message Bridging for more information.
• The typical BMC is expected to allow only a small number of simultaneous open sessions (on the order of four to eight). Thus, remote console applications should avoid activating multiple sessions whenever possible, in order to allow other remote consoles to also get access.
• The Activate Session command will return a completion code indicating whether the request was rejected because BMC is presently busy with other open sessions.
• The specification allows multiple sessions to be activated from a single IP address. The primary reason for allowing multiple sessions is to allow a system to serve as a proxy agent that provides BMC access for remote consoles that connect to it instead of directly to the BMC.
• Multiple sessions are not intended to be used to support access by multiple applications behind an IP address. If multiple applications require access to the BMC on a given system, a single driver or ‘middle-ware’ should coordinate that access and use a single session, if possible. The IPMI Software ID and the
IPMI sequence number are two fields that a shared driver can used to identify and route messages to and from a given application.
• There is a 1:1 relationship between a user name and a session. I.e. different usernames cannot share the same session. However, multiple sessions can be activated using the same username.
• All sessions start off at User Level privilege. It is necessary to issue a Set Session Privilege to raise the operating privilege level before commands that required higher privilege can be executed. The maximum operating privilege for a session is determined by Privilege Limits that are set both for the user and for the overall channel. The more restrictive setting of the User Privilege Limit and the Channel Privilege Limit sets the maximum operating privilege available for a session.
• An Operator can optionally use the Get Channel Info and Get Session Info commands to retrieve the address of parties with open sessions and their present privilege level. This is to allow a remote console to coordinate with another remote console that already has an active session. This can be used to allow software to
coordinate access to the system. For example, one system
• An Administrator can force sessions on any channel to be terminated.