RE: D-AR006.11 discussion points

> From: Steven A. Monetti [mailto:smonetti@att.com]
[snip]

> imo a requirement such as:
> The security framework must include auditing.
> would be of value.

This, without elevating auditing to the status of a sec aspect/facet,
is a lot more appealing to me.

Joe Hui
Exodus, a Cable & Wireless service
====================================================


> 
> s.a.monetti
> at&t
> 
> ----- Original Message -----
> From: "Joseph Hui" <Joseph.Hui@exodus.net>
> To: "Dilber, Ayse, ALASO" <adilber@att.com>; "Christopher Ferris"
> <chris.ferris@sun.com>; <www-ws-arch@w3.org>
> Sent: Wednesday, May 08, 2002 4:40 PM
> Subject: RE: D-AR006.11 discussion points
> 
> 
> > Ayse,
> >
> > Then what's your answer to my questions in [1]
> > pertaining to threat characterization?
> >
> > I'm copying the text of the original question over
> > as follows:
> >
> >   Auditing* as a security aspect?
> >   Can you explain why?  E.g. for starter, how would you
> >   characterize the threat (model) that's unique to Auditing?
> >   Note that the impetus for requiring each of the original
> >   six begins with a unique threat, or in some cases, threats.
> >
> > Joe Hui
> > Exodus, a Cable & Wireless service
> >
> > PS: I wasn't interested in what auditing means in
> >     the conventional sense.  It's obvious.
> >
> > [1] 
> http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0056.html
> > 
> ======================================================================
> > > -----Original Message-----
> > > From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > > Sent: Wednesday, May 08, 2002 12:59 PM
> > > To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
> > > Subject: RE: D-AR006.11 discussion points
> > >
> > >
> > > No, I didn't back out on Auditing!  I was having serious
> > > e-mail problems that's why I couldn't respond.  I believe
> > > that the Auditing should be included!
> > > Ayse
> > >
> > > -----Original Message-----
> > > From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> > > Sent: Wednesday, May 08, 2002 3:55 PM
> > > To: Christopher Ferris; www-ws-arch@w3.org
> > > Subject: RE: D-AR006.11 discussion points
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > > > Sent: Wednesday, May 08, 2002 12:00 PM
> > > > To: www-ws-arch@w3.org
> > > > Subject: Re: D-AR006.11 discussion points
> > > >
> > > >
> > > > Joe/Ayse,
> > > >
> > > > 1) Please keep this, and all technical discussion, on the public
> > > > mailing list.
> > > >
> > > > 2) It seems to me that Joe is suggesting that the bulleted
> > > > item under D-AR006.11 that says:
> > > >
> > > > "There are six aspects in the security framework for Web
> > > > Services architecture: Accessibility,
> > > > Authentication, Authorization, Confidentiality, Integrity,
> > > > and Non-repudiation. Together they form
> > > > the foundation for secure Web Services.
> > >
> > > The above text is NOT a requirement at all!!!
> > > It doesn't even read like one.
> > > It's a lite intro for D-AR006.1 thru D-AR006.6.
> > > The editors inserted D-AR006.10 and D-AR006.11 in
> > > the wrong place.  The two should have followed D-AR009;
> > > and the intro should not have been bulletized.
> > > What a mess.  sigh.
> > >
> > > D-AR006.11 text should read as follows:
> > >
> > >   D-AR006.11 The architecture must provide an interface for
> > >   Web Services to directly communicate with their underlying
> > >   infrastructure.
> > >
> > >   The interface is for negotiating services that an infrastructure
> > >   may provide to, or perform on behalf of, requesting Web 
> Services.
> > >   Such value-added services may include: security, 
> content delivery,
> > >   QoS, etc. For instance, a Web service may instruct (via the
> > > interface)
> > >   the security agents of its infrastructure to defend against
> > >   DOS/DDOS attacks on its behalf."
> > >
> > > > is actually a separate requirement from D-AR006.11 and should
> > > > have been
> > > > labeled D-AR006.12 in the document. Am I reading this
> > > > correctly? If so,
> > > > then this needs to be fed to the editors as a comment 
> so that it is
> > > > certain to be tracked (and fixed in the next editor's draft).
> > > >
> > > > The question I have then is whether or not Joe is accepting
> > > > Ayse's request to add Auditing to this list of 6 aspects
> > > > or whether he is suggesting that yet another requirement
> > > > (D-AR006.13) be created to accomodate Auditing... do any others
> > > > have an opinion on this?
> > >
> > > I think Ayse has already backed out on Auditing.
> > > So it's no longer an issue whether I'd accept it.
> > > (I wasn't inclined to accept it because there's no
> > > threat model that's uniquely associated with Auditing.
> > > But I wouldn't decide one way or the other without
> > > hearing the case out first.)
> > >
> > > Whoever wants to give it another shot is welcome to
> > > present his/her *reasoning and analysis*.
> > >
> > > Cheers,
> > >
> > > Joe Hui
> > > Exodus, a Cable & Wireless service
> > > ==================================================
> > > >
> > > > Thanks,
> > > >
> > > > Chris
> > > >
> > > > Joseph Hui wrote:
> > > >
> > > > >>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > > > >>
> > > > > [snip]
> > > > >
> > > > >
> > > > >>D-AR006.11 the six aspects need to be replaced with the
> > > > >>following seven aspects of the security framework:
> > > > >>
> > > > >
> > > > > Ayse, the D-AR006.11 number was taken.
> > > > > You may want to re-number your proposal as D-AR006.12 instead
> > > > > if you're serious about it (to be voted on or debated).
> > > > >
> > > > >
> > > > >>Auditing;
> > > > >>
> > > > >
> > > > > Auditing* as a security aspect?
> > > > > Can you explain why?  E.g. for starter, how would you
> > > > > characterize the threat (model) that's unique to Auditing?
> > > > > Note that the impetus for requiring each of the original
> > > > > six begins with a unique threat, or in some cases, threats.
> > > > >
> > > > >
> > > > >>Authentication (includes identification and authorization);
> > > > >>
> > > > >
> > > > > Authc & Authz are separate sec aspects.
> > > > >
> > > > > Example 1: The security policy of the very system that you're
> > > > > using probably includes only Authz but not Authc.  To login,
> > > > > you simply enter user name and password, the system checks
> > > > > the password file and lets you in.  You are not asked to
> > > > > authenticate yourself as Ayse.  BTW, password file is known
> > > > > to be one form of Access Control List (ACL).
> > > > >
> > > > > Example 2: Alice's security policy includes Authc & Authz.
> > > > > To join Alice's party, Bob must present a certificate to
> > > > > Alice to authenticate himself as Bob -- Authc, AND, after
> > > > > successful authc (sometimes aka positive identification),
> > > > > Alice checks whether Bob is on her guest list (i.e. ACL)
> > > > > before allowing him into her party.
> > > > >
> > > > >
> > > > >>Access Control (file permission, etc.);
> > > > >>
> > > > >
> > > > > Access Control is just a Authz means.  (See example 2 above.)
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Joe Hui
> > > > > Exodus, a Cable & Wireless service
> > > > > ========================================================
> > > > >
> > > > >
> > > > >>Confidentiality;
> > > > >>Availability; Integrity; Non-repudiation.
> > > > >>Thanks,
> > > > >>Ayse
> > > > >>
> > > > >>-----Original Message-----
> > > > >>From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > > > >>Sent: Saturday, May 04, 2002 10:00 AM
> > > > >>To: wsawg public
> > > > >>Subject: D-AR006.11 discussion points
> > > > >>
> > > > >>
> > > > >>SUNW: This requirement goes "inside" a web service and places
> > > > >>requirements
> > > > >>on how it is designed.  We should be focusing on externally
> > > > observable
> > > > >>(through the web service interfaces) behaviour
> > > > >>
> > > > >>SYBS: Implementation details. Don't seem to fit in Web
> > > > >>Services Architecture
> > > > >>group..
> > > > >>
> > > > >>W3C: See
> > > > 
> >>http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0015.html
> > > > >>
> > > > >>ORCL: I don't quite see how "an architecture" can actually
> > > > provide an
> > > > >>interface. And in this case the goal may be too ambitious
> > > given the
> > > > >>number of different possible "infrastructures".
> > > > >>
> > > > >>PF: I just don't see the need for this.
> > > > >>
> > > > >>TIB: not clear to me that individual Web services would
> > > ever want to
> > > > >>know whether they were under DOS at some lower layer
> > > > >>
> > > > >>CrossWeave: Don't understand this
> > > > >>
> > > > >>CMPQ: The interface is for negotiating services that an
> > > > >>infrastructure may
> > > > >>provide to, or perform on behalf of, a requesting Web 
> Services.
> > > > >>Such value-added services may include: security, 
> content delivery,
> > > > >>QoS, etc. For instance, a Web service may instruct (via the
> > > > >>interface) the security
> > > > >>agents of its infrastructure to defend against DOS/DDOS
> > > > >>attacks on its behalf.
> > > > >>
> > > > >>This seems to say that the requirement is
> > > > >>"The security framework must provide for negotiations
> > > pertaining to
> > > > >>security considerations."
> > > > >>
> > > > >>That is, the requirement is for negotiation support;  within
> > > > >>security context,
> > > > >>it is security negotiation, within QoS context, it is QoS
> > > > >>negotiation, etc.
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> 
> 
>

Received on Thursday, 9 May 2002 01:28:42 UTC