Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 23 Apr 2004 00:19:53 -0400

> I'd suggest adding the following sentence to the first 
 > paragraph in Section
 > 3:
 > 
 >     "The key preconfiguration mechanism is outside the scope 
 > of this draft,
 > but possible mechanisms are static configuration, Diffie-Hellman key
 > exchange if both parties have a certified public key 
 > [RFC2631], or through
 > configuration during an AAA exchange [ref?]."

=> I don't think we should lump all these alternatives
without proper analysis. I think they draft should 
only address manual config. KISS principle should apply.
This goes back to the difference between trust relationships
and security relationships.

Hesham

 > 
 >          jak
 > 
 > ----- Original Message ----- 
 > From: "Soliman Hesham" <[email-masked]>
 > To: "Christian Vogt" <[email-masked]>; <[email-masked]>
 > Cc: <[email-masked]>; "Jari Arkko" <[email-masked]>; "Charles
 > Perkins" <[email-masked]>; "Roland Bless" 
 > <[email-masked]>; "Mark
 > Doll" <[email-masked]>; "Tobias Küfner" <[email-masked]>
 > Sent: Thursday, April 22, 2004 5:23 AM
 > Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt
 > 
 > 
 > 
 > 
 >  > In an email from March 15, I mentioned that there may be
 >  > scenarios in which peers have a security relationship, but
 >  > no trust relationship. For instance, an ISP may configure
 >  > its media servers with the keys of its customers. The
 >  > customers could then use their keys and Mobile IPv6 for
 >  > communications with the media servers, but some customers
 >  > might misuse the lack of a care-of-address test to wage a
 >  > re-direction-based flooding attack against an arbitrary IP host.
 > 
 > => I had the same concern at the beginning of last year
 > when this was discussed. That's why I think it's necessary
 > for the draft to either make this distinction between trust
 > and security relationship explicit (for deployment's sake) or
 > add a CoA test.
 > 
 > Hesham
 > 
 >  >
 >  > IMO, there is an easy way to combine standard Mobile IPv6's
 >  > care-of-address tests with Charlie's pre-configured-keys
 >  > proposal. Here is an excerpt from my email from March 15:
 >  >
 >  > > [...]                                   Maybe this [the 
 > combination
 >  > > of pre-configured keys with a care-of-address test] could
 >  > > be realized by a CoTI/CoT exchange, and by 
 > authenticating a Binding
 >  > > Update with a key produced with the pre-configured key and the
 >  > > Care-of Keygen Token? The (64-bit) pre-configured key
 >  > would play the
 >  > > role of the Home Keygen Token in this case. One would
 >  > still avoid the
 >  > > HoTI/HoT exchange, and one would avoid involving the 
 > home agent in
 >  > > the binding-update procedure.
 >  >
 >  > Sure, the care-of-address test would partly vitiate the
 >  > binding-update-latency improvement that pre-configured keys
 >  > bring along. But at least we save a potentially long
 >  > home-address test through the mobile node's home agent.
 >  >
 >  > Using a *concurrent* care-of-address test (i.e., one running
 >  > in parallel with data transfer to and from a new care-of
 >  > address as described in [1] and [2]) could help to avoid the
 >  > additional latency of the care-of-address test during the
 >  > critical phase. The concurrent care-of-address test could be
 >  > protected by Credit-Based Authorization [2]. Credit-Based
 >  > Authorization was first presented during the MOBOPTS session
 >  > at the 59th IETF meeting in Seoul. I am currently putting
 >  > the finishing touches to an Internet-Draft describing
 >  > Credit-Based Authorization in more detail.
 >  >
 >  > Best regards!!
 >  >
 >  >
 >  > - Christian
 >  >
 >  >
 >  > [1] Early Binding Updates for Mobile IPv6
 >  >
 >  > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-bin
 >  > ding-updates-00.txt
 >  > [2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf
 >  >
 >  >
 >  > -- 
 >  > Christian Vogt
 >  > Institute of Telematics, University of Karlsruhe (TH)
 >  > www.tm.uka.de/~chvogt/
 >  >
 >  >
 >  > "If we knew what we were doing, it wouldn't be called
 >  > research, would it?" (Albert Einstein)
 >  >
 >  >
 >  > On Thursday, April 22, 2004 12:29 AM [GMT+1=CET],
 >  > [email-masked] <[email-masked]> wrote:
 >  >
 >  > >> S. Daniel Park wrote:
 >  > >>> not sure because I didn't follow up this thread fully but
 >  > >>> this is my personal concern.
 >  > >>>
 >  > >>> If this draft would be a RFC as standard track, I guess
 >  > >>> current RR in 24version will not be used for Mobile IPv6
 >  > >>> with the implementation aspect. Is there any consideration
 >  > >>> or requirement ? I hope to see more improved and clarified
 >  > >>> something in this draft.
 >  > >>
 >  > >> I may have misunderstood the question, but the proposed
 >  > >> mechanism is an alternative and optional scheme for
 >  > >> authorizing BUs related to route optimization.
 >  > >>
 >  > >> As such, the base RR mechanism is used by default
 >  > >> unless this specific scheme is implemented and
 >  > >> configured on. The proposed mechanism is applicable
 >  > >> only to a certain (limited) class of situations, so
 >  > >> you would not always have such a configuration available.
 >  > >>
 >  > >> Or perhaps you are asking whether the mechanism is used
 >  > >> in addition to RR? I think the authors have inteded the
 >  > >> mechanim to be used as a replacement (for the situations
 >  > >> that it applies to) rather than as an add-on.
 >  > >
 >  > > I think this method can be considered as an alternate to
 >  > > RR based RO when the MN and CN share a key/secret. For the
 >  > > subset of CNs that the MN has a preconfigured key/secret,
 >  > > RR is not applied. But it does not necessarily replace the
 >  > > RR based RO scheme. The MN *should* be capable of doing
 >  > > RO using RR for the larger set of CNs. So I would'nt call
 >  > > it as a replacement, but rather an alternate scheme for
 >  > > a set of CNs that the MN is aware of.
 >  > >
 >  > >
 >  > >> There has
 >  > >> also been some discussion on the list about whether the
 >  > >> proposed mechanism should be merged with care of address
 >  > >> testing from the base RFC or possibly some improvement of
 >  > >> that, such as CBA/EBU. I personally think that something
 >  > >> along those lines might be fruitful and would make the
 >  > >> mechanism more widely applicable, though it may be too
 >  > >> early to tell yet.
 >  > >
 >  > > Maybe the authors could express their thoughts on the
 >  > > enhancement proposals.
 >  > >
 >  > >> --Jari
 >  > >>
 >  > > -Basavaraj
 >  >
 >  > 2(tm)SSSz®¶ÿ?¢(tm)(tm)-Sþ
 >  >
 > 
 > ========================================================
 > 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.
 > ========================================================
 > 
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/mip6
 > 
 > 
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Fri, 23 Apr 2004 08:15:47 -0700

OK, then just include static configuration.

But I'm pretty sure the Security Directorate won't approve it without some
indication of how the keys are configured.

            jak

----- Original Message ----- 
From: "Soliman Hesham" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Christian Vogt"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Jari Arkko" <[email-masked]>; "Charles
Perkins" <[email-masked]>; "Roland Bless" <[email-masked]>; "Mark
Doll" <[email-masked]>; "Tobias Küfner" <[email-masked]>
Sent: Thursday, April 22, 2004 9:19 PM
Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt

Hesham