Alert Standard Format (ASF) Specification

Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136
DSP0136 23 April 2003 Page 30 of 94
RAKP uses pre-shared symmetric keys and HMAC-based integrity algorithms to mutually
authenticate a management console to a given managed client and to generate pair-wise unique
symmetric keying material that can be used with a number of integrity algorithms to provide
protection for RMCP messages. For this specification, RAKP shall use the HMAC-SHA1 integrity
algorithm defined in [RFC2104] and the HMAC-SHA1-96 integrity algorithm defined in
[RFC2404].
RAKP also supports the concept of management console user “roles” and optionally “names”
(e.g. operator “x” or administrator “y”), which are established by RAKP when a session is created.
This feature combined with a management console defined Device Security Policy allows a
managed client to control its behavior.
Examples of behavior that can be controlled include the roles that the managed client can use to
establish sessions (e.g. operator-only sessions), the roles and names (optional) allowed to
execute each RMCP message the managed client might receive during a given session, and
whether the managed client will accept messages over the compatibility RMCP port (026Fh).
Before a given managed client’s RMCP implementation can become operational, it must be
configured with various RMCP-related parameters. At installation time for RAKP, a management
console user uses an out-of-band mechanism (e.g. local physical access or remote access via a
secured connection) to record the Globally Unique ID (GUID) for a managed client and install in
the managed client a Device Security Policy and three (3) 160-bit random symmetric keys.
The first two keys are used for authentication operations based on the “role” being requested by
the user at the management console during session setup. The first key, K
O,
is used for operator
authentication and the second key, K
A,
is used for administrator authentication. The third key,
K
G, is used for key generation operations. The scope of these keys (shared by multiple managed
clients and the management console or pair-wise unique for each managed client and the
management console) is a local policy issue that is determined by the equipment owner at the
time of installation.
Once this and other necessary RMCP-related data is installed in the managed client and the
managed client is initialized, the management console can initiate sessions with the managed
client. Following the exchange of RMCP Presence Ping/Pong and RSSP Open Session
Request/Response messages (exchanging session IDs and selecting RAKP for use), the
management console starts the RAKP protocol. First, the management console selects a
random number, R
M
, a requested role, Role
M
, a user name length, ULength
M
, a user name
(optional – denoted by < > below), UName
M
, and the managed client’s session ID, SID
C
, and
sends them to the managed client as Message 1.
Message 1: Mgt Console —► Managed Client
SID
C
, R
M
, Role
M
, ULength
M
, < UName
M
>
After receiving Message 1, the managed client verifies that the value SID
C
is active and that a
session can be created using Role
M
, ULength
M
, and (optional), UName
M
, by evaluation of the
Device Security Policy. If the request is valid, the managed client then selects a random number,
R
C
, and sends to the management console as Message 2 the values SID
M
, R
C
, and GUID
C
as
well as the HMAC per [RFC2404] of the values (SID
M
, SID
C
, R
M
, R
C
, GUID
C
, Role
M
, ULength
M
,
< UName
M
>) generated using key K
O
or K
A
selected by the requested role, Role
M
.
Message 2: Managed Client —► Mgt Console
SID
M
, R
C
, GUID
C
,
HMAC
KO or KA
(SID
M
, SID
C
, R
M
, R
C
, GUID
C
, Role
M
, ULength
M
, < UName
M
>)