Re: [Pana] IESG discussions on draft-ohba-pana-relay

Jari Arkko <jari.arkko@piuha.net> Thu, 30 June 2011 21:11 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D74F11E8245 for <pana@ietfa.amsl.com>; Thu, 30 Jun 2011 14:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.33
X-Spam-Level:
X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COkwb2nGem4t for <pana@ietfa.amsl.com>; Thu, 30 Jun 2011 14:11:38 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 34F7311E8267 for <pana@ietf.org>; Thu, 30 Jun 2011 14:11:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5EAEE2CEA0; Fri, 1 Jul 2011 00:11:15 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ4oUUrngrX6; Fri, 1 Jul 2011 00:11:11 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 603E52CC39; Fri, 1 Jul 2011 00:11:11 +0300 (EEST)
Message-ID: <4E0CE66F.2040203@piuha.net>
Date: Thu, 30 Jun 2011 23:11:11 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <4DF04217.3080304@toshiba.co.jp> <6491375641982933760@unknownmsgid> <BANLkTinVZ2Bvd6A+znQTiB7X-P6XXh3Cow@mail.gmail.com> <4E037743.2060602@gridmerge.com> <4E037A9D.8080200@piuha.net> <4E03EABF.501@net-zen.net> <4E04595B.4070908@cs.tcd.ie>
In-Reply-To: <4E04595B.4070908@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ohba-pana-relay@tools.ietf.org, pana@ietf.org
Subject: Re: [Pana] IESG discussions on draft-ohba-pana-relay
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 30 Jun 2011 21:11:38 -0000

Stephen, Glen,

>>> "PRE/PAA security is OPTIONAL since PANA messages are designed to be
>>> used in untrusted networks, but if cryptographic mechanism is supported,
>>> it SHOULD be IPsec."
>>>       
>> This is an interesting statement.  Just one question: if it is not
>> possible to use the protocol in a secure fashion (the claim being that
>> MITM attacks are impossible to prevent), how is it that the protocol is
>> "designed to be used in untrusted networks"?
>>     
>
> So the suggested text does assume that the pana messages are well
> protected between the PaC and PAA and that the PRE is security-wise
> just the same as any old router on the path.
>
> If pana messages are actually commonly sent that are vulnerable to
> some attacks on the messages themselves, then IPsec between the PRE
> and PAA would add enough value that I'd want it as a SHOULD.
>
> However, I'm told that this is not the case and so the text above
> should be fine.
>
> But if the reality differs, I'd like to know about that.
>   

Obviously, we do not necessarily know what the reality will be with PANA 
use, there is not much deployed practice to look at. I think most people 
would run a cryptographically well designed EAP methods.

My point was that even with such methods, a MITM can cause PANA to fail 
and network access to be prevented. This is true of many things, 
including IPsec. If I'm in a position to drop selected messages, for 
instance, I can prevent an IPsec tunnel from being established. Still, 
we like to think that IPsec has been designed to be used in untrusted 
environments. It just cannot deal with all types of attacks, just with 
some. Just like PANA.

I have sent an approved message for this draft with an RFC Editor note 
using Alper's suggested text. If there are further text tweaks please 
handle them in AUTH48. If there is further discussion of bigger issues, 
we can bring the document back for another look at the IESG.

Jari