[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [74.208.4.195]) 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 [88.247.135.202]) 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. ------8<---------------------- 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).
- [secdir] Secdir review of draft-ohba-pana-relay Alan DeKok
- Re: [secdir] Secdir review of draft-ohba-pana-rel… Yoshihiro Ohba
- Re: [secdir] Secdir review of draft-ohba-pana-rel… Alan DeKok
- [secdir] PRE enforcing message validity (was RE: … Alper Yegin
- [secdir] Token (was RE: Secdir review of draft-oh… Alper Yegin
- Re: [secdir] PRE enforcing message validity (was … Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Margaret Wasserman
- Re: [secdir] pana-relay security considerations Alper Yegin