[secdir] pana-relay security considerations

["Alper Yegin" <[e-mail]>]

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