Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 3)

From: Julien Bournelle <[email-masked]>
Date: Mon, 3 May 2004 10:42:20 +0200

Hi,

    I have two comments concerning added text:

    please see inline,

On Fri, Apr 30, 2004 at 01:12:50PM -0700, Alper Yegin wrote:
> 4.9 Mobility Handling
> 
>    A mobile PaC's AAA performance can be enhanced by deploying a 
>    context-transfer-based mechanism, where some session attributes are 
>    transferred from a previous PAA to the current one in order to avoid 
>    performing a full EAP authentication (reactive approach). Additional 
>    mechanisms that are based on the proactive AAA state establishment at
> 
>    one or more candidate PAAs may be developed in the future 
>    [I-D.irtf-aaaarch-handoff]. The details of a context-transfer-based 
>    mechanism is provided in this section.
> 
>    Upon changing its point of attachment, a PaC that wants to quickly
> resume 
>    its ongoing PANA session without running EAP MAY send the unexpired
>    PANA session identifier in its PANA-Start-Answer message. This action
> 
>    signals PaC's desire to perform the mobility optimization. In 
>    the absence of Session-Id AVP in this message, PANA session 
>    takes its usual course (i.e., EAP-based authentication is performed).
> 
>    If PAA receives a session identifier in the PANA-Start-Answer
>    message, and it is configured to enable fast re-authentication, it
>    SHOULD retrieve the PANA session attributes from a previous (anchor)
>    PAA that has an unexpired PANA session with the PaC. Current PAA
>    determines the identity of the anchor PAA by looking at the
>    DiameterIdentity part of the PANA session identifier. The mechanism 
>    required to retrieve the session attributes from the anchor PAA is
>    outside the scope of this protocol. Seamoby Context Transfer Protocol
> 
>    [I-D.ietf-seamoby-ctp] might be useful for this purpose.

As the PaC does not give its previous Device-Identifier, the anchor PAA
won't be able to retrieve the PANA context.

> 
>    When the anchor or current PAA is not configured to enable this 
>    optimization, the current PAA can not retrieve the PANA session 
>    attributes, or the PANA session has already expired (i.e., session 
>    lifetime is zero), the PAA MUST send the PANA-Auth-Request message
> with 
>    the new session identifier and let the PANA exchange take its usual 
>    course. This action will engage EAP-based authentication and create a
>    fresh PANA session from scratch.
> 
>    In case the current PAA can retrieve the on-going PANA session
> attributes
>    from the anchor PAA, the PANA session continues with a PANA-Bind
>    exchange. 
> 
>    A new AAA-Key is provided by the anchor PAA to the current PAA. The 
>    anchor PAA and PaC perform the following computation for generating
> the 
>    new AAA-Key: 
> 
>    AAA-Key-new = The first N bits of 
>                  HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)

if an attacker is able to get this AAA-Key, (s)he will be able to
compute this new key. 

-- 
[email-masked]

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

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 3 May 2004 10:42:20 +0200

Hi,

    please see inline,

---

From: Alper Yegin <[email-masked]>
Date: Mon, 03 May 2004 11:38:31 -0700

Hi Julien,

> won't be able to retrieve the PANA context.

The PANA session identifier is sufficient to retrieve all the parameters
associated with the session. The CT protocol should carry the session id
to the anchor PAA. Note that this is the session between the PaC and the
anchor PAA.

> if an attacker is able to get this AAA-Key, (s)he will be able to

That's true. We address this issue in the security considerations
section. 

i) Mobility optimization

The mobility optimization described in Section 4.9 involves an anchor
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 anchor PAA, as AAA-Key cannot be
computed 
from a compromised AAA-Key-new. But a compromised anchor PAA 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 
optimized PANA execution.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 03 May 2004 11:38:31 -0700

Hi Julien,

i) Mobility optimization

Alper