W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

RE: D-AG006 Security

From: David Orchard <david.orchard@bea.com>
Date: Sat, 16 Mar 2002 09:35:51 -0800
To: "'Anne Thomas Manes'" <anne@manes.net>, "'Abbie Barbir'" <abbieb@nortelnetworks.com>, "'Allen Brown'" <allenbr@microsoft.com>
Cc: <www-ws-arch@w3.org>
Message-ID: <01b001c1cd11$062bdac0$420ba8c0@beasys.com>
RE: D-AG006 SecurityAnne, I somewhat share your trepidation.  This could be
the most straightforward WG to kick off, if we focus properly.  9 months
would put us in December.  I think the AC members would be very agitated we
didn't have at least 1 or 2 new WGs chartered up by the November AC meeting.

However, I'm hopeful that if the group came up with a straightforward set of
goals and requirements, such as "carry digital signatures", we could kick of
a group earlier than that.  My probably hopeful timeframe was that we had
something in the summer time frame.  I'm leaning to believe that at least 2
soap headers WGs need to be formed in our first round of WG formation, one
for security and one for asynch/reliable/conversations.  If it turns out
that our goals and reqs for security match fairly well with existing work,
like "carry dsig" req matches with soap-sec and parts of ws-sec, then this
should be fairly "startable".

I think this will be determined by whether the group wants the "WS-Sec" WG
to a minimalist or a maximalist effort.  If we can all agree to do a focused
effort on one or two well known problems, there should be tremendous upside
for us.  The WSActivity has yet to prove that it can function successfully,
so I think we should do the most focused effort we can to prove to ourselves
and the community that we are a functional group.  But that's just
motherhood and American apple pie for a new architecture and stds group..

Cheers,
Dave
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Anne Thomas Manes
  Sent: Saturday, March 16, 2002 7:49 AM
  To: Abbie Barbir; Allen Brown; David Orchard
  Cc: www-ws-arch@w3.org
  Subject: RE: D-AG006 Security


  I wonder if it will take another 9 months to get this working group
started.
    -----Original Message-----
    From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Abbie Barbir
    Sent: Friday, March 15, 2002 9:29 AM
    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 Saturday, 16 March 2002 12:37:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:56 GMT