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

Alan DeKok <aland@deployingradius.com> Wed, 15 December 2010 10:44 UTC

Return-Path: <aland@deployingradius.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 EC6C328C15F; Wed, 15 Dec 2010 02:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level:
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 D0prgx1czdcr; Wed, 15 Dec 2010 02:44:31 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id B96D628C114; Wed, 15 Dec 2010 02:44:30 -0800 (PST)
Message-ID: <4D089C73.6050107@deployingradius.com>
Date: Wed, 15 Dec 2010 11:46:11 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: robert.cragie@gridmerge.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> <4D087AD5.8020901@gridmerge.com>
In-Reply-To: <4D087AD5.8020901@gridmerge.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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
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 10:44:32 -0000

Robert Cragie wrote:
>  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;


> <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>

  I'm not sure what "different messages" means.  My goal was to ensure
that rogue PAAs could only send PANA messages to the IP and source port
used by a PaC to send PANA messages.

  I'm not concerned about protecting messages to the PAA.  It's already
on an open network, and anyone on that network can send any content to
any port.  So adding PRE to PAA security is useless.

  i.e. authenticating messages in *both* directions is not the goal of
the token.

>>   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>

  If the PaC has access to the wider network before it's authenticated,
then there is no need for any PRE-PAA token.

  If the PaC has access to the wider network before it's authenticated,
then I'm not really sure why PANA is being used at all.

  Alan DeKok.