Subject: RE: [Pana] [issue32] PANA Security considerations

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 23 Oct 2003 11:59:42 +0200

hi dan, 
hi alper, 

thanks for talking a look at the security consideration section. 
please see my comments inline:

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

this is true for the current draft. however, adding the functionality
described in issue
12 this is not possible anymore. 

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

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

i agree with you (since the 4-way handshake described in ieee 802.11i) does
not use separate keys for each direction either. 

however, we have to insure that reflection attacks are not possible. we have
to add some text on this issue somewhere. 

> 
> "per-default" -> "by default"
> 
> To select the security association for signaling message 
> protection the
> Session ID.
> 
> This sentence seems unfinished.

that's more than true. 

how about: 
"To select the security association for signaling message protection the
Session 
ID is used."

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

ok - sounds like a good idea to keep these things separate. 

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

ok. 

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

you are right. we should be more precise here. 

how about: 

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 unless physical layer or
crypto-based per-packet protection is provided. 

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

true. this is old text. 

ciao
hannes

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

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