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

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 16 Mar 2005 17:02:16 -0500

> 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. 

=> I hope my earlier answer can show you that it's certainly deployable. 
But aside from that, let's say it has no security at all, how does that come into
the discussion if we're developing security for other proposals that have none?
Seems like we're not applying the same measure.

    In a previous posting, you
 > alluded to some deployment experiments, perhaps you would 
 > care to elaborate?
 > What type of security are they using?

=> I talked about deployment needs in the context of combining anticipation with a local
mobility agent (not in the AR). 

BTW, Some of your colleagues produced a document a couple of years ago with the intention
of making a BCP for HMIPv6 deployment with the PKI approach I mentioned earlier. 
I believe they were in Japan but can't find a pointer to the draft.

 > 
 > 
 > > 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.
 > >
 > 
 > 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. 

=> The IESG had no participation in the experimental issue and I think you
know that. 

 > 
 > 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?

=> No I would not care to do that because I think it's a waste of time. If this WG
wants to work on it I'll produce a draft, I never thought it was a research issue to
begin with. I don't want to use this list for spam but I can mention that I already
proposed alternatives in a book I published. Sorry, but I won't spend time on this 
in the IRTF. I'd rather just do it in IETF or in real life when opportunity comes. 
IRTF was never a requirement for work in IETF anyway.

 > > 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.
 > >
 > 
 > In practically every standardization forum I've listened in 
 > on, people want
 > solutions that don't require host certificate provisioning. 
 > To my knowledge,

=> James, I already mentioned _two_ other alternatives: A) local AAA
and B) CGAs. It seems to me like you want to put HMIP at a disadvantage 
because it has a solution....I've mentioned numerous times that CGAs will
work for both HMIP and FMIP...

 > > 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...
 > >
 > >
 > 
 > With what credentials does the MN prove its right to 
 > establish the keys?

=> Triangle of trust : MN authenticates to AAAH (as it has to), as a result, 
app keys are created, some of them can be used for local mobility. 

 > 
 > 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.

=> Ok, that's one way. Another way is to produce the application keys and liftimes
I mentioned above.

 > 
 > 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?

=> The MN cert is issued by CA2 (home operator), which is trusted
by CA5 (local operator) because the home and local operator agreed on this
as part of their roaming agreement.

 > 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.

=> Charlie said that he wants to be able to run them separately. I agree
with him. But I also want to add the possibility to make them coexist efficiently. 
Based on current experience, I see that this is needed. I don't understand 
why you would not want to have that added to the charter. Why?

Hesham

 >             jak

===========================================================
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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 16 Mar 2005 14:27:16 -0800

>Seems like we're not applying the same measure.

Hesham, you've lost me here. The RG has been having an active discussion
about security for FMIP for over a year. We are about to refer one draft to
MIPSHOP, and there's another coming along that looks promising. It seems
like we are finally starting to get a handle on interesting technology that
actually might be deployable for FMIP security.

On the other hand, nobody at any meeting I've been at has said anything
about practical, deployable security for HMIP, and there are no drafts on
the topic. All I am trying to say is I'd like to see the same kind of
discussion on practical, deployable security for HMIP that we've been having
for FMIP before we consider referring HMIP to MIPSHOP. Even if the solution
is almost the same (and it might actually be quite different, or, at least,
different enough to be technically interesting). Besides the technical
aspect, it seems only fair.

> The IESG had no participation in the experimental issue and I think you
> know that.

They took the WG's recommendation on it. If they had had a different
opinion, I'm sure you would have heard it. IESG members are rarely shy when
it comes to contradicting a WG opinion with which they disagree. :-)

> No I would not care to do that because I think it's a waste of time. If
this WG
> IRTF was never a requirement for work in IETF anyway.

My understanding is that MOBOPTS is now a gateway for work to come into
IETF. I believe this is part of the reorganization of IRTF that the new IRTF
Director, Aaron Falk, is trying to achieve, to make IRTF more relevant to
IETF.

Besides which, I fail to see why HMIP should be accorded any different
treatment than FMIP. If its just a matter of taking the solutions you've
outlined in the your book and putting them into a draft, then what's the
problem?

> as part of their roaming agreement.

So how does this NOT involve certificate provisioning on a per host basis?

> why you would not want to have that added to the charter. Why?

So write up a draft for the next RG meeting on it. It even sounds like you
might have some experimental data, which would make the draft even more
compelling.

            jak