[secdir] Secdir review of draft-ohba-pana-relay
Alan DeKok <aland@deployingradius.com> Thu, 09 December 2010 09:09 UTC
Return-Path: <aland@deployingradius.com>
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 B35A128C0E1; Thu, 9 Dec 2010 01:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 OrWvlru-x239; Thu, 9 Dec 2010 01:09:49 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 576F828C0CF; Thu, 9 Dec 2010 01:09:49 -0800 (PST)
Message-ID: <4D009D34.1020809@deployingradius.com>
Date: Thu, 09 Dec 2010 10:11:16 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: yoshihiro.ohba@toshiba.co.jp, paduffy@cisco.com, 'Alper Yegin' <alper.yegin@yegin.org>, margaretw42@gmail.com, pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, Ralph Droms <rdroms.ietf@gmail.com>
Subject: [secdir] Secdir review of draft-ohba-pana-relay
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: Thu, 09 Dec 2010 09:09:50 -0000
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.
- [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