Re: [6tisch] [6tisch-security] proposed security text for architecture draft
<yoshihiro.ohba@toshiba.co.jp> Fri, 14 November 2014 20:00 UTC
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFBF1A9043; Fri, 14 Nov 2014 12:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no0Tptt3RiGg; Fri, 14 Nov 2014 12:00:02 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07431A9099; Fri, 14 Nov 2014 12:00:00 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAEJxt6h026879; Sat, 15 Nov 2014 04:59:55 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id sAEJxt2j018461; Sat, 15 Nov 2014 04:59:55 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id EAA18460; Sat, 15 Nov 2014 04:59:55 +0900
Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAEJxssO004998; Sat, 15 Nov 2014 04:59:55 +0900 (JST)
Received: from TGXML207.toshiba.local by toshiba.co.jp id sAEJxsFH024357; Sat, 15 Nov 2014 04:59:54 +0900 (JST)
Received: from TGXML210.toshiba.local ([169.254.4.194]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 04:59:54 +0900
From: yoshihiro.ohba@toshiba.co.jp
To: pthubert@cisco.com
Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft
Thread-Index: AQHP/9Hsmv4jLXPqmkGCw6POgAr77Jxf0IxwgACgdYWAABePkA==
Date: Fri, 14 Nov 2014 19:59:54 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@TGXML210.toshiba.local>
References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com>
In-Reply-To: <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.199.16.234]
msscp.transfermailtomossagent: 103
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/OMZnqSEi7VtbLYHRknP3xlo9nVQ
Cc: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org
Subject: Re: [6tisch] [6tisch-security] proposed security text for architecture draft
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 20:00:07 -0000
Hi Pascal, Can you please explain a use case where a JA has multiple LLN interfaces as I could find it in draft-ietf-6tisch-architecture? If multiple LLN interfaces need to be supported, then I agree that link-local address solely does not work for a JN to communicate with a JCE via a JA using a relay or a RH or whatsoever. Yoshihiro Ohba -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Saturday, November 15, 2014 3:25 AM To: ohba yoshihiro(´óö ÁxÑó ¡ð£Ò£Ä£Ã¡õ£Î£Ó£Ì) Cc: mcr+ietf@sandelman.ca; 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft Hello Yoshi: Please see below and many thanks for all this Pascal > Le 13 nov. 2014 ¨¤ 23:50, "yoshihiro.ohba@toshiba.co.jp" <yoshihiro.ohba@toshiba.co.jp> a ¨¦crit : > > Here is main PANA use: > > 1. Creating a PANA SA (based on EAP MSK) between JCE and JN where JCE is PAA, JN is PaC, and JA is PANA relay. > (PANA relay is a stateless relay as described in RFC 6345, and no need > for loose source routing or ULA allocation.) On this I respectfully disagree. The IP address of the PaC is not sufficient information to identify the join bundle should there be more than one. This is why RH usually carries ULA or global addresses, with the intention that the prefix indicates the next interface - to your earlier point. But then in a ML subnetwork this is no help whatsoever since multiple interfaces may be on a same subnet. This is where the ULA comes into play; hiding the network ID from untrusted lurkers and yet providing an unequivocal bundle ID. Makes sense? Pascal > > 2. Using the SA to securely distribute locally significant credentials > such as a 802.11AR LDevID certificate or a network-wide shared > symmetric key, and I am not in favor of the latter though :) > > For 1), existing RADIUS servers can be used if EAP server is a physically separated from PCE box where scalability is needed. EAP-based approach can also support roaming cases where electric vehicles are authenticated via smart meters. > > For 2) we can define new PANA attributes to carry RFC 4210 CertRequest and CertResponse defined by PKIX for distributing 802.11AR LDevID certificate. > > I did not think to use PANA to carry CoAP messages. I think DTLS should be used for protecting CoAP for 6top as being discussed. The DTLS session for CoAP can be established, e.g., by using the locally significant credentials distributed in 2). > > Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would make 6tisch more attractive to cover certain business scenarios. > > Please note that I do not disagree with DTLS-based approach for more resource constrained device (although more work seems to be needed to carry DTLS message between JCE and JN via JA), but we should support multiple options if one solution is difficult to cover all cases. > > Best Regards, > Yoshihiro Ohba > > > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: Friday, November 14, 2014 3:12 PM > To: ohba yoshihiro(´óö ÁxÑó ¡ð£Ò£Ä£Ã¡õ£Î£Ó£Ì) > Cc: 6tisch@ietf.org; 6tisch-security@ietf.org > Subject: Re: [6tisch-security] [6tisch] proposed security text for > architecture draft > > > <yoshihiro.ohba@toshiba.co.jp> wrote: >> Use of EAP-TLS and terminating TLS session at AAA server does not >> mean that all parameters have to be coming from AAA server. >> Especially when PANA is used, PAA can be co-located with JCE and >> provide 6top data over a secure PANA SA. Actually this model applies to any EAP method. > > So, we would be creating a masterkey with EAP-TLS, and then we would use PANA as a transport for CoAP? > > I understand why we want to use EAP when we have devices with humans > at the far end; > 1) it means the pieces in the middle do not need to know anything about the > kind of authentication will be done > > 2) we can deploy new forms of authentication (such as challenge response > methods, and things like EAP-SIM or EAP-AKA) without changes to the middle > machines. > > 3) we can proxy things all the way back to the users home service, which is > how GSM roaming works these days. > > I'm unaware that industrial/deterministic uses of 15.4 have requirements for ths kind of thing. I seem to recall a conversation about whether or not including a SIM card into nodes would work from a power, size, and cost point of view. Having a replaceable SIM card would definitely be a really easy way to imprint new devices. If someone can do that, then we really don't need any of this... > > -- > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security
- [6tisch] proposed security text for architecture … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Pascal Thubert (pthubert)
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Rene Struik
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Subir Das
- Re: [6tisch] [6tisch-security] proposed security … Pascal Thubert (pthubert)
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- [6tisch] (procedural) Re: [6tisch-security] propo… Rene Struik
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Pascal Thubert (pthubert)
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Pascal Thubert (pthubert)
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Rafa Marin Lopez
- Re: [6tisch] [6tisch-security] proposed security … Subir Das
- Re: [6tisch] [6tisch-security] proposed security … Pascal Thubert (pthubert)
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Rafa Marin Lopez
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … Michael Richardson
- Re: [6tisch] [6tisch-security] proposed security … yoshihiro.ohba