Re: [ws-dd] DPWS Security changes

[Antoine Mensch <antoine.mensch@odonata.fr>]

Hi Dan,

see additional comments below

Cheers

Antoine

Dan Driscoll a écrit :
>
> Hi Antoine-
>
> /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./
>
> I disagree—7.8.3 shows an example certificate, and the text that 
> follows simply explains the example. Additionally R4043 allows DEVICEs 
> to share certificates; if DEVICEs MUST have unique identities (R0005) 
> but MAY share certificates (R4043), there is no expectation that the 
> Subject field be a substring of the device ID.
>
You're right, but maybe we need to explain better that both the value of 
the Subject (the UUID value) and its type (UUID) are examples: a naive 
reader (like me) could consider that only the values are specific to the 
example, and that the type is part of the spec.
>
> Except for the example, the spec is intentionally silent on the 
> content of the certificates, and how clients validate them.
>
> /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./
>
> The DEVICE must be protected to ensure an attacker does not 
> impersonate the DEVICE and deliver non-secure HOSTED SERVICE 
> addresses. In cases where it makes sense to leave the DEVICE open to 
> impersonation but protect HOSTED SERVICEs, I recommend relying on an 
> alternate security profile.
>
As I said above, I agree with you on this case.
>
> / /
>
> /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./
>
> The HOSTED SERVICEs are ultimately the primary reason why we want 
> security in the first place: I expect any concerns about 
> confidentiality and authentication apply more to the HOSTED SERVICEs 
> than to the DEVICE.
>
I agree, hence the reason why I also considered case a. above.
>
> As a customer, I would care more about an unauthorized client /using 
> /my device than I do about them getting metadata. I think an alternate 
> security profile is the right solution here, as well.
>
Let's take a simple temperature sensor: one might want to use it for 
both providing information and sending alarms when the temperature 
exceeds a given limit. While accessing the value may not create specific 
security issues, changing the alarm threshold might: so the GetData 
service could be unsecure, and the Configure service secure.
I don't see reasons (maybe you can point out some) why having an 
unsecure service on a secure device would create problems for the 
default security model: the client would just not use the secure channel 
to talk to the unsecure service.
>
> /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?/
>
> Good catch—this was an oversight on my part. I’ll fix this.
>
> /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?/
>
> I don’t think this is a problem. If the connection is torn down and a 
> new one is established, each party will have to reauthenticate the 
> other. There is clearly a performance incentive to reuse the existing 
> connection. It’s up to implementers to balance the performance 
> incentive of reusing the connection against the cost of implementing 
> reuse.
>
The problem is if a client tries to establish directly a new TLS 
connection to a HOSTED SERVICE, instead of connecting to the DEVICE 
first: if we consider that this can happen, then we must be very clear 
that the client must be able to relate (when verifying the DEVICE 
certificate during the handshake) the HOSTED SERVICE to the DEVICE. This 
is not necessarily trivial.
>
> Also, the “secure association” was discarded at any point the 
> connection was closed, so there’s no net change here: CLIENTs and 
> SERVICEs have a relationship as long as the secure channel is alive.
>
Well, if you use session resumption, the association may be avalaible a 
little longer. Imposing that the same channel is used means that the 
CLIENT must be aware of the session key when trying to connect to a 
HOSTED SERVICE.
>
> 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.
>
> R4071, R4046, R4048, and the new paragraph immediately between them 
> are intended to solve this problem. Would it be clearer to split this 
> into a new section?
>
I don't see any new paragraph in the vicinity of those requirements. Are 
you referring to the last paragraph of Section 7.1 Model? In this 
paragraph there is a may (not capitalized) that is much fuzzier than the 
two requirements I mention above.
>
> Thanks
>
> --D
>
> -----Original Message-----
> From: Antoine Mensch [mailto:antoine.mensch@odonata.fr]
> Sent: Friday, January 09, 2009 3:43 AM
> To: Dan Driscoll; ws-dd@lists.oasis-open.org
> 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
>
> >>
>
> >>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.5/1882 - Release Date: 08/01/2009 08:13
>
>