RE: Strawman list of goals for WSAWG - AG006

I agree that it would be a good idea to produce the 
following types of documents:

1) Web Services Security Use Case and Requirements
2) Web Services Risk Assessment 

These can be a good starting point to zero-in on
the specific web services security elements this group
should focus. For example:

1) Message and application level security applicable
   to web services;
2) How other W3C and OASIS specification can be 
   leveraged.

We also specifically do not want to produce any new
security protocols although we should identify what are
gaps in current protocols w.r.t. web services security
use cases.

---Zahid



-----Original Message-----
From: David Orchard [mailto:david.orchard@bea.com]
Sent: Friday, February 15, 2002 3:55 PM
To: www-ws-arch@w3.org
Subject: RE: Strawman list of goals for WSAWG - AG006


Let's not get into rhetoric.  The web cut huge corners in meeting security
requirements and does pretty well.  Security is really about risk
assessment.  If we wanted fully secure systems, we wouldn't connect them to
a network among other things.  The web meets a very reasonable level of
risk, and applications can decrease the level of risk in an modular manner.
As a great example, people consider SSL part of the "web" and it is
incredibly easy from a developer perspective to use http/ssl instead of
http.  But that has a significant performance impact - many sites use ssl
hardware encrypt/decrypt - so often sites have both ssl and non-ssl zones.
This gives control over the risk into the hands of the information supplier,
which is a good thing.

We do need to determine what levels of risk we are prepared to accept in our
specifications.  I specifically want to make sure we don't follow down a
path of "wonderful" security specifications - shttp, set, .. - that do not
end up being widely adopted.  Nor should we mandate an arbitrary level of
risk (ie always use ssl).

Where the group could also add value is in defining a migration path or best
practices between different risk levels and how web services could increase
or decrease the risk level they conform to.  ie "For greater security use of
a algorithm x in XMLEncryption for encrypting credentials in a web services
header, but this typically results in y decrease in performance and a
tighter coupling for synchronization of algorithm input z".

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Joseph Hui
> Sent: Friday, February 15, 2002 3:35 PM
> To: David Orchard; www-ws-arch@w3.org
> Subject: RE: Strawman list of goals for WSAWG - AG006
>
>
> > -----Original Message-----
> > From: David Orchard [mailto:david.orchard@bea.com]
> > Sent: Friday, February 15, 2002 2:58 PM
> > To: www-ws-arch@w3.org
> > Subject: RE: Strawman list of goals for WSAWG - AG006
> >
> >
> > Completeness can be a nice to have, but where does it fit in
> > the schedule?
>
> The context of this thread is security.
> Completeness fits snugly in security.
> Where does schedule fit in security?
>
> We have to be thorough when it comes to security.
> Incomplete security is as good as no security at all.
> If you're a manufacturer of safes, you must ship safe,
> not boxes.  If the time's up, and you haven't got a safe,
> then you ship boxes, or don't ship at all.
>
> I agree we should be t-o-m sensitive and wouldn't mind
> letting some minor things slide.  But there's no corner
> cutting in security.
>
> Cheers,
>
> Joe Hui
> Exodus, a Cable & Wireless service
> ==========================================================
>
> > Again, my suggestion is that we sketch out the rough areas of
> > requirements,
> > leaving all requirements not fully complete.  We then start a
> > select # of
> > working groups, and iterate to complete the requirements and receive
> > feedback on the initial requirements.
> >
> > I am strongly opposed to completeness of requirements being a
> > "requirement"
> > for starting additional working groups.  Again, time to
> > market is crucial
> > for us.
> >
> > The trade-offs that we will have to make will need to be
> > discussed further.
> > In the architecture documents I've produced in the past,
> > there is typically
> > a section for "non-functional" requirements (NFRs), like
> performance,
> > scalability, composability, reliability, ease-of-use, security,
> > evolvability, accuracy, interoperability, portability, etc.  This is
> > sometimes referred to as the "ilities" section.  There is never an
> > architecture that can fully match all the NFRs, so
> organizations make
> > choices about which ones to favour.  We will need to do the same.
> >
> > To look at a few NFRs, the web made scalability of # clients
> > and server
> > robustness extremely high priorities, compared to message
> > reliability or
> > security.   You can see this because there are no reliability
> > guarantees nor
> > security in the core web specs - adding ACLs and SSL came
> > later.  And it
> > never added non-repudiation or audit trails.  Even
> > performance at a message
> > level was not a high priority - typical RMI/CORBA/DCOM
> > systems outperform
> > HTTP for any given message interaction at a protocol level.
> > A wonderful
> > example of doing the right prioritization and ordering of
> > specification,
> > with completeness (in this example security and message
> > reliability) not
> > being high priorities.  I remember many a debate on why "distributed
> > objects" were going to win out over the web, but it turns
> out the web
> > priorities were much better made.  Hence why we are all here ;-)
> >
> > On the specific topic, I believe we can start with a sketch
> > of security, and
> > then after we have decided the requirements priorities, we
> > decide which
> > security requirements are addressed in which order.  I
> > believe completeness
> > of your step 2)(which I slightly change from security issues
> > to security
> > requirements) is not required before beginning your step 3).
> > FWIW, I favour
> > leaving audit trails and non-repudiation out of scope for us.
> >
> > To fully flesh out which requirements have priorities, we
> > also need use
> > cases.  Different security related use cases will help us
> > determine what we
> > need to stdize.
> >
> > Cheers,
> > Dave
> >
> > > -----Original Message-----
> > > From: www-ws-arch-request@w3.org
> > [mailto:www-ws-arch-request@w3.org]On
> > > Behalf Of Joseph Hui
> > > Sent: Friday, February 15, 2002 12:32 PM
> > > To: Edgar, Gerald; www-ws-arch@w3.org
> > > Subject: RE: Strawman list of goals for WSAWG - AG006
> > >
> > >
> > > Completeness should be a very-nice-to-have WS architectural
> > > quality.  (I'm not expecting arguments against it. :-)
> > > WS security is not complete if any of following five aspects
> > > is not addressed: confidentiality, authentication, authorization,
> > > integrity, and non-repudiation.  (See [1] for the example/use
> > > case I gave.)
> > >
> > > Accessibility should also be addressed, but IMHO only in the
> > > form of Security Consideration, because frankly there's not much
> > > one can do *effectively* at the XML layer against DOS/DDOS.
> > >
> > > Also, we can't really have a meaningful WS security discourse
> > > in an arch doc without first setting the premise of trust
> > > What's the trust model that will be most recommendable?
> > > I see issues such as this as more overriding in our current
> > > context.  We are at the goal setting stage; we have a goal;
> > > and the goal is good enough.
> > >
> > > So I suggest we not get hung up on the splitting thing at this
> > > juncture.  Instead, in steps: 1) keep the goal as-is; 2) start
> > > compiling what WS-Sec issues there are; 3) determine what we
> > > shall and shall not address, and set subgoals accordingly.
> > > Only at step 3 can we have a clear vision on what and how
> > > to do the splitting.
> > >
> > > BTW, I'm withholding my judgment on whether the IETF philosophy
> > > and models are directly transplantable to WS-Sec, notwithstanding
> > > my inclination to capitalize on the good Sec works from there.
> > >
> > > Cheers,
> > >
> > > Joe Hui
> > > Exodus, a Cable & Wireless service
> > >
> > > [1]
> > http://lists.w3.org/Archives/Public/www-ws-arch/2002Feb/0055.html
> > >
> >
> ======================================================================
> > >
> > > > -----Original Message-----
> > > > From: Edgar, Gerald [mailto:gerald.edgar@boeing.com]
> > > > Sent: Friday, February 15, 2002 10:22 AM
> > > > To: www-ws-arch@w3.org
> > > > Subject: RE: Strawman list of goals for WSAWG - AG006
> > > >
> > > >
> > > > I think that breaking this into Communications and Systems
> > > > security would be
> > > > sufficient.
> > > >
> > > > Systems security could in turn be addressed as message and
> > > > applications
> > > > security. Higher level would fit this effort better so
> > that we could
> > > > determine who is addressing these requirements. Security for
> > > > each area would
> > > > then cover the confidentiality, integrity, and
> > > accessibility aspects.
> > > >
> > > > for these I use:
> > > >
> > > > confidentiality : to protect data  against unauthorized
> > > disclosure to
> > > > unauthorized individuals or processes. (not privacy which
> > > > refers to the
> > > > right of someone to determine how it will interact with its
> > > > environment,
> > > > including how much to reveal)
> > > >
> > > > integrity : protecting against unauthorized changes to
> data, both
> > > > intentional and accidental-ensuring that changes to data are
> > > > detectable.
> > > >
> > > > availability : protection against unauthorized deletion or
> > > > otherwise cause a
> > > > denial of access to the data or service
> > > >
> > > >
> > > >
> > > > 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: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> > > > Sent: Thursday, February 14, 2002 17:09
> > > > To: www-ws-arch@w3.org
> > > > Subject: RE: Strawman list of goals for WSAWG - AG006
> > > >
> > > >
> > > > > > AG006 addresses the security of web services across
> > > > > > distributed domains and
> > > > > > platforms
> > > >
> > > > W.r.t. AG006, we need to address transport-, message-,
> > > > and application- level security for web services.
> > > >
> > > >
> > > > This does not imply that we split the security objectives
> > > > into three sub-areas necessarily though; it implies we
> > > > define the principal components of web services security
> > > > and their relationships with other elements of a web
> > > > services system (transaction, routing, registry, auditing,
> > > > etc.)
> > > >
> > > >
> > > > ---Zahid
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Joseph Hui [mailto:jhui@digisle.net]
> > > > Sent: Thursday, February 14, 2002 10:49 AM
> > > > To: Sandeep Kumar; Champion, Mike; www-ws-arch@w3.org
> > > > Subject: RE: Strawman list of goals for WSAWG
> > > >
> > > >
> > > >
> > > > Splitting sec into Message and Transport levels has one
> > disadvantage
> > > > I can think of: extra work.
> > > >
> > > > E.g. a connection between A & B conducting WS
> > transactions requires:
> > > > confidentiality, authentication, (mutual) authorization,
> > integrity,
> > > > and non-repudiation.  The five requirements can be
> > > satisfied by using
> > > > XML-sig messages over TLS with client authentication.  In
> > this case,
> > > > XML-sig is at Message level; and TLS is at Transport level.
> > >  Splitting
> > > > the sec work into two levels will necessitate extra work to
> > > > define some
> > > > glue between the two levels.
> > > >
> > > > Of course there may be advantages in splitting Ag006.  (What
> > > > may they be?)
> > > > I'd like the group to consider the above while
> > deliberating to split
> > > > or not to split.
> > > >
> > > > Cheers,
> > > >
> > > > Joe Hui
> > > > Exodus, a Cable & Wireless service
> > > > =================================================
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Sandeep Kumar [mailto:sandkuma@cisco.com]
> > > > > Sent: Thursday, February 14, 2002 9:56 AM
> > > > > To: Champion, Mike; www-ws-arch@w3.org
> > > > > Subject: RE: Strawman list of goals for WSAWG
> > > > >
> > > > >
> > > > > A good compilation!
> > > > >
> > > > > I think AG006 should be split into Message Level Security and
> > > > > Transport
> > > > > Level Security.
> > > > > Cheers,
> > > > >
> > > > > Sandeep Kumar
> > > > > Cisco Systems
> > > > > sandeep.kumar@cisco.com
> > > > >
> > > > > -----Original Message-----
> > > > > From: www-ws-arch-request@w3.org
> > > > [mailto:www-ws-arch-request@w3.org]On
> > > > > Behalf Of Champion, Mike
> > > > > Sent: Thursday, February 14, 2002 9:43 AM
> > > > > To: www-ws-arch@w3.org
> > > > > Subject: RE: Strawman list of goals for WSAWG
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Austin, Daniel [mailto:Austin.D@ic.grainger.com]
> > > > > > Sent: Thursday, February 14, 2002 12:02 PM
> > > > > > To: www-ws-arch@w3.org
> > > > > > Cc: Carroll, Tom
> > > > > > Subject: Strawman list of goals for WSAWG
> > > > > >
> > > > > Thanks for doing this, it is an excellent "strawman".  Let me
> > > > > take a few whacks at it ... If I don't mention something,
> > > > > it means I generally agree with the point as written.
> > > > >
> > > > > >
> > > > > > AG001 ensures the interoperability of web services software
> > > > > > products from
> > > > > > different implementors based on well-defined standards
> > > > >
> > > > > Isn't that a pretty ambitious goal for a "reference
> > architecture"?
> > > > > I would think that only the *designs* of software could be
> > > > > consistent in that they refer to the same concepts e.g.,
> > > > > "a Web service endpoint" in the same way.
> > > > >
> > > > > > AG005 provides simplicity and ease-of-use that does not
> > > > impose high
> > > > > barriers
> > > > > > to entry for users of web services
> > > > >
> > > > > Again, I just don't see how a "reference architecture" could
> > > > > hope to do this.
> > > > >
> > > > > > AG006 addresses the security of web services across
> > > > > > distributed domains and
> > > > > > platforms
> > > > >
> > > > > Here, we need to be more specific about what "security means."
> > > > >
> > > > > >
> > > > > > AG007 is reliable, and stable, and whose evolution is
> > > > > > predictable over time
> > > > >
> > > > > I'd suggest that there's no point in mentioning what we cannot
> > > > > control.  If we do a good job on the other goals, and
> > > > > implementers find it useful, it will be evolve in a
> > > > > predictable manner.
> > > > > If not, it will end up in the bitbucket of history, end
> > of story.
> > > > >
> > > > > >
> > > > > > AG008 is coherent and consistent in its definition
> > > > >
> > > > > The highest priority, IMHO.
> > > > >
> > > > > >
> > > > > > AG009 is aligned with the semantic web initiative at W3C and
> > > > > > the overall
> > > > > > existing web architecture
> > > > >
> > > > > I'd suggest that the point is to come up with coherent
> > > architecture
> > > > > for web services that uses what is valuable from the
> > semantic web
> > > > > initiative and web architecture principles, but doesn't
> > treat them
> > > > > as formal constraints.  It is possible (HIGHLY unlikely,
> > > IMHO) that
> > > > > a coherent and consistent web services architecture could
> > > "violate"
> > > > > some of the web architecture principles as we think we
> > > > understand them
> > > > > today.  To constrain this group too heavily by the current
> > > > > understanding
> > > > > views on the subject could lead to some quasi-religous
> > > > > debates rather than
> > > > > a two-way dialog to clarify both the web architecture and
> > > > web services
> > > > > architecture in a fruitful way.  A casual glance at the
> > > > > xml-dist-app or
> > > > > xml-dev archives should give one reason for caution on
> > > this subject.
> > > > > And a casual glance at the trade press this week should
> > > > give us pause
> > > > > about formally tieing the web services and semantic web
> > activities
> > > > > together!
> > > > >
> > > > > >
> > > > > > AG011 is consistent with the existing web and its
> > > > > > heterogenous environment
> > > > > > and distributed architecture to the greatest extent
> possible.
> > > > >
> > > > > Another EXTREMELY high priority goal IMHO.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Received on Friday, 15 February 2002 19:41:37 UTC