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

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Jan 2011 13:54:53 +0100

Alper Yegin wrote:
> 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.

  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.

  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.

  Alan DeKok.

---

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

Hi Alan,

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

> should be updated to say that the PAA only sends packets to the PANA

Alper

---

From: Alan DeKok <[email-masked]>
Date: Mon, 10 Jan 2011 12:02:42 +0100

> 716. And the response from the PAA reverses the ports. 

  OK.

> normally(*) have to perform another level of check on the packets. 

  And if not?  Anyone can pretend to be the PAA, and send any data to
any port on the PaC.  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.

  Alan DeKok.

---

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

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

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: Alan DeKok <[email-masked]>
Date: Mon, 10 Jan 2011 13:06:52 +0100

> legit PAA before accepting any packets from it. So, it's not  "anyone".

  Only when a secure transport is used.  When a secure transport is not
used, the PAA to PRE is just UDP, which is spoofable.

>> the security issues are minimal.  But I don't see that requirement

  The PRE can't verify that it's sending a valid PANA packet to the PaC?

> of PANA-relay spec each time) when PaC/PAA gets upgraded. This is very

  Some basic level of checks should be possible.

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

  Then it should be a MUST.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 10 Jan 2011 14:25:49 +0100

Margaret Wasserman wrote:
> 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?

  That would satisfy my concerns, yes.

  Alan DeKok.

---

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

Hi Alan,

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

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