W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

RE: D-AR006.11 discussion points

From: Joseph Hui <Joseph.Hui@exodus.net>
Date: Wed, 8 May 2002 15:54:38 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D5523BB4C@SJDCEX01.int.exodus.net>
To: "Narahari, Sateesh" <Sateesh_Narahari@jdedwards.com>, "Christopher Ferris" <chris.ferris@sun.com>
Cc: "Dilber, Ayse, ALASO" <adilber@att.com>, <www-ws-arch@w3.org>
Sateesh,

I've just sent you the "expert names/refs" in a private reply.
(I do not give out names in public.)

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

> -----Original Message-----
> From: Narahari, Sateesh [mailto:Sateesh_Narahari@jdedwards.com]
> Sent: Wednesday, May 08, 2002 3:38 PM
> To: Joseph Hui; Christopher Ferris
> Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> Subject: RE: D-AR006.11 discussion points
> 
> 
> could you please provide some pointers to these "security experts" you
> mention below, and their reasoning why they wouldn't 
> categorize it as the
> "original six"
> 
> Here is a link to security considerations :
> http://www.cpfr.org/SecurityConsiderations.html
> 
> This group aims to create collaborative relationships between 
> buyers and
> sellers through co-managed processes and shared information. 
> The reason I
> refered it here is, these folks may be a good set of users 
> for web services.
> 
> 
> Regards,
> Sateesh 
> -----Original Message-----
> From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> Sent: Wednesday, May 08, 2002 4:11 PM
> To: Christopher Ferris
> Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> Subject: RE: D-AR006.11 discussion points
> 
> 
> > From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > Sent: Wednesday, May 08, 2002 2:25 PM
> > To: Joseph Hui
> > Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> > Subject: Re: D-AR006.11 discussion points
> > 
> > 
> > Joe,
> > 
> > As with AuthN and AuthZ, it is a countermeasure used
> > to mitigate a security threat(s) such as when AuthN and
> > AuthZ have been (somehow) circumvented. It is also
> > useful to protect against abuse of privileges that
> > may have been granted.
> 
> Chris,
> 
> I'm well aware of the benefits of auditing -- nuts and
> bolts and trimmings; and what auditing may mean in various
> contexts.  (Exodus is a well established vendor of Security
> Audit services, albeit Ayse's notion of Auditing is more
> like logging and our products cover far more than that.)  
> 
> However, I wouldn't elevate it to a "security aspect/facet"
> equal to the original six commonly known to security experts.
> The experts no doubt know what Auditing can mean in the
> context of security, but wouldn't group it in the company
> of the original six for sure.
> 
> Can you think of a security primitive that does Auditing?
> 
> Cheers,
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> =================================================
> 
> 
> 
> > 
> > Cheers,
> > 
> > Chris-sans-chapeau
> > 
> > Joseph Hui wrote:
> > 
> > >>-----Original Message-----
> > >>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> > >>Sent: Wednesday, May 08, 2002 2:02 PM
> > >>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
> > >>Subject: RE: D-AR006.11 discussion points
> > >>
> > >>
> > >>i don't know if you will receive this but i'm having lots of 
> > >>e-mail problems today, i thought i answered your question in 
> > >>a different message but it sounds like it wasn't delivered.  
> > >>so here it is:
> > >>
> > > 
> > > Well, here it is what?  Another mail problem? ;-)
> > > Please take your time, Ayse.
> > > Fix you mail first; the world can wait. :-)
> > > 
> > > Joe Hui
> > > Exodus, a Cable & Wireless service
> > > =============================================
> > > 
> > >>-----Original Message-----
> > >>From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> > >>Sent: Wednesday, May 08, 2002 4:41 PM
> > >>To: Dilber, Ayse, ALASO; Christopher Ferris; www-ws-arch@w3.org
> > >>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 Wednesday, 8 May 2002 18:54:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:59 GMT