[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                           A. Patel
Internet-Draft                                                  K. Leung
Expires: November 22, 2004                                 Cisco Systems
                                                               M. Khalil
                                                               H. Akhtar
                                                            K. Chowdhury
                                                         Nortel Networks
                                                            May 24, 2004


                Authentication Protocol for Mobile IPv6
                 draft-patel-mipv6-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 November 22, 2004.

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 as defined in
   the base Mobile IPv6 specification.




Patel, et al.          Expires November 22, 2004                [Page 1]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  General Terms  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Operational flow . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Mobility message authentication option . . . . . . . . . . . .  8
     6.1   MN-HA authentication mobility option . . . . . . . . . . .  9
     6.2   MN-AAA authentication mobility option  . . . . . . . . . .  9
       6.2.1   Processing considerations  . . . . . . . . . . . . . . 10
   7.  Mobility message identification option . . . . . . . . . . . . 11
     7.1   Processing considerations  . . . . . . . . . . . . . . . . 12
       7.1.1   Home Agent Considerations  . . . . . . . . . . . . . . 12
       7.1.2   Mobile Node Considerations . . . . . . . . . . . . . . 12
       7.1.3   AAA server Considerations  . . . . . . . . . . . . . . 12
   8.  Encrypted Home KeyGen Token Option . . . . . . . . . . . . . . 14
     8.1   Processing Considerations  . . . . . . . . . . . . . . . . 15
       8.1.1   Home Agent Considerations  . . . . . . . . . . . . . . 15
       8.1.2   Mobile Node Considerations . . . . . . . . . . . . . . 15
   9.  Securing The Mobile Prefix Solicitation and Mobile Prefix
       Advertisement messages . . . . . . . . . . . . . . . . . . . . 16
     9.1   Prefix Encryption Option . . . . . . . . . . . . . . . . . 16
       9.1.1   Processing Considerations  . . . . . . . . . . . . . . 17
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 19
   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 20
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
   13.   Normative References . . . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 23





















Patel, et al.          Expires November 22, 2004                [Page 2]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


1.  Motivation

   The base specification of Mobile IPv6 [BASE] mandates IPsec support
   between MN and HA for authentication.  Also, return routability
   messages passing via the HA (HoT/HoTi) and mobile prefix discovery
   messages must be protected using IPsec.

   While IPsec (ESP) may offer strong protection (depending on the
   algorithms used), use of IPsec may not be required/feasible in all
   cases where Mobile IPv6 may be used.  For small handheld devices, the
   use of IPsec may be too taxing on battery and processor performance.
   Also depending on the model 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).

   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 a fixed prefix or
   acquired during network access authentication (PPP, 802.1x etc.),
   IPsec will most likely not work as the IPsec SAs are tied to the
   address.  The mechanism described in this draft is not tied with
   mobility entities home IP address and therefore does not mandate SA
   relationship with an IP address.

   Another important motivation for this proposed mechanism is to allow
   the MN to register with a Home Agent on a dynamically discovered Home
   Link.  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 a Home Link or Home
   Agent for the user that is closest to the subnet of attachment of the
   user.  There may be various other reasons for opportunistic Home
   Agent assignment.  The mechanisms described in the draft allows the
   MN to register with any Home Agent in the home network as long as the
   MN user shares security association with an entity in the home
   network such as a AAA server.















Patel, et al.          Expires November 22, 2004                [Page 3]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


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.

   As per the specification in the current MIPv6 draft [BASE], the
   return routability messages are protected by IPsec between MN and HA.
   Specifically, the Home KeyGen token sent by the CN to the MN (via) HA
   needs to be protected to secure the messages from an eves-dropper on
   the path between MN and HA.  The extensions in this draft encrypts
   the Home KeyGen token from the HA to MN (based on a shared secret
   that is either derived, distributed or preconfigured between the MN
   and the HA).  Thus, the integrity of the HoT message is preserved.

   This  document introduces new mobility options to aid in
   authentication of the MN and to protect the integrity and
   confidentiality of return routability and mobile prefix solicitation
   and advertisement messages.
































Patel, et al.          Expires November 22, 2004                [Page 4]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


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.














































Patel, et al.          Expires November 22, 2004                [Page 5]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


4.  General Terms

   MN      Mobile Node

   HA      Home Agent

   SA      Security Association

   CN      Correspondent Node

   IPsec   IP Security protocol

   ESP     Encapsulating security protocol

   BU      Binding Update

   BA      Binding Acknowledgement

   HoT     Home Test Message (part of Return Routability test)

   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

   AES     Advanced Encryption Standard

   IV      Initialization Vector












Patel, et al.          Expires November 22, 2004                [Page 6]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


5.  Operational flow


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

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































Patel, et al.          Expires November 22, 2004                [Page 7]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


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

       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                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   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 and Option Length 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



Patel, et al.          Expires November 22, 2004                [Page 8]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


         Mobility Header upto and including the SPI field.

      Alignment requirements :

         TBD.

6.1  MN-HA authentication mobility option

   The format of the MN-HA authentication mobility option is as defined
   in section 6.  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
   security association between the MN and the HA.

   This must be the last option in a message with mobility header.  The
   authenticator is calculated on the message starting from the mobility
   header till 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 Data

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

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

6.2  MN-AAA authentication mobility option

   The format of the MN-AAA authentication mobility option is as defined
   in section 6.  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 based on the shared
   security association between MN and HAAA.

   This must be the last option in a message with mobility header.  The
   authenticator is calculated on the message starting from the mobility
   header till the SPI value of this option.

   The MN SHOULD use NAI option [NAI]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.  The authenticator
   shall be calculated as follows:




Patel, et al.          Expires November 22, 2004                [Page 9]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


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

   SPI = CHAP_SPI:

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

   SPI = HMAC_CHAP_SPI:

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

   Nonces: TBD

6.2.1  Processing 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.  The HA relies on the
   HAAA to admit or reject the home registration request from the MN.

6.2.1.1  Home Agent Considerations

   Upon receiving a BU from the 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].  The HA SHALL
   include the extracted MN-AAA authenticator, SPI and the NAI in AAA
   specific AVPs while initiating the authentication procedure via AAA
   infrastructure.






















Patel, et al.          Expires November 22, 2004               [Page 10]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


7.  Mobility message identification option

   The identification option is used to prevent replay protection.  The
   Identification field carries either timestamps or nonces for replay
   protection (support for timestamps is mandatory).  This option can be
   used in binding update and binding acknowledgement messages.

   The default method for this purpose is the timestamp method; some
   other methods may be utilized as well.  If the MN uses 'timestamp' as
   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 by the sender) 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 the receiver).

   The low-order 32 bits of the identification option represents
   fractional seconds, the rest of the bits SHOULD be generated from a
   good source of randomness.

   For  the  identification  field  to  be  valid,  the  'timestamp'
   contained in the Identification field MUST be close enough (as
   determined by the system implementers) and greater than the HA's and/
   or HAAA's time of day clock.

   The style of replay protection in effect between a mobile node and
   the HA and/or the HAAA is part of the mobile 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 the type mobility option.

      Option Length:




Patel, et al.          Expires November 22, 2004               [Page 11]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004



         8-bit unsigned integer, representing the length in octets of
         the Identification field.

      Identification:

         The Identification field carries either timestamps or nonces
         for replay protection (support for timestamps is mandatory).

      Alignment requirements :

         TBD.

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 not replayed by an attacker from some older registrations.

7.1.1  Home Agent Considerations

   The HA processes this option only when MN-HA authentication mobility
   option is used in the BU.  In this case:

   MN-HA Timestamps: After successful authentication of Binding Update,
   the Home Agent must verify that the Identification field falls within
   the replay protection window.  If Identification field is not within
   this window, 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 the Binding
   Acknowledgement message.

   Nonces: TBD

7.1.2  Mobile Node Considerations

   Timestamps: If MN receives a Binding Acknowledgement with the code
   MIPV6-ID-MISMATCH, MN must adjust its timestamp and send subsequent
   Binding Update using the updated value.

   Nonces: TBD

7.1.3  AAA server Considerations

   The HAAA processes this option only when MN-AAA authentication
   mobility option is used in the BU.  In this case:

   MN-AAA Timestamps: After successful authentication of MN's



Patel, et al.          Expires November 22, 2004               [Page 12]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


   credentials contained in the AVPs, the Home AAA server MUST verify
   that the Identification field falls within the replay protection
   window.  If Identification field is not within this window, HAAA MUST
   reject the authentication and authorization request.  In the reject
   message the HAAA MUST include the latest timestamp.  Upon receiving
   the reject message from HAAA server, the 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 the
   Binding Acknowledgement message

   Nonces: TBD








































Patel, et al.          Expires November 22, 2004               [Page 13]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


8.  Encrypted Home KeyGen Token Option

   This option is inserted by the HA in the HoT message if MN and HA are
   using the authentication option defined in this document.  If IPsec
   is used as per [BASE], this processing does not apply.

   HA must use the Home KeyGen token from the HoT message and encrypt it
   as described below.  The encrypted token is included in the HoT
   message.  HA must set the Home KeyGen token in the HoT message to
   zero.

   Encrypting the Home KeyGen token provides similar level of security
   as provided by using IPsec for protecting the HoT messages.  The Home
   KeyGen Token is encrypted using AES [AES].



      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 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              SPI                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                                                               |
       |                               IV                              |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Payload Data . . .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Option Type:

         KEYGEN-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 SPI, Nonce, IV and the payload data fields, not including
         the Option Type and Option Length field.





Patel, et al.          Expires November 22, 2004               [Page 14]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


      SPI:

         The SPI corresponds to the SPI of the security associations
         between MN and HA.  It is used to associate the right shared
         key to decrypt the Home KeyGen token.

      Nonce:

         The Nonce field is 4 octets in length and is used to ensure the
         uniqueness of the encryption key used to encrypt each instance
         of the Home KeyGen Token option occurring in a given HoT
         message.  The contents of each Nonce field in a given HoT
         message MUST be unique.

      IV:

         The Initialization Vector (IV) field is 16 octets in length.
         This value is required to encrypt the first block of plaintext
         data.

      Payload data:

         AES (Home KeyGen Token).

      Alignment requirements:

         TBD.

8.1  Processing Considerations

8.1.1  Home Agent Considerations

   Home Agent must intercept the HoT message and if IPsec is not in use
   between MN and HA as described in [BASE] (for authentication/
   encryption of control messages), MUST encrypt the Home KeyGen token
   as described in section 8.

8.1.2  Mobile Node Considerations

   When MN receives a HoT message, if IPsec is not in use between MN and
   HA, MN must extract the Home KeyGen Token by decrypting the payload
   data field with the IV, Nonce and the key.









Patel, et al.          Expires November 22, 2004               [Page 15]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


9.  Securing The Mobile Prefix Solicitation and Mobile Prefix
   Advertisement messages

   The [BASE] allows the MN to solicit home prefix from the HA.  This
   solicitation message SHOULD be authenticated at the HA before the HA
   gives out home prefix details to the MN.  In order to authenticate
   the message The MN-HA authentication mobility option SHALL be used.
   If IPsec is used as per [BASE], this processing does not apply.

   In response to the prefix solicitation message, the HA sends Prefix
   Advertisement Message back the MN.  These prefixes SHOULD be
   encrypted to protect the network from attacks.  The prefixes
   [RFC2461], section 4.6.2 SHOULD be encrypted using a suitable
   encryption method such as AES [AES].  Encrypting the prefixes
   provides similar level of security as provided by IPsec using ESP.

9.1  Prefix Encryption Option

   to send encrypted prefixes the HA MUST use the following destination
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Valid Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Preferred Lifetime                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SPI                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Nonce                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                             IV                                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       payload data  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Patel, et al.          Expires November 22, 2004               [Page 16]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


      Type:

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

      Length, Prefix Length, L and A-bit, Reserved1, Valid Lifetime,
      Preferred Lifetime, Reserved2 are as defined in [RFC2461], section
      4.6.2.

      SPI:

         The SPI corresponds to the SPI of the security associations
         between MN and HA.  It is used to associate the right shared
         key to decrypt the Encrypted Prefix.

      Nonce:

         The Nonce field is 4 octets in length and is used to ensure the
         uniqueness of the encryption key used to encrypt each instance
         of the prefix encryption option occurring in a given prefix
         advertisement message.  The contents of each Nonce field in a
         given prefix advertisement message MUST be unique.

      IV:

         The Initialization Vector (IV) field is 16 octets in length.
         This value is required to encrypt the first block of plaintext
         data.

      Payload data:

         AES (Prefix).

      Alignment requirements:

         TBD.

9.1.1  Processing Considerations

9.1.1.1  Home Agent Considerations

   Upon receiving the Mobile Prefix Solicitation message from a MN, the
   HA SHOULD authenticate the MN using the MN-HA authentication mobility
   option that is included in the message.  The processing consideration
   for the MN-HA authentication mobility option is as described in
   section 6.1.

   While sending the Mobile Prefix Advertisement message back to the MN



Patel, et al.          Expires November 22, 2004               [Page 17]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


   in response to a solicitation or unsolicited but unicast way, the HA
   SHOULD encrypt the prefix with a shared secret that is either derived
   or provisioned between the HA and the MN and use IV and nonce.  The
   encrypted data should be included in the payload data field of the
   prefix encryption option defined in 9.1.  The IV and the nonce used
   by the HA MUST be included in the respective fields in the prefix
   encryption option.  The HA SHOULD encrypt the prefix using the shared
   secret, IV and Nonce and the AES mode as indexed by SPI.

9.1.1.2  Mobile Node Considerations

   While sending a Mobile Prefix Solicitation message the MN SHOULD
   include the MN-HA authentication mobility option.  The calculation of
   the authenticator can be performed as:

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

   Data = All fields in the IP header and the message body.

   Upon receiving a Mobile Prefix Advertisement message from the HA in a
   solicited or unsolicited manner, the MN SHOULD decrypt the prefix
   using the shared secret, IV and Nonce and the AES mode as indexed by
   SPI.




























Patel, et al.          Expires November 22, 2004               [Page 18]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


10.  Security Considerations

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

   In terms of protecting the return routability messages, this
   mechanism provides a way to encrypt the Home KeyGen token from CN to
   MN on the path between HA and MN.

   In terms of protecting Prefix Solicitation and Prefix Advertisement
   messages this specification provides ways to calculate and include
   message authenticators and provides ways to send encrypted prefixes
   to the MN.



































Patel, et al.          Expires November 22, 2004               [Page 19]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


11.  IANA Considerations

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












































Patel, et al.          Expires November 22, 2004               [Page 20]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


12.  Acknowledgements

   TBD.

13  Normative References

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

   [AES]      "National Institute of Standards.  FIPS Pub 197: Advanced
              Encryption Standard (AES).", 26 November 2001.

   [BASE]     Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
              in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress),
              June 2003.

   [NAI]      Patel et. al., A., "Network Access Identifier Option for
              Mobile IPv6", draft-patel-mipv6-nai-option-00.txt (work in
              progress), February 2004.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.


Authors' Addresses

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

   Phone: +1 408-853-9580
   EMail: alpesh@cisco.com









Patel, et al.          Expires November 22, 2004               [Page 21]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


   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













Patel, et al.          Expires November 22, 2004               [Page 22]


Internet-Draft    Authentication Protocol for Mobile IPv6       May 2004


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.




Patel, et al.          Expires November 22, 2004               [Page 23]