Subject: [Pana] [issue32] PANA Security considerations

From: [email-masked]
Date: Tue, 30 Sep 2003 15:46:08 +0300

New submission from Dan Forsberg <[email-masked]>:

From/through Alper Yegin:
-------------------------

I have some editorial and technical comments on the security
considerations section of the current PANA draft.

- a) Discovery message exchange
...
   Since PAA and PaC are one IP hop away from each other, PANA messages
   can be filtered whenever messages arrive at interfaces where they
   are not expected.

We should expand on this. Proposed addition "For example, EP may drop
PANA-Start-Request messages when they are received from access side of
the network where only PaCs can connect."

- b) EAP over PANA message exchange

Change:

   Hence an 
   adversary can both eavesdrop the EAP messages and is also able to
   inject arbitrary messages which might confuse both the PaC and the
   PAA. 

To:

   Hence an 
   adversary can both eavesdrop the EAP messages and is also able to
   inject arbitrary messages which might confuse both the EAP peer on PaC
   and the EAP authenticator or the authentication server on the PAA.

- c) PANA SA establishment

"subsection (c)" -> "subsection (d)"

"Integrity Object" -> "MAC AVP"

The session keys (one for each direction) used for this object has to be
provided by the EAP method.

We don't really require that the session keys are unidirectional.

"per-default" -> "by default"

To select the security association for signaling message protection the
Session ID.

This sentence seems unfinished.

"looses" -> "loses"

   The lifetime of the PANA SA has to be bound to the refresh interval
   with an additional tolerance period. To provide fast re-
   authentication a separate security association (e.g. one stored at
   the local AAA server) should be used. By fast re-authentication we
   mean a new PANA protocol execution which does not involve the entire
   AAA communication. The ability to trigger such a protocol execution
   depends on the given EAP method and on the policy of the local
   network requesting authentication.

This paragraph is talking about couple of things. I suggest we don't get
into EAP-based fast reauth schemes in here (after all it should be all
transparent to PANA). Instead we can say this:

   The lifetime of the PANA SA has to be bound to the refresh interval
   with an additional tolerance period. Unless PANA state is updated by
   executing EAP authentication, PANA SA is removed when the current
   session lifetime expires.
  
g) Triggering a data protection protocol

   Furthermore, a derived session key might help to create the
   pre-requisites for network layer protection (for example IPsec).

Let's add reference to PANA-IPsec draft here.

h) Periodic refresh messages

   If network 
   access authentication as part of PANA is executed only at the
   beginning then an adversary can gain advantage of the installed
   packet filters to submit and receive data packets.

This is not accurate. Because, one would either rely on physical
security, or use crypto-based per-packet protection to prevent this
possibility.

   Different procedures can be used for disconnect indication. PANA
   cannot assume link layer disconnect indication. Hence this
   functionality has to be provided at a higher layer. With this
   version of the draft we suggest to apply the soft-state principle
   found at other protocols (such as RSVP). Soft-state means that
   session state is kept alive as long as refresh messages refresh the
   state. If no new refresh messages are provided then the state
   automatically times out and resources are released. This process
   includes stopping accounting procedures.
    
   Based on the different environments where PANA could be used it is
   difficult to fix a refresh interval. Hence a default refresh
   interval of 30 seconds is suggested. Additionally there is the
   possibility to negotiation this interval once the PANA security
   association is established. A policy at the PAA and the PaC would
   ensure that the refresh interval is selected with a value which is
   either too high or too low. There is certainly a tradeoff between
   the refresh interval and the bandwidth consumption. To reduce the
   bandwidth consumption a small PANA message consisting only of a
   session identifier and the Integrity object is used. The session
   identifier refers to the state that has to be refreshed. Some
   environments do not need PANA refresh messages to detect orphan
   states. For these environments the refresh interval should be set to
   zero which effectively disables the usage of refresh messages. In
   case of IPsec protection a dead-peer mechanism can be used to detect
   inactivity (see [HBR03]).
    
   Refresh messages are sent from the PaC to the PAA.

This text is not aligned with the latest discussions. I presume it is
referring to PANA-reauth as the refresh message... but we don't really
suggest using periodic re-auth messages in the specification. There is
only a PANA session lifetime, and that is not negotiated. We had a
lengthy discussion on that.

----------
category: Technical
document: draft-ietf-pana-pana-xx.txt
messages: 94
nosy: dforsber
priority: Must Fix
status: No Discussion
title: PANA Security considerations
________________________________________________
PANA Issues <[email-masked]>
http://danforsberg.info:8080/pana-issues/issue32
________________________________________________

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana