[secdir] Security Review for draft-ohba-pana-relay-02.txt

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

Return-Path: <margaretw42@gmail.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 3DE7128C0DC for <secdir@core3.amsl.com>; Fri, 19 Nov 2010 10:19:56 -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=[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 AdFfa79MHmWJ for <secdir@core3.amsl.com>; Fri, 19 Nov 2010 10:19:54 -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 AE0293A6809 for <secdir@ietf.org>; Fri, 19 Nov 2010 10:19:54 -0800 (PST)
Received: by vws7 with SMTP id 7so194158vws.31 for <secdir@ietf.org>; Fri, 19 Nov 2010 10:20:44 -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=KLeE3yXrsEEklRCsVvxDVrNXLxjMzJWSbqH+TPnERNs=; b=PZDpgoLrdT3i1hO3j604xnWXww3R7SpIeVswYGlesnA38AG/R9JDpbFfVGrIiTfeFh nVoC67G3qPr3zMeVsfwZvphSus8Axe9GeigGElpIFGOC+catyjX6BWfqwqgUosPPer6V EjJ5J8yAqankWUGhvCPpjaRvhSWqFY/PMJo/E=
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=rF0fnWe6T+BOSiz0CjZZzno+M0pZHMY9ETO4sFDV+SxORqyFrsK4tqxCOEQWRt/Zb9 zexn+jCXcyLzY4FNwUriIc6ESj5BYZhQBK9dEAXo7jsu+cf5ZZ7HnHfmgr3ApgEuJJBb 3cfYnUpLIF/vcSxoOESJhlQzKg3M64eh7t2qk=
Received: by 10.220.186.2 with SMTP id cq2mr567318vcb.142.1290190842667; Fri, 19 Nov 2010 10:20:42 -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 v20sm712781vbw.19.2010.11.19.10.20.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 10:20:42 -0800 (PST)
Message-Id: <F3073454-E86F-4E6F-AEFC-7B4184A73040@lilacglade.org>
From: Margaret Wasserman <margaretw42@gmail.com>
To: secdir@ietf.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 13:20:40 -0500
X-Mailer: Apple Mail (2.936)
X-Mailman-Approved-At: Fri, 19 Nov 2010 10:30:03 -0800
Cc: Ralph Droms <rdroms.ietf@gmail.com>
Subject: [secdir] Security Review for draft-ohba-pana-relay-02.txt
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: Fri, 19 Nov 2010 18:19:56 -0000

Hi Security Directorate Folks,

I am shepherding draft-ohba-pana-relay-02.txt for publication as a  
Proposed Standard RFC, and I would like to get a Security Directorate  
review for this document as soon as possible.  The document can be  
found here:

https://datatracker.ietf.org/doc/draft-ohba-pana-relay/

IMO, there is (at least) one way in which the introduction of a relay  
changes the security model for PANA.  In the original PANA protocol,  
the PANA Authentication Agent (PAA) determines the source IP Address  
and source UDP Port number of the PANA Client (PaC) by looking in the  
headers of the request, and responds to that IP Address/Port.   
However, in the case where a relay is being used, the client IP  
Address/Port are included in an option in the relay message.  Requests  
are sent from the relay and responses are sent to the relay, using the  
IP Address/Port in the headers, but the client (using information from  
the option) is authenticated.  I understand that this changes the  
security properties of the PANA exchange, but I am not sure if it  
changes them in a way that matters for the PANA protocol.

So, I could use help here from someone who understands EAP (and  
ideally, PANA) well enough to understand how/if a relay can safely be  
used in a PANA environment.

This is not a WG document, as the PANA WG is closed.  Review comments  
should be sent to me, to Ralph Droms (cc:ed), to the authors (paduffy@cisco.com 
, samitac@ipinfusion.com, robert.cragie@gridmerge.com, yoshihiro.ohba@toshiba.co.jp 
, alper.yegin@yegin.org), and to the (still operational, but now  
unofficial) PANA mailing list (pana@ietf.org).

Thanks,
Margaret