Re: [6tisch] [6tisch-security] proposed security text for architecture draft

Rafa Marin Lopez <rafa@um.es> Mon, 17 November 2014 09:27 UTC

Return-Path: <rafa@um.es>
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 ED2221A1A43; Mon, 17 Nov 2014 01:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.195
X-Spam-Level:
X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, SPF_PASS=-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 ON5k-kmOqZVD; Mon, 17 Nov 2014 01:27:42 -0800 (PST)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 84D3D1A1A42; Mon, 17 Nov 2014 01:27:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 56C4848E7B; Mon, 17 Nov 2014 10:27:37 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id skl6MqfezCA4; Mon, 17 Nov 2014 10:27:37 +0100 (CET)
Received: from inf-205-157.inf.um.es (inf-205-157.inf.um.es [155.54.205.157]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 9549F48C12; Mon, 17 Nov 2014 10:27:32 +0100 (CET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local>
Date: Mon, 17 Nov 2014 10:27:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <62FBEB5B-56E2-438A-968C-0C014D81F720@um.es>
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> <C75D9F2A-664D-4245-8977-08B3BAD14AAA@um.es> <8156.1416111189@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local>
To: yoshihiro.ohba@toshiba.co.jp
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/bkcu08vr3FB4HQrplflLAoTSIA8
Cc: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org, Rafa Marin Lopez <rafa@um.es>
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: Mon, 17 Nov 2014 09:27:45 -0000

Regarding issuing a certificate, we have discussed internally here at UMU that the PAA could certify a public key, which is sent by the PaC/JN through the PANA SA built after a successful PANA authentication  (e.g. a PNR/PNA exchange could be used for that). In this sense, there is no need for a global CA.

Best Regards.

El 17/11/2014, a las 00:36, yoshihiro.ohba@toshiba.co.jp escribió:

> An issued certificate in a CertResponse is signed by a CA trusted by JN, and the CertResponse is protected by the PANA SA.
> 
> The PANA SA is derived from an EAP MSK which is established between EAP peer and EAP server and is transported by EAP server to authenticator, and therefore the PANA SA is attached to the EAP method security.
> 
> Yoshihiro Ohba
> 
> 
> -----Original Message-----
> From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: Sunday, November 16, 2014 1:13 PM
> To: 6tisch@ietf.org; 6tisch-security@ietf.org
> Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft
> 
> 
>> For 2) we can define new PANA attributes to carry RFC 4210 CertRequest
>> and CertResponse defined by PKIX for distributing 802.11AR LDevID
>> certificate.
> 
> The EAP-TLS security is between joining node (supplicant) and radius/diameter server (authentication server).  
> 
> The PANA is between the authenticator and the joining node (supplicant). 
> The PANA has no security attached.   
> 
> How can the supplicant know that the CertResponse it is getting is legitimate?
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
> 	
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------