Subject: [Pana] Issue 94 and 95 - proposed text

From: Alper Yegin <[email-masked]>
Date: Thu, 19 Aug 2004 12:38:35 -0700

Here is the new proposed text for the security considerations section to
handle issues 94 and 95.

Comments welcome.

9.  Security Considerations

   The PANA protocol defines a UDP-based EAP encapsulation that runs 
   between two IP-enabled nodes on the same IP link. Various security
   threats that are relevant to a protocol of this nature are outlined
   in [I-D.ietf-pana-threats-eval]. Security considerations stemming
   from the use of EAP and EAP methods are discussed in [RFC3748].
   This section provides a discussion on the security-related issues
   that are related to PANA framework and protocol design.

   An important element in assessing security of PANA design and
   deployment in a network is the presence of lower-layer (physical and
   link-layer) security. In the context of this document, lower-layers 
   are said to be secure if they can prevent eavesdropping and spoofing
of
   packets. Examples of such networks are physically-secured DSL
networks 
   and 3GPP2 networks with crytographically-secured cdma2000 link-layer.

   In these examples, the lower-layer security is enabled even before 
   running the first PANA-based authentication. In the absence of such a

   pre-established secure channel, one needs to be created in
conjunction 
   with PANA using a link-layer or network-layer cryptographic 
   mechanism (e.g., IPsec). 

9.1. General security measures 

   PANA provides multiple mechanisms to secure a PANA session.

   Since PaC and PAA are on the same IP link, a simple TTL check on
   the received PANA messages prevents off-link attacks.

   PANA messages carry both a transmission sequence number and 
   an acknowledgement of the received sequence number. These numbers
   are randomly initialized at the beginning of the session, and
   verified against expected numbers upon receipt. A message whose
   sequence numbers fall outside of the expected range are silently
   discarded. In addition to accomplishing orderly delivery of EAP
messages 
   and duplicate elimination, this scheme also helps prevent an
adversary 
   spoof messages to disturb ongoing PANA and EAP sessions unless it can

   also eavesdrop to synchronize on the sequence numbers. 

   The PANA framework defines EP which is ideally located on a
   network device that can filter traffic from the PaCs
   before the traffic enters the intranet. A set of filters can be used
to
   discard unauthorized packets, such as a PANA-Start-Request message
   that is received from the segment of the access network where only
   PaCs are supposed to be connected.

   The protocol also provides authentication and integrity protection to
   PANA messages when the used EAP method can generate cryptographic 
   session keys. PANA SA is generated based on the AAA-Key exported by
the 
   EAP method. This SA is used for generating per-packet MAC to protect
the 
   PANA header and payload (including the complete EAP message).  The 
   cryptographic protection prevents an adversary from acting as a 
   man-in-the-middle, injecting messages, replaying messages and
modifying 
   the content of the exchanged messages. Any packet that fails to pass
the
   MAC verification is silently discarded. The earliest this protection
can
   be enabled is when the very first PANA-Bind-Request that signals a
   successful authentication is generated. Starting with the 
   PANA-Bind-Request and PANA-Bind-Answer, any subsequent PANA message 
   until the session gets torn down can be cryptographically protected. 

   PANA SA enables authenticated and integrity protected exchange of
   the device ID information between the PaC and PAA. This ensures there
   were no man-in-the-middle during the PANA authentication.

   The lifetime of the PANA SA is bounded by the AAA-authorized
   session lifetime with an additional tolerance period.  Unless PANA
   state is updated by executing another EAP authentication, PANA SA is
   removed when the current session expires.  

   The ability to use cryptographic protection within PANA is determined
   by the used EAP method, which is generally dictated by the deployment
   environment. Unsecure lower-layers necessitate use of key-generating
   EAP methods. In networks where lower-layers are already secured, 
   cryprographic protection of PANA messages is not necessary. 

9.2. Discovery

   The initial discovery phase is vulnerable to spoofing attacks as
   these messages are not authenticated and integrity protected. In
order
   to prevent very basic denial-of service attacks an adversary should
not 
   be able to cause state creation by sending discovery messages to the 
   PAA. This protection is achieved by using a cookie-based scheme
(similar 
   to [RFC2522]) which allows the responder (PAA) to be stateless in the

   first round of message exchange. A return-routability test does not
   provide additional protection as PANA traffic is not routed but
   simply forwarded on-link. It is difficult to prevent this
   threat entirely.  

   In networks where lower-layers are not secured prior to running PANA,
   the capability discovery enabled through inclusion of
   Protection-Capability and Post-PANA-Address-Configuration AVPs in
   PANA-Start-Request message is susceptible to spoofing leading to 
   denial-of service attacks.  Therefore, usage of these AVPs during the

   discovery phase in such insecure networks is NOT RECOMMENDED.  The
same 
   AVPs are delivered via an integrity-protected PANA-Bind-Request upon 
   successful authentication.

9.3. EAP methods

   Eavesdropping EAP packets might cause problems when the EAP
   method is weak and enables dictionary or replay attacks or even
   allows an adversary to learn the long-term password directly.
   Furthermore, if the optional EAP Identity payload is used then it
   allows the adversary to learn the identity of the PaC.  In such a
   case a privacy problem is prevalent.

   To prevent these threats, [I-D.ietf-pana-framework] suggests using
   proper EAP methods for particular environments.  Depending on the
   deployment environment an EAP authentication which supports user 
   identity confidentiality, protection against dictionary attacks and 
   session key establishment must be used. It is therefore
   the responsibility of the network operators and users to choose
   a proper EAP method.

9.4. Separate NAP-ISP authentication

   PANA design allows running two separate EAP methods for the same
   PaC: one with the NAP, and one with the ISP. The process of arriving
at 
   the resultant authorization, which is a combination of the individual
   authorizations obtained from respective service providers, is outside
   the scope of this protocol. In the absence of lower-layer security, 
   both authentications MUST be able to generate a AAA-Key, leading to 
   generation of PANA SA. The resultant PANA SA cryptographically binds
   the two AAA-Keys together, hence it prevents man-in-the-middle
attacks.

9.5. Cryptographic keys

   When the EAP method exports a AAA-Key, this key is used to produce a 
   PANA SA with PANA_MAC_KEY with a distinct key ID. PANA_MAC_KEY is
unique 
   to the PANA session, and takes PANA-based nonce values into
computation 
   to cryptographically separate itself from the AAA-Key.

   PANA_MAC_KEY is solely used for authentication and integrity
protection
   of the PANA messages within the designated session.

   Two AAA-keys may be generated as a result of separate NAP and ISP 
   authentication. In that case, the AAA-key used with the PANA SA is
the
   combination of both keys. 

   The PANA SA lifetime is bounded by the AAA-Key lifetime. Another 
   execution of EAP method yields in a new AAA-Key, and updates 
   the PANA SA, PANA_MAC_KEY and key ID.

   Upon PaC's movement to a another PAA (new PAA) and request to perform
   a context transfer based optimization, the current PAA computes a
   AAA-key-int based on the AAA-Key, ID of new PAA, and the session ID. 
   This AAA-key-int is delivered to the new PAA, and used in the
   computation of AAA-key-new, which further takes a pair of nonce
values 
   into account. After this point on, the AAA-key-new becomes the
AAA-key
   between the PaC and the new PAA.

   When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is 
   enabled as a result of successful PANA authentication, a separate
master 
   key is generated based on the AAA-Key, session ID, key ID, and EP ID.

   The lifetime of this key is bounded by the lifetime of the PANA SA.
This 
   key may be used with a secure association protocol 
   [I-D.ietf-ipsec-ikev2] to produce further cipher-specific and
transient 
   keys. 

9.6. Per-packet ciphering

   Networks that are not secured at the lower-layers prior to running  
   PANA can rely on enabling per-packet data traffic ciphering upon
   successful PANA session establishment. The PANA framework allows 
   generation of a master key from AAA-key for using with a per-packet 
   protection mechanism, such as link-layer or IPsec-based
   ciphering [I-D.ietf-pana-ipsec]. In case the master key is not
readily 
   useful to the ciphering mechanism, an additional secure association 
   protocol [I-D.ietf-ipsec-ikev2] may be needed to produce the required

   keying material. These mechanisms ultimately establish a
cryptographic 
   binding between the data traffic generated by and for a client and
the 
   authenticated identity of the client. Data traffic must be minimally 
   data origin authenticated, replay and integrity protected, and 
   optionally encrypted.

9.7. PAA-to-EP communication

   The PANA framework allows separation of PAA from EP(s). SNMPv3 
   [I-D.ietf-pana-snmp] is used between the the PAA and EP for
   provisioning authorized PaC information on the EP. This exchange MUST
be
   always physically or cryptographically protected for authentication,
   integrity and replay protection. It MUST also be privacy-protected
   when per-PaC master key for per-packet ciphering is transmitted to
the
   EP.

   The per-packet ciphering master key MUST be unique to the PaC and EP 
   pair. The session ID and EP's device ID are taken into computation
for 
   achieving this effect [I-D.ietf-pana-ipsec]. Compromise of an EP does

   not automatically lead to compromise of another EP or the PAA.

9.8. Livenes test         

   A PANA session is associated with a session lifetime.  The session is
   terminated unless it is refreshed by a new round of EAP
   authentication before it expires.  Therefore, at the latest a
   disconnected client can be detected when its lifetime expires.  A
   disconnect may also be detected earlier by using PANA
   reauthentication messages.  A request message can be generated by
   either PaC or PAA at any time and the peer must respond with an
   answer message.  A successful round-trip of this exchange is a simple
   verification that the peer is alive.  This test can be engaged when
   there is a possibility that the peer might have disconnected (e.g.,
   after discontinuation of data traffic).  Periodic use of this
   exchange as a keep-alive requires additional care as it might result
   in congestion and hence false alarms.  This exchange is
   cryptographically protected when PANA SA is available in order to
   prevent threats associated with the abuse of this functionality.

9.9. Mobility optimization

   The mobility optimization described in Section 4.12 involves the
   previous PAA providing a AAA-Key to the current PAA of the PaC.
   There are security risks stemming from potential compromise of PAAs.
   Compromise of the current PAA does not yield compromise of the
   previous PAA, as AAA-Key cannot be computed from a compromised
   AAA-Key-new.  But a compromised previous PAA along with the
   intercepted nonce values on the current link leads to the 
   compromise of AAA-Key-new. Operators should be aware of the potential

   risk of using this optimization.  An operator can reduce the risk 
   exposure by forcing the PaC to perform an EAP-based authentication 
   immediately after the PaC gains access to new link via the optimized
PANA 
   execution.

9.10. Updating PaC's IP address

   Even though the IP-Address AVP in a PANA-update-Request can be
   cryptographically protected by the MAC AVP, there is not way to
   prove the ownership of the IP address presented by the PaC. Hence
   an authorized PaC can launch a redirect attack by spoofing a victim's
   IP address. 

9.11. Early termination of a session

   The PANA protocol supports the ability for both the PaC and the PAA
   to transmit a tear-down message before the session lifetime expires.

   This message causes state removal, a stop of the accounting procedure

   and removes the installed per-PaC state on the EP(s). This message is

   cryptographically protected when PANA SA is present.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 20 Sep 2004 11:18:20 -0400

Hi Alper,

The text looks very nice.  Maybe "PANA reauthentication messages" in
section 9.8 is replaced with "PANA ping messages".

Yoshihro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 23 Aug 2004 11:39:43 -0700

> section 9.8 is replaced with "PANA ping messages".

Thanks for catching this. I fixed it now.

9.2. Discovery

9.3. EAP Methods

9.5. Cryptographic keys

9.8. Livenes test         

   ping messages.  A request message can be generated by