- From: Joseph Hui <Joseph.Hui@exodus.net>
- Date: Thu, 9 May 2002 10:11:05 -0700
- To: <www-ws-arch@w3.org>
Hi all, I've just read my own message sent last and realized that the following text: > (There're corner cases one can use > to make arguments over this characterization. I'll > leave them as homework for those who may want to argue.) could be misconstrued as a discouragement for our continuing "lively" debate over the issues. I didn't and don't mean to imply any of us have been argumentative. Please chime in any time. Regards, Joe Hui Exodus, a Cable & Wireless service =========================================== > -----Original Message----- > From: Joseph Hui > Sent: Thursday, May 09, 2002 9:47 AM > To: 'Dilber, Ayse, ALASO'; Christopher Ferris; www-ws-arch@w3.org > Subject: D-AR006.12 [Was RE: D-AR006.11 discussion points] > > > > From: Dilber, Ayse, ALASO [mailto:adilber@att.com] > > Sent: Thursday, May 09, 2002 7:32 AM > > To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org > > Subject: 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. > > This is the first time I've heard "Confidentiality, > Availability, Integrity" be referred to as security primitives. > I've already explained the conventional meaning of > security primitives in couple other messages, so > won't repeat here. I participate/tune in many security > forums, but not all. So I could have missed it somewhere, > though I doubt it. Perhaps you could show me where. > > My advise to the WG is that we should stick to nomenclatures > that are more conventionally known or used in *credible* > security publications/discourses, and refrain from re-inventing > new meanings for established terminologies unnecessarily. > It follows that we stay with the "aspects/facets" terms > when referring to Accessibility, Authc, Authz, Conf, > Integrity, and Non-rep. > > Also, Availability is not the same as Accessibility in > the strictest sense. E.g. you can have a website > available all day (by having triple backup sites > irrespective of security), yet a consumer can't > access it because its (the consumer's) DNS server > has been spoofed. The former pertains to the WS > provider only, the latter concerns both the provider > and consumer. (There're corner cases one can use > to make arguments over this characterization. I'll > leave them as homework for those who may want to argue.) > > > 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. > > Again, nomenclature issue: the term "principle(s)" connotes > "how to do something better." We want to convey "what > constitutes the foundation" in the sentence, because the > paragraph is meant to be a lite intro for the few reqs to > follow. Additionally, as I said in a previous message, > "Access Control (file permission, etc.)" is an Authz means. > > > ADD to the requirements statements: > > - The security framework must include Auditing. > > IMO, this is good -- something I can recommend to the WG > and the public. So, unless there're objections, the following > is going to the WG's floor: > > D-AR006.12 -- > The security framework must include Auditing. > > Editors, please take note of the D-AR006.12 addition. > > Thanks, > > Joe Hui > Exodus, a Cable & Wireless service > ======================================== > > > > > > -----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 13:11:13 UTC