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

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 23 Apr 2004 11:24:26 -0400

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

=> Manually? I thought that was the intent all along.
I think anything else is actually potentially dangerous.

Hesham

 > 
 >             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
 > 
 > 
 > 
 > 
 >  > 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:36:26 -0700

Manually is fine, I just think they will want some indication of how its
done.

Perhaps we ought to simply ask Russ and Steve for an opinion. If they say
they don't care, then of course we can leave it out.

            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: Friday, April 23, 2004 8:24 AM
Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt

Hesham