Comments on ebXML RegRep Security-002.doc (jdm)

["Munter, Joel D" <joel.d.munter@intel.com>]

I apologize for the delay .  Here are some preliminary comments on the Draft
Registry/Repository Security proposal recently submitted by Farrukh and
Krishna.  I stopped after Page 9 (Lines 206).  I wanted to get these
preliminary comments circulating as soon as possible.  As I am able to, I
will comment on the latter half of the proposal as well. I intentionally
chose to keep these comments just to the Reg/Rep team.  If when we are ready
and/or where applicable now, we may want to share some or all of these
questions with others teams such as POC and TR&P.

General Notes:
A great thanks to Farrukh and Krishna for taking a first stab at this!
My line numbers come from the PDF version entitled: ebXML RegRep
Security-002.doc, Dated: December 8, 2000
No other specifications are referenced as Normative or non-Normative.  This
surely was not intentional.   
The Security Processing Section Lines 222 and forward seem to describe
implementation details (i.e., "how") more than the "what" that this Security
specification should describe.

Specific Notes: Requirements
Lines 113-115:  If, as written, a default guest access has no privileges,
then why have one?  Please clarify the difference if any between the terms
"guest level access" and the default privileges implied for a RegistryClient
described in lines 156-166.
Line 117:  In this context, what is an entity? 
Line 118:  In this context, what is an authenticator?
Line 120:  Within the context of this proposal, it appears as though an
Authorization must be present.  Therefore, why even have a statement "If an
authorization scheme is present..."?
Lines 122-126:  This list of roles is inconsistent with the list presented
in the box shown on Line 156
Lines 127-128:  Are you stating that there is a requirement to allow for
private areas for the users or at the "role" level?
Lines 131-132:  This describes how you might do something.  This is not a
requirement but an implementation suggestion.  Please clarify this or remove
it.
Lines 133-134:  What constitutes long-lived?  Seconds, Minutes, Hours,
Days?, By whose standards? 
Line 135: Please describe specifically what you mean by Registry spoofing
here or later in this document.
Line 136-137:  Please describe specifically what you mean by
man-in-the-middle, replay, and denial of service attacks here or later in
this document.
Line 138:  How does requirement no. 14 relate to SMTP messaging ?  Also
please define what is meant here by the word Confidential. 
Line 141:  Please clarify what you mean by "not be visible to registry if
registry is not trusted."  This does not make sense.

Security Rules:
Lines 147-149:  What specifications are normative to this encryption
process?  If possible, please use diagrams to show how the messages are to
be "packaged within the registry and where content is to be signed, etc.  
Lines 152-153:  I'd suggest changing the sentence portion from "...there is
no concept of a session or a long-standing conversation." to "...there is
concept of a multi-message conversation."
Line 156:  Roles listed here are inconsistent with list shown in Requirement
No. 8.
Line 163:  Earlier requirements implied that even some getXXXX messages will
need to be signed.  Should we say so here.
Line 165-166:  If this is true and requirement 5.c. is met, then what
privileges will be allowed?
Line 167-168:  If role based access control and access control policies are
not visible outside of the registry, and as lines 172-178 imply, then why
bother to specify them at all.  This specification seems to say in Phase I
"Anyone authentic user can publish, anyone can view."  How does this lack of
visibility of access control polices outside of the registry affect the use
or architecture of "distributed registries?"   How is security
"distributed?"
Line 192:  The call-out box in the lower left hand corner implies that
Username/Password combination "may" be valid.  How can this be so and still
be consistent with lines 147-149? 
  
Joel Munter
Intel - eArchitecture Solutions Lab
joel.d.munter@intel.com
(480) 552-3076