Subject: [Pana] Issue 8

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Sep 2003 12:34:30 -0700

Please see below for the proposed resolution of Issue #8
http://danforsberg.info:8080/pana-issues/issue8

Comments welcome.

--------

Change Section 4.8 to:

4.8. Session Lifetime

The authentication phase determines the PANA session lifetime when the
network access authorization succeeds. The Session-Lifetime AVP MAY be
optionally included in the PANA-Bind-Request message to inform PaC about the
valid lifetime of the PANA session. It MUST be ignored when included in
other PANA messages. When there are multiple EAP authentication taking
place, this AVP SHOULD be included after the final authentication.

The lifetime is a non-negotiable parameter that can be used by PaC to manage
PANA-related state. PaC does not have to perform any actions when the
lifetime expires, other than optionally purging local state. PAA SHOULD
initiate EAP authentication before the current session lifetime expires.

PaC and PAA MAY optionally rely on lower-layer indications to expedite the
detection of a disconnected peer. Availability and reliability of such
indications depend on the specific access technologies. PANA peer can use
PANA-Reauth-Request message to verify the disconnection before taking an
action.

The session lifetime parameter is not related to the transmission of
PANA-Reauth-Request messages. These messages can be used for asynchronously
verifying the liveness of the peer and enabling mobility optimizations. The
decision to send PANA-Reauth-Request message is taken locally and does not
require coordination between the peers.

Add:

9.4.9. Session-Lifetime AVP

The Session-Lifetime AVP (Code 1032) data is of type Unsigned32. It contains
the number of seconds remaining before the current session is considered
expired.

In section 4.3, change from:

      <-----     PANA-Bind-Request(x+3,y+2)           // F-flag set
                   [EAP{Success}, Device-Id, Protection-Cap., MAC]
      ----->     PANA-Bind-Answer(y+3,x+3)
                   [Device-Id, Protection-Cap., MAC]  // F-flag set

To:

      <-----     PANA-Bind-Request(x+3,y+2)           // F-flag set
                   [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC]
      ----->     PANA-Bind-Answer(y+3,x+3)
                   [Device-Id, Protection-Cap., MAC]  // F-flag set

In section 4.6, change from:

      <-----     PANA-Bind-Request(x+3,y+2)        // F-flag set
                   [EAP, Device-Id, Data-Protection, MAC]
    
      ----->     PANA-Bind-Answer(y+3,x+3)         // F-flag set
                   [Device-Id, Data-Protection, MAC]

To: 

      <-----     PANA-Bind-Request(x+3,y+2)        // F-flag set
                   [EAP{Success}, Device-Id, Lifetime, Data-Protection, MAC]
    
      ----->     PANA-Bind-Answer(y+3,x+3)         // F-flag set
                   [Device-Id, Data-Protection, MAC]

In section 9.3.7, change from:

     PANA-Bind-Request ::= < PANA-Header: 6, REQ, [FIN] >
                    < Session-Id >
                    < Device-Id >
                    { EAP-Payload }
                    { Result-Code }
                    [ Protection-Capability ]
                  * [ AVP ]
                0*1 < MAC >
To:

     PANA-Bind-Request ::= < PANA-Header: 6, REQ, [FIN] >
                    < Session-Id >
                    < Device-Id >
                    { EAP-Payload }
                    { Result-Code }
                    [ Session-Lifetime ]
                    [ Protection-Capability ]
                  * [ AVP ]
                0*1 < MAC >

In section 9.5, change from:

                       +-----------------------------------------+
                       |        Message                          |
                       |          Type                           |
                       +-----+-----+-----+-----+-----+-----+-----+
   Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
   --------------------+-----+-----+-----+-----+-----+-----+-----+
   Result-Code         |  0  |  0  |  0  |  0  |  1  |  0  |  0  |
   Session-Id          |  0  |  0  |  1  |  1  |  1  |  1  |  0  |
   Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
   EAP-Payload         |  0  |  0  |  1  |  1  |  1  |  0  |  0  |
   MAC                 |  0  |  0  | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
   Device-Id           |  0  |  0  |  0  |  0  |  1+ |  1+ | 0-1 |
   Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0  |  0  |
   Protection-Cap.     |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
   --------------------+-----+-----+-----+-----+-----+-----+-----+

To:

                      +-----------------------------------------+
                       |        Message                          |
                       |          Type                           |
                       +-----+-----+-----+-----+-----+-----+-----+
   Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
   --------------------+-----+-----+-----+-----+-----+-----+-----+
   Result-Code         |  0  |  0  |  0  |  0  |  1  |  0  |  0  |
   Session-Id          |  0  |  0  |  1  |  1  |  1  |  1  |  0  |
   Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
   EAP-Payload         |  0  |  0  |  1  |  1  |  1  |  0  |  0  |
   MAC                 |  0  |  0  | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
   Device-Id           |  0  |  0  |  0  |  0  |  1+ |  1+ | 0-1 |
   Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0  |  0  |
   Protection-Cap.     |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
   Session-Lifetime    |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
   --------------------+-----+-----+-----+-----+-----+-----+-----+ 

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Sep 2003 16:16:15 -0700

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

I think the current text is sufficient... EAP-level exchanges are always
initiated by the authenticator/AS by EAP design.

On the other hand, I propose we rely on session id instead of device id in
order to identify a PaC requesting another round of EAP authentication.

Change from:

   When a PaC initiates EAP-based re-authentication, it
   sends a PANA-PAA-Discovery message to the PAA.  If the PAA already
   has an established PANA session for the PaC with a device identifier
   that matches the one extracted from the MAC header and/or IP header
   of the PANA-PAA-Discover message, it sends a PANA-Auth-Request
   message with the session identifier for that PANA session to start
   an authentication phase.  When the PAA initiates EAP-based re-
   authentication, it sends a PANA-Auth-Request message with the
   session identifier for the PaC to enter an authentication phase.

To:

   When a PaC wants to initiate EAP-based re-authentication, it
   sends a unicast PANA-PAA-Discovery message to the PAA. This message MUST
   contain a Session-Id AVP which is used for identifying the PANA session
   on the PAA. If the PAA already has an established PANA session for the
   PaC with the matching identifier, it sends a PANA-Auth-Request
   message containing the same identifier to start an authentication
   phase. If the PAA cannot recognize the session identifier, it proceeds
   with regular authentication by sending back PANA-Start-Request.
   When the PAA initiates EAP-based re-authentication, it sends a
   PANA-Auth-Request message containing the session identifier for the PaC
   to enter an authentication phase.

Comments welcome.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Sep 2003 16:16:15 -0700

Change from:

To:

Comments welcome.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Sep 2003 17:39:24 -0700

New proposed text for section 4.7, for handling issue 5. Comments welcome...
http://danforsberg.info:8080/pana-issues/issue5

4.7 Device ID Choice
    
   A PaC SHOULD configure an IP address before PANA if it can. It might
   either have a pre-configured IP address, or have to obtain one via
   dynamic methods such as DHCP or stateless address autoconfiguration.
   Dynamic methods may or may not succeed depending on the local
   security policy.  In networks where clients have to be authorized
   before they are allowed to obtain an IP address, EPs will detect the
   associated activity and PANA protocol will be engaged before the clients
   can configure a valid IP address.
   
   Either an IP address or a link-layer address should be used as device
   ID at any time. It is assumed that PAA knows the security mechanisms
   being provided or required on the access network (e.g., based on physical
   security, link-layer ciphers enabled before or after PANA, or IPsec).
   When IPsec-based mechanism [PANA-IPSEC] is the choice of access control,
   PAA should provide its IP address as device ID, and expect the PaC to
   provide its IP address in return.  In all other cases, link-layer
   addresses can be provided from both sides.
    
   When IPsec-based access control is used but the PaC is using an
   unspecified IP address in the authentication phase, the device ID
   reported by the PaC MUST be either 0.0.0.0 or 0::0. This device ID MUST
   be recorded as a temporary one by the PAA until the PaC obtains a valid
   one and informs the PAA. Eventually PaC MUST obtain an IP address,
   possibly by relying on the newly-created PANA session [PANA-DHCP], in
   order to gain full access to the network. PaC MUST update the device
   identifier registered on the PAA from unspecified to the valid IP address
   by initiating a PANA-Reauth-Request/PANA-Reauth-Answer exchange in
   which the IP address of the PaC is contained in the Device-Id AVP.

References:

[PANA-IPSEC] M. Parthasarathy: "Securing the first hop in PANA using IPsec,"
Internet Draft, Internet Engineering Task Force, May 2003, Work in
progress. 

[PANA-DHCP] H. Tschofenig, A. Yegin, D. Forsberg: "Bootstrapping RFC3118
Delayed authentication using PANA," Internet Draft, Internet Engineering
Task Force, June 2003, Work in progress.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Sep 2003 17:39:24 -0700

4.7 Device ID Choice

    

References: