[secdir] pana-relay security considerations

"Alper Yegin" <alper.yegin@yegin.org> Fri, 24 December 2010 20:57 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 51F973A686B; Fri, 24 Dec 2010 12:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.825
X-Spam-Status: No, score=-100.825 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ut6bpcxSGWWb; Fri, 24 Dec 2010 12:57:23 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net []) by core3.amsl.com (Postfix) with ESMTP id 47C6E3A683B; Fri, 24 Dec 2010 12:57:23 -0800 (PST)
Received: from ibm (dsl88-247-34762.ttnet.net.tr []) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MQ4KJ-1PS87u2n1X-0051yh; Fri, 24 Dec 2010 15:59:01 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Alan DeKok' <aland@deployingradius.com>, margaretw42@gmail.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>
Date: Fri, 24 Dec 2010 22:58:45 +0200
Message-ID: <070601cba3ad$63852150$2a8f63f0$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acuby82V+EVk4y89Qsim1hbsx9U3iwH4OIZw
Content-Language: en-us
X-Provags-ID: V02:K0:uGATVOeq0WE9qEefQ6WUdDIzvdbDrjxvfkzyjccSn5b fuDQydRKkokYkSkLNR6BwzBOBi/YzJMqkXOU4zpVhpPuG6Cpz6 gLytTOwXb05R/5hEIN00DwynZg1DUIZWr0IoTjgPvLCZG3c14B y37zgU15QeY8BDUAIwbcKbF9QS7+fdjAbytoMdtIH7SdheSrVB uQ4NDbdIofSMQnxFq9gOz7iYPD6Z2c+buy0QisdLAA=
Cc: secdir@ietf.org, paduffy@cisco.com, pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: [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: Fri, 24 Dec 2010 20:57:24 -0000

Hi Alan, Margaret,

Based on the feedback we have received from you, we have enhanced the
security considerations section of pana-relay I-D as follows.

Please see and let us know your feedback.


Security Considerations

A PRE's main objective is to assist transport of PANA messages between the
PaC and the PAA. Relay operation performed between the PRE and the PAA forms
an additional conceptual link for relaying the end-to-end PANA messages
between the PaC and the PAA. In that sense, a PRE resembles a bridge or a
router that sits between the PaC and the PAA when non-relayed PANA (RFC
5191) is used, however the PRE acts as a protocol-aware relay and thus will
only relay valid PANA messages to and from the PaC.  

A PRE can pose certain threats to the relayed PANA messages. A PRE can delay
or drop PANA messages sent by the PaC or the PAA. It can also spoof or
modify PANA messages sent towards the PaC or the PAA. These threats are
similar to what an on-path bridge/router (i.e., a man-in-the-middle, MitM)
can pose to non-relayed PANA. EAP and PANA protocols are designed to operate
over unsecure links where aforementioned threats can already exist. Even
though these threats cannot be leveraged to gain unauthorized network
access, or compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.),
other damages such as preventing authentication to complete, or denial-of
service are still possible. 

Even though the PRE-to-PAA relay path appears to be a separate additional
link for transporting the PANA messages, the PRE may pose a few additional
risks than traditional on-path bridges and routers. The following explains
the risks and mitigations of PRE as a relay device.

The PRE inserts PaC-Information AVP as the PaC-generated PANA packet is
encapsulated in a PRY packet to the PAA. This AVP carries the IP address and
the UDP port number values of the PANA packet as sent by the PAC. These
values are already carried inside the IP and UDP headers with non-relayed
PANA and they are not necessarily secured. EAP and PANA are designed to work
in the absence of their protection. Therefore, no additional PANA-layer
security is needed when these values are carried as PANA AVPs between the
PRE and the PAA. If a future document defines additional payload AVPs for
the PRY messages, there may be a need to define additional security for
those messages.  

A rogue PRE can spoof PANA messages on behalf of a victim PaC and receive
the response irrespective of the location of the PRE with respect to the
network topology. Achieving the same threat with non-relayed PANA requires
the rogue node be a MitM, otherwise the spoofed packets may be dropped by
the ingress filtering network elements, or the responses would be directly
sent to the victim PaC IP address and may not be received by the rogue node.
Nevertheless, such a rogue PRE cannot perform full initial authentication on
behalf of the victim PaC unless it also holds the PaC's credentials
(including the master key). Furthermore, any spoofed PANA messages after the
initial authentication will fail the integrity checks at the PAA when a
key-generating EAP method is used. 

The only state that can change on the PAA upon a rogue PRE sending a spoofed
PRY is the IP address and UDP port number of the PRE stored as PANA session
attributes, which impacts where the PAA sends the next PANA packet (i.e., to
the rogue PRE instead of the legitimate PRE). The PAA also needs to handle
the PaC-Information AVP in addition to the PaC-originated PANA message
carried in the Relayed-Message AVP, so use of the PRE may impose additional
storage requirements on the PAA. As required by this specification, if the
relayed PANA packet is invalid, it cannot cause the aforementioned state
change. A rogue PRE generating a valid PANA packet requires it be a MitM in
order to synch up with the PANA session state and attributes on the PaC.
Such a MitM can already disturb the EAP and PANA even without playing the
role of a PRE.

An unauthorized node pretending as PAA, can spoof the relayed PANA messages
to the PRE in order to get them delivered to the PaC. While the harm caused
by such spoofed packets are limited (due to the EAP and PANA design with
unsecured network operation in mind), processing of bogus packets can cause
processing load on the PaC. This specification does not allow the PRE to
relay any non-PANA packet (*).

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. Access control lists implemented on the PRE,
PAA, or intermediary firewalls supported by cryptographic (e.g., using
IPsec, DTLS, L2 security, etc.) or physical authentication/authorization are
needed for protecting legitimate PRE and PAAs against rogue ones. Details of
exact solutions are outside the scope of this document.

PREs do not need to maintain per-PaC state, therefore they are robust
against resource consumption DoS (Deniable of Service) attacks. However,
PREs may maintain per-PaC state to provide additional security based on the
transaction sequence being relayed. 

(*) need to reflect that to the document body.  Will only be checking the
UDP port (at least one be 716).