Re: [ws-dd] RE: DPWS Section 7 (Security)

[Anthony Nadalin <drsecure@us.ibm.com>]

So I like the idea of a section redo

Goals:

1) so not sure a single option may work, so we need to see if this is viable (use SSL/TLS along with compact signatures as a starting point) as this will have an impact on #2 which is how extensible this could be to allow other mechanisms. I do believe that we should look into WS-Security (as these stacks are getting common) as part of this effort

3) Yes looks at what has been done in WS-I around SSL/TLS and the processing of the signature (expanded signature)

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Dan Driscoll ---12/11/2008 04:47:41 PM---Please see the attached slides of functional changes to DPWS Section 7 to make it align better with the goals set out in my pri

From:	Dan Driscoll <Dan.Driscoll@microsoft.com>
To:	"ws-dd@lists.oasis-open.org" <ws-dd@lists.oasis-open.org>
Date:	12/11/2008 04:47 PM
Subject:	[ws-dd] RE: DPWS Section 7 (Security)

---

Please see the attached slides of functional changes to DPWS Section 7 to make it align better with the goals set out in my prior mail on security.
--D
 
From: Dan Driscoll [mailto:Dan.Driscoll@microsoft.com] 
Sent: Wednesday, December 10, 2008 11:48 AM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] DPWS Section 7 (Security)
 
I took an action item to investigate DPWS Section 7 (Security) and propose a concrete resolution.  Because section 7 is so large (and rarely fully implemented), I would like to use this mail to bring you up to speed.
 
I think it is important for us to have a shared understanding of this section, and to resolve any conceptual issues before we discuss any concrete changes.
 
Here is my assessment:

1) Section 7 defines an abstract security framework. For example, it defines Integrity (section 7.1.1) and tells us that we must “protect” the SOAP header and body. This section would allow an implementer to plug in any protection mechanism as long as it met the described requirements.
2) Many sections do not provide concrete definitions. Security for Discovery (section 7.1.9) describes abstract signing rules, but does not tell us to use WS-Discovery Compact Signatures. This is a common theme—most subsections do not provide concrete direction on what to implement.
3) Implementers must read all of Section 7 to understand any of it. Some sections are redundant (Authentication has an abstract part, 7.1.3, and a concrete part, 7.1.10) and many concrete definitions cannot be read without understanding the entire abstract framework. Another way to put this: Section 7 is poorly organized.
4) Many abstract restrictions have limited utility. Consider R4007: CLIENTs and DEVICEs MUST have the necessary credentials to perform authentication. This statement adds very little information to the specification.
5) Some subsections are implemented in the way that the spec describes; others are completely unimplemented. For example, many devices use x.509v3 certificates (R4045) but I am not aware of any that use out-of-band PIN exchange for DPWS security (R4055).
6) Section 7 does not preclude alternative security solutions. Currently section 7 is recommended, so implementers are free to implement no security whatsoever, a subset of section 7, all of section 7, or a completely different security model

My goals for this section:

1) Section 7 should provide a single minimum, concrete, and interoperable security formula. This will benefit generic stack implementations, and will promote a base level of security across specifications that build on DPWS.
2) Section 7 should continue to allow alternate security solutions. We can cover many applications with a minimum baseline security formula, but some solutions have very rigorous security requirements and very different operating parameters. Higher-layer specifications should be free to specialize their security formula to meet their needs. However, the goal is not to specify any framework in DPWS for alternative security solutions (see item 4, below)
3) Section 7 should benefit from implementation experience gathered since 2006. We should improve sections that have been widely implemented; we should consider removing sections that have not.
4) Section 7 should not provide unnecessary abstract definitions. The text should provide concrete definitions, requirements, and recommendations where necessary.

Regards
--D
 (See attached file: Changes to DPWS Section (Security).pdf)---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Changes to DPWS Section (Security).pdf