RE: D-AR006.11 discussion points

Sorry about my e-mail problems, I think the majority of it has been resolved.  

Here is another proposal:

FROM: 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.

TO: There are three security primitives in the security framework for Web
Services architecture: Confidentiality, Availability, and Integrity. And,
together with Authentication (includes identification and authorization),
Access Control (file permission, etc.), Non-repudiation, and Auditing make
up the seven the security principles that form the foundation for secure Web
Services.

ADD to the requirements statements:
     - The security framework must include Auditing.

-----Original Message-----
From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
Sent: Wednesday, May 08, 2002 7:50 PM
To: Christopher Ferris
Cc: Dilber, Ayse, ALASO; 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 3:50 PM
> To: Joseph Hui
> Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
> Subject: Re: D-AR006.11 discussion points
> 
> 
> Joe,
> 
> What is a "security primitive" per se? My understanding of
> security is based on the premise of risks and balanced
> countermeasures based on the level of risk assessed
> for each resource. I have never heard of a "security
> primitive" before so I have no idea how to respond
> to your question.

Off the top of my head, the established security primitives
include: encryption (for Confidentiality); message digest (for
data Integrity; Public Key Encryption (PKE, for key
establishment, which may be further broken down to
key exchange and key agreement); digital signature
(for non-repudiation), ...  I think you get gist by now.

(Just like doing computer graphics, you have point,
draw, fill, ... as graphic primitives.)

> IMO, auditing as a service *might* be something we
> consider as an important aspect of web services
> security. 

I agree it can be important, but not to the point of
being the equal of the original six.

> Or, we might conclude that in terms of priority
> that other countermeasure technologies should be considered
> ahead of auditing. But that's beside the point.
> 
> The six "facets" you cite are in fact (IMHO) merely six
> countermeasures which comprise but a subset of the
> total arsenal of countermeasures that might be applied
> to mitigate a risk. Auditing is another, equally valid,
> countermeasure that is (or should be!) often employed
> within the fabric of a secure environment. There are
> other non-technical (and IMHO, far more important)
> countermeasures (management comes to mind, without which
> all the glitzy technicological countermeasures one
> can imagine can be rendered useless overhead) that could
> also be included in the list.

Are we going to roll admin/operational elements into the mix now?
I thought there was already enough grief given to D-AR006.7
through 6.8.  They are admin/operational-ish.

> Why is it that you are so adamantly opposed to its (Auditing)
> inclusion in this list? 

Let's not jump to conclusions.  I haven't made up my mind yet
whether to oppose it, let alone adamantly. 
For Pete's sake, what's the final wording of the req? 

I have already expressed my reservation about grouping Auditing
in as a sec aspect.  (Ayse was having mail problem and I'm
still waiting on the response that she said she'd sent me.)
And I've already responded (favorbly, mind you :-) to the
one proposed by Steven A. Monetti.

> A number of others have chimed in suggesting
> that its inclusion would be "a good thing(tm)".

No argument ever from me against Auditing being a good thing.

> Would you be willing to live with its inclusion?

Inclusion as a separate req; or inclusion as replacement to
supplant the original six?  Like implied earlier, I can
live with the simple wording proposed by Steven.
Will that be the final wording?

Cheers

Joe Hui
Exodus, a Cable & Wireless service
=========================================
> 
> Cheers,
> 
> Chris
> 
> 
> 
> Joseph Hui wrote:
> 
> >>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 10:32:59 UTC