From tho@koanlogic.com Mon Aug 1 10:57:32 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF2C11E8114 for ; Mon, 1 Aug 2011 10:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUg7qCmYQ4xN for ; Mon, 1 Aug 2011 10:57:31 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id BA9A911E8077 for ; Mon, 1 Aug 2011 10:57:31 -0700 (PDT) Received: from host171-48-dynamic.49-79-r.retail.telecomitalia.it ([79.49.48.171]:51858 helo=[192.168.0.2]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Qnwk4-0006IT-Dv for core@ietf.org; Mon, 01 Aug 2011 13:57:37 -0400 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 19:56:55 +0200 Message-Id: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.49.48.171 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Subject: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:57:32 -0000 Hi all, the Security Consideration section of draft-ietf-core-coap fails to = acknowledge what I perceive as a major security threat in the CoAP = protocol: IP address spoofing. Due to the non-reliability of UDP (and to some extent to the duplicate = messages processing strategy too), a rogue endpoint which is free to = read and write messages carried by the constrained network (i.e. NoSec = or SharedKey deployments, and also, though with a possibly narrower = scope, MultiKey with nodes/key ratio > 1:1), may easily attack a single = endpoint, a group of endpoints, as well as the whole network. E.g. by: 1 - spoofing RST in response to a CON message, thus making an endpoint = "deaf"; or 2 - spoofing the entire response with forged payload/options (this has = different levels of impact: from single response disruption, to much = bolder attacks on the supporting infrastructure, e.g. poisoning proxy = caches, or tricking validation / lookup interfaces in resource = directories and, more generally, any component that stores global = network state and uses CoAP as the messaging facility to handle state = set/update's is a potential target.); or 3 - spoofing a multicast request for a target node which may result in = both network congestion/collapse and victim DoS'ing / forced wakeup from = sleeping; or 4 - spoofing observe messages, etc. {{ 1-3 can be combined together (e.g. 3 to mute an endpoint, and 2 to = act as the endpoint with respect to a client) if needed (e.g make 4 = cleaner). }} Practically every corner of the messaging layer can be abused in this = way, which IMO asks for a clear warning sign to be exposed in the spec. In principle, spoofing can be detected by CoAP only in case CON = semantics is used, because of unexpected ACK/RSTs coming from the = deceived endpoint. But this imposes keeping track of the used MIDs = which is not always possible, and moreover detection becomes available = usually after the damage is already done. Anyway, when the threat of a "bad thing" -- as opposed to the usual "bad = guy" :-) -- is concrete and painful, the only real solution is to use = MultiKey(1:1) or Certificate modes. Any other security setup would lead = (with different levels of ramification, and involving more or less = complexity on the attacker side), to vulnerable deployments. Bye, t. PS about attack feasibility: I fear that getting crypto keys from a = large, unattended, constrained network would not be a particularly hard = task: one or more endpoints could be easily stolen, and key extraction = (i.e. locate high entropy bytes out of a tiny storage) should be quite = feasible with such simple devices. In such scenarios (i.e. large, = unattended deployments), infiltrating rogue endpoints could be really = cheap and effective.= From rgm@labs.htt-consult.com Tue Aug 2 05:19:38 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8622621F8E92 for ; Tue, 2 Aug 2011 05:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81dvAY2VURey for ; Tue, 2 Aug 2011 05:19:37 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA8B21F8B3D for ; Tue, 2 Aug 2011 05:19:37 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D0DF36282C; Tue, 2 Aug 2011 12:18:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zfud2xbgA8e; Tue, 2 Aug 2011 08:18:33 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 34FEF62A9B; Tue, 2 Aug 2011 08:18:33 -0400 (EDT) Message-ID: <4E37EB18.3010400@labs.htt-consult.com> Date: Tue, 02 Aug 2011 08:18:32 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> In-Reply-To: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> Content-Type: multipart/alternative; boundary="------------010708080307050904020405" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 12:19:38 -0000 This is a multi-part message in MIME format. --------------010708080307050904020405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It is borderline impossible to defend against layer 3 attacks at layer 5 (or 4 depending on where you place DTLS, but I look at it as 5). This is fairly well understood and why I push for 'defense in depth' with all layers being secured: MAC, IP, Transport (though perhaps TCPcrypt done right fits in here too). Given this, you ARE allowed to state in your security considerations that this is a layer 3 attack and SHOULD be addressed with a layer 3 security framework like ESP. Of course, securing at all layers has its cost. This can be mitigated by having a single KMP that works for them all. It could be further addresses if we went after good security APIs, such that optimize security work when there really is overlap (say devices are only a single hop so MACsec could 'address' all needs). On 08/01/2011 01:56 PM, Thomas Fossati wrote: > Hi all, > > the Security Consideration section of draft-ietf-core-coap fails to acknowledge what I perceive as a major security threat in the CoAP protocol: IP address spoofing. > > Due to the non-reliability of UDP (and to some extent to the duplicate messages processing strategy too), a rogue endpoint which is free to read and write messages carried by the constrained network (i.e. NoSec or SharedKey deployments, and also, though with a possibly narrower scope, MultiKey with nodes/key ratio> 1:1), may easily attack a single endpoint, a group of endpoints, as well as the whole network. E.g. by: > > 1 - spoofing RST in response to a CON message, thus making an endpoint "deaf"; or > 2 - spoofing the entire response with forged payload/options (this has different levels of impact: from single response disruption, to much bolder attacks on the supporting infrastructure, e.g. poisoning proxy caches, or tricking validation / lookup interfaces in resource directories and, more generally, any component that stores global network state and uses CoAP as the messaging facility to handle state set/update's is a potential target.); or > 3 - spoofing a multicast request for a target node which may result in both network congestion/collapse and victim DoS'ing / forced wakeup from sleeping; or > 4 - spoofing observe messages, etc. > > {{ 1-3 can be combined together (e.g. 3 to mute an endpoint, and 2 to act as the endpoint with respect to a client) if needed (e.g make 4 cleaner). }} > > Practically every corner of the messaging layer can be abused in this way, which IMO asks for a clear warning sign to be exposed in the spec. > > > In principle, spoofing can be detected by CoAP only in case CON semantics is used, because of unexpected ACK/RSTs coming from the deceived endpoint. But this imposes keeping track of the used MIDs which is not always possible, and moreover detection becomes available usually after the damage is already done. > > Anyway, when the threat of a "bad thing" -- as opposed to the usual "bad guy" :-) -- is concrete and painful, the only real solution is to use MultiKey(1:1) or Certificate modes. Any other security setup would lead (with different levels of ramification, and involving more or less complexity on the attacker side), to vulnerable deployments. > > Bye, t. > > PS about attack feasibility: I fear that getting crypto keys from a large, unattended, constrained network would not be a particularly hard task: one or more endpoints could be easily stolen, and key extraction (i.e. locate high entropy bytes out of a tiny storage) should be quite feasible with such simple devices. In such scenarios (i.e. large, unattended deployments), infiltrating rogue endpoints could be really cheap and effective. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------010708080307050904020405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It is borderline impossible to defend against layer 3 attacks at layer 5 (or 4 depending on where you place DTLS, but I look at it as 5).  This is fairly well understood and why I push for 'defense in depth' with all layers being secured:  MAC, IP, Transport (though perhaps TCPcrypt done right fits in here too).

Given this, you ARE allowed to state in your security considerations that this is a layer 3 attack and SHOULD be addressed with a layer 3 security framework like ESP.

Of course, securing at all layers has its cost.  This can be mitigated by having a single KMP that works for them all.  It could be further addresses if we went after good security APIs, such that optimize security work when there really is overlap (say devices are only a single hop so MACsec could 'address' all needs).

On 08/01/2011 01:56 PM, Thomas Fossati wrote: 
Hi all,

the Security Consideration section of draft-ietf-core-coap fails to acknowledge what I perceive as a major security threat in the CoAP protocol: IP address spoofing.

Due to the non-reliability of UDP (and to some extent to the duplicate messages processing strategy too), a rogue endpoint which is free to read and write messages carried by the constrained network (i.e. NoSec or SharedKey deployments, and also, though with a possibly narrower scope, MultiKey with nodes/key ratio > 1:1), may easily attack a single endpoint, a group of endpoints, as well as the whole network. E.g. by:

1 - spoofing RST in response to a CON message, thus making an endpoint "deaf"; or
2 - spoofing the entire response with forged payload/options (this has different levels of impact: from single response disruption, to much bolder attacks on the supporting infrastructure, e.g. poisoning proxy caches, or tricking validation / lookup interfaces in resource directories and, more generally, any component that stores global network state and uses CoAP as the messaging facility to handle state set/update's is a potential target.); or
3 - spoofing a multicast request for a target node which may result in both network congestion/collapse and victim DoS'ing / forced wakeup from sleeping; or
4 - spoofing observe messages, etc.

{{ 1-3 can be combined together (e.g. 3 to mute an endpoint, and 2 to act as the endpoint with respect to a client) if needed (e.g make 4 cleaner). }}

Practically every corner of the messaging layer can be abused in this way, which IMO asks for a clear warning sign to be exposed in the spec.


In principle, spoofing can be detected by CoAP only in case CON semantics is used, because of unexpected ACK/RSTs coming from the deceived endpoint.  But this imposes keeping track of the used MIDs which is not always possible, and moreover detection becomes available usually after the damage is already done.

Anyway, when the threat of a "bad thing" -- as opposed to the usual "bad guy" :-) -- is concrete and painful, the only real solution is to use MultiKey(1:1) or Certificate modes.  Any other security setup would lead (with different levels of ramification, and involving more or less complexity on the attacker side), to vulnerable deployments.

Bye, t.

PS about attack feasibility: I fear that getting crypto keys from a large, unattended, constrained network would not be a particularly hard task: one or more endpoints could be easily stolen, and key extraction (i.e. locate high entropy bytes out of a tiny storage) should be quite feasible with such simple devices.  In such scenarios (i.e. large, unattended deployments), infiltrating rogue endpoints could be really cheap and effective.
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------010708080307050904020405-- From tho@koanlogic.com Tue Aug 2 06:49:51 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AAE21F8781 for ; Tue, 2 Aug 2011 06:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLYyptkoSRhV for ; Tue, 2 Aug 2011 06:49:50 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6247821F87D6 for ; Tue, 2 Aug 2011 06:49:50 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:56099 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QoFM0-0007nP-E5; Tue, 02 Aug 2011 09:49:58 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E37EB18.3010400@labs.htt-consult.com> Date: Tue, 2 Aug 2011 15:49:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 13:49:51 -0000 On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote: > It is borderline impossible to defend against layer 3 attacks at layer = 5 (or 4 depending on where you place DTLS, but I look at it as 5). This = is fairly well understood and why I push for 'defense in depth' with all = layers being secured: MAC, IP, Transport (though perhaps TCPcrypt done = right fits in here too). >=20 > Given this, you ARE allowed to state in your security considerations = that this is a layer 3 attack and SHOULD be addressed with a layer 3 = security framework like ESP. Right. It scares me thinking about how cheap for the attacker it'd be, and how = wide the possible consequences on the CoAP infrastructure are (proxies, = RDs, etc.) Which, in turn, makes me wonder why we don't mandate IPsec = instead of DTLS. t.= From kerlyn2001@gmail.com Tue Aug 2 07:16:16 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D0321F884F for ; Tue, 2 Aug 2011 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdQvCMc9Mn+o for ; Tue, 2 Aug 2011 07:16:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB18C21F87C5 for ; Tue, 2 Aug 2011 07:16:15 -0700 (PDT) Received: by iye7 with SMTP id 7so9684791iye.31 for ; Tue, 02 Aug 2011 07:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8crzz60muDs0DvwhVMS9yrT4hA5RyxJsdNtIf1CtT9A=; b=Gu2i9iek0DJrvja6wP4unzxb8RZNrhY/PlZUPTsANoiFAejdHTzH6neieQ1gelDNKs zPQmaP1lF+qvnbRTFRwB2dlDVzpr7ql/13UZufD5Xj/VU25WpLMnN1vdn/SiMQVeM8X6 S4qtB4uv7YAWEcqefbq/LPtWymzju3f5hxZe0= MIME-Version: 1.0 Received: by 10.42.245.5 with SMTP id ls5mr4131621icb.149.1312294584795; Tue, 02 Aug 2011 07:16:24 -0700 (PDT) Received: by 10.43.48.134 with HTTP; Tue, 2 Aug 2011 07:16:24 -0700 (PDT) In-Reply-To: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> Date: Tue, 2 Aug 2011 10:16:24 -0400 Message-ID: From: Kerry Lynn To: Thomas Fossati Content-Type: multipart/alternative; boundary=90e6ba5bc13791421504a986643e Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:16:16 -0000 --90e6ba5bc13791421504a986643e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati wrote: > On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote: > > It is borderline impossible to defend against layer 3 attacks at layer 5 > (or 4 depending on where you place DTLS, but I look at it as 5). This is > fairly well understood and why I push for 'defense in depth' with all layers > being secured: MAC, IP, Transport (though perhaps TCPcrypt done right fits > in here too). > > > > Given this, you ARE allowed to state in your security considerations that > this is a layer 3 attack and SHOULD be addressed with a layer 3 security > framework like ESP. > > Right. > > It scares me thinking about how cheap for the attacker it'd be, and how > wide the possible consequences on the CoAP infrastructure are (proxies, RDs, > etc.) Which, in turn, makes me wonder why we don't mandate IPsec instead of > DTLS. > > t. > It seems an additional benefit to mandating IPsec is that it could secure multicast as well as unicast CoAP traffic? -K- > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --90e6ba5bc13791421504a986643e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati <tho@koanlogic.com> wrote:
<= div class=3D"gmail_quote">
On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote:
> It is borderline impossible to defend against layer 3 attacks at layer= 5 (or 4 depending on where you place DTLS, but I look at it as 5). =A0This= is fairly well understood and why I push for 'defense in depth' wi= th all layers being secured: =A0MAC, IP, Transport (though perhaps TCPcrypt= done right fits in here too).
>
> Given this, you ARE allowed to state in your security considerations t= hat this is a layer 3 attack and SHOULD be addressed with a layer 3 securit= y framework like ESP.

Right.

It scares me thinking about how cheap for the attacker it'd be, and how= wide the possible consequences on the CoAP infrastructure are (proxies, RD= s, etc.) =A0Which, in turn, makes me wonder why we don't mandate IPsec = instead of DTLS.

t.

It seems an additional b= enefit to mandating IPsec is that it could secure
multicast as we= ll as unicast CoAP traffic?

-K-=A0
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--90e6ba5bc13791421504a986643e-- From robert.cragie@gmail.com Tue Aug 2 07:38:22 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C5A21F86E6 for ; Tue, 2 Aug 2011 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIDY2eHopmWS for ; Tue, 2 Aug 2011 07:38:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45BE621F86E0 for ; Tue, 2 Aug 2011 07:38:21 -0700 (PDT) Received: by vws12 with SMTP id 12so6265459vws.31 for ; Tue, 02 Aug 2011 07:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ERYRyRM9fjThmyJD0VE0g4XcM2KlmtvKihzj3IDLDCk=; b=tuQDkre5g9KDnIqtMcJDhHJarah4lZt9pZXSZ+5Dlk19wjsYBWAb4PTfUAXscVe2Nk 3MWMv57rcrrRhb3hQVwqpnxdI3dCHOCXun/wLpsWRgdaE5/oGHC759FSU2adJdjX6Y4i OJ8gaAcZs8vwxqiMNwbxLJL+yu3NmcIUHYo/U= MIME-Version: 1.0 Received: by 10.52.95.81 with SMTP id di17mr5473643vdb.167.1312295910283; Tue, 02 Aug 2011 07:38:30 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.6.15 with HTTP; Tue, 2 Aug 2011 07:38:30 -0700 (PDT) In-Reply-To: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> Date: Tue, 2 Aug 2011 15:38:30 +0100 X-Google-Sender-Auth: drcycA6JpNFoJJpRO8q5Tif9hHA Message-ID: From: Robert Cragie To: Kerry Lynn Content-Type: multipart/alternative; boundary=20cf307f398c9298e504a986b3fc Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:38:22 -0000 --20cf307f398c9298e504a986b3fc Content-Type: text/plain; charset=ISO-8859-1 I agree with Bob's assessment and agree with the 'defense in depth' approach. Cross-layer key management and support for protocols and cipher suites which can work across layers is also important. IPsec has peer-to-peer security associations so multicast doesn't directly work here. You would need group keys and group SAs for that to work in IPsec. I believe there are ways of carrying encapsulated multicast IP datagrams across SAs using GRE or something similar. Robert On Tue, Aug 2, 2011 at 3:16 PM, Kerry Lynn wrote: > On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati wrote: > >> On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote: >> > It is borderline impossible to defend against layer 3 attacks at layer 5 >> (or 4 depending on where you place DTLS, but I look at it as 5). This is >> fairly well understood and why I push for 'defense in depth' with all layers >> being secured: MAC, IP, Transport (though perhaps TCPcrypt done right fits >> in here too). >> > >> > Given this, you ARE allowed to state in your security considerations >> that this is a layer 3 attack and SHOULD be addressed with a layer 3 >> security framework like ESP. >> >> Right. >> >> It scares me thinking about how cheap for the attacker it'd be, and how >> wide the possible consequences on the CoAP infrastructure are (proxies, RDs, >> etc.) Which, in turn, makes me wonder why we don't mandate IPsec instead of >> DTLS. >> >> t. >> > > It seems an additional benefit to mandating IPsec is that it could secure > multicast as well as unicast CoAP traffic? > > -K- > >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --20cf307f398c9298e504a986b3fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Bob's assessment and agree with the 'defense in depth&= #39; approach. Cross-layer key management and support for protocols and cip= her suites which can work across layers is also important.

IPsec has peer-to-peer security associations so multicast doesn't = directly work here. You would need group keys and group SAs for that to wor= k in IPsec. =A0I believe there are ways of carrying encapsulated multicast = IP datagrams across SAs using GRE or something similar.

Robert

On Tue, Aug 2,= 2011 at 3:16 PM, Kerry Lynn <kerlyn2001@gmail.com> wrote:
On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati <tho@koa= nlogic.com> wrote:
On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote:
> It is borderline impossible to defend against layer 3 attacks at layer= 5 (or 4 depending on where you place DTLS, but I look at it as 5). =A0This= is fairly well understood and why I push for 'defense in depth' wi= th all layers being secured: =A0MAC, IP, Transport (though perhaps TCPcrypt= done right fits in here too).
>
> Given this, you ARE allowed to state in your security considerations t= hat this is a layer 3 attack and SHOULD be addressed with a layer 3 securit= y framework like ESP.

Right.

It scares me thinking about how cheap for the attacker it'd be, and how= wide the possible consequences on the CoAP infrastructure are (proxies, RD= s, etc.) =A0Which, in turn, makes me wonder why we don't mandate IPsec = instead of DTLS.

t.

It seems an additi= onal benefit to mandating IPsec is that it could secure
multicast= as well as unicast CoAP traffic?

-K-=A0
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core


_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core


--20cf307f398c9298e504a986b3fc-- From rgm@labs.htt-consult.com Tue Aug 2 10:38:53 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9110511E8080 for ; Tue, 2 Aug 2011 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1lrt5Ya8oae for ; Tue, 2 Aug 2011 10:38:52 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8646411E807F for ; Tue, 2 Aug 2011 10:38:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id DF9AC62A91; Tue, 2 Aug 2011 17:38:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sp0OtvBrqwH; Tue, 2 Aug 2011 13:38:20 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 99BBE62A7F; Tue, 2 Aug 2011 13:38:20 -0400 (EDT) Message-ID: <4E38360C.4010405@labs.htt-consult.com> Date: Tue, 02 Aug 2011 13:38:20 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:38:53 -0000 On 08/02/2011 09:49 AM, Thomas Fossati wrote: > On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote: >> It is borderline impossible to defend against layer 3 attacks at layer 5 (or 4 depending on where you place DTLS, but I look at it as 5). This is fairly well understood and why I push for 'defense in depth' with all layers being secured: MAC, IP, Transport (though perhaps TCPcrypt done right fits in here too). >> >> Given this, you ARE allowed to state in your security considerations that this is a layer 3 attack and SHOULD be addressed with a layer 3 security framework like ESP. > Right. > > It scares me thinking about how cheap for the attacker it'd be, and how wide the possible consequences on the CoAP infrastructure are (proxies, RDs, etc.) Which, in turn, makes me wonder why we don't mandate IPsec instead of DTLS. This debate is almost 2 decades old and we will not resolve it here. Actually it would be mandating ESP with keying as the DTLS mandate does not mandate certificate-based key establishment. Perhaps wording along the lines of if an API can disclose and manage IP layer security to CoAP, the IP layer security can be used instead of DTLS. One arguement often used for TLS over ESP is packet size and resulting communication overhead. You can have large TLS packets that span multiple IP datagrams. This is often mentioned in cellular discussions. But in CoAP, and DTLS this may NOT be an issue. From rgm@labs.htt-consult.com Tue Aug 2 10:44:08 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B8611E808C for ; Tue, 2 Aug 2011 10:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5ORHKbrhCw4 for ; Tue, 2 Aug 2011 10:44:08 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5411E807F for ; Tue, 2 Aug 2011 10:44:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A10E162A91; Tue, 2 Aug 2011 17:43:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc1A8-vKRTXh; Tue, 2 Aug 2011 13:43:46 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 220A762A7F; Tue, 2 Aug 2011 13:43:46 -0400 (EDT) Message-ID: <4E383751.7040907@labs.htt-consult.com> Date: Tue, 02 Aug 2011 13:43:45 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Kerry Lynn References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040208010909010202090403" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:44:09 -0000 This is a multi-part message in MIME format. --------------040208010909010202090403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/02/2011 10:16 AM, Kerry Lynn wrote: > On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati > wrote: > > On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote: > > It is borderline impossible to defend against layer 3 attacks at > layer 5 (or 4 depending on where you place DTLS, but I look at it > as 5). This is fairly well understood and why I push for 'defense > in depth' with all layers being secured: MAC, IP, Transport > (though perhaps TCPcrypt done right fits in here too). > > > > Given this, you ARE allowed to state in your security > considerations that this is a layer 3 attack and SHOULD be > addressed with a layer 3 security framework like ESP. > > Right. > > It scares me thinking about how cheap for the attacker it'd be, > and how wide the possible consequences on the CoAP infrastructure > are (proxies, RDs, etc.) Which, in turn, makes me wonder why we > don't mandate IPsec instead of DTLS. > > t. > > > It seems an additional benefit to mandating IPsec is that it could secure > multicast as well as unicast CoAP traffic? ESP CAN support multicast, the challenge is the keying. You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys. This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway. BTW, this is basically what we did for IEEE 802.11i. --------------040208010909010202090403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/02/2011 10:16 AM, Kerry Lynn wrote:
On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati <tho@koanlogic.com> wrote:
On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote:
> It is borderline impossible to defend against layer 3 attacks at layer 5 (or 4 depending on where you place DTLS, but I look at it as 5).  This is fairly well understood and why I push for 'defense in depth' with all layers being secured:  MAC, IP, Transport (though perhaps TCPcrypt done right fits in here too).
>
> Given this, you ARE allowed to state in your security considerations that this is a layer 3 attack and SHOULD be addressed with a layer 3 security framework like ESP.

Right.

It scares me thinking about how cheap for the attacker it'd be, and how wide the possible consequences on the CoAP infrastructure are (proxies, RDs, etc.)  Which, in turn, makes me wonder why we don't mandate IPsec instead of DTLS.

t.

It seems an additional benefit to mandating IPsec is that it could secure
multicast as well as unicast CoAP traffic?

ESP CAN support multicast, the challenge is the keying.  You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.

BTW, this is basically what we did for IEEE 802.11i.


--------------040208010909010202090403-- From oscar.novo@ericsson.com Wed Aug 3 03:06:40 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6AA21F8AFC for ; Wed, 3 Aug 2011 03:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXd68IZupdTW for ; Wed, 3 Aug 2011 03:06:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2B21F8B4C for ; Wed, 3 Aug 2011 03:06:39 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-93-4e391dab0602 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C3.68.20773.BAD193E4; Wed, 3 Aug 2011 12:06:35 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.37]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Aug 2011 12:06:35 +0200 From: Oscar Novo To: Klaus Hartke , "core@ietf.org" Date: Wed, 3 Aug 2011 12:06:33 +0200 Thread-Topic: [core] Observing Resources in CoAP: re-ordering Thread-Index: AcxIkGSsrHZUWfJQSb+gkYgCNcBa6AJM2RVg Message-ID: <58E207308662A748A4AC1ECB4E885614113C712CD8@ESESSCMS0355.eemea.ericsson.se> References: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Observing Resources in CoAP: re-ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:06:40 -0000 Hi, Klaus wrote: >A simple counter for notifications is actually an acceptable implementatio= n, provided that the server does not reuse the same counter value within 2^= 16 seconds. The counter increments in one for every notification, once the value reach = the max value (2^16), the counter starts from 0 again. There is not any tim= e constraint of 2^16 seconds in the solution I proposed. =20 Klaus wrote: >The server needs no state to generate the option value. The client needs j= ust to remember two values per observation relationship; the if-expression = is copied literally from the >draft. I'm not sure how this can be further s= implified; suggestions are welcome. Incrementing an integer value in every notification is far more simple to i= mplement. The server and client only need to keep the last counter value, a= simple integer value.=20 Oscar On 22 July 2011 12:10, Oscar Novo wrote: > > Hi, > > I think the way the observe draft handles reordering is far too complicat= ed. Besides, I'm wondering how this solution would work for sleeping client= s.=A0Have you think about it? At least, I can=A0see some problems with the = actual solution. > > I think a neat solution would=A0be that=A0the=A0server increments in one = an integer value in every notification to indicate the order of the notific= ations. What do you think about that? > > Cheers, > > Oscar _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From oscar.novo@ericsson.com Wed Aug 3 03:26:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9483121F8B61 for ; Wed, 3 Aug 2011 03:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA6JghtV-cVU for ; Wed, 3 Aug 2011 03:26:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BB21A21F8B5B for ; Wed, 3 Aug 2011 03:26:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e4-4e39227d9540 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.CB.09774.D72293E4; Wed, 3 Aug 2011 12:27:09 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.37]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 3 Aug 2011 12:27:09 +0200 From: Oscar Novo To: Carsten Bormann Date: Wed, 3 Aug 2011 12:27:08 +0200 Thread-Topic: [core] Observing Resources in CoAP: re-ordering Thread-Index: AcxKwsU1ESfoFXdMSDqBJ9BRM0yX0wHAo+FA Message-ID: <58E207308662A748A4AC1ECB4E885614113C712CF8@ESESSCMS0355.eemea.ericsson.se> References: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> <58E207308662A748A4AC1ECB4E8856140DCC0F8F29@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] Observing Resources in CoAP: re-ordering X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:26:59 -0000 On Jul 25, 2011, at 12:31, Oscar Novo wrote: > If we suppose the case of a network which has some sleeping nodes and som= e caching nodes which store the observation methods and deliver them once t= he sleeping-nodes are awake. How an sleeping observer could handle the hist= orical notifications data of a subject if the wake up time of the node is h= igher than 18.2 hours? Carsten wrote: >I'm not sure I understand the question, but after 18.2 hours the time limi= t of t2 < (t1 + (2**14)) is long gone, so there would be no need to check f= or reordered messages=20 >reaching back that long. I agree the example is a bit unrealistic but I still think it is not good i= dea to link the re-ordering with the local timestamp. I guess some type of = time synchronization scheme will be needed to have the necessary time accur= acy in the nodes which will complicate even more the whole solution.=20 I consider a simple counter option would be a better solution. Cheers, Oscar =20 From tho@koanlogic.com Wed Aug 3 09:27:22 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E5221F8B2E for ; Wed, 3 Aug 2011 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYSji-5CLmBQ for ; Wed, 3 Aug 2011 09:27:22 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7E21F8A70 for ; Wed, 3 Aug 2011 09:27:22 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:60313 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QoeI1-00013X-D6; Wed, 03 Aug 2011 12:27:31 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Wed, 3 Aug 2011 18:26:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8693D6B5-C4B9-49F7-93C2-5AD8D8A8D0AC@koanlogic.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:27:22 -0000 On Aug 2, 2011, at 4:16 PM, Kerry Lynn wrote: > It seems an additional benefit to mandating IPsec is that it could = secure > multicast as well as unicast CoAP traffic? Yes, with a caveat: the IPsec SAD support for multicast is limited to = manual configuration. So in cases where the lifetime of the SA is an = issue, some other method for handling dynamic SAs configuration is = needed.= From tho@koanlogic.com Wed Aug 3 09:38:54 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7721F8876 for ; Wed, 3 Aug 2011 09:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT-SlEqIGwES for ; Wed, 3 Aug 2011 09:38:53 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id A6DD921F87F0 for ; Wed, 3 Aug 2011 09:38:53 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:60342 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QoeTB-00014S-3T; Wed, 03 Aug 2011 12:39:03 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E383751.7040907@labs.htt-consult.com> Date: Wed, 3 Aug 2011 18:38:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:38:54 -0000 On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: > ESP CAN support multicast, the challenge is the keying. =20 Right, sorry for the delayed duplicate answer. > You can create a mulitcast overlay on a set of unicast security SAs, = using the unicast security to transmit the multicast keys. This could = be a simplier implementation than adding a multicast key distribution = independent of the unicast one you need anyway. In many use cases (low-to-medium group population) this can be a good = solution. SA lifetimes must be weighted against group cardinality in a = sensible way, thus not saturating the medium with control traffic.= From rgm@labs.htt-consult.com Wed Aug 3 11:05:26 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8021F881C for ; Wed, 3 Aug 2011 11:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Av-3fc2IvWF for ; Wed, 3 Aug 2011 11:05:25 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id B780F21F880C for ; Wed, 3 Aug 2011 11:05:25 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0E64A62934; Wed, 3 Aug 2011 18:05:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRTEzu6M6VQq; Wed, 3 Aug 2011 14:04:56 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 2C42C62AAE; Wed, 3 Aug 2011 14:04:52 -0400 (EDT) Message-ID: <4E398DC4.6050601@labs.htt-consult.com> Date: Wed, 03 Aug 2011 14:04:52 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:05:26 -0000 On 08/03/2011 12:38 PM, Thomas Fossati wrote: > On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >> ESP CAN support multicast, the challenge is the keying. > Right, sorry for the delayed duplicate answer. > >> You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys. This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway. > In many use cases (low-to-medium group population) this can be a good solution. SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic. If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method. I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders. Of course as with any multicast approach you loose source authenticity to some degree. I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution. Otherwise a large 4f PAN would be totally unsecurable (key scaling problems). From kerlyn2001@gmail.com Wed Aug 3 11:22:23 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3621F8A70 for ; Wed, 3 Aug 2011 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsClFAzLccar for ; Wed, 3 Aug 2011 11:22:22 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6216121F8588 for ; Wed, 3 Aug 2011 11:22:21 -0700 (PDT) Received: by pzk33 with SMTP id 33so2286072pzk.18 for ; Wed, 03 Aug 2011 11:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LFezlXDBPw8zMiSCJzjG4WaEsFEyZlnaGuGTs3SpkEM=; b=d64MwW8TazT5A3i9IUZ41ffb7xJS0VpCgSFW1t7n7bUcKVkrzW2hlrVP2aEuFSZF2r YDu3MzwzdawVlWyOFLXwj9EmNSaAaw1iFJmhrt810sG5k2Bm8idCPBq/K7qSnQWubfU/ cdQqr8BWZpNzrm3ngoZ1qTkd1hG5w2XfMH4RA= MIME-Version: 1.0 Received: by 10.142.61.33 with SMTP id j33mr5295620wfa.135.1312395753724; Wed, 03 Aug 2011 11:22:33 -0700 (PDT) Received: by 10.68.42.167 with HTTP; Wed, 3 Aug 2011 11:22:33 -0700 (PDT) In-Reply-To: <4E398DC4.6050601@labs.htt-consult.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> Date: Wed, 3 Aug 2011 14:22:33 -0400 Message-ID: From: Kerry Lynn To: Robert Moskowitz Content-Type: multipart/alternative; boundary=001636e1f93db49a4b04a99df25c Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:22:23 -0000 --001636e1f93db49a4b04a99df25c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz wrote: > On 08/03/2011 12:38 PM, Thomas Fossati wrote: > >> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >> >>> ESP CAN support multicast, the challenge is the keying. >>> >> Right, sorry for the delayed duplicate answer. >> >> You can create a mulitcast overlay on a set of unicast security SAs, >>> using the unicast security to transmit the multicast keys. This could be a >>> simplier implementation than adding a multicast key distribution independent >>> of the unicast one you need anyway. >>> >> In many use cases (low-to-medium group population) this can be a good >> solution. SA lifetimes must be weighted against group cardinality in a >> sensible way, thus not saturating the medium with control traffic. >> > > If multicast is REALLY important to CoAP, we probably do need to look at a > deployable multicast security method. I would seriously recommend looking > at the key heirarchy model in IEEE 802.1AE which allows for a single master > key managed by some entity (out of scope of 1AE and addressed in 1X) but a > heirarchy that allows for multiple senders. Of course as with any multicast > approach you loose source authenticity to some degree. > > I have been thinking about this for the 802.15.4f situation where the > sensor has a receive radio that can be used at join time for key > distribution. Otherwise a large 4f PAN would be totally unsecurable (key > scaling problems). > > There are two main scenarios where multicast is indicated. The first is for resource discovery bootstrapping (i.e. finding resource directories if they exist, without a priori configuration, and discovering CoAP servers and resources directly of RDs don't exist in the network). It's not clear that these exchanges need to be secured (nobody seems overly worried about mDNS or DNS spoofing at the moment) but I can imagine concerns about this in some applications. The second scenario is for applications that require near simultaneity for user quality-of-experience and the oft-cited example is a single switch controlling a floor of lighting controllers. In both cases, I suspect that just being able to assert that you're a "member of the tribe" is sufficient authentication. -K- --001636e1f93db49a4b04a99df25c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz= <rgm@labs= .htt-consult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wr= ote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using = the unicast security to transmit the multicast keys. =A0This could be a sim= plier implementation than adding a multicast key distribution independent o= f the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solut= ion. =A0SA lifetimes must be weighted against group cardinality in a sensib= le way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a = deployable multicast security method. =A0I would seriously recommend lookin= g at the key heirarchy model in IEEE 802.1AE which allows for a single mast= er key managed by some entity (out of scope of 1AE and addressed in 1X) but= a heirarchy that allows for multiple senders. =A0Of course as with any mul= ticast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the senso= r has a receive radio that can be used at join time for key distribution. = =A0Otherwise a large 4f PAN would be totally unsecurable (key scaling probl= ems).

There are two main scenarios where multicast is indicate= d. =A0The first
is for resource discovery bootstrapping (i.e. finding r= esource directories
if they exist, without a priori configuration= , and discovering CoAP
servers and resources directly of RDs don't exist in the network).= =A0It's
not clear that these exchanges need to be secured (n= obody seems
overly worried about mDNS or DNS spoofing at the mome= nt) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultan= eity
for user quality-of-experience and the oft-cited example is = a single
switch controlling a floor of lighting controllers.

In both cases, I suspect that just being able to assert that you'= ;re a
"member of the tribe" is sufficient authenticatio= n.

-K-
--001636e1f93db49a4b04a99df25c-- From stpeter@stpeter.im Wed Aug 3 11:31:08 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E4021F8A23 for ; Wed, 3 Aug 2011 11:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFCazAULM9w3 for ; Wed, 3 Aug 2011 11:31:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 83BCC21F89BE for ; Wed, 3 Aug 2011 11:31:08 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D52841386 for ; Wed, 3 Aug 2011 12:32:42 -0600 (MDT) Message-ID: <4E3993F8.7060908@stpeter.im> Date: Wed, 03 Aug 2011 12:31:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: core@ietf.org References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> In-Reply-To: <4E398DC4.6050601@labs.htt-consult.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [core] multicast (was: Re: Spoofing in CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:31:09 -0000 On 8/3/11 12:04 PM, Robert Moskowitz wrote: > On 08/03/2011 12:38 PM, Thomas Fossati wrote: >> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>> ESP CAN support multicast, the challenge is the keying. >> Right, sorry for the delayed duplicate answer. >> >>> You can create a mulitcast overlay on a set of unicast security SAs, >>> using the unicast security to transmit the multicast keys. This >>> could be a simplier implementation than adding a multicast key >>> distribution independent of the unicast one you need anyway. >> In many use cases (low-to-medium group population) this can be a good >> solution. SA lifetimes must be weighted against group cardinality in >> a sensible way, thus not saturating the medium with control traffic. > > If multicast is REALLY important to CoAP, we probably do need to look at > a deployable multicast security method. Good question. I think it would be helpful for the group to decide how important multicast is (or is not) to CoAP... Peter -- Peter Saint-Andre https://stpeter.im/ From zach@sensinode.com Wed Aug 3 11:39:56 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A8111E807D for ; Wed, 3 Aug 2011 11:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee4Hi77M7fCH for ; Wed, 3 Aug 2011 11:39:55 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1D11E8078 for ; Wed, 3 Aug 2011 11:39:53 -0700 (PDT) Received: from [192.168.1.100] (87-93-94-199.bb.dnainternet.fi [87.93.94.199]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p73Idxup023406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2011 21:40:00 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-26--917846761; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4E3993F8.7060908@stpeter.im> Date: Wed, 3 Aug 2011 21:40:02 +0300 Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] multicast (was: Re: Spoofing in CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:39:56 -0000 --Apple-Mail-26--917846761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2011, at 9:31 PM, Peter Saint-Andre wrote: > >=20 > On 8/3/11 12:04 PM, Robert Moskowitz wrote: >> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>>> ESP CAN support multicast, the challenge is the keying. >>> Right, sorry for the delayed duplicate answer. >>>=20 >>>> You can create a mulitcast overlay on a set of unicast security = SAs, >>>> using the unicast security to transmit the multicast keys. This >>>> could be a simplier implementation than adding a multicast key >>>> distribution independent of the unicast one you need anyway. >>> In many use cases (low-to-medium group population) this can be a = good >>> solution. SA lifetimes must be weighted against group cardinality = in >>> a sensible way, thus not saturating the medium with control traffic. >>=20 >> If multicast is REALLY important to CoAP, we probably do need to look = at >> a deployable multicast security method. >=20 > Good question. I think it would be helpful for the group to decide how > important multicast is (or is not) to CoAP... Secure multicast is not urgent enough for us to solve as part of the = current charter IMO, however I do think it is interesting upcoming work = for CoRE, or in cooperation with the security area. Something to keep in = mind for rechartering.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-26--917846761 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgwMzE4NDAw MlowIwYJKoZIhvcNAQkEMRYEFMZaZBg8IXupTCNcD1/dW59RzKMfMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBACTLuGyVMfY97Ka1rrdKYp4v7fq77MqZHrJ8rnLIJUMfD9KaewAJ3RqF 9Nkmq3iBP/FR1UH+m5XuwGxhkQPX8tJf9d04f+89R/VUNrSJK3PoH69+DqeJwMvVS2+zsJA4rpys nCKJZEidhD3WDc4FTnC9LkXeV3x5YGPz+gNKMOUem+/ncoD6GJhrkywZqd8i2zhsW0r4dyQ+Jz+s kmdLlOTWUoN/caKSzxCMQ4Ci2LxnoFiADw2MmMUxv08GjGEfTQBQZgo/4NUTC81tPdr/wt1837Qv xLGt4IwQUK3u8gafbxU2gfBhEejZDl/CCRsFxEA7Ygdqq9OQN7UELO2fSTgAAAAAAAA= --Apple-Mail-26--917846761-- From rgm@labs.htt-consult.com Wed Aug 3 11:51:43 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEEE11E8084 for ; Wed, 3 Aug 2011 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp8uYU589+xx for ; Wed, 3 Aug 2011 11:51:43 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id D95F311E807D for ; Wed, 3 Aug 2011 11:51:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0C47462AAE; Wed, 3 Aug 2011 18:51:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klpj91q3x51h; Wed, 3 Aug 2011 14:51:19 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 0D37862A65; Wed, 3 Aug 2011 14:51:19 -0400 (EDT) Message-ID: <4E3998A6.8070703@labs.htt-consult.com> Date: Wed, 03 Aug 2011 14:51:18 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Kerry Lynn References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080406050809070303030708" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:51:44 -0000 This is a multi-part message in MIME format. --------------080406050809070303030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 02:22 PM, Kerry Lynn wrote: > On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz > > wrote: > > On 08/03/2011 12:38 PM, Thomas Fossati wrote: > > On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: > > ESP CAN support multicast, the challenge is the keying. > > Right, sorry for the delayed duplicate answer. > > You can create a mulitcast overlay on a set of unicast > security SAs, using the unicast security to transmit the > multicast keys. This could be a simplier implementation > than adding a multicast key distribution independent of > the unicast one you need anyway. > > In many use cases (low-to-medium group population) this can be > a good solution. SA lifetimes must be weighted against group > cardinality in a sensible way, thus not saturating the medium > with control traffic. > > > If multicast is REALLY important to CoAP, we probably do need to > look at a deployable multicast security method. I would seriously > recommend looking at the key heirarchy model in IEEE 802.1AE which > allows for a single master key managed by some entity (out of > scope of 1AE and addressed in 1X) but a heirarchy that allows for > multiple senders. Of course as with any multicast approach you > loose source authenticity to some degree. > > I have been thinking about this for the 802.15.4f situation where > the sensor has a receive radio that can be used at join time for > key distribution. Otherwise a large 4f PAN would be totally > unsecurable (key scaling problems). > > There are two main scenarios where multicast is indicated. The first > is for resource discovery bootstrapping (i.e. finding resource directories > if they exist, without a priori configuration, and discovering CoAP > servers and resources directly of RDs don't exist in the network). It's > not clear that these exchanges need to be secured (nobody seems > overly worried about mDNS or DNS spoofing at the moment) but I > can imagine concerns about this in some applications. > > The second scenario is for applications that require near simultaneity > for user quality-of-experience and the oft-cited example is a single > switch controlling a floor of lighting controllers. The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image). The switch instructs the lights all at once. So there is a single direction of multicast, from the controller to all lights in the multicast group. This is an 'easy' keying problem. There is an admin process that defines the group, and in so doing results in the group key distribution: "These and these lights are for the shop floor and these are the lobby." The real challenge comes if there are multiple senders/listeners. Perhaps stress sensors on a bridge to multiple/redundant collectors. > > In both cases, I suspect that just being able to assert that you're a > "member of the tribe" is sufficient authentication. IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security. --------------080406050809070303030708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as with any multicast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would be totally unsecurable (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the lights all at once.  So there is a single direction of multicast, from the controller to all lights in the multicast group.  This is an 'easy' keying problem.  There is an admin process that defines the group, and in so doing results in the group key distribution:  "These and these lights are for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners.  Perhaps stress sensors on a bridge to multiple/redundant collectors.


In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.


--------------080406050809070303030708-- From rgm@labs.htt-consult.com Wed Aug 3 11:59:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3511E808B for ; Wed, 3 Aug 2011 11:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4nEX3RZxn0P for ; Wed, 3 Aug 2011 11:59:01 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57511E807E for ; Wed, 3 Aug 2011 11:59:01 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1973C62AA1; Wed, 3 Aug 2011 18:58:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYRhigX6CWio; Wed, 3 Aug 2011 14:58:42 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id A2EB662A65; Wed, 3 Aug 2011 14:58:42 -0400 (EDT) Message-ID: <4E399A62.5020906@labs.htt-consult.com> Date: Wed, 03 Aug 2011 14:58:42 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Zach Shelby References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:59:02 -0000 On 08/03/2011 02:40 PM, Zach Shelby wrote: > On Aug 3, 2011, at 9:31 PM, Peter Saint-Andre wrote: > >> >> >> On 8/3/11 12:04 PM, Robert Moskowitz wrote: >>> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>>>> ESP CAN support multicast, the challenge is the keying. >>>> Right, sorry for the delayed duplicate answer. >>>> >>>>> You can create a mulitcast overlay on a set of unicast security SAs, >>>>> using the unicast security to transmit the multicast keys. This >>>>> could be a simplier implementation than adding a multicast key >>>>> distribution independent of the unicast one you need anyway. >>>> In many use cases (low-to-medium group population) this can be a good >>>> solution. SA lifetimes must be weighted against group cardinality in >>>> a sensible way, thus not saturating the medium with control traffic. >>> If multicast is REALLY important to CoAP, we probably do need to look at >>> a deployable multicast security method. >> Good question. I think it would be helpful for the group to decide how >> important multicast is (or is not) to CoAP... > Secure multicast is not urgent enough for us to solve as part of the current charter IMO, however I do think it is interesting upcoming work for CoRE, or in cooperation with the security area. Something to keep in mind for rechartering. There are 'simple' solutions for things like controlling a bank of lights that take little text copying (this is a basic feature in 802.11 architecture). For the hard stuff, yeah, push it off :) From d.sturek@att.net Wed Aug 3 12:03:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3F21F854F for ; Wed, 3 Aug 2011 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0GVQsGiFVYq for ; Wed, 3 Aug 2011 12:03:12 -0700 (PDT) Received: from nm23.access.bullet.mail.mud.yahoo.com (nm23.access.bullet.mail.mud.yahoo.com [66.94.237.88]) by ietfa.amsl.com (Postfix) with SMTP id 9634E21F8508 for ; Wed, 3 Aug 2011 12:03:12 -0700 (PDT) Received: from [66.94.237.196] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Aug 2011 19:03:19 -0000 Received: from [66.94.237.115] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Aug 2011 19:03:19 -0000 Received: from [127.0.0.1] by omp1020.access.mail.mud.yahoo.com with NNFMP; 03 Aug 2011 19:03:19 -0000 X-Yahoo-Newman-Id: 525866.58211.bm@omp1020.access.mail.mud.yahoo.com Received: (qmail 88996 invoked from network); 3 Aug 2011 19:03:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1312398199; bh=Zkka5Uud9eGc9qAVAuyuSyIwGay/ZDmfpMO0iUDDXJg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=OwsLEL9MOit/7TkgWUXPCb1mVEAsTWrGAdyxl9sq2Z9rCUk/cDixW4mlUfWdjLvbqZxMnytL6E2M4duopTvLvBDtPLW307JSHvZt76Cc9EbnCI/u6I/61tpAMQvOwQ1gJQSXaxmRPxrJEgg6QImcTdsR9tB1lN/b25zQaOmP5/Q= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oF7BRugVM1m9ayeyd6tfQl0YtOz8uyUnQkaqJgJ.AxgGFz0 xRN6ABDyFyVxcwqHv5wEEUeG_Q9RcqLn9KFGoqREVfxw7luirCFyJ55cSUV_ CretOFw_1qC8jkhJAwoaw5.as0INg_AXqA_5zXijW9Gove1Y.Zi75Itiq.YL NkNINkK2lg9sqvyerozn0hmUjFlSuHXtOC3rC78gOe9M0d9aLItM1wTYByAd 7r3ejpQ5l9xAKaMi1KPr1v.AdwmkBHZHUJ2MUK82HbOf.8qUl9Gk.RSVqxYv .4nOds1BMcmYHncrGveVB7zzmUWZxE9gzQusHA3PwuoE4Xw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.183.15.120] (d.sturek@38.126.23.254 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 03 Aug 2011 12:03:18 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 12:03:09 -0700 From: Don Sturek To: Robert Moskowitz , Kerry Lynn Message-ID: Thread-Topic: [core] Spoofing in CoAP In-Reply-To: <4E3998A6.8070703@labs.htt-consult.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395217798_173573" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:03:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395217798_173573 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Robert, Here is a typical scene lighting solution: 1) Multiple lamps grouped together (multicast group) 2) Multiple switches (imagine a large room with switches on either end that can switch on/off the grouped lamps) I think it would be hard to define lighting to be just single sender to a a multicast group. Don From: Robert Moskowitz Date: Wed, 03 Aug 2011 14:51:18 -0400 To: Kerry Lynn Cc: Subject: Re: [core] Spoofing in CoAP On 08/03/2011 02:22 PM, Kerry Lynn wrote: > > On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz > wrote: > >> >> >> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >> >>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>> >>>> ESP CAN support multicast, the challenge is the keying. >>>> >>> Right, sorry for the delayed duplicate answer. >>> >>> >>>> You can create a mulitcast overlay on a set of unicast security SAs, using >>>> the unicast security to transmit the multicast keys. This could be a >>>> simplier implementation than adding a multicast key distribution >>>> independent of the unicast one you need anyway. >>>> >>> In many use cases (low-to-medium group population) this can be a good >>> solution. SA lifetimes must be weighted against group cardinality in a >>> sensible way, thus not saturating the medium with control traffic. >>> >> >> >> >> If multicast is REALLY important to CoAP, we probably do need to look at a >> deployable multicast security method. I would seriously recommend looking at >> the key heirarchy model in IEEE 802.1AE which allows for a single master key >> managed by some entity (out of scope of 1AE and addressed in 1X) but a >> heirarchy that allows for multiple senders. Of course as with any multicast >> approach you loose source authenticity to some degree. >> >> I have been thinking about this for the 802.15.4f situation where the sensor >> has a receive radio that can be used at join time for key distribution. >> Otherwise a large 4f PAN would be totally unsecurable (key scaling problems). >> >> > > There are two main scenarios where multicast is indicated. The first > is for resource discovery bootstrapping (i.e. finding resource directories > > if they exist, without a priori configuration, and discovering CoAP > > servers and resources directly of RDs don't exist in the network). It's > > not clear that these exchanges need to be secured (nobody seems > > overly worried about mDNS or DNS spoofing at the moment) but I > > can imagine concerns about this in some applications. > > > > > The second scenario is for applications that require near simultaneity > > for user quality-of-experience and the oft-cited example is a single > > switch controlling a floor of lighting controllers. > The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image). The switch instructs the lights all at once. So there is a single direction of multicast, from the controller to all lights in the multicast group. This is an 'easy' keying problem. There is an admin process that defines the group, and in so doing results in the group key distribution: "These and these lights are for the shop floor and these are the lobby." The real challenge comes if there are multiple senders/listeners. Perhaps stress sensors on a bridge to multiple/redundant collectors. > > > > > In both cases, I suspect that just being able to assert that you're a > > "member of the tribe" is sufficient authentication. > IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --B_3395217798_173573 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Robert,

Here is a typical scene lighting solution:

= 1)  Multiple lamps grouped together (multicast group)
2) &nbs= p;Multiple switches (imagine a large room with switches on either end that c= an switch on/off the grouped lamps)

I think it woul= d be hard to define lighting to be just single sender to a a multicast group= .

Don


From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 14:51:18 -0400
To: Kerry Lynn <kerlyn2001@gmail.com>
Cc: <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP
=
On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted= against group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as wi= th any multicast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would b= e totally unsecurable (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the lights all at once.  So= there is a single direction of multicast, from the controller to all lights in the multicast group.  This is an 'easy' keying problem.&= nbsp; There is an admin process that defines the group, and in so doing results in the group key distribution:  "These and these lights ar= e for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners. = Perhaps stress sensors on a bridge to multiple/redundant collectors.

In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.


_______________________________________________ core mailing list core@ietf.org https://www.ietf.org/m= ailman/listinfo/core --B_3395217798_173573-- From rgm@labs.htt-consult.com Wed Aug 3 12:25:18 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5021F8B44 for ; Wed, 3 Aug 2011 12:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwiQcWPsCoHi for ; Wed, 3 Aug 2011 12:25:17 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1F221F8B42 for ; Wed, 3 Aug 2011 12:25:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4F89062A9C; Wed, 3 Aug 2011 19:25:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUa2zn-HpvNf; Wed, 3 Aug 2011 15:24:47 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id C558E62934; Wed, 3 Aug 2011 15:24:47 -0400 (EDT) Message-ID: <4E39A07B.5070106@labs.htt-consult.com> Date: Wed, 03 Aug 2011 15:24:43 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070107050101070808080803" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:25:18 -0000 This is a multi-part message in MIME format. --------------070107050101070808080803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 03:03 PM, Don Sturek wrote: > Hi Robert, > > Here is a typical scene lighting solution: > > 1) Multiple lamps grouped together (multicast group) > 2) Multiple switches (imagine a large room with switches on either > end that can switch on/off the grouped lamps) > > I think it would be hard to define lighting to be just single sender > to a a multicast group. But do the switches directly communicate to the lights? Not through an energy controller? I can see a very high failure rate due to RF where some lights get the signal from a switch and others do not. Or are we counting on multiple IP relays to get to all the lights so the RF reachablity is mitigated? I suppose so. It seems so chaotic to do this without a controller. How do you define a lighting group? Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights. Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down. Rapping this up, if you go with a controller model, the security is a 'simple' single sender. If you go with the more open direct model, wait for us to work out the multisender model. > > > > From: Robert Moskowitz > > Date: Wed, 03 Aug 2011 14:51:18 -0400 > To: Kerry Lynn > > Cc: > > Subject: Re: [core] Spoofing in CoAP > > On 08/03/2011 02:22 PM, Kerry Lynn wrote: >> On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz >> > wrote: >> >> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >> >> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >> >> ESP CAN support multicast, the challenge is the keying. >> >> Right, sorry for the delayed duplicate answer. >> >> You can create a mulitcast overlay on a set of unicast >> security SAs, using the unicast security to transmit the >> multicast keys. This could be a simplier implementation >> than adding a multicast key distribution independent of >> the unicast one you need anyway. >> >> In many use cases (low-to-medium group population) this can >> be a good solution. SA lifetimes must be weighted against >> group cardinality in a sensible way, thus not saturating the >> medium with control traffic. >> >> >> If multicast is REALLY important to CoAP, we probably do need to >> look at a deployable multicast security method. I would >> seriously recommend looking at the key heirarchy model in IEEE >> 802.1AE which allows for a single master key managed by some >> entity (out of scope of 1AE and addressed in 1X) but a heirarchy >> that allows for multiple senders. Of course as with any >> multicast approach you loose source authenticity to some degree. >> >> I have been thinking about this for the 802.15.4f situation where >> the sensor has a receive radio that can be used at join time for >> key distribution. Otherwise a large 4f PAN would be totally >> unsecurable (key scaling problems). >> >> There are two main scenarios where multicast is indicated. The first >> is for resource discovery bootstrapping (i.e. finding resource >> directories >> if they exist, without a priori configuration, and discovering CoAP >> servers and resources directly of RDs don't exist in the network). It's >> not clear that these exchanges need to be secured (nobody seems >> overly worried about mDNS or DNS spoofing at the moment) but I >> can imagine concerns about this in some applications. >> >> The second scenario is for applications that require near simultaneity >> for user quality-of-experience and the oft-cited example is a single >> switch controlling a floor of lighting controllers. > > The switch talks to the energy controller to turn lights on/off (it > was explained to me how BAD 'toggle' is in this usage; I chuckled at > the image). The switch instructs the lights all at once. So there is > a single direction of multicast, from the controller to all lights in > the multicast group. This is an 'easy' keying problem. There is an > admin process that defines the group, and in so doing results in the > group key distribution: "These and these lights are for the shop > floor and these are the lobby." > > The real challenge comes if there are multiple senders/listeners. > Perhaps stress sensors on a bridge to multiple/redundant collectors. > >> >> In both cases, I suspect that just being able to assert that you're a >> "member of the tribe" is sufficient authentication. > > IF these apps use IP multicast (even broadcast), THEN we SHOULD > provide IP security. > > > --------------070107050101070808080803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 03:03 PM, Don Sturek wrote:
Hi Robert,

Here is a typical scene lighting solution:

1)  Multiple lamps grouped together (multicast group)
2)  Multiple switches (imagine a large room with switches on either end that can switch on/off the grouped lamps)

I think it would be hard to define lighting to be just single sender to a a multicast group.

But do the switches directly communicate to the lights?  Not through an energy controller?  I can see a very high failure rate due to RF where some lights get the signal from a switch and others do not.  Or are we counting on multiple IP relays to get to all the lights so the RF reachablity is mitigated?  I suppose so.  It seems so chaotic to do this without a controller.  How do you define a lighting group?

Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights.

Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down.

Rapping this up, if you go with a controller model, the security is a 'simple' single sender.  If you go with the more open direct model, wait for us to work out the multisender model.




From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 14:51:18 -0400
To: Kerry Lynn <kerlyn2001@gmail.com>
Cc: <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as with any multicast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would be totally unsecurable (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the lights all at once.  So there is a single direction of multicast, from the controller to all lights in the multicast group.  This is an 'easy' keying problem.  There is an admin process that defines the group, and in so doing results in the group key distribution:  "These and these lights are for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners.  Perhaps stress sensors on a bridge to multiple/redundant collectors.


In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.




--------------070107050101070808080803-- From d.sturek@att.net Wed Aug 3 12:34:35 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5C21F8B79 for ; Wed, 3 Aug 2011 12:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azFUd9J2w4pw for ; Wed, 3 Aug 2011 12:34:35 -0700 (PDT) Received: from nm1.access.bullet.mail.sp2.yahoo.com (nm1.access.bullet.mail.sp2.yahoo.com [98.139.44.128]) by ietfa.amsl.com (Postfix) with SMTP id 0AAA321F8B74 for ; Wed, 3 Aug 2011 12:34:35 -0700 (PDT) Received: from [98.139.44.100] by nm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 19:34:45 -0000 Received: from [98.139.44.82] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 19:34:45 -0000 Received: from [127.0.0.1] by omp1019.access.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 19:34:45 -0000 X-Yahoo-Newman-Id: 281190.71478.bm@omp1019.access.mail.sp2.yahoo.com Received: (qmail 51648 invoked from network); 3 Aug 2011 19:34:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1312400084; bh=RESfPqGn3c8N/nvKABFLLq91cPLHem4uMNHGWGIw+Bc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=MdaYZxWFpBCPGZnVETznz1eI4JUMuVm/IBdRcZEEBCYdt6odyQ26dOzhWTpXGHc4lEJWvwi2RrJ2r+hip+2853vIpdrM73seP7A4kaLlMl3ni6862jXBsYZK9sQKnfExytwbAZNewY2a7PR+qKPM1wQ6pvLZC/1tkuw8rkvey24= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PqSh.84VM1mSwgM7N3zTvAQJVwfKKXoTDzwT8cwH35wt209 z9VqqULVVQgYtaqYSqvAvMzTgQTcjLK7UcDgLAIjJvc6cP_8oN_MTUVhf_Y5 lzc6..tXR_geGs7n8bzNOEoDggcMsqdpC8dxgnjzs5xkpK9upDYIrWBA1K41 Wy4egjVXkvnrC4JrOP8Fm7O9Sy.vfi87tNdyk373twOyAIhjEyimeR411ShI 6xdRbGN7x8_UhRMXWoA42LNiTTYCP05uOMjnu4Vf1eubUWGgH0KbWDR8wZ4F F4RjW3LEt.VQBE7Yr5E_ggdRay5ccMp8pbaekhdR8sxj65Q-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.183.15.120] (d.sturek@38.126.23.254 with login) by smtp110.sbc.mail.ne1.yahoo.com with SMTP; 03 Aug 2011 12:34:44 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 12:34:40 -0700 From: Don Sturek To: Robert Moskowitz Message-ID: Thread-Topic: [core] Spoofing in CoAP In-Reply-To: <4E39A07B.5070106@labs.htt-consult.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395219684_273542" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:34:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395219684_273542 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Robert, I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller. The switches were provisioned to directly switch on/off the groups of lights. Don From: Robert Moskowitz Date: Wed, 03 Aug 2011 15:24:43 -0400 To: Don Sturek Cc: Kerry Lynn , Subject: Re: [core] Spoofing in CoAP On 08/03/2011 03:03 PM, Don Sturek wrote: > > Hi Robert, > > > > > Here is a typical scene lighting solution: > > > > > 1) Multiple lamps grouped together (multicast group) > > 2) Multiple switches (imagine a large room with switches on either end that > can switch on/off the grouped lamps) > > > > > I think it would be hard to define lighting to be just single sender to a a > multicast group. > But do the switches directly communicate to the lights? Not through an energy controller? I can see a very high failure rate due to RF where some lights get the signal from a switch and others do not. Or are we counting on multiple IP relays to get to all the lights so the RF reachablity is mitigated? I suppose so. It seems so chaotic to do this without a controller. How do you define a lighting group? Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights. Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down. Rapping this up, if you go with a controller model, the security is a 'simple' single sender. If you go with the more open direct model, wait for us to work out the multisender model. > > > > > > > > > From: Robert Moskowitz > Date: Wed, 03 Aug 2011 14:51:18 -0400 > To: Kerry Lynn > Cc: > Subject: Re: [core] Spoofing in CoAP > > > > > > > On 08/03/2011 02:22 PM, Kerry Lynn wrote: >> >> On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz >> wrote: >> >>> >>> >>> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>> >>>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>>> >>>>> ESP CAN support multicast, the challenge is the keying. >>>>> >>>> Right, sorry for the delayed duplicate answer. >>>> >>>> >>>>> You can create a mulitcast overlay on a set of unicast security SAs, >>>>> using the unicast security to transmit the multicast keys. This could be >>>>> a simplier implementation than adding a multicast key distribution >>>>> independent of the unicast one you need anyway. >>>>> >>>> In many use cases (low-to-medium group population) this can be a good >>>> solution. SA lifetimes must be weighted against group cardinality in a >>>> sensible way, thus not saturating the medium with control traffic. >>>> >>> >>> >>> >>> If multicast is REALLY important to CoAP, we probably do need to look at a >>> deployable multicast security method. I would seriously recommend looking >>> at the key heirarchy model in IEEE 802.1AE which allows for a single master >>> key managed by some entity (out of scope of 1AE and addressed in 1X) but a >>> heirarchy that allows for multiple senders. Of course as with any multicast >>> approach you loose source authenticity to some degree. >>> >>> I have been thinking about this for the 802.15.4f situation where the >>> sensor has a receive radio that can be used at join time for key >>> distribution. Otherwise a large 4f PAN would be totally unsecurable (key >>> scaling problems). >>> >>> >> >> There are two main scenarios where multicast is indicated. The first >> is for resource discovery bootstrapping (i.e. finding resource directories >> >> if they exist, without a priori configuration, and discovering CoAP >> >> servers and resources directly of RDs don't exist in the network). It's >> >> not clear that these exchanges need to be secured (nobody seems >> >> overly worried about mDNS or DNS spoofing at the moment) but I >> >> can imagine concerns about this in some applications. >> >> >> >> >> The second scenario is for applications that require near simultaneity >> >> for user quality-of-experience and the oft-cited example is a single >> >> switch controlling a floor of lighting controllers. >> > > The switch talks to the energy controller to turn lights on/off (it was > explained to me how BAD 'toggle' is in this usage; I chuckled at the image). > The switch instructs the lights all at once. So there is a single direction > of multicast, from the controller to all lights in the multicast group. This > is an 'easy' keying problem. There is an admin process that defines the > group, and in so doing results in the group key distribution: "These and > these lights are for the shop floor and these are the lobby." > > The real challenge comes if there are multiple senders/listeners. Perhaps > stress sensors on a bridge to multiple/redundant collectors. > > >> >> >> >> >> In both cases, I suspect that just being able to assert that you're a >> >> "member of the tribe" is sufficient authentication. >> > > IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP > security. > > > > > > --B_3395219684_273542 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Robert,

I did several projects with leading lighting manufacturers and, for = those projects which targeted residential and light commercial, there was no= centralized lighting controller.   The switches were provisioned to di= rectly switch on/off the groups of lights.

Don



Fr= om: Robert Moskowitz <r= gm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 15:24:43 -0400
To: Don Sturek <d.sturek@att.net&= gt;
Cc: Kerry Lynn <kerlyn2001@gmail.com>, <core@ietf.org>
Subj= ect: Re: [core] Spoofing in CoAP

On 08/03/2011 03:03 PM, Don Sturek wrote:
Hi Robert,

Here is a typical scene lighting solution:

1)  Multiple lamps grouped together (multicast group)
=
2)  Multiple switches (imagine a large room with switches o= n either end that can switch on/off the grouped lamps)

I think it would be hard to define lighting to be just single sender to a a multicast group.

But do the switches directly communicate to the lights?  Not throu= gh an energy controller?  I can see a very high failure rate due to R= F where some lights get the signal from a switch and others do not. = Or are we counting on multiple IP relays to get to all the lights so the RF reachablity is mitigated?  I suppose so.  It seems so = chaotic to do this without a controller.  How do you define a lighting group?

Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights.

Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down.

Rapping this up, if you go with a controller model, the security is a 'simple' single sender.  If you go with the more open direct model, wait for us to work out the multisender model.




From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 14:51:18 -0400
To: Kerry Lynn <kerlyn2001@gmail.com= >
Cc: <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-consult.com><= /span> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  Th= is could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as with any multicast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would be totally unsecurab= le (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the= lights all at once.  So there is a single direction of multicast, from the controller to all lights in the multicast group.  This is an 'easy' keying problem.  = There is an admin process that defines the group, and in so doing results in the group key distribution:  "These and these lights are for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners.  Perhaps stress sensors on a bridge to multiple/redundant collectors.


In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.




 --B_3395219684_273542-- From tho@koanlogic.com Wed Aug 3 12:41:34 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACF311E808B for ; Wed, 3 Aug 2011 12:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9IIkWweFnb6 for ; Wed, 3 Aug 2011 12:41:34 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE1C11E8086 for ; Wed, 3 Aug 2011 12:41:34 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:60681 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QohJk-0001Hv-Qv; Wed, 03 Aug 2011 15:41:46 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Wed, 3 Aug 2011 21:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:41:35 -0000 On Aug 3, 2011, at 9:34 PM, Don Sturek wrote: > I did several projects with leading lighting manufacturers and, for = those projects which targeted residential and light commercial, there = was no centralized lighting controller. The switches were provisioned = to directly switch on/off the groups of lights. In the scenario you are proposing there may be one only SA, selected by = SPI and the lamps+switches multicast address. =20 Formally it fits a many-to-many model, but all the (homomorphic) senders = can be actually seen as one only entity.= From tho@koanlogic.com Wed Aug 3 12:51:43 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC45721F884E for ; Wed, 3 Aug 2011 12:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skKrpUFMJpg5 for ; Wed, 3 Aug 2011 12:51:43 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 24FDB21F8849 for ; Wed, 3 Aug 2011 12:51:43 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:60762 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QohTe-0001Ii-8b; Wed, 03 Aug 2011 15:51:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E3993F8.7060908@stpeter.im> Date: Wed, 3 Aug 2011 21:51:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] multicast (was: Re: Spoofing in CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:51:43 -0000 On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote: > Good question. I think it would be helpful for the group to decide how > important multicast is (or is not) to CoAP... I'm implementing the humans/things bridging technology, so I'm = interested in knowing if secure multicast is in the spec only from an = "opportunistic" point of view. =20 That said, I believe secure multicast is a basic building block for a = number of very basic stuff: from efficient firmware update on a number = of same sensors, to instructing coordinated actuators, plus resource = discovery, etc. So, for me it's a +1 both in this spec round or in the next -- but my = vote may count less than one here, since I'm half a stakeholder WRT this = specific requisite. PS: I'm quite struck that no one (but Bob) has commented about the = extremely easy spoofing issue I've posed at the beginning of this same = thread. Do you all think it is so much unlikely ? It'd be interesting = bringing in some "spoofer" box next CoRE plug fest :-)= From robert.cragie@gmail.com Wed Aug 3 12:54:40 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EB321F85CE for ; Wed, 3 Aug 2011 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsfaHzzUefPG for ; Wed, 3 Aug 2011 12:54:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2914321F861A for ; Wed, 3 Aug 2011 12:54:40 -0700 (PDT) Received: by vws12 with SMTP id 12so1000143vws.31 for ; Wed, 03 Aug 2011 12:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EHA0mDgKW3Ev0Eg5ZFj2grL4wd5Vay4CG3rBg5jsLYc=; b=CE1S3fWw8hlldR3tf0L4SJ/NwJX9NBTEUVn7OTpd6NrysJtxTAaEa1fnlaO1BFzALI K0HmleE1VlQsTI9FsydsxPTK246MlK++WKm0bXeDFfSPEa2vvDXb6G1wetPc2xpK+8+S F9SV+pdIR/7AVap1jpZa7o2LxArGbgX5DuvLw= MIME-Version: 1.0 Received: by 10.52.71.106 with SMTP id t10mr8057471vdu.33.1312401292563; Wed, 03 Aug 2011 12:54:52 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.6.15 with HTTP; Wed, 3 Aug 2011 12:54:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Aug 2011 20:54:52 +0100 X-Google-Sender-Auth: rJtkv9IVwpB8SIyUkCe8ua5FwGI Message-ID: From: Robert Cragie To: Thomas Fossati Content-Type: multipart/alternative; boundary=20cf307cfbced8950d04a99f3c36 Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:54:40 -0000 --20cf307cfbced8950d04a99f3c36 Content-Type: text/plain; charset=ISO-8859-1 That's essentially how it needs to work in the sort of networks CoAP is targeted at. The multicast group addressing needs to be associated with group keying so 'zones' can be set up; the pairing of group addressing and group keying can act as a convenient way of being a zone member or not. It could also help with multicast echo suppression, although this can be difficult to configure unless the network is completely static. There can be no assumption of a central controller and it makes more sense to think of the multi-link subnet model. Robert On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati wrote: > On Aug 3, 2011, at 9:34 PM, Don Sturek wrote: > > I did several projects with leading lighting manufacturers and, for those > projects which targeted residential and light commercial, there was no > centralized lighting controller. The switches were provisioned to directly > switch on/off the groups of lights. > > In the scenario you are proposing there may be one only SA, selected by SPI > and the lamps+switches multicast address. > > Formally it fits a many-to-many model, but all the (homomorphic) senders > can be actually seen as one only entity. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --20cf307cfbced8950d04a99f3c36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's essentially how it needs to work in the sort of networks CoAP is= targeted at. The multicast group addressing needs to be associated with gr= oup keying so 'zones' can be set up; the pairing of group addressin= g and group keying can act as a convenient way of being a zone member or no= t. It could also help with multicast echo suppression, although this can be= difficult to configure unless the network is completely static. There can = be no assumption of a central controller and it makes more sense to think o= f the multi-link subnet model.

Robert

On Wed, Aug 3, 2011= at 8:40 PM, Thomas Fossati <tho@koanlogic.com> wrote:
On Aug 3, 2011, at 9:34 PM, Don Sturek wrote:
> I did several projects with leading lighting manufacturers and, for th= ose projects which targeted residential and light commercial, there was no = centralized lighting controller. =A0 The switches were provisioned to direc= tly switch on/off the groups of lights.

In the scenario you are proposing there may be one only SA, selected = by SPI and the lamps+switches multicast address.

Formally it fits a many-to-many model, but all the (homomorphic) senders ca= n be actually seen as one only entity.
_______________________________________________

--20cf307cfbced8950d04a99f3c36-- From rgm@labs.htt-consult.com Wed Aug 3 12:59:00 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034CF21F861E for ; Wed, 3 Aug 2011 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbMs9msl+ELz for ; Wed, 3 Aug 2011 12:58:58 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6FD21F8564 for ; Wed, 3 Aug 2011 12:58:58 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D3B2B62A9C; Wed, 3 Aug 2011 19:58:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1woP3t7H6Y2; Wed, 3 Aug 2011 15:58:38 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 2780862AA3; Wed, 3 Aug 2011 15:58:38 -0400 (EDT) Message-ID: <4E39A86E.7030207@labs.htt-consult.com> Date: Wed, 03 Aug 2011 15:58:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050307020109050401020409" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:59:00 -0000 This is a multi-part message in MIME format. --------------050307020109050401020409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 03:34 PM, Don Sturek wrote: > Hi Robert, > > I did several projects with leading lighting manufacturers and, for > those projects which targeted residential and light commercial, there > was no centralized lighting controller. The switches were > provisioned to directly switch on/off the groups of lights. I can't see this as anything but madness and chaos. Too much decentralized smarts to group switches and lights. Switches need to be dumb/cheap (unless they are multiple switches of bunches of buttons for bunches of actions). "I turn on. I turn off." Lights need to be dumb (I am on/off and tell me what to do, on/off). The cost in the controller with a UI to define groups of switches and groups of lights. I know we want Grandma to be able to set this up (she is more with it than Grandpa who is too busy fishing to care about the lights). But then Grandmas tend to be as computer savy as their Granddaughters (and more than their daughters) :) Wait... Ah, 'Provisioned'. So there was a provisioning system. That controller I postulated that set up the group then stepped aside? I have seen something like this in big convention halls (like in Vegas). I CAN define a group keying environment similar to 802.1AE. But I don't know if there is the energy to write if up formally and get it through the process. > > Don > > > > From: Robert Moskowitz > > Date: Wed, 03 Aug 2011 15:24:43 -0400 > To: Don Sturek > > Cc: Kerry Lynn >, > > > Subject: Re: [core] Spoofing in CoAP > > On 08/03/2011 03:03 PM, Don Sturek wrote: >> Hi Robert, >> >> Here is a typical scene lighting solution: >> >> 1) Multiple lamps grouped together (multicast group) >> 2) Multiple switches (imagine a large room with switches on either >> end that can switch on/off the grouped lamps) >> >> I think it would be hard to define lighting to be just single sender >> to a a multicast group. > > But do the switches directly communicate to the lights? Not through > an energy controller? I can see a very high failure rate due to RF > where some lights get the signal from a switch and others do not. Or > are we counting on multiple IP relays to get to all the lights so the > RF reachablity is mitigated? I suppose so. It seems so chaotic to do > this without a controller. How do you define a lighting group? > > Even with multiple switches (hey, my Dad is an electrician and I > apprenticed under him and did 3-way and 4-way switch wirings), you > want some intelligence in their control of the lights. > > Thinking about this further and wanting to 'simplify' the risk > boundaries, I can see a controller defining the environment but then > allowing direct communication in case the controller has been taken down. > > Rapping this up, if you go with a controller model, the security is a > 'simple' single sender. If you go with the more open direct model, > wait for us to work out the multisender model. > >> >> >> >> From: Robert Moskowitz > > >> Date: Wed, 03 Aug 2011 14:51:18 -0400 >> To: Kerry Lynn > >> Cc: > >> Subject: Re: [core] Spoofing in CoAP >> >> On 08/03/2011 02:22 PM, Kerry Lynn wrote: >>> On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz >>> > wrote: >>> >>> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>> >>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>> >>> ESP CAN support multicast, the challenge is the keying. >>> >>> Right, sorry for the delayed duplicate answer. >>> >>> You can create a mulitcast overlay on a set of unicast >>> security SAs, using the unicast security to transmit the >>> multicast keys. This could be a simplier implementation >>> than adding a multicast key distribution independent of >>> the unicast one you need anyway. >>> >>> In many use cases (low-to-medium group population) this can >>> be a good solution. SA lifetimes must be weighted against >>> group cardinality in a sensible way, thus not saturating the >>> medium with control traffic. >>> >>> >>> If multicast is REALLY important to CoAP, we probably do need to >>> look at a deployable multicast security method. I would >>> seriously recommend looking at the key heirarchy model in IEEE >>> 802.1AE which allows for a single master key managed by some >>> entity (out of scope of 1AE and addressed in 1X) but a heirarchy >>> that allows for multiple senders. Of course as with any >>> multicast approach you loose source authenticity to some degree. >>> >>> I have been thinking about this for the 802.15.4f situation >>> where the sensor has a receive radio that can be used at join >>> time for key distribution. Otherwise a large 4f PAN would be >>> totally unsecurable (key scaling problems). >>> >>> There are two main scenarios where multicast is indicated. The first >>> is for resource discovery bootstrapping (i.e. finding resource >>> directories >>> if they exist, without a priori configuration, and discovering CoAP >>> servers and resources directly of RDs don't exist in the network). It's >>> not clear that these exchanges need to be secured (nobody seems >>> overly worried about mDNS or DNS spoofing at the moment) but I >>> can imagine concerns about this in some applications. >>> >>> The second scenario is for applications that require near simultaneity >>> for user quality-of-experience and the oft-cited example is a single >>> switch controlling a floor of lighting controllers. >> >> The switch talks to the energy controller to turn lights on/off (it >> was explained to me how BAD 'toggle' is in this usage; I chuckled at >> the image). The switch instructs the lights all at once. So there >> is a single direction of multicast, from the controller to all lights >> in the multicast group. This is an 'easy' keying problem. There is >> an admin process that defines the group, and in so doing results in >> the group key distribution: "These and these lights are for the shop >> floor and these are the lobby." >> >> The real challenge comes if there are multiple senders/listeners. >> Perhaps stress sensors on a bridge to multiple/redundant collectors. >> >>> >>> In both cases, I suspect that just being able to assert that you're a >>> "member of the tribe" is sufficient authentication. >> >> IF these apps use IP multicast (even broadcast), THEN we SHOULD >> provide IP security. >> >> >> > -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------050307020109050401020409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 03:34 PM, Don Sturek wrote:
Hi Robert,

I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller.   The switches were provisioned to directly switch on/off the groups of lights.

I can't see this as anything but madness and chaos. Too much decentralized smarts to group switches and lights.

Switches need to be dumb/cheap (unless they are multiple switches of bunches of buttons for bunches of actions).  "I turn on.  I turn off."  Lights need to be dumb (I am on/off and tell me what to do, on/off).  The cost in the controller with a UI to define groups of switches and groups of lights.

I know we want Grandma to be able to set this up (she is more with it than Grandpa who is too busy fishing to care about the lights).  But then Grandmas tend to be as computer savy as their Granddaughters (and more than their daughters)  :)


Wait...

Ah, 'Provisioned'.

So there was a provisioning system.  That controller I postulated that set up the group then stepped aside?  I have seen something like this in big convention halls (like in Vegas).  I  CAN define a group keying environment similar to 802.1AE.  But I don't know if there is the energy to write if up formally and get it through the process.


Don



From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 15:24:43 -0400
To: Don Sturek <d.sturek@att.net>
Cc: Kerry Lynn <kerlyn2001@gmail.com>, <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 03:03 PM, Don Sturek wrote:
Hi Robert,

Here is a typical scene lighting solution:

1)  Multiple lamps grouped together (multicast group)
2)  Multiple switches (imagine a large room with switches on either end that can switch on/off the grouped lamps)

I think it would be hard to define lighting to be just single sender to a a multicast group.

But do the switches directly communicate to the lights?  Not through an energy controller?  I can see a very high failure rate due to RF where some lights get the signal from a switch and others do not.  Or are we counting on multiple IP relays to get to all the lights so the RF reachablity is mitigated?  I suppose so.  It seems so chaotic to do this without a controller.  How do you define a lighting group?

Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights.

Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down.

Rapping this up, if you go with a controller model, the security is a 'simple' single sender.  If you go with the more open direct model, wait for us to work out the multisender model.




From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 14:51:18 -0400
To: Kerry Lynn <kerlyn2001@gmail.com>
Cc: <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as with any multicast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would be totally unsecurable (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the lights all at once.  So there is a single direction of multicast, from the controller to all lights in the multicast group.  This is an 'easy' keying problem.  There is an admin process that defines the group, and in so doing results in the group key distribution:  "These and these lights are for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners.  Perhaps stress sensors on a bridge to multiple/redundant collectors.


In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.





--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------050307020109050401020409-- From rgm@labs.htt-consult.com Wed Aug 3 13:00:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C938821F86C7 for ; Wed, 3 Aug 2011 13:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTsjqTdJ3ay4 for ; Wed, 3 Aug 2011 13:00:59 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0D21F8564 for ; Wed, 3 Aug 2011 13:00:59 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B17C362A9C; Wed, 3 Aug 2011 20:00:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVV1sd6F84F5; Wed, 3 Aug 2011 16:00:40 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 7B82D6293E; Wed, 3 Aug 2011 16:00:40 -0400 (EDT) Message-ID: <4E39A8E8.6090200@labs.htt-consult.com> Date: Wed, 03 Aug 2011 16:00:40 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:00:59 -0000 On 08/03/2011 03:40 PM, Thomas Fossati wrote: > On Aug 3, 2011, at 9:34 PM, Don Sturek wrote: >> I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller. The switches were provisioned to directly switch on/off the groups of lights. > In the scenario you are proposing there may be one only SA, selected by SPI and the lamps+switches multicast address. > > Formally it fits a many-to-many model, but all the (homomorphic) senders can be actually seen as one only entity. There are key heirarchy challenges here. Your IV space MUST be segmented somehow or you are up against some simple attacks. From rgm@labs.htt-consult.com Wed Aug 3 13:02:36 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB38221F83E2 for ; Wed, 3 Aug 2011 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEdbOd2ylnbk for ; Wed, 3 Aug 2011 13:02:36 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id ED91C21F81D7 for ; Wed, 3 Aug 2011 13:02:35 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8829862A9C; Wed, 3 Aug 2011 20:02:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikZE1rcK3cRd; Wed, 3 Aug 2011 16:02:17 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id E9FB86293E; Wed, 3 Aug 2011 16:02:16 -0400 (EDT) Message-ID: <4E39A948.1070803@labs.htt-consult.com> Date: Wed, 03 Aug 2011 16:02:16 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010602090007070203040107" Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:02:36 -0000 This is a multi-part message in MIME format. --------------010602090007070203040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 03:51 PM, Thomas Fossati wrote: > On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote: >> Good question. I think it would be helpful for the group to decide how >> important multicast is (or is not) to CoAP... > I'm implementing the humans/things bridging technology, so I'm interested in knowing if secure multicast is in the spec only from an "opportunistic" point of view. > > That said, I believe secure multicast is a basic building block for a number of very basic stuff: from efficient firmware update on a number of same sensors, to instructing coordinated actuators, plus resource discovery, etc. > > So, for me it's a +1 both in this spec round or in the next -- but my vote may count less than one here, since I'm half a stakeholder WRT this specific requisite. > > > PS: I'm quite struck that no one (but Bob) I jumped in pretty fast for many to give me a +1 vote on the layering challenges. > has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread. Do you all think it is so much unlikely ? It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-) > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------010602090007070203040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 03:51 PM, Thomas Fossati wrote: 
On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote:

Good question. I think it would be helpful for the group to decide how
important multicast is (or is not) to CoAP...

I'm implementing the humans/things bridging technology, so I'm interested in knowing if secure multicast is in the spec only from an "opportunistic" point of view.  

That said, I believe secure multicast is a basic building block for a number of very basic stuff: from efficient firmware update on a number of same sensors, to instructing coordinated actuators, plus resource discovery, etc.

So, for me it's a +1 both in this spec round or in the next -- but my vote may count less than one here, since I'm half a stakeholder WRT this specific requisite.


PS: I'm quite struck that no one (but Bob)

I jumped in pretty fast for many to give me a +1 vote on the layering challenges.

 has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread.  Do you all think it is so much unlikely ?  It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-)
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------010602090007070203040107-- From kerlyn2001@gmail.com Wed Aug 3 13:04:14 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B729621F8429 for ; Wed, 3 Aug 2011 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IPieUr4UffC for ; Wed, 3 Aug 2011 13:04:13 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7321F83E2 for ; Wed, 3 Aug 2011 13:04:13 -0700 (PDT) Received: by pzk33 with SMTP id 33so2528788pzk.18 for ; Wed, 03 Aug 2011 13:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I2lrtoBxOgyEw5pszOH3l901xymdrgbDEQeIgqHKCtQ=; b=Ea1BypoQWztc2FZfsf47DeH45xTGiYbs7Z9vbOgREOL0616qwhKwZa+3gbZxcHQp4K 37ncfs1veN6l7Zuobee/GGGJ+8U4rrokYfPXz7oM8aYDdVZeF2E/5VLF6u3H4VzKEvSM A6J9E6KdDan/Y+AAGPiuG+ZjQpfIWLbA6eQR8= MIME-Version: 1.0 Received: by 10.142.61.33 with SMTP id j33mr5384667wfa.135.1312401865762; Wed, 03 Aug 2011 13:04:25 -0700 (PDT) Received: by 10.68.42.167 with HTTP; Wed, 3 Aug 2011 13:04:25 -0700 (PDT) In-Reply-To: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> Date: Wed, 3 Aug 2011 16:04:25 -0400 Message-ID: From: Kerry Lynn To: Zach Shelby Content-Type: multipart/alternative; boundary=001636e1f93d02e91504a99f5fbc Cc: core@ietf.org Subject: Re: [core] multicast (was: Re: Spoofing in CoAP) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:04:14 -0000 --001636e1f93d02e91504a99f5fbc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 3, 2011 at 2:40 PM, Zach Shelby wrote: > On Aug 3, 2011, at 9:31 PM, Peter Saint-Andre wrote: > > > > > > > On 8/3/11 12:04 PM, Robert Moskowitz wrote: > >> On 08/03/2011 12:38 PM, Thomas Fossati wrote: > >>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: > >>>> ESP CAN support multicast, the challenge is the keying. > >>> Right, sorry for the delayed duplicate answer. > >>> > >>>> You can create a mulitcast overlay on a set of unicast security SAs, > >>>> using the unicast security to transmit the multicast keys. This > >>>> could be a simplier implementation than adding a multicast key > >>>> distribution independent of the unicast one you need anyway. > >>> In many use cases (low-to-medium group population) this can be a good > >>> solution. SA lifetimes must be weighted against group cardinality in > >>> a sensible way, thus not saturating the medium with control traffic. > >> > >> If multicast is REALLY important to CoAP, we probably do need to look at > >> a deployable multicast security method. > > > > Good question. I think it would be helpful for the group to decide how > > important multicast is (or is not) to CoAP... > > Secure multicast is not urgent enough for us to solve as part of the > current charter IMO, however I do think it is interesting upcoming work for > CoRE, or in cooperation with the security area. Something to keep in mind > for rechartering. > > Let's remember that the beginning of this thread essentially posed the question of whether IPSec or DTLS should be the "must implement" solution. That issue can probably be explored without rechartering. -K- Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001636e1f93d02e91504a99f5fbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 3, 2011 at 2:40 PM, Zach Shelby <zach@sensinode.com> wrote:
=
On Aug 3, 2011, at 9:31 PM, Peter Saint-Andre wrote:

> <hat type=3D'individual'/>
>
> On 8/3/11 12:04 PM, Robert Moskowitz wrote:
>> On 08/03/2011 12:38 PM, Thomas Fossati wrote:
>>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
>>>> ESP CAN support multicast, the challenge is the keying. >>> Right, sorry for the delayed duplicate answer.
>>>
>>>> You can create a mulitcast overlay on a set of unicast sec= urity SAs,
>>>> using the unicast security to transmit the multicast keys.= =A0This
>>>> could be a simplier implementation than adding a multicast= key
>>>> distribution independent of the unicast one you need anywa= y.
>>> In many use cases (low-to-medium group population) this can be= a good
>>> solution. =A0SA lifetimes must be weighted against group cardi= nality in
>>> a sensible way, thus not saturating the medium with control tr= affic.
>>
>> If multicast is REALLY important to CoAP, we probably do need to l= ook at
>> a deployable multicast security method.
>
> Good question. I think it would be helpful for the group to decide how=
> important multicast is (or is not) to CoAP...

Secure multicast is not urgent enough for us to solve as part of the = current charter IMO, however I do think it is interesting upcoming work for= CoRE, or in cooperation with the security area. Something to keep in mind = for rechartering.

Let's remember that the beginning of this thread = essentially posed the question
of whether IPSec or DTLS should be= the "must implement" solution. =A0That issue
can proba= bly be explored without rechartering.

-K-

Zach

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode= .com
http://zachshelby.org =A0- My blog "On the Internet of Things"
http://6lowpan.net - M= y book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 = 40 7796297


_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core


--001636e1f93d02e91504a99f5fbc-- From d.sturek@att.net Wed Aug 3 13:04:21 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2329821F8686 for ; Wed, 3 Aug 2011 13:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTpFSDwR-IRg for ; Wed, 3 Aug 2011 13:04:17 -0700 (PDT) Received: from nm14-vm0.access.bullet.mail.sp2.yahoo.com (nm14-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.162]) by ietfa.amsl.com (Postfix) with SMTP id ACA2B21F85A7 for ; Wed, 3 Aug 2011 13:04:17 -0700 (PDT) Received: from [98.139.44.104] by nm14.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 20:04:28 -0000 Received: from [98.139.44.86] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 20:04:27 -0000 Received: from [127.0.0.1] by omp1023.access.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 20:04:27 -0000 X-Yahoo-Newman-Id: 915732.44157.bm@omp1023.access.mail.sp2.yahoo.com Received: (qmail 69339 invoked from network); 3 Aug 2011 20:04:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1312401867; bh=PBglNuaqFAuRwYALiHTCKal9/erdD7Pu0WLxYgMaBg8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=bg47ePzr+RHEXKU1qbiMNY0LakPa95dG6mpKZYPiHFzr2HdVV10Lz8zN1CeSk7J8M88zRC/M11xPpAeczy5u3XHI1lmLC4LaT6zcYKNyZJbdKAoO2zYZ4dW92zuSLe5cSJacUXmnShy3VTskWjcj2C9iEvhr8HP6c36AwikMDT4= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6D_j78YVM1nRdLtyPc7mUYqdkdHdHUpzHIRymdg43eWbStk uo4ezBQiZmA_ZMBMfOyfWSn0pU80YFDuDMmQ9AJyo_N6Oy8DKxgeEOOU7X2B ukPpIu7oOOAmUnu1BkDwDFay5B7oQsQbhAY8epzkC_AnZ0r74MjDJOZqwLUo YU4WGSkT7zAhGg6sfwwQPkOAXkItkO6E_kanCjrMRqio.F0PwLYTQKhjYGD3 qGxzdj18FxzqpHtoWRwu9s7fDArq12LSgVWkXRlXthLNnFqIM2hyDRVWKq5t Z3HsrPHZFj705HAA7nmuAgthSX3xiijh8ResLTJ_CqiFD4pa9IxBNLWQLv.P Vox3J9sRS6rRxxixrgGMRJlFvxrFBBZ8q834Ju.Ns X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.183.15.120] (d.sturek@38.126.23.254 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 03 Aug 2011 13:04:23 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 13:04:17 -0700 From: Don Sturek To: Robert Moskowitz Message-ID: Thread-Topic: [core] Spoofing in CoAP In-Reply-To: <4E39A86E.7030207@labs.htt-consult.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395221463_440467" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:04:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395221463_440467 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Provisioned in such a system means: Button press on the device, button press on the remote control, etc=8A=8A There does not need to be a sophisticated tool to do provisioning on lights and switches. Don From: Robert Moskowitz Date: Wed, 03 Aug 2011 15:58:38 -0400 To: Don Sturek Cc: Kerry Lynn , Subject: Re: [core] Spoofing in CoAP =20 On 08/03/2011 03:34 PM, Don Sturek wrote: > =20 > Hi Robert, > =20 >=20 > =20 > =20 > I did several projects with leading lighting manufacturers and, for those > projects which targeted residential and light commercial, there was no > centralized lighting controller. The switches were provisioned to direc= tly > switch on/off the groups of lights. > =20 =20 I can't see this as anything but madness and chaos. Too much decentralized smarts to group switches and lights. =20 Switches need to be dumb/cheap (unless they are multiple switches of bunches of buttons for bunches of actions). "I turn on. I turn off." Lights need to be dumb (I am on/off and tell me what to do, on/off). The cost in the controller with a UI to define groups of switches and groups of lights. =20 I know we want Grandma to be able to set this up (she is more with it than Grandpa who is too busy fishing to care about the lights). But then Grandmas tend to be as computer savy as their Granddaughters (and more than their daughters) :) =20 =20 Wait... =20 Ah, 'Provisioned'. =20 So there was a provisioning system. That controller I postulated that set up the group then stepped aside? I have seen something like this in big convention halls (like in Vegas). I CAN define a group keying environment similar to 802.1AE. But I don't know if there is the energy to write if up formally and get it through the process. =20 =20 > =20 >=20 > =20 > =20 > Don > =20 >=20 > =20 > =20 >=20 > =20 > =20 >=20 > =20 > =20 > From: Robert Moskowitz > Date: Wed, 03 Aug 2011 15:24:43 -0400 > To: Don Sturek > Cc: Kerry Lynn , > Subject: Re: [core] Spoofing in CoAP > =20 > =20 >=20 > =20 > =20 > =20 > On 08/03/2011 03:03 PM, Don Sturek wrote: >> =20 >> Hi Robert, >> =20 >>=20 >> =20 >> =20 >> Here is a typical scene lighting solution: >> =20 >>=20 >> =20 >> =20 >> 1) Multiple lamps grouped together (multicast group) >> =20 >> 2) Multiple switches (imagine a large room with switches on either end = that >> can switch on/off the grouped lamps) >> =20 >>=20 >> =20 >> =20 >> I think it would be hard to define lighting to be just single sender to = a a >> multicast group. >> =20 > =20 > But do the switches directly communicate to the lights? Not through an > energy controller? I can see a very high failure rate due to RF where so= me > lights get the signal from a switch and others do not. Or are we countin= g on > multiple IP relays to get to all the lights so the RF reachablity is > mitigated? I suppose so. It seems so chaotic to do this without a > controller. How do you define a lighting group? > =20 > Even with multiple switches (hey, my Dad is an electrician and I apprent= iced > under him and did 3-way and 4-way switch wirings), you want some intellig= ence > in their control of the lights. > =20 > Thinking about this further and wanting to 'simplify' the risk boundarie= s, I > can see a controller defining the environment but then allowing direct > communication in case the controller has been taken down. > =20 > Rapping this up, if you go with a controller model, the security is a > 'simple' single sender. If you go with the more open direct model, wait = for > us to work out the multisender model. > =20 > =20 >> =20 >>=20 >> =20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Robert Moskowitz >> Date: Wed, 03 Aug 2011 14:51:18 -0400 >> To: Kerry Lynn >> Cc: >> Subject: Re: [core] Spoofing in CoAP >> =20 >> =20 >>=20 >> =20 >> =20 >> =20 >> On 08/03/2011 02:22 PM, Kerry Lynn wrote: >>> =20 >>> On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz >>> wrote: >>> =20 >>>> =20 >>>> =20 >>>> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>>> =20 >>>>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>>>> =20 >>>>>> ESP CAN support multicast, the challenge is the keying. >>>>>> =20 >>>>> Right, sorry for the delayed duplicate answer. >>>>> =20 >>>>> =20 >>>>>> You can create a mulitcast overlay on a set of unicast security SAs= , >>>>>> using the unicast security to transmit the multicast keys. This cou= ld be >>>>>> a simplier implementation than adding a multicast key distribution >>>>>> independent of the unicast one you need anyway. >>>>>> =20 >>>>> In many use cases (low-to-medium group population) this can be a goo= d >>>>> solution. SA lifetimes must be weighted against group cardinality in= a >>>>> sensible way, thus not saturating the medium with control traffic. >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> If multicast is REALLY important to CoAP, we probably do need to look= at a >>>> deployable multicast security method. I would seriously recommend loo= king >>>> at the key heirarchy model in IEEE 802.1AE which allows for a single m= aster >>>> key managed by some entity (out of scope of 1AE and addressed in 1X) b= ut a >>>> heirarchy that allows for multiple senders. Of course as with any >>>> multicast approach you loose source authenticity to some degree. >>>> =20 >>>> I have been thinking about this for the 802.15.4f situation where the >>>> sensor has a receive radio that can be used at join time for key >>>> distribution. Otherwise a large 4f PAN would be totally unsecurable (= key >>>> scaling problems). >>>> =20 >>>> =20 >>> =20 >>> There are two main scenarios where multicast is indicated. The first >>> is for resource discovery bootstrapping (i.e. finding resource director= ies >>> =20 >>> if they exist, without a priori configuration, and discovering CoAP >>> =20 >>> servers and resources directly of RDs don't exist in the network). It'= s >>> =20 >>> not clear that these exchanges need to be secured (nobody seems >>> =20 >>> overly worried about mDNS or DNS spoofing at the moment) but I >>> =20 >>> can imagine concerns about this in some applications. >>> =20 >>>=20 >>> =20 >>> =20 >>> The second scenario is for applications that require near simultaneity >>> =20 >>> for user quality-of-experience and the oft-cited example is a single >>> =20 >>> switch controlling a floor of lighting controllers. >>> =20 >> =20 >> The switch talks to the energy controller to turn lights on/off (it was >> explained to me how BAD 'toggle' is in this usage; I chuckled at the ima= ge). >> The switch instructs the lights all at once. So there is a single direc= tion >> of multicast, from the controller to all lights in the multicast group. = This >> is an 'easy' keying problem. There is an admin process that defines the >> group, and in so doing results in the group key distribution: "These an= d >> these lights are for the shop floor and these are the lobby." >> =20 >> The real challenge comes if there are multiple senders/listeners. Perh= aps >> stress sensors on a bridge to multiple/redundant collectors. >> =20 >> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> In both cases, I suspect that just being able to assert that you're a >>> =20 >>> "member of the tribe" is sufficient authentication. >>> =20 >> =20 >> IF these apps use IP multicast (even broadcast), THEN we SHOULD provide= IP >> security. >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 > =20 > =20 > =20 > =20 =20 =20 --=20 Standard Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C: 248-219-2059 F: 248-968-2824 E: robert.moskowitz@verizonbusiness.com =20 There's no limit to what can be accomplished if it doesn't matter who get= s the credit =20 =20 --B_3395221463_440467 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Provisioned in such a system= means:

           Bu= tton press on the device, button press on the remote control, etc…R= 30;

There does not need to be a sophisticated tool = to do provisioning on lights and switches.

Don



Fr= om: Robert Moskowitz <r= gm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 15:58:38 -0400
To: Don Sturek <d.sturek@att.net&= gt;
Cc: Kerry Lynn <kerlyn2001@gmail.com>, <core@ietf.org>
Subj= ect: Re: [core] Spoofing in CoAP

On 08/03/2011 03:34 PM, Don Sturek wrote:
Hi Robert,

I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller.   Th= e switches were provisioned to directly switch on/off the groups of lights.

I can't see this as anything but madness and chaos. Too much decentralized smarts to group switches and lights.

Switches need to be dumb/cheap (unless they are multiple switches of bunches of buttons for bunches of actions).  "I turn on.  I t= urn off."  Lights need to be dumb (I am on/off and tell me what to do,= on/off).  The cost in the controller with a UI to define groups of= switches and groups of lights.

I know we want Grandma to be able to set this up (she is more with it than Grandpa who is too busy fishing to care about the lights). = ; But then Grandmas tend to be as computer savy as their Granddaughters (and more than their daughters)  :)


Wait...

Ah, 'Provisioned'.

So there was a provisioning system.  That controller I postulated that set up the group then stepped aside?  I have seen something like this in big convention halls (like in Vegas).  I  CAN de= fine a group keying environment similar to 802.1AE.  But I don't know if there is the energy to write if up formally and get it through the process.


Don



From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 15:24:43 -0400
To: Don Sturek <d.sturek@att.net>=
Cc: Kerry Lynn <kerlyn2001@gmail.com= >, <core@ie= tf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 03:03 PM, Don Sturek wrote:
Hi Robert,

Here is a typical scene lighting solution:

1)  Multiple lamps grouped together (multicast grou= p)
2)  Multiple switches (imagine a large room with switches on either end that can switch on/off the grouped lamps)

I think it would be hard to define lighting to be just single sender to a a multicast group.

But do the switches directly communicate to the lights?  N= ot through an energy controller?  I can see a very high failu= re rate due to RF where some lights get the signal from a switch and others do not.  Or are we counting on multiple = IP relays to get to all the lights so the RF reachablity is mitigated?  I suppose so.  It seems so chaotic to do = this without a controller.  How do you define a lighting group?=

Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights.

Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down.

Rapping this up, if you go with a controller model, the security is a 'simple' single sender.  If you go with the more open direct model, wait for us to work out the multisender model.




From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 14:51:18 -0400
To: Kerry Lynn <kerlyn2001@gmail.com>
Cc: <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-con= sult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against= group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriousl= y recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as with any multicast approach yo= u loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would be totally unsecurable (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the lights all at once.  So there is a single direction of multicast= , from the controller to all lights in the multicast group.  This is an 'easy' keying problem.  Th= ere is an admin process that defines the group, and in so doing results in the group key distribution:  "The= se and these lights are for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners.  Perhaps stress sensors on a bridge to multiple/redundant collectors.


In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.





--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:    = ;  248-968-2824 E:    = ;  robert.mos= kowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
 --B_3395221463_440467-- From robert.cragie@gmail.com Wed Aug 3 13:29:45 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450EB21F8A97 for ; Wed, 3 Aug 2011 13:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIPA4t9UV2Qq for ; Wed, 3 Aug 2011 13:29:44 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63521F8A95 for ; Wed, 3 Aug 2011 13:29:44 -0700 (PDT) Received: by vws12 with SMTP id 12so1031161vws.31 for ; Wed, 03 Aug 2011 13:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0SmldYFsASJlh9b4No1QMGRsQXFIzgJ1m8DiwFRsMZc=; b=uXeAIfbONuXv0o1+8Z+fOKVhg9X2cJNnNTOzqstk4QQHvdAub5bIP5mfTQkrdb7eJx iQwNctivoDN7TOILQhznqPNCVmwSV/ZZmlkdY2fIy9juaUEO3rZiJDsrzpFO9rNf6x5n yzQMQP29sq8IQ9XTuscCuv2zRuDl3ejdZUnms= MIME-Version: 1.0 Received: by 10.52.182.169 with SMTP id ef9mr3649083vdc.100.1312403396716; Wed, 03 Aug 2011 13:29:56 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.6.15 with HTTP; Wed, 3 Aug 2011 13:29:56 -0700 (PDT) In-Reply-To: <4E39A948.1070803@labs.htt-consult.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> Date: Wed, 3 Aug 2011 21:29:56 +0100 X-Google-Sender-Auth: uRkTTZ5XUmsnRp1LbCm55emRxzk Message-ID: From: Robert Cragie To: Robert Moskowitz Content-Type: multipart/alternative; boundary=bcaec548607c43679104a99fba6d Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:29:45 -0000 --bcaec548607c43679104a99fba6d Content-Type: text/plain; charset=ISO-8859-1 I +1'ed you, Bob. Unfettered access to any sort of network at L3 can cause havoc in many areas, not just unreliable UDP. There is only so much mitigation you can do there (e.g. SYN cookies, etc.). If these are multi-link subnet/NBMA type of arrangement there will be control plane issues to think about as well. My preference is for L2 hop-by-hop security with (a) key(s) given out through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall around the subnet which makes the unfettered access that much harder. Robert On Wed, Aug 3, 2011 at 9:02 PM, Robert Moskowitz wrote: > ** > On 08/03/2011 03:51 PM, Thomas Fossati wrote: > > On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote: > > Good question. I think it would be helpful for the group to decide how > important multicast is (or is not) to CoAP... > > I'm implementing the humans/things bridging technology, so I'm interested in knowing if secure multicast is in the spec only from an "opportunistic" point of view. > > That said, I believe secure multicast is a basic building block for a number of very basic stuff: from efficient firmware update on a number of same sensors, to instructing coordinated actuators, plus resource discovery, etc. > > So, for me it's a +1 both in this spec round or in the next -- but my vote may count less than one here, since I'm half a stakeholder WRT this specific requisite. > > > PS: I'm quite struck that no one (but Bob) > > > I jumped in pretty fast for many to give me a +1 vote on the layering > challenges. > > has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread. Do you all think it is so much unlikely ? It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-) > _______________________________________________ > core mailing list > core@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > -- > Robert Moskowitz > Senior Technical Advisor > Security & Standards > Verizon Business Systems > C:** **248-219-2059 > F:** **248-968-2824 > E:** **robert.moskowitz@verizonbusiness.com > > There's no limit to what can be accomplished if it doesn't matter who gets > the credit > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --bcaec548607c43679104a99fba6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I +1'ed you, Bob. Unfettered access to any sort of network at L3 can ca= use havoc in many areas, not just unreliable UDP. There is only so much mit= igation you can do there (e.g. SYN cookies, etc.). If these are multi-link = subnet/NBMA type of arrangement there will be control plane issues to think= about as well.

My preference is for L2 hop-by-hop security with (a) key(s) = given out through secure subnet access (e.g. EAPOL/PANA etc.). This puts a = wall around the subnet which makes the unfettered access that much harder.<= br>

Robert

On Wed, Aug 3,= 2011 at 9:02 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
=20 =20 =20
On 08/03/2011 03:51 PM, Thomas Fossati wrote: 
On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote:

Good question. I think it would be helpful for the group to de=
cide how
important multicast is (or is not) to CoAP...

I'm implementing the humans/things bridging technology=
, so I'm interested in knowing if secure multicast is in the spec only =
from an "opportunistic" point of view. =20

That said, I believe secure multicast is a basic building block for a numbe=
r of very basic stuff: from efficient firmware update on a number of same s=
ensors, to instructing coordinated actuators, plus resource discovery, etc.

So, for me it's a +1 both in this spec round or in the next -- but my v=
ote may count less than one here, since I'm half a stakeholder WRT this=
 specific requisite.


PS: I'm quite struck that no one (but Bob)

I jumped in pretty fast for many to give me a +1 vote on the layering challenges.

 has commented about the extremely easy spoofing issue I've =
posed at the beginning of this same thread.  Do you all think it is so much=
 unlikely ?  It'd be interesting bringing in some "spoofer" b=
ox next CoRE plug fest :-)
_______________________________________________
core mailing list

core@i=
etf.org
ht=
tps://www.ietf.org/mailman/listinfo/core

--
=20 =20 Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:=A0=A0=A0=A0=A0=A0<= u>248-219-2059
F:=A0=A0=A0=A0=A0=A0248-968-2824
E:=A0=A0=A0=A0=A0=A0robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core


--bcaec548607c43679104a99fba6d-- From rgm@labs.htt-consult.com Wed Aug 3 13:39:06 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878355E8006 for ; Wed, 3 Aug 2011 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNBxghc-NdFc for ; Wed, 3 Aug 2011 13:39:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 654B65E8001 for ; Wed, 3 Aug 2011 13:39:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9334562AA1; Wed, 3 Aug 2011 20:38:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3HxODDcLlnk; Wed, 3 Aug 2011 16:38:28 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 291C562A9C; Wed, 3 Aug 2011 16:38:28 -0400 (EDT) Message-ID: <4E39B1C3.1040901@labs.htt-consult.com> Date: Wed, 03 Aug 2011 16:38:27 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040604090908050804050908" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:39:06 -0000 This is a multi-part message in MIME format. --------------040604090908050804050908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 03:54 PM, Robert Cragie wrote: > That's essentially how it needs to work in the sort of networks CoAP > is targeted at. The multicast group addressing needs to be associated > with group keying so 'zones' can be set up; the pairing of group > addressing and group keying can act as a convenient way of being a > zone member or not. It could also help with multicast echo > suppression, although this can be difficult to configure unless the > network is completely static. There can be no assumption of a central > controller and it makes more sense to think of the multi-link subnet > model. AES-CCM (what is in your chipsets) is very intolerant of multiple packets with the same key and IV. So you must segment the IV space by sender. This is not naturally part of ESP of DTLS. For ESP you either go with a separate SA for each sender (which IS the natural model for unicast ESP) or a segmented seq # (and with only 64 bits with 32 implied this can be a problem with lots of senders). Probably be better to have a managed SA space and segment that by sender. All the 'smarts' go into managing that segmentation and the keys. > > Robert > > On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati > wrote: > > On Aug 3, 2011, at 9:34 PM, Don Sturek wrote: > > I did several projects with leading lighting manufacturers and, > for those projects which targeted residential and light > commercial, there was no centralized lighting controller. The > switches were provisioned to directly switch on/off the groups of > lights. > > In the scenario you are proposing there may be one only SA, > selected by SPI and the lamps+switches multicast address. > > Formally it fits a many-to-many model, but all the (homomorphic) > senders can be actually seen as one only entity. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------040604090908050804050908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 03:54 PM, Robert Cragie wrote:
That's essentially how it needs to work in the sort of networks CoAP is targeted at. The multicast group addressing needs to be associated with group keying so 'zones' can be set up; the pairing of group addressing and group keying can act as a convenient way of being a zone member or not. It could also help with multicast echo suppression, although this can be difficult to configure unless the network is completely static. There can be no assumption of a central controller and it makes more sense to think of the multi-link subnet model.

AES-CCM (what is in your chipsets) is very intolerant of multiple packets with the same key and IV.  So you must segment the IV space by sender.  This is not naturally part of ESP of DTLS.  For ESP you either go with a separate SA for each sender (which IS the natural model for unicast ESP) or a segmented seq # (and with only 64 bits with 32 implied this can be a problem with lots of senders).  Probably be better to have a managed SA space and segment that by sender.

All the 'smarts' go into managing that segmentation and the keys.



Robert

On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati <tho@koanlogic.com> wrote:
On Aug 3, 2011, at 9:34 PM, Don Sturek wrote:
> I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller.   The switches were provisioned to directly switch on/off the groups of lights.

In the scenario you are proposing there may be one only SA, selected by SPI and the lamps+switches multicast address.

Formally it fits a many-to-many model, but all the (homomorphic) senders can be actually seen as one only entity.
_______________________________________________


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------040604090908050804050908-- From rgm@labs.htt-consult.com Wed Aug 3 13:53:10 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3451311E807D for ; Wed, 3 Aug 2011 13:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM-m4Xar1Egj for ; Wed, 3 Aug 2011 13:53:06 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5746311E807C for ; Wed, 3 Aug 2011 13:53:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0F48862AA1; Wed, 3 Aug 2011 20:52:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMCevI-SriGo; Wed, 3 Aug 2011 16:52:42 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id B96E462A9C; Wed, 3 Aug 2011 16:52:42 -0400 (EDT) Message-ID: <4E39B51A.30901@labs.htt-consult.com> Date: Wed, 03 Aug 2011 16:52:42 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070609020601060806070006" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:53:10 -0000 This is a multi-part message in MIME format. --------------070609020601060806070006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 04:04 PM, Don Sturek wrote: > Provisioned in such a system means: > > Button press on the device, button press on the remote > control, etc...... > > There does not need to be a sophisticated tool to do provisioning on > lights and switches. So do you press the buttons on all the lights and switches within a small time window? Or if a switch connects to one light, that light instructs all the other lights? Defining a group means that somewhere is a sense of the group. Of course if all the group is a multicast address, the first system 'claims' the address and each new device learns that address as it joins. Drawing here on a napkin in front of my notebook.... Establish a unicast key between the new device and one establish device. This can even be the 15.4 keying and the bootstraping of the group occurs just above the MAC. Send the group key and 16 bit SA over this secure link. The full 32 bit SA is this value plus the 16 bit short PAN address of the device (assumed unique thanks to 6lowpan). If any device gets close to its 2^63 packets, it forces group rekeying. Or get 'smarter' and further segment the SA to include a key number so have a hierarchy of sending keys. Again, look at 802.1AE. Then you work out things like when to rekey just because. The only unicast keys in this case are the bootstrap keys and can even only be the MAC keys. Assign a 6lowpan frame ID for handling this activity. (yeah toss it back to 6lowpan!) But this is all drawing on a crumbled napkin left over from lunch. > > Don > > > > From: Robert Moskowitz > > Date: Wed, 03 Aug 2011 15:58:38 -0400 > To: Don Sturek > > Cc: Kerry Lynn >, > > > Subject: Re: [core] Spoofing in CoAP > > On 08/03/2011 03:34 PM, Don Sturek wrote: >> Hi Robert, >> >> I did several projects with leading lighting manufacturers and, for >> those projects which targeted residential and light commercial, there >> was no centralized lighting controller. The switches were >> provisioned to directly switch on/off the groups of lights. > > I can't see this as anything but madness and chaos. Too much > decentralized smarts to group switches and lights. > > Switches need to be dumb/cheap (unless they are multiple switches of > bunches of buttons for bunches of actions). "I turn on. I turn > off." Lights need to be dumb (I am on/off and tell me what to do, > on/off). The cost in the controller with a UI to define groups of > switches and groups of lights. > > I know we want Grandma to be able to set this up (she is more with it > than Grandpa who is too busy fishing to care about the lights). But > then Grandmas tend to be as computer savy as their Granddaughters (and > more than their daughters) :) > > > Wait... > > Ah, 'Provisioned'. > > So there was a provisioning system. That controller I postulated that > set up the group then stepped aside? I have seen something like this > in big convention halls (like in Vegas). I CAN define a group keying > environment similar to 802.1AE. But I don't know if there is the > energy to write if up formally and get it through the process. > >> >> Don >> >> >> >> From: Robert Moskowitz > > >> Date: Wed, 03 Aug 2011 15:24:43 -0400 >> To: Don Sturek > >> Cc: Kerry Lynn >, >> > >> Subject: Re: [core] Spoofing in CoAP >> >> On 08/03/2011 03:03 PM, Don Sturek wrote: >>> Hi Robert, >>> >>> Here is a typical scene lighting solution: >>> >>> 1) Multiple lamps grouped together (multicast group) >>> 2) Multiple switches (imagine a large room with switches on either >>> end that can switch on/off the grouped lamps) >>> >>> I think it would be hard to define lighting to be just single sender >>> to a a multicast group. >> >> But do the switches directly communicate to the lights? Not through >> an energy controller? I can see a very high failure rate due to RF >> where some lights get the signal from a switch and others do not. Or >> are we counting on multiple IP relays to get to all the lights so the >> RF reachablity is mitigated? I suppose so. It seems so chaotic to >> do this without a controller. How do you define a lighting group? >> >> Even with multiple switches (hey, my Dad is an electrician and I >> apprenticed under him and did 3-way and 4-way switch wirings), you >> want some intelligence in their control of the lights. >> >> Thinking about this further and wanting to 'simplify' the risk >> boundaries, I can see a controller defining the environment but then >> allowing direct communication in case the controller has been taken down. >> >> Rapping this up, if you go with a controller model, the security is a >> 'simple' single sender. If you go with the more open direct model, >> wait for us to work out the multisender model. >> >>> >>> >>> >>> From: Robert Moskowitz >> > >>> Date: Wed, 03 Aug 2011 14:51:18 -0400 >>> To: Kerry Lynn > >>> Cc: > >>> Subject: Re: [core] Spoofing in CoAP >>> >>> On 08/03/2011 02:22 PM, Kerry Lynn wrote: >>>> On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz >>>> > wrote: >>>> >>>> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>>> >>>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>>> >>>> ESP CAN support multicast, the challenge is the keying. >>>> >>>> Right, sorry for the delayed duplicate answer. >>>> >>>> You can create a mulitcast overlay on a set of unicast >>>> security SAs, using the unicast security to transmit >>>> the multicast keys. This could be a simplier >>>> implementation than adding a multicast key distribution >>>> independent of the unicast one you need anyway. >>>> >>>> In many use cases (low-to-medium group population) this can >>>> be a good solution. SA lifetimes must be weighted against >>>> group cardinality in a sensible way, thus not saturating >>>> the medium with control traffic. >>>> >>>> >>>> If multicast is REALLY important to CoAP, we probably do need >>>> to look at a deployable multicast security method. I would >>>> seriously recommend looking at the key heirarchy model in IEEE >>>> 802.1AE which allows for a single master key managed by some >>>> entity (out of scope of 1AE and addressed in 1X) but a >>>> heirarchy that allows for multiple senders. Of course as with >>>> any multicast approach you loose source authenticity to some >>>> degree. >>>> >>>> I have been thinking about this for the 802.15.4f situation >>>> where the sensor has a receive radio that can be used at join >>>> time for key distribution. Otherwise a large 4f PAN would be >>>> totally unsecurable (key scaling problems). >>>> >>>> There are two main scenarios where multicast is indicated. The first >>>> is for resource discovery bootstrapping (i.e. finding resource >>>> directories >>>> if they exist, without a priori configuration, and discovering CoAP >>>> servers and resources directly of RDs don't exist in the network). >>>> It's >>>> not clear that these exchanges need to be secured (nobody seems >>>> overly worried about mDNS or DNS spoofing at the moment) but I >>>> can imagine concerns about this in some applications. >>>> >>>> The second scenario is for applications that require near simultaneity >>>> for user quality-of-experience and the oft-cited example is a single >>>> switch controlling a floor of lighting controllers. >>> >>> The switch talks to the energy controller to turn lights on/off (it >>> was explained to me how BAD 'toggle' is in this usage; I chuckled at >>> the image). The switch instructs the lights all at once. So there >>> is a single direction of multicast, from the controller to all >>> lights in the multicast group. This is an 'easy' keying problem. >>> There is an admin process that defines the group, and in so doing >>> results in the group key distribution: "These and these lights are >>> for the shop floor and these are the lobby." >>> >>> The real challenge comes if there are multiple senders/listeners. >>> Perhaps stress sensors on a bridge to multiple/redundant collectors. >>> >>>> >>>> In both cases, I suspect that just being able to assert that you're a >>>> "member of the tribe" is sufficient authentication. >>> >>> IF these apps use IP multicast (even broadcast), THEN we SHOULD >>> provide IP security. >>> >>> >>> >> > > -- > Robert Moskowitz > Senior Technical Advisor > Security & Standards > Verizon Business Systems > C:248-219-2059 > F:248-968-2824 > E:robert.moskowitz@verizonbusiness.com > > There's no limit to what can be accomplished if it doesn't matter who > gets the credit -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------070609020601060806070006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 04:04 PM, Don Sturek wrote:
Provisioned in such a system means:

           Button press on the device, button press on the remote control, etc……

There does not need to be a sophisticated tool to do provisioning on lights and switches.

So do you press the buttons on all the lights and switches within a small time window?  Or if a switch connects to one light, that light instructs all the other lights?

Defining a group means that somewhere is a sense of the group.  Of course if all the group is a multicast address, the first system 'claims' the address and each new device learns that address as it joins.

Drawing here on a napkin in front of my notebook....

Establish a unicast key between the new device and one establish device.  This can even be the 15.4 keying and the bootstraping of the group occurs just above the MAC.  Send the group key and 16 bit SA over this secure link.  The full 32 bit SA is this value plus the 16 bit short PAN address of the device (assumed unique thanks to 6lowpan).  If any device gets close to its 2^63 packets, it forces group rekeying.  Or get 'smarter' and further segment the SA to include a key number so have a hierarchy of sending keys.  Again, look at 802.1AE.

Then you work out things like when to rekey just because.

The only unicast keys in this case are the bootstrap keys and can even only be the MAC keys.  Assign a 6lowpan frame ID for handling this activity. (yeah toss it back to 6lowpan!)

But this is all drawing on a crumbled napkin left over from lunch.

Don



From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 15:58:38 -0400
To: Don Sturek <d.sturek@att.net>
Cc: Kerry Lynn <kerlyn2001@gmail.com>, <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 03:34 PM, Don Sturek wrote:
Hi Robert,

I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller.   The switches were provisioned to directly switch on/off the groups of lights.

I can't see this as anything but madness and chaos. Too much decentralized smarts to group switches and lights.

Switches need to be dumb/cheap (unless they are multiple switches of bunches of buttons for bunches of actions).  "I turn on.  I turn off."  Lights need to be dumb (I am on/off and tell me what to do, on/off).  The cost in the controller with a UI to define groups of switches and groups of lights.

I know we want Grandma to be able to set this up (she is more with it than Grandpa who is too busy fishing to care about the lights).  But then Grandmas tend to be as computer savy as their Granddaughters (and more than their daughters)  :)


Wait...

Ah, 'Provisioned'.

So there was a provisioning system.  That controller I postulated that set up the group then stepped aside?  I have seen something like this in big convention halls (like in Vegas).  I  CAN define a group keying environment similar to 802.1AE.  But I don't know if there is the energy to write if up formally and get it through the process.


Don



From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 15:24:43 -0400
To: Don Sturek <d.sturek@att.net>
Cc: Kerry Lynn <kerlyn2001@gmail.com>, <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 03:03 PM, Don Sturek wrote:
Hi Robert,

Here is a typical scene lighting solution:

1)  Multiple lamps grouped together (multicast group)
2)  Multiple switches (imagine a large room with switches on either end that can switch on/off the grouped lamps)

I think it would be hard to define lighting to be just single sender to a a multicast group.

But do the switches directly communicate to the lights?  Not through an energy controller?  I can see a very high failure rate due to RF where some lights get the signal from a switch and others do not.  Or are we counting on multiple IP relays to get to all the lights so the RF reachablity is mitigated?  I suppose so.  It seems so chaotic to do this without a controller.  How do you define a lighting group?

Even with multiple switches (hey, my Dad is an electrician and I apprenticed under him and did 3-way and 4-way switch wirings), you want some intelligence in their control of the lights.

Thinking about this further and wanting to 'simplify' the risk boundaries, I can see a controller defining the environment but then allowing direct communication in case the controller has been taken down.

Rapping this up, if you go with a controller model, the security is a 'simple' single sender.  If you go with the more open direct model, wait for us to work out the multisender model.




From: Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wed, 03 Aug 2011 14:51:18 -0400
To: Kerry Lynn <kerlyn2001@gmail.com>
Cc: <core@ietf.org>
Subject: Re: [core] Spoofing in CoAP

On 08/03/2011 02:22 PM, Kerry Lynn wrote:
On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 08/03/2011 12:38 PM, Thomas Fossati wrote:
On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
ESP CAN support multicast, the challenge is the keying.
Right, sorry for the delayed duplicate answer.

You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.
In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic.

If multicast is REALLY important to CoAP, we probably do need to look at a deployable multicast security method.  I would seriously recommend looking at the key heirarchy model in IEEE 802.1AE which allows for a single master key managed by some entity (out of scope of 1AE and addressed in 1X) but a heirarchy that allows for multiple senders.  Of course as with any multicast approach you loose source authenticity to some degree.

I have been thinking about this for the 802.15.4f situation where the sensor has a receive radio that can be used at join time for key distribution.  Otherwise a large 4f PAN would be totally unsecurable (key scaling problems).

There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

The switch talks to the energy controller to turn lights on/off (it was explained to me how BAD 'toggle' is in this usage; I chuckled at the image).  The switch instructs the lights all at once.  So there is a single direction of multicast, from the controller to all lights in the multicast group.  This is an 'easy' keying problem.  There is an admin process that defines the group, and in so doing results in the group key distribution:  "These and these lights are for the shop floor and these are the lobby."

The real challenge comes if there are multiple senders/listeners.  Perhaps stress sensors on a bridge to multiple/redundant collectors.


In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP security.





--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit

--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------070609020601060806070006-- From rgm@labs.htt-consult.com Wed Aug 3 13:56:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6F211E807D for ; Wed, 3 Aug 2011 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K4cVJCDToNs for ; Wed, 3 Aug 2011 13:56:59 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id A08EB11E807C for ; Wed, 3 Aug 2011 13:56:58 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 561F362AA1; Wed, 3 Aug 2011 20:56:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hsxq8lXu038n; Wed, 3 Aug 2011 16:56:39 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id BCAA362ACB; Wed, 3 Aug 2011 16:56:30 -0400 (EDT) Message-ID: <4E39B5FE.3010304@labs.htt-consult.com> Date: Wed, 03 Aug 2011 16:56:30 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090405050301090002080602" Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:56:59 -0000 This is a multi-part message in MIME format. --------------090405050301090002080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2011 04:29 PM, Robert Cragie wrote: > I +1'ed you, Bob. Unfettered access to any sort of network at L3 can > cause havoc in many areas, not just unreliable UDP. There is only so > much mitigation you can do there (e.g. SYN cookies, etc.). If these > are multi-link subnet/NBMA type of arrangement there will be control > plane issues to think about as well. > > My preference is for L2 hop-by-hop security with (a) key(s) given out > through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall > around the subnet which makes the unfettered access that much harder. See my KMPIG over in 802.15.4. I am providing for any KMP here; I prefer HIP or even IKEv2 and shudder at EAPOL/PANA especially considering this lighting discussion! But I REQUIRE 15.4e to do this completely as a MAC function. But once defined, 6lowpan could easily allocate a frame ID to carry it as part of 6lowpan setup. Join me at Okinawa and then Atlanta. Oh I had slides for this for the saag session thrusday pm1. > > Robert > > On Wed, Aug 3, 2011 at 9:02 PM, Robert Moskowitz > > wrote: > > On 08/03/2011 03:51 PM, Thomas Fossati wrote: >> On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote: >>> Good question. I think it would be helpful for the group to decide how >>> important multicast is (or is not) to CoAP... >> I'm implementing the humans/things bridging technology, so I'm interested in knowing if secure multicast is in the spec only from an "opportunistic" point of view. >> >> That said, I believe secure multicast is a basic building block for a number of very basic stuff: from efficient firmware update on a number of same sensors, to instructing coordinated actuators, plus resource discovery, etc. >> >> So, for me it's a +1 both in this spec round or in the next -- but my vote may count less than one here, since I'm half a stakeholder WRT this specific requisite. >> >> >> PS: I'm quite struck that no one (but Bob) > > I jumped in pretty fast for many to give me a +1 vote on the > layering challenges. > >> has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread. Do you all think it is so much unlikely ? It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-) >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Robert Moskowitz > Senior Technical Advisor > Security & Standards > Verizon Business Systems > C: 248-219-2059 > F: 248-968-2824 > E: robert.moskowitz@verizonbusiness.com > > > There's no limit to what can be accomplished if it doesn't matter > who gets the credit > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------090405050301090002080602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2011 04:29 PM, Robert Cragie wrote:
I +1'ed you, Bob. Unfettered access to any sort of network at L3 can cause havoc in many areas, not just unreliable UDP. There is only so much mitigation you can do there (e.g. SYN cookies, etc.). If these are multi-link subnet/NBMA type of arrangement there will be control plane issues to think about as well.

My preference is for L2 hop-by-hop security with (a) key(s) given out through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall around the subnet which makes the unfettered access that much harder.

See my KMPIG over in 802.15.4.  I am providing for any KMP here; I prefer HIP or even IKEv2 and shudder at EAPOL/PANA especially considering this lighting discussion!

But I REQUIRE 15.4e to do this completely as a MAC function.  But once defined, 6lowpan could easily allocate a frame ID to carry it as part of 6lowpan setup.

Join me at Okinawa and then Atlanta.

Oh I had slides for this for the saag session thrusday pm1.


Robert

On Wed, Aug 3, 2011 at 9:02 PM, Robert Moskowitz <rgm@labs.htt-consult.com> wrote:
On 08/03/2011 03:51 PM, Thomas Fossati wrote: 
On Aug 3, 2011, at 8:31 PM, Peter Saint-Andre wrote:

Good question. I think it would be helpful for the group to decide how
important multicast is (or is not) to CoAP...

I'm implementing the humans/things bridging technology, so I'm interested in knowing if secure multicast is in the spec only from an "opportunistic" point of view.  

That said, I believe secure multicast is a basic building block for a number of very basic stuff: from efficient firmware update on a number of same sensors, to instructing coordinated actuators, plus resource discovery, etc.

So, for me it's a +1 both in this spec round or in the next -- but my vote may count less than one here, since I'm half a stakeholder WRT this specific requisite.


PS: I'm quite struck that no one (but Bob)

I jumped in pretty fast for many to give me a +1 vote on the layering challenges.

 has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread.  Do you all think it is so much unlikely ?  It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-)
_______________________________________________
core mailing list

core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--
Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core



--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------090405050301090002080602-- From tho@koanlogic.com Wed Aug 3 16:10:42 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74621F87C5 for ; Wed, 3 Aug 2011 16:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upAxV+7TY+LM for ; Wed, 3 Aug 2011 16:10:41 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id AC85821F87C3 for ; Wed, 3 Aug 2011 16:10:41 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:61187 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Qoka1-0001Ye-Ip; Wed, 03 Aug 2011 19:10:32 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E39A948.1070803@labs.htt-consult.com> Date: Thu, 4 Aug 2011 01:09:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap (was: multicast) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:10:42 -0000 On Aug 3, 2011, at 10:02 PM, Robert Moskowitz wrote: >> PS: I'm quite struck that no one (but Bob) >=20 > I jumped in pretty fast for many to give me a +1 vote on the layering = challenges. Perhaps I've worded my point in a misleading way. So let me recap it. What I am trying to say is that we have *very cheap* and clearly = disruptive attacks spanning the whole CoAP spec (the base protocol, = proxying, resource directories, etc.) which are all based on simple = address spoofing. Which means typically 50 lines of well indented C = code that any of us could write -- I'm sure Jari could provide an = assembly equivalent using less than 10 instructions :-) Moreover, the "MUST implement" security protocol that the spec is = proposing has 3 over 4 modes (basically all but the Certificate mode) = that are in some way vulnerable to this kind of attacks.=20 So, first of all, it'd be good if we had some text in the Security = Consideration of core-coap that acknowledges this fact, in order that = implementers/deployers are advised. And secondly (also given the very interesting discussion about which = layer / which crypto mechanism is better): are we sure that mandating = DTLS instead of IPsec is a clever idea ?= From rgm@labs.htt-consult.com Wed Aug 3 18:06:47 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D161E21F8865 for ; Wed, 3 Aug 2011 18:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA1RhiSv9FCl for ; Wed, 3 Aug 2011 18:06:47 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 384A221F8862 for ; Wed, 3 Aug 2011 18:06:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6AE7862A81; Thu, 4 Aug 2011 01:06:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb0YjPGof0b0; Wed, 3 Aug 2011 21:06:11 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 1A2F962C2A; Wed, 3 Aug 2011 21:06:08 -0400 (EDT) Message-ID: <4E39F07F.8030107@labs.htt-consult.com> Date: Wed, 03 Aug 2011 21:06:07 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> In-Reply-To: <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:06:48 -0000 On 08/03/2011 07:09 PM, Thomas Fossati wrote: > On Aug 3, 2011, at 10:02 PM, Robert Moskowitz wrote: >>> PS: I'm quite struck that no one (but Bob) >> I jumped in pretty fast for many to give me a +1 vote on the layering challenges. > Perhaps I've worded my point in a misleading way. So let me recap it. > > What I am trying to say is that we have *very cheap* and clearly disruptive attacks spanning the whole CoAP spec (the base protocol, proxying, resource directories, etc.) which are all based on simple address spoofing. Which means typically 50 lines of well indented C code that any of us could write -- I'm sure Jari could provide an assembly equivalent using less than 10 instructions :-) > > Moreover, the "MUST implement" security protocol that the spec is proposing has 3 over 4 modes (basically all but the Certificate mode) that are in some way vulnerable to this kind of attacks. > > So, first of all, it'd be good if we had some text in the Security Consideration of core-coap that acknowledges this fact, in order that implementers/deployers are advised. > > And secondly (also given the very interesting discussion about which layer / which crypto mechanism is better): are we sure that mandating DTLS instead of IPsec is a clever idea ? Those that know me know my bias to security where it belongs. And to my work on MAC and IP layers more than TCP or session. So no arguement from me. Maybe why I jumped in so fast. But I am aware of the challenges of API defining in IETF as well as the real issues found in developing the HIP API. So how DO we add a 'good' API for security? And over on the saag list, there has been a discussion just along these lines wrt tcpcrypt. For example running 2 browsers on a platform with different identities. From robert.cragie@gmail.com Wed Aug 3 22:17:44 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0095811E80E2 for ; Wed, 3 Aug 2011 22:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41nHs+rMMVsG for ; Wed, 3 Aug 2011 22:17:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 103D921F85FF for ; Wed, 3 Aug 2011 22:17:42 -0700 (PDT) Received: by vws12 with SMTP id 12so257729vws.31 for ; Wed, 03 Aug 2011 22:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=73XIJpvdGA8QPEHlMhq6jEnjVfLXDhqFq3WDu+wIEtQ=; b=fivzfxWbQd09HyS2jgvDoUVGyks2ozq4EDP155p647fYRPmreStPlt9BcZqLpuRzau gsT/ZLbJpRqiPb/X8A5Qey2V5goci2o2ZUhviWpOhd+4JTKGY1ZD/gxceJ7WfU47JCZ6 zwjZxzX3rw+jz3c0Nq2wK3TMyOofUL1s83Dcw= MIME-Version: 1.0 Received: by 10.220.213.137 with SMTP id gw9mr83894vcb.247.1312435072622; Wed, 03 Aug 2011 22:17:52 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.6.15 with HTTP; Wed, 3 Aug 2011 22:17:52 -0700 (PDT) In-Reply-To: <4E39B1C3.1040901@labs.htt-consult.com> References: <4E39B1C3.1040901@labs.htt-consult.com> Date: Thu, 4 Aug 2011 06:17:52 +0100 X-Google-Sender-Auth: QLUvYE3qYYhxKAZDdFFq8824pA4 Message-ID: From: Robert Cragie To: Robert Moskowitz Content-Type: multipart/alternative; boundary=bcaec54ee6564b5ef404a9a71a7e Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:17:44 -0000 --bcaec54ee6564b5ef404a9a71a7e Content-Type: text/plain; charset=ISO-8859-1 +1 That's the way to do it - segment the nonce/IV space by sender. This is done in 802.15.4 Robert On Wed, Aug 3, 2011 at 9:38 PM, Robert Moskowitz wrote: > ** > On 08/03/2011 03:54 PM, Robert Cragie wrote: > > That's essentially how it needs to work in the sort of networks CoAP is > targeted at. The multicast group addressing needs to be associated with > group keying so 'zones' can be set up; the pairing of group addressing and > group keying can act as a convenient way of being a zone member or not. It > could also help with multicast echo suppression, although this can be > difficult to configure unless the network is completely static. There can be > no assumption of a central controller and it makes more sense to think of > the multi-link subnet model. > > > AES-CCM (what is in your chipsets) is very intolerant of multiple packets > with the same key and IV. So you must segment the IV space by sender. This > is not naturally part of ESP of DTLS. For ESP you either go with a separate > SA for each sender (which IS the natural model for unicast ESP) or a > segmented seq # (and with only 64 bits with 32 implied this can be a problem > with lots of senders). Probably be better to have a managed SA space and > segment that by sender. > > All the 'smarts' go into managing that segmentation and the keys. > > > > > Robert > > On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati wrote: > >> On Aug 3, 2011, at 9:34 PM, Don Sturek wrote: >> > I did several projects with leading lighting manufacturers and, for >> those projects which targeted residential and light commercial, there was no >> centralized lighting controller. The switches were provisioned to directly >> switch on/off the groups of lights. >> >> In the scenario you are proposing there may be one only SA, selected by >> SPI and the lamps+switches multicast address. >> >> Formally it fits a many-to-many model, but all the (homomorphic) senders >> can be actually seen as one only entity. >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > -- > Robert Moskowitz > Senior Technical Advisor > Security & Standards > Verizon Business Systems > C:** **248-219-2059 > F:** **248-968-2824 > E:** **robert.moskowitz@verizonbusiness.com > > There's no limit to what can be accomplished if it doesn't matter who gets > the credit > --bcaec54ee6564b5ef404a9a71a7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

That's the way to do it - segment the nonce/IV sp= ace by sender. This is done in 802.15.4

Robert
=
On Wed, Aug 3, 2011 at 9:38 PM, Robert Mosko= witz <rgm@= labs.htt-consult.com> wrote:
=20 =20 =20
On 08/03/2011 03:54 PM, Robert Cragie wrote:
That's essentially how it needs to work i= n the sort of networks CoAP is targeted at. The multicast group addressing needs to be associated with group keying so 'zones' can be set up; = the pairing of group addressing and group keying can act as a convenient way of being a zone member or not. It could also help with multicast echo suppression, although this can be difficult to configure unless the network is completely static. There can be no assumption of a central controller and it makes more sense to think of the multi-link subnet model.

AES-CCM (what is in your chipsets) is very intolerant of multiple packets with the same key and IV.=A0 So you must segment the IV space by sender.=A0 This is not naturally part of ESP of DTLS.=A0 For ESP you either go with a separate SA for each sender (which IS the natural model for unicast ESP) or a segmented seq # (and with only 64 bits with 32 implied this can be a problem with lots of senders).=A0 Probably be better to have a managed SA space and segment that by sender.

All the 'smarts' go into managing that segmentation and the key= s.




Robert

On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati <tho@koanlogic.com> wrote:
On Aug 3, 2011, at 9:34 PM, Don Sturek wrote:
> I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller. =A0 The switches were provisioned to directly switch on/off the groups of lights.

In the scenario you are proposing there may be one only SA, selected by SPI and the lamps+switches multicast address.

Formally it fits a many-to-many model, but all the (homomorphic) senders can be actually seen as one only entity.
_______________________________________________


_______________________________________________
core mailing list
core@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/core

--
=20 =20 Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:=A0=A0=A0=A0=A0=A0<= u>248-219-2059
F:=A0=A0=A0=A0=A0=A0248-968-2824
E:=A0=A0=A0=A0=A0=A0robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit

--bcaec54ee6564b5ef404a9a71a7e-- From zach@sensinode.com Thu Aug 4 00:20:26 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49C11E80E8 for ; Thu, 4 Aug 2011 00:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ3CfHwOBtUW for ; Thu, 4 Aug 2011 00:20:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9900F11E80F2 for ; Thu, 4 Aug 2011 00:20:24 -0700 (PDT) Received: from [192.168.0.90] (82-128-196-163.bb.dnainternet.fi [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p747KQLa016234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 10:20:27 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-44--872220836; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> Date: Thu, 4 Aug 2011 10:20:28 +0300 Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap (was: multicast) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:20:26 -0000 --Apple-Mail-44--872220836 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Thomas, Slow responses are likely caused from IETF recovery, at least in my case = :-) Thanks Thomas, this e-mail asks exactly the right questions. On Aug 4, 2011, at 2:09 AM, Thomas Fossati wrote: > On Aug 3, 2011, at 10:02 PM, Robert Moskowitz wrote: >>> PS: I'm quite struck that no one (but Bob) >>=20 >> I jumped in pretty fast for many to give me a +1 vote on the layering = challenges. >=20 > Perhaps I've worded my point in a misleading way. So let me recap it. >=20 > What I am trying to say is that we have *very cheap* and clearly = disruptive attacks spanning the whole CoAP spec (the base protocol, = proxying, resource directories, etc.) which are all based on simple = address spoofing. Which means typically 50 lines of well indented C = code that any of us could write -- I'm sure Jari could provide an = assembly equivalent using less than 10 instructions :-) Exactly, and I assume that a similar attack is possible on most other = UDP based protocols? Do you happen to have any pointers how other IETF = UDP based protocols have dealt with this issue?=20 > Moreover, the "MUST implement" security protocol that the spec is = proposing has 3 over 4 modes (basically all but the Certificate mode) = that are in some way vulnerable to this kind of attacks.=20 The WG found consensus in Quebec to make an update to the security = specification. We are reducing our focus on pre-shared keys, and instead = concentrating on the provisioning and efficient use of public keys. = There is currently work going on to define the use of raw public keys = and hashed identities with DTLS (this can also be used by IKEv2/IPSec) = in addition to certificates. Thus we will end up with these modes: 1. NoSec 2. PreSharedKey - Reduced in importance, basically if you happen to have = pre-shared keys you can use them, but be warned of the consequences = (pointer to the attack that Thomas pointed out). 3. RawPublicKey - Currently being defined. Will include a pretty = complete provisioning discussion. 4. Certificate - As now in the spec.=20 =20 >=20 > So, first of all, it'd be good if we had some text in the Security = Consideration of core-coap that acknowledges this fact, in order that = implementers/deployers are advised. Yes, I 100% agree and will make a ticket to add a section with your = contribution. Thanks! > And secondly (also given the very interesting discussion about which = layer / which crypto mechanism is better): are we sure that mandating = DTLS instead of IPsec is a clever idea ? Let's have that discussion again. For a long time the CoAP specification described both DTLS and IPsec in = a fairly balanced way, without requiring an implementer to do one or the = other. However, we have been required to define a must implement = mechanism for the specification, and the WG chose DTLS for that purpose. = The reason is that DTLS is really the mechanism that an application = layer developer can influence, and really the only one that makes sense = to define as must implement in the CoAP specification. We also have a section on IPsec, and we should also describe how the = keying material (e.g. RawPublicKey) can be used with IPsec. But I don't = see how in the world we could define IPsec as must implement in an = application layer specification. How in the world does an application = protocol implementor using an underlying IP protocol stack or OS force = the implement of that? I definitely think we can recommend how IPsec = should be used with CoAP when it is available and appropriate for the = deployment scenario, but I don't see how we could require it as MTI in = this specification.=20 Zach =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-44--872220836 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgwNDA3MjAy OFowIwYJKoZIhvcNAQkEMRYEFLJA91il3BWbplTd+SJgm+gIwqhfMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABszlPDc5xij6y4SdCWIO7LaA9lbjXoEZZs2Y7fknhXKTGTrv5AS/czB 01JNMavGVzFgSFtnzER/7Fpj7wamDI4ofoZLXUd5hjkFrVzvLL7zVoMDJCQqU6B/ElDI6fHXidu8 leTlgvYxR6uv5hX7S2ewAY8Uk/K3zmaSFuCv8aCeGB0iNR6+6q7eP14razPEJRzvN1hSwRzbY39Q 8yJjWCrF4SZ8jeDeSWEiuKcTp0k2dQgolGmcD6zI+0vZZU4Zz9faFrmxJBEGVqw8UP9/XRoNk2Bm 1Z9/wJbAHszUC+XV8KCMSD3cw+cztRlvypTQx3LjDuGwFbW2jAoN5WJKZHUAAAAAAAA= --Apple-Mail-44--872220836-- From salvatore.loreto@ericsson.com Thu Aug 4 00:57:52 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563AF21F873D for ; Thu, 4 Aug 2011 00:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29jO0pQ7yLDA for ; Thu, 4 Aug 2011 00:57:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 54F6B21F86F6 for ; Thu, 4 Aug 2011 00:57:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-96-4e3a510ce9bc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AE.4D.20773.C015A3E4; Thu, 4 Aug 2011 09:58:04 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 4 Aug 2011 09:58:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 725D224D8 for ; Thu, 4 Aug 2011 10:58:04 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 35EDC51068 for ; Thu, 4 Aug 2011 10:58:04 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E71BC50F58 for ; Thu, 4 Aug 2011 10:58:03 +0300 (EEST) Message-ID: <4E3A510B.3060701@ericsson.com> Date: Thu, 4 Aug 2011 10:58:03 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:57:52 -0000 On 8/3/11 9:40 PM, Zach Shelby wrote: > On Aug 3, 2011, at 9:31 PM, Peter Saint-Andre wrote: > >> >> >> On 8/3/11 12:04 PM, Robert Moskowitz wrote: >>> On 08/03/2011 12:38 PM, Thomas Fossati wrote: >>>> On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote: >>>>> ESP CAN support multicast, the challenge is the keying. >>>> Right, sorry for the delayed duplicate answer. >>>> >>>>> You can create a mulitcast overlay on a set of unicast security SAs, >>>>> using the unicast security to transmit the multicast keys. This >>>>> could be a simplier implementation than adding a multicast key >>>>> distribution independent of the unicast one you need anyway. >>>> In many use cases (low-to-medium group population) this can be a good >>>> solution. SA lifetimes must be weighted against group cardinality in >>>> a sensible way, thus not saturating the medium with control traffic. >>> If multicast is REALLY important to CoAP, we probably do need to look at >>> a deployable multicast security method. >> Good question. I think it would be helpful for the group to decide how >> important multicast is (or is not) to CoAP... > Secure multicast is not urgent enough for us to solve as part of the current charter IMO, however I do think it is interesting upcoming work for CoRE, or in cooperation with the security area. Something to keep in mind for rechartering. > > Zach IMO multicast is important to CoAP, and we agree to work on it when we chartered this group /Sal -- Salvatore Loreto www.sloreto.com From tho@koanlogic.com Thu Aug 4 07:28:52 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E189B21F889D for ; Thu, 4 Aug 2011 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKoAu3EON6Fw for ; Thu, 4 Aug 2011 07:28:52 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 3C62A21F886C for ; Thu, 4 Aug 2011 07:28:51 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:64460 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Qoyut-0002fN-M0; Thu, 04 Aug 2011 10:29:03 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Thu, 4 Aug 2011 16:28:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap (was: multicast) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:28:53 -0000 On Aug 4, 2011, at 9:20 AM, Zach Shelby wrote: > On Aug 4, 2011, at 2:09 AM, Thomas Fossati wrote: >> What I am trying to say is that we have *very cheap* and clearly = disruptive attacks spanning the whole CoAP spec (the base protocol, = proxying, resource directories, etc.) which are all based on simple = address spoofing. Which means typically 50 lines of well indented C = code that any of us could write -- I'm sure Jari could provide an = assembly equivalent using less than 10 instructions :-) >=20 > Exactly, and I assume that a similar attack is possible on most other = UDP based protocols? Yes, in fact DNS people had to come up with DNSSEC to prevent cache = poisoning. =20 > Do you happen to have any pointers how other IETF UDP based protocols = have dealt with this issue?=20 Both NTP and SIP, just to mention a few going over UDP, have built-in = authentication methods. Perhaps we could add a 4.01 response code + "Authenticate" option to = triggers a challange/response auth in CoAP ? >> Moreover, the "MUST implement" security protocol that the spec is = proposing has 3 over 4 modes (basically all but the Certificate mode) = that are in some way vulnerable to this kind of attacks.=20 >=20 > The WG found consensus in Quebec to make an update to the security = specification. We are reducing our focus on pre-shared keys, and instead = concentrating on the provisioning and efficient use of public keys. = There is currently work going on to define the use of raw public keys = and hashed identities with DTLS (this can also be used by IKEv2/IPSec) = in addition to certificates. Thus we will end up with these modes: >=20 > 1. NoSec > 2. PreSharedKey - Reduced in importance, basically if you happen to = have pre-shared keys you can use them, but be warned of the consequences = (pointer to the attack that Thomas pointed out). > 3. RawPublicKey - Currently being defined. Will include a pretty = complete provisioning discussion. > 4. Certificate - As now in the spec.=20 Good. However, how are we supposed to handle raw public keys with DTLS = ? Shall we pack them into certificates on the fly ? Or are they = already supported with a format perhaps similar to PSK+identities ? {{ This is a genuine question due to ignorance, I'm unaware of TLS = support for raw pkeys :-) }} >> So, first of all, it'd be good if we had some text in the Security = Consideration of core-coap that acknowledges this fact, in order that = implementers/deployers are advised. >=20 > Yes, I 100% agree and will make a ticket to add a section with your = contribution. Thanks! Very good, thanks to you. >> And secondly (also given the very interesting discussion about which = layer / which crypto mechanism is better): are we sure that mandating = DTLS instead of IPsec is a clever idea ? >=20 > Let's have that discussion again. >=20 > For a long time the CoAP specification described both DTLS and IPsec = in a fairly balanced way, without requiring an implementer to do one or = the other. However, we have been required to define a must implement = mechanism for the specification, and the WG chose DTLS for that purpose. = The reason is that DTLS is really the mechanism that an application = layer developer can influence, and really the only one that makes sense = to define as must implement in the CoAP specification. >=20 > We also have a section on IPsec, and we should also describe how the = keying material (e.g. RawPublicKey) can be used with IPsec. But I don't = see how in the world we could define IPsec as must implement in an = application layer specification. How in the world does an application = protocol implementor using an underlying IP protocol stack or OS force = the implement of that? I definitely think we can recommend how IPsec = should be used with CoAP when it is available and appropriate for the = deployment scenario, but I don't see how we could require it as MTI in = this specification.=20 If presented this way, I could argue that even DTLS is out of scope = here. An application protocol should define its own security mechanisms = (e.g. like WWW-Authenticate in HTTP and/or SIP), and do not rely on = other layers (be it 3 or 4.5) to provide its trust primitives. Instead, = bindings can in principle be defined with security protocols at any = lower layer, if needed. By the way, applications do have ways to tinker with the IPsec SADB (see = RFC2367).= From tho@koanlogic.com Thu Aug 4 09:01:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ECD21F8BD3 for ; Thu, 4 Aug 2011 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaFCZo3jYLBr for ; Thu, 4 Aug 2011 09:01:01 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC621F8BD8 for ; Thu, 4 Aug 2011 09:00:56 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:64685 helo=[192.168.1.4]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Qp0M0-0002m0-Kx; Thu, 04 Aug 2011 12:01:08 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Thu, 4 Aug 2011 18:00:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69491ECB-31E8-404C-8F29-C9812318C665@koanlogic.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:01:02 -0000 On Aug 3, 2011, at 10:29 PM, Robert Cragie wrote: > My preference is for L2 hop-by-hop security with (a) key(s) given out = through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall = around the subnet which makes the unfettered access that much harder. L2 is ok to counteract on-path spoofing. Instead an off-path spoofer = can always use L3-provided routing to inject its garbage into the = next-hop L2 subnet. And a CoAP message can be really easy to guess, = even for a blind attacker.= From zach@sensinode.com Thu Aug 4 09:45:45 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6621F8BBA for ; Thu, 4 Aug 2011 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0UZEcp6BQkX for ; Thu, 4 Aug 2011 09:45:44 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF621F8BBB for ; Thu, 4 Aug 2011 09:45:43 -0700 (PDT) Received: from [192.168.1.102] (87-95-88-228.bb.dnainternet.fi [87.95.88.228]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p74GjU38017278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 19:45:47 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-59--852835120; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4E3A510B.3060701@ericsson.com> Date: Thu, 4 Aug 2011 15:43:33 +0300 Message-Id: <1674E07C-A2A6-42C7-A03D-D80C289D0CFE@sensinode.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E3A510B.3060701@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:45:45 -0000 --Apple-Mail-59--852835120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 4, 2011, at 10:58 AM, Salvatore Loreto wrote: >>>>>> You can create a mulitcast overlay on a set of unicast security = SAs, >>>>>> using the unicast security to transmit the multicast keys. This >>>>>> could be a simplier implementation than adding a multicast key >>>>>> distribution independent of the unicast one you need anyway. >>>>> In many use cases (low-to-medium group population) this can be a = good >>>>> solution. SA lifetimes must be weighted against group cardinality = in >>>>> a sensible way, thus not saturating the medium with control = traffic. >>>> If multicast is REALLY important to CoAP, we probably do need to = look at >>>> a deployable multicast security method. >>> Good question. I think it would be helpful for the group to decide = how >>> important multicast is (or is not) to CoAP... >> Secure multicast is not urgent enough for us to solve as part of the = current charter IMO, however I do think it is interesting upcoming work = for CoRE, or in cooperation with the security area. Something to keep in = mind for rechartering. >>=20 >> Zach > IMO multicast is important to CoAP, and we agree to work on it when we = chartered this group Multicast I agree, and we have ongoing work in the group communications = draft, the building automation draft and basic CoAP support. But *secure* multicast (and its key distribution) is a more difficult = problem. I do think it is a good idea to include some more text in the = CoAP spec on how IPsec could be used today for securing multicast using = for example the multicast overlay using unicast SAs Thomas mentions = above, and its limitations (if someone can contribute that text, that = would be great). Assuming of course there is WG consensus on that.=20 My knee-jerk reaction is that working on a *new* multicast security = solution is pretty far beyond our current charter or even the App area, = but something we should discuss in Taipei.=20 Zach =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-59--852835120 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgwNDEyNDMz NFowIwYJKoZIhvcNAQkEMRYEFEiJe4UEfKrFhBK3oFXwvUqCpkFkMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKYB26TfbJ5n1ZRAnrhe/P0DarzVXhAUGsfjBNK5Ku1v5Qt6LIcmqtnj hfE4lGxkd+LagcfynHtRmJtRm+l2tBiTJ14QEywTIQHbStS+0cRjLBJjmJihYbIO4Q82XB0wI43M TKRaT9OWFQi+/twjn6/x9NkfOTFrgyW2VkcM/Q90Gi6EzU2cfWe1cdDyZT9vIZNnZSB5WetQAG6F kJgRIgphT2e7LJrRPvM0j+QV8XnMn0EN1skrz8oYFoqOt4nngzBFE4WfshS2Rs9wKVIQPvNDSnsb Vifzdd2AunR9ZwUSxxzQSka5sXuw5leR9x8HYeexRkiRbL6Oz5YJfvNVTXYAAAAAAAA= --Apple-Mail-59--852835120-- From rgm@labs.htt-consult.com Thu Aug 4 13:34:16 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E430711E8087 for ; Thu, 4 Aug 2011 13:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5CTcd59Qvc3 for ; Thu, 4 Aug 2011 13:34:16 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D411E8077 for ; Thu, 4 Aug 2011 13:34:16 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 71CF062A6F; Thu, 4 Aug 2011 20:33:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBw-hNMDHgcg; Thu, 4 Aug 2011 16:33:41 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id D891862A6E; Thu, 4 Aug 2011 16:33:41 -0400 (EDT) Message-ID: <4E3B0225.60405@labs.htt-consult.com> Date: Thu, 04 Aug 2011 16:33:41 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: [core] IP Multicast == MAC broadcast -- Re: multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:34:17 -0000 On 08/03/2011 04:29 PM, Robert Cragie wrote: > I +1'ed you, Bob. Unfettered access to any sort of network at L3 can > cause havoc in many areas, not just unreliable UDP. There is only so > much mitigation you can do there (e.g. SYN cookies, etc.). If these > are multi-link subnet/NBMA type of arrangement there will be control > plane issues to think about as well. > > My preference is for L2 hop-by-hop security with (a) key(s) given out > through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall > around the subnet which makes the unfettered access that much harder. Something I was totally glossing over in my thoughts yesterday crytalized last night while out walking. To wit: Multicasting at IP requires Broadcasting at MAC or why bother? (much). In my discussions over the past year in IEEE 802.15 I have been looking for decent broadcasting scenarios to work out challenges of group keying in a PAN. No one I spoke to brought up this clear example we have been discussing here. There must be some mechanism for IP to 'instruct' the MAC to send a datagram out as a broadcast. As simple as the .15 MAC is we can't expect it to do data content inspection to figure this out. I will ASSuME that 6lowpan has already addressed this. We speak of multicast, but in v6-speak I might think that anycast would be used? But basically the same issues. So there needs to be a process for distributing a group key at join time, whether for MAC broadcasts or IP multicasts. The MAC group key limits traffic to all members of the PAN. Now there can be many enclaves within a PAN; in the home there could be the lighting, HVAC, and security for 3 such distinct enclaves. Thus PAN membership is good but not necessarily sufficient. This brings us back to looking at IP layered security. Now I earlier said that you need layer 3 security to protect from layer 3 attacks. However, ESP does not protect the IP addresses. They are 'malleable'; but then the idea is the SA provides the trust between the systems so there is little gained by the hacker in altering the addresses. Something to remember though. Finally we need to discuss attacks against the keying in a multi-group transmission model where a counter-based AES mode is used (eg AES CCM). Basically you cannot reuse a counter with a key. So the challenge comes in an encryptor to ALWAYS never do this. What happens if the device looses state? The easy example is power lose and reset of all operational values. Somehow this device would need to reset the WHOLE group's master key or some other device would need to tell it were it left off with its counter or some similar mechinism. This is a really challenging problem to fix, but fixed it must be. From tho@koanlogic.com Fri Aug 5 05:59:29 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D607621F8B3A for ; Fri, 5 Aug 2011 05:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbZwEy53J+B8 for ; Fri, 5 Aug 2011 05:59:29 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 511BE21F8B37 for ; Fri, 5 Aug 2011 05:59:29 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:51388 helo=[192.168.1.3]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QpK00-00042E-M2; Fri, 05 Aug 2011 08:59:43 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E3B0225.60405@labs.htt-consult.com> Date: Fri, 5 Aug 2011 14:59:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88A983DB-5E35-4264-879D-18667AB770DA@koanlogic.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <4E3B0225.60405@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] IP Multicast == MAC broadcast -- Re: multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:59:29 -0000 On Aug 4, 2011, at 10:33 PM, Robert Moskowitz wrote: > This brings us back to looking at IP layered security. Now I earlier = said that you need layer 3 security to protect from layer 3 attacks. = However, ESP does not protect the IP addresses. They are 'malleable'; = but then the idea is the SA provides the trust between the systems so = there is little gained by the hacker in altering the addresses. = Something to remember though. Correct me if I'm wrong. WRT the spoofing argument, the lesser ESP = protection scope (compared to AH) means that spoofing a replayed CoAP = response (by cut-and-paste'ing of a previous legitimate ESP+UDP+CoAP = packet) will be caught only in case the anti-replay service is in place = at the receiver. If true, than we need to highlight that ESP needs to support the = anti-replay service at least in "infrastructural" receivers such as RDs = and proxies (where the spoofing threat has the worst impact). These = boxes should be typically enough "unconstrained" to implement the = further state handling due to the receive window maintenance. From rgm@labs.htt-consult.com Fri Aug 5 06:25:26 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDAF21F8B65 for ; Fri, 5 Aug 2011 06:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQZG5bYWkokk for ; Fri, 5 Aug 2011 06:25:26 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id D819621F8B01 for ; Fri, 5 Aug 2011 06:25:25 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id AF0FD62A74; Fri, 5 Aug 2011 13:25:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axsbNju-0sIr; Fri, 5 Aug 2011 09:24:58 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 70A1762A6F; Fri, 5 Aug 2011 09:24:58 -0400 (EDT) Message-ID: <4E3BEF2A.3000601@labs.htt-consult.com> Date: Fri, 05 Aug 2011 09:24:58 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: Thomas Fossati References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <4E3B0225.60405@labs.htt-consult.com> <88A983DB-5E35-4264-879D-18667AB770DA@koanlogic.com> In-Reply-To: <88A983DB-5E35-4264-879D-18667AB770DA@koanlogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] IP Multicast == MAC broadcast -- Re: multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:25:26 -0000 On 08/05/2011 08:59 AM, Thomas Fossati wrote: > On Aug 4, 2011, at 10:33 PM, Robert Moskowitz wrote: >> This brings us back to looking at IP layered security. Now I earlier said that you need layer 3 security to protect from layer 3 attacks. However, ESP does not protect the IP addresses. They are 'malleable'; but then the idea is the SA provides the trust between the systems so there is little gained by the hacker in altering the addresses. Something to remember though. > Correct me if I'm wrong. WRT the spoofing argument, the lesser ESP protection scope (compared to AH) means that spoofing a replayed CoAP response (by cut-and-paste'ing of a previous legitimate ESP+UDP+CoAP packet) will be caught only in case the anti-replay service is in place at the receiver. > > If true, than we need to highlight that ESP needs to support the anti-replay service at least in "infrastructural" receivers such as RDs and proxies (where the spoofing threat has the worst impact). These boxes should be typically enough "unconstrained" to implement the further state handling due to the receive window maintenance. Yes. This is my view. And tracking SA/sender/seq# for replay attack addresses how to inform a re-joinee where they left off to avoid seq# reuse attack. From yoshihiro.ohba@toshiba.co.jp Fri Aug 5 07:58:32 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283EC21F8B56 for ; Fri, 5 Aug 2011 07:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-WVP-ypqsD4 for ; Fri, 5 Aug 2011 07:58:31 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14621F85AE for ; Fri, 5 Aug 2011 07:58:30 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p75EwkDO018093 for ; Fri, 5 Aug 2011 23:58:46 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p75Ewk8k004186 for core@ietf.org; Fri, 5 Aug 2011 23:58:46 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA04185; Fri, 5 Aug 2011 23:58:46 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p75Ewjui002213 for ; Fri, 5 Aug 2011 23:58:46 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p75Ewj9U016964; Fri, 5 Aug 2011 23:58:45 +0900 (JST) Received: from [133.199.16.74] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LPG000NIMXX9O80@mail.po.toshiba.co.jp> for core@ietf.org; Fri, 05 Aug 2011 23:58:45 +0900 (JST) Date: Fri, 05 Aug 2011 23:58:43 +0900 From: Yoshihiro Ohba In-reply-to: To: core@ietf.org Message-id: <4E3C0523.80401@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: Re: [core] Spoofing in CoAP recap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:58:32 -0000 I have one comment, please see below. (2011/08/04 16:20), Zach Shelby wrote: > Hi Thomas, > > Slow responses are likely caused from IETF recovery, at least in my case :-) > > Thanks Thomas, this e-mail asks exactly the right questions. > > On Aug 4, 2011, at 2:09 AM, Thomas Fossati wrote: > >> On Aug 3, 2011, at 10:02 PM, Robert Moskowitz wrote: >>>> PS: I'm quite struck that no one (but Bob) >>> >>> I jumped in pretty fast for many to give me a +1 vote on the layering challenges. >> >> Perhaps I've worded my point in a misleading way. So let me recap it. >> >> What I am trying to say is that we have *very cheap* and clearly disruptive attacks spanning the whole CoAP spec (the base protocol, proxying, resource directories, etc.) which are all based on simple address spoofing. Which means typically 50 lines of well indented C code that any of us could write -- I'm sure Jari could provide an assembly equivalent using less than 10 instructions :-) > > Exactly, and I assume that a similar attack is possible on most other UDP based protocols? Do you happen to have any pointers how other IETF UDP based protocols have dealt with this issue? > >> Moreover, the "MUST implement" security protocol that the spec is proposing has 3 over 4 modes (basically all but the Certificate mode) that are in some way vulnerable to this kind of attacks. > > The WG found consensus in Quebec to make an update to the security specification. We are reducing our focus on pre-shared keys, and instead concentrating on the provisioning and efficient use of public keys. There is currently work going on to define the use of raw public keys and hashed identities with DTLS (this can also be used by IKEv2/IPSec) in addition to certificates. Thus we will end up with these modes: > > 1. NoSec > 2. PreSharedKey - Reduced in importance, basically if you happen to have pre-shared keys you can use them, but be warned of the consequences (pointer to the attack that Thomas pointed out). > 3. RawPublicKey - Currently being defined. Will include a pretty complete provisioning discussion. > 4. Certificate - As now in the spec. If we use MultiKey, there is no spoofing issue because no PSK sharing among different clients. So I suggest to keep MultiKey option and just mention that provisioning for MultiKey is out of scope. Note that other forum such as ETSI M2M does address provisioning for MultiKey. Yoshihiro Ohba > >> >> So, first of all, it'd be good if we had some text in the Security Consideration of core-coap that acknowledges this fact, in order that implementers/deployers are advised. > > Yes, I 100% agree and will make a ticket to add a section with your contribution. Thanks! > >> And secondly (also given the very interesting discussion about which layer / which crypto mechanism is better): are we sure that mandating DTLS instead of IPsec is a clever idea ? > > Let's have that discussion again. > > For a long time the CoAP specification described both DTLS and IPsec in a fairly balanced way, without requiring an implementer to do one or the other. However, we have been required to define a must implement mechanism for the specification, and the WG chose DTLS for that purpose. The reason is that DTLS is really the mechanism that an application layer developer can influence, and really the only one that makes sense to define as must implement in the CoAP specification. > > We also have a section on IPsec, and we should also describe how the keying material (e.g. RawPublicKey) can be used with IPsec. But I don't see how in the world we could define IPsec as must implement in an application layer specification. How in the world does an application protocol implementor using an underlying IP protocol stack or OS force the implement of that? I definitely think we can recommend how IPsec should be used with CoAP when it is available and appropriate for the deployment scenario, but I don't see how we could require it as MTI in this specification. > > Zach > > >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From tho@koanlogic.com Fri Aug 5 08:20:19 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF96121F8BAE for ; Fri, 5 Aug 2011 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0iRSG9n-J+q for ; Fri, 5 Aug 2011 08:20:19 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 054CB21F8B7C for ; Fri, 5 Aug 2011 08:20:18 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:51985 helo=[192.168.1.3]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QpMCL-00048O-7V; Fri, 05 Aug 2011 11:20:35 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E3C0523.80401@toshiba.co.jp> Date: Fri, 5 Aug 2011 17:19:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> <4E3C0523.80401@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:20:19 -0000 On Aug 5, 2011, at 4:58 PM, Yoshihiro Ohba wrote: > If we use MultiKey, there is no spoofing issue because no PSK sharing > among different clients. This is true for MultiKey with 1:1 key associations, but in = circumstances with nodes/key ratio > 1 all the nodes sharing the same = PSK can spoof any other node in the group. So, in order to keep the = MultiKey mode we should slightly change its semantics to strict 1:1 PSK = per nodes' pair.= From yoshihiro.ohba@toshiba.co.jp Fri Aug 5 08:24:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE721F8B65 for ; Fri, 5 Aug 2011 08:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpqyZvfSeor2 for ; Fri, 5 Aug 2011 08:24:12 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 39F5521F8B4F for ; Fri, 5 Aug 2011 08:24:12 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p75FOTDg021674 for ; Sat, 6 Aug 2011 00:24:29 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p75FOT6Y013776 for core@ietf.org; Sat, 6 Aug 2011 00:24:29 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA13775; Sat, 6 Aug 2011 00:24:29 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p75FOTD2007236 for ; Sat, 6 Aug 2011 00:24:29 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p75FOSxI028755; Sat, 6 Aug 2011 00:24:28 +0900 (JST) Received: from [133.199.17.232] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LPG000PXO4R9N80@mail.po.toshiba.co.jp> for core@ietf.org; Sat, 06 Aug 2011 00:24:27 +0900 (JST) Date: Sat, 06 Aug 2011 00:24:26 +0900 From: Yoshihiro Ohba In-reply-to: <69491ECB-31E8-404C-8F29-C9812318C665@koanlogic.com> To: core@ietf.org Message-id: <4E3C0B2A.3020700@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <69491ECB-31E8-404C-8F29-C9812318C665@koanlogic.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:24:13 -0000 Off-path attackers will need to synch up with DTLS sequence number. It is possible to mitigate spoofing attack from off-path attackers by choosing a smaller size of DTLS sliding receive window. Yoshihiro Ohba (2011/08/05 1:00), Thomas Fossati wrote: > On Aug 3, 2011, at 10:29 PM, Robert Cragie wrote: >> My preference is for L2 hop-by-hop security with (a) key(s) given out through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall around the subnet which makes the unfettered access that much harder. > > L2 is ok to counteract on-path spoofing. Instead an off-path spoofer can always use L3-provided routing to inject its garbage into the next-hop L2 subnet. And a CoAP message can be really easy to guess, even for a blind attacker. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From yoshihiro.ohba@toshiba.co.jp Fri Aug 5 08:25:33 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AE121F8BA7 for ; Fri, 5 Aug 2011 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R26YQke0M+O for ; Fri, 5 Aug 2011 08:25:33 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A821F8B80 for ; Fri, 5 Aug 2011 08:25:32 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p75FPloC003934; Sat, 6 Aug 2011 00:25:47 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id p75FPlbG019425; Sat, 6 Aug 2011 00:25:47 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA19424; Sat, 6 Aug 2011 00:25:47 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p75FPlkb019219; Sat, 6 Aug 2011 00:25:47 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p75FPkgC027017; Sat, 6 Aug 2011 00:25:46 +0900 (JST) Received: from [133.199.17.232] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LPG000Q3O6Y9N80@mail.po.toshiba.co.jp>; Sat, 06 Aug 2011 00:25:46 +0900 (JST) Date: Sat, 06 Aug 2011 00:25:45 +0900 From: Yoshihiro Ohba In-reply-to: To: Thomas Fossati Message-id: <4E3C0B79.7070800@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> <4E3C0523.80401@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:25:33 -0000 (2011/08/06 0:19), Thomas Fossati wrote: > On Aug 5, 2011, at 4:58 PM, Yoshihiro Ohba wrote: >> If we use MultiKey, there is no spoofing issue because no PSK sharing >> among different clients. > > This is true for MultiKey with 1:1 key associations, but in circumstances with nodes/key ratio> 1 all the nodes sharing the same PSK can spoof any other node in the group. So, in order to keep the MultiKey mode we should slightly change its semantics to strict 1:1 PSK per nodes' pair. Sure. Yoshihiro Ohba From tho@koanlogic.com Fri Aug 5 08:58:20 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EDF21F8C1E for ; Fri, 5 Aug 2011 08:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeEcs8qtbCwD for ; Fri, 5 Aug 2011 08:58:20 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1B07221F8C13 for ; Fri, 5 Aug 2011 08:58:20 -0700 (PDT) Received: from host58-49-dynamic.47-79-r.retail.telecomitalia.it ([79.47.49.58]:52058 helo=[192.168.1.3]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QpMn8-0004AA-M5; Fri, 05 Aug 2011 11:58:37 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4E3C0B2A.3020700@toshiba.co.jp> Date: Fri, 5 Aug 2011 17:57:57 +0200 Content-Transfer-Encoding: 7bit Message-Id: <332DC676-381A-4002-B91E-7E0BA73D52BF@koanlogic.com> References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <69491ECB-31E8-404C-8F29-C9812318C665@koanlogic.com> <4E3C0B2A.3020700@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.49.58 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) Cc: core@ietf.org Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:58:20 -0000 On Aug 5, 2011, at 5:24 PM, Yoshihiro Ohba wrote: > Off-path attackers will need to synch up with DTLS sequence number. > It is possible to mitigate spoofing attack from off-path attackers by > choosing a smaller size of DTLS sliding receive window. A bit of ingress/egress filtering on router nodes could help too. From zach@sensinode.com Sat Aug 6 00:41:59 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F7321F884C for ; Sat, 6 Aug 2011 00:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg4r05SVKR1E for ; Sat, 6 Aug 2011 00:41:58 -0700 (PDT) Received: from smtp-68.nebula.fi (smtp.nblnetworks.fi [IPv6:2001:1bc8:100c:f220::66]) by ietfa.amsl.com (Postfix) with ESMTP id 10C2C21F87F0 for ; Sat, 6 Aug 2011 00:41:57 -0700 (PDT) Received: from webmail3.nebula.fi (webmail3.nebula.fi [83.145.246.137]) by smtp-68.nebula.fi (Postfix) with ESMTP id 1C1E543F065C; Sat, 6 Aug 2011 10:42:12 +0300 (EEST) MIME-Version: 1.0 Date: Sat, 06 Aug 2011 10:42:12 +0300 From: "zach@sensinode.com" To: Thomas Fossati In-Reply-To: References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <688AF298-5944-453B-A9DB-EDE14B2C1F27@koanlogic.com> <4E3C0523.80401@toshiba.co.jp> Message-ID: <9d10aa6f0d3aded2e5443d4a9ab2fa90@mailserver13.nebula.fi> X-Sender: zach@sensinode.com User-Agent: Nebula Webmail Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: core@ietf.org Subject: Re: [core] Spoofing in CoAP recap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 07:41:59 -0000 On Fri, 5 Aug 2011 17:19:55 +0200, Thomas Fossati wrote: > On Aug 5, 2011, at 4:58 PM, Yoshihiro Ohba wrote: >> If we use MultiKey, there is no spoofing issue because no PSK sharing >> among different clients. > > This is true for MultiKey with 1:1 key associations, but in circumstances > with nodes/key ratio > 1 all the nodes sharing the same PSK can spoof any > other node in the group. So, in order to keep the MultiKey mode we should > slightly change its semantics to strict 1:1 PSK per nodes' pair. This is exactly what I had in mind. In the next version of the draft the PreSharedKey mode would be strictly 1:1 key associations. In other words, we drop the SharedKey mode all together. Zach > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Mon Aug 8 07:47:15 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9521F8556 for ; Mon, 8 Aug 2011 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crc28MWkdAkc for ; Mon, 8 Aug 2011 07:47:15 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C721F854F for ; Mon, 8 Aug 2011 07:47:14 -0700 (PDT) Received: from client-82-26-175-170.pete.adsl.virginmedia.com ([82.26.175.170] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QqR76-0001LP-4T for core@ietf.org; Mon, 08 Aug 2011 15:47:32 +0100 Message-ID: <4E3FF752.1050406@gridmerge.com> Date: Mon, 08 Aug 2011 15:48:50 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: core@ietf.org References: <15B1A348-34BA-42BC-B112-FA84BCE64BEA@koanlogic.com> <4E37EB18.3010400@labs.htt-consult.com> <4E383751.7040907@labs.htt-consult.com> <4E398DC4.6050601@labs.htt-consult.com> <4E3993F8.7060908@stpeter.im> <4E39A948.1070803@labs.htt-consult.com> <69491ECB-31E8-404C-8F29-C9812318C665@koanlogic.com> <4E3C0B2A.3020700@toshiba.co.jp> <332DC676-381A-4002-B91E-7E0BA73D52BF@koanlogic.com> In-Reply-To: <332DC676-381A-4002-B91E-7E0BA73D52BF@koanlogic.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070304080604020805090704" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] multicast X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 14:47:15 -0000 This is a cryptographically signed message in MIME format. --------------ms070304080604020805090704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Indeed - it is unlikely a node would blindly route into a L2-protected=20 subnet. So the off-path attack model is probably not as easy as it may se= em. Robert On 05/08/2011 4:57 PM, Thomas Fossati wrote: > On Aug 5, 2011, at 5:24 PM, Yoshihiro Ohba wrote: >> Off-path attackers will need to synch up with DTLS sequence number. >> It is possible to mitigate spoofing attack from off-path attackers by >> choosing a smaller size of DTLS sliding receive window. > A bit of ingress/egress filtering on router nodes could help too. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------ms070304080604020805090704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK0DCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMYIEYDCCBFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMAkGBSsOAwIaBQCgggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTExMDgwODE0NDg1MFowIwYJKoZIhvcNAQkEMRYEFI8zdagFb6oBbX+5Cwxc P8Uliv9aMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJ KwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNV BAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1D bGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYL KoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UE BxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0 LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0G CSqGSIb3DQEBAQUABIIBABGZ3uCKzkUxTL0NuYzGZtbbvJ2KcSg3hjYPdVzdbf7UMyl8FAcB YR0qhAmsX0DWelTyEJG5jlQVNHCvnLhR9uKjKfOx8Y1YSLD7bTGZBZEUq8WFMxpM1y2uGLS3 19Wbpp1lu4AcXj7KeDgiy8lrjHPc74/tia+EVBzVKCS/pG7wet8mttj9CcR80kmp55w4Jtv9 DWuvTSTTPv2B9/so9Nw1XutFpYsc+gzSrDO9+HPWjCgtcCl3J/XwcuZFgLMAk0S4jaDbeqha EUHlCPjAUCj5uOYdGNTIhxOIVHBIry5a5qadFDRBUhoJBqhnmM7AUJKHOTQ4xty9S8+6WrQI AiQAAAAAAAA= --------------ms070304080604020805090704-- From likepeng@huawei.com Thu Aug 18 20:07:06 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BFE21F8686 for ; Thu, 18 Aug 2011 20:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlPoS81-EvRc for ; Thu, 18 Aug 2011 20:07:05 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5221F85B9 for ; Thu, 18 Aug 2011 20:07:05 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ500MDQNAIC8@szxga05-in.huawei.com> for core@ietf.org; Fri, 19 Aug 2011 11:06:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ5003YFNAIR5@szxga05-in.huawei.com> for core@ietf.org; Fri, 19 Aug 2011 11:06:18 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG11955; Fri, 19 Aug 2011 11:06:17 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 11:06:05 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.40]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 11:06:16 +0800 Date: Fri, 19 Aug 2011 03:06:16 +0000 From: Likepeng X-Originating-IP: [10.70.109.110] To: core WG Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2CA21D0@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CoAP] About Location-Query Thread-index: AcxeHPPWWplJDsQ6QtiFsbhtmMA68A== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AVMm AasT B6sY CqRY DIi3 DSpR D1yz EeKP E5ud FFOw FkJO GMtE GXPo ICaI KKVm KYVy; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {CA66B466-CC40-4BE2-9596-B73EFD63933E}; bABpAGsAZQBwAGUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 19 Aug 2011 03:06:13 GMT; WwBDAG8AQQBQAF0AIABBAGIAbwB1AHQAIABMAG8AYwBhAHQAaQBvAG4ALQBRAHUAZQByAHkA x-cr-puzzleid: {CA66B466-CC40-4BE2-9596-B73EFD63933E} X-CFilter-Loop: Reflected Subject: [core] [CoAP] About Location-Query X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 03:07:06 -0000 Hi Klaus, Zach, and all I have a question about Location-Query in CoAP-07. What is the use case for the Location-Query? From the description, it is mainly used in Post response to indicate the location of the new created resource. In this case, there should be a determined location, why should we use query conditions? Location-Path is enough. Another question is ,why can't we reuse URI-Path and URI-Query in this case, instead of using new options? When I check the change history, Location-Query was added in CoAP-05 based on ticket #113. Ticket #113 was from Klaus and it says: coap-04 inadvertently removed the ability of a server to specify a query string in the Location Option. This can be remedied by defining a new Location-Query Option. But I checked CoAP-03 and the previous versions, there are no Location-Query before. So I am curious about the motivation to have this option. Can anybody tell me the reason? Thanks, Kind Regards Kepeng From vincengay@gmail.com Tue Aug 23 07:48:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B106821F8B06 for ; Tue, 23 Aug 2011 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmuF8TfQZctC for ; Tue, 23 Aug 2011 07:48:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68F8421F8ADC for ; Tue, 23 Aug 2011 07:48:12 -0700 (PDT) Received: by wyg8 with SMTP id 8so161379wyg.31 for ; Tue, 23 Aug 2011 07:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=WxbevVsAIEwH5RC3hWQmDZ5IH64iEFUtcMI8Kemlo9M=; b=Rgn9eimxIiX1cddzKz1fu8i9G+wGvlOKL/JKrMiH8pGJUKYQo+FuYNuMbZkI8fXwg+ D/GypW0hJmT/jmNCp9TmXnzL5pU1B10YcddApzPEXHjcXVkb9mzCI6y6x+XUyYIp6dYI 2XgWtCPVlAFGkBvQgvcwGVw3M6fvzkXFxazZM= Received: by 10.216.233.7 with SMTP id o7mr3580511weq.7.1314110959762; Tue, 23 Aug 2011 07:49:19 -0700 (PDT) Received: from [192.168.20.39] (thalescom-48-34.cnt.nerim.net [213.215.48.34]) by mx.google.com with ESMTPS id y61sm36960wec.6.2011.08.23.07.49.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 07:49:19 -0700 (PDT) From: Vincent Gay Content-Type: multipart/alternative; boundary="Apple-Mail=_9DDF6563-5FFF-4121-A85C-63CF760D297C" Date: Tue, 23 Aug 2011 16:49:17 +0200 Message-Id: To: core@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [core] Open-source implementations of HTTC/CoAP mapping proxy? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 14:54:07 -0000 --Apple-Mail=_9DDF6563-5FFF-4121-A85C-63CF760D297C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, can someone indicate me what are the available open-source = implementations of HTTC/CoAP mapping proxy? When googling, I have found: - a Squid-based implementation developed by Angelo Castellani from Univ. = of Padova = https://telecom.dei.unipd.it/tlcrepos/castellani/iot/coap-proxy=20 - Californium, developed within ETH Z=FCrich, that announce the support = of "CoAP proxy". Also available from ETHZ, the Copper Firefox plugin for = supporting the CoAP scheme right in the web browser. Any other pointers to share? Thanks -Vincent= --Apple-Mail=_9DDF6563-5FFF-4121-A85C-63CF760D297C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 h= ttps://telecom.dei.unipd.it/tlcrepos/castellani/iot/coap-proxy<= span class=3D"Apple-style-span" style=3D"font-family: Times; = background-color: rgb(255, 255, 255); "> 
- Californium, = developed within ETH Z=FCrich, that announce the support of "CoAP = proxy". Also available from ETHZ, the Copper Firefox plugin for = supporting the CoAP scheme right in the web = browser.

Any other pointers to = share?

Thanks
-Vincent
= --Apple-Mail=_9DDF6563-5FFF-4121-A85C-63CF760D297C-- From prvs=721736C4B2=guido.moritz@uni-rostock.de Wed Aug 24 00:35:18 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17D21F8B33 for ; Wed, 24 Aug 2011 00:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrrVTMIiQys8 for ; Wed, 24 Aug 2011 00:35:17 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id B5B5121F8B2F for ; Wed, 24 Aug 2011 00:35:16 -0700 (PDT) From: Guido Moritz To: 'Vincent Gay' , References: In-Reply-To: Date: Wed, 24 Aug 2011 09:37:20 +0200 Message-ID: <007b01cc6230$a8461820$f8d24860$@uni-rostock.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CC6241.6BCFD280" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJh3o3u1wjo8hs/SQpEWGNreTFo1pQAo1Zw Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Open-source implementations of HTTC/CoAP mapping proxy? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 07:35:18 -0000 ------=_NextPart_000_007C_01CC6241.6BCFD280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is also a CoAP stack (without CoAP/HTTP proxy) in Java from the = WS4D folks: http://ws4d.e-technik.uni-rostock.de/2011/announcing-ws4d-jcoap/=20 =20 Best, Guido =20 Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Vincent Gay Gesendet: Dienstag, 23. August 2011 16:49 An: core@ietf.org Betreff: [core] Open-source implementations of HTTC/CoAP mapping proxy? =20 Hi, =20 can someone indicate me what are the available open-source = implementations of HTTC/CoAP mapping proxy? =20 When googling, I have found: - a Squid-based implementation developed by Angelo Castellani from Univ. = of Padova https://telecom.dei.unipd.it/tlcrepos/castellani/iot/coap-proxy=20 - Californium, developed within ETH Z=FCrich, that announce the support = of "CoAP proxy". Also available from ETHZ, the Copper Firefox plugin for supporting the CoAP scheme right in the web browser. =20 Any other pointers to share? =20 Thanks -Vincent ------=_NextPart_000_007C_01CC6241.6BCFD280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There is also a CoAP stack (without CoAP/HTTP proxy) in Java from the = WS4D folks: http://ws4d.e-technik.uni-rostock.de/2011/announcing-ws4d-jcoap/ =

 

Best,

Guido

 

Von:<= /b> = core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von = Vincent Gay
Gesendet: Dienstag, 23. August 2011 = 16:49
An: core@ietf.org
Betreff: [core] Open-source = implementations of HTTC/CoAP mapping = proxy?

 

Hi,

 

can someone indicate me what are the available = open-source implementations of HTTC/CoAP mapping = proxy?

 

When googling, I have = found:

- a Squid-based = implementation developed by Angelo Castellani from Univ. of = Padova = https://telecom.dei.unipd.it/tlcrepos/castellani/iot/coap-proxy =

- Californium, developed within ETH Z=FCrich, that announce the support = of "CoAP proxy". Also available from ETHZ, the Copper Firefox = plugin for supporting the CoAP scheme right in the web = browser.

 

Any other pointers to = share?

 

Thanks

-Vincent

------=_NextPart_000_007C_01CC6241.6BCFD280--