Re: [Pana] Security Comment: draft-ohba-pana-relay-02.txt

"Samita Chakrabarti" <samitac@ipinfusion.com> Mon, 29 November 2010 23:20 UTC

Return-Path: <samitac@ipinfusion.com>
X-Original-To: pana@core3.amsl.com
Delivered-To: pana@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B133A6C42 for <pana@core3.amsl.com>; Mon, 29 Nov 2010 15:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 QnbT5VAiN7j0 for <pana@core3.amsl.com>; Mon, 29 Nov 2010 15:20:53 -0800 (PST)
Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by core3.amsl.com (Postfix) with SMTP id 9624628C17D for <pana@ietf.org>; Mon, 29 Nov 2010 15:20:48 -0800 (PST)
Received: from [98.139.91.66] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2010 23:21:56 -0000
Received: from [98.139.91.17] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 29 Nov 2010 23:21:56 -0000
Received: from [127.0.0.1] by omp1017.mail.sp2.yahoo.com with NNFMP; 29 Nov 2010 23:21:56 -0000
X-Yahoo-Newman-Id: 707334.93517.bm@omp1017.mail.sp2.yahoo.com
Received: (qmail 64124 invoked from network); 29 Nov 2010 23:21:56 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 29 Nov 2010 15:21:55 -0800 PST
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: OZa9gc0VM1nBmsDt3Q5uSd0qbrK8Ciar4cSBwHrQ0pMSCfQ iBmlCBKjJfohhsA5w1ts2hcxQbpKaZdO0U0gXi.A5xTq4VPKNBNIxPyJtSO0 lRqanDdQtBBCkEwiyeKvc0qcUgetd64vQj1wMom_ThHsKdcvme2AxEMGG5E. Q5ja9fwoyTg6Ym4dir3G5wXgj99oqB.MFbdDaCpluQTssSFqu2VN.9izUg2B HmhLyJNlkT5ZSaXBuoEeOKNklBPwR8dRAozev0es-
X-Yahoo-Newman-Property: ymail-3
From: Samita Chakrabarti <samitac@ipinfusion.com>
To: 'Margaret Wasserman' <margaretw42@gmail.com>
References: <10506E23-EE49-4355-BE7E-CE0151DDD34D@lilacglade.org> <645DDAC5-3104-4BEF-9CA1-6E0362CEFF2C@lilacglade.org> <025601cb8cd6$d23a57c0$76af0740$@yegin@yegin.org> <07cb01cb9000$6cc3eb90$464bc2b0$@com> <5292D095-AB48-4DD3-A70A-ACC39D2FBF71@gmail.com>
In-Reply-To: <5292D095-AB48-4DD3-A70A-ACC39D2FBF71@gmail.com>
Date: Mon, 29 Nov 2010 15:21:53 -0800
Message-ID: <081401cb901c$355666d0$a0033470$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuQBw0m9lpIV5LmSTG6+wbx6VyniAAEl3Pg
Content-Language: en-us
Cc: pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [Pana] Security Comment: draft-ohba-pana-relay-02.txt
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2010 23:20:55 -0000

Hi Margaret,

> 
> 1) An attacker could potentially collect a large set of EAP responses.
> Would that enable any type of brute force attack?  Is there any value to a
> potential attacker in being able to collect these responses for an entire
> site?  This is quite different from an attacker who simply sniffs the site
> communication, as that requires on- path access and the attacker may need
to
> wait much longer to see a large number of request/responses.
> 
> 2) By sending requests to a PAA, an attacker using a rogue PRE might be
able
> to change the state of various resources on the network -- poking holes
> through firewalls, provisioning client access, logging access attempts,
> billing clients for access, or whatever happens in a typical PANA use
> case...  Are there any security implications to the fact that an off-path
> attacker could cause these things to happen?
> 
> 3) You've gone to some lengths to ensure that the PRE itself is not prone
to
> DoS attacks through resource exhaustion.  However, I am concerned that the
> addition of the relay feature to a PAA may open the PAA up to resource-
> exhaustion attacks from a third-party, off-path attacker.  Can you explore
> how/if this can be prevented while allowing any PRE to send requests to
the
> PAA?
> 
> Are there other possible attacks that may be enabled by the existence of
the
> PRE?
> 

[SC>]   I cannot think of any other. You have provided a good list for us to
think about.
My co-authors and Alper have more background in PANA-security or DHCP Relay
security than mine - so it seems we need to discuss this among the
co-authors and come up with a text that addresses different threats. This
work is partially modeled after DHCP relay agent. Also the deployment
scenario we were thinking of is in the home-network. So, some of the threats
in the public Internet may not be applicable here, but we should at least
discuss the assumptions/restrictions/cautions for the use-case networks.
RFC 3046 (DHCP Relay Agent Option) has some wordings on 'trusted' network
and trusted entities in the security section - perhaps we can provide some
texts along that line. 


Thanks,
-Samita