RE: D-AG006 Security

Hi Suresh,

So there's the apparent agreement that listing use cases
exhaustively is not the way to go, i.e. a few well
thought-out examples will do.

In my view the system boundaries may indeed vary between
applications.  In fact, in some cases, say XML-Encryption,
the notion of system boundaries in the tradition sense
is immaterial, and may even get in the way.  Perhaps in
WSsec the notion of "system boundaries" should be re-invented
to be "security boundaries," which will enclose the security
policies of the union of (the sets) of security policies
of all WS endpoints involved in a transaction.  Note that
in WSsec each WS endpoint can have its own security policy.  

I agree we should indeed try not to delve into too much
detail, especially mechanisms -- none at all if possible
at this juncture.  So we can stay focused on our more
immediate objectives.

For the long term, there's a set of steps I'm thinking of
to approach this WSsec deal methodically:
  1) develop a WS-Arch security policy -- the policy
     of all policies (of all WS endpoints); 
  2) develop a model that captures the policy;
  3) translate the model into WS architectural elements,
     aka "modules" in WSAWA charter's nomenclature; and
  4) implement the modules with mechanisms.  (Note that
     a WS endpoint only needs to implement/deploy a subset
     of the modules according to its own security policy.)
(Steps 1 through 3 are the WSAWG's gig.  Step 4 will be
left to the implementers/vendors.)
Does this sound reasonable to you?  And to the group?

BTW, do you find the D-AG006 goal statement as-is acceptable?
(I do, BTW.)  Care to share any thoughts on it?

Cheers,

Joe
=================
> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Monday, March 11, 2002 9:12 AM
> To: Joseph Hui; www-ws-arch@w3.org
> Subject: RE: D-AG006 Security
> 
> 
> 
> Joseph,
> 
> More comments below.
> I have some additional thoughts that I will send separately, 
> when ready.
> This is a hard topic, and it is a challenge for us to get the right
> "stuff" done for the WS-Sec
> 
> -----Original Message-----
> From: Joseph Hui [mailto:jhui@digisle.net]
> Sent: Friday, March 08, 2002 8:11 PM
> To: Damodaran, Suresh; www-ws-arch@w3.org
> Subject: RE: D-AG006 Security
> 
> 
> > -----Original Message-----
> > From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> [snip]
> > 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.
> 
> <sd>
> I agree with "can" part. We might document this thought in 
> the proposal
> for clarification. Indeed, my suggestion for categorization
> was to lead to a "proof" that WSA cannot foresee all possible 
> scenarios, and would possibly have to limit to suggesting
> "toolkit standards" (i.e., standards that are applicable
> for generic techniques, say signing). Is this an agreeable
> thought to all? One possible class of exceptions to this
> rule is a set of combinations of techniques that are 
> widely useful in the applications that use WS-Arch.
> E.g., Ensuring confidentiality and integrity of
> a message send from point-to-point (i.e., when there is no 
> intermediary),
> WSSec may suggest signing/encryption sequence with appropriate
> security considerations. At this time, I am not even
> sure we need to get to this level. Others might have some opinions
> on this, especially since different application 
> domains/products may choose
> to do these differently.
> </sd>
> 
> > 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.
> 
> <sd>
> As you would agree, given the combinations possible,
> keeping an exhaustive use case list will be pretty hard,
> if not theoretically impossible. The hard part is in showing
> that the use cases we have are sufficient.
> </sd>
> 
> > 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.
> 
> <sd>
> Are you saying that the implementer of the web service decides
> the boundary?
> I am a bit intrigued by the term "security semantics are complete"
> (This idea does sound promising) What does it mean to you?
> Can we define security semantics to any scenarios, or even
> abstract security semantics?
> 
> Friendly ASIDE:
> 	As for the repertoire of security primitives being sufficient to
> deal
> 	with WS- use cases, I would say, in theory yes, but in practice,
> 	to achieve "interoperable security" the parties involved have to
> 	go through a "hell of a journey" to make it work. WS-Sec may
> 	safely stay away from that hell by only prescribing primitives.
> </sd>
> 
> > 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.
> 
> <sd>
> 
> If the boundary is defined by the implementer, may be it doesn't
> matter, because, the implementer would have defined the roles
> of humans and their actions within the scenario. 
> Otherwise, it would make sense to define the role of humans 
> and security
> implications in WSSec.
> </sd>
> 
> Cheers,
> -Suresh
> 
> 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 Monday, 11 March 2002 14:04:04 UTC