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


Some comments on the updated document (section 7)

General - the requirements assume security profile is in effect (i assume that but not sure if there are any requirements that would still be there if a security profile was not used), needt to clarify

line 939 - I don't think that this is an appropriate restriction as worded, as I would expect as more profiles are developed that implementors will want to support multiple profiles
line 969 - it's confusing on what certificates to use, since we talked about not using multiple certificates on call today and we just say that the certificate to authenticate is the same certificate used in the secure channel negotiations
line 984 - suggest that we add a requirement ": If a SERVICE uses TLS/SSL, it MUST provide Integrity (as defined in this section) for any TLS/SSL connections"
line 1009 - I don't know how we can meet requirement R4003 and get interoperability
line 1015 - Suggest we reword R4004 to say that you must use SSL/TLS credentials
line 1019 - suggest that we add a requirement ": If a SERVICE uses TLS/SSL, it MUST provide Authentication (as defined in this section) for any TLS/SSL connections"

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for Dan Driscoll ---01/20/2009 12:42:06 PM---Hi everybody-Dan Driscoll ---01/20/2009 12:42:06 PM---Hi everybody-


From:

Dan Driscoll <Dan.Driscoll@microsoft.com>

To:

"ws-dd@lists.oasis-open.org" <ws-dd@lists.oasis-open.org>

Cc:

"antoine.mensch@odonata.fr" <antoine.mensch@odonata.fr>, Anthony Nadalin/Austin/IBM@IBMUS

Date:

01/20/2009 12:42 PM

Subject:

RE: [ws-dd] DPWS Security changes





Hi everybody-
See the attached security proposal.  This is the latest version.

I have incorporated proposals from both Antoine and Tony on prior versions of the security changes.  This includes incremental changes over the document titled wsdd-dpws-1.1-spec-wd-03-security-20090116.docx mailed out in message 85.  This does not include any editorial restructuring; I expect that to take place after CD2.

Please review these changes.  If you have any concerns, please include a concrete proposed change.

Thanks!
--D

From: Dan Driscoll [mailto:Dan.Driscoll@microsoft.com]
Sent:
Monday, January 19, 2009 6:59 PM
To:
Anthony Nadalin
Cc:
antoine.mensch@odonata.fr; ws-dd@lists.oasis-open.org
Subject:
RE: [ws-dd] DPWS Security changes

Hi Tony-
Thanks for your notes.

During tomorrow’s call I intend to discuss proposals for four of these items. These are all identified with “Proposed change:”

Some responses:

line 253 - any additional security requirements for attachments (mime) to secure the attachment(s) ?
Attachments are a good point, but I don’t think any more restrictions are necessary. The only model we have to attachments is to append them as separate MIME sections to the current HTTP request. Since the HTTP request is encapsulated inside a TLS channel, the attachments will always be encapsulated, too. We looked at that briefly during the F2F but it’s rarely used in WS-Discovery now, and including policy to a WS-Discovery message that uses Compact Signature will push us close to (or beyond) MTU in most cases.
I believe you’re talking about R4046 here, which deals with HTTP Basic Authentication. Antoine raised objections to removing HTTP Authentication. This is left unchanged from the prior version of the spec. We can address the issue of multiple credentials on the next call. I assume the goal here is to allow participants to negotiate down to SSL v3.0.

Proposed change: modify instances of “TLS” in the document to “TLS/SSL,” but do not add any restrictions. Proposed change: add a restriction that clearly states that a CLIENT authenticates a DEVICE via x.509 certs exchanged during TLS setup. I believe the intent is that TLS is the Secure Channel, and that it should be reused for multiple messages if possible. It’s not clear.

Proposed change: modify restriction so it clearly indicates the TLS session is to be reused, and not imply that a TLS session is used to set up another TLS session. Another instance of HTTP Authentication (see note for line 1105, above). I agree; this can be fixed with a restriction that clearly binds the Secure Channel to TLS/SSL.

Proposed change: add a restriction that clearly requires the use of TLS/SSL, and update R5014 to accommodate the SSL-named Ciphersuites.

line 1126 - I think we should just have a requirement that lists the unsupported cipher suites for SSL/TLS
Per our last conversation, I copied the rules directly from WS-I Basic Security Profile v1.0.

Thanks
--D

From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent:
Monday, January 19, 2009 12:44 PM
To:
Dan Driscoll
Cc:
antoine.mensch@odonata.fr; ws-dd@lists.oasis-open.org
Subject:
RE: [ws-dd] DPWS Security changes

Here are my additional comments:

line 253 - any additional security requirements for attachments (mime) to secure the attachment(s) ?
line 738 - should we use a ws-securitypolicy to indicate a security (security profile) and not just the uri ?
line 1105 - seem there will be an interop issue if we let folks decide on what mechanisms to use for authentication, seems that we should just state what is acceptable in the security profile that is required to be supported
line 1131 - I think that R4035 should be removed as we don't yet have a profile that has multiple credentials, we need make sure we have a set of requirements that cover the profile
line 1146 - I think that we should state the "credentials of the client or device" or make sure that the profile we have for SSL/TLS covers multiple credentials
line 1151 - should add SSL also
line 1155 - we should be specific here as this could be basic authn or some form of SSL/TLS mutual authn
line 1159 - should the the same session that was used to negotiate a secure session be used ?
line 1174 - R4046 for interop we should just stick with TLS certificate authn, this goes back to having a profile and a set of requirements for that profile, some of these requirements are too framework like and don't get us to an interop point
line 1212 - I think that we should limit this to SSL/TLS as I could use a proprietary secure channel and we would not get interop
line 1126 - I think we should just have a requirement that lists the unsupported cipher suites for SSL/TLS

Basically I think we need to have a section for a mandatory (if you want security)secure profile and then have the requirements that cover that secure profile as this is still trying to cover a framework for security

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
>
>
[attachment "wsdd-dpws-1.1-spec-wd-03-security.docx" deleted by Anthony Nadalin/Austin/IBM]
---------------------------------------------------------------------
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 [attachment "wsdd-dpws-1.1-spec-wd-03-security-20090120.docx" deleted by Anthony Nadalin/Austin/IBM]


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