Subject: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 27 Jul 2001 12:59:09 -0700

Hello folks,

It seems to me that an engineer, unfamiliar with Mobile IPv6, would
form some very bad impressions after reading this draft.

This is because it is declared several times in the draft that mobility
opens security vulnerabilities when home agents and correspondent
nodes accept Binding Updates without any authentication.

However, the Mobile IPv6 specification does not in any way permit
such behavior, and thus DOES NOT open the declared vulnerability.

One can understand that the document needs to list all the possible
threats that are important to understand, and the acceptance of
unauthenticated remote redirects is certainly an error that needs
to be prevented.  However, the document COULD be misinterpreted to
mean that the stated vulnerability is a current problem with
Mobile IPv6.  I would earnestly request that every such instance
within the Requirements document should be repaired to make it
clear that the threat has been countered within the Mobile IPv6
specification.

More generally, I would suggest that every scenario should have
an additional "STATUS" subtopic heading.  That is, for each of
the scenarios, the current status of the threat should be listed.
So, for instance, each of the remote redirect scenarios (in addition
to being reworded) could contain the following paragraph:

   STATUS: prevented within Mobile IPv6 by the requirement that
           all Binding Updates MUST be validated using the
           unforgeable Authentication Data provided along with
           the Binding Update.

That is my major comment.  In addition, I have the following
issues, in varying degrees of importance.

1) All scenario subtopics should occur in the same order:
   - Scenario description
   - Threat
   - Result
   - Requirement
   - Status  (I sneaked the new one in here...)

2) The table in section 6 should cross reference the relevant sections

3) On page 11, second paragraph of Effect B.3, the words
   "ownership of the home address" should be "... care-of address",
   right?

4) The document seems to be missing all the page feed characters.

5) The second paragraph of Requirement E.1 seems to be trying to
   outline threats that might exist if someone tried to create a
   new challenge-based protocol.  This is not a scenario inherent
   to Mobile IPv6, nor to mobility in general I don't think.

6) Masquerade is misspelled.

7) In the first sentence of section 6.6, the words "the link" should
   be "a link", correct?

8) The requirement generated from section B.3 (on page 21) is
   really a requirement for address autoconfiguration, not a mobility
   problem.

9) The problem described for the Home Agent discovery mechanism is
   actually a problem for ALL anycast messages that are served by
   routers.  Furthermore, it's not always a problem!  For many domains,
   perhaps the network administrator would not care.  We should allow
   network administrators not to care if they would not otherwise care.
   Thus, the requirement H.1 on page 21 should be a SHOULD not a MUST.

10) In section 7.1, the concept of Identity Authentication is introduced,
    but (unless I missed it) not explained earlier.  Furthermore, it's
    not shown earlier why it is _always_ needed -- and, in fact, I don't
    think it is always needed.  Maybe the whole requirement C in
    section 7.1 should be deleted.

11) In Result H.1, on page 18, the last sentence should actually be
    the start of the next scenario.

12) On page 2, section 2, the first "off" should be "from".

13) In section 3, it is plainly stated that MIPv6 "introduces" a
    threat from bogus redirection.  This is wrong, as I explained
    above.

14) In section 5, first bullet, "gainst" should be "against".

15) Every occurences of "it's" should be "its".  I checked.

16) On page 18, there are two occurrences of "Threat H.2".  I think
    the second one should be "Result H.2".

17) Perhaps [Ref1] should be updated to cite revision 14?

Thanks for your consideration of these suggestions.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2001 13:12:02 -0700 (PDT)

I don't get it. The current -14 draft does not
contain a complete specification, nor does what
little is in there have consensus. As such,
somebody interpreting the spec as incomplete and
vulnerable would be correct. Rather than shooting
the messenger, maybe we should ignore tender
sensibilities and get down to the job of getting
consensus on what's broken, and the choose an
approach to fix it in the mipv6 spec.

	    Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 27 Jul 2001 14:00:40 -0700

Michael Thomas wrote:

> little is in there have consensus.

What incompleteness are you referring to?
I think it is complete except that it cites a
working group document on key establishment that
does not exist.  I thought it was far better to
send out the document for further comment rather
than wait for the finalization of the key establishment
draft, which is likely to take a while.

Furthermore, varying parts of the draft have varying
degrees of consensus.  Perhaps you were thinking of
some particular part of the draft for your comment.
Could you be more specific?  We need to have as much
discussion as possible on it so that we can generate
ideas for making sure it satisfies the requirements.

>                                          As such,

You must be reading a different specification than I
was.  Perhaps you had something uncomplimentary in
mind when you referred to tender sensibilities.  If
so, obviously whoever the target was probably wouldn't
derive as much benefit as might be possible from the
rest of your good ideas.

I'd be curious to find out whether you have any comments
on my suggestions on how to improve the requirements
draft.  I didn't see anything useful in your message
in response to my comments.

When it comes to getting down to the job, I have been
doing my best to do exactly that for a long time.  Thus,
I _have_ made my best judgment on how to respond to
many comments made during discussions about Mobile IPv6.
See the "Changes" section for details.  If you have some
suggestions on how I can be more effective for the task
of incorporating the changes needed as a result of working
group discussion, please let me know either on the list
or in private e-mail.

Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2001 14:55:50 -0700 (PDT)

> draft, which is likely to take a while.

   Even if key establishment weren't a definition
   of "incomplete" -- which I most assuredly do
   not agree with; indeed we've take a giant step
   backward if we can't use IKE to key SA's --
   what is currently defined is a length and an
   unspecified value for the bits in the vector.
   That is not my idea of "complete". How are
   replays, for example, prevented?
 
 > ideas for making sure it satisfies the requirements.

   Yes. You moved the authentication data to the BU, and
   as far as I can tell, that was a) never discussed on
   the list, b) pre-supposes that IPsec is a non-starter,
   c) doesn't have any consensus, and d) surprised quite 
   a few of us.

   I've already discussed in a number of posts why
   it is premature to declare IPsec dead. Thus far
   you have as yet to respond to any of them.
  
 > derive as much benefit as might be possible from the

   I read both the -14 spec and the security
   analysis. I agree with the conclusions of the
   security analysis, as I assume the authors 
   did as well. As far as I can tell, you seem
   to be asking anybody who agrees with that
   analysis to either downplay its conclusions
   or sweep them under the rug. If you want
   marketing spin, I suggest you contact your
   marketing department instead of asking the
   participants of this forum to participate in
   whatever your idea of damage control is.

 > in response to my comments.

   I have already sent out my own comments on the
   requirements draft. There are archives if you
   missed them.

		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 27 Jul 2001 23:27:39 -0700

>
>  > I didn't go back and check the archives, but during the last
>  > two IETFs, in various meetings including the mobileip
>  > working group meetings, it seemed pretty clear to me that
>  > we were being told that IPsec wasn't appropriate for
>  > authenticating Binding Updates.  Given that, I didn't see
>  > any alternatives for how to proceed except to make the
>  > authentication data into one of the fields of the Binding
>  > Update option.
>
>    Operative words: me, and I.

I use these when I am speaking for myself and
trying to counter your personal accusations.  I used
'we' to describe cases where (to my understanding)
the working group was being informed about something.

As co-author of the specification, which was in Last Call,
it is my job to try to fix problems with the specification,
and since it is a working group document, I follow
working group consensus when determining a solution.
If something needs to be changed, let's change it.

I think over the last year, and long before your
involvement, I have demonstrated my willingness and
ability to follow working group consensus, and respond
to all the comments that have been presented.  I'll happily
do it again, if it is decided to use IPsec for authenticating
Binding Updates.

>                                          Note that this isn't
>    the same as working group consensus. In fact, I
>    haven't heard _anybody_ say that they don't
>    want to IPsec for some parts of the solution
>    other than you, and this draft that got foisted
>    on the working group.

Well, that was my understanding from the last working
group meeting in Minneapolis, and it seems to have been
shared by other people too.  You are saying there is
disagreement.  That means the discussion isn't over.

>  > You seem to be dead set on discrediting this work, and
>  > of course I wish you could take a more constructive
>  > approach.  You should acknowledge that I argued quite
>  > vociferously in various meetings and venues to retain the
>  > IPsec AH mechanism.  You didn't voice any support for
>  > that effort before.  Now that another approach has been
>  > proposed, you seem more willing to support IPsec AH.
>  > I don't know what to expect, but I guess it will not be
>  > support from you.
>
>    I have made literally dozens of posts on this subject
>    and if this is your simplistic take on my view of this
>    matter you are either unwilling or unable to grasp
>    what is at issue here. I have *never* said that I
>    think that IPsec is inappropriate in all circumstances
>    and I challenge you to find where I have said so.

I didn't put those words in your mouth.  I just said that
I don't remember you offering any support for keeping IPsec
last year.  That does not at all mean that I knew what your
real position was.

>    I have said that I'd prefer ESP over AH, but again if
>    that leads you to believe that I don't support use
>    of IPsec in some situations, then you are clearly
>    not grasping the subtleties here.

bzzt.

>  > I did send out the proposed format for Binding Update
>  > to a number of people for sanity checking before revising
>  > the draft.  Then I had to leave town for almost three
>  > weeks.  The work was done (aka getting down to work)
>  > to the best of my understanding of what was needed, and
>  > with as much input as I could gather in the time available.
>  > If consensus indicates another approach, that will be very
>  > fine with me.
>
>    Yet, and there was no list consensus to do so, and this
>    is the result.

...?

>  > Plus, authenticating payloads might need a different
>  > algorithm than authenticating the Binding Update --
>  > so separation is advisable.
>
>    What leads you to this conclusion?

If a Binding Update needs to be authenticated using
algorithm X, and AH says to use algorithm Y, then there
would be a problem.  I don't view this as serious.

>  > >    did as well.
>  > As should have been obvious from what I posted,
>  > I largely agree with the conclusions of the work
>  > also -- except that it gives the false impression that
>  > the existing Mobile IPv6 specification opens up
>  > a vulnerability from remote redirection which is
>  > false.
>
>    That is yet to be seen, and from what I've
>    read, there is no reason whatsoever for them
>    to tone down their message. This is a very
>    serious issue even if it is inconvenience to
>    your standards track uber-alles schedule.

The reqs draft says that Mobile IPv6 is vulnerable to
misuse from unauthenticated Binding Updates.
Mobile IPv6 says that unauthenticated Binding Updates
have to be ignored.  The claimed vulnerability does
not exist by the rules of the the Mobile IPv6 spec.
It would exist by other rules, sure.  This is a very
serious issue.

>  > >                As far as I can tell, you seem
>  > This is totally wrong, unconstructive, and very
>  > annoying. I ask you to stop it right away.  Your
>  > accusations are unfounded and cause for alarm,
>  > making the entire rest of your points suspect also.
>
>    So do tell, Charlie: what *was* the purpose of
>    your "please tone it down" request? You are the
>    *only* person who has disputed their findings.

My purpose was to suggest improvements to the draft.
I believe that the draft is misleading insofar as it might
lead one to believe that Mobile IPv6 has a problem with
allowing nodes to accept unauthenticated Binding Updates.
Mobile IPv6 specifies that such behavior is illegal, thus
avoiding the vulnerability.

I made many other positive suggestions which you don't
seem interested in considering.

>    Also: it is rather disingenuous to argue with them
>    after the fact since their analysis was made on the
>    -13 draft. The -14 draft, until a week ago or so, was not
>    available to them or anybody else to comment on.
>    Their analysis of the  -13 draft was pretty spot
>    on from what I can tell, and it's completely unclear
>    whether -14 -- which hasn't incorporated any
>    feedback from the working group -- is any
>    better.

Their analysis is equally valid for drafts 13 and 14.
Draft 14 is not appreciably better from the standpoint
of specifying any way of establishing keys.

>  > Did you have any comments to make on my suggestions for
>  > improvement?  I don't see why your comment was in the
>  > least relevant to what I said.
>
>    Yes: the unvarnished truth is far better than
>    putting some idiotic market spin on the
>    security problem with mipv6. It's appalling
>    that you'd ask the working group to soft peddle
>    the reality, and is insulting to those who have
>    spent a lot of time trying to make an honest
>    evaluation of the current state of affairs.

One unvarnished truth is that Binding Updates have to be
authenticated, and the honest evaluation is that Mobile IPv6
doesn't currently suffer from the claimed vulnerabililty.
Another unvarnished truth is that we have been given the
task of finding a way to set up security associations that
can be used to enable verification of authentication data
supplied with Binding Updates. Another unvarnished truth
is that your postings to this mailing list are insulting,
unconstructive, ignore or twist my words, and lately have
been a waste of my time.  I have never asked the working
group to soft-peddle reality.  I have not insulted anyone
for championing IPsec (or for any other reason), and I
will be just as happy one way or the other.  You are wrong
to suggest otherwise.  Further, as much as I dislike your
way of insulting me, I have not intentionally  insulted you.

Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2001 20:43:17 -0700 (PDT)

Charlie Perkins writes:
 > - Replays are prevented by using different sequence
 >   numbers.  Section 13.1 discusses this briefly.

   What is in there is wholly insufficient and 
   incomplete.

 > - Requiring IKE from every IPv6 node is too much.
 >   However, it should be _allowed_ for nodes that
 >   want it.  Do you wish to specify the details?

   With what you have now, IKE cannot be use _at
   all_ because there is no DOI. This is large
   step backward; one which was not discussed on
   the list whatsoever.

 > - Section 4.4 discusses the authentication calculation.
 >    I expected there to be more discussion about this;
 >    presumably there could be an agreement for a
 >    common default mechanism like HMAC_MD5 for
 >    the algorithm.

   Insufficient and unreviewed, and incomplete.

 > authentication data into one of the fields of the Binding

   Operative words: me, and I. Note that this isn't

   and I challenge you to find where I have said so. I
   have said that I'd prefer ESP over AH, but again if

 > As I understand it, and as further supported by recent
 > discussion, IPsec security associations aren't really
 > selectable based on the type of the Destination Options.

   If this were an original hope of pre-14, then it was
   clearly a misuse of IPsec.

		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 27 Jul 2001 18:49:16 -0700

>    you have as yet to respond to any of them.

I'm happy either way.  The authentication data can be
part of the IPsec header, or it can be in the Binding Update.
I understand the arguments for both sides, and I am not
that particular.  However, I would like to encourage the
discussion to take place ASAP.

Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2001 13:03:29 -0700 (PDT)

Charlie Perkins writes:
 > trying to counter your personal accusations.

   It must be very convenient for you to trot out
   this personal offense nonsense instead of
   replying to substance of my posts. 

 > If something needs to be changed, let's change it.

   Is it your claim that there was working group
   consensus to remove IPsec from the draft?

 > disagreement.  That means the discussion isn't over.

   I have yet to see any *disagreement* that IPsec
   not be used in some cases (HA/MN, some MN/CN). Yet
   the use of IPsec was removed from the -14 draft.

 > last year.  That does not at all mean that I knew what your

   I have stated quite plainly in many posts what my
   position on the use of IPsec is. Many were in response
   to posts you made. I cannot force you to read them,
   but for you to say that I have not voiced support is
   verifyably false. And your accusation of my
   trying to "discredit" mobile ipv6 is a load of
   whooey, and is not supported by the long list
   of posts -- not to mention two drafts -- that
   I've done.

 > >    not grasping the subtleties here.

   Bzzt, what? I do not see how you could come to
   the conclusions you have if you were a) paying
   attention, and b) able to properly subdivide
   the different aspect of the problem. For this,
   I get awarded the Charlie Perkins MIPv6
   Destroyer Award.

 > >    Yet, and there was no list consensus to do so, and this

   That means that you changed a major aspect of
   the spec -- not just an editorial nit, etc -- 
   without working group consensus. You don't see
   a problem here?

 > would be a problem.  I don't view this as serious.

   You can always have multiple SA's with different
   selectors for different 5-tuples. This is not a 
   problem.

 > It would exist by other rules, sure.  This is a very
 
   The spec may say that they must be ignored, but it
   does not provide a workable method for how a node
   determines that they are unauthenticated Thus the
   analysis states the situation correctly.

 > avoiding the vulnerability.

   But the spec *does* have the claimed vulnerabilities,
   regardless of your wanting to downplay them, or saying
   that an incomplete and unanalyzed revision fixes all
   of the problems.
 
 > of specifying any way of establishing keys.

   This is *completely* false. The current draft has *no*
   means of using IKE or KINK! That in my mind is appreciably
   *worse*!

 > doesn't currently suffer from the claimed vulnerabililty.

   Honest evaluation by whom? Certainly not the authors of
   the analysis draft.

 > Another unvarnished truth
 > been a waste of my time. 

   If you expect me or anybody else to just roll
   over while you try to get the authors to soft
   peddle their message, I am delighted that you
   are insulted because you deserve to be insulted
   for such a sleazy request.

 > Further, as much as I dislike your

   Well, I dislike your trying turn technical
   disagreements into a faux-personal afront to shift
   the subject. It's an extremely dishonest debating
   tactic.

	Mike

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 30 Jul 2001 21:06:03 -0700

Here's a technical point...

>  analysis states the situation correctly.

If a node has no security association with a mobile
node, it cannot authenticate the Binding Update and
it must be ignored.  What else needs to be said?
I don't think this is at all ambiguous.  Thus, it is not
correct to characterize Mobile IPv6 as suffering from
this vulnerability.

The rest of the note doesn't have any technical
discussion, but for those who insist on not skipping
it, I'll supply some other sorts of corrections.

=====================================

>    replying to substance of my posts.

I found your posts  personally offensive.
Nevertheless I have tried to respond to the technical
substance of your posts.

>    consensus to remove IPsec from the draft?

My claim is that I believe the last two working group
meetings clearly indicated the need to do exactly that.
Given the recent situation, I don't think we have
consensus for either position at the current time.

>    the use of IPsec was removed from the -14 draft.

I guess that Vijay's pointer supplied something that
you might wish to consider.

>    of posts -- not to mention two drafts -- that

Yes you have.  And no-one would claim that you have
failed to recently support the continued use of IPsec.
I was talking about last year, and just that I didn't remember
you supporting my attempts to retain IPsec.  Maybe you
did and I didn't remember.

And I did not claim that you have tried to discredit
Mobile IPv6, merely all the work I have tried to do on
it recently.

>    I get awarded the Charlie Perkins MIPv6

Which of my conclusions were wrong?  And I did not
claim you were the Mobile IPv6 destroyer, but instead
that you made many attempts to discredit my attempts
to resolve difficulties with authenticating Binding Updates.

>    without working group consensus. You don't see

I could not parse your sentence.  Do I have to say more?

>    that an incomplete and unanalyzed revision fixes all

Problems can be fixed, and of course I wouldn't claim that
the specification is problem free.  Constructive dialog is
needed.  I maintain that the specification doesn't have the
particular vulnerability that I previously wrote about.
Instead of writing notes like this to counter false (and
overtly personal) charges, I'd rather have the constructive
dialog.

>    means of using IKE or KINK! That in my mind is appreciably

?  O.K.  You think it's worse.  I guess we've established that.

>    Honest evaluation by whom? Certainly not the authors of

It's my honest evaluation, and I am trying to make the case.
So far, there haven't been too many other people addressing
this point, and I don't see any merit in your position.

>    for such a sleazy request.

I continue to try to explain that Mobile IPv6 does not suffer
from that particular vulnerability.  I again find your words
to be insulting, non-constructive, and unfit for proper
discourse.  If a node CANNOT accept an unauthenticated
Binding Update, you have no reason to claim that such a
thing can threaten a node.

>    the subject. It's an extremely dishonest debating

I'll bet that everyone reading these notes would believe
that you have intentionally been insulting to me.

Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 31 Jul 2001 07:50:08 -0400

> nodes accept Binding Updates without any authentication.

One point that we all could probably be much more clear about is that
it is the route optimization part of MIPv6 that has the security
issues. I agree with Charlie that it is not MIPv6 in general.  This
distinction is very important, because MIPv4 has *exactly* the same
problem. Yet, very few people (and especially not those in the press)
seem to be noticing this.  This has to some extent caused additional
PR problems for MIPv6, since many folks don't distinguish MIPv6 from
just the route optimization. It would be good for all of us to
continually educate folks that don't make this distinction.

So why has MIPv6 security being targeted and not MIPv4? For one thing,
in MIPv4, the route optimization stuff is in a separate draft, so it
is not part of the base spec. Second, in conversations I have had with
folks interested in MIPv6, they seem to generally think that the route
optimization part of MIPv6 *is* important, and that MIPv6 in general
is significantly less attractive without it. I don't fully understand
this reasoning, given that MIPv4 (without route optimization) is being
deployed today, and route optization in MIPv4 is not being pursued by
any of the carriers (from what I can tell - please correct me if I'm
wrong).

>            unforgeable Authentication Data provided along with

This is an interesting suggestion. But rather than making the threat
analysis document do this for the various proposals, it might be
better for each proposed solution to describe how (and whether) it
deals with each of the described threats.  Certainly, one of the
intents of the threat analysis document was to provide a
straightforward way of comparing various proposed solutions to see
exactly which threats they guarded against.

Thomas

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 08:28:18 -0700 (PDT)

> correct to characterize Mobile IPv6 as suffering from

Since there isn't sufficient information on _how_
to authenticated binding updates, the only way to
interpret what you wrote in light of the analysis
is that MIPv6 does not have this vulnerability
because it does not support route
optimization. This is clearly not very helpful as
it's obvious that the goal is to have a secure
route optimization feature as part of the base
spec, and I'll guess that that was their take on
the matter as well.

I'm sorry if you feel frustrated with all of this
because the MIP WG has unwittingly fallen into a
trap with an extremely hard puzzle that needs to
be solved before it gets out. Things like this
happen, and security/identity/authorization is
very fertile ground for these sorts of pit
traps. My attitude is we're here, we're hosed, we
need to get on with solving the puzzle. It does no
good to parse differing degrees of hoseitude, and
indeed detracts from the real job at hand. My sin
is that I did not pursue this more vigorously than
sending off a note well over a year ago to Steve
Deering and Fred Baker about whether the IESG was
going to step up to the plate given the global
implication of IP address ownership that MIPv6
brings to the fore. To me, this was as plain as
the nose on my face and I assumed that the MIP WG
had already been through this and come to its own
inner peace about which of the set of bad options
it was willing to live with. I was wrong, and now
I look like a Cassandra for raising what should
have been raised years ago. I am but the messanger
though, and it's a good thing this was widely
realized before it went to proposed standard since
we *really* would have looked foolish if it were
realized after the fact.

	       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 08:43:36 -0700 (PDT)

> any of the carriers (from what I can tell - please correct me if I'm

It seems hard for me to imagine why an operator
wouldn't like the prospect of not having to buy
expensive, single-point-of-failure, etc, network
elbow joints if they didn't have to. Since MIP is
mainly a host OS deployment issue, and assuming
that the usual suspects start supporting route
optimization, I imagine that they'd be delighted
to spend less money. I could be wrong though;
people willingly force OE on people which defies
logic too.

		Mike