RE: D-AG006 Security

Allen,

i do second your remark.
The discussion on security clearly indicate that there is the need for
having a WG that sepcifically deals with the subject.

I think that the birth of the security group should come out as a result of
the WG work.

abbie


> -----Original Message-----
> From: Allen Brown [mailto:allenbr@microsoft.com]
> Sent: Thursday, March 14, 2002 3:10 PM
> To: David Orchard
> Cc: www-ws-arch@w3.org
> Subject: RE: D-AG006 Security
> 
> 
> Dave,
> 
> Indeed, this is exactly the sort of thread I'd expect to evolve in
> chartering, setting goals for, and setting requirements for a Web
> Services Security WG.
> 
> I'd add to your qualitative facets of security: supporting end-to-end
> security for both seeking and providing Web Services.
> 
> Allen
> 
> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com] 
> Sent: Monday, March 11, 2002 1:52 PM
> To: www-ws-arch@w3.org
> Subject: RE: D-AG006 Security
> 
> 
> This discussion is getting into requirements, WSA process, artifacts,
> etc. and not goals.
> 
> Why not keep the security goals pretty simple, like listing 
> the typical
> facets of authentication, authorization, etc?  And say that 
> the security
> facets apply to web service message exchange, interface definition and
> discovery?
> 
> Remember, goals not requirements.
> 
> Cheers,
> Dave
> 
> 
> 
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Joseph Hui
> > Sent: Monday, March 11, 2002 11:04 AM
> > 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.
> >
> > 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
> > > >
> > >
> >
> >
> 
>