Network Working Group                                           A. Patel
Internet-Draft                                                  K. Leung
Expires: December 31, 2004 May 2, 2005                                       Cisco Systems
                                                                M. Khalil
                                                                H. Akhtar
                                                             K. Chowdhury
                                                          Nortel Networks
                                                            July 2,
                                                            November 2004

                 Authentication Protocol for Mobile IPv6
                  draft-ietf-mip6-auth-protocol-00.txt
                   draft-ietf-mip6-auth-protocol-01.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 December 31, 2004. May 2, 2005.

Copyright Notice

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

Abstract

   This document defines new mobility options to enable authentication
   between mobility entities.  These options can be used in addition to
   or in lieu of

    IPsec to authenticate mobility messages is specified as defined in the base 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 specification.
    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.  Motivation .  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
    4.  General Terms  .  Operational flow . . . . . . . . . . . . . . . . . . . . . . .  6
    5.  Operational flow  Mobility message authentication option . . . . . . . . . . . .  7
      5.1   MN-HA authentication mobility option . . . . . . . . . . .  7
   6.  Mobility message authentication option  8
        5.1.1   Processing Considerations  . . . . . . . . . . . .  8
     6.1   MN-HA . .  9
      5.2   MN-AAA authentication mobility option  . . . . . . . . . . .  9
     6.2   MN-AAA authentication mobility option  . .
        5.2.1   Processing Considerations  . . . . . . . .  9
       6.2.1   Processing considerations . . . . . . 10
      5.3   Authentication Failure Detection at the MN . . . . . . . . 10
   7.
    6.  Mobility message identification option . . . . . . . . . . . . 11
     7.1   Processing considerations
      6.1   Timestamp option . . . . . . . . . . . . . . . . . . . . . 12
       7.1.1   Home Agent
    7.  Security Considerations  . . . . . . . . . . . . . . 12
       7.1.2   Mobile Node Considerations . . . . . 14
    8.  IANA Considerations  . . . . . . . . . 12
       7.1.3   AAA server Considerations . . . . . . . . . . . . 15
    9.  Acknowledgements . . . 13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations . 16
    10.   Normative References . . . . . . . . . . . . . . . . . . . . 15
   10.   Acknowledgements 16
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
   11.   Normative References
    A.  Authentication using CHAP  . . . . . . . . . . . . . . . . . . 18
      A.1   Processing considerations  . . . 16
       Authors' Addresses . . . . . . . . . . . . . 18
      A.2   Mapping BU to Radius Attributes  . . . . . . . . . 16 . . . . 18
      A.3   Processing of Radius response  . . . . . . . . . . . . . . 18
    B.  Rationale for message identification option  . . . . . . . . . 20
        Intellectual Property and Copyright Statements . . . . . . . . 18 21

1.  Motivation  Introduction

    The base specification of Mobile IPv6 specification [RFC3775] mandates IPsec
   support between MN specifies the signaling
    messages, Binding Update (BU) and HA for authentication.  Also, return
   routability messages passing via Binding Acknowledegment (BA),
    between the HA (HoT/HoTi) Mobile node and mobile prefix
   discovery messages must Home agent to be protected using IPsec.

   While IPsec (ESP) may offer strong protection (depending on secured by the
   algorithms used), use of IPsec may not be required/feasible in all
   cases where SA
    that is established between these two entities.  This security model
    for Mobile IPv6 may be used.  For small handheld devices, does not fit in very well for deployment scenarios
    which:

    1.  rely on the use of IPsec may be too taxing on battery and processor performance.
   Also depending on a AAA infrastructure for authenticating the model
        subscriber
    2.  require dynamic assignment of home agent deployment (HA deployed by
   enterprise/service provider), MN may have to VPN back into the
   enterprise (which may impose dual IPsec requirement on MN).

   Moreover, IPsec/IKE based Mobile IPv6 over public wireless carrier's
   networks may pose serious capacity and scalability challenge.  The
   multiple round trips to perform ISAKMP/IKE to establish IPsec SA may
   be too taxing home addresses
    3.  have constraints on the wireless link, not to mention increase in setup
   latency during initial access and during handoffs.  The use number of manual
   IPsec SA messages involved in these large public network deployments suffer from
   scalability issue and involve provisioning nightmare.

   Also, having an authentication mechanism tied to the Mobile's home IP
   address does not permit the mobility entity to derive or acquire a
   dynamic home address based on the configured prefix.  If the MN's
   home address is dynamically configured based on setting up
        a fixed prefix or
   acquired during network access authentication (PPP, 802.1x etc.),
   IPsec will most likely security association using protocols like IKEv1
    4.  include mobile nodes that do not work as the IPsec SAs are tied to the
   address. support IKEv1

    The mechanism described in this draft conclusion drawn thereby is not tied with
   mobility entities home IP address and therefore the need for a solution that does not mandate SA
   relationship with
    necessarily require an IP address.

   Another important motivation IPsec SA for this proposed mechanism is to allow securing the MN to register signaling messages
    that deal with the Registration process of a Home Agent on mobile node with a dynamically discovered Home
   Link. home
    agent.

    This sort of Dynamic Home Link assignments will allow the
   operators to leverage the true benefit of dynamic Home Agent
   assignment.  For example the operator may assign document proposes a Home Link or Home
   Agent solution for securing the user that is closest to the subnet of attachment of Binding update and
    Binding acknowledgment messages between the
   user.  There may be various other reasons for opportunistic Mobile node and Home
   Agent assignment.  The mechanisms described in the draft allows the
   MN
    agent using an authentication option which is included in these
    messages.  Such a mechanism enables IPv6 mobility in hosts without
    having to register establish an IPsec SA with any Home Agent in the its home network as long as the
   MN user shares security association agent.  A mobile node
    can implement Mobile IPv6 without having to integrate it with an entity the
    IPsec module, in which case the home
   network Binding update and Binding
    Acknowldegement messages (between MN-HA) are secured with the
    authentication option.  It should be noted that it does not imply
    that the availability of such as a AAA server. solution deprecates the use of IPsec
    for securing Mobile IPv6 signaling between MNs and HAs.  Home agents
    however have to implement and support registrations from mobile nodes
    that are secured via IPsec as well as with the authentication option.

2.  Overview

    This document presents a lightweight mechanism to authenticate the MN
    at the HA or at the Home AAA based on a shared security association
    between the MN and the respective authenticating entity.

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

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.

4.  General Terms

   MN      Mobile Node

   HA      Home Agent

   SA      Security Association

   IPsec   IP Security protocol

   ESP     Encapsulating security protocol

   BU      Binding Update

   BA      Binding Acknowledgement

   SPI     Security Parameter Index

   MH      Mobility Header

   HAAA    Home Authentication Authorization Accounting server

   CHAP    CHallenge Authentication Protocol

   HoA     Home Address

   AVP     Attribute Value Pair

   AAA     Authentication Authorization Accounting

   NAI     Network Address Identifier

5.  Operational flow

          MN                                                  HA/HAAA
          |                   BU to HA                           |
    (a)   |---------------------------------------------------->|   |----------------------------------------------------->|
          | (HoA option, NAI[optional], MN-ID option [optional],                |
          |  Message ID option, auth option) option [optional], authentication option)|
          |                                                      |
          |                                                      |
          |                                   HA/HAAA authenticates MN
          |                                                      |
          |                                                      |
          |                  BA to MN                            |
    (b)   |<----------------------------------------------------|   |<-----------------------------------------------------|
          | (HoA    (RH-2 option, NAI[optional], MN-ID option [optional],            |
          |     Message ID option, option [optional], auth option)       |
          |                                                      |
         |                                                     |

    MN may MAY use NAI option as defined in [NAI] [MN_Ident] to identify itself to the
   HA
    while authenticating with the HA.  The HA or AAA infrastructure.

    MN SHOULD MAY use NAI Message Identifier option
   [NAI] while authenticating with the AAA infrastructure.

6. as defined in Section 6 for
    replay protection.

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 extension can be used along with IPsec or preferably
    as an alternate mechanism to authenticate binding update Binding Update and binding
   acknowledgement 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.

       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

    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 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  |  Subtype Option Length |          SPI  Subtype      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          SPI                                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Authenticator . . .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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, SPI and authenticator, not including the Option
         Type Sub-type, Security Parameter Index (SPI) and Option Length Authenticator
          fields.

       Subtype:

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

       SPI:

          Used to identify the particular security association to use to
          authenticate the message.

       Authenticator:

          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 :

         MUST be aligned on an 8-octet boundary.

6.1

          The alignment requirement for this option is 4n + 1 octets.

5.1  MN-HA authentication mobility option

    The format of the MN-HA authentication mobility option is as defined
    in section 6. Section 5.  This option uses the subtype value of 1.  The MN-HA
    authentication mobility option is used to authenticate the binding
   update Binding
    Update and binding acknowledgement Binding Acknowledgement messages based on the shared
    security association between the MN and the HA.

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

    The authenticator is calculated on the message starting from the
    mobility header till (including) the SPI value of this option.

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

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

    MH Data is the content of the Mobility Header till (including) the
    SPI field of this extension.

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

6.2

5.1.1  Processing Considerations

    MN MUST include this option in a BU if it shares a security
    association with the HA.  HA MUST include this option in the BA if
    IPsec is not used and it has a security association with the MN.

    MN or HA receiving this option MUST verify the authenticator in the
    option.  If authentication fails, HA MUST discard the BU and send BA
    with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the MN.

5.2  MN-AAA authentication mobility option

    The format of the MN-AAA authentication mobility option is as defined
    in section 6. Section 5.  This option uses the subtype value of 2.  The MN-AAA
    authentication mobility option is used to authenticate the binding
   update and binding acknowledgement messages Binding
    Update message based on the shared security association between MN
    and HAAA.

   This must be the last option in a message with mobility header.  The
   authenticator Home Authentication, Authorization and Accounting (AAA) server.
    It is calculated on not used in Binding Acknowledgement message.

    This must be the last option in a message starting from the with mobility
   header till header.  If
    both Mobile-Home and Mobile-AAA authentication mobility options are
    present, the SPI value of this option. Mobile-Home Authentication Extension MUST appear prior
    to the Mobile-AAA Authentication extension.  The corresponding
    response MUST include the Mobile-Home Authentication Extension, and
    MUST NOT include the Mobile-AAA Authentication Extension.

    The MN SHOULD MAY use NAI option [NAI] [MN_Ident] to enable the Home Agent to make
    use of available AAA infrastructure which requires NAI.

    The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in
   [3012bis] to indicate CHAP style authentication. authenticator is calculated on the message starting from the
    mobility header till (including) the SPI value of this option.

    The authenticator shall be calculated as follows:

    Authenticator = First (96, HMAC_SHA1 (MN-AAA hash_fn(MN-AAA Shared key, MAC_Mobility
   Data))). Data)

    hash_fn() is decided by the value of SPI field in the authentication
    option.  The SPI field in the MN-AAA authentication option also
    defines how the mobility options in BU are mapped to AAA attributes
    for authentication.

    SPI = CHAP_SPI:

    hash_fn() is MD5.  When CHAP_SPI is used, the BU is authenticated via
    AAA using Challenge Handshake Authentication Protocol (CHAP)
    authentication.  Specifics of how CHAP authentication is done using
    RADIUS ([RFC2865]) is described in Appendix A.

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

   SPI = HMAC_CHAP_SPI:

   MAC_Mobility Data = HMAC_MD5 (care-of address | home address | Data)

    MH
   Data).

6.2.1 Data is the content of the Mobility Header till (including) the
    SPI field of this extension.

5.2.1  Processing considerations Considerations

    The MN-AAA authentication mobility option MUST be verified by the AAA
    infrastructure that has the shared secret with the MN.  The HA relays
    the authenticating information to the HAAA. home AAA.  The HA relies on the
   HAAA
    home AAA to admit or reject the home registration request Binding Update from the MN.

6.2.1.1

5.2.1.1  Home Agent Considerations

    Upon receiving a BU from the MN MN, the HA SHALL extract the MN-AAA
    authenticator and the SPI from the MN-AAA authentication mobility
    option and extract the NAI from the NAI option [NAI]. [MN_Ident].

    The HA SHALL include the extracted MN-AAA authenticator, SPI and the
    NAI in AAA specific AVPs Attribute-Value Pairs (AVPs) while initiating the
    authentication procedure via AAA infrastructure.

7.  Specifics of how
    authentication is done using RADIUS ([RFC2865]) when CHAP_SPI is
    used, are described in Appendix A.

5.3  Authentication Failure Detection at the MN

    In case of authentication failure, the HA MUST send a Binding
    Acknowledgement with error code MIPV6-AUTH-FAIL to the MN, if an SA
    to be used between MN and HA for authentication exists.  This MAY
    need administrative intervention to resolve the cause of the
    authentication failure.

    Upon receiving a Binding Acknowledgement with error code
    MIPV6-AUTH-FAIL, the MN SHOULD stop sending new Binding Updates to
    the responding HA.

6.  Mobility message identification option

    The Mobility message identification option is MAY be used to prevent replay protection.  The
   Identification field carries timestamp for replay protection.  This in a Binding
    Update/Binding Acknowledgement messages when authenticated using the
    mobility authentication option can be used as described in binding update and binding acknowledgement
   messages. Section 5.

    The default method for this purpose Identification option is used to let the timestamp method; some
   other methods may be utilized as well.  If the MN uses 'timestamp' as home agent verify that a measure against replay protection, it SHOULD insert the current
   time of day.  When the destination node receives the
    Binding Update,
   it will make sure that the 'timestamp' (as included Update has been freshly generated by the sender) mobile node, not
    replayed by an attacker from some previous Binding Update.  The
    identification option when included is
   close enough to its own time of the day.  A default value of 500
   milliseconds MAY be used as a reasonable offset (the time difference
   between the sender and by the receiver). MN for matching BA
    with BU.

    The low-order 32 bits of subtype field in the identification option represents
   fractional seconds, specifies the rest style of the bits SHOULD be generated from a
   good source
    replay protection used.  This document specifies timestamps as one
    style of randomness.

   For the identification field to be valid, the 'timestamp' contained replay protection, as described in the Section 6.1.  The
    Identification field in a new Binding Update MUST not be close enough (as determined by
   the system implementers) and greater than the HA's and/or HAAA's time
   of day clock. same as in an
    immediately preceding Binding Update.

    The style of replay protection in effect between a mobile node and
    the HA and/or the HAAA is part of the mobile mobility security association.  A mobile node
    and the HA and/or the HAAA MUST agree on which method of replay protection will be
    used.

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

      Option Type:

         IDENT-OPTION-TYPE to be defined by IANA.  An 8-bit identifier
         of  If the type mobility option. policy at HA mandates replay protection using this
    option (as opposed to the sequence number in Mobility Header in
    Binding Update) and the Binding Update from MN does not include this
    option, HA discards the BU and sets the Status Code in BA to
    MIPV6-MESG-ID-REQD.

    When mobility message identification option is used along with
    authentication option, the MN 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.  Appendix B provides details
    regarding why message identification 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     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  Identification ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

       Subtype:

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

       Identification:

          The Identification field carries timestamp Subtype specific data for
          replay protection.

       Alignment requirements :

         MUST be aligned on an 8-octet boundary.

7.1  Processing considerations

   The Identification field is used to let the HA and/or the HAAA verify
   that a Binding Update message has been generated recently by the MN,
   and it is

          This option does not replayed by an attacker from some older registrations.

7.1.1  Home Agent Considerations

   The HA processes this have any specific alignment requirements.

6.1  Timestamp option only when MN-HA authentication

    The format of the timestamp mobility option is used as defined in Section
    6.  This option uses the BU.  In this case:

   After successful authentication subtype value of Binding Update, the Home Agent
   must verify that the 1.  The Identification
    field falls within the carries timestamp for replay
   protection window.  If Identification field is not within this window
   but the authentication protection.

    The basic principle of timestamp replay protection is that the BU succeeds, HA MUST send node
    generating a Binding
   Acknowledgement with error code "TBD by IANA" MIPV6-ID-MISMATCH.  In
   this  case, HA must include message inserts the correct identification field in current time of day, and the
   Binding Acknowledgement message.

   MN-HA Timestamp: If node
    receiving the message checks that this timestamp based replay check is successful and
   the authentication succeeds, sufficiently
    close to its own time of day.  Unless specified differently in the HA MUST include
    security association between the received
   Identification nodes, a default value in the corresponding field of 7 seconds
    MAY be used to limit the Mobility
   message identification option in the BA.

7.1.2  Mobile Node Considerations

   The MN MUST process time difference.  This value SHOULD be
    greater than 3 seconds.  Obviously the Mobility message identification option.

   MN-HA Timestamp and MN-AAA Timestamp: two nodes must have adequately
    synchronized time-of-day clocks.

    The MN mobile node MUST set the Identification field to a 64-bit value in the Mobility message identification option in
    formatted as specified by the BU message according to its own clock.  If Network Time Protocol [RFC1305].  The
    low-order 32 bits of the MN receives NTP format represent fractional seconds, and
    those bits which are not available from a
   Binding Acknowledgement with time source SHOULD be
    generated from a good source of randomness.  Note, however, that when
    using timestamps, the code MIPV6-ID-MISMATCH, MN must
   adjust its timestamp and send subsequent 64-bit Identification used in a Binding Update using
    from the
   updated value.

7.1.3  AAA server Considerations

   The HAAA processes this option only when MN-AAA authentication
   mobility option is mobile node MUST be greater than that used in the BU.  In this case: any previous
    Binding Update.

    After successful authentication of MN's credentials contained in Binding Update (either locally at
    the
   AVPs, HA or when a success indication is received from the Home AAA server server),
    the home agent MUST verify that check the Identification field
   falls within for validity.  In
    order to be valid, the timestamp contained in the replay protection window.  If Identification
    field
   is not within this window, HAAA MUST reject be close enough to the authentication home agent's time of day clock and
   authorization request.  Upon receiving
    the reject message 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
    Identification field into the Identification 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 HAAA
   server, its own time of day.  If the timestamp field
    is not valid but the authentication of the BU succeeds, HA MUST send
    a Binding Acknowledgement with error code
   "TBD by IANA" MIPV6-ID-MISMATCH.  In this case,  HA must include the
   correct identification field in does
    not create a binding cache entry if the Mobility message identification
   option in timestamp check fails.

    If the MN receives a Binding Acknowledgement message.

   MN-AAA Timestamp: If timestamp based replay check is successful and with the code
    MIPV6-ID-MISMATCH, the MN MUST authenticate the BA by processing the
    MN-HA authentication mobility option.  If authentication and authorization succeeds,
    the HAAA MN MUST adjust its timestamp and send subsequent Binding Update
    using the updated value.  Upon receiving a BA that does not
   include any updated contain
    the MIPV6-ID-MISMATCH error code, the MN MUST compare the
    Identification value in the accept message.  In
   this case, the HA copies BA to the Identification value from the BU into it sent in
    the corresponding field BU.  If the values match, the MN proceeds to
    process the MN-HA authenticator in the BA.  If the replay check fails but
   authentication succeeds, in the reject message values do not
    match, the HAAA MUST include MN silently discards the latest timestamp according to it's own clock.

8. BA.

7.  Security Considerations

    This document proposes new authentication options to authenticate the
    control message between MN, HA and/or HAAA home AAA (as an alternative to
    IPsec).  The new options provide for authentication of Binding Update
    and Binding Acknowledgement messages

9.  IANA Considerations

   The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, as defined in
   section 6 and 7 respectively are new mobility options. messages.  The
   MIPV6-ID-MISMATCH error code also needs to be defined.  IANA should
   record values for these new mobility MN-AAA authentication
    options and the new error code.

10. provides for authentication with AAA infrastructure.  It can
    be used to generate a per session key between MN and HA for
    subsequent authentication of BU/BA between MN and HA 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 message identification.

8.  IANA Considerations

    IANA services are required for this document.  The values for new
    mobility options and error 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 value 0 should not be assigned.

    The value 2 is suggested for CHAP_SPI as defined in section Section
    5.2.

    The value 3 is suggested for HMAC_SHA1.

    The value 5 is reserved for use by 3GPP2.

9.  Acknowledgements

   TBD.

11

    The authors would like to thank Basavaraj Patil, Charlie Perkins and
    Vijay Devarapalli for their suggestions and comments on the draft.
    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

    [3012bis]  Perkins et. al., C., "Mobile IPv4 Challenge/Response
               Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work
               in progress), April 2004.

   [NAI]

    [MN_Ident]
               Patel et. al., A., "Network Access "MN Identifier Option for Mobile IPv6", draft-ietf-mipv6-nai-option-00.txt
               draft-ietf-mip6-mn-ident-option-01.txt (work in progress), February
               December 2004.

   [RFC2486]  Aboba, B.

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

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

    [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 2486, January 1999. 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: alpesh@cisco.com
    Kent Leung
    Cisco Systems
    170 W. Tasman Drive
    San Jose, CA  95134
    US

    Phone: +1 408-526-5030
    EMail: kleung@cisco.com

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

    Phone: +1 972-685-0574
    EMail: mkhalil@nortelnetworks.com

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

    Phone: +1 972-684-4732
    EMail: haseebak@nortelnetworks.com

    Kuntal Chowdhury
    Nortel Networks
    2221 Lakeside Blvd.
    Richardson, TX  75082
    US

    Phone: +1 972 685 7788
    EMail: chowdury@nortelnetworks.com

Appendix A.  Authentication using CHAP

A.1  Processing considerations

    The HA acts as a Radius client in accordance with ([RFC2865]) when
    MN-AAA mobility option is received in a BU.  On receipt of the BU
    from the MN, and if SPI in the MN-AAA mobility option is set to
    CHAP-SPI, the HA shall create a Radius Access-Request message to
    authenticate the BU.

    If the SPI in the MN-AAA Authentication Extension is set to CHAP-SPI,
    the HA shall use MD5 when computing the CHAP challenge.

A.2  Mapping BU to Radius Attributes

    The home agent maps the mobility options to the Radius attributes as
    follows:

    User-Name(1):
       obtained from NAI mobility option in BU.

    Chap-Password(3):

       CHAP Ident field:
          High-order byte of the identification field in the
          Identification mobility option
       String field:
          Authenticator field from the MN-AAA Authentication option

    Chap-Challenge(60):
       MD5(care-of address | home address | Mobility header till
       (including) SPI field in MN-AAA mobility option), followed by the
       Identification field in the identification mobility option.

    NAS-IP-Address:

    NAS-IPv6-Address:
       Address of the HA.  HA uses the v4/v6 address or both if
       available.

A.3  Processing of Radius response

    If the authentication succeeds, the Home Radius server sends a Radius
    Access-Accept message to the HA.  HA proceeds to process the BU
    message and sends a BA with appropriate code.

    If the authentication fails, the Home Radius server sends a Radius
    Access-Reject message to the HA.  If Access-Reject is received from
    AAA, HA drops the BU.  HA does not send a BA to the MN in response to
    this BU.  An existing binding cache entry from a previous successful
    Binding Update MUST not be modified due to this authentication
    failure.

Appendix B.  Rationale for message identification 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 HA should accept a BU with a
    Sequence Number greater than the Sequence Number from previous
    Binding Update.  This implicitly assumes that the HA 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 HA 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 MN
    to register with a different home agent during each mobility session.
    Thus, it is unreasonable to expect each HA in the network to maintain
    state about the MN.  Also, if the HA 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 MN.
    Thus, when authentication option is used, Sequence Number does not
    provide protection against replay attack.

    One solution to this problem would be for the HA to reject the first
    BU and assign a starting sequence number for the session and force
    the MN 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 message identification option to
    prevent replay attacks.  Specifically, timestamps are used for
    message identification 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 MN and CN, the liveness proof is provided by the use
    of nonces which the CN generates.

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
    ietf-ipr@ietf.org.

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 (2004).  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.