Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)

Robert Cragie <robert.cragie@gridmerge.com> Wed, 15 December 2010 08:21 UTC

Return-Path: <robert.cragie@gridmerge.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 C42E43A6F61; Wed, 15 Dec 2010 00:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 iqjlLh3Ov3xe; Wed, 15 Dec 2010 00:21:26 -0800 (PST)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 653BA3A6E46; Wed, 15 Dec 2010 00:21:24 -0800 (PST)
Received: from client-86-31-167-78.oxfd.adsl.virginmedia.com ([86.31.167.78] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSmdN-0002KP-Is; Wed, 15 Dec 2010 08:22:50 +0000
Message-ID: <4D087AD5.8020901@gridmerge.com>
Date: Wed, 15 Dec 2010 08:22:45 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Alan DeKok <aland@deployingradius.com>
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>
In-Reply-To: <4D07D090.9020407@deployingradius.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010002030800010202000003"
X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800
Cc: 'Yoshihiro Ohba' <yoshihiro.ohba@toshiba.co.jp>, secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin <alper.yegin@yegin.org>, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert.cragie@gridmerge.com
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: Wed, 15 Dec 2010 08:21:27 -0000

Alan,

Thanks for your response. Some further comments below, bracketed by 
<RCC></RCC>.

In summary, I think there are two security considerations in addition to 
the other text already proposed which need to be addressed:

   1. The PRE, as a protocol-aware relay, MUST only relay PRY messages
      and MUST only accept valid PANA messages
   2. The use of a PRE causes additional state at the PAA (IP address
      and port of PRE) which may need to be stored

Whilst the language Alper has used so far is probably sufficient, I do 
think that it is important to strenuously recommended that the PRE-PAA 
connection is secured using either DTLS, PANA SA or L2 protection;

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>


On 14/12/2010 8:16 PM, Alan DeKok wrote:
> Robert Cragie wrote:
>>      * I agree with the notion of enforcing the relay to only process
>>        valid PANA messages and only send valid PANA messages. The fact it
>>        is a functionally-defined relay (as opposed to a generic IP
>>        tunnel) means that we can do this. Therefore we need to add text
>>        as you suggest.
>    Thanks.
>
>>      * I am less sure of the need for a token. As far as I can see, the
>>        token would only protect the immutable information in the data
>>        sent from PRE to PAA, i.e. the IP address and the port. This has
>>        some benefit but would not necessarily prevent a rogue PAA sending
>>        a bogus encapsulated frame.
>    It would *authenticate* the data sent from the PAA to the PRE.  This
> authentication would ensure that the PAA could only respond to packets
> sent by the PRE.
<RCC>Unless I am missing something, a token generated and validated by 
the PRE could only authenticate the immutable parts of the PRY, i.e. the 
PaC-Information AVP. You would need a full security association between 
PRE and PAA to authenticate different messages in both directions.</RCC>
>    As I said earlier, this would ensure that a rogue PAA can only (a)
> send PANA messages, to (b) the IP of the PaC, and (c) the port of the
> PaC used to send PANA messages.  It would prevent a rogue PAA from
> sending a non-PANA frame to arbitrary non-PANA IPs and ports.
<RCC>The use of a token doesn't enforce (a) but the PRE can check for 
(a) in the scope of PANA as a transport. I agree it does enforce (b) and 
(c). The question is whether the additional effort is worth it on the 
basis that considering a PaC-PAA communication, the IP address and port 
may not be protected either and PANA doesn't require it at the moment.</RCC>
>>   Using DTLS between PRE and PAA would
>>        provide protection for the whole packet, possibly including
>>        encryption.
>     It's not per-packet protection.  It's that the PRE will only accept
> frames from the PAA that have been authenticated via TLS.
<RCC>Agreed - that's essentially what I meant; perhaps I used the wrong 
language.</RCC>
>> Using a PANA SA would provide better protection than a
>>        PRE-originated token. Using L2 security also provides a 'walled
>>        garden' protection. It seems to me possible for a rogue node to
>>        send any packet to any port on a node which is accessible at the
>>        link layer provided one knows its address and assumes no L2
>>        security therefore I don't again see this as an additional threat
>    The document clearly states that the PRE is proxying packets because
> the PAA can not otherwise route traffic to the PaC.  Security between
> the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE
> to route traffic to the PaC.
<RCC>I agree it is required to prevent rogue PAAs from causing the PRE 
to route traffic. It would seem the debate is about whether we have to 
mandate this for PRE-PAA in general as PANA, as a transport, does not 
require it.</RCC>
>    One view could be that the PaC is already vulnerable to rogue PAAs on
> the local network.  That local network may, however, be limited in the
> number of systems, and what they're allowed to do.  My presumption is
> that the PRE to PAA network is a fully-connected network capable of
> routing to arbitrary destinations.
>
>    So adding a PRE opens the PaC to attacks from arbitrary sources on a
> wide-area network, which would seem to be a violation of the PANA
> assumptions.
<RCC>That is true. However, I think Alper's point is that an equivalent 
MiTM router on a wider network in the vicinity of the PaC could still be 
the target for a rogue PAA and that the PRE model was really no 
different. So this doesn't necessarily pose an *additional* threat.</RCC>
>    Alan DeKok.
>