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 Thursday, 9 May 2002 01:28:47 UTC