GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4285

Network Working Group A. Patel Request for Comments: 4285 K. Leung Category: Informational Cisco Systems

                                                             M. Khalil
                                                             H. Akhtar
                                                       Nortel Networks
                                                          K. Chowdhury
                                                      Starent Networks
                                                          January 2006
              Authentication Protocol for Mobile IPv6

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

IESG Note

 This RFC is not a candidate for any level of Internet Standard.  RFC
 3775 and 3776 define Mobile IPv6 and its security mechanism.  This
 document presents an alternate security mechanism for Mobile IPv6
 used in 3GPP2 networks.
 The security properties of this mechanism have not been reviewed in
 the IETF.  Conducting this review proved difficult because the
 standards-track security mechanism for Mobile IPv6 is tightly
 integrated into the protocol; extensions to Mobile IPv6 and the core
 documents make assumptions about the properties of the security model
 without explicitly stating what assumptions are being made.  There is
 no documented service model.  Thus it is difficult to replace the
 security mechanism and see if the current protocol and future
 extensions meet appropriate security requirements both under the
 original and new security mechanisms.  If a service model for Mobile
 IPv6 security is ever formally defined and reviewed, a mechanism
 similar to this one could be produced and fully reviewed.
 Section 1.1 of this document provides an applicability statement for
 this RFC.  The IESG recommends against the usage of this
 specification outside of environments that meet the conditions of
 that applicability statement.  In addition the IESG recommends those

Patel, et al. Informational [Page 1] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 considering deploying or implementing this specification conduct a
 sufficient security review to meet the conditions of the environments
 in which this RFC will be used.

Abstract

 IPsec is specified as the means of securing signaling messages
 between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).
 MIPv6 signaling messages that are secured include the Binding Updates
 and Acknowledgement messages used for managing the bindings between a
 Mobile Node and its Home Agent.  This document proposes an alternate
 method for securing MIPv6 signaling messages between Mobile Nodes and
 Home Agents.  The alternate method defined here consists of a
 MIPv6-specific mobility message authentication option that can be
 added to MIPv6 signaling messages.

Table of Contents

 1. Introduction ....................................................3
    1.1. Applicability Statement ....................................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 Mobility Message Authentication Option ...............8
         5.1.1. Processing Considerations ...........................9
    5.2. MN-AAA Mobility Message Authentication Option ..............9
         5.2.1. Processing Considerations ..........................10
    5.3. Authentication Failure Detection at the Mobile Node .......11
 6. Mobility Message Replay Protection Option ......................11
 7. Security Considerations ........................................13
 8. IANA Considerations ............................................14
 9. Acknowledgements ...............................................15
 10. References ....................................................15
    10.1. Normative References .....................................15
    10.2. Informative References ...................................15
 Appendix A. Rationale for mobility message replay protection
             option ................................................16

Patel, et al. Informational [Page 2] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

1. Introduction

 The base Mobile IPv6 specification [RFC3775] specifies the signaling
 messages, Binding Update (BU) and Binding Acknowledgement (BA),
 between the Mobile Node (MN) and Home Agent (HA) to be secured by the
 IPsec Security Associations (IPsec SAs) that are established between
 these two entities.
 This document proposes a solution for securing the Binding Update and
 Binding Acknowledgment messages between the Mobile Node and Home
 Agent using a mobility message authentication option that 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
 Acknowledgement messages (between MN-HA) are secured with the
 mobility message authentication option.
 The authentication mechanism proposed here is similar to the
 authentication mechanism used in Mobile IPv4 [RFC3344].

1.1. Applicability Statement

 The mobility message authentication option specified in Section 5 is
 applicable in certain types of networks that have the following
 characteristics:
  1. Networks in which the authentication of the MN for network access

is done by an authentication server in the home network via the home

 agent.  The security association is established by the network
 operator (provisioning methods) between the MN and a backend
 authentication server (e.g., Authentication, Authorization, and
 Accounting (AAA) home server).  MIPv6 as per RFCs 3775 and 3776
 relies on the IPsec SA between the MN and an HA.  In cases where the
 assignment of the HA is dynamic and the only static or long-term SA
 is between the MN and a backend authentication server, the mobility
 message authentication option is desirable.
  1. In certain deployment environments, the mobile node needs dynamic

assignment of a home agent and home address. The assignment of such

 can be on a per-session basis or on a per-MN power-up basis.  In such
 scenarios, the MN relies on an identity such as a Network Access
 Identifier (NAI) [RFC4283], and a security association with a AAA
 server to obtain such bootstrapping information.  The security
 association is created via an out-of-band mechanism or by non Mobile
 IPv6 signaling.  The out-of-band mechanism can be specific to the
 deployment environment of a network operator.  In Code Division
 Multiple Access (CDMA) network deployments, this information can be

Patel, et al. Informational [Page 3] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 obtained at the time of network access authentication via [3GPP2]
 specific extensions to PPP or DHCPv6 on the access link and by AAA
 extensions in the core.  It should be noted that the out-of-band
 mechanism is not within the scope of the mobility message
 authentication option (Section 5) and hence is not described therein.
  1. Network deployments in which not all Mobile Nodes and Home Agents

have IKEv2 implementations and support for the integration of IKEv2

 with backend AAA infrastructures.  IKEv2 as a technology has yet to
 reach maturity status and widespread implementations needed for
 commercial deployments on a large scale.  At the time of this
 writing, [RFC4306] is yet to be published as an RFC.  Hence from a
 practical perspective that operators face, IKEv2 is not yet capable
 of addressing the immediate need for MIPv6 deployment.
  1. Networks that expressly rely on the backend AAA infrastructure as

the primary means for identifying and authentication/authorizing a

 mobile user for MIPv6 service.
  1. Networks in which the establishment of the security association

between the Mobile Node and the authentication server (AAA Home) is

 established using an out-of-band mechanism and not by any key
 exchange protocol.  Such networks will also rely on out-of-band
 mechanisms to renew the security association (between MN and AAA
 Home) when needed.
  1. Networks that are bandwidth constrained (such as cellular wireless

networks) and for which there exists a strong desire to minimize the

 number of signaling messages sent over such interfaces.  MIPv6
 signaling that relies on Internet Key Exchange (IKE) as the primary
 means for setting up an SA between the MN and HA requires more
 signaling messages compared with the use of an mobility message
 authentication option carried in the BU/BA messages.
 One such example of networks that have such characteristics are CDMA
 networks as defined in [3GPP2].

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 mobility security association between the
 Mobile Node and the respective authenticating entity.  This shared-
 key-based mobility security association (shared-key-based mobility
 SA) may be statically provisioned or dynamically created.  The term

Patel, et al. Informational [Page 4] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 "mobility security association" referred to in this document is
 understood to be a "shared-key-based Mobile IPv6 authentication"
 security association.
 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 not provided when these options are used for authentication of the
 Mobile Node to the Home Agent.  Thus, unless the network can
 guarantee such protection (for instance, like in 3GPP2 networks),
 Route Optimization and Mobile Prefix Discovery should not be used
 when using the mobility message authentication option.

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.
 Shared-key-based Mobility Security Association
    Security relation between the Mobile Node and its Home Agent, used
    to authenticate the Mobile Node for mobility service.  The
    shared-key-based mobility security association between Mobile Node
    and Home Agent consists of a mobility Security Parameter Index
    (SPI), a shared key, an authentication algorithm, and the replay
    protection mechanism in use.
 Mobility SPI
    A number in the range [0-4294967296] used to index into the
    shared-key-based mobility security associations.

Patel, et al. Informational [Page 5] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

4. Operational Flow

 The figure below describes the sequence of messages sent and received
 between the MN and HA in the registration process.  Binding Update
 (BU) and Binding Acknowledgement (BA) messages are used in the
 registration process.
       MN                                                  HA/AAAH
       |                   BU to HA                           |
 (a)   |----------------------------------------------------->|
       | (including MN-ID option,                             |
       |  mobility message replay protection option[optional],|
       |  mobility message authentication option)             |
       |                                                      |
       |                                   HA/AAAH authenticates MN
       |                                                      |
       |                                                      |
       |                  BA to MN                            |
 (b)   |<-----------------------------------------------------|
       | (including MN-ID option,                             |
       |  mobility message replay protection option[optional],|
       |  mobility message authentication option)             |
       |                                                      |
       Figure 1: Home Registration with Authentication Protocol
 The Mobile Node MUST use the Mobile Node Identifier option,
 specifically the MN-NAI mobility option as defined in [RFC4283] to
 identify itself while authenticating with the Home Agent.  The Mobile
 Node uses the Mobile Node Identifier option as defined in [RFC4283]
 to identify itself as may be required for use with some existing AAA
 infrastructure designs.
 The Mobile Node MAY use the Message Identifier option as defined in
 Section 6 for additional replay protection.
 The mobility message authentication option described in Section 5 may
 be used by the Mobile Node to transfer authentication data when the
 Mobile Node and the Home Agent are utilizing a mobility SPI (a number
 in the range [0-4294967296] used to index into the shared-key-based
 mobility security associations) to index between multiple mobility
 security associations.

Patel, et al. Informational [Page 6] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

5. Mobility Message Authentication Option

 This section defines a mobility message authentication 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 the 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.  Other subtypes
 may be defined for use in the future.
 Only one instance of a mobility message authentication option of a
 particular subtype can be present in the message.  One message may
 contain multiple instances of the mobility message authentication
 option with different subtype values.  If both MN-HA and MN-AAA
 authentication options are present, the MN-HA authentication option
 must be present before the MN-AAA authentication option (else, the HA
 MUST discard the message).
 When a Binding Update or Binding Acknowledgement is received without
 a mobility message authentication option and the entity receiving it
 is configured to use the mobility message authentication option or
 has the shared-key-based mobility security association for the
 mobility message 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      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Mobility SPI                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Authentication Data ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 2: Mobility Message Authentication Option
    Option Type:
       AUTH-OPTION-TYPE value 9 has been defined by IANA.  An 8-bit
       identifier of the type mobility option.

Patel, et al. Informational [Page 7] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

    Option Length:
       8-bit unsigned integer, representing the length in octets of
       the Subtype, mobility Security Parameter Index (SPI) and
       Authentication Data fields.
    Subtype:
       A number assigned to identify the entity and/or mechanism to be
       used to authenticate the message.
    Mobility SPI:
       Mobility 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 up to and including the mobility SPI field.
    Alignment requirements :
       The alignment requirement for this option is 4n + 1.

5.1. MN-HA Mobility Message Authentication Option

 The format of the MN-HA mobility message authentication option is as
 defined in Figure 2.  This option uses the subtype value of 1.  The
 MN-HA mobility message authentication 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 mobility security association between Mobile
 Node and Home Agent used within this specification consists of a
 mobility SPI, a key, an authentication algorithm, and the replay
 protection mechanism in use.  The mobility SPI is a number in the
 range [0-4294967296], 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 Timestamp option as defined in Section 6.  If the Timestamp
 option is used for replay protection, the mobility security
 association includes a "close enough" field to account for clock
 drift.  A default value of 7 seconds SHOULD be used.  This value
 SHOULD be greater than 3 seconds.

Patel, et al. Informational [Page 8] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 The MN-HA mobility message authentication option MUST be the last
 option in a message with a mobility header if it is the only mobility
 message authentication option in the message.
 The authentication data is calculated on the message starting from
 the mobility header up to and including the mobility SPI value of
 this option.
 Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
 Data))
 Mobility Data = care-of address | home address | Mobility Header (MH)
 Data
 MH Data is the content of the Mobility Header up to and including the
 mobility SPI field of this option.  The Checksum field in the
 Mobility Header MUST be set to 0 to calculate the Mobility Data.
 The first 96 bits from the Message Authentication Code (MAC) result
 are used as the Authentication Data field.

5.1.1. Processing Considerations

 The assumption is that the Mobile Node has a shared-key-based
 security association with the Home Agent.  The Mobile Node MUST
 include this option in a BU if it has a shared-key-based mobility
 security association with the Home Agent.  The 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 mobility
 security association with the Mobile Node.
 The Mobile Node or Home Agent receiving this option MUST verify the
 authentication data in the option.  If authentication fails, the Home
 Agent MUST send BA with Status Code MIPV6-AUTH-FAIL.  If the Home
 Agent does not have shared-key-based mobility SA, Home Agent MUST
 discard the BU.  The Home Agent MAY log such events.

5.2. MN-AAA Mobility Message Authentication Option

 The format of the MN-AAA mobility message authentication 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 mobility security
 association between the 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 mobility message authentication option (Section 5.1).

Patel, et al. Informational [Page 9] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 The MN-AAA mobility message authentication option must be the last
 option in a message with a mobility header.  The corresponding
 response MUST include the MN-HA mobility message authentication
 option, and MUST NOT include the MN-AAA mobility message
 authentication option.
 The Mobile Node MAY use the Mobile Node Identifier option [RFC4283]
 to enable the Home Agent to make use of available AAA infrastructure.
 The authentication data is calculated on the message starting from
 the mobility header up to and including the mobility 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 mobility SPI field in the MN-AAA
 mobility message authentication option.
 SPI = HMAC_SHA1_SPI:
 If mobility SPI has the well-known value HMAC_SHA1_SPI, then
 hash_fn() is HMAC_SHA1.  When HMAC_SHA1_SPI is used, the BU is
 authenticated by AAA using HMAC_SHA1 authentication.  In that case,
 MAC_Mobility Data is calculated as follows:
 MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
 MH Data is the content of the Mobility Header up to and including the
 mobility SPI field of this option.

5.2.1. Processing Considerations

 The use of the MN-AAA mobility message authentication option assumes
 that AAA entities at the home site communicate with the HA via an
 authenticated channel.  Specifically, a BU with the MN-AAA mobility
 message authentication option is authenticated via a home AAA server.
 The specific details of the interaction between the HA and the AAA
 server is beyond the scope of this document.
 When the Home Agent receives a Binding Update with the MN-AAA
 mobility message authentication option, the Binding Update is
 authenticated by an entity external to the Home Agent, typically a
 AAA server.

Patel, et al. Informational [Page 10] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

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 a shared-key-based mobility security association to be used
 between Mobile Node and Home Agent for authentication exists.  If
 there is no shared-key-based mobility security association, HA drops
 the Binding Update.  HA may log the message for administrative
 action.
 Upon receiving a Binding Acknowledgement with status code MIPV6-
 AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding Updates to
 the Home Agent.

6. Mobility Message Replay Protection Option

 The Mobility message replay protection option MAY be used in 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 and not replayed by an attacker from some previous
 Binding Update.  This is especially useful for cases where the Home
 Agent does not maintain stateful information about the Mobile Node
 after the binding entry has been removed.  The Home Agent does the
 replay protection check after the Binding Update has been
 authenticated.  The mobility message replay protection option when
 included is used by the Mobile Node for matching BA with BU.
 If this mode of replay protection is used, it needs to be part of the
 shared-key-based mobility security association.
 If the policy at Home Agent mandates replay protection using this
 option (as opposed to the sequence number in the Mobility Header in
 Binding Update) and the Binding Update from the Mobile Node does not
 include this option, the Home Agent discards the BU and sets the
 Status Code in BA to MIPV6-MESG-ID-REQD.
 When the Home Agent receives the mobility message replay protection
 option in Binding Update, it MUST 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.

Patel, et al. Informational [Page 11] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

     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 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp                                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 3: Mobility Message Replay Protection Option
    Option Type:
       MESG-ID-OPTION-TYPE value 10 has been 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 Timestamp field.
    Timestamp:
       This field carries the 64 bit timestamp.
    Alignment requirements :
       The alignment requirement for this option is 8n + 2.
 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 mobility 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.  The two nodes must have
 adequately synchronized time-of-day clocks.
 The Mobile Node MUST set the Timestamp field to a 64-bit value
 formatted as specified by the Network Time Protocol (NTP) [RFC1305].
 The low-order 32 bits of the NTP format represent fractional seconds,
 and those bits that 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 timestamp used in a Binding Update from
 the Mobile Node MUST be greater than that used in any previous
 successful Binding Update.

Patel, et al. Informational [Page 12] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 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 Timestamp field for validity.
 In order to be valid, the timestamp contained in the Timestamp 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 Timestamp
 field into the Timestamp 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, the Home Agent MUST send a Binding Acknowledgement with
 status code MIPV6-ID-MISMATCH.  The 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 Timestamp value in the
 BA to the Timestamp 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.

7. Security Considerations

 This document proposes new mobility message 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 mobility message authentication
 option provide for authentication with AAA infrastructure.
 This specification also introduces an optional replay protection
 mechanism in 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. Informational [Page 13] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

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, have been
 assigned.  The values are 9 for the AUTH-OPTION-TYPE and 10 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 and Section 5.3, have
 been assigned.  The values are 144 for MIPV6-ID-MISMATCH 145 for
 MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
 A new section for enumerating algorithms identified by specific
 mobility SPIs within the range 0-255 has to be added to
 http://www.iana.org/assignments/mobility-parameters
 The currently defined values are as follows:
 The value 0 should not be assigned.
 The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
 The value 5 is reserved for use by 3GPP2.
 New values for this namespace can be allocated using IETF Consensus.
 [RFC2434].
 In addition, IANA has created a new namespace for the Subtype field
 of the MN-HA and MN-AAA mobility message authentication options under
 http://www.iana.org/assignments/mobility-parameters
 The currently allocated values are as follows:
 1 MN-HA mobility message authentication option Section 5.1
 2 MN-AAA mobility message authentication option Section 5.2
 New values for this namespace can be allocated using IETF Consensus.
 [RFC2434].

Patel, et al. Informational [Page 14] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

9. Acknowledgements

 The authors would like to thank Basavaraj Patil, Charlie Perkins,
 Vijay Devarapalli, Jari Arkko, and Gopal Dommety, and Avi Lior 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. References

10.1. Normative References

 [RFC4283]   Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
             Chowdhury, "Mobile Node Identifier Option for Mobile
             IPv6", RFC 4283, November 2005.
 [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.
 [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.

10.2. Informative References

 [3GPP2]     "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D,
             September 2005.
 [RFC4306]   Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
             Protocol", RFC 4306, December 2005.

Patel, et al. Informational [Page 15] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

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.
 First, the specification states that the Home Agent should accept a
 BU with a Sequence Number greater than the Sequence Number from the
 previous Binding Update.  This implicitly assumes that the Home Agent
 has some information regarding the Sequence Number from the previous
 BU (even when the binding cache entry is not present).  Second, 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 document, 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 the 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 signaling 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.
 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 Client Node (CN), the liveness proof
 is provided by the use of nonces that the CN generates.

Patel, et al. Informational [Page 16] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

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@nortel.com
 Haseeb Akhtar
 Nortel Networks
 2221 Lakeside Blvd.
 Richardson, TX  75082
 US
 Phone: +1 972-684-4732
 EMail: haseebak@nortel.com

Patel, et al. Informational [Page 17] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

 Kuntal Chowdhury
 Starent Networks
 30 International Place
 Tewksbury, MA  01876
 US
 Phone: +1 214 550 1416
 EMail: kchowdhury@starentnetworks.com

Patel, et al. Informational [Page 18] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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.
 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Patel, et al. Informational [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4285.txt · Last modified: 2006/01/06 19:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki