[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 4285

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


                 Authentication Protocol for Mobile IPv6
                   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 May 2, 2005.

Copyright Notice

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

Abstract

    IPsec is specified as the sole means of securing all signaling
    messages between the Mobile Node and Home agent for Mobile IPv6.  A
    flexible model for security between the mobile node and home agent is
    required from the perspective of deployment of the Mobile IPv6
    protocol.  One instance of such deployment need comes from networks



Patel, et al.             Expires May 2, 2005                   [Page 1]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


    that are built on 3GPP2 standards.  This document proposes an
    alternate method for securing the signaling messages that are
    responsible for performing Registration of a mobile node at a home
    agent.

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
    4.  Operational flow . . . . . . . . . . . . . . . . . . . . . . .  6
    5.  Mobility message authentication option . . . . . . . . . . . .  7
      5.1   MN-HA authentication mobility option . . . . . . . . . . .  8
        5.1.1   Processing Considerations  . . . . . . . . . . . . . .  9
      5.2   MN-AAA authentication mobility option  . . . . . . . . . .  9
        5.2.1   Processing Considerations  . . . . . . . . . . . . . . 10
      5.3   Authentication Failure Detection at the MN . . . . . . . . 10
    6.  Mobility message identification option . . . . . . . . . . . . 11
      6.1   Timestamp option . . . . . . . . . . . . . . . . . . . . . 12
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
    9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
    10.   Normative References . . . . . . . . . . . . . . . . . . . . 16
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
    A.  Authentication using CHAP  . . . . . . . . . . . . . . . . . . 18
      A.1   Processing considerations  . . . . . . . . . . . . . . . . 18
      A.2   Mapping BU to Radius Attributes  . . . . . . . . . . . . . 18
      A.3   Processing of Radius response  . . . . . . . . . . . . . . 18
    B.  Rationale for message identification option  . . . . . . . . . 20
        Intellectual Property and Copyright Statements . . . . . . . . 21





















Patel, et al.             Expires May 2, 2005                   [Page 2]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


1.  Introduction

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

    1.  rely on the use of a AAA infrastructure for authenticating the
        subscriber
    2.  require dynamic assignment of home agent and home addresses
    3.  have constraints on the number of messages involved in setting up
        a security association using protocols like IKEv1
    4.  include mobile nodes that do not support IKEv1

    The conclusion drawn thereby is the need for a solution that does not
    necessarily require an IPsec SA for securing the signaling messages
    that deal with the Registration process of a mobile node with a home
    agent.

    This document proposes a solution for securing the Binding update and
    Binding acknowledgment messages between the Mobile node and Home
    agent using an authentication option which is included in these
    messages.  Such a mechanism enables IPv6 mobility in hosts without
    having to establish an IPsec SA with its home agent.  A mobile node
    can implement Mobile IPv6 without having to integrate it with the
    IPsec module, in which case the Binding update and Binding
    Acknowldegement messages (between MN-HA) are secured with the
    authentication option.  It should be noted that it does not imply
    that the availability of such a 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.

















Patel, et al.             Expires May 2, 2005                   [Page 3]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 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.

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








































Patel, et al.             Expires May 2, 2005                   [Page 4]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 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 May 2, 2005                   [Page 5]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


4.  Operational flow


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


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

    MN MAY use Message Identifier option as defined in Section 6 for
    replay protection.


























Patel, et al.             Expires May 2, 2005                   [Page 6]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


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 and Binding
    Acknowledgement messages in absence of IPsec.

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

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

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


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |  Option Type  | Option Length |  Subtype      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          SPI                                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          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, Security Parameter Index (SPI) and Authenticator
          fields.

       Subtype:




Patel, et al.             Expires May 2, 2005                   [Page 7]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004



          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 :

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






Patel, et al.             Expires May 2, 2005                   [Page 8]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


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 5.  This option uses the subtype value of 2.  The MN-AAA
    authentication mobility option is used to authenticate the Binding
    Update message based on the shared security association between MN
    and Home Authentication, Authorization and Accounting (AAA) server.
    It is not used in Binding Acknowledgement message.

    This must be the last option in a message with mobility header.  If
    both Mobile-Home and Mobile-AAA authentication mobility options are
    present, the Mobile-Home Authentication 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 MAY use NAI option [MN_Ident] to enable the Home Agent to make
    use of available AAA infrastructure which requires NAI.

    The 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 = hash_fn(MN-AAA Shared key, MAC_Mobility 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.




Patel, et al.             Expires May 2, 2005                   [Page 9]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


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

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

5.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 home AAA.  The HA relies on the
    home AAA to admit or reject the Binding Update from the MN.

5.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 [MN_Ident].

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
















Patel, et al.             Expires May 2, 2005                  [Page 10]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


6.  Mobility message identification option

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

    The Identification option is used to let the home agent verify that a
    Binding Update has been freshly generated by the mobile node, not
    replayed by an attacker from some previous Binding Update.  The
    identification option when included is used by the MN for matching BA
    with BU.

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

    The style of replay protection in effect between a mobile node and
    the HA is part of the mobility security association.  A mobile node
    and the HA MUST agree on which method of replay protection will be
    used.  If the 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:





Patel, et al.             Expires May 2, 2005                  [Page 11]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


          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 Subtype specific data for
          replay protection.

       Alignment requirements :

          This option does not have any specific alignment requirements.

6.1  Timestamp option

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

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

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

    After successful authentication of Binding Update (either locally at
    the HA or when a success indication is received from the AAA server),



Patel, et al.             Expires May 2, 2005                  [Page 12]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


    the home agent MUST check the Identification field for validity.  In
    order to be valid, the timestamp contained in the Identification
    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
    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 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 MIPV6-ID-MISMATCH.  HA does
    not create a binding cache entry if the timestamp check fails.

    If the MN receives a Binding Acknowledgement with the code
    MIPV6-ID-MISMATCH, the MN MUST authenticate the BA by processing the
    MN-HA authentication mobility option.  If authentication succeeds,
    the MN 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 error code, the MN MUST compare the
    Identification value in the BA to the Identification value it sent in
    the corresponding BU.  If the values match, the MN proceeds to
    process the MN-HA authenticator in the BA.  If the values do not
    match, the MN silently discards the BA.


























Patel, et al.             Expires May 2, 2005                  [Page 13]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


7.  Security Considerations

    This document proposes new authentication options to authenticate the
    control message between MN, HA and/or home AAA (as an alternative to
    IPsec).  The new options provide for authentication of Binding Update
    and Binding Acknowledgement messages.  The MN-AAA authentication
    options provides for authentication with AAA infrastructure.  It can
    be used to generate a per session key between 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.




































Patel, et al.             Expires May 2, 2005                  [Page 14]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


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.


















Patel, et al.             Expires May 2, 2005                  [Page 15]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


9.  Acknowledgements

    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.

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

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

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

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

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


Authors' Addresses

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

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








Patel, et al.             Expires May 2, 2005                  [Page 16]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 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 May 2, 2005                  [Page 17]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


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



Patel, et al.             Expires May 2, 2005                  [Page 18]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


    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.















































Patel, et al.             Expires May 2, 2005                  [Page 19]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 2004


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.






Patel, et al.             Expires May 2, 2005                  [Page 20]


Internet-Draft    Authentication Protocol for Mobile IPv6  November 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 May 2, 2005                  [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/