Subject: RE: [Mip6] RE: Comments on mip6-mn-ident-option-00.txt

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 6 Jan 2005 12:36:21 -0500

Hi Alpesh,

The search of SA DB could be based on any combination of SPI, SRC IP, DST
IP, or NAI. To make the proposed protocol independent of any implementation
I would request to make the SPI 32 bits as it was before. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
alpesh
Sent: Wednesday, January 05, 2005 9:23 PM
To: 'alpesh'; 'Charles E.Perkins'
Cc: 'Mobile IPv6 Mailing List'
Subject: [Mip6] RE: Comments on mip6-mn-ident-option-00.txt

Charlie -

Here is an updated version. Please review it. I may need to update the
General Terms section a bit more. I intend to post it to the WG alias soon.
Thanks for the comments and suggestions.

Alpesh

Network Working Group                                           A. Patel
Internet-Draft                                                  K. Leung
Expires: July 6, 2005                                      Cisco Systems
                                                               M. Khalil
                                                               H. Akhtar
                                                         Nortel Networks
                                                            K. Chowdhury
                                                        Starent Networks
                                                         January 5, 2005

                Authentication Protocol for Mobile IPv6
                  draft-ietf-mip6-auth-protocol-03.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 6, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   IPsec is specified as the sole means of securing all signaling
   messages between the Mobile Node and Home agent for Mobile IPv6.  A
   flexible model for security between the Mobile Node and Home Agent is
   required from the perspective of deployment of the Mobile IPv6

Patel, et al.             Expires July 6, 2005                  [Page 1]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

   protocol.  One instance of such deployment need comes from networks
   that are built on 3GPP2 standards.  This document proposes an
   alternate method for securing the signaling messages that are
   responsible for performing Registration of a Mobile Node at a home
   agent.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   General Terms  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Operational flow . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Mobility message authentication option . . . . . . . . . . . .  7
     5.1   MN-HA authentication mobility option . . . . . . . . . . .  8
       5.1.1   Processing Considerations  . . . . . . . . . . . . . .  9
     5.2   MN-AAA authentication mobility option  . . . . . . . . . .  9
       5.2.1   Processing Considerations  . . . . . . . . . . . . . . 10
     5.3   Authentication Failure Detection at the Mobile Node  . . . 10
   6.  Mobility message replay protection option  . . . . . . . . . . 11
     6.1   Timestamp option . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   10.   Normative References . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   A.  Rationale for mobility message replay protection option  . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 20

Patel, et al.             Expires July 6, 2005                  [Page 2]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

1.  Introduction

   The base Mobile IPv6 specification [RFC3775] specifies the signaling
   messages, Binding Update (BU) and Binding Acknowledgement (BA),
   between the Mobile Node and Home agent to be secured by the IPsec
   Security Associations (IPsec SAs) that are established between these
   two entities.  This security model for Mobile IPv6 does not fit in
   very well for deployment scenarios which:

   1.  rely on the use of a Authentication, Authorization and Accounting
       (AAA) infrastructure for authenticating the subscriber
   2.  require dynamic assignment of Home Agent and home addresses
   3.  have constraints on the number of messages involved in setting up
       IPsec SAs
   4.  include Mobile Nodes that do not support IKEv1

   This indicates the need for a solution that does not necessarily
   require an IPsec SA for securing the signaling messages that deal
   with the Registration process of a Mobile Node with a home agent.

   This document proposes a solution for securing the Binding Update and
   Binding Acknowledgment messages between the Mobile Node and Home
   agent using an authentication option which is included in these
   messages.  Such a mechanism enables IPv6 mobility in a host without
   having to establish an IPsec SA with its Home Agent.  A Mobile Node
   can implement Mobile IPv6 without having to integrate it with the
   IPsec module, in which case the Binding Update and Binding
   Acknowldegement messages (between MN-HA) are secured with the
   authentication option.  It does not imply that the availability of
   such a solution deprecates the use of IPsec for securing Mobile IPv6
   signaling between Mobile Nodes and Home Agents.  Home agents still
   have to implement and support registrations from Mobile Nodes that
   are secured via IPsec as well as with the authentication option.

   The authentication mechanism proposed here is similar to the
   authentication mechanism used in Mobile IPv4 [RFC3344].

Patel, et al.             Expires July 6, 2005                  [Page 3]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

2.  Overview

   This document presents a lightweight mechanism to authenticate the
   Mobile Node at the Home Agent or at the Authentication, Authorization
   and Accounting (AAA) server in Home network (AAAH) based on a shared
   key based security association between the Mobile Node and the
   respective authenticating entity.  This shared key based security
   association (shared-key based SA) may be statically provisioned or
   dynamically created.  The term "security association" referred to in
   this document is understood to be a "shared-key based Mobile IPv6
   authentication" security association.  Mobile Node MUST use only one
   means of authentication, based on either the shared key based
   authentication or IPsec security association.  Home agents still have
   to implement and support registrations from Mobile Nodes that are
   secured via IPsec as well as with the authentication option.

   This document introduces new mobility options to aid in
   authentication of the Mobile Node to the Home Agent or AAAH server.
   The confidentiality protection of Return Routability messages and
   authentication/integrity protection of Mobile Prefix Discovery (MPD)
   is outside the scope of this document.

Patel, et al.             Expires July 6, 2005                  [Page 4]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

3.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD",  "SHOULD  NOT",  "RECOMMENDED",  "MAY",  and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119.

3.1  General Terms

   First (size, input)

      Some formulas in this specification use a functional form "First
      (size, input)" to indicate truncation of the "input" data so that
      only the first "size" bits remain to be used.

Patel, et al.             Expires July 6, 2005                  [Page 5]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

4.  Operational flow

         MN                                                  HA/AAAH
         |                   BU to HA                           |
   (a)   |----------------------------------------------------->|
         | (including MN-ID option [optional],                  |
         |  Message ID option [optional], authentication option)|
         |                                                      |
         |                                                      |
         |                                   HA/AAAH authenticates MN
         |                                                      |
         |                                                      |
         |                  BA to MN                            |
   (b)   |<-----------------------------------------------------|
         | (including MN-ID option [optional],                  |
         |  Message ID option [optional], authentication option)|
         |                                                      |

        Figure 1: Home Registration with Authentication Protocol

   Mobile Node MAY use Mobile Node Identifier Option as defined in
   [MN_Ident] or Home Address to identify itself while authenticating
   with the Home Agent.  The mobile node MUST use the Mobile Node
   Identifier option as defined in [MN_Ident] to identify itself while
   authenticating with the AAA infrastructure.

   Mobile Node MAY use Message Identifier option as defined in Section 6
   for additional replay protection.

Patel, et al.             Expires July 6, 2005                  [Page 6]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

5.  Mobility message authentication option

   This section defines the message authentication mobility option that
   may be used to secure Binding Update and Binding Acknowledgement
   messages.  This option can be used along with IPsec or preferably as
   an alternate mechanism to authenticate Binding Update and Binding
   Acknowledgement messages in absence of IPsec.

   This document also defines subtype numbers, which identify the mode
   of authentication and the peer entity to authenticate the message.
   Two subtype numbers are specified in this document.  It is expected
   that other subtypes will be defined by other documents in the future.

   Only one instance of an authentication option of a particular subtype
   can be present in the message.  One message may contain multiple
   instances of authentication options with different subtype values.

   When a Binding Update or Binding Acknowledgement is received without
   an authentication option and the entity receiving it is configured to
   use authentication option or has the shared-key based security
   association for authentication option, the entity should silently
   discard the received message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  Option Type  | Option Length |  Subtype      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              SPI              | Authentication Data ....
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                Figure 2

      Option Type:

         AUTH-OPTION-TYPE to be defined by IANA.  An 8-bit identifier of
         the type mobility option.

      Option Length:

         8-bit unsigned integer, representing the length in octets of
         the Sub-type, Security Parameter Index (SPI) and Authentication
         Data fields.

      Subtype:

Patel, et al.             Expires July 6, 2005                  [Page 7]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

         A number assigned to identify the entity and/or mechanism to be
         used to authenticate the message.

      SPI:

         Security Parameter Index

      Authentication Data:

         This field has the information to authenticate the relevant
         mobility entity.  This protects the message beginning at the
         Mobility Header upto and including the SPI field.

      Alignment requirements :

         This option does not have any specific alignment requirements.

5.1  MN-HA authentication mobility option

   The format of the MN-HA authentication mobility option is as defined
   in Figure 2.  This option uses the subtype value of 1.  The MN-HA
   authentication mobility option is used to authenticate the Binding
   Update and Binding Acknowledgement messages based on the shared-key
   based security association between the Mobile Node and the Home
   Agent.

   The shared-key based security association between Mobile Node and
   Home Agent as per this specification consists of a SPI, a key, an
   authentication algorithm and the replay protection mechanism in use.
   The SPI is a number in range [0-65535], where the range [0-255] is
   reserved.  The key consists of an arbitrary value and is 16 octets in
   length.  The authentication algorithm is HMAC_SHA1.  The replay
   protection mechanism may use the Sequence number as specified in
   [RFC3775] or the option as defined in Section 6.  If the Timestamp
   option is used for replay protection as defined in Section 6.1, the
   security association includes a "close enough" field to account for
   clock drift.  A default value of 7 seconds MAY be used.  This value
   SHOULD be greater than 3 seconds.

   This must be the last option in a message with mobility header if it
   is the only authentication option in the message.  It must occur
   before the MN-AAA Section 5.2 authentication option if both options
   are present in the message.

   The authentication data is calculated on the message starting from
   the mobility header upto and including the SPI value of this option.

   Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility

Patel, et al.             Expires July 6, 2005                  [Page 8]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

   Data))

   Mobility Data = care-of address | home address | Mobility Header(MH)
   Data

   MH Data is the content of the Mobility Header upto and including the
   SPI field of this option.

   The first 96 bits from the MAC result are used as the Authentication
   Data field.

5.1.1  Processing Considerations

   The assumption is that Mobile Node has a shared-key based security
   association with the Home Agent.  Mobile Node MUST include this
   option in a BU if it has a shared-key based security association with
   the Home Agent.  Home Agent MUST include this option in the BA if it
   received this option in the corresponding BU and Home Agent has a
   shared-key based security association with the Mobile Node.

   Mobile Node or Home Agent receiving this option MUST verify the
   authentication data in the option.  If authentication fails, Home
   Agent MUST send BA with Status Code MIPV6-AUTH-FAIL.  If Home Agent
   does not have shared-key based SA, Home Agent MUST discard the BU.
   Home Agent MAY log such events.

5.2  MN-AAA authentication mobility option

   The format of the MN-AAA authentication mobility option is as defined
   in Figure 2.  This option uses the subtype value of 2.  The MN-AAA
   authentication mobility option is used to authenticate the Binding
   Update message based on the shared security association between
   Mobile Node and AAA server in Home network (AAAH).  It is not used in
   Binding Acknowledgement messages.  The corresponding Binding
   Acknowledgement messages must be authenticated using the MN-HA
   authentication option.

   This must be the last option in a message with mobility header.  If
   both Mobile-Home and Mobile-AAA authentication mobility options are
   present, the Mobile-Home Authentication option MUST appear prior to
   the Mobile-AAA Authentication option.  The corresponding response
   MUST include the Mobile-Home Authentication option, and MUST NOT
   include the Mobile-AAA Authentication option.

   The Mobile Node MAY use Mobile Node Identifier option [MN_Ident] to
   enable the Home Agent to make use of available AAA infrastructure.

   The authentication data is calculated on the message starting from

Patel, et al.             Expires July 6, 2005                  [Page 9]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

   the mobility header upto and including the SPI value of this option.

   The authentication data shall be calculated as follows:

   Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)

   hash_fn() is decided by the value of SPI field in the authentication
   option.

   SPI = HMAC_SHA1_SPI:

   hash_fn() is HMAC_SHA1.  When HMAC_SHA1_SPI is used, the BU is
   authenticated by AAA using HMAC_SHA1 authentication.

   MAC_Mobility Data = SHA1(care-of address | home address | MH Data)

   MH Data is the content of the Mobility Header upto and including the
   SPI field of this option.

5.2.1  Processing Considerations

   When the Home Agent receives a Binding Update with the Mobile-AAA
   authentication option, the Binding Update is authenticated by an
   entity external to the Home Agent, typically a AAA server.

5.3  Authentication Failure Detection at the Mobile Node

   In case of authentication failure, the Home Agent MUST send a Binding
   Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node,
   if an SA to be used between Mobile Node and Home Agent for
   authentication exists.

   Upon receiving a Binding Acknowledgement with status code
   MIPV6-AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding
   Updates to the Home Agent.

Patel, et al.             Expires July 6, 2005                 [Page 10]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

6.  Mobility message replay protection option

   The Mobility message replay protection option MAY be used in a
   Binding Update/Binding Acknowledgement messages when authenticated
   using the mobility message authentication option as described in
   Section 5.

   The mobility message replay protection option is used to let the Home
   Agent verify that a Binding Update has been freshly generated by the
   Mobile Node, not replayed by an attacker from some previous Binding
   Update.  The mobility message replay protection option when included
   is used by the Mobile Node for matching BA with BU.

   The subtype field in the option specifies the style of replay
   protection used.  This document specifies timestamps as one style of
   replay protection, as described in Section 6.1.  The Replay
   Protection Data field in the replay protection option in a new
   Binding Update MUST not be the same as in an immediately preceding
   Binding Update.

   The style of replay protection in effect between a Mobile Node and
   the Home Agent is part of the shared-key based mobility security
   association.  A Mobile Node and the Home Agent MUST agree on which
   method of replay protection will be used (even though the security
   association may be dynamically derived.  This can be done as part of
   policy at the Home Agent).

   If the policy at Home Agent mandates replay protection using this
   option (as opposed to the sequence number in Mobility Header in
   Binding Update) and the Binding Update from Mobile Node does not
   include this option, Home Agent discards the BU and sets the Status
   Code in BA to MIPV6-MESG-ID-REQD.

   When mobility message replay protection option is used along with
   authentication option, the Mobile Node SHOULD set the Sequence Number
   in the mobility header in Binding Update to 0 and SHOULD ignore the
   Sequence Number in Mobility Header in BA.  When the Home Agent
   receives the mobility message replay protection option in Binding
   Update, it should include the mobility message replay protection
   option in Binding Acknowledgement.  Appendix A provides details
   regarding why the mobility message replay protection option MAY be
   used when using the authentication option.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  Option Type  | Option Length |   Subtype     |

Patel, et al.             Expires July 6, 2005                 [Page 11]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Replay Protection Data ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                Figure 3

      Option Type:

         MESG-ID-OPTION-TYPE to be defined by IANA.  An 8-bit identifier
         of the type mobility option.

      Option Length:

         8-bit unsigned integer, representing the length in octets of
         the Subtype and Replay Proection Data field.

      Subtype:

         8-bit unsigned integer indicating the style of replay
         protection in use.

      Replay Proection Data :

         The Replay Protection Data field carries Subtype specific data
         for replay protection.

      Alignment requirements :

         This option does not have any specific alignment requirements.

6.1  Timestamp option

   The format of the timestamp mobility option is as defined in Section
   6.  This option uses the subtype value of 1.  The Replay Protection
   Data field carries timestamp for replay protection.

   The basic principle of timestamp replay protection is that the node
   generating a message inserts the current time of day, and the node
   receiving the message checks that this timestamp is sufficiently
   close to its own time of day.  Unless specified differently in the
   shared-key based security association between the nodes, a default
   value of 7 seconds MAY be used to limit the time difference.  This
   value SHOULD be greater than 3 seconds.  Obviously the two nodes must
   have adequately synchronized time-of-day clocks.

   The Mobile Node MUST set the Replay Protection Data field to a 64-bit

Patel, et al.             Expires July 6, 2005                 [Page 12]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

   value formatted as specified by the Network Time Protocol [RFC1305].
   The low-order 32 bits of the NTP format represent fractional seconds,
   and those bits which are not available from a time source SHOULD be
   generated from a good source of randomness.  Note, however, that when
   using timestamps, the 64-bit Replay Protection Data used in a Binding
   Update from the Mobile Node MUST be greater than that used in any
   previous Binding Update.

   After successful authentication of Binding Update (either locally at
   the Home Agent or when a success indication is received from the AAA
   server), the Home Agent MUST check the Replay Protection Data field
   for validity.  In order to be valid, the timestamp contained in the
   Replay Protection Data field MUST be close enough to the Home Agent's
   time of day clock and the timestamp MUST be greater than all
   previously accepted timestamps for the requesting Mobile Node.

   If the timestamp is valid, the Home Agent copies the entire Replay
   Protection Data field into the Replay Protection Data field in the BA
   it returns to the Mobile Node.  If the timestamp is not valid, the
   Home Agent copies only the low-order 32 bits into the BA, and
   supplies the high-order 32 bits from its own time of day.

   If the timestamp field is not valid but the authentication of the BU
   succeeds, Home Agent MUST send a Binding Acknowledgement with status
   code MIPV6-ID-MISMATCH.  Home Agent does not create a binding cache
   entry if the timestamp check fails.

   If the Mobile Node receives a Binding Acknowledgement with the code
   MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by
   processing the MN-HA authentication mobility option.

   If authentication succeeds, the Mobile Node MUST adjust its timestamp
   and send subsequent Binding Update using the updated value.

   Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH
   status code, the Mobile Node MUST compare the Replay Protection Data
   value in the BA to the Replay Protection Data value it sent in the
   corresponding BU.  If the values match, the Mobile Node proceeds to
   process the MN-HA authentication data in the BA.  If the values do
   not match, the Mobile Node silently discards the BA.

Patel, et al.             Expires July 6, 2005                 [Page 13]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

7.  Security Considerations

   This document proposes new authentication options to authenticate the
   control message between Mobile Node, Home Agent and/or home AAA (as
   an alternative to IPsec).  The new options provide for authentication
   of Binding Update and Binding Acknowledgement messages.  The MN-AAA
   authentication options provides for authentication with AAA
   infrastructure.  It can be used to generate a per session key between
   Mobile Node and Home Agent for subsequent authentication of BU/BA
   between Mobile Node and Home Agent via the MN-HA authentication
   option.

   This memo also introduces an optional replay protection mechanism
   Section 6, to prevent replay attacks.  The sequence number field in
   the Binding Update is not used if this mechanism is used.  This memo
   defines the timestamp option to be used for mobility message replay
   protection.

Patel, et al.             Expires July 6, 2005                 [Page 14]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

8.  IANA Considerations

   IANA services are required for this specification.  The values for
   new mobility options and status codes must be assigned from the
   Mobile IPv6 [RFC3775] numbering space.

   The values for Mobility Option types AUTH-OPTION-TYPE and
   MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6 need to be
   assigned.  The suggested values are 8 for the AUTH-OPTION-TYPE and 9
   for the MESG-ID-OPTION-TYPE Mobility Option.

   The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and
   MIPV6-MESG-ID-REQD as defined in Section 6.1, Section 6 and Section
   5.3 also need to be assigned.  The suggested values are 144 for
   MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for
   MIPV6-AUTH-FAIL.

   IANA should record values for these new Mobility Options and the new
   Status Codes.

   A new section for enumerating algorithms identified by specific SPIs
   within the range 0-255 is to be added to

   http://www.isi.edu/in-notes/iana/assignments/mobility-parameters

   The currently defined values are as follows:

   The value 0 should not be assigned.

   The value 3 is suggested for HMAC_SHA1_SPI as defined in section
   Section 5.2.

   The value 5 is reserved for use by 3GPP2.

   New values for this namespace can be allocated using Standards Action
   [RFC2434].

   In addition, IANA needs to create a new namespace for the subtype
   field of the MN-HA and MN-AAA authentication mobility options under

   http://www.isi.edu/in-notes/iana/assignments/mobility-parameters

   The currently allocated values are as follows:

   MN-HA authentication mobility option Section 5.1	[1]

   MN-AAA authentication mobility option Section 5.2	[2]

Patel, et al.             Expires July 6, 2005                 [Page 15]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

   New values for this namespace can be allocated using Standards Action
   [RFC2434].

Patel, et al.             Expires July 6, 2005                 [Page 16]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

9.  Acknowledgements

   The authors would like to thank Basavaraj Patil, Charlie Perkins
   Vijay Devarapalli and Jari Arkko for their thorough review and
   suggestions on the document.  The authors would like to acknowledge
   the fact that a similar authentication method was considered in base
   protocol [RFC3775] at one time.

10  Normative References

   [MN_Ident]
              Patel et. al., A., "Mobile Node Identifier Option for
              Mobile IPv6", draft-ietf-mip6-mn-ident-option-01.txt (work
              in progress), December 2004.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC3775]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

Authors' Addresses

   Alpesh Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   US

   Phone: +1 408-853-9580
   EMail: [email-masked]

Patel, et al.             Expires July 6, 2005                 [Page 17]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

   Kent Leung
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   US

   Phone: +1 408-526-5030
   EMail: [email-masked]

   Mohamed Khalil
   Nortel Networks
   2221 Lakeside Blvd.
   Richardson, TX  75082
   US

   Phone: +1 972-685-0574
   EMail: [email-masked]

   Haseeb Akhtar
   Nortel Networks
   2221 Lakeside Blvd.
   Richardson, TX  75082
   US

   Phone: +1 972-684-4732
   EMail: [email-masked]

   Kuntal Chowdhury
   Starent Networks
   2540 Coolwater Dr.
   Plano, TX  75025
   US

   Phone: +1 214 550 1416
   EMail: [email-masked]

Patel, et al.             Expires July 6, 2005                 [Page 18]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

Appendix A.  Rationale for mobility message replay protection option

   Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility
   header to prevent replay attacks.  There are two aspects that stand
   out in regards to using the Sequence Number to prevent replay
   attacks.

   Firstly, the specification states that Home Agent should accept a BU
   with a Sequence Number greater than the Sequence Number from previous
   Binding Update.  This implicitly assumes that the Home Agent has some
   information regarding the Sequence Number from previous BU (even when
   the binding cache entry is not present).  Secondly, the specification
   states that if the Home Agent has no binding cache entry for the
   indicated home address, it MUST accept any Sequence Number value in a
   received Binding Update from this Mobile Node.

   With the mechanism defined in this draft, it is possible for the
   Mobile Node to register with a different Home Agent during each
   mobility session.  Thus, it is unreasonable to expect each Home Agent
   in the network to maintain state about the Mobile Node.  Also, if the
   Home Agent does not cache information regarding sequence number, as
   per the second point above, a replayed BU can cause a Home Agent to
   create a binding cache entry for the Mobile Node.  Thus, when
   authentication option is used, Sequence Number does not provide
   protection against replay attack.

   One solution to this problem (when Home Agent does not save state
   information for every Mobile Node) would be for the Home Agent to
   reject the first BU and assign a (randomly generated) starting
   sequence number for the session and force the Mobile Node to send a
   fresh BU with the suggested sequence number.  While this would work
   in most cases, it would require an additional round trip and this
   extra signalling and latency is not acceptable in certain deployments
   (3GPP2).  Also, this rejection and using sequence number as a nonce
   in rejection is a new behavior that is not specified in [RFC3775].

   Thus, this specification uses the mobility message replay protection
   option to prevent replay attacks.  Specifically, timestamps are used
   to prevent replay attacks as described in Section 6.1.

   It is important to note that as per Mobile IPv6 [RFC3775] this
   problem with sequence number exists.  Since the base specification
   mandates the use of IPsec (and naturally that goes with IKE in most
   cases), the real replay protection is provided by IPsec/IKE.  In case
   of BU/BA between Mobile Node and CN, the liveness proof is provided
   by the use of nonces which the CN generates.

Patel, et al.             Expires July 6, 2005                 [Page 19]

Internet-Draft    Authentication Protocol for Mobile IPv6   January 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Patel, et al.             Expires July 6, 2005                 [Page 20]


_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6