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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 11 Oct 2002 18:48:49 +0200

=> This proposal seems to allow two different ways of 
securing BUs to the HA: IPsec or binding authorisation data, right?
What is the advantage of having two different methods? 

Hesham

---

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

Hello Hesham,

> What is the advantage of having two different methods?

The advantage of having the possibility for Kbu used for
authentication of Binding Updates to the home agent is
that a home agent and mobile node can use a predetermined
security association to authenticate Binding Updates.  As
I pointed out in my note below (included for reference)
this is known to work from Mobile IPv4, and is also important
to enable manual configuration approaches.  James Kempf
points out that it will be important as well for other
future techniques .

Regards,
Charlie P.

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