Subject: [mobile-ip] Binding Authorization data for Binding Update to Home Agent

From: Charlie Perkins <[email-masked]>
Date: Thu, 10 Oct 2002 17:06:59 -0700

Hello folks,

In Mobile IPv4, there is a Mobile-Home Authentication extension that is
useful for authenticating the Registration Request.

In Mobile IPv6, the analogous feature is the Binding Authorization Data
option to the Binding Update.

In both cases, the home agent can have a predetermined security
association
with the mobile node which allows computation and verification of the
security data (the Authenticator field within the Binding Authorization
Data
option).  The calculation for the fields are different between IPv4 and
IPv6, because in the latter case ONLY the fields of the Binding Update
and the associated addresses are used as input data.  However, that is
sufficient for the purpose of validating the Binding Update.

The calculation for the Binding Authorization Data field is already
specified
in the context of the Binding Update and the Binding Acknowledgement
for Mobility Headers sent to and from a correspondent node.  The exact
same calculation is equally valid for use with a Mobility Header sent to
or
from a Home Agent.  The strength of the security association would be
stronger, since it was established by means other than Return
Routability.
In fact, it would be just as good as exists today for Mobile IPv4, and
no one
has ever observed a weakness to that protocol operation.

The proposal is simply to recognize this fact within the specification.
The proposed revision to paragraph 1 of section 5.1 follows:

   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.  When the Binding Update to the Home Agent is
   protected by use of the Binding Authorization Data option, the mobile

   node calculates the authenticator field as described in section ??,
   using the home agent's address as the final destination address.  In
   this case, Kbu is a shared secret between the mobile node and the
   home agent.

The ?? refers to a section which documents the method by which the
Authenticator field is calculated for Mobility Header messages, which
is exactly the same as has been previously specified for the Binding
Update and Binding Acknowledgment messages to and from the
Correspondent node using, again, Kbu.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 11 Oct 2002 09:33:32 -0700

Hi Charlie,

I generally support your idea, but I am not sure whether putting this specific
text in is the right way to accomplish it. I think it might be too limiting.

In particular,  I would like to make it possible to use the Binding
Authorization Data option in a BU sent to a CN to carry a MAC calculated with
shared keys that have been established by algorithms other than by RR. This is
specified in draft-okazaki-mobileip-abk-01.txt for securing BUs using ABK
instead of RR, for example. This would also include your idea of using the MN-HA
shared key for this purpose.

I think it would be OK to specify one way to calculate the MAC, as long as the
actual source of the shared key is not limited to just the key established by
RR. It might even be desirable to specify a particular algorithm for calculating
the MAC, since it could be shared between the different uses (if this is
technically possible without limiting the key in a way that would preclude a
particular use) thus fostering better interoperability.

Does this make sense?

                jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 11 Oct 2002 10:35:15 -0700

Hello James,

Thanks for your comments.

> shared key for this purpose.

O.K.  I agree this should not be prohibited by the text.
If you happen to notice a place that prohibits it, please
let me know in case I miss it.

> particular use) thus fostering better interoperability.

So far, we've used HMAC_SHA1.  How about that?

> Does this make sense?

Yes, eminently so in my opinion!

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 11 Oct 2002 12:54:19 -0700 (PDT)

> shared key for this purpose.

   Absent real key management -- and I stress the word
   "management" -- I find this entire proposition extremely
   dubious. Just handwaving away this issue -- or worse,
   trying to tackle it in this WG -- would be a big mistake.

   And while I'm at it, I wish the IESG and/or IAB would
   make up its mind about whether AAA should be used as
   the basis of key management. The nether world it lives
   in right now is not condusive to well thought out 
   design and invites lots of one-off hackery which is
   not well reviewed by people who should be reviewing
   it. Either formalize the use of AAA keying, or stop
   its proliferation; the current state of affairs is
   dangerously suboptimal. We do not need any WEP-like
   debacles.

		Mike

---

From: "James Kempf" <[email-masked]>
Date: Fri, 11 Oct 2002 13:09:36 -0700

> So far, we've used HMAC_SHA1.  How about that?

Sounds good.

            jak