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

Alan DeKok <> Fri, 10 December 2010 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDD903A6C83; Fri, 10 Dec 2010 00:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.572
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id efxo+RoLGCvi; Fri, 10 Dec 2010 00:40:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 673DE3A6C82; Fri, 10 Dec 2010 00:40:02 -0800 (PST)
Message-ID: <>
Date: Fri, 10 Dec 2010 09:41:31 +0100
From: Alan DeKok <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Yoshihiro Ohba <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc:,, 'Alper Yegin' <>,,,,,, Ralph Droms <>
Subject: Re: [secdir] Secdir review of draft-ohba-pana-relay
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.