[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-dd] DPWS Security changes
Hi everyone- Antoine and I have discussed his feedback on a telephone
call—I expect to have a response to his feedback before the next conference
call. If you have additional concerns, please mail on this thread.
I would like all feedback before the next call so we can make progress on this
large issue. Thanks very much --D -----Original Message----- 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 > > --------------------------------------------------------------------- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]