> * No plans to make SSCONFIG publicly available

The problem with the current "secure" configuration tools is that they
require a trusted user.  The mechanisms themselves are protected by one-time
challenge/response passwords, so you can issue these passwords centrally and
thus control whether or not each change is allowed to happen because the CE
has to phone someone up to get the password and the operator can verify
their identity at that point.  But there is no mechanism to control *what*
change(s) are made, nor what system the changes are being applied to.  So an
untrustworthy CE can call up and say "I need to make change A to machine X"
and really make change B to machine Y.  Hence in the current system the user
in the field has to be trusted.

The proper way to have done the whole thing from the beginning would be for
there to be a publicly available configuration program that one could run
from the ISL prompt that would provide secure control of the *specific*
changes to be made.

The way this would work is as follows:

1) The CE (or end user!) runs the CONFIG program from the ISL-> prompt.  It
displays the current configuration (Serial number, Model string, etc.) and
prompts for new values.

2) The user enters their requested change.

3) The program issues a challenge based on a hash of the old and new
information and some random value.

4) The user phones up someone at HP or whatever trusted institution is
acting as a clearing house for configuration changes.  They read off the old
and new values for the change they are trying to make, and the challenge
value from the program.

5) The user at HP enters the information into a trusted system which does
whatever it needs to with regard to verifying that the change is acceptable
(maybe it simply logs the information), and issues the response password to
the operator who reads it back to the user over the phone.

6) The user enters the password and the CONFIG program commits the change.

Because the challenge/response password that is generated will only work for
the *specific* change that the user *says* they're making, there is no
longer a need for the user in the field to be a trusted HP employee.  If the
user lies about, say, the old serial number of the board they're changing,
or the new serial number or model string they're changing to, then the
password they get won't work.

Because the central authority gets all the old and new information, they can
do whatever validation/tracking that they need to, and if they choose to,
say, disallow the installation of 9000 CPUs into 3000 boxes, then they can
do that automatically.

Since the system that makes the decisions and issues the passwords can
itself be "trusted", not even the operator at HP needs to be trusted not to
cheat.  In fact, HP could potentially create a web-based interface that
would generate passwords for certain classes of simple changes required for
day to day maintenance.

If HP later wants to get out of "the business" they could either turn the
central system over to some new trusted authority, or they could give to 3rd
party maintenance providers a program that would only generate passwords for
MPE machines, preventing changes that would affect HP-UX systems.

Gavin