[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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] 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 |
Changes to DPWS Section (Security).pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]