Subject: RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 21 Jul 2005 14:21:07 -0500

> 
> > In fact, one of the things that will be a problem for us if
> > HK derivation is made dependent on the EAP method is 802.11r - 
> > if 11r is adopted as being proposed now with evolving keys, 
> > the MN will not perform a full EAP method upon handoff - as 
> > long as it is handing off under the same R0 entity, it will 
> > only change its PMK-R1/PMK-R2 - hence, the exchange will 
> > not reach the AAA server. So, unless the HK itself evolves 
> > the same way (which means we now rely on a hierarchy of ARs, 
> > with SAs between them, etc.) or we make an assumption that 
> > PMK-R0 will always change upon inter-subnet handoffs, it 
> > becomes a problem for us. So, I am not entirely sure how 
> > we can make L3 handover keys applicable for heterogeneous 
> > L2 handoffs (whether L2 employs 802.11i/PANA/802.11r/etc) if 
> > the L3 HKs are dependent on L2 authentication. 
> > 
> 
> Creating a shared secret between MN and PAR can be done
> assuming some L2 access (or L3 in the SEND-based handover
> key derivation draft) authentication method is used, right?
> This should be the focus of the draft IMO.

As long as the shared secret between MN and PAR is not piggybacked on L2 access authentication, this is true, right? If we were to tightly couple it to L2 access authentication, such independence does not seem to be available. The current protocol makes the creation of shared secret between MN and PAR be totally independent of the type of L2 access. 

> 
> Assuming so, which L3 handover key are you referring to that
> would be needed across different L2 access types?
> If a MN did .11i, created a shared secret (Sk-L3) for L3 to use,
> moved over to a different L2, and then did method auth-Y, why
> is the applicability of Sk-L3 on the new L2 important during
> a handover?
> 

I am confused by this. The L3 handover key I am referring to is the shared secret between MN and AR. If we extended an EAP method to derive this key, when the EAP authenticator is not the same as the AR, we have some issues in getting the key to the AR without breaking some of the Housley criteria. It is not that we need a new key as a result of a new L2 auth method, but it is the process of deriving a key with the next AR may now need to be different, due to the 

> -Rajeev
> 
> 
> 
> > 
> > 
> >>One of the key design goals in FMIP has been to disengage
> >>all other signaling (e.g., RR, BU, DHCP in fmipv4) from
> >>the critical path. We should try to preserve that as we
> >>move along.
> >>
> > 
> > 
> > Yes, we had this goal as well in designing the protocol. If 
> you look at the 5th bullet in section 1.1, it states this as 
> one of the design goals. 
> > 
> > Regards,
> > Vidya
> > 
> > 
> > 
> >>-Rajeev
> >>
> >>
> >>
> >>
> >>>AAA server does not send any keys unsolicited to an entity 
> >>
> >>from which
> >>
> >>>it hasn't received any messages - isn't it?  
> >>>
> >>>_______________________________________________
> >>>Mipshop mailing list
> >>>[email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
> >>
> > 
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Jul 2005 12:45:39 -0700

Narayanan Vidya-CVN065 wrote:

> 
> I am confused by this. The L3 handover key I am referring to is 
> the shared secret between MN and AR. If we extended an EAP method 
> to derive this key, when the EAP authenticator is not the same as 
> the AR, we have some issues in getting the key to the AR without 
> breaking some of the Housley criteria. It is not that we need a 
> new key as a result of a new L2 auth method, but it is the process 
> of deriving a key with the next AR may now need to be different, due to the 

Perhaps you meant to say something more..

Okay. I guess we need to solve this so that it can also work
for EAP. And, a constraint is not to derive these keys during
a handover, which I guess is already being addressed.

I see your point about coupling L3 key derivation tightly to
L2 authentication. And, I agree that the process needs to be
applicable across different L2 access types. It would be good
to discuss the pros and cons.

-Rajeev

> Mobopts mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Jul 2005 08:03:10 -0700

> I am confused by this. The L3 handover key I am referring to is the shared
secret between MN and AR. If we extended an EAP method to derive this key,
when the EAP authenticator is not the same as the AR, we have some issues in
getting the key to the AR without breaking some of the Housley criteria. It
is not that we need a new key as a result of a new L2 auth method, but it is
the process of deriving a key with the next AR may now need to be different,
due to the

Suppose that the AAA server pushes the key directly to the AR using some
protocol. That means the AAA server and the AR need to share an end-to-end
security association, that the key must be encrypted in transit, and only
the AR can decrypt.

Now, suppose that, instead of routing the key directly to the AR, it is
routed through the NAS instead. If the key is end-to-end encrypted, how does
that violate the Housley critera? The NAS is acting like a proxy AAA server
and doesn't ever get to look at the key.

Am I missing something?

            jak