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

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 17 Mar 2005 18:59:22 +0100

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 10:24:51 -0800

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,

--Gerardo

---

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

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.

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