Early Review of draft-ohba-pana-relay-
|Requested rev.||no specific revision (document currently at 03)|
|Team||Security Area Directorate (secdir)|
|Authors||Alper Yegin, Samita Chakrabarti, Yoshihiro Ohba, Robert Cragie, Paul Duffy|
|Draft last updated||2010-12-16|
Secdir Early review of -?? by Alan DeKok
Tsvdir Last Call review of -?? by Yoshifumi Nishida
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Margaret Wasserman said: > IMO, there is (at least) one way in which the introduction of a relay > changes the security model for PANA. In the original PANA protocol, > the PANA Authentication Agent (PAA) determines the source IP Address > and source UDP Port number of the PANA Client (PaC) by looking in the > headers of the request, and responds to that IP Address/Port. > However, in the case where a relay is being used, the client IP > Address/Port are included in an option in the relay message. Requests > are sent from the relay and responses are sent to the relay, using the > IP Address/Port in the headers, but the client (using information from > the option) is authenticated. I understand that this changes the > security properties of the PANA exchange, but I am not sure if it > changes them in a way that matters for the PANA protocol. > > So, I could use help here from someone who understands EAP (and > ideally, PANA) well enough to understand how/if a relay can safely be > used in a PANA environment. The proposed document doesn't affect the security of EAP. EAP is already transported over insecure and unauthenticated channels (i.e. EAPoL), so changing the PANA transport requirements should have no effect on EAP. Some questions: Are multiple relays allowed? If so, how do they work? If not, how are they detected, and forbidden by the participants? The Security Considerations section says: Since the PRE does not maintain per-PaC state, the PRE is robust against resource consumption DoS (Deniable of Service) attack. However, the PRE relays packets to the PaC. This means that entities on the PAA network can now send PANA messages to the PaC, when they previously could not. While the PaC is supposed to discard invalid and/or unexpected messages (RFC 5191), the PRE can be used to send messages to *arbitrary* UDP ports on the PaC or any other machine in the PaC network. The same attack applies (but less so) in the inverse direction. A fake PaC can send the PAA arbitrary PANA messages. Since this can already happen today, there is no new issue here. Having a stateful PRE would help address this attack. It would not prevent it, as the PANA messages are unsigned, and anyone can pretend to be the PRE. I would suggest requiring that the PRE enforce the Message Validity checks of RFC 5191, Section 5.5. If this cannot be done in its entirety, this draft should add a new section entitled "Message Validty checks for the PRE". e.g. The PRE MUST relays only well-formed PANA messages to the PAA. And before relaying messages back to the PaC, it ensures that the Relayed-Message AVP contains a well-formed PANA message. All malformed messages MUST be discarded. Since the behavior of the PAA is also changing, it would be good to leverage the PAA session tracking to add a cryptographic token between the PRE and PAA. This token would be added by the PRE prior to relaying a message, and the PAA could echo it back in the response. This ability means that the PRE is still stateless (in terms of tracking packets), but gains a little bit of security by maintaining additional state. The token would be subject to eavesdropping, so it offers small additional security. Adding it is a recommendation, not a requirement of this review. The token could be (for example) a signature of the PaC source IP and port, using a secret known only to the PaC, and generated automatically. The secret would also need to change periodically. Along with Message Validation, this token would increase the bar for attackers sending packets to the PaC. Rather than simply being able to leverage the PRE to send arbitrary traffic to the PaC, the attacker would need to be able to monitor PRE -> PAA traffic, and to then send well-formed PANA messages to the PaC, to the port used by the PaC for receiving PANA messages. That minimizes the attack exposure. There is also some confusion between PRE and PRY, such as: (c) The source IP address and UDP port number of the PRY is stored in a new PANA session attribute "IP address and UDP port number of the PRE". The text should consistently refer to "address of the PRE", or "address carried within the PRY" Alan DeKok.