Re: [secdir] pana-relay security considerations

Alan DeKok <aland@deployingradius.com> Mon, 10 January 2011 11:00 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 B6EE83A6AF7; Mon, 10 Jan 2011 03:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.289
X-Spam-Level:
X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 6oCqa1jIfV+h; Mon, 10 Jan 2011 03:00:31 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id DA0233A6953; Mon, 10 Jan 2011 03:00:30 -0800 (PST)
Message-ID: <4D2AE752.2000504@deployingradius.com>
Date: Mon, 10 Jan 2011 12:02:42 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <070601cba3ad$63852150$2a8f63f0$@yegin@yegin.org> <4D270D1D.8090006@deployingradius.com> <005f01cbb0b2$2bc21cc0$83465640$@yegin@yegin.org>
In-Reply-To: <005f01cbb0b2$2bc21cc0$83465640$@yegin@yegin.org>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org, paduffy@cisco.com, margaretw42@gmail.com, pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [secdir] pana-relay security considerations
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: Mon, 10 Jan 2011 11:00:31 -0000

Alper Yegin wrote:
> The PaC picks an ephemeral port when sending the PANA packet. Src:any, dst:
> 716. And the response from the PAA reverses the ports. 

  OK.

> The most PRE can do is to check if source port is 716.
> 
> If the PRE knows that it received the packet from a trusted source (by means
> of DTLS, physical security, IPsec, etc.), then the PRE should not
> normally(*) have to perform another level of check on the packets. 

  And if not?  Anyone can pretend to be the PAA, and send any data to
any port on the PaC.  If this data MUST be a well-formed PANA packet,
the security issues are minimal.  But I don't see that requirement
clearly in the document.

  Alan DeKok.