Subject: Re: [Pana] pana-relay security considerations

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Jan 2011 12:35:46 +0200

Hi Alan,

>   It looks good.  I'd like to know if the PRE can relay messages from
> the PAA to the PaC on a non-PANA port.  If so, that needs to be
> addressed somehow.  Saying "use DTLS" might not be enough.

The PaC picks an ephemeral port when sending the PANA packet. Src:any, dst:
716. And the response from the PAA reverses the ports. 

The most PRE can do is to check if source port is 716.

If the PRE knows that it received the packet from a trusted source (by means
of DTLS, physical security, IPsec, etc.), then the PRE should not
normally(*) have to perform another level of check on the packets. 

(*) If the PRE cares extra about this, it can start performing DPI on the
packets. I don't think we should specify this in the document though.

> 
>   If the PaC always sends packets from the PANA port, then the text
> should be updated to say that the PAA only sends packets to the PANA
> port on the PaC.

Alper

>   Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Jan 2011 13:16:25 +0200

>   OK.
>   And if not?  Anyone can pretend to be the PAA, and send any data to
> any port on the PaC.  

PRE would authenticate and authorize the other end-point who claims to be a
legit PAA before accepting any packets from it. So, it's not  "anyone".

> If this data MUST be a well-formed PANA packet,
> the security issues are minimal.  But I don't see that requirement
> clearly in the document.

This is the DPI aspect. 

What should we check for well-formation? Many if not all fields in the PANA
header may be updated by future releases of the spec (extensions, etc.). so
checking on them would force the PRE to get upgraded (with a revised version
of PANA-relay spec each time) when PaC/PAA gets upgraded. This is very
undesirable. 

I think we shall stick to relying on PAA-PRE security.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Jan 2011 07:26:42 -0500

Hi Alan,

On Jan 10, 2011, at 7:06 AM, Alan DeKok wrote:
>  Then it should be a MUST.

I originally thought that we needed some form of PRE-PAA security, and  
your comments have, IMO, suggested more reasons why this is needed.

In my opinion, a security mechanism for PRE-PAA authentication needs  
to be defined in this spec before we publish it.  I think it should be  
optional to actually _use_ the security mechanism, though since there  
some situations (such as closed or otherwise secured networks) where  
this type of security isn't required operationally.  The security  
considerations should make it clear what the risks are, and describe  
the situations in which it would be safe not to use the PRE-to-PAA  
security.

Alan, would that satisfy your concerns?  PANA folks, would that meet  
your needs?

Margaret

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Jan 2011 21:59:29 +0200

> >  Then it should be a MUST.

Security considerations section already says so:

	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.

> to be defined in this spec before we publish it.  

Continuing the modeling after DHCP, we could define use of IPsec (same way
RFC 3315 does).

> I think it should be
> this type of security isn't required operationally. 

Indeed.

>  The security

Alper