RE: D-AG006 Security : Proposal for a task force for writing the Security WG Charter

I will work with you to write the charter.
Ayse

-----Original Message-----
From: Abbie Barbir [mailto:abbieb@nortelnetworks.com]
Sent: Tuesday, May 07, 2002 4:00 PM
To: David Orchard; Dilber, Ayse, ALASO; 'Joseph Hui'; 'Edgar, Gerald'; 'Allen Brown'
Cc: www-ws-arch@w3.org
Subject: RE: D-AG006 Security : Proposal for a task force for writing the Security WG Charter




David, chris, 

I agree with you, we should write the charter in a month or so. 

Here, I propose to start a task group that could do that. 

Chris, 

can we have a task force that write the charter for the Security WG. 
I do volunteer to be the editor for that activity. 

abbie 


-----Original Message----- 
From: David Orchard [ mailto:dorchard@bea.com] 
Sent: Tuesday, May 07, 2002 3:46 PM 
To: 'Dilber, Ayse, ALASO'; 'Joseph Hui'; 'Edgar, Gerald'; Barbir, Abbie 
[CAR:1A00:EXCH]; 'Allen Brown' 
Cc: www-ws-arch@w3.org 
Subject: RE: D-AG006 Security 


I think there's some irony that almost 100% of the group knows or agrees 
that we will have a web services security working group, that it's perhaps 
our highest priority, but yet we can't quite seem to bash through some 
details and kick out a charter. 

I seriously think if we said something like: 

- specify a trust model for end to end security 
- authentication - some issue about which types of authn 
- message integrity - some issues about whether just soap or attachments 
- confidentiality. 

About 75% of the working group would roughly agree.  We actually understand 
these usage scnarios pretty well.  The usage scenarios lists, though don't 
go into detail, these scenarios with a priority of high. 

Reality is, I think we could write a charter for that WG in very short 
order.  Heck, we could probably have a charter in front of the WSACG in less 
than a month on this with some focus. 

Our methodology all along is that we ought to focus on a few WGs, including 
security, and kick them off as quickly as possible. 

I am fully prepared to do whatever work is necessary to expedite this. 

Cheers, 
Dave 

> -----Original Message----- 
> From: www-ws-arch-request@w3.org [ mailto:www-ws-arch-request@w3.org]On 
> Behalf Of Dilber, Ayse, ALASO 
> Sent: Tuesday, May 07, 2002 12:10 PM 
> To: Joseph Hui; Edgar, Gerald; Abbie Barbir; Allen Brown; 
> David Orchard 
> Cc: www-ws-arch@w3.org 
> Subject: RE: D-AG006 Security 
> 
> 
> to have a separate WG to deal with security issues. 
> ayse 
> 
> -----Original Message----- 
> From: Joseph Hui [ mailto:Joseph.Hui@exodus.net] 
> Sent: Tuesday, May 07, 2002 2:55 PM 
> To: Dilber, Ayse, ALASO; Edgar, Gerald; Abbie Barbir; Allen 
> Brown; David 
> Orchard 
> Cc: www-ws-arch@w3.org 
> Subject: RE: D-AG006 Security 
> 
> 
> What exactly is the proposal here? 
> 
> Joe Hui 
> Exodus, a Cable & Wireless service 
> ============================================= 
> 
> > -----Original Message----- 
> > From: Dilber, Ayse, ALASO [ mailto:adilber@att.com] 
> > Sent: Monday, May 06, 2002 8:57 AM 
> > To: Edgar, Gerald; Abbie Barbir; Allen Brown; David Orchard 
> > Cc: www-ws-arch@w3.org 
> > Subject: RE: D-AG006 Security 
> > 
> > 
> > i support this proposal. 
> > Ayse 
> > 
> > -----Original Message----- 
> > From: Edgar, Gerald [ mailto:gerald.edgar@boeing.com] 
> > Sent: Monday, May 06, 2002 11:49 AM 
> > To: 'Abbie Barbir'; Allen Brown; David Orchard 
> > Cc: www-ws-arch@w3.org 
> > Subject: RE: D-AG006 Security 
> > 
> > 
> > I second this... 
> > 
> > 
> > Gerald W. Edgar <Gerald.Edgar@Boeing.com> 
> > Architecture support, BCA Architecture and e-business 
> > 425-234-1422 
> > 
> > Mailing address: 
> > The Boeing Company, M/S 6H-WW 
> > PO Box 3707, Seattle, WA 98124-2207 
> > USA 
> > 
> > 
> > 
> > -----Original Message----- 
> > From: Abbie Barbir [ mailto:abbieb@nortelnetworks.com] 
> > Sent: Friday, March 15, 2002 6:29 
> > To: Allen Brown; David Orchard 
> > Cc: www-ws-arch@w3.org 
> > Subject: 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 
> > > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
>

Received on Tuesday, 7 May 2002 16:08:30 UTC