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

[Krishna Sankar <ksankar@cisco.com>]

Joel,

	Thank you very much for your comments. Very timely, as I was going to do
add more stuff and do more damage ;-).

	My comments are embedded <ks/>. Will talk more tomorrow.

	cheers

> -----Original Message-----
> From: Munter, Joel D [mailto:joel.d.munter@intel.com]
> Sent: Monday, December 18, 2000 10:14 AM
> To: 'ebxml-regrep@lists.ebxml.org'
> Subject: Comments on ebXML RegRep Security-002.doc (jdm)
>
>
>
<snip>
> 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.
<ks>
Yep. In the next revision we should change the how to what.
</ks>
>
> 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.
<ks>
The intention was to clearly give guests permissions and that guest should
not get permissions where nothing is specified.
The principle here is that guests would get permission if they are
*explicitly* given permission
Otherwise if somebody does not give any permissions, that would mean guests
can access the object.

Where I was struggling with was what we want to eventually and what we
should do for Release 1.
The default RegistryClient is equivalent to the guest.
</ks>
> Line 117:  In this context, what is an entity?
<ks>
Entity is a Registry client - could be an organization or a named person. In
real sense a CN in a certificate
</ks>
> Line 118:  In this context, what is an authenticator?
<ks>
The Registry Security System - includes the initial priming of the various
defaults and also the service which performs the authentication function.
</ks>
> 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..."?
<ks>
Yep. I will correct it
</ks>
> Lines 122-126:  This list of roles is inconsistent with the list presented
> in the box shown on Line 156
<ks>
I am still struggling with the roles required. You are right - they need to
be the same
</ks>
> Lines 127-128:  Are you stating that there is a requirement to allow for
> private areas for the users or at the "role" level?
<ks>
My point was that the scheme should *not* preclude the private areas. By
saying that, we are requiring the
capability to allow private spaces
</ks>
> 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.
<ks>
The actual requirement is a) which says long-lives session should not be
used - which brings to the definition of "long-lived" ! Any suggestions ?
</ks>
> Lines 133-134:  What constitutes long-lived?  Seconds, Minutes, Hours,
> Days?, By whose standards?
<ks>
I did not see this until I wrote the answer above. May be, like you
suggested, the sentence should be that session timeout should be implemented
if the session design is used
</ks>
> Line 135: Please describe specifically what you mean by Registry spoofing
> here or later in this document.
<ks>
Yep. Thanks
</ks>
> 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.
<ks>
I will include references
</ks>
> Line 138:  How does requirement no. 14 relate to SMTP messaging ?  Also
> please define what is meant here by the word Confidential.
<ks>
I assume in case of SMTP, encryption would be used. I will add definitions
or provide normalitive references
</ks>
> Line 141:  Please clarify what you mean by "not be visible to registry if
> registry is not trusted."  This does not make sense.
<ks>
If we want to keep objects in the registry but still want to keep it from
anybody, one can by encrypting the content. Some examples are User Names,
passwords etc. They can be kept in the registry but the registry would not
be able to "see" them
</ks>
>
> 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.
<ks>
Good idea. I am still waiting for the TRP security and then add RegRep
related security.
</ks>
> 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."
<ks>
Yep. Will do
</ks>
> Line 156:  Roles listed here are inconsistent with list shown in
> Requirement
> No. 8.
<ks>
Yep. Will make them the same
</ks>
> Line 163:  Earlier requirements implied that even some getXXXX
> messages will
> need to be signed.  Should we say so here.
<ks>
For release 1 there is no need for signing the getXXX methods.
</ks>
> Line 165-166:  If this is true and requirement 5.c. is met, then what
> privileges will be allowed?
<ks>
You are right, too many  loose use of the word "default" everywhere. I will
correct it.
</ks>
> 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?"
<ks>
Phase 1 motto is "Any known entity can publish and anyone can view". I am
not pleased at all, but no choice.
So far we have no notion of a distributed registries. But if they are
distributed, then the security objects would also be distributed. So no
problems. If an object is distributed, we will need to replicate the related
security objects as well. It of course raises the sync problem - which the
distributed registry paradigm has to solve. Definitely not in Release 1 (as
I know of)
</ks>
> 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?
<ks>
If we all decide to do away with UN/PW, I will delete all the UN/PW
references from the document
</ks>
<ks>
Joel, I once again thank you for taking the time. It is of immense help. As
this is the first time, lot of ideas are in there and so the document is low
on consistency. Once we decide which ideas will be present, then I will do
the consistency check and normalize all references et al.
</ks>
cheers
</ks>