RE: D-AR006.11 discussion points

Folks,

Isn't it the case that to accomplish Non-Repudiation one has to implement
auditing of some kind? If so, Auditing DOES NOT belong in security 
architecture discussions or is NOT A REQUIREMENT.

Comments?

Sandeep Kumar
Cisco Systems

Joseph Hui wrote:

>>-----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 Wednesday, 8 May 2002 20:26:27 UTC