Initial Proposed Consensus Response for
Security Design (1.a.c)

1. BAT
Description of major interfaces (user-web, SRC-Database) is 
marginally sufficient.  Communication, authentication, and access
control between MetaStar components are not adequately addressed.
This is important because these components may reside on separate
machines. Insufficient detail provided regarding MetaStar Login
and Kerberos.  It appears that the authenticated session is
maintained using LDAP and cookies but the possibility of using
Kerberos encryption to maintain the session and the location of
the Kerberos ticket cache are not addressed.  Unclear which web
server they are using.

2. HPTi
Descriptions of components and component interfaces are reasonably
clear and complete.  Use of Kerberos for inter-component
communication is workable, but somewhat lacking in detail.
Conservative approach to Kerberos user authentication is reasonable
and is claimed to have already passed HPCMO security review.

3. KPMG
Several components shown in Fig. 5 & 6 are not adequately
described.  Components beyond the scope of this RFP are
proposed, including intrusion detection, antivirus software,
and a One-Way Security Device providing connectivity to a
Secret network which we do not require.  Several inter-
component interfaces are undefined, including Interface
between SRC and IEDB.  User authentication is some mix of
Kerberos, PKI with client certificates, and Windows NT
challenge/response.  The interface between Kerberos and
PKI (or is it NT challenge/response?) is undefined. Their
claim to encrypt all Kerberos passwords that are stored on
IE servers and client workstations indicates either a
misunderstanding of Kerberos or a misuse of Kerberos.
Proposal may have been cut-and-pasted together from other
unrelated proposals.

4. Logicon
Minimal description of components and component interfaces.
Access controls description is weak.  Unsure how mature
Kerberos support is in Novell Network Directory Service
(NDS); integration of web and Kerberos authentication is
listed as a technical risk which has not yet been prototyped.
Section 2.9 Assumption #17 demonstrates lack of familiarity
with Kerberos and hardware preauthentication.

5. NetworkCS
Descriptions of components and component interfaces are clear,
complete, and detailed.  Description of cookie usage is less
thorough.  Conservative approach to Kerberos user authentication
is reasonable and is claimed to have already passed HPCMO security
review.  Very good use of SSH for inter-component authentication
and authorization.

6. PwC
Component descriptions are limited and vague.  Description of
inter-component communication using kftp is somewhat weak.
Relationship between Kerberos and SecurID for authentication
to web server is undefined.  Kerberos is mis-characterized as
a form of asymmetric or public key cryptography.  Their claim
to support Kerberos encryption between web server and client
appears unfounded; client components necessary to support this
are never discussed.  Vendor appears to be parroting back elements
from SoW without understanding the issues involved.  SecurID,
Kerberos, SSL, and SSH all get a mention, but they do not
describe how these parts are integrated to provide strongly
authenticated web service.



This message is possibly signed and/or encrypted. This application does not currently support signed or encrypted messages.