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

From: [email-masked]
Date: Fri, 23 Apr 2004 11:23:16 -0500

Hi James,

I am indeed well aware of the ongoing efforts to improve the
IETF standardization process and the associated benefits of
having early reviews from different areas. In the case of
this I-D, I think the security aspects are fairly straight
forward and we have had some conversations with security
people earlier before taking up this work. But its definitely
a benefit if we can get some secuity people to comment on the
implications of keys on the MN and CN that the I-D relies on.

-Basavaraj

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> 
> 
> Raj,
> 
> I'm a little concerned.
> 
> One issue that has arisen lately in discussions of IETF 
> effectiveness is the
> importance of early review to ensure that drafts aren't 
> returned from the
> IESG at the last minute with showstopper bugs. What I am 
> trying to point out
> here is that, based on my experience, this draft may encounter such a
> showstopper (then again, it may not).
> 
> In any event, it seems prudent to me to at least check with 
> the Security
> Directorate if they are OK with having the draft leave the 
> issue of key
> configuration open. In fact, through the wonders of the 
> Internet (now that I
> think of it), I can send them an email myself and ask.
> 
>         jak
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, April 23, 2004 8:35 AM
> Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt
> 
> 
> 
> I dont think we need to speculate and worry about the obstacles
> that the security directorate or the IESG is going to pose to this
> I-D.
> As you mentioned the draft does not deal with the details of how the
> keys get securely on the MN and CN. There are any number of ways
> that we dont need to discuss in this document since that is not the
> intent.
> 
> So lets not add all sorts of disclaimers in the I-D to enable its
> passage through the IESG.
> 
> -Basavaraj
> 
> > -----Original Message-----
> > From: ext James Kempf [mailto:[email-masked]]
> >
> > 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
> >
> >
> >
> >
> >  > 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