OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]