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

[Robert Cragie <[e-mail]>]

Hi Alan,

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

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 15/12/2010 10:46 AM, Alan DeKok wrote:
> Robert Cragie wrote:
>>   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;
>
>> <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>
>    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.
<RCC>OK, understood, we are talking about the same thing.</RCC>
>>>    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>
>    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.
<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.

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.
</RCC>
>    Alan DeKok.
>