Subject: [secdir] Secdir review of draft-ohba-pana-relay

From: Alan DeKok <[email-masked]>
Date: Thu, 09 Dec 2010 10:11:16 +0100

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.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Dec 2010 16:46:07 +0900

Thank you very much for reviewing the draft.  Please see my comments
below.

> they detected, and forbidden by the participants?

Relaying happens only one time for each message belonging to the same
PANA session.  We can clarify this in the draft.

> messages MUST be discarded.

I agree that some message validity check at the PRE can help address
issues you mentioned above.  In my analysis: (1) Some check requires
the PRE to be stateful (e.g., sequence number check on relayed PANA
message requires the PRE to keep track of sequence numbers for each
session), (2) some check does not require the PRE to be stateful
(e.g., message length check), and (3) some check is impossible unless
security is compromised (e.g., AUTH AVP check of relayed PANA message
using the PANA SA between the PaC and the PAA).  Let's discuss (1) and
(2).   There are several design choices here:

(a) (1) and (2) are mandatory
(b) (1) is optional, (2) is mandatory
(c) (1) and (2) are optional

I listed these choices because ZigBee has chosen pana-relay mainly
because of the stateless nature of PRE in its current design and I
think that making PRE stateful can be a too strong requirement for ZigBee.

(Just to clarify, "stateless" here means that per-PaC state does not
need to be maintained by PRE.)

> receiving PANA messages.  That minimizes the attack exposure.

To address Margaret's security comment, we (co-authors) are currently
discussing whether we can recommend use of DTLS to protect PRY message
between PRE and PAA for less-trusted environment.  Your suggested
token-based approaches (PRE-generated and PaC-generated tokens) can be
another recommendation for similar environment.  I think we need to
consider tradeoff between the level of improvement in security and the
required cost for each alternative.

> "address carried within the PRY"

We will improve the consistency about referring to addresses.

Thank you,
Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Fri, 10 Dec 2010 09:41:31 +0100

> PANA session.  We can clarify this in the draft.

  Yes.  The draft does not forbid a message passing through multiple relays.

> think that making PRE stateful can be a too strong requirement for ZigBee.

  A cryptographic token can help with this.  The token can contain
information about the sequence number, signed by a secret known only to
the PRE.

> required cost for each alternative.

  Yes.  Adding a token is simple, and requires minimal changes to the
PAA (echo the token), and some small work on the PRE (generate / verify
the token).

  In contrast, DTLS takes much more work.

  Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 13 Dec 2010 10:28:10 +0200

Hi Alan,

Thank you for the review.

> > messages to *arbitrary* UDP ports on the PaC or any other machine in

Is the concern that a rogue PRE injecting bogus PANA messages towards the
PaC, or a legitimate PRE relaying bogus PANA messages injected by some rogue
PAA?

> > messages MUST be discarded.

Why not let the PaC deal with this? It already performs such checks.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 13 Dec 2010 10:31:45 +0200

Alan,

> > receiving PANA messages.  That minimizes the attack exposure.

Arbitrary traffic cannot pass the validation on the PaC, as the sequence
numbers need to match. And there is also state machine match needed. PaC's
is in certain state and would not react to any arbitrary message unless the
message is expected in the current state.

Alper

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Dec 2010 17:11:47 +0100

Alper Yegin wrote:
>>> While the PaC is supposed to discard invalid

  A legitimate PRE relaying bogus PANA messages.  Or even non-PANA
messages.  From my reading of the draft, the reply from the PAA is a
PANA message with a PANA message carried as a TLV.  But there is *no*
requirement that the TLV actually carries a real PANA message.  So it
can be anything.

> Why not let the PaC deal with this? It already performs such checks.

  The PaC discards invalid PANA messages sent to the port from which it
sent PANA messages.

  Since the PRE is stateless, it can be coerced into sending messages to
*any* port on the PaC.  Since the PRE has no requirement to verify the
relayed message, it doesn't even have to be PANA.

  The PRE can be convinced to relay arbitrary data to arbitrary UDP
ports on the PaC.  This can't be a good thing.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Dec 2010 17:14:59 +0100

> message is expected in the current state.

  If the traffic is sent to the PANA port used by the PaC.  The traffic
*can* be sent to other ports.  As it stands today, the draft doesn't
appear to prevent this.

  The idea of the token is to add limited state to the PRE.  It will
only send messages that are (a) valid PANA messages, (b) to the IP of a
PaC, and (c) to the port used by the PaC used to send PANA messages.

  Using DTLS in between the PRE and PAA would achieve the same effect.
The possibility of a rogue PAA is removed, so no token is required.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Dec 2010 21:16:16 +0100

Robert Cragie wrote:
>     * I agree with the notion of enforcing the relay to only process
>       valid PANA messages and only send valid PANA messages. The fact it
>       is a functionally-defined relay (as opposed to a generic IP
>       tunnel) means that we can do this. Therefore we need to add text
>       as you suggest.

  Thanks.

>     * I am less sure of the need for a token. As far as I can see, the
>       token would only protect the immutable information in the data
>       sent from PRE to PAA, i.e. the IP address and the port. This has
>       some benefit but would not necessarily prevent a rogue PAA sending
>       a bogus encapsulated frame.

  It would *authenticate* the data sent from the PAA to the PRE.  This
authentication would ensure that the PAA could only respond to packets
sent by the PRE.

  As I said earlier, this would ensure that a rogue PAA can only (a)
send PANA messages, to (b) the IP of the PaC, and (c) the port of the
PaC used to send PANA messages.  It would prevent a rogue PAA from
sending a non-PANA frame to arbitrary non-PANA IPs and ports.

>  Using DTLS between PRE and PAA would
>       provide protection for the whole packet, possibly including
>       encryption.

   It's not per-packet protection.  It's that the PRE will only accept
frames from the PAA that have been authenticated via TLS.

> Using a PANA SA would provide better protection than a
>       PRE-originated token. Using L2 security also provides a 'walled
>       garden' protection. It seems to me possible for a rogue node to
>       send any packet to any port on a node which is accessible at the
>       link layer provided one knows its address and assumes no L2
>       security therefore I don't again see this as an additional threat

  The document clearly states that the PRE is proxying packets because
the PAA can not otherwise route traffic to the PaC.  Security between
the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE
to route traffic to the PaC.

  One view could be that the PaC is already vulnerable to rogue PAAs on
the local network.  That local network may, however, be limited in the
number of systems, and what they're allowed to do.  My presumption is
that the PRE to PAA network is a fully-connected network capable of
routing to arbitrary destinations.

  So adding a PRE opens the PaC to attacks from arbitrary sources on a
wide-area network, which would seem to be a violation of the PANA
assumptions.

  Alan DeKok.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 14 Dec 2010 17:25:08 +0000

Alan,

Thank you for your review of the PANA relay draft. Sorry for the late 
reply - I was busy last week (actually testing PANA relay). In response 
to some of your points:

      a bogus encapsulated frame. Using DTLS between PRE and PAA would
      encryption. Using a PANA SA would provide better protection than a

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 15 Dec 2010 08:22:45 +0000

Alan,

Thanks for your response. Some further comments below, bracketed by 
<RCC></RCC>.

In summary, I think there are two security considerations in addition to 
the other text already proposed which need to be addressed:

   1. The PRE, as a protocol-aware relay, MUST only relay PRY messages
      and MUST only accept valid PANA messages
   2. The use of a PRE causes additional state at the PAA (IP address
      and port of PRE) which may need to be stored

Whilst the language Alper has used so far is probably sufficient, I do 
think that it is important to strenuously recommended that the PRE-PAA 
connection is secured using either DTLS, PANA SA or L2 protection;

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

> authentication would ensure that the PAA could only respond to packets
<RCC>Unless I am missing something, a token generated and validated by 
the PRE could only authenticate the immutable parts of the PRY, i.e. the 
PaC-Information AVP. You would need a full security association between 
PRE and PAA to authenticate different messages in both directions.</RCC>
> sending a non-PANA frame to arbitrary non-PANA IPs and ports.
<RCC>The use of a token doesn't enforce (a) but the PRE can check for 
(a) in the scope of PANA as a transport. I agree it does enforce (b) and 
(c). The question is whether the additional effort is worth it on the 
basis that considering a PaC-PAA communication, the IP address and port 
may not be protected either and PANA doesn't require it at the moment.</RCC>
> frames from the PAA that have been authenticated via TLS.
<RCC>Agreed - that's essentially what I meant; perhaps I used the wrong 
language.</RCC>
> to route traffic to the PaC.
<RCC>I agree it is required to prevent rogue PAAs from causing the PRE 
to route traffic. It would seem the debate is about whether we have to 
mandate this for PRE-PAA in general as PANA, as a transport, does not 
require it.</RCC>
> wide-area network, which would seem to be a violation of the PANA
<RCC>That is true. However, I think Alper's point is that an equivalent 
MiTM router on a wider network in the vicinity of the PaC could still be 
the target for a rogue PAA and that the PRE model was really no 
different. So this doesn't necessarily pose an *additional* threat.</RCC>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Dec 2010 11:46:11 +0100

> PRE and PAA to authenticate different messages in both directions.</RCC>

  I'm not sure what "different messages" means.  My goal was to ensure
that rogue PAAs could only send PANA messages to the IP and source port
used by a PaC to send PANA messages.

  I'm not concerned about protecting messages to the PAA.  It's already
on an open network, and anyone on that network can send any content to
any port.  So adding PRE to PAA security is useless.

  i.e. authenticating messages in *both* directions is not the goal of
the token.

> different. So this doesn't necessarily pose an *additional* threat.</RCC>

  If the PaC has access to the wider network before it's authenticated,
then there is no need for any PRE-PAA token.

  If the PaC has access to the wider network before it's authenticated,
then I'm not really sure why PANA is being used at all.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Dec 2010 15:27:37 +0100

Robert Cragie wrote:
> Actually, there is one additional consideration - the PRE has to have
> prior knowledge of the PAA address. It is not stated how this is
> achieved but is state which is stored in the PRE which means not just
> any rogue device can masquerade as the PAA as the PRE would check the
> source address. A rogue PAA would either have to hijack the PRE-PAA
> address resolution phase or somehow obtain the PAA address and spoof it.

  PANA is carried over UDP, right?

  Anyone can trivially spoof UDP packets.  Checking the PAA source IP is
useful, but it adds no security.

  Alan DeKok.

---

From: Robert Cragie <[email-masked]>
Date: Wed, 15 Dec 2010 14:22:34 +0000

Hi Alan,

Some further comments below, bracketed by <RCC></RCC>

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

>    i.e. authenticating messages in *both* directions is not the goal of
<RCC>OK, understood, we are talking about the same thing.</RCC>
> then I'm not really sure why PANA is being used at all.
<RCC>
I was considering the case where the PaC has link-local access to a MiTM 
router which has access to the wider network, not the PaC itself. One of 
the models we considered prior to the relay was one of simply performing 
first-hop access to a router that has access to the PAA. But we 
dismissed this approach for a number of security reasons in favour of 
the relay approach.

</RCC>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 15 Dec 2010 15:45:34 +0000

Agreed, it just makes the attack more complex.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 24 Dec 2010 22:58:45 +0200

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