From alper.yegin@yegin.org Mon Jan 10 02:34:41 2011 Return-Path: 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 5BEC83A6956; Mon, 10 Jan 2011 02:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.561 X-Spam-Level: X-Spam-Status: No, score=-100.561 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, 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 c8m2pQ9JZoRr; Mon, 10 Jan 2011 02:34:40 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9388B28C0ED; Mon, 10 Jan 2011 02:34:40 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M8lvA-1PSK0u2OK4-00CcFo; Mon, 10 Jan 2011 05:36:47 -0500 From: "Alper Yegin" To: "'Alan DeKok'" 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> In-Reply-To: <4D270D1D.8090006@deployingradius.com> Date: Mon, 10 Jan 2011 12:35:46 +0200 Message-ID: <005f01cbb0b2$2bc21cc0$83465640$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuuahYO8CAV0E0sQci2eFTD0TST8wCRmpHQ Content-Language: en-us X-Provags-ID: V02:K0:Q8vWxxcFPRbIpR+Ghh197rTw+iHbMC7mQgL2bQoyt+Q hH81m72HDjhlxwAAM89IGS6YtMgOXOA4IStANmTB1IQRrRbeRb D+Xgo12gI26B1AlYJDhOtutplxfFiT7zxkzpn+dahtM3Fxu3mb e2I21e/1T1aiy6FVXQuUrSe/PhYOHqO/OiccBVGEE1xbyCR6r7 A5I1LZjtDSssMlT1MFW9qnLaSzg0CrD9rZALxEub0c= Cc: secdir@ietf.org, pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' Subject: Re: [Pana] pana-relay security considerations X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:34:41 -0000 Hi Alan, > It looks good. I'd like to know if the PRE can relay messages from > the PAA to the PaC on a non-PANA port. If so, that needs to be > addressed somehow. Saying "use DTLS" might not be enough. The PaC picks an ephemeral port when sending the PANA packet. Src:any, dst: 716. And the response from the PAA reverses the ports. 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. (*) If the PRE cares extra about this, it can start performing DPI on the packets. I don't think we should specify this in the document though. > > If the PaC always sends packets from the PANA port, then the text > should be updated to say that the PAA only sends packets to the PANA > port on the PaC. Alper > > Alan DeKok. From alper.yegin@yegin.org Mon Jan 10 03:15:19 2011 Return-Path: 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 06EA428C146; Mon, 10 Jan 2011 03:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.56 X-Spam-Level: X-Spam-Status: No, score=-100.56 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, 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 bZIahc2miQq7; Mon, 10 Jan 2011 03:15:18 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 3CEDE28C13A; Mon, 10 Jan 2011 03:15:18 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MBEIX-1PUncX3ghh-009uyg; Mon, 10 Jan 2011 06:17:27 -0500 From: "Alper Yegin" To: "'Alan DeKok'" 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> <4D2AE752.2000504@deployingradius.com> In-Reply-To: <4D2AE752.2000504@deployingradius.com> Date: Mon, 10 Jan 2011 13:16:25 +0200 Message-ID: <006001cbb0b7$da450050$8ecf00f0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuwtei1MAWfTMPWSv6RWCiLEVgL9wAAKEVQ Content-Language: en-us X-Provags-ID: V02:K0:7MlJwzroWSRyEcbDzi8Yy6IqtktPlJ8V8nLaK1oYtSI RoSlKmaoC9/5C9g70op1fGt1GOy/1ehPVau7Uos5MB5V3wlvKu GBg5TF3Ex4/qE33Wi1TdUza0JPKeeBY4m/xRLUpz/zbrNnAbDs abHJKojOlJkxTd3KJdpmBdoXxde85LYiZCzwKi285LxYvr7EvT j0KKVhR2W85O/67eZLxvx68MV96yuiBMq4rfCKFA7c= Cc: secdir@ietf.org, pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' Subject: Re: [Pana] pana-relay security considerations X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 11:15:19 -0000 > > 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. PRE would authenticate and authorize the other end-point who claims to be a legit PAA before accepting any packets from it. So, it's not "anyone". > 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. This is the DPI aspect. What should we check for well-formation? Many if not all fields in the PANA header may be updated by future releases of the spec (extensions, etc.). so checking on them would force the PRE to get upgraded (with a revised version of PANA-relay spec each time) when PaC/PAA gets upgraded. This is very undesirable. I think we shall stick to relying on PAA-PRE security. Alper > > Alan DeKok. From margaretw42@gmail.com Mon Jan 10 04:24:33 2011 Return-Path: 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 31F5D28C134; Mon, 10 Jan 2011 04:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Xx7sKxe-XL9n; Mon, 10 Jan 2011 04:24:32 -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 1900028C133; Mon, 10 Jan 2011 04:24:32 -0800 (PST) Received: by vws7 with SMTP id 7so7836867vws.31 for ; Mon, 10 Jan 2011 04:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=QwZUdrojJsTawoc3ox31HEtl+igA41D9Ao7nLYLQ+Yo=; b=fLs78LQt/dPIhQE8t7yX624IGZye9cb5ai7meYT3F/IC0Cfw7jrSTmaCaxn5xiudoQ HtOWrBQBLOq3m2Z4hMh5yTyGaxmrcQlbUAKE71y1Z0gJgOQg7P8OKGhnLCFg6/lnYJTA UgmB2lPm2GjZjyj5JqNuyuWmIWPs+ec/A8baQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=o9cJ+4xtwITCNIQYAE/SQUkshopjaBpJDTCZC+P91uzobATgfHwmhADLwMdF9ctvTd 6b/Kd7XEU9D8M3v5W72jeD+5h1mHNq7WES36zH8CfKTdeuDh5hR3OmhyP90e4w7S8iug XpYFSTRgCWGLv0SUtttPyNW+K+dd9gMhAxwe8= Received: by 10.220.188.133 with SMTP id da5mr8922414vcb.175.1294662405169; Mon, 10 Jan 2011 04:26:45 -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 d14sm6278228vcx.23.2011.01.10.04.26.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 04:26:44 -0800 (PST) Message-Id: From: Margaret Wasserman To: Alan DeKok In-Reply-To: <4D2AF65C.6060903@deployingradius.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Jan 2011 07:26:42 -0500 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> <4D2AE752.2000504@deployingradius.com> <006001cbb0b7$da450050$8ecf00f0$@yegin@yegin.org> <4D2AF65C.6060903@deployingradius.com> X-Mailer: Apple Mail (2.936) Cc: secdir@ietf.org, pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' Subject: Re: [Pana] pana-relay security considerations X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 12:24:33 -0000 Hi Alan, On Jan 10, 2011, at 7:06 AM, Alan DeKok wrote: > >> I think we shall stick to relying on PAA-PRE security. > > Then it should be a MUST. I originally thought that we needed some form of PRE-PAA security, and your comments have, IMO, suggested more reasons why this is needed. In my opinion, a security mechanism for PRE-PAA authentication needs to be defined in this spec before we publish it. I think it should be optional to actually _use_ the security mechanism, though since there some situations (such as closed or otherwise secured networks) where this type of security isn't required operationally. The security considerations should make it clear what the risks are, and describe the situations in which it would be safe not to use the PRE-to-PAA security. Alan, would that satisfy your concerns? PANA folks, would that meet your needs? Margaret From alper.yegin@yegin.org Mon Jan 10 11:58:20 2011 Return-Path: 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 CE81428C117; Mon, 10 Jan 2011 11:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.859 X-Spam-Level: X-Spam-Status: No, score=-100.859 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 nEgfEN2hOL0t; Mon, 10 Jan 2011 11:58:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 13AD828C110; Mon, 10 Jan 2011 11:58:20 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M932L-1PSBBO2wt3-00CFvm; Mon, 10 Jan 2011 15:00:31 -0500 From: "Alper Yegin" To: "'Margaret Wasserman'" , "'Alan DeKok'" 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> <4D2AE752.2000504@deployingradius.com> <006001cbb0b7$da450050$8ecf00f0$@yegin@yegin.org> <4D2AF65C.6060903@deployingradius.com> In-Reply-To: Date: Mon, 10 Jan 2011 21:59:29 +0200 Message-ID: <010101cbb100$ecead380$c6c07a80$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuwwaTIb/4A+U5fT3GmjFhBVvOXTgAPo5Kw Content-Language: en-us X-Provags-ID: V02:K0:b/VDN2plbSwZLBH8VzR/kZpOazowCauPzaA10qeoQda +esLQNt4mv1KU21R8Z7ZI7kIe90B9c9C7cxg/olGc14dlzPFqe EkwdbNtoMGERukISwAW6Pg1nZlW9AqDZyqZWUJWEsiqF0DkE+L sZdKou1avtdBBajtvfOcBk32ilQlRGsE6FATQWqh5drIHOayui rJ/KD2TV2gGs1RIY4v0Gz7q5hUYZuOyKa6SRfreqIQ= Cc: secdir@ietf.org, pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' Subject: Re: [Pana] pana-relay security considerations X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:58:20 -0000 > On Jan 10, 2011, at 7:06 AM, Alan DeKok wrote: > > > >> I think we shall stick to relying on PAA-PRE security. > > > > Then it should be a MUST. Security considerations section already says so: Some of the risks stemming from the aforementioned threats are already handled by the EAP and PANA as described. The residual risks >>shall be<< mitigated using additional physical or cryptographic security in the network hosting the PREs and the PAAs. > I originally thought that we needed some form of PRE-PAA security, and > your comments have, IMO, suggested more reasons why this is needed. > > In my opinion, a security mechanism for PRE-PAA authentication needs > to be defined in this spec before we publish it. Continuing the modeling after DHCP, we could define use of IPsec (same way RFC 3315 does). > I think it should be > optional to actually _use_ the security mechanism, though since there > some situations (such as closed or otherwise secured networks) where > this type of security isn't required operationally. Indeed. > The security > considerations should make it clear what the risks are, and describe > the situations in which it would be safe not to use the PRE-to-PAA > security. > > Alan, would that satisfy your concerns? PANA folks, would that meet > your needs? Alper