Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)
From: Alan DeKok <[email-masked]>
To: [email-masked]
Cc: 'Yoshihiro Ohba' <[email-masked]>, [email-masked], [email-masked], Alper Yegin <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], 'Ralph Droms' <[email-masked]>
Date: Wed, 15 Dec 2010 11:46:11 +0100
List-Id: Security Area Directorate <secdir.ietf.org>

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.

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

  Alan DeKok.