Subject: Re: [Pana] Issue 58 and issue 74: proposed text

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Apr 2004 15:42:58 -0700

Hi Alper,

Please see my comments below.

On Sun, Mar 21, 2004 at 10:10:55PM -0800, Alper Yegin wrote:
> 
> Here is an attempt to resolve issues 58 and 74.
> 
> Outline of the changes:
> - pointing deployment considerations for this optimization as analyzed
> in the EAP keying framework document.
> - previous PAA is determined based on the new session-ID AVP format.
> - PANA-reauth exchange is replaced by PANA-Bind exchange.
> - Computation of context transferred AAA-key is included in the draft.
> It can be removed if and when the EAP keying framework document
> incorporates it. (note: that draft already describes how this is done
> for proactive optimizations, but not the ones based on context
> transfers)
> 
> Here we go....
> 
> New text for section 4.9:
> 
> 4.9 Mobility Handling
> 
>    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 will 
>    signal PaC's desire to perform the mobility optimization. In the
> absence 
>    of a 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 the previous PAA of
>    the PaC. Current PAA determines the identity of the previous PAA by
>    looking at the DiameterIdentity part of the PANA session identifier.
>    The mechanism required to retrieve the session attributes from the 
>    previous PAA is outside the scope of this protocol. Seamoby Context 
>    Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this
> purpose.

When the PaC changes its attachment points multiple times, the
DiameterIdentity part of the PANA session identifier may not contain
the identity of the *previous* PAA.  Instead it always contains the
identity of the PAA which generated the Session-Id.
                                                                                
> 
>    When the previous or current PAA is not configured to enable fast 
>    re-authentication, 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 previous PAA, the PANA session continues with a PANA-Bind
>    exchange.  
> 
>    The required AAA-Key is provided by the previous PAA to the current
>    PAA. PAA and PaC perform the following computation for generating the
> new
>    AAA-Key: 
> 
>    AAA-Key-new = The first N bits of 
>                  HMAC-SHA1(EMSK(0,63), 
>                            AAA-Key | DiameterIdentity | Session-ID)

There may be two AAA-Keys derived in the case of double
authentication.  In such a case, another derivation algorithm would be
needed (like we have two types of PANA_MAC_KEY derivation algorithms
to deal with issue 52) such as:

     AAA-Key-new = The first N bits of 
                   HMAC-SHA1(EMSK(0,63), 
                             AAA-Key1 | AAA-Key2 | DiameterIdentity | Session-ID)

Yoshihiro Ohba

>                            
> 
>    The value of N depends on the integrity protection algorithm in
>    use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based
>    keys that were made available to previous PAA and PaC as a result of
>    the earlier EAP authentication. Due to the reliance on EMSK, this 
>    optimization only works when PaC has performed an EAP-based 
>    authentication on the previous PAA. DiameterIdentity is the
> identifier of
>    the current PAA. Session-ID is the identifier of the PaC's PANA 
>    session with the previous PAA. New PANA_MAC_Key is computed based on
>    the algorithm described in section 4.1.5, by using the new AAA-Key
> and 
>    the new Session-ID assigned by the current PAA. 
>   
>    The MAC AVP contained in the PANA-Bind messages MUST be
>    generated and verified by using the new PANA_MAC_Key.
>    Session-ID AVP MUST include a new session identifier assigned
>    by the current PAA. A new PANA session is created upon successful 
>    completion of this exchange. 
> 
>    Note that correct operation of this optimization relies on many
> factors,
>    including applicability of authorization state from one network 
>    attachment to another. [I-D.ietf-eap-keying] identifies this
> operation as 
>    "fast handoff" and provides deployment considerations. Operators are 
>    recommended to take those guidelines into account when using this 
>    optimization in their networks. 
>    
> 
> Change section 9.3.7 from:
> 
> 9.3.7 PANA-Bind-Request (PBR)
> 
>    PANA-Bind-Request (PBR) is sent by the PAA to the PaC.
> 
>          PANA-Bind-Request ::= < PANA-Header: 4, REQ >
>                        < Session-Id >
>                        < Device-Id >
>                        { EAP-Payload }
>                        { Result-Code }
>                        [ Session-Lifetime ]
>                        [ Protection-Capability ]
>                        [ Key-Id ]
>                     *  [ EP-Device-Id ]
>                     *  [ AVP ]
>                    0*1 < MAC >
> 
> to:
> 
> 9.3.7 PANA-Bind-Request (PBR)
> 
>    PANA-Bind-Request (PBR) is sent by the PAA to the PaC.
> 
>          PANA-Bind-Request ::= < PANA-Header: 4, REQ >
>                        < Session-Id >
>                        < Device-Id >
>                        [ EAP-Payload ]                    
>                        { Result-Code }
>                        [ Session-Lifetime ]
>                        [ Protection-Capability ]
>                        [ Key-Id ]
>                     *  [ EP-Device-Id ]
>                     *  [ AVP ]
>                    0*1 < MAC >
> 
> 
> Update the AVP occurrence table 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-1 |
>       Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
>       EAP-Payload         | 0-1 | 0-1 |  1  |  1  |  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-1 |
>       Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
>       EAP-Payload         | 0-1 | 0-1 |  1  |  1  | 0-1 |  0  |  0  |
> 
> 
> Alper
> 
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Apr 2004 15:42:58 -0700

Hi Alper,

                                                                                

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 Apr 2004 11:59:21 -0700

> identity of the PAA which generated the Session-Id.

Yes, basically we anchor on the PAA that PaC had performed full
authentication with. PaC can perform re-authentication with a currently
serving PAA to move up the anchor point.

Any issues here?

>                              AAA-Key1 | AAA-Key2 | DiameterIdentity |

OK, I'll add this text too.

Alper

> >                           |        Message
|
> >                           |          Type
|
> >                           |        Message
|
> >                           |          Type
|

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 Apr 2004 11:59:21 -0700

Any issues here?

Alper

|
|
|
|

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Apr 2004 12:29:39 -0700

> serving PAA to move up the anchor point.

Assuming that the context transfer protocol (CTP) is used for
transferring the PANA session information as a transferred context as
well as other context, the previous access router in CTP may be
different from the anchor PAA (even when the PAA is co-located with an
access router) and additional consideration may be needed in CTP.
Assuming that this issue is out of the scope of the PANA
specification, it is ok.  But it might be better to replace the word
"the previous PAA" with "the anchor PAA or the PAA which had generated
the PANA Session-Id for the PaC".
                                                                                
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Apr 2004 12:29:39 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 15:33:03 -0700

I updated the proposed text based on the earlier feedback.

4.9 Mobility Handling

   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.

   When the anchor or current PAA is not configured to enable fast 

   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.  

   The required AAA-Key is provided by the anhcor PAA to the current
   PAA. PAA and PaC perform the following computation for generating the
new
   AAA-Key: 

   In case there are two AAA-Keys generated from a NAP-ISP
authentication,
   the AAA-Key-new computation is:

   AAA-Key-new = The first N bits of 
                 HMAC-SHA1(EMSK(0,63), 
                           AAA-Key1 | AAA-Key2 | DiameterIdentity | 
                           Session-ID)

   The value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based
   keys that were made available to anchor PAA and PaC as a result of
   the earlier EAP authentication. Due to the reliance on EMSK, this 
   optimization only works when PaC has performed an EAP-based 
   authentication on the anchor PAA. DiameterIdentity is the identifier
of
   the current PAA. Session-ID is the identifier of the PaC's PANA 
   session with the anchor PAA. New PANA_MAC_Key is computed based on
   the algorithm described in section 4.1.5, by using the new AAA-Key
and 
   the new Session-ID assigned by the current PAA. 

to:

To:

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 15:33:03 -0700

4.9 Mobility Handling

  

to:

To:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 Apr 2004 20:36:22 -0700

>                            AAA-Key1 | AAA-Key2 | DiameterIdentity | 

In the proposed text, the EMSK needs to be exported to PAA to compute
the AAA-Key-new.  However, this is not consistent with
draft-ietf-eap-keying-01.txt that defines EMSK as:

   Extended Master Session Key (EMSK)
      Additional keying material (64 octets) derived between the EAP
      client and server that is exported by the EAP method.  The EMSK is
      known only to the EAP peer and server and is not provided to a
      third party.
                                                                                
So I think that the AAA-Key-new should be computed by the EAP server
and then transfered to the PAA by using some method that is not
defined in the PANA protocol.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 Apr 2004 20:36:22 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 11:57:58 -0700

Good point. I got this text inspired by the Appendix E of the EAP-keying
draft, but apparently missed this important aspect.

We rather solve this problem without impacting the AAA backend.

How about this?

    AAA-Key-new = The first N bits of
                  HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Monday, April 26, 2004 8:36 PM
> To: Alper Yegin
> Cc: [email-masked]; 'Yoshihiro Ohba'
> Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2)
>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 11:57:58 -0700

How about this?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 15:14:52 -0700

>                   HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)

This means that the two AAA-Keys are not cryptographycally separated 
and thus not recommended in the EAP keying draft.

The purpose of using a non-exposed variable (i.e., EMSK) in the key
computation is to improve security of fast handoff such that
compromising a NAS does not compromise other NASes.  For this reason,
I would suggest using EMSK.  There are some references for how the AAA
backend can distribute fast handoff keys to NASes before a mobile
client performs handoff to the NASes:

Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key
Distribution to support fast and secure roaming", IEEE 802.11 Working
Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January
2003.
                     
draft-irtf-aaaarch-handoff-04.txt

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 15:14:52 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 15:55:32 -0700

> compromising a NAS does not compromise other NASes.  

The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the
AAA-Key-new and delivers to current PAA. In that case, compromise of
current PAA does not lead to compromise of the anchor PAA. 

> For this reason,

Alper

> > > >    PAA. PAA and PaC perform the following computation for
generating
> > the
> > >       client and server that is exported by the EAP method.  The
EMSK
> > is

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 15:55:32 -0700

Alper

generating
EMSK

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 16:42:11 -0700

> current PAA does not lead to compromise of the anchor PAA. 

But if the anchor PAA itself is compromised, other PAAs which receive
the AAA-Key from the anchor PAA will be compromized.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 16:42:11 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 18:16:58 -0700

> the AAA-Key from the anchor PAA will be compromized.

If we consider the roles of the anchor PAA and the current PAA in this
context, I think this is very similar to the roles of AS and
authenticator in EAP terms. These two PAAs are not really peers from
keying perspective, one is like a master to other. Consider how
compromise of AS leads to compromise of the authenticator. Actually,
compromise of MK/MSK does not lead to compromise of TSKs, as the latter
generally uses nonces in computation. So, to converge better, we can
include a cookie delivered by PBR in the AAA-Key-new computation. 

Does this make sense?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 18:16:58 -0700

Does this make sense?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 18:52:22 -0700

> include a cookie delivered by PBR in the AAA-Key-new computation. 

I believe compromise of MK/MSK leads to compromise of TSKs, because
the nonces are not much different from other key computation
parameters such as device-ids in that they are carried in clear text.

Exposing the AAA-Key from AS to the NAS is a necessary break of PFS
(perfect forward secrecy), otherwise, the three-party (client-NAS-AS)
authentication model cannot exit.  My concern is whether this break of
PFS can be a justification of yet another break of PFS, i.e., using
the AAA-Key for AAA-Key-new computation does not provide PFS, which
can be provided by using an existing scheme.

What do you think?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 18:52:22 -0700

What do you think?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 19:40:47 -0700

> parameters such as device-ids in that they are carried in clear text.

Unlike device IDs, the nonces are not carried in any packet. Only  one
round of exchange carries it, and the adversary has to be there at the
right time. This doesn't necessarily make it perfectly secure, but this
is an improvement over using device IDs.

> can be provided by using an existing scheme.

I think this is necessary for a context-transfer based approach. We can
warn the operators about the potential risks of using this optional
optimization. 

By the "existing scheme", are you referring to aaaarch-handoff scheme?
My concern about that approach is its impact on the AAA protocols, which
we are trying to stay away from in PANA design.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 19:40:47 -0700

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Apr 2004 06:56:23 -0700

> warn the operators about the potential risks of using this optional

Yes, that is necessary for context-transfer based approach.  
> By the "existing scheme", are you referring to aaaarch-handoff scheme?

Yes.

> we are trying to stay away from in PANA design.

It seems to me that AAA protocol and context-transfer are equally what
we are trying to stay away from in PANA design.  How much those
outside protocols are complicated is not a PANA problem anyways.

We have identified two schemes to deal with mobility, i.e.,
context-transfer and aaaarch-handoff, and also identified that the two
schemes have differerent keying charactersitics (i.e., non-PFS and
PFS, respectively).

Secure mobility optimization technologies are now developping and I
don't think making PANA mobility optimization work just under non-PFS
is a good idea, while I agree that PANA mobility optimization should
work at least non-PFS, with knowing the security risks.

What do you think?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Apr 2004 06:56:23 -0700

Yes.

What do you think?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Apr 2004 12:15:34 -0700

> outside protocols are complicated is not a PANA problem anyways.

To some extent you are right. But I'm also thinking in terms of ease of
deployment. A CT-based approach only impacts the local access network
which is trying to achieve this optimization. Even a proprietary CT
protocol can be useful in this case. But for the aaaarch-handoff to
work, we have reliance on AAA backends supporting an interoperable
feature. This is why I'm leaning towards the CT-based approach in the
base spec.

> work at least non-PFS, with knowing the security risks.

I think we should keep the CT-based approach in the spec, and
investigate the aaaarch-handoff-based approach. Depending on the
investigation, we can decide whether we fold that approach into the base
spec, or have a separate spec, etc.  

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Apr 2004 12:15:34 -0700

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Apr 2004 13:38:24 -0700

> spec, or have a separate spec, etc.  

I think at least the following things need to be specified in the PANA
specification draft:

  - PANA session attributes are transferred from the anchor PAA to the
  current PAA.

  - AAA-Key-new, or the AAA-Key used between the PaC and the current
  PAA, must be different from the AAA-Key used between the PaC and the
  anchor PAA.

  - PANA session attributes transfer mechanism as well as AAA-Key-new
  derivation/distribution mechanism vary per mobility opmization
  solution in use, but once PANA session attributes are transfered and
  the AAA-Key-new is established, the PANA mobility optimization 
  scheme (i.e., PSR/PSA and PBR/PBA exchanges) works.

I think we can keep the AAA-Key-new derivation algorithm specific to
the CT-based approach in the PANA specification draft until the
investigation is made, but then I would like to keep it in Appendix.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Apr 2004 13:38:24 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Apr 2004 15:32:12 -0700

Yes.

>   PAA, must be different from the AAA-Key used between the PaC and the

Yes. Both of these are already satisfied in the current text.

> investigation is made, but then I would like to keep it in Appendix.

Current design is complete as a CT-based scheme. I don't fully
understand what breaking it apart and moving some part to Appendix serve
here. I think the best is to complete what we started (a CT-based
scheme) that people can implement. And meanwhile consider an
aaarch-handoff-based scheme.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Apr 2004 15:32:12 -0700

Yes.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Apr 2004 16:04:17 -0700

> aaarch-handoff-based scheme.

I just want to make the PANA protocol flexible and less contain
hard-coded part as much as possible.  If the AAA-Key-new derivation
algorithm is going to be included in the main section, I don't
disagree, but it should be described something like:

"When a CT-based scheme is used, the AAA-Key-new is calculated as
follows: ..."

Does this make sense?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Apr 2004 16:04:17 -0700

Does this make sense?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Apr 2004 17:51:18 -0700

> "When a CT-based scheme is used, the AAA-Key-new is calculated as

OK, this makes sense. I'll revise the text.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Apr 2004 17:51:18 -0700

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Apr 2004 13:12:50 -0700

Updated text... Comments please.

[1] New text for section 4.9:

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

   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.

   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-Key1, AAA-Key2, DiameterIdentity | 
                           Session-ID)

   The value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based
   key that was made available to anchor PAA and PaC as a result of
   the earlier EAP authentication. Due to the reliance on the AAA-Key,
this 
   optimization only works when PaC has performed an EAP-based 
   authentication on the anchor PAA. DiameterIdentity is the identifier
of
   the current PAA. Session-ID is the identifier of the PaC's PANA
session 
   with the anchor PAA. New PANA_MAC_Key is computed based on the
algorithm 
   described in Section 4.1.5, by using the new AAA-Key and the new 
   Session-ID assigned by the current PAA. 
  
   The MAC AVP contained in the PANA-Bind messages MUST be generated and

   verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a
new 
   session identifier assigned by the current PAA. A new PANA session is

   created upon successful completion of this exchange. 

[2] Change section 9.3.7 from:

to:

                       [ Nonce]
                    *  [ EP-Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[3] Update the AVP occurrence table from:

To:

[4] Add to references:

[I-D.irtf-aaaarch-handoff] draft-irtf-aaaarch-handoff-04.txt

[5] Add to 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.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Apr 2004 13:12:50 -0700

4.9 Mobility Handling

  

to:

To:

[4] Add to references:

i) Mobility optimization

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 15:53:08 -0700

I am ok with the updated text.

Thanks,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Apr 2004 15:53:08 -0700

Thanks,

Yoshihiro Ohba