Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 17 Mar 2005 19:44:28 +0100

> 
> We have two issues here.
> 
> 1) Protecting FBU using a shared secret between the MN and AR
> 2) Reducing re-authentication latency during handovers
> 
> I am thinking of AAA Keys for Handover to address 1) in environments
> where AAA is the default choice. 
>

I was thinking about this point when I posted my message. 
However, the way you handle these keys for handovers (e.g. how you
derive fresh keys) might have impact also in the handover latency.

--Gerardo
 
> 2) needs more consideration, including activities in IEEE and 
> elsewhere. 
> It is a further optimization issue which needs investigation 
> but does not
> need IESG blessing :-)
> 
> -Rajeev
> 
> 
> James Kempf wrote:
> 
> Gerardo and Vijay,
> 
> I agree with Jari that really nothing is needed other than as 
> described in
> handover key draft. But, of course, I'm a co-author on the 
> draft, so you'd
> expect I'd say that. :-)
> 
> That said, I'm willing to take a look at an AAA key 
> mechanism. However,
> before MOBOPTS refers a solution to MIPSHOP, I'd like to be 
> sure that the
> solution has a compelling handover optimization mechanism. 
> This issue is
> actually currently being discussed in 802.11r, and I believe 
> PANA in IETF.
> The proposed solutions I've seen so far involve either having 
> the MN set up
> state with multiple network entities (ARs for this case) using
> preauthentication which requires managing that state  or 
> involve round trips
> back to the AAA-H during the handover window which can make 
> handover slow.
> 
> The advantage of the handover key technique is that it 
> involves one round
> trip to the current AR outside the handover window. In 
> addition, the only
> state involved is on the current AR or perhaps the previous 
> AR, until the MN
> completes handover and gets a new key on the new AR, making 
> managing the key
> much easier. The disadvantage is that address provisioning on 
> the MN is
> constrained to use SEND CGAs.
> 
>             jak
> 
> 
> ----- Original Message ----- 
> From: "Gerardo Giaretta" <[email-masked]>
> To: "Vijay Devarapalli" <[email-masked]>; "Jari Arkko"
> <[email-masked]>
> Cc: "gabriel montenegro" <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 17, 2005 9:59 AM
> Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones
> 
> 
> Hi Vijay and Jari,
> 
>   
> hi Jari,
> 
> Jari Arkko wrote:
> 
>     
> - MN-AR security is a significant issue in current specifications,
> and as such addressing it would be really useful. But I wonder
> about the need to have two different solutions in this space.
> Seems like James' draft would technically work in all scenarios.
> What he said about the IPR sounded positive too (but I am not
> a lawyer nor have I looked at the relevant patents).
>       
> in some networks, where there is access network authentication
> using AAA access, it might make sense to setup keys for securing
> FBU along with access authentication. so, I think we should take
> a look at this solution too.
> 
>     
> 
> I agree with Vijay. I think that in networks where a AAA 
> infrastructure
> is deployed it could be reasonable to exploit this infrastructure and
> the network access authentication to bootstrap other security
> associations (a sort of SSO approach for network services). This has
> been considered for MIP6 bootstrapping, but it could be considered for
> FMIPv6 and HMIPv6 as well.
> 
> --Gerardo
> 
>   
> Vijay
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 
>     
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> 
> ====================================================================
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please send an e_mail to
> [email-masked]. Thank you
> ====================================================================
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
>   
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 17 Mar 2005 10:51:56 -0800

>derive fresh keys) might have impact also in the handover latency.
Right. We have a problem if key derivation slows FMIP. I guess I assumed 
you would
do it off critical-path. This is something that a method must take into 
account.

-Rajeev