RE: D-AR006.11 discussion points

I can say that as a vendor of security products, security relevant audit
is considered by most as an integral part of a unified security
infrastructure. I would second including this. 

As you are all no doubt aware, the AuthN and AuthZ are very often
included with Audit and Administration to form the "Four A's" of
security. I would like to propose we also include the fourth 'A' for
Administration.  

The last two 'A's are often ignored as they are focused on the onward
operation of a deployed service.  Ignoring the last two A's will
doubtlessly restrict rollout, adoption and general success of a WS
initiative.  I therefore propose adding "Administration" to the 6.

For the spaghetti western fans out there may I now say "and then there
were 8" doo, doodle, doodle oo ;-)  - Magnificent Seven - 1960

--------------------------------------------------------
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
(512) 657 8360                    PGP  0x8AC67C6F   
--------------------------------------------------------


-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com] 
Sent: Wednesday, May 08, 2002 2: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."

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?

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 15:32:23 UTC