Re: [secdir] pana-relay security considerations

Margaret Wasserman <margaretw42@gmail.com> Mon, 10 January 2011 12:24 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 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 <multiple recipients>; 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: <A5B8DC5E-C118-47CE-9419-2F73879A6430@gmail.com>
From: Margaret Wasserman <margaretw42@gmail.com>
To: Alan DeKok <aland@deployingradius.com>
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)
X-Mailman-Approved-At: Mon, 10 Jan 2011 06:28:08 -0800
Cc: secdir@ietf.org, paduffy@cisco.com, Alper Yegin <alper.yegin@yegin.org>, 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 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