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

<yoshihiro.ohba@toshiba.co.jp> Sun, 16 November 2014 23:37 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 D11911A1C00; Sun, 16 Nov 2014 15:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.286
X-Spam-Level:
X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, 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 p98dSrRDVZMq; Sun, 16 Nov 2014 15:36:58 -0800 (PST)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACEE1A00F0; Sun, 16 Nov 2014 15:36:57 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sAGNatTe009652; Mon, 17 Nov 2014 08:36:55 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id sAGNatnj020161; Mon, 17 Nov 2014 08:36:55 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA20156; Mon, 17 Nov 2014 08:36:55 +0900
Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sAGNatmu026760; Mon, 17 Nov 2014 08:36:55 +0900 (JST)
Received: from TGXML207.toshiba.local by toshiba.co.jp id sAGNasVY004475; Mon, 17 Nov 2014 08:36:54 +0900 (JST)
Received: from TGXML210.toshiba.local ([169.254.4.146]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 08:36:54 +0900
From: yoshihiro.ohba@toshiba.co.jp
To: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org
Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft
Thread-Index: AQHQAVMgkoi1cepLG0+Y55kDTOfXCZxj5X1A
Date: Sun, 16 Nov 2014 23:36:54 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272B3300@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> <C75D9F2A-664D-4245-8977-08B3BAD14AAA@um.es> <8156.1416111189@sandelman.ca>
In-Reply-To: <8156.1416111189@sandelman.ca>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.196.20.218]
msscp.transfermailtomossagent: 103
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/fpe6NmlAR6iZed6rrGRvxKK45Rw
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: Sun, 16 Nov 2014 23:37:01 -0000

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    [