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). _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana