Subject: RE: [mobile-ip] Binding Authorization data for Binding Update toHome Agent

From: [email-masked]
Date: Mon, 14 Oct 2002 17:58:57 -0500

>    Let me try this again: is what is being proposed is to
>    use the binding authorization data which uses a keyed
>    hash using a private (to the host) secret key, and
>    instead allow it to be directly verified by the other
>    party if it is also in possession of the secret?

Yes. Is it way too simple to merit any consideration? :)

> 
>    If that's what's being proposed, either I'm a real
>    dunce and this should have been obvious, or it's going
>    to need a bit more explaination than I've seen
>    on the list. 

More explanation in terms of security issues that the solution
would have to overcome? 

>    Nor does it strike me as obvious
>    that this is secure, though it's possible I've
>    missed that discussion.

It is as secure as what you have today for MIPv4 if you take
care of the replay protection issue. (I have to say that I do
not know if the replay protection issue has been addressed)

> 	       Mke

-BP

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Oct 2002 16:09:07 -0700

> not know if the replay protection issue has been addressed)

the sequence number in the BU gives replay protection
just as it does for manual IPsec keying.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Oct 2002 16:14:56 -0700 (PDT)

> just as it does for manual IPsec keying.

   What happens when you have sequence space rollover?

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Oct 2002 16:14:03 -0700 (PDT)

> More explanation in terms of security issues that the solution

   Well it took me quite a while to grok that
   what was intended was to circumvent the first
   two messages of the three message exchange.
   Maybe I'm being more dense than usual, but I
   suspect that this mode of operation would need
   quite a bit more explanation than the sentence or
   two which is how I read the proponents portraying
   the ease of incorporation.
 
 > not know if the replay protection issue has been addressed)

   Well, that's why I said it isn't obvious to me :)
   In particular, replay protection requires some for
   of synchronization. In the current return routeability
   test, that sychronization happens each test. What
   would be required for this is some means of saving
   that synchronized state, what happens if it's lost
   etc, etc. Indeed, there we would need to consider
   what would happen if the sequence space was exhausted,
   etc. 
   
   All this really points to is that I don't think this
   is quite the slight editorial change that is being
   suggested here. I still agree with Gabriel that this
   would be better considered separately rather than
   being included into the base draft.

		  Mike

---

From: Brian Haley <[email-masked]>
Date: Tue, 15 Oct 2002 08:17:48 -0400

> just as it does for manual IPsec keying.

Not quite.  If a MN has a binding with a HA and it expires, there
is nothing in the draft that says I can't send the same sequence
number in the very next BU.  Technically, this could be a replay
attack by any other system that had intercepted the original packet.
This has been a problem all along with manual keying, which is
discussed at the beginning of Section 14.3 of the Mipv6 draft.

-Brian

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 15 Oct 2002 05:21:34 -0700

Hello Brian,

This is a good catch, and I'm surprised the draft does not
already say that the sequence number MUST be incremented.
I thought it already did say so, and logically speaking it has to.
Do you have a suggestion about where the language should
be inserted?

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Oct 2002 05:31:28 -0700 (PDT)

> Do you have a suggestion about where the language should

   if (bu.seq_no++ == 0xffff) {
		/* ? */
   }

		Mike

---

From: Brian Haley <[email-masked]>
Date: Tue, 15 Oct 2002 11:39:45 -0400

Hi Charlie,

I guess my point was that it doesn't matter if the draft says you have to,
an attacker won't.

After reading further, Section 11.1 does talk about the MN storing the
last-known sequence number, but it doesn't have to store a Binding Update
List entry forever...

-Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Oct 2002 08:50:55 -0700

Hello Brian,

> I guess my point was that it doesn't matter if the draft says you have to,

That's true, but then what's important is what the home agent
will accept.  So, we have to make it so that the home agent
won't take Binding Updates with repeated (non-incremented)
sequence numbers.  And, the home agent has to keep this information
around for as long as it has a security association with the
mobile node.

Regards,
Charlie P.

---

From: Brian Haley <[email-masked]>
Date: Tue, 15 Oct 2002 12:14:58 -0400

Hi Charlie,

In a thread back in March it was decided that Home Agents need not store
sequence numbers in non-volatile storage since the overhead required
could be significant.  This was the reason Section 14.3 was written the
way it was and a key management mechanism recommended.

-Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Oct 2002 09:22:20 -0700

Hello Brian,

> way it was and a key management mechanism recommended.

I must have missed that!  Doesn't it make more sense to keep
the sequence number stored along with the security association,
since it's useful to avoid the vulnerability you point out?
Or is the point that one would like to have the security association
parameters stored permanently?

Without having gone back to read over the design discussion,
I would be inclined to classify this as an issue that requires
resolution.  But it does not seem hard to fix!

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Oct 2002 12:11:20 -0700

>    being included into the base draft.

Agree. We really, truely, and honestly need to get the MIPv6 base draft
finished.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Oct 2002 12:30:37 -0700

Hello Jim,

> Agree. We really, truely, and honestly need to get the MIPv6 base draft

It seems quite likely to me that we ought to be done this week.
Things are going along quite nicely with resolving various
issues.

I do not agree that there is anything hard about
allowing the Binding Authorization data for Binding Update
to the Home Agent.  In fact, I am starting to think it's
a bit crazy to disallow it, after the recent discussion
with Hesham and so on.  One would have to write some pretty
weird code to allow it for the correspondent node, but not
allow it for the co-located home agent.  There is no
additional code complexity for allowing it.

Worse, the concept of writing an Internet Draft and submitting
all 5 words to the IESG for consideration is silly.
There is no good reason to disallow this feature, and
according to recent discussion, Jon Postel's axiom
definitely applies.  Why in the heck would a home
agent discard a perfectly valid Binding Update that
was secure and verifiable?

The text was already written and under discussion.
It's drastically a lot simpler than the whole
return routability discussion, and not at all suitable
for submission as a separate Internet Draft.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Oct 2002 14:58:47 -0700

Charlie,

If the Home Agent accepts it as part of its function as an IPv6 node, as your
email implied, then there is no problem, and I don't believe there needs to be
additional text put into the document. What I am objecting to is yet more
discussion about putting in a feature involving the HA-MN security association
that is unclear. The text that Jari proposed about how to calculate the MAC in
the BAD should be sufficient for the base draft, with any additional uses
(including possibly ones that simplify the HA-MN security association) being
relegated to a separate draft.

Like I said, I think we *really* need to get this document done...

            jak

----- Original Message -----
From: "Charles E. Perkins" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, October 15, 2002 12:30 PM
Subject: Re: [mobile-ip] Binding Authorization data for Binding Update toHome
Agent

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 17 Oct 2002 11:10:26 +0200

> Like I said, I think we *really* need to get this document done...

Yes, we need to.

First of all, how about a specific proposal. Would this be
acceptable?:

    The mobile node and the home agent must have an security association
    to protect this signaling.  Authentication Header (AH) or
    Encapsulating Security Payload (ESP) can be used for integrity
    protection.  For ESP we require that a non-null authentication
    algorithm is applied.

    Besides IPsec, other mechanisms (e.g. Binding Authorization Data
    option) are possible according to separate specifications.

[By the way Charlie, I noticed your original proposal talked about how the
MN calculates the authenticator for the BU, but not about how the HA
calculates it for the BA. Not a biggie, just noting in case the WG
adopts your original proposal.]

There's been a lot of private email on this. I'd like to
bring out some of my thoughts on this subject out on the alias.

Claim: BAD-to-home is "proven technology" as it's similar to what's used
in MIPv4.

I don't believe the MIPv4 experience applies here.
We're looking at a very different animal because
of the importance of encrypting RR signaling. On the other hand,
BAD-to-home would be much more acceptable if it were used
when RO was turned off.

RR by itself is "weaker" security already, not encrypting the
signaling on the HA-MN path just waters it down too much.

So I don't think BAD-to-home can be recommended without fixing
the encryption issue. I see it as an example of how 2 seemingly
reasonable decisions when taken together are a dangerous
idea:

     1. not imposing a MUST on HA-MN MH traffic (it's a SHOULD)
     2. allowing BAD-to-home

Perhaps if we fixed the encryption on the MN-HA path by
using IPsec? Let's see if BAD-to-home and draft-ietf-mobileip-mipv6-ha-ipsec-01.txt
could be used at the same time. Looking at
draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, perhaps doing this:

section 7.2.1.  Binding Updates and Acknowledgements
     --> use BAD-to-home

section 7.2.2.  Return Routability Signaling
section 7.2.3.  Prefix Discovery
section 7.3.4.  Payload Packets
     --> use IPsec as per the ha-ipsec draft.

It seems like it would be possible to not have the IPsec SPD
and SAD entries in 7.2.1 and still have the rest work out
for IPsec (we seem to have the right selectors). Section
7.2.1 seems to have slightly less complexity than section 7.2.2.
This and the fact that there are still 7.2.3 and (possibly) 7.3.4 makes
me think that the overall gain is not quite worth the effort of
using both approeaches together. But it is possible.

Another tack would be to fix the encryption on the HA-MN path by
using a reserved SPI with ESP or specifying an encryption mode
for BAD. Hmmm... More specs to do, hopefully not in the base
MIPv6 document.

The reserved SPI business is not too farfetched. It would
be the 4th example, after SKIP, SUCV, SeND (the charter
announces this approach will be explored). So spose one
did manage to define such a reserved SPI for Kbu usage
with IPsec. One could even define it such that it would
also work for BU's to the CN (by specifying how the
SA would be created on the fly using inline parameters
like the nonce indices).

What this would mean would be that one would no longer
have *ANY* reason to use the binding authorization data
option for anything (you'd just use ESP/AH to protect the MH).
So going down this path should ultimately lead to realizing
that BAD is no longer needed, highlighting that it may be
best not to proliferate its use any more than absolutely
necessary at the moment.

Not sure how to resolve this. Given that this is primarily a
security issue, perhaps we should actively seek advice from
more security folks.

Suggestions?

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Oct 2002 11:46:48 -0700

>     protection.  For ESP we require that a non-null authentication

    For ESP, a non-null authentication algorithm is applied.

>     option) are possible according to separate specifications.

This looks fine to me.

> reasonable decisions when taken together are a dangerous

Agree. Loose analogies are rarely acceptable as design verifiers. They are OK as
motivators, however.

> using IPsec? Let's see if BAD-to-home and
draft-ietf-mobileip-mipv6-ha-ipsec-01.txt
> for BAD. Hmmm... More specs to do, hopefully not in the base

Definitely not in the base.

> SA would be created on the fly using inline parameters

Worth exploring,  I suppose. But wasn't this approach explicitly rejected a year
and a half ago when the whole BU security debate started? If so, then is it
being proposed as an alternative solution today? And why is it any better today?

> best not to proliferate its use any more than absolutely

But wouldn't it still be needed for RR? Also, we use BAD for ABK.

> security issue, perhaps we should actively seek advice from

I think the MIPv6 base spec should be concluded.

I think we should agree on some framework that alternative BU security protocols
can share. If all can share through an IPsec reserved SPI, then that's fine.
Clearly, if the CN and MN share a preexisting security association, then it
should be possible to use IPsec, but if using BAD is a better option for other
security protocols, then I think that should be used.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Mon, 21 Oct 2002 08:15:06 -0700 (PDT)

As of -18, I see absolutely no text at all which describes 
what a CN does with a shared Kbu. Thus it is incorrect to
say that this is already available for the CN.

	      Mike