RE: D-AG006 Security

Hi Joseph,

I like many of the suggestions you put forward below.
Specific comments below to expand the thoughts out some more.
Cheers,
-Suresh

-----Original Message-----
From: Joseph Hui [mailto:jhui@digisle.net]
Sent: Monday, March 11, 2002 1:04 PM
To: Damodaran, Suresh; www-ws-arch@w3.org
Subject: 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.

<sd>
I agree, though, as I point out in my earlier message proving
these use cases are sufficient would be a difficult job.
We have to have an abstract security model or equivalent to prove the
sufficiency.
We may be inching our way towards that per your comments below.
</sd>

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.  

<sd>
Yes, boundaries vary between the different categories of use cases
(I assume that you mean use cases when you say "applications" in this case).
Perhaps a good starting point of this effort is to define what are
	1. Ws-Endpoints (need the help of the larger team to define these)
	2. What qualification or assumptions make each such end-point as a
"security boundary" (by defn. or otherwise)
	3. What policies *can* be in place at each end-point.
	4. Are there interesting patterns emerging that can be designated as
a WS-Sec wide
	policy element.
</sd>

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.

<sd> Are the immediate objectives any different than the long term
objectives? Did I misunderstand something?
</sd>

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); 
<sd> Yes, hopefully I have helped to expand the idea further in my comments
earlier,
let me repeat them here for completion.
	1.1. Ws-Endpoints (need the help of the larger team to define these)
	1.2. What qualification or assumptions make each such end-point as a
"security boundary" (by defn. or otherwise)
	1.3. What policies *can* be in place at each end-point.
	1.4. Are there interesting patterns emerging that can be designated
as a WS-Sec wide
	policy element (can help finding principles in 3.2, below)

</sd>
  2) develop a model that captures the policy;
<sd> yes </sd>
  3) translate the model into WS architectural elements,
     aka "modules" in WSAWA charter's nomenclature; and
<sd>
Though I agree the step 3 would be fine in a product, I somewhat differ in
how
step 3 should happen in WS-A. Like to hear your comments.
I think we should 
	3.1 strive to find the most risky threats the model could face.
	3.2 Outline general principles that could be used as guide lines
	across the whole framework. I can think of at least one principle
that could
	be applied that I will expand later should you think this approach
is workable.
	3.3. Outline how the principles should be used to create security
supportive
	infrastructures in each standard within the framework. It might be
creating
	architectural elements if commonly used and separable (as you
outlined above)
	(credentials management might be a good example here), 
	or adding interfaces within each standard.
</sd>
  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? 
<sd> Sounds fine.
</sd>
 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?

<sd>
Sure, since you asked:-)
I find that goal unrealistic and impossible to achieve (as stated).
"AG006 -- addresses the security of web services across
distributed domains and platforms"
I would restate it as follows to reflect what can be done.
"AG006 : supports securing of web services implemented in heterogeneous
environments"
(the key points here:
	1. WS-A will not inhibit any effort to secure web services in
whatever manner
	2. WS-A will support such efforts, if not comprehensively, by
providing primitives,
	advisories, whatever
	3. Security applies to only *implemented* web services (the paper
tigers can rest),
	and implemented web services can have concerns that are outside of
WS-A purview.
The "heterogeneous environment" is an editorial change.
</sd>

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 19:35:55 UTC