Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)

Alan DeKok <aland@deployingradius.com> Tue, 14 December 2010 20:14 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 DB94D28C110; Tue, 14 Dec 2010 12:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level:
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 s4+WbxdKpW6O; Tue, 14 Dec 2010 12:14:37 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E6AC528C104; Tue, 14 Dec 2010 12:14:36 -0800 (PST)
Message-ID: <4D07D090.9020407@deployingradius.com>
Date: Tue, 14 Dec 2010 21:16:16 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: robert.cragie@gridmerge.com
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com>
In-Reply-To: <4D07A874.4010702@gridmerge.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 'Yoshihiro Ohba' <yoshihiro.ohba@toshiba.co.jp>, 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, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [secdir] Token (was RE: 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: Tue, 14 Dec 2010 20:14:38 -0000

Robert Cragie wrote:
>     * I agree with the notion of enforcing the relay to only process
>       valid PANA messages and only send valid PANA messages. The fact it
>       is a functionally-defined relay (as opposed to a generic IP
>       tunnel) means that we can do this. Therefore we need to add text
>       as you suggest.

  Thanks.

>     * I am less sure of the need for a token. As far as I can see, the
>       token would only protect the immutable information in the data
>       sent from PRE to PAA, i.e. the IP address and the port. This has
>       some benefit but would not necessarily prevent a rogue PAA sending
>       a bogus encapsulated frame.

  It would *authenticate* the data sent from the PAA to the PRE.  This
authentication would ensure that the PAA could only respond to packets
sent by the PRE.

  As I said earlier, this would ensure that a rogue PAA can only (a)
send PANA messages, to (b) the IP of the PaC, and (c) the port of the
PaC used to send PANA messages.  It would prevent a rogue PAA from
sending a non-PANA frame to arbitrary non-PANA IPs and ports.

>  Using DTLS between PRE and PAA would
>       provide protection for the whole packet, possibly including
>       encryption.

   It's not per-packet protection.  It's that the PRE will only accept
frames from the PAA that have been authenticated via TLS.

> Using a PANA SA would provide better protection than a
>       PRE-originated token. Using L2 security also provides a 'walled
>       garden' protection. It seems to me possible for a rogue node to
>       send any packet to any port on a node which is accessible at the
>       link layer provided one knows its address and assumes no L2
>       security therefore I don't again see this as an additional threat

  The document clearly states that the PRE is proxying packets because
the PAA can not otherwise route traffic to the PaC.  Security between
the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE
to route traffic to the PaC.

  One view could be that the PaC is already vulnerable to rogue PAAs on
the local network.  That local network may, however, be limited in the
number of systems, and what they're allowed to do.  My presumption is
that the PRE to PAA network is a fully-connected network capable of
routing to arbitrary destinations.

  So adding a PRE opens the PaC to attacks from arbitrary sources on a
wide-area network, which would seem to be a violation of the PANA
assumptions.

  Alan DeKok.