RE: Justificationsforstandardizingdraft-ietf-mip6-auth-protocol-00.txt

 > >=> Sure, but there are ways of achieving that, some of which
 > >were discussed in the EAP WG. For example:
 > >- PP2 as a system can decide on things like the lifetime of the
 > >SA and encryption algorithm for all MNs. This is what 3GPP did
 > >for SIP and it's fine to do that, or, 
 > 
 > I guess you are refering to RFC3329 which is used by 3GPP for setting
 > up the SA between the UE and SIP Proxy. However in that case, the SIP
 > signaling is negotiating the parameters for the SA and at least the
 > number of RTs (looking at the message sequence flows) is not
 > optimal. 

=> Correct, but SIP is used because 3GPP didn't reuse the 
keying material from the original authentication. This is 
done for several reasons outside our scope here. In any case,
my point was that you can reuse the keying material that 
comes out of the initial auth to generate keys for MIP. There
are zero messages required for this approach.

   Additionally it is the SIP client on the UE that has to then
 > create the IPsec SA on the mobile. So some form of APIs to the IPsec
 > stack are needed to create the SA. But thats an 
 > implementation issue. 

=> Correct.

 > 
 > In the scenario that we are now discussing, do you believe that
 > PPP/AAA signaling should be used to exchange the parameters of the SA
 > between AAA-Home and the MN? I dont think this works very well from a
 > practical perspective.

=> I think it's certainly possible but not necessary. Static
lifetimes and algorithms can be used if you don't want to
add new fields in PPP/AAA. But I don't see it as impractical. 

 > 
 > >- Extensions to EAP methods. 
 > 
 > There is an I-D from Giaretta (within the scope of bootstrapping)
 > which proposes the use of EAP with some extensions to establish the
 > IPsec SA. But EAP is not necessarily a feasible option within the
 > scope of the discussion, given that EAP is not (yet) used in the
 > network for authentication. The WG as you are aware is working on a
 > bootstrapping solution. This may be based on IKEv2 or AAA or EAP or
 > something else. This is work in progress. 

=> Sure.

 > 
 > But stepping back here, do you (dis)agree that the use of IPsec for
 > securing the signaling messages for MIP6 is an overkill. 

=> Yes :) Seriously I haven't seen a good reason for eliminating
IPsec (AH/ESP). I also think that once we develop an alternative
for protecting BUs, we will develop something that is more or less
like IPsec ,with the addition that it will only work for one
app. So that's why I don't think we should do it unless absolutely
necessary. As far as IKE goes, I agree that it might be too much.


   I tend to
 > believe that the auth option based solution provides an equivalent
 > level of security for the MIP6 signaling without involving IPsec in
 > the mobility equation.

=> It sure does. I guess I'm questioning the justification.

 > >=> In the first bullet above there are no messages. 
 > 
 > So in what messages do you exchange the SA parameters?

=> You don't, you define a well known algorithm and lifetime
that are always used. 

Hesham


===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================