Early Review of draft-ohba-pana-relay-
review-ohba-pana-relay-secdir-early-dekok-2010-12-16-00

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.