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

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 22 Apr 2004 08:23:37 -0400

> 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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 22 Apr 2004 13:57:31 -0700

As a practical matter, I think that the Security Considerations section has
to say something about how the key gets there, or the IESG is likely to
object (please, no flames about the IESG, I'm just trying to be practical).
A Seamoby draft had a Discuss put on it recently for this reason. Their
reason for this is that people who read the draft need some guidance about
how the keys might get there, and not believe that they should just show up
somehow a position which I believe makes some sense.

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?]."

         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

Hesham

---

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 22 Apr 2004 15:00:14 -0700

Hello Jim,

> James Kempf wrote:

This is fine with me, except that I wouldn't want the AAA exchange
to be a normative reference.

> object.

I think it's objectionable that so much unnecessary cruft gets
stuck into protocol documents, but as long as it does not
interfere with the actual protocol specification it's more
tolerable.  Plus, as you note, guidance sez do it or else.
Up until now, there is so little protocol (zero?) in the
document that it's going to be hard to mess it up.

When it comes to similar messages on milk cartons or automobile
owner manuals, people make fun of it.  "Caution, coffee may
be hot!".  There is a whole section on applicability.  That
should be enough.  People should design the system so that it
meets the restrictions described there.  Any key installation
that meets the restrictions should work fine.

Anyone who has ever borrowed money to buy a house recognizes
this effect.  Over time, more and more lawsuits are settled
disadvantageously to the lender.  Over time, more and more
pages are tacked onto the loan documents, in hopes of removing
more and more remote vulnerabilities.  Over time, fewer and
fewer people actually read the documents.  When I did it, I
was gently made to feel like I was quite "special" that way.

I am suggesting that it will be a terrible problem if, over time,
fewer and fewer people actually read IETF protocol documents.

> somehow a position which I believe makes some sense.

Well, what if (!from the standpoint of Mobile IPv6!) the keys
DID just show up, and your commanding officer told you to
securely install them?  Do you need to know any more than
that?  However they are preconfigured, needs to conform to the
applicability section.  Any more than that is overspecification.

Regards,
Charlie P.

PS. I trimmed the CC: list, since the message was going to the
    mailing list anyway.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Apr 2004 23:36:07 +0300

James, Charlie, Hesham,

> configuration during an AAA exchange [ref?]."

I agree with Hesham that we should avoid making
a general statement here. This is for preconfiguration
only, as in manually configured. The assumptions
and implications of this should be documented
(and have been discussed on the list in the past,
I have not read the latest version to see if it
has the right words).

It is possible that some day there will be an AAA based
mechanism, but we should not necessarily assume that it
uses this as a component, and we shouldn't spend time
now analyzing the assumptions necessary to get the keys
from AAA.

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

I think saying that the configuration is done manually
is fine. In addition there's a need to talk about the
assumptions (e.g. you trust the other guy) that must
hold before you can do this.

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

Please do. In general, the security folks have been interested
in having automatic key management in many contexts; see e.g.
Bellovin's draft. However, I believe in this context we can show
that

   - There is a mandatory automatic mechanism (RR)
   - This scheme is optional and for a very specific & limited
     situation
   - Assumptions that must hold before a key can be configured
     have been documented (or will be if they are not yet)

But there may be other issues that we have not thought of,
so it would be good to get some input on this.

--Jari