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

Margaret Wasserman <margaretw42@gmail.com> Fri, 19 November 2010 20:27 UTC

Return-Path: <margaretw42@gmail.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 6B2293A689C for <pana@core3.amsl.com>; Fri, 19 Nov 2010 12:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 qjxBYT6EL-AU for <pana@core3.amsl.com>; Fri, 19 Nov 2010 12:27:35 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B5C063A6862 for <pana@ietf.org>; Fri, 19 Nov 2010 12:27:34 -0800 (PST)
Received: by vws7 with SMTP id 7so318835vws.31 for <pana@ietf.org>; Fri, 19 Nov 2010 12:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=bLyii60sPrHMWJeZTKjMYr02ydeyymRAgLzPUSfuhVE=; b=qXP3Ng3uaW94qwdeRKYsfKHZpw5i893OPTt3EnR8lQ06c9zwJ+ByDWPD1BfdTK6s+x kwxB0PpIxDZ3yjJCH+UU2rJ6bPQnwd94aAEP+2jCW2ryVoyHLKvYPf4d0qvx679GEoWS W1iBlQ7Voys5hmcg4Le5BYELVHhu9rycCzYSY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=IsdkuTARz4WanN8X1yI3vAU5cv/T4+Hn/TOMEQNmXpROdK+5QadGGeTqIx7jrf8mpD MHcN3DhECaBkRlmFD6/x6d05WTr7xmmo682Ub66dNn99BLhBsfjw9hEaaoKlVCRzraDk iQ4oVF/YpYJJpYBs5fYV7L5X0GxM9dmcWDB5Y=
Received: by 10.220.170.65 with SMTP id c1mr559594vcz.86.1290198504031; Fri, 19 Nov 2010 12:28:24 -0800 (PST)
Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id y14sm512905vch.4.2010.11.19.12.28.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 12:28:23 -0800 (PST)
Message-Id: <10506E23-EE49-4355-BE7E-CE0151DDD34D@lilacglade.org>
From: Margaret Wasserman <margaretw42@gmail.com>
To: paduffy@cisco.com, Samita Chakrabarti <samitac@ipinfusion.com>, robert.cragie@gridmerge.com, yoshihiro.ohba@toshiba.co.jp, Alper Yegin <alper.yegin@yegin.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 19 Nov 2010 15:28:22 -0500
X-Mailer: Apple Mail (2.936)
Cc: Ralph Droms <rdroms.ietf@gmail.com>, pana@ietf.org
Subject: [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: Fri, 19 Nov 2010 20:27:36 -0000

Hi All,

As part of asking the Security Directorate to review draft-ohba-pana- 
relay-02.txt, I reviewed the Security Considerations section and tried  
to determine how/if this relay changes the security model for PANA.

As I understand it, the original PANA protocol relied on return  
routability...  We didn't worry about address spoofing, because the  
credentials were returned to the address they were meant for, meaning  
that only an on-link (or on path? -- but we didn't allow a path  
originally) attacker could spoof a client address and see the  
response.  With introduction of relay code on the PAA, any node can  
pretend to be a PRE
and get credentials for any other node.

This isn't mentioned in the Security considerations section, but it is  
potentially significant.  So, there might be a need for the PAA to  
authorize the PRE before responding to messages from it.  If there is  
some reason why you don't believe the PAA needs to authorize the PRE,  
you would (at the very least) need to explain that in the Security  
Considerations section.

Thanks,
Margaret