RE: D-AG006 Security

ORCL would certainly support such an effort. I'd be willing to help draft 
such a charter, not that you guys need any more help.
     jeff

At 12:45 PM 5/7/02, David Orchard wrote:
>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
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >

--
Jeff Mischkinsky                    jeff.mischkinsky@oracle.com
Consulting Member Technical Staff   +1(650)506-1975 (voice)
Oracle Corporation                  +1(650)506-7225 (fax)
400 Oracle Parkway, M/S 4OP960
Redwood Shores, CA 94065 USA

Received on Monday, 13 May 2002 11:34:58 UTC