RE: D-AR006.11 discussion points

Joe,

Are you proposing that we have a goal that says we must support these
primitives? I'd prefer to have goals that simply state the requirements:
- define a trust model
- ensure message integrity
- message confidentiality
- authentication
- authorization
- non-repudiation

And then let the WG determine how to apply the primitives to address these
requirements. Since auditing is generally required to achieve
non-repudiation, it will be included.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Joseph Hui
> 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 Friday, 10 May 2002 08:19:13 UTC