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

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 16 Mar 2005 14:58:44 -0500

James, 

 > Primarily security. 

=> More detailed responses below, but first I'd like to highlight one issue:
Your resistance to have further work on HMIPv6 is predicated on what 
you see as "lack of security". Apart from this being incorrect, it is certainly
a strange position, given the support for FMIPv6 which has zero security.
The security ADs thoroughly reviewed HMIPv6 security and saw no problem
with it apart from textual clarification. That's good enough for me.
More detailed answer below.

      The HMIP draft requires an IPsec SA 
 > between the MN and
 > MAP. 

=> It is not inherent to HMIP, other solutions are also acceptable. E.g. CGAs.

    The MAP is typically located in a foreign network, into 
 > which the MN
 > has roamed. Now, there are a couple ways the MN could 
 > authenticate itself to
 > the foreign network MAP to set up the SA. With IKEv2, it 
 > could use EAP, but
 > assuming that the MN is provisioned with AAA credentials for 
 > every foreign
 > network with which the home service provider has a roaming 
 > agreement is a
 > bit of a stretch. 

=> Sure, but you jumped several steps here: 

1. A local CA will do. This is very common, a PKI between operators that already
have roaming agreements is something very logical. I discussed this with Steve Bellovin
on the list and he agreed. Please go back to the LC discussions.

2. There is no need for a pre-established AAA association with every visited domain.
Thanks to EAP's key hierarchy, most EAP methods can establish keys on the fly...

   The MN could authenticate back through the 
 > foreign MAP to
 > the home network, but it would have to do this every time it 
 > moved to a new
 > MAP, which could be very slow, thus limiting the topological 
 > deployment span
 > of the MAP to a very high level.. 

=> I can't parse this on a technical level. Please elaborate.

     Alternatively, the MN and 
 > MAP could do a
 > full certificate exchange, but this requires provisioning a 
 > public key
 > certificate on the MN, something that has, as yet, proven 
 > elusive as Jari's
 > talk at IETF 62 mentioned. Have I missed any others? So I 
 > think practical
 > security for host-based localized mobility management (such 
 > as HMIP does) is
 > still very much an open issue, which is why these drafts were made
 > experimental in the first place.

=> Please see my answers above, this doesn't make sense to me. I haven't
seen Jari's talk, but I suspect (from what you said above) that it's not for aggregate
trust. The HMIP model (if you use PKI between roaming operators) requires
_aggregate trust_ NOT on a per mobile basis. This is trivial....

 > 
 > The situation with FMIP is somewhat different. There is one 
 > draft already on
 > how to do security (handover key using SEND) and another on 
 > the way that
 > will describe how to use the EAP keying hierarchy derived 
 > from the 802.11
 > three party security model. Both are based on past 
 > experience with security
 > techniques that look practical and deployable. So we have a 
 > couple security
 > solutions lined up. Even given that, I still believe there 
 > is some design
 > work required on FMIP to tease out the PrxyRtXXX messages, 
 > as I mentioned in
 > another posting, and I'd prefer to see that done in MOBOPTS.

=> If you read the above, I thnik you'll realise that the same solution can be adopted, 
regardless. The Basic problem is about forwarding from one address to another. This
applies to HAs, MAPs and ARs. MAPs and ARs are very similar, HAs are a little different.

Hesham

  > 
 > ----- Original Message ----- 
 > From: "Soliman, Hesham" <[email-masked]>
 > To: "James Kempf" <[email-masked]>; "gabriel montenegro"
 > <[email-masked]>; <[email-masked]>
 > Sent: Wednesday, March 16, 2005 11:22 AM
 > Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones
 > 
 > 
 > > I'm not sure why. It seems at least as mature as the rest 
 > of the items on
 > > the list.
 > >
 > >
 > >
 > >  > -----Original Message-----
 > >  > From: James Kempf [mailto:[email-masked]]
 > >  > Sent: Wednesday, March 16, 2005 2:21 PM
 > >  > To: Soliman, Hesham; gabriel montenegro; [email-masked]
 > >  > Subject: Re: [Mipshop] MIPSHOP discussion on new items 
 > and milestones
 > >  >
 > >  >
 > >  > I think this needs consideration in MOBOPTS first.
 > >  >
 > >  >             jak
 > >  >
 > >  > ----- Original Message ----- 
 > >  > From: "Soliman, Hesham" <[email-masked]>
 > >  > To: "gabriel montenegro" <[email-masked]>; <[email-masked]>
 > >  > Sent: Wednesday, March 16, 2005 10:39 AM
 > >  > Subject: RE: [Mipshop] MIPSHOP discussion on new items 
 > and milestones
 > >  >
 > >  >
 > >  > > Comments?
 > >  >
 > >  > => I think the items you listed all seem reasonable. Of
 > >  > course we need to
 > >  > discuss
 > >  > priorities. However, I would add the following item:
 > >  >
 > >  > - Work on proposals for integrating FMIPv6 and HMIPv6. There
 > >  > are already
 > >  > drafts on this and previous discussions in MIP (before the
 > >  > split). I thnik
 > >  > the community will benefit from this, instead of providing
 > >  > two independent
 > >  > solutions that provide different optimisations but 
 > cannot coexist
 > >  > efficiently.
 > >  > I think this is more important than the RR optimisations items.
 > >  >
 > >  > Hesham
 > >  >
 > >  >  >
 > >  >  > -gabriel
 > >  >  >
 > >  >  > _______________________________________________
 > >  >  > Mipshop mailing list
 > >  >  > [email-masked]
 > >  >  > https://www1.ietf.org/mailman/listinfo/mipshop
 > >  >  >
 > >  >
 > >  > ===========================================================
 > >  > 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.
 > >  > ===========================================================
 > >  >
 > >  >
 > >  > _______________________________________________
 > >  > 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: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 13:45:40 -0800

> you see as "lack of security". Apart from this being incorrect, it is
certainly

What I intended to say (and perhaps I wasn't clear so I will reiterate) is
that the security mechanisms proposed in the draft seem, to me, to be not
deployable in practical, roaming situations, not that there was lack of
security. Two completely different things. In a previous posting, you
alluded to some deployment experiments, perhaps you would care to elaborate?
What type of security are they using?

> More detailed answer below.

There's a difference between having security and having practical,
deployable security. The IESG's evaluation was based on the former, I
believe, hence the Experimental designation. To go to PS, I believe there is
agreement within the RG that the security needs to be practical and
deployable.

> => It is not inherent to HMIP, other solutions are also acceptable. E.g.
CGAs.

Then perhaps you would care to author a draft for MOBOPTS on the topic about
how it would work, just as others in the RG are doing for FMIP?

> on the list and he agreed. Please go back to the LC discussions.

In practically every standardization forum I've listened in on, people want
solutions that don't require host certificate provisioning. To my knowledge,
there are no examples where host certificate provisioning has achieved
widespread deployment, with the possible exception of PacketCable. IEEE
802.16 recently moved their certificate based security scheme which required
host certificate provisioning to "legacy" and changed to using the same
three party EAP/AAA-based authentication model as 802.11.

That said, from a design standpoint, I, too, really wish everybody would get
with the program, put certificates on their hosts, and deploy a PKI. It
makes much more sense from a design standpoint. Sad to say, we are not there
yet.

> Thanks to EAP's key hierarchy, most EAP methods can establish keys on the
fly...

With what credentials does the MN prove its right to establish the keys?

> => I can't parse this on a technical level. Please elaborate.

Sorry, coming from the bootstrapping discussion, we're discussing this a
lot.

Suppose the MN and MAP use IKEv2 to set up the SA. IKEv2 has a provision for
the host to use EAP to authenticate to the network node (a certificate must
be used the other way around, however). Now, it would be possible for the MN
to authenticate to the MAP using the EAP provision of IKEv2. In that case,
the MN would use the same credentials as for network access authentication,
the MAP would act as a NAS and pass through the EAP to the home network AAA.
The home network AAA server would render a yes/no decision about whether the
MN was authorized, and push the AAA-key to the MAP if so.

> _aggregate trust_ NOT on a per mobile basis. This is trivial....

I'm not sure I understand. What you seem to be saying (and please correct me
if I am wrong) is that the local operator can accept a certificate from the
home operator that is not specific to the MN. If so, how does the local
operator know that the MN has the right to claim authorization and that the
MN is who it claims to be, in the absence of a certified public key for the
MN?

> applies to HAs, MAPs and ARs. MAPs and ARs are very similar, HAs are a
little different.

While its possible that there could be some overlap, I don't think the
solutions would be exactly the same. And, as Rajeev and Charlie have already
mentioned, I'd like to keep some separation so that the two solutions could
be used separately. I think a draft or two on the topic, as is already
occuring with FMIP, would be useful.

            jak