Subject: Re: [mobile-ip] -14 Authentication Data computation

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Sep 2001 12:16:44 -0700

Hello Karen,

"Karen E Nielsen (TED)" wrote:
> 
> Comment/question to the computation of the Authentication Data covering
> a Binding Update and a Binding Acknowledgement in draft -14.
> 
> According to section 4.4 in draft-14 the Authentication Data covering
> a Binding Updata MUST be computed over a bit string containing the
> following IP addresses:
>	Destination IP Address of the IPv6 header
>	Care-of Address, in the Source IP Address of the IPv6 header
>	Home Address, from the Home Address destination option
>	+ some more data
> 
> And the Authentication Data covering a Binding Acknowledgement MUST be
> computed over a bit string containing the following IP addresses :
>	Destination IP Address of the IPv6 header
>	Source IP Address of the IPv6 header
>	+ some more data
> 
> First of all I suppose that what is meant is the destination addresses
> of the IPv6 header as it appears at the receiver end (in line with the
> computation of authentication data in IP SEC)  !?   Since both the BU
> (in case the CN is mobile) and the BUAck might be send using a routing
> header this will be important to specify, I think.

I agree!

> Secondly, in the case where the CN is itself a mobile node, the source
> address of the IP header of the BuAck will be a CoA of the CN,
> which really has nothing to do with the acknowledgement of a BU sent
> to the CN - wouldn't the appropriate address to cover here be the Home
> address of the CN -  either appearing in the source address of the IP
> header or in the Home Address option ?

Again, I agree!  Thank you for pointing out these problems.

Here is the new text for section 4.4:

=======================================================================
4.4. Authentication Requirements for Binding Update and Acknowledgement

   Any packet that includes a Binding Update or Binding Acknowledgement
   option has to contain some Authentication Data to guard against
   malicious Binding Updates or Acknowledgements.  The way that
   the Authentication Data is computed has to provide sender
   authentication, data integrity protection, and replay protection.
   This section specifies requirements for which data is to be protected
   when the Authentication Data Sub-Option is used to supply the
   necessary authentication data for the Binding Update or Binding
   Acknowledgement.  Every IPv6 node which supports transmission or
   reception of these destination options MUST support the computation
   of the Authentication Data Sub-Option according to the rules in
   this section.  The Authentication Data Sub-Option MUST be the last
   Sub-Option contained within any destination option in which the
   Authentication Data Sub-Option occurs.

   The Authentication Data covering a Binding Update or MUST be computed
   over a bitstring containing the following fields of the IPv6 header
   and destination options, in order:

    -  The IPv6 address of the destination of the packet, as seen by the
       recipient
    -  Care-of Address, in the Source IP Address of the IPv6 header
    -  The Home Address of the mobile node, from the Home Address
       destination option
    -  Option Type of the Binding Update destination option
    -  Option Length of the Binding Update destination option
    -  All flags of the Binding Update destination option
    -  Reserved Field of the Binding Update destination option
    -  Sequence Number Field of the Binding Update
    -  Lifetime of the Binding Update destination option
    -  The entire data from all Binding Update Sub-Options (except the
       Authentication Data suboption), if any others exist
    -  The Type (i.e., the 8-bit value 0x04) and the Length of the
       Authentication Data Sub-Option
    -  Security Parameters Index (SPI) of the Authentication Data
       Sub-Option

   When a Routing Header is used to deliver the Binding Update to
   the receiving node, the address to be used for the Destination IP
   Address part of the computation will initially be located as the last
   component of the Routing Header.  Otherwise, the address to be used
   will be the Destination IP Address in the IPv6 header of the outgoing
   packet.

   When the Authentication Data Sub-Option is used with a Binding
   Acknowledgement, the Authentication Data MUST be computed over a
   bitstring containing the following data, in order:

    -  The IPv6 address of the destination of the packet, as seen by the
       recipient
    -  The Home Address of the sender
    -  Option Type of the Binding Acknowledgement destination option
    -  Option Length of the Binding Acknowledgement
    -  Status of the Binding Acknowledgement
    -  Sequence Number field of the Binding Acknowledgement
    -  Lifetime field of the Binding Acknowledgement destination option
    -  Refresh field of the Binding Acknowledgement destination option
    -  The entire data from all Binding Acknowledgement Sub-Options
       (except the Authentication Data suboption), if any others exist
    -  The Type (i.e., the 8-bit value 0x04) and the Length of the
       Authentication Data Sub-Option
    -  Security Parameters Index (SPI) of the Authentication Data
       Sub-Option

   When a Home Address destination option is used to deliver the Binding
   Acknowledgement to the receiving node, the Home Address of the sender
   will be located in that destination option.  Otherwise, the Home
   Address of the sender will be located in the Source IP Address field
   of the IPv6 header.

   If a Security Association applied to the packet for other reasons
   requires use of ESP [12], for example to encrypt the transport layer
   data carried in the packet, this use of ESP is not sufficient to
   satisfy the authentication requirements of Mobile IPv6.

   Authentication Data assuring the integrity of Binding Updates and
   Binding Acknowledgement MAY, in some cases, instead be supplied by
   other authentication mechanisms outside the scope of this document
   (e.g., IPsec [13]).  When alternative mechanisms are used, the same
   data as indicated above MUST be included as part of the input data
   stream for the authentication algorithm; however (according to the
   requirements of the alternative authentication algorithm) the order
   of the data elements in the input data stream MAY be changed from the
   order specfied within this section for use with the Authentication
   Data Sub-Option (see section 5.5).

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

Note: the exact wording and placement of this text is likely to
change if I find further problems.  Maybe it should be two subsections
instead of one.  Maybe there should be two Authentication Data
Sub-Options instead of one.

Comments?

> /Karen

Regards,
Charlie P.