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

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 24 Sep 2001 10:40:04 +0200

Hi Charlie,

I gather from what's below that you're now aiming at putting
the authentication data into a destination sub-option - that seems reasonable
(I guess that it allows for more elegant interworking with other authentication 
mechs (e.g., IP SEC AH)).

Other Comments (for what they are worth) are inside.

Regards,
Karen

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: 20. september 2001 21:17
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] -14 Authentication Data computation
> 
> 
> 
> 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

I think, one shouldn't specify where the CoA and Home Address can be found. I find 
it slightly confusing since the (at least conceptual) location of these addresses might have 
been interchanged due to prior IP SEC processing of the packet in case some SA applies to the packet as a hole.

>     -  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.
> 
I do not see why it is important to specify that ESP cannot be used.
The specification below which clearly states that any alternative authentication
mechs MUST cover the data specified above should be sufficient.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Sep 2001 14:53:26 -0700

Hello Karen,

> mechs (e.g., IP SEC AH)).

Yes, thanks, I have indeed put the authentication data into a sub-option
as part of the revisions for draft ...-15

>>     -  The IPv6 address of the destination of the packet, as seen by the
>>        recipient

> I think, one shouldn't specify where the CoA and Home Address can be found.
> I find it slightly confusing since the (at least conceptual) location of these
> addresses might have been interchanged due to prior IP SEC processing of the
> packet in case some SA applies to the packet as a hole.

O.K.  I will try to figure out how to make this change.  In particular,
something needs to be said when the care-of address is in the
Alternate Care-of Address Sub-Option.

>>    requires use of ESP [12], for example to encrypt the transport layer

The original intention was to say that ESP couldn't be used *in transport mode*.
I don't think there is any prohibition against using ESP in tunnel mode.
Does this alleviate your concern?

Regards,
Charlie P.