Re: [secdir] Secdir review of draft-ohba-pana-relay

Alan DeKok <aland@deployingradius.com> Fri, 10 December 2010 08:40 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD903A6C83; Fri, 10 Dec 2010 00:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efxo+RoLGCvi; Fri, 10 Dec 2010 00:40:02 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 673DE3A6C82; Fri, 10 Dec 2010 00:40:02 -0800 (PST)
Message-ID: <4D01E7BB.50605@deployingradius.com>
Date: Fri, 10 Dec 2010 09:41:31 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp>
In-Reply-To: <4D01DABF.6060604@toshiba.co.jp>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, 'Alper Yegin' <alper.yegin@yegin.org>, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [secdir] Secdir review of draft-ohba-pana-relay
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 08:40:04 -0000

Yoshihiro Ohba wrote:
> Relaying happens only one time for each message belonging to the same
> PANA session.  We can clarify this in the draft.

  Yes.  The draft does not forbid a message passing through multiple relays.

> I agree that some message validity check at the PRE can help address
> issues you mentioned above.  In my analysis: (1) Some check requires
> the PRE to be stateful (e.g., sequence number check on relayed PANA
> message requires the PRE to keep track of sequence numbers for each
> session), (2) some check does not require the PRE to be stateful
> (e.g., message length check), and (3) some check is impossible unless
> security is compromised (e.g., AUTH AVP check of relayed PANA message
> using the PANA SA between the PaC and the PAA).  Let's discuss (1) and
> (2).   There are several design choices here:
> 
> (a) (1) and (2) are mandatory
> (b) (1) is optional, (2) is mandatory
> (c) (1) and (2) are optional
> 
> I listed these choices because ZigBee has chosen pana-relay mainly
> because of the stateless nature of PRE in its current design and I
> think that making PRE stateful can be a too strong requirement for ZigBee.

  A cryptographic token can help with this.  The token can contain
information about the sequence number, signed by a secret known only to
the PRE.

> To address Margaret's security comment, we (co-authors) are currently
> discussing whether we can recommend use of DTLS to protect PRY message
> between PRE and PAA for less-trusted environment.  Your suggested
> token-based approaches (PRE-generated and PaC-generated tokens) can be
> another recommendation for similar environment.  I think we need to
> consider tradeoff between the level of improvement in security and the
> required cost for each alternative.

  Yes.  Adding a token is simple, and requires minimal changes to the
PAA (echo the token), and some small work on the PRE (generate / verify
the token).

  In contrast, DTLS takes much more work.

  Alan DeKok.