[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-dd] DPWS Security changes
|
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. 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. 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.
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. 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. 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. 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? Thanks --D -----Original Message----- 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]