From owner-zeroconf@merit.edu Mon May 1 18:38:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07769 for ; Mon, 1 May 2000 18:38:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9F9A5DDEA; Mon, 1 May 2000 18:38:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A80F75DDF5; Mon, 1 May 2000 18:38:08 -0400 (EDT) Received: from dns3.nec.com (dns3.nec.com [131.241.15.5]) by segue.merit.edu (Postfix) with ESMTP id 388125DDEA for ; Mon, 1 May 2000 18:38:07 -0400 (EDT) Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by dns3.nec.com (ready at/) with ESMTP id PAA03733; Mon, 1 May 2000 15:38:00 -0700 (PDT) Received: from galatica.pc.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id PAA07842; Mon, 1 May 2000 15:37:29 -0700 (PDT) Received: by GALATICA with Internet Mail Service (5.5.2448.0) id ; Mon, 1 May 2000 15:31:36 -0700 Message-ID: From: Jim Busse To: franklin.reynolds@nokia.com, raj@cisco.com, myron.hattig@intel.com Cc: zeroconf@merit.edu Subject: RE: service discovery characteristics Date: Mon, 1 May 2000 15:31:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Does anyone have the concern about supporting low-bandwidth network physical layers when considering service discovery? Consider the home net with a usual stereo/TV system connected to the HomeRF network as the environment. In to this configuration walks a guy with a notebook and an Acer or Intel Bluetooth PC-card. I think all the tuner/tone/changer/channel/etc characteristics that will get reported may make the bluetooth physical layer inoperable for a significant period of time. If the characteristics get reported using a verbose XML message, that will extend the delay even further, I think. Myron, do you remember the delays we saw when getting bus-resets interconnecting 3 devices on IP/1394 plugfests? And that was a 400mbit physical layer. Or maybe we don't care about low-bandwidth physical layers? Jim Busse -----Original Message----- From: franklin.reynolds@nokia.com [mailto:franklin.reynolds@nokia.com] Sent: Friday, April 28, 2000 1:27 PM To: raj@cisco.com; myron.hattig@intel.com Cc: zeroconf@merit.edu Subject: RE: service discovery characteristics > -----Original Message----- > From: EXT Richard Johnson [mailto:raj@cisco.com] > Sent: Friday, April 28, 2000 3:51 PM > To: Hattig, Myron > Cc: 'zeroconf@merit.edu' > Subject: Re: service discovery characteristics > > > Hattig, Myron writes: > > I think characteristics SHOULD be supported. > Characteristics allow for > > refined queries so that things like color printers can be > discovered instead > > of just printers. The alternative is to discover all > printers then negotiate > > with each to determine whether it supports color printing > or not. In my > > simple view of the world this seems pretty obvious that > characteristics > > SHOULD be supported by a service discovery protocol. Can > someone enlighten > > as to why this is such a debatable topic? > > Ok, I'll try: > > Discovering that a printer *exists* and finding out the > *characteristics* of the printer could be separated. Once you start > down the road of "characteristics", there no end to what could be > done. (Does the printer have 2 or more paper trays? How much paper > is in the paper trays? What type of paper does it print on? How fast > does it print?) Afterall, what if I'm printing a large job (want > something which prints fast), on a special type of paper (want to know > what type of paper is in the trays), and I want it printed *now* (want > a printer which doesn't have any jobs running currently)? Maybe > characteristics should be done using SNMP? > > Anyway, that's an argument against including characteristics in > service discovery. (Flame retardant suit in place.) > > Of course, it's also a matter of how you define the device types. > Your list could consist of "CPU", "printer", "video recorder", etc., > or it could consist of "CPU", "color printer", "b&w printer", "hard > disk video recorder", "VCR". > > /raj I guess I still don't understand. Assuming a device is free to to advertise only its name, what difference does it make whether other devices choose to advertise a large number of characteristics? One argument related to yours is that the query language for characteristic-enabled queries is too complex for simple devices. These days this is only true for the most simple of devices and the most complex of query languages. It seems likely to me that any device that can handle an IP stack has the computational power to handle resonable query processing. Perhaps I am getting old, but I think I have heard this debate many times before. It seems like everytime someone invents a successful, scalable (more than a couple hundred nodes) namespace, they discover that a flat name space is too hard to navigate. "Characteristics" aren't the only approach, but they are a good one. Franklin Reynolds From owner-zeroconf@merit.edu Tue May 2 12:07:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04081 for ; Tue, 2 May 2000 12:07:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C123B5DE22; Tue, 2 May 2000 12:07:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AF4C45DE10; Tue, 2 May 2000 12:07:28 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id DD5C85DE0A for ; Tue, 2 May 2000 12:07:26 -0400 (EDT) Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id TAA10632; Tue, 2 May 2000 19:07:11 +0300 (EETDST) From: franklin.reynolds@nokia.com Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id TAA02622; Tue, 2 May 2000 19:07:08 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 11:05:44 -0500 Message-ID: To: JIM@pc.sj.nec.com, raj@cisco.com, myron.hattig@intel.com Cc: zeroconf@merit.edu Subject: RE: service discovery characteristics Date: Tue, 2 May 2000 11:04:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk I am quite concerned about low-bandwidth networks, especially bluetooth. However, I am not sure I understand the basis for your concern. It sounds to me like you are suggesting either: a) that the arrival of a new host would trigger a flood of XML-based, advertisement messages from each device/service. b) the ability to send a query that matches all devices and returns all the characteristics of any matching device could cause a network flood. In the first case, I don't understand why an SLP-like approach to characteristic enhanced queries results in advertizement induced overload. In the second case, this is not a low bandwidth network problem, this is a scaling problem which would show up in fast networks, if there were a large number or devices. Characteristic reporting for a large number of devices relative to available message processing power, will always be expensive. The question is whether you allow wildcards or you force the client to ask each device to report their characteristics individually. This is separate from using characteristics (like SLP) to modify selection. Selection without characteristic reporting is less likely (though it is still possible) to overwhelm a network. Franklin > -----Original Message----- > From: EXT Jim Busse [mailto:JIM@pc.sj.nec.com] > Sent: Monday, May 01, 2000 6:31 PM > To: franklin.reynolds@nokia.com; raj@cisco.com; myron.hattig@intel.com > Cc: zeroconf@merit.edu > Subject: RE: service discovery characteristics > > > Does anyone have the concern about supporting low-bandwidth > network physical > layers when considering service discovery? > > Consider the home net with a usual stereo/TV system connected > to the HomeRF > network as the environment. In to this configuration walks a > guy with a > notebook and an Acer or Intel Bluetooth PC-card. I think all the > tuner/tone/changer/channel/etc characteristics that will get > reported may > make the bluetooth physical layer inoperable for a > significant period of > time. If the characteristics get reported using a verbose > XML message, that > will extend the delay even further, I think. > > Myron, do you remember the delays we saw when getting bus-resets > interconnecting 3 devices on IP/1394 plugfests? And that was > a 400mbit > physical layer. > > Or maybe we don't care about low-bandwidth physical layers? > > Jim Busse > From owner-zeroconf@merit.edu Tue May 2 12:34:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04643 for ; Tue, 2 May 2000 12:34:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDE635DE07; Tue, 2 May 2000 12:34:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE1D45DE00; Tue, 2 May 2000 12:34:18 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id E1DBC5DDB4 for ; Tue, 2 May 2000 12:34:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16990; Tue, 2 May 2000 10:23:41 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA14912; Tue, 2 May 2000 09:23:40 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA07895; Tue, 2 May 2000 09:23:14 -0700 (PDT) From: James Kempf Message-Id: <200005021623.JAA07895@nasnfs.eng.sun.com> Date: Tue, 2 May 2000 09:26:02 -0700 To: Cc: Reply-To: Subject: RE: service discovery characteristics X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I am quite concerned about low-bandwidth networks, especially >bluetooth. However, I am not sure I understand the basis for your >concern. It sounds to me like you are suggesting either: > >a) that the arrival of a new host would trigger a flood of >XML-based, advertisement messages from each device/service. > >b) the ability to send a query that matches all devices and >returns all the characteristics of any matching device could >cause a network flood. > >In the first case, I don't understand why an SLP-like approach >to characteristic enhanced queries results in advertizement >induced overload. > For a system based on client-query like SLP, the delay would only happen if the the arriving client made a blanket query upon arrival rather than performing the query on demand, as applications required access to the services. In addition, the actual amount of data will depend, as Jim originally noted, on the the data format in which the advertisments are transmitted. Something verbose like XML will place a heavier load than a more compact representation. jak From owner-zeroconf@merit.edu Wed May 3 11:12:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03968 for ; Wed, 3 May 2000 11:12:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47FC95DD97; Wed, 3 May 2000 11:11:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 310F25DDA9; Wed, 3 May 2000 11:11:55 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 06F7A5DD97 for ; Wed, 3 May 2000 11:11:54 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26708 for ; Wed, 3 May 2000 08:11:51 -0700 (PDT) Received: from vayne (muc-isdn-17 [129.157.164.117]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id RAA29536; Wed, 3 May 2000 17:11:48 +0200 (MET DST) Date: Wed, 3 May 2000 17:20:33 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: zeroconf security - conclusions To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I have reviewed the thread on home networking security. There has been some excellent discussion. This is an attempt to see what the concensus was. Remember that the primary goal of security work in the ZEROCONF WG is to not make IP networking any less secure than it already is. 0 Scope of discussion: 0.1) The ZEROCONF WG is working on 4 protocol areas - host configuration, service discovery, name to address resolution and multicast address allocation. Application level protocols (including device control) are out of scope. 0.2) The threats which have been discussed and broadly agreed upon are: . masquerading (A host uses zeroconf protocols to fool others by sending messages it shouldn't) . hoarding (A host subverts zeroconf protocols by pretending to have resources it doesn't have) . antagonistic server (This server undermines hosts because it uses a protocol which automatically configures hosts which use 'zeroconf protocols') Additional threats which were mentioned were: . Inventory attack - ZeroConf protocols (especially service discovery) would allow thieves to take inventory very easily. . Evesdropping attack - Capturing ZC protocol messages issued by hosts use could inform about what the network is used for, how much it is used, etc. . Denial of service attack - But is there anything specific to Zero Configuration networking here? 0.3) The scenario in which these threats occur is 'remote access.' As Jeff Schiller pointed out in Adelaide, there are social mechanisms for security at home and between neighbors. The real threat is the anonymous stranger attacking from afar. Configuration for such networks can be very simple (such as a group key) since we don't have to differentiate between users and devices on a zeroconf network. We have to assume that an attacker can send and receive messages on the local network since in important cases Zero Configuration protocols will be used on shared access links (RF, power line, 'neighborhood area network' cable subnets, etc.) 1 Conclusions of discussion: 1.1) Punting is not an option. Security does require configuration. So, we have to consider the best, minimal configuration requirements. The ZEROCONF charter includes the following text: ZEROCONF requirements will make networking as easy as possible, but no easier. In some cases other considerations may dominate ease of use. For example, network security requires some configuration which may not be as easy as the unacceptable alternative of 'no security.' 1.2) We are only discussing security for ZC protocols and transitions to 'configured' protocol behavior. Security for application level (device control) protocols is out of scope. It may be that app level protocols can share the same mechanisms, but that is not a requirement. 1.3) There is concern about the default value. - Security enabled means nothing works until it is configured. - Security disabled means many systems will be vulnerable (as one cannot expect all users to do security configuration). It was suggested that there can't be a hard and fast rule - for some applications 'ease of use' demands no security by default. In other cases, safety demands security by default. 1.4) It was suggested that the ability to authenticate messages as having come from a peer with a shared secret may not be enough. Encryption capability, to provide privacy, was suggested as being important. 2 Requirements arising from discussion: 2.1) Hosts MUST implement a security mechanism (or mechanisms) to protect against the following threats: + Hoarding attack. A host MUST be able to determine whether a multicast address allocation claim (used in a claim and defend protocol) is legitimate or not. Protecting against IP address hoarding is NOT a requirement for IPv4, since it would mean securing ARP. That is the concensus of the DHC WG. + Masquerading attack. Service discovery, name to address resolution and multicast address allocation services MUST support a mechanism so that legitimate and illigitimate responses can be differentiated. (Note that in the case of name to address resolution, this protects against a 'hoarding attack.' A malevolent host couldn't respond to all names to prevent 'nameless' host from picking a unique name.) + Antagonistic server attack. The host MUST be able to determine whether a discovered DHCP server, DNS server, SLP DA (or whatever) or MADCAP server is to be used or not. NOTE: This requirement *looks good,* but how many systems in practice are enabled to use DHCP authentication, DNSSec, SLP authentication and MADCAP security? We are 'raising the bar' by requiring this, not avoiding 'making IP less secure' which is our guiding principal. Hosts MAY implement security mechanism to protect them against the following threats: + Evesdropping attack. The host MAY be able to encrypt service discovery, name to address resolution messages. Host configuration (ie. ARP and DHCP) and multicast address allocation messages (ie. MADCAP) do not require encryption as there is little to be learned from them. 2.2) Hosts MUST be configurable to use that security, as easily as possible. 2.3) It is not specified in the requirements whether security is on by default or not. Note that if security is on by default and the host is unconfigured that implies that the host is not usable *until it has been configured.* Some devices (such as those which are dangerous) should require a priori configuration. It is out of the scope of the WG to do more than point this out. 2.4) Security mechanisms used for the four protocol areas covered by Zero Configuration requirements should be the same if possible so they can: + share common implementation + share common configuration + be as easily administered as possible Please send your feedback. If there is broad agreement, I will turn this into an internet draft. Whether we ultimately separate out the security requirements for ZC networking from the current document or not, I would like to focus attention on it so we can make rapid progress. Once we complete our 'requirements' work, we can work on defining the security mechanisms to fulfill the requirements. Whether this should take place in the current ZEROCONF WG or a new WG needs to be chartered is a separate discussion. Stay tuned. Erik From owner-zeroconf@merit.edu Wed May 3 11:13:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04025 for ; Wed, 3 May 2000 11:13:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C2DF05DDBD; Wed, 3 May 2000 11:13:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B1CBB5DDBB; Wed, 3 May 2000 11:13:30 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3E1F75DDA9 for ; Wed, 3 May 2000 11:13:29 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27527; Wed, 3 May 2000 08:13:24 -0700 (PDT) Received: from vayne (muc-isdn-17 [129.157.164.117]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id RAA29631; Wed, 3 May 2000 17:13:21 +0200 (MET DST) Date: Wed, 3 May 2000 17:22:06 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: home networking security To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, Daniel Senie Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk At 10:57 PM 04/09/2000 -0400, Daniel Senie wrote: >Before we continue down this path of figuring out security for accessing >these various devices in the house, can we figure out where the >addresses assigned to your water heater came from? Daniel, Thanks for your many comments on this thread. At 10:57 PM 04/09/2000 -0400, Daniel Senie wrote: >Before we continue down this path of figuring out security for accessing >these various devices in the house, Just to be clear, protecting devices from being accessed is beyond the scope of the working group. Protecting the infrastructure by which devices are configured (or autoconfigure) is within scope. > can we figure out where the addresses assigned to your water heater > came from? Zeroconf protocols are independent. That is, a host could have a configured global address but still use ZC mechanisms for service discovery, name resolution and multicast address allocation. Further, even if addresses were assigned as link-local, it doesn't mean that hosts remote to the link don't have access to it. (The link may be shared access media). Finally, the zeroconf water heater may be given a routable address by a hostile DHCP server as part of making accessible to an attack. Erik From owner-zeroconf@merit.edu Wed May 3 12:54:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06105 for ; Wed, 3 May 2000 12:54:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B0925DDC2; Wed, 3 May 2000 12:54:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1AE8A5DDC0; Wed, 3 May 2000 12:54:42 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by segue.merit.edu (Postfix) with ESMTP id 1FC8F5DDBE for ; Wed, 3 May 2000 12:54:38 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA88778; Wed, 3 May 2000 09:39:25 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Erik Guttman'" , Subject: RE: zeroconf security - conclusions Date: Wed, 3 May 2000 09:56:24 -0700 Message-ID: <000c01bfb520$85093fa0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Antagonistic server attack. The host MUST be able to determine >whether a discovered DHCP server, DNS server, SLP DA (or >whatever) or MADCAP server is to be used or not. >NOTE: This requirement *looks good,* but how many systems in > practice are enabled to use DHCP authentication, DNSSec, SLP > authentication and MADCAP security? If one assumes that all of these services reside on a home gateway, it may be quite reasonable to come up with a relatively simple way of securing all of them. However, saying that the host MUST be able to use it seems like raising the bar too high, given that very few hosts can do this today. From owner-zeroconf@merit.edu Wed May 3 14:44:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08847 for ; Wed, 3 May 2000 14:44:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3260B5DDA9; Wed, 3 May 2000 14:44:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CF715DDAC; Wed, 3 May 2000 14:44:09 -0400 (EDT) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by segue.merit.edu (Postfix) with ESMTP id 712A45DDA9 for ; Wed, 3 May 2000 14:44:07 -0400 (EDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.22 2000/04/06 17:58:51 dmccart Exp $) with SMTP id LAA02027; Wed, 3 May 2000 11:43:58 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 03 May 2000 18:43:57 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 3 May 2000 11:43:56 -0700 Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE962D@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Erik Guttman'" Cc: zeroconf@merit.edu Subject: RE: zeroconf security - conclusions Date: Wed, 3 May 2000 11:43:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik: Very nice summary. I agree with most of it, and so raise questions about only a handful of the statements from your text. 0.3) The scenario in which these threats occur is 'remote access.' As Jeff Schiller pointed out in Adelaide, there are social mechanisms for security at home and between neighbors. The real threat is the anonymous stranger attacking from afar. Wireless is changing this, unless people install their wireless LANs outside their home firewalls. It is a very large leap of faith to assume people will do this. Configuration for such networks can be very simple (such as a group key) since we don't have to differentiate between users and devices on a zeroconf network. It is not evident that group keys can provide any kind of a useful solution for many problems, especially because of the emergence of wireless. Use of group keys means LAN users need to reconfigure all the devices relying on these keys to reestablish security in the event of divorce or betrayal by a previously trusted friend. If wireless indeed makes easy revocation a requirement, as I think it does, then it is unfortunately hard to imagine anything short of a credentials management scheme being part of the solution. If this is the case, the proper requirement is that the credentials management scheme has to be simple to use. 2.1) Hosts MUST implement a security mechanism (or mechanisms) to protect against the following threats: + Hoarding attack. A host MUST be able to determine whether a multicast address allocation claim (used in a claim and defend protocol) is legitimate or not. Depending on your assumptions about overall network size and credentials management schemes deployed, this might not be feasible except by using asymmetric key techniques. My guess is the low end market will be unwilling to pay the computational and administrative costs associated with existing asymmetric key techniques for a very long time. Perhaps this requirement should be a MAY; or it may simply require more discussion to narrow the requirement sufficiently to something vendors can implement and users will actually deploy. 2.2) Hosts MUST be configurable to use that security, as easily as possible. My concern with this is we need to specify what we means by "security". Without doing that, this is a very open-ended requirement, and we will never be able to determine when implementations do or do not conform. Jesse Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214-5961 (503) 712-1849 jesse.walker@intel.com From owner-zeroconf@merit.edu Thu May 4 01:59:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23261 for ; Thu, 4 May 2000 01:59:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 84B2A5DDC0; Thu, 4 May 2000 01:58:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6A7545DDB8; Thu, 4 May 2000 01:58:53 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id 985D65DDA5 for ; Thu, 4 May 2000 01:58:51 -0400 (EDT) Received: from SERVER ([63.199.7.253]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FU000BFYTS4SA@mta5.snfc21.pbi.net> for ZeroConf@Merit.edu; Wed, 3 May 2000 22:55:16 -0700 (PDT) Date: Wed, 03 May 2000 22:52:35 -0700 From: Peter Johansson Subject: Re: zeroconf security - conclusions In-reply-to: X-Sender: Celeborn@PacBell.net To: Zero Configuration Message-id: <3.0.5.32.20000503225235.00968bf0@PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 05:20 PM 5/3/00 +0200, Erik Guttman wrote: <<2.3) It is not specified in the requirements whether security is on by default or not. Note that if security is on by default and the host is unconfigured that implies that the host is not usable *until it has been configured.* Some devices (such as those which are dangerous) should require a priori configuration. It is out of the scope of the WG to do more than point this out.>> I think a useful zero configuration draft is going to have to do more than make the observation that, "Well, you can have security enabled or you can have it disabled." The key element is informed consent of the user. If I buy a device labeled "SECURE" or "INSECURE" there need to be some minimal behavioral expectations upon which I can rely. I don't single out this WG for criticism---I think the problem of inadequate disclosure of security risks is rampant in the current rush to deploy broadband---but I don't think the working gruop can punt on this one, either. I'm sorry I don't have a ready-made solution, but I do think more discussion will be needed on this issue, that it's not sufficient to describe the pros and cons. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Thu May 4 01:59:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23272 for ; Thu, 4 May 2000 01:59:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19ACA5DDA9; Thu, 4 May 2000 01:58:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E5A935DDA5; Thu, 4 May 2000 01:58:53 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id BEDF15DDA9 for ; Thu, 4 May 2000 01:58:51 -0400 (EDT) Received: from SERVER ([63.199.7.253]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FU000BFYTS4SA@mta5.snfc21.pbi.net> for ZeroConf@Merit.edu; Wed, 3 May 2000 22:55:17 -0700 (PDT) Date: Wed, 03 May 2000 22:52:17 -0700 From: Peter Johansson Subject: Re: zeroconf security - conclusions In-reply-to: X-Sender: Celeborn@PacBell.net To: Zero Configuration Message-id: <3.0.5.32.20000503225217.00958cd0@PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 05:20 PM 5/3/00 +0200, Erik Guttman wrote: <> If I have been tripped up by some subtle meaning of the word "remote" above (and consequently misunderstand the conclusion) please excuse me. But if I read it correctly, I don't feel at all secure that I have adequate social mechanisms for addressing security transgressions by my neighbors! Adequate "social mechanisms" work just fine when the problem is as minor as your neighbor's annoying, constantly barking dog or incessant wind chime---no lasting harm is done in the interval that social mechanisms yield a resolution. If the social mechanisms fail, the continuing harm done is of a relatively minor scale. But if we're talking about my private and sensitive data, I am not willing to wait to apply "social mechanisms" until after a sociopathic neighbor has made off with the goods! or regularly and consistently denied me use of my system! So, someone, please tell me I've completely misunderstood what has been said. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Thu May 4 10:22:07 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06575 for ; Thu, 4 May 2000 10:22:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1C615DDE8; Thu, 4 May 2000 10:21:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D9E3F5DDE4; Thu, 4 May 2000 10:21:57 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id ADABB5DE0B for ; Thu, 4 May 2000 10:21:55 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16105; Thu, 4 May 2000 07:21:51 -0700 (PDT) Received: from vayne (muc-isdn-19 [129.157.164.119]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id QAA03399; Thu, 4 May 2000 16:21:49 +0200 (MET DST) Date: Thu, 4 May 2000 16:30:33 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: zeroconf security - conclusions To: aboba@internaut.com Cc: "'Erik Guttman'" , zeroconf@merit.edu In-Reply-To: "Your message with ID" <000c01bfb520$85093fa0$428939cc@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > >Antagonistic server attack. The host MUST be able to determine > >whether a discovered DHCP server, DNS server, SLP DA (or > >whatever) or MADCAP server is to be used or not. > > >NOTE: This requirement *looks good,* but how many systems in > > practice are enabled to use DHCP authentication, DNSSec, SLP > > authentication and MADCAP security? > > If one assumes that all of these services reside on a home > gateway, it may be quite reasonable to come up with a > relatively simple way of securing all of them. However, > saying that the host MUST be able to use it seems like > raising the bar too high, given that very few hosts can > do this today. SHOULD? MAY? Or is this really out of scope? Would we be specifying requirements for clients of *non-zeroconf* protocols? Erik From owner-zeroconf@merit.edu Thu May 4 10:33:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06787 for ; Thu, 4 May 2000 10:33:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B9405DDFA; Thu, 4 May 2000 10:33:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 05FE15DE0C; Thu, 4 May 2000 10:33:00 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 82D5C5DDFA for ; Thu, 4 May 2000 10:32:59 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20147; Thu, 4 May 2000 07:32:57 -0700 (PDT) Received: from vayne (muc-isdn-19 [129.157.164.119]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id QAA03866; Thu, 4 May 2000 16:32:53 +0200 (MET DST) Date: Thu, 4 May 2000 16:41:37 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: zeroconf security - conclusions To: Peter Johansson Cc: Zero Configuration In-Reply-To: "Your message with ID" <3.0.5.32.20000503225217.00958cd0@PacBell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Peter Johansson wrote: > At 05:20 PM 5/3/00 +0200, Erik Guttman wrote: > < Schiller pointed out in Adelaide, there are social mechanisms for security > at home and between neighbors. The real threat is the anonymous stranger > attacking from afar.>> > > If I have been tripped up by some subtle meaning of the word "remote" above > (and consequently misunderstand the conclusion) please excuse me. > > But if I read it correctly, I don't feel at all secure that I have adequate > social mechanisms for addressing security transgressions by my neighbors! ... > I am not willing to wait to apply "social mechanisms" until after a > sociopathic neighbor has made off with the goods! ... > > So, someone, please tell me I've completely misunderstood what has been said. You didn't misunderstand. Is your claim is that normal social mechanisms are OK for noise, smells and so on, as they 'stay on the other side of the fence (are clearly coming from your neighbor's place, etc)?' But with shared access media (wireless, power line, network area cable subnets) we have no 'walls' between us an our neighbors? In this case, should we modify the scenario to be a binary 'insider' / 'outsider' model. Like those who you give a housekey to, and those you don't? (Is the problem with the 'close' / 'remote' model is that trust and effective reprisal mechanisms aren't 'proximity' based, they're more 'who knows which flower pot the house key is hidden in' based? Erik From owner-zeroconf@merit.edu Thu May 4 10:52:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07224 for ; Thu, 4 May 2000 10:52:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B34CA5DE03; Thu, 4 May 2000 10:52:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A22F85DE00; Thu, 4 May 2000 10:52:02 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 407275DDFD for ; Thu, 4 May 2000 10:52:01 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27054; Thu, 4 May 2000 07:51:58 -0700 (PDT) Received: from vayne (muc-isdn-19 [129.157.164.119]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id QAA04846; Thu, 4 May 2000 16:51:55 +0200 (MET DST) Date: Thu, 4 May 2000 17:00:39 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: zeroconf security - conclusions To: "Walker, Jesse" Cc: "'Erik Guttman'" , zeroconf@merit.edu, dan.mcdonald@eng.sun.com In-Reply-To: "Your message with ID" <392A357CE6FFD111AC3E00A0C99848B002FE962D@hdsmsx31.hd.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Walker, > >> Configuration for such networks can be very simple (such as >> a group key) since we don't have to differentiate between users >> and devices on a zeroconf network. > > Use of group keys means LAN users need to reconfigure all > the devices relying on these keys to reestablish security in the event > of divorce or betrayal by a previously trusted friend. If wireless > indeed makes easy revocation a requirement, as I think it does, then > it is unfortunately hard to imagine anything short of a credentials > management scheme being part of the solution. If this is the case, > the proper requirement is that the credentials management scheme has > to be simple to use. Is easy revocation a requirement? Or does easy configuration (and reconfiguration, say contingent upon physical access to the device) satisfy this? After a break up, just call the locksmith. You don't need restraining orders, revised contracts, etc. normally. I am concerned that if the security requirements are complicated we won't make any headway. If they really are complicated, good to know. But maybe we can keep this simple. > 2.1) Hosts MUST implement a security mechanism (or mechanisms) to > protect against the following threats: > > + Hoarding attack. A host MUST be able to determine whether a > multicast address allocation claim (used in a claim and defend > protocol) is legitimate or not. > > Depending on your assumptions about overall network size and credentials > management schemes deployed, this might not be feasible except by using > asymmetric key techniques. My guess is the low end market will be > unwilling to pay the computational and administrative costs associated > with existing asymmetric key techniques for a very long time. Perhaps > this requirement should be a MAY; or it may simply require more > discussion to narrow the requirement sufficiently to something vendors > can implement and users will actually deploy. Or can we drop this requirement? The DHC WG agreed that ARP security was a non-starter. Service discovery and name to address resolution aren't subject to hoarding attacks. How vital is it to protect networks from multicast allocation hoarding attacks? I did not mention that some work has gone into protecting neighbor discovery in IPv6 (which would defend against hoarding attacks as a result). Dan, do you want to say something about this? > 2.2) Hosts MUST be configurable to use that security, as easily > as possible. > > My concern with this is we need to specify what we means by "security". > Without doing that, this is a very open-ended requirement, and we will > never be able to determine when implementations do or do not conform. > That's what I'm trying to specify in section 2.1. These are requirements we are discussing, so the specification is necessarily high level. If there are too few or too many security features in that list - let's discuss it now. Erik From owner-zeroconf@merit.edu Thu May 4 11:33:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08581 for ; Thu, 4 May 2000 11:33:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA2655DDE4; Thu, 4 May 2000 11:30:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BCD0A5DDE9; Thu, 4 May 2000 11:30:27 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 5CB255DDE4 for ; Thu, 4 May 2000 11:30:25 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07737 for ; Thu, 4 May 2000 09:30:23 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA14562; Thu, 4 May 2000 11:00:52 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA26677; Thu, 4 May 2000 11:00:49 -0400 (EDT) Message-ID: <39118FD7.42999E37@sun.com> Date: Thu, 04 May 2000 10:57:27 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: zeroconf security - conclusions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for a good summary, Erik. Clearly, there are still some unresolved issues. But agreeing on which protocols are in scope and providing a list of generally agreed-upon threats is a good start. > 0.3) The scenario in which these threats occur is 'remote access.' > As Jeff Schiller pointed out in Adelaide, there are social > mechanisms for security at home and between neighbors. The > real threat is the anonymous stranger attacking from afar. > > Configuration for such networks can be very simple (such as > a group key) since we don't have to differentiate between users > and devices on a zeroconf network. > > We have to assume that an attacker can send and receive messages > on the local network since in important cases Zero Configuration > protocols will be used on shared access links (RF, power line, > 'neighborhood area network' cable subnets, etc.) If an attacker can send and receive messages on the local network (and I agree with that), that's the important thing from a security perspective. Whether the attacker is a neighbor or not is not important. I suggest you drop the first paragraph here, unless you can explain some way in which it changes the security analysis. > Protecting against IP address hoarding is NOT a requirement > for IPv4, since it would mean securing ARP. That is the > concensus of the DHC WG. ... > + Antagonistic server attack. The host MUST be able to determine > whether a discovered DHCP server, DNS server, SLP DA (or > whatever) or MADCAP server is to be used or not. > > NOTE: This requirement *looks good,* but how many systems in > practice are enabled to use DHCP authentication, DNSSec, SLP > authentication and MADCAP security? We are 'raising the bar' > by requiring this, not avoiding 'making IP less secure' which > is our guiding principal. If we don't protect against IP address hoarding and we don't protect against an antagonistic server attack, we're leaving two big holes in our security system. I agree that securing ARP and authenticating servers isn't easy. But we can't just stick our heads in the sand. What about a simple solution like link-level encryption using a shared key (such as 802.11 WEP)? Or layer 3 crypto with a shared key (IPsec without IKE)? This would secure all network access with a single mechanism. Admittedly, it doesn't have all of the features of protocol-specific security, but it *is* fairly simple! And it addresses all of the threats we have listed. -Steve From owner-zeroconf@merit.edu Thu May 4 13:58:46 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12788 for ; Thu, 4 May 2000 13:58:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C9FD5E01C; Thu, 4 May 2000 13:57:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4DD5B5DE86; Thu, 4 May 2000 13:57:21 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id 8FD1E5E01C for ; Thu, 4 May 2000 13:57:19 -0400 (EDT) Received: from SERVER ([63.199.7.253]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FU1001Q9P6W0L@mta5.snfc21.pbi.net> for ZeroConf@merit.edu; Thu, 4 May 2000 10:13:44 -0700 (PDT) Date: Thu, 04 May 2000 10:12:45 -0700 From: Peter Johansson Subject: Re: zeroconf security - conclusions In-reply-to: X-Sender: Celeborn@PacBell.net To: Erik Guttman Cc: Zero Configuration Message-id: <3.0.5.32.20000504101245.00952100@PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Content-type: text/plain; charset="us-ascii" References: <"Your message with ID <3.0.5.32.20000503225217.00958cd0"@PacBell.net> Sender: owner-zeroconf@merit.edu Precedence: bulk At 04:41 PM 5/4/00 +0200, Erik Guttman wrote: <> Yes, just so. <