Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)

[Robert Cragie <[e-mail]>]

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

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
[phone]
[phone]
http://www.gridmerge.com <http://www.gridmerge.com/>


On 14/12/2010 8:16 PM, Alan DeKok wrote:
> 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.
<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>
>    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.
<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>
>>   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.
<RCC>Agreed - that's essentially what I meant; perhaps I used the wrong 
language.</RCC>
>> 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.
<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>
>    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.
<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>
>    Alan DeKok.
>