Subject: [Pana] PANA-IPSEC draft ?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 6 Oct 2003 10:07:01 -0700

Hello,

draft-ietf-pana-ipsec-00.txt should have addressed most of the issues since
the last time.
I had problems accessing the archives sometime back. So, i am not sure this
addresses
all of the concerns. At least the major ones are taken care of. So, please
send me your
comments on the list.

thanks
-mohan

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Oct 2003 21:30:04 -0700

From PANA-IPsec draft:

3.0 Pre-requisites for IPsec SA establisment
  
   This document assumes that the following have already happened before
   the IPSEC SA is established.
     
     1) PANA client (PaC) learns the IP address of the Enforcement point
        (EP) during the PANA exchange.

Currently we don't have this feature in PANA. I think we can handle this by:

- Having an AVP for carrying the DI of EP(s). We can add a new field (or
flag?) to current device-ID AVP to indicate whether it belongs to PAA or one
of the EPs.
- This AVP MUST be included in PANA-Bind-Request when L2 or L3 ciphering
will be enabled after PANA. There may be more than one such AVP at a time
(for multiple access routers, for example).
- The address type in this AVP MUST match the ciphering type.

Comments?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Oct 2003 21:30:04 -0700

From PANA-IPsec draft:

     

Comments?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Oct 2003 22:49:15 -0700

http://danforsberg.info:8080/pana-issues/issue32

Proposed text changes are below... Comments welcome.

From:

   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.

To:

   Since PAA and PaC are supposed to be one IP hop away, a simple
   TTL check can prevent off-link attacks. Furthermore, additional
   filtering can be enabled on the EPs. An EP may be able to filter
   unauthorized PAA advertisements when they are received on the
   access side of the network where only PaCs are connected.

From:

   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 authentication server on the PAA.

From:

   For further discussion about the
   importance of the session key generation refer to the next
   subsection (c) about compound authentication.

To:

   For further discussion about the
   importance of the session key generation refer to the next
   subsection (d) about compound authentication.

From:

   For the current version of the document an Integrity
   object is defined which is based on Diameter objects. The Integrity
   Object supports data-origin authentication, replay protection based
   on sequence numbers and integrity protection based on a keyed
   message digest. Confidentiality protection is not provided. The
   session keys (one for each direction) used for this object has to be
   provided by the EAP method.

To:

   For the current version of the document an itegrity object (MAC AVP) is
   defined which supports data-origin authentication, replay protection
   based on sequence numbers and integrity protection based on a keyed
   message digest. Confidentiality protection is not provided. The
   session keys used for this object have to be provided by the EAP method.

From:

   Instead HMAC-SHA1 is used per-default.

To:

   Instead HMAC-SHA1 is used by default.

From:

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

To:

   To select the 
   security association for signaling message protection the Session
   ID is conveyed

From:

   If an entity (PAA or PaC) looses its state (especially the current
   sequence number) then the entire PANA protocol has to be restarted.

To:

   If an entity (PAA or PaC) loses its state (especially the current
   sequence number) then the entire PANA protocol has to be restarted.

From:

   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.

To:

   The lifetime of the PANA SA has to be bound to 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.

From:

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

To:

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

Add to references:

   [PANA-IPSEC] M. Parthasarathy: "PANA enabling IPsec based Access
   Control," Internet Draft, Internet Engineering Task Force, October 2003.
   Work in progress.

From:

   Network access authentication is done for a very specific purpose
   and often charging procedures are involved which allow restricting
   network resource usage based on some policies. In mobility
   environments it is always possible that an end host suddenly
   disconnects without transmitting a disconnect message. 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.
    
   Also for the network operator it might be desirable to enforce a
   disconnect based on some external events (e.g. because of
   insufficient funds, etc.).
    
   An additional motivation for detecting a disconnected end host is
   the ability to release resources (i.e. garbage collection). The PAA
   can remove per-session state information including installed
   security association, packet filters etc.

To:

   Network access authentication is done for a very specific purpose
   and often charging procedures are involved which allow restricting
   network resource usage based on some policies. In mobility
   environments it is always possible that an end host suddenly
   disconnects without transmitting a disconnect message. Operators
   are generally motivated to detect a disconnected end host as soon
   as possible in order to release resources (i.e., garbage collection).
   The PAA  can remove per-session state information including installed
   security association, packet filters, etc.

From:

   h) Periodic refresh messages

   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]).
    
   From a security point of view an adversary must not be able to
   inject, modify or replay refresh messages nor must he be able to
   change the refresh interval (e.g. setting it to zero) without
   detection. Hence these messages experience cryptographic protection.

To:

   h) Liveness test
    
   Network access authentication is done for a very specific purpose
   and often charging procedures are involved which allow restricting
   network resource usage based on some policies. In mobility
   environments it is always possible that an end host suddenly
   disconnects without transmitting a disconnect message. Operators
   are generally motivated to detect a disconnected end host as soon
   as possible in order to release resources (i.e., garbage collection).
   The PAA can remove per-session state information including installed
   security association, packet filters, etc.

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Oct 2003 22:49:15 -0700

From:

To:

From:

   Hence an 

To:

   Hence an 

From:

To:

From:

To:

From:

To:

From:

   To select the 

To:

   To select the 

From:

To:

From:

To:

From:

   Furthermore, a 

To:

   Furthermore, a 

Add to references:

From:

    

To:

From:

    

To:

   h) Liveness test

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 7 Oct 2003 10:06:38 -0700

> - The address type in this AVP MUST match the ciphering type.
Sounds okay.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Oct 2003 10:59:04 -0700

The new text looks good, except that there is some duplicate text in
section h).

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Oct 2003 10:59:04 -0700

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 7 Oct 2003 10:06:38 -0700

Sounds okay.

-mohan