RE: D-AG006 Security

> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
[snip]
> Here are my comments. This is a great kickoff mail!
Thanks!

> 1. For the security terms, it would be useful to refer to
> a glossary for a consistent, unambiguous definition of terms.
> I propose we adopt RFC 2828 (http://www.ietf.org/rfc/rfc2828.txt) 
> as our glossary. 
Agreed. Excellent suggestion!
I'll see to that the editors get this.

Anyone who wishes to object please come forward (and provide your
reasoning for objection).

> 2. You have described the techniques one may use to secure
> *any* web service usage scenario. It would be useful to see
> whether there are categories of usage scenarios where some
> specific combination of techniques will make sense.
> For example, should accessing a "weather info service,"
> be secured using authorization, authentication? 
> Should the 
> weather info be ensured to be authentic and unaltered?
Whether should or should not depends on the weather info
WS provider and consumer.  It'll be their choice. 
We should only concern ourselves with the "can" factor --
can our WSsec ensure the weather info to be authentic and
unaltered?  By obligating ourselves to address authc, authz,
and integrity, we can say: "yes, the WS-Arch can."  
Just to ensure potential skeptics who may think
the "can" is easier said then done, I'm giving concrete
answers to your two questions, replacing "should" with "can".
For the first Q, the provider needs to keep an ACL, then the
two can either use Kerberos or SSL/TLS with client
authentication to take care of the Authz part.  For
the Auchc part, use HMAC. 
For the second Q, HMAC will also do nicely.

> Same questions for sending in a bill payment to a bank from
> a customer. If there are many categories, then we may see
> how to satisfy all of them in a generic way. Alternately,
> we may suggest techniques that may be generically adopted.

The use case list doesn't have to be exhaustive.
We only need exemplary cases to show the need for
addressing the security concerns being brought forward.
Hopefully someone on this mailing list would pitch in
some as we progress.  Regardless, I believe limited
empirical input will not stop us from coming up with
a well designd WSsec.

> 3. It would be good to define the "end points" of whatever
> scenarios we are securing. What are the boundaries of whatever
> we are securing? 

Indeed.  I believe there are well established definitions in
existence.  We just have to scrounge for them going forward.
The endpoint has to be understood to be the WS provider and
consumer.  (There can be intermediaries, of course, which
complicate to great extent the end-to-end argument that
most security models assume.)  Boundary, or the sense of
it that calls out for Accessibility and Authorization, is
relatively less significant in WSsec than in system security.
Nonetheless, it'd be good if one can be vigorously defined for WS.

> Is it from a s/w client to the web service?

It's the WS implementer's choice, e.g. client sends
plaintext request and gets encrypted response in return.
The WSsec doesn't care.  It doesn't have to, as long as
its security semantics are complete, thus its repertoire
of security primitives -- symmetric key encryption for
bulk data, asymmetric key encryption for symmetric key
exchange and for digital signature, message digest, just
to name a few -- can be sufficient to deal with just about
the most challenging WS use case anyone may come up with.

> Or, is it from the human client to the web service provider?

The human factor should be kept to a minimum, say confining
human involvement in WS endpoints to no more than private
key storage/retrieval, e.g. a system administrator may be
needed to type in a password to retrieve and decrypt an
encrypted private key needed for public key ciphers during
a WS server start-up.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
==============================================



> 
> Cheers,
> -Suresh
> 
> -----Original Message-----
> From: Joseph Hui [mailto:jhui@digisle.net]
> Sent: Thursday, March 07, 2002 7:40 PM
> To: www-ws-arch@w3.org
> Subject: D-AG006 Security
> 
> 
> Hi all,
> 
> As the volunteered "champion" (during today's telecon) for one of the
> WSAWG goals, "AG006 -- addresses the security of web services across
> distributed domains and platforms," I wish to solicit your interest
> in starting and sustaining a "spirited" discussion on web services
> security.  The primary objective (of the discussion) is to confirm
> the stated goal by *rough* consensus, and refine it (the goal, not
> the consensus ;-) if necessary.  The secondary objective is to
> harvest the upshot of the discussion and turn it into something
> we can use in near term for identifying "Critical Success
> Factors" -- whatever that may mean to you -- and requirements.
> Hopefully, by being mindful of the objectives, we can keep this
> thread reasonably focused.  However, please don't let the
> objectives adversely constrain your will to express.  You're
> welcome to disregard the objectives and throw in whatever you
> see fit in the spirit of doing good for web services security.
> 
> To get the ball rolling, let me start with the goal statement itself:
> 
>    AG006 -- addresses the security of web services across
>             distributed domains and platforms.
> 
> Q to all: Is the goal set to your satisfaction?  
>           Too broad, too narrow, too ...?
> 
> Answers/comments?
> 
> 
> To flesh out AG006 a bit more in terms of its implications,
> we can give it another whack at what addressing the web 
> services security (WSsec) should entail in the architecture 
> WS-Arch) to be designed.  Based on some previous discussions
> fragmented across several threads in www-ws-arch@w3.org, an
> assertion can be made that attaining goal AG006 entails 
> addressing six security aspects in computing:
>    1) Accessibility;
>    2) Authentication (of ID and data/messages);
>    3) Authorization;
>    4) Confidentiality;
>    5) (data) Integrity; and
>    6) Non-repudiation.
> 
> Comments?  
> 
> 
> Closely related to security is (the issue of) "trust."
> We shall have a security framework alright. The question is:
> should we include trust modeling as a part of the framework's
> design, (e.g.. what trust model(s) to recommend or adopt for web 
> services,) thus trust is a part of AG006; or should we deem "trust"
> outside the scope of AG006, thus we may need a separate goal?
> 
> Answers/comments?
> 
> 
> Also, there was the mention of "privacy" in the charter, right
> next to security.  Privacy can mean different things in
> different contexts, ranging from preventing one's home address
> disclosed to a web merchant from being sold to junkmailers to
> keeping one's ID anonymous in transactions. 
> I wasn't at the WS workshop last April, so have no clue
> what that was about.  Can someone shed some light on what the
> "privacy" is supposed to mean in our WS-Arch context, so we
> can determine whether it will be appropriate to lump it into
> AG006, or set a separate goal for it, or whatever?
> 
> Answers/comments?
> 
> 
> Please chime in.
> 
> Thanks,
> 
> Joe Hui
> Exodus, a Cable & Wireless service
>

Received on Friday, 8 March 2002 21:11:10 UTC