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.

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 17:27:31 UTC