[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-dd] DPWS Security changes
Hi Dan, I agree with your changes. I still have a few comments/questions: 1) I see that R009 mentions the case of DEVICEs using a physical transport address as its EPR. I assume this addition is for supporting the existing Vista security model. However, it is inconsistent with the certificate description in section 7.8.3, which says that the subject must be the device UUID. So if you want to keep this new requirement, you may want to update the certificate description. 2) I am still not completely clear about the secure DEVICE/HOSTED SERVICE relationship: because security is so CPU-intensive, in the interest of performances and energy saving on small devices, we may want to have only a subset of secure HS on a device (e.g. configuration services, but not control ones). So in fact we have two options: a) allow unsecure devices to expose secure HS: I understand this could be a problem for the default security model, as it would be more difficult to authenticate the HS with the unique device certificate. This would require each HS to have its own certificate, so it is a different security model. b) allow secure devices to expose unsecure HS: I don't see a good reason why this should not be allowed in the default security model, so it seems to me that we should support it, which means that R5010 may be a problem. 3) Still on the relation between DEVICE and HOSTED SERVICES, I see that you have updated section 7.9. However: a) Shouldn't we update R4057 to use SERVICE instead of DEVICE? b) Does the security model work if the CLIENT tries to use a different secure channel to communicate with a HS than the one used to communicate with the DEVICE? I think we will end up with the same authentication problem than the one I mentioned for 2.a above. So it may be required that the CLIENT uses the same secure channel to communicate with a DEVICE and all its secure HS. In other words, is it such a good idea to discard the notion of security association? 4) I am still not completely comfortable with the removal of requirements R4028 and R4069: I find the new version less explicit than the original version about which protocols are recommended and which are mandatory. Cheers Antoine Dan Driscoll a écrit : > 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 >> >> >> >> ------------------------------------------------------------------------ >> >> --------------------------------------------------------------------- >> 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 >> ------------------------------------------------------------------------ >> >> >> Internal Virus Database is out of date. >> Checked by AVG - http://www.avg.com >> Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date: 02/01/2009 13:10 >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]