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: RE: [ws-dd] DPWS Security changes


Hi all-

Attached is an updated proposal document which:

·         Incorporates the changes in my prior proposals, but with change tracking and comments disabled

·         Incorporates the proposal about making HOSTED SERVICEs optional, with change tracking and comments enabled

·         Incorporates the changes from the discussion below, with change tracking and comments enabled

 

Please review these changes.  Functional feedback is the most important.  Editorial changes that do not impact wire compatibility can be fixed after we produce CD2.  I would like to close on this proposal during our next conference call.

 

The notes on the feedback below are the conclusions Tony and I reached on a phone discussion earlier.  Tony has not yet had a chance to review these changes, so these are a best-effort on my part to accommodate the feedback.

 

line 89 - I don't think that the WSU namespace should be removed as it seems that the timestamp elements are used

line 145 - I don't think that the WS-Security reference should be removed (it should be updated though) as the processing of the reconstructed message can follow the WS-Security processing

In this case, WS-Discovery uses the timestamp, and does directly reference WS-Security.  The conclusion we reached was that WS-Security may be a helpful informative reference for implementers to consult in understanding how WS-Discovery uses Compact Signatures, and in how encryption/decryption process works.

 

Action taken: I have added WS-Security as an informative reference.

 

line 941 - HTTP could provide basic authentication and could be used if someone provided other technology that meets the rest of the requirements,

The introduction was still unclear on the use of HTTP, TLS, and x.509 certificates.

 

Action taken: I updated the introduction to clarify that HTTPS URLs are used to indicate the presence of this security profile, and to reinforce the roles TLS, HTTP, and x.509 play.

 

line 949 - SHA2 should be considered here

The SHS reference was out of date.  As Dave Whitehead found in his investigate, 128 RC4+SHA1 is the minimum bar we can reasonably require, but mentioning SHA-2 is a good idea anyway.

 

Action taken: Reinforced R4062 with a paragraph.

 

line 959 - connection level should be transport level
line 960 - compact signature only allows you to determine who signed the message, it may not be the originator
line 963 - TLS will only allow point to point so if there is an intermediary, this breaks. Also confidentiality is only achieved if the proper cipher suites are used, same with origin authentication

line 979 - integrity does not protect, its only a way to detect a change

The terminology here is not particularly crisp.

 

Action taken: I updated the terminology.

 

line 971 - does the x.509 v3 have to have the proper key usage ?

DPWS Section 7 does not yet describe any rules for validating the x.509 certificate or its contents as many of the choices here are solution- or deployment-specific.  We may encounter interoperability problems with the lack of a description around x.509 certificates.

 

Action taken: None.  We can investigate this for future versions of the specification.

 

line 982 - R4000 is this a on wire only requirement only ?

Line 1001 - R4002 is this an on the wire requirement only ?

It was not clear if these requirements applied specifically to messages in transit inside a secure channel.

 

Action taken: add text to reinforce that these are requirements for when the message is in transit.

 

line 990 - R4001 Does this include faults ?

It was not clear if this included faults.  SOAP ENVELOPEs technically includes Fault messages, but it was not clear if an error message could be sent without security.

 

Action taken: reinforce that SOAP Faults must be protected.

 

line 995 - Would change Secure Channel to Secure Transport

“Secure Channel” is not defined anywhere in Section 7, but is used in many places.  Instead of changing the wording to use ”transport,” we concluded to adding a definition.

 

Action taken: defined Compact Signature and Secure Channel

 

Line 1003 - R4067 this may be hard as if the transport security is being used it may be unencrypted before the processing engine gets the message and thus no one may know if the message was encrypted Line 1005 - no idea what a confidential message really is

It is not clear how sections 7.2 through 7.5 (Integrity, Confidentiality, Authentication, Trust) apply to TLS or Compact Signatures.  The easiest solution here is to add restrictions that clearly state which rules apply.

 

Action taken: added restrictions to 7.2 and 7.3 to clearly associate their behavior with TLS and Compact Signatures.  7.4 and 7.5 appear to be self-explanatory.

 

line 1024 - I don't see any difference between R4004 and R4007, and don't see why R4007 is under Trust section

R4004 and R4007 are redundant.

 

Action taken: R4004 removed.

 

line 1028 - I think R4008 is wrong as HTTP basic auth could be used and that is not at the lower network layer

The goal of R4008 is to allow a device to discriminate on other factors, such as the client’s IP address.

 

Action taken: Added an example below R4008 to explain this.

 

Thanks

--D

 

From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Tuesday, January 13, 2009 6:51 AM
To: Dan Driscoll
Cc: antoine.mensch@odonata.fr; ws-dd@lists.oasis-open.org
Subject: RE: [ws-dd] DPWS Security changes

 

Regrets for todays call but here are some comments:

line 89 - I don't think that the WSU namespace should be removed as it seems that the timestamp elements are used
line 145 - I don't think that the WS-Security reference should be removed (it should be updated though) as the processing of the reconstructed message can follow the WS-Security processing
line 941 - HTTP could provide basic authentication and could be used if someone provided other technology that meets the rest of the requirements,
line 949 - SHA2 should be considered here
line 959 - connection level should be transport level
line 960 - compact signature only allows you to determine who signed the message, it may not be the originator
line 963 - TLS will only allow point to point so if there is an intermediary, this breaks. Also confidentiality is only achieved if the proper cipher suites are used, same with origin authentication
line 971 - does the x.509 v3 have to have the proper key usage ?
line 979 - integrity does not protect, its only a way to detect a change
line 982 - R4000 is this a on wire only requirement only ?
line 990 - R4001 Does this include faults ?
line 995 - Would change Secure Channel to Secure Transport
Line 1001 - R4002 is this an on the wire requirement only ?
Line 1003 - R4067 this may be hard as if the transport security is being used it may be unencrypted before the processing engine gets the message and thus no one may know if the message was encrypted Line 1005 - no idea what a confidential message really is
line 1024 - I don't see any difference between R4004 and R4007, and don't see why R4007 is under Trust section
line 1028 - I think R4008 is wrong as HTTP basic auth could be used and that is not at the lower network layer

More to follow, not all the way through this yet

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for Dan Driscoll ---01/07/2009 11:18:51 PM---Thanks for the feedback, Antoine!Dan Driscoll ---01/07/2009 11:18:51 PM---Thanks for the feedback, Antoine!


From:


Dan Driscoll <Dan.Driscoll@microsoft.com>


To:


"antoine.mensch@odonata.fr" <antoine.mensch@odonata.fr>, "ws-dd@lists.oasis-open.org" <ws-dd@lists.oasis-open.org>


Date:


01/07/2009 11:18 PM


Subject:


RE: [ws-dd] DPWS Security changes





Thanks for the feedback, Antoine!

I incorporated all changes except a few minor notes:
* One comment you had said that we should distinguish "DEVICE" by saying "DEVICEs that conform to this security profile."  If we did, I think we would have to change most (all?) instances in this section--I think it is far more effective to allow the composition text at the beginning make it clear: all of Section 7 is optional and must be applied in entirety.
* The case of an unsecure DEVICE and a secure HOSTED SERVICE is an unusual one, and in cases where it's used, I think we should classify that as a separate security profile entirely, instead of trying to accommodate it in this profile.

Everyone, please see the updated text.  You may reply with the original text, or this one--if you haven't yet started reviewing, please use the latest version.

Issues addressed in this draft:
032: Describe security composability
051: Generalize security
112: Remove WS-Security reference
113: Cleanup Network Model
114: Remove security negotiation
115: Replace R4070 with switches on HTTPS ID/xAddrs
138: Create introduction and concrete description of security profile
139: Remove protocol negotiation
140: Clean up HTTP Authentication

Thanks
--D

-----Original Message-----
From: Antoine Mensch [mailto:antoine.mensch@odonata.fr]
Sent: Monday, January 05, 2009 4:27 AM
To: ws-dd@lists.oasis-open.org
Subject: Re: [ws-dd] DPWS Security changes

Hi Dan and all,

Please find enclosed a version of the document annotated with comments.
As the comments author is lost when saving the doc, I have prefixed all my comments with AM. Besides minor editorial issues, I have two major concerns with the current version:
1) it does not really clarify the security model for HOSTED SERVICEs:
most requirements still refer to DEVICEs, although the spec mentions that control and eventing messages (that normally apply to HOSTED
SERVICEs) should use the Secure Channel established for the DEVICE. I think the intent is that HOSTED SERVICEs delegate the establishment the security association to the DEVICE and then use the secure channel established between DEVICE and CLIENT, but it should be made clearer in the spec.
2) The removal of requirements R4028 and R4069 adds uncertainty to the
spec: it becomes more difficult to understand with feature is optional and which one is mandatory. I think we should explicitly say that TLS with both server and client certificates is the preferred approach, but that HTTP Basic Authentication can be used as a mandatory minimal fallback mechanism when client certificates are not practically feasible.

Cheers

Antoine

Dan Driscoll a écrit :
>
> Hi all-
>
> Please see my proposed changes for the DPWS Security issues.  The
> following issues are addressed in this proposal:
>
>     * 032: Describe security composability
>     * 112: Remove WS-Security reference
>     * 113: Cleanup Network Model
>     * 114: Remove security negotiation
>     * 115: Replace R4070 with switches on HTTPS ID/xAddrs
>     * 138: Create introduction and concrete description of security
>       profile
>     * 139: Remove protocol negotiation
>     * 140: Clean up HTTP Authentication
>
>
>
> Note that although change tracking is enabled, the document is much
> easier to read with tracking disabled.
>
>
>
> Thanks
>
> --D
>
> ----------------------------------------------------------------------
> --
>
> ---------------------------------------------------------------------
> 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
> ----------------------------------------------------------------------
> --
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date:
> 02/01/2009 13:10
>
>
(See attached file: wsdd-dpws-1.1-spec-wd-03-security.docx)---------------------------------------------------------------------
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 

wsdd-dpws-1.1-spec-wd-03-security-20090116.docx



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