- From: Joseph Hui <Joseph.Hui@exodus.net>
- Date: Fri, 10 May 2002 11:17:32 -0700
- To: "Christopher Ferris" <chris.ferris@sun.com>, <www-ws-arch@w3.org>
Chris, What's your point? I can give you a billion hits if I care to pay $49.95 a month for a website and fill it with fluff if only hits count. There're books written by industry recognized experts and archives in ICSA, IETF, etc that I can bring to the pissing contest. But, why bother. This is public list. The informed readers can judge for themselves what nomenclatures are more proper anyway. Joe Hui Exodus, a Cable & Wireless service ================================================ > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Friday, May 10, 2002 6:54 AM > To: www-ws-arch@w3.org > Subject: Re: D-AR006.12 [Was RE: D-AR006.11 discussion points] > > > Hmmm... > > I did a search for "security primitives" and get only > 666 (spooky!) hits[2]. > > I did a search on "security countermeasures" and get > 3,350 hits[3]. Seems to me to be a more widely used > term than "security primitives" (which I had never > previously heard used, and I've been around a while:) > > A search on "security principles" will get you 10,100 > hits[1], the most interesting of which is[4] (parented by > [5]). The interesting thing there is that this body > The International Information Security Foundation (I2SF), > cites 3 "Pervasive" security principles (e.g. rule or standard, > see [6]) which are: > Confidentiality > Integrity > Availability > > Cheers, > > Chris > > [1] http://www.google.com/search?q=%22security+primitives%22 > [2] http://www.google.com/search?q=%22security+countermeasures%22 > [3] http://www.google.com/search?q=%22security+principles%22 > [4] http://web.mit.edu/security/www/GASSP/gassp021.html > [5] http://web.mit.edu/security/www/gassp1.html > [6] http://www.dictionary.com/search?q=principle > > Joseph Hui wrote: > <snip/> > > > > 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 Friday, 10 May 2002 14:17:10 UTC