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

Versions: 00

Network Working Group                                   Luis A. Sanchez
Internet Draft                                        Gregory D. Troxel
Expire in six months                                   BBN Technologies
                                                      November 21, 1997


                  Rapid Authentication for Mobile IP
                   <draft-ietf-mobileip-ra-00.txt>

Status of This Memo

  This document is an Internet-Draft.  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."

  To view the entire list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  Coast), or ftp.isi.edu (US West Coast).

  Copyright (C) The Internet Society (November 1997).  All Rights
  Reserved.

Abstract

  This document describes a mechanism that provides Mobile IP nodes
  and agents with the necessary keys and information
  needed to establish mobility security associations within a
  foreign network. This mechanism aims at reducing the latency and
  computational burden introduced by public-key based key management
  protocols in network topologies where visiting mobile nodes register
  with their respective home agents several times through different
  foreign agents requiring Mobile-Foreign Authentication. This
  mechanism employs a key distribution center capable of generating
  the security contexts needed to authenticate Mobile IP control
  messages. This mechanism, designed as an extension to the Mobile IP
  protocol, preservs backward compatibility and interoperability with
  RFC2002 compliant implementations of Mobile IP.











Sanchez, Troxel                                                 [Page 1]


Internet Draft     Rapid Authentication for Mobile IP      November 1997




Table of Contents

1.0 Introduction
    1.1 Requirements Terminology
    1.2 Technical Definitions
2.0 Rapid Authentication Overview
3.0 Conventional Mobility Security Association (CMSA)
4.0 Rapid Authentication Extensions for Mobile IP
    4.1 Authentication Extensions
    4.2 Agent Advertisement Extension
5.0 Rapid Authentication Control Messages for Mobile IP
    5.1 Request Message (RA-Req)
    5.2 Reply Message (RA-Rep)
    5.3 Distribution Message (RA-Dist)
    5.4 Distribution Acknowledgment Message (RA-Dist-Ack)
    5.5 Rapid Authentication Message Generation
6.0 Rapid Authentication Payload Processing
    6.1 RA-Req Processing
    6.2 RA-Rep Processing
    6.3 RA-Dist Processing
    6.4 RA-Dist-Ack Processing
7.0 Agent Advertisement Processing
8.0 Performance Considerations
Acknowledgments
References
Disclaimer
Author Information

1.0 Introduction

The Mobile IP protocol as described in RFC2002 relies on control
messages transmitted from mobile hosts to establish IP tunnels.  These
tunnels provide the mechanism needed to redirect traffic addressed to
the mobile host using an IP address associated with its current
topological location.  This new feature would be a security
vulnerability if request messages sent by hosts masquerading as
authorized hosts were honored without cryptographically verifying the
authenticity of such messages.  This vulnerability has been identified
as a security problem in the Internet today[Bel89].  In order to avoid
such security problems, Mobile IP requires that all request messages
transmitted by a Mobile Node (MN) to a Home Agent (HA) be
authenticated using a message authentication code.  The default
mechanism uses the keyed-MD5 algorithm [Riv92] in preffix+suffix mode
with a key size of 128 bits.

Mobile Node to Home Agent authentication is not the only case where
authentication is useful.  For instance, an MN might want to verify
that a Foreign Agent (FA) is trustworthy before authenticating a
request to the HA to bind the MN's address to the Care-of Address


Sanchez, Troxel                                                 [Page 2]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


(COA) given by that particular FA.  Another possibility is for the FA
to be able to choose to provide or decline service to the MN based
upon some policy; the MN must be able to authenticate requests to the
FA for this to be possible with authentication-based access control.
Another scenario where authentication might be useful is when the FA
wishes the HA to authenticate itself to the FA in order to avoid
denial-of-service (DoS) attacks by an attacker injecting false binding
rejections claiming to be from the HA.  In all these cases the use of
keyed-MD5 or other MAC algorithms to authenticate registration and
reply messages is sufficient to establish the authenticity of the
messages exchanged between FAs and MNs.

Mobile IP does not mandate a protocol to establish the security
contexts (shared key, authentication algorithm, type of replay
protection, etc.) between a pair of nodes.  It is the collection of
these security contexts that encompases a Mobilility Security
Association [Perk96].  Mobile Agents and nodes establish pairwise
Mobility Security Associations (MSA) manually using shared secrets
previously agreed upon.  Manual configurations don't scale, making
this authentication scheme a management nightmare even for small size
networks.  Using a key management protocol such as ISAKMP provides the
scalability and flexibility needed when establishing security
associations with a performance cost.  For example, consider an MN
which has been unregistered for a long time contacting a foreign agent
in some domain where there are multiple FAs.  This will likely require
some certificate fetches and public-key operations to validate and
perform a key exchange.  If the MN has not recently registered with
any foreign agents, this is acceptable.  However, we would like to
avoid this burden when the MN moves to another FA in the same domain.
Regardless of the reason for an MSA to be present between an MN and an
FA or an FA and an HA, it is desirable for these MSAs to be created
quickly for subsequent authentications.

Rapid Authentication (RA) is a mechanism that allows the establishment
of Mobility Security Associations between mobile nodes and agents in a
particular foreign domain without using any public key operations,
generating multiple round trips, or key lookups that leave the foreign
domain. Rapid Authentication uses a key exchange approach with
symmetric cryptography, to distribute the keying material needed to
authenticate Mobile IP control messages among mobility agents and
nodes while in a foreign domain.  Rapid Authentication is designed to
be a compatible extension to the standards-track Mobile IP protocols,
so that if a host does not implement RA, interoperability will not be
impaired. This document assumes that there is some mechanism for MSA
creation between mobility entities and the Key Distribution Center.

In order to understand this document, the reader should be thoroughly
familiar with most of RFC2002.





Sanchez, Troxel                                                 [Page 3]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


1.1 Requirement Terminology

In this document, the words that are used to define the significance
of each particular requirement are usually capitalized.  These words
are defined in [RFC 2119] and are inlcuded in this document for
completeness. These key words are:


     - MUST

     This word or the adjective "REQUIRED" means that implementation of
     the item is an absolute requirement of the specification.

     - SHOULD

     This word or the adjective "RECOMMENDED" means that there might
     exist valid reasons in particular circumstances to not implement
     this item, but the full implications should be understood and the
     case carefully weighed before not implementing this or not
     implementing it in a conforming manner.

     - MAY

     This word or the adjective "OPTIONAL" means that implementation of
     this item is truly optional.  One vendor might choose to include
     the item because particular buyers require it or it enhances the
     product, while another vendor may omit the same item.

1.2 Technical Definitions

This section provides definition of terms applicable to Rapid
Authentication.

Mobility Security Association

        A Mobility Security Association (MSA) denotes the association
        between a pair of nodes (nodes A and B) by a collection of
        security contexts comprised of the identities of the nodes,
        SPI values by which each locates the MSA, authentication
        algorithm and mode, authentication key, and style of replay
        protection.

Conventional Mobility Security Association

        A Conventional Mobility Security Association (CMSA) denotes
        the association between a pair of nodes (nodes A and B) by a
        collection of security contexts comprised of the identities of
        the nodes, SPI values by which each locates the CMSA,
        an authentication algorithm and mode, an encryption algorithm
        and mode, an authentication key, an key-encrypting key, a
        style of replay protection and expiration time.


Sanchez, Troxel                                                 [Page 4]


Internet Draft     Rapid Authentication for Mobile IP      November 1997




Rapid Mobility Security Association

        A Rapid Mobility Security Association (RMSA) denotes the
        association between a pair of nodes (nodes A and B) by a
        collection of security contexts comprised of the identities of
        the nodes, SPI values by which each locates the RMSA, the
        identity of the party that functioned as the RKDC,
        the authentication algorithm and mode, the authentication key,
        the style of replay protection and the expiration time.

Rapid Key Distribution Center

        A host functioning as Key Distribution Center for Rapid
        Authentication in Mobile IP.  RKDCs generate keys, SPIs and
        other related information required to establish a Mobility
        Security Association between Mobile Agents and Mobile Nodes.
        Foreign Agents serve as RKDCs.

2.0 Rapid Authentication Overview

Rapid Authentication (RA) is a mechanism that allows establishment of
MSAs between the mobile nodes and agents in a particular foreign
domain without using any public key operations, generating multiple
round trips, or key lookups that leave the foreign domain.  The
central idea of Rapid Authentication is to allow Foreign Agents to
function as a Kerberos-style [Kohl93] Key Distribution Centers
(KDC). These Foreign Agents are capable of creating the security
contexts that Mobile Nodes and Agents require in order to generate
Mobility Security Associations among themselves. Foreign Agents
supporting Rapid Authentication and functioning as key distribution
centers are known as Rapid Key Distribution Centers or RKDCs. In order
for this mechanism to work, security associations must exist between
the RKDC and the Mobile Node requesting Rapid authentication, the RKDC
and the Home Agent of the Mobile Node and between the RKDC and the
nearby Foreign Agent. These security associations, also known as
Conventional Mobile Security Associations (CMSA), include among other
security contexts, a key encrypting key and an authentication
key. RKDCs use the key encrypting keys to encrypt the authentication
keys required by both mobile nodes and agents to authenticate Mobile
IP control messages. These security associations could be in place a
priori (before a Mobile Node requests Rapid Authentication) or be
established as a result of a request message sent from a Mobile Node
to an RKDC. CMSAs could be created manually, via ISAKMP/Oakley,
ZmKeyGen [MOIPS97] or some other key management mechanism.







Sanchez, Troxel                                                 [Page 5]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


Rapid Authentication introduces four new Mobile IP control messages:

                1) RA-Req
                2) RA-Rep
                3) RA-Dist
                4) RA-Dist-Ack

All RA control messages follow the same format: a Rapid Authentication
header, Rapid Authentication data and an authentication extension. The
RA header is common to all messages and it includes among other
fields: the home IP address of the Mobile Node requesting RA, the IP
address of the target Foreign Agent, the IP address of RKDC and an
Identification Field to be used for anti-replay protection. The
authentication extensions provide authentication and integrity for
the RA control messages exchanged among nodes and agents.

The Rapid Authentication process begins with the RA-Req message. The
RA data in this message indicates the authentication algorithm and the
length of the key required by the Mobile Node. The RA-Rep messages do
not contain RA data. RKDCs use this message to indicate to Mobile
Nodes the status of their requests. RKDCs employ RA-Dist messages to
distribute the security contexts needed to create MSAs among nodes and
agents. These contexts include SPI values, Key Lifetime,
Authentication Key, etc. RA-Dist messages are acknowledge by their
recipient using the RA-Dist-Ack message. Like the RA-Rep message, the
RA-Dist-Ack message does not contain RA data and is used by nodes and
agents to indicate RKDCs the status of a particular RA-Dist message
received.  Rapid Authentication also introduces a new Agent
Advertisement extension to provide advertisement of RA support by
Foreign Agents.  This extension allows Foreign Agents to advertise
whether or not they are functioning as RKDCs since it is possible that
FAs supporting RA MAY not function as RKDCs for administrative
reasons.  This extension also allows Foreign Agents to announce the
list of RKDCs for which they have valid CMSA enabling Mobile Nodes to
request RA with a target Foreign Agent via their common RKDC.

Rapid Authentication operates in two modes: direct and target mode.
In direct mode operation, Mobile Nodes have IP connectivity with the
RKDC. In target mode operation, Mobile Nodes do not have IP
connectivity with RKDCs, only link connectivity. In this mode, Mobile
Nodes send RA-Req messages via Foreign Agents for which they have link
layer connectivity. Foreign Agents supporting RA forward these request
messages to the appropriate RKDC.  The basic Rapid Authentication
operation is straight forward. Mobile Nodes send RA-Req messages to
RKDCs. The request messages come directly from the Mobile Node (direct
mode operation) or get forwarded by a Foreign Agent (target mode
operation). RKDCs send RA-Rep messages indicating whether or not they
can generate the security contexts required for the mobile nodes and
agents to establish MSAs among themselves. In target mode operation,
RKDCs send reply messages to the Mobile Nodes via Foreign
Agents. RKDCs verify if they have CMSAs established with both the


Sanchez, Troxel                                                 [Page 6]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


Mobile Node and the target Foreign Agent.  If so established, the RKDC
creates SPIs, authentication keys and all other required
information. The RKDC encrypts the authentication keys using the
default encryption algorithm, DES with 56-bit keys. RKDCs generate
RA-Dist messages containing the SPIs, algorithm information,
authentication keys, etc. and transmit them to the mobile nodes and
agents. All nodes and agents receive one message containing the SPI
values that they will use to identify the MSAs. Since the MSAs are
simplex, each nodes receives two SPIs, one for outgoing and one for
incoming traffic for that communication. Foreign Agents however,
receive two sets of SPI values (a total of four); two for identifying
the MSA between the Foreign Agent and the Home Agent and two for
identifying the MSA between the Foreign Agent and the Mobile
Node. Once both the mobile nodes and agents receive the RA-Dist
messages and the mobility security associations are established, they
reply to the RKDCs by transmitting RA-Dist-Ack messages indicating the
status of the transaction. Upon reception of a RA-Dist-Ack message
reporting good status, RKDCs destroy all keying information and clear
all states.

3.0 CMSA Generation

We will assume that two FAs are capable of creating a security
association with each other for use in the Rapid Mobility protocol.
This association, known as a CMSA, includes an authentication key, a
key-encrypting key, type of replay protection, encryption and
authentication algorithm identifiers, SPI values and expiration times.
CMSAs could be created manually, via ISAKMP/Oakley, ZmKeyGen [MOIPS97]
or some other mechanism.  The KEK is used to encrypt the keying
material generated at the RKDCs before is sent to the final
destination.  The destination uses the corresponding KEK to decrypt
the keying material.  A possible scheme for generating CMSAs will be
defined in a separate document.

4.0 New Mobile IP Extensions

4.1 Authentication Extensions

RA introduces three new Mobile IP extensions to provide authentication
to control messages exchanged between mobile nodes and agents with
RKDCs as specified below.

           Type              Authentication
           Value              Extension

            129            Mobile-RKDC Authentication
            130            Foreign-RKDC Authentication Extension
            131            Home-RKDC Authentication Extension





Sanchez, Troxel                                                 [Page 7]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


These extensions follow the same format used in other Mobile IP
authentication extensions.  The extension format is depicted below for
reference.

    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    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ...  SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            129,130,or 131.

      Length          4-octets plus the number of octets in the
                      Authenticator.

      SPI             Security Parameter Index is a 4-octet field with
                      an arbitrary value that combined with a
                      destination IP address identifies a security
                      association.

      Authenticator   This is a variable length field that depends upon
                      the algorithm used.  Default authentication
                      algorithm is keyed-MD5 in prefix+suffix
                      mode. This algorithm produces a 16-octet value.

The Mobile-RKDC Authentication Extension MUST be present in all
RA control messages exchanged between Mobile Nodes and RKDCs.  The
Foreign-RKDC Authentication Extension MUST be present in all RA control
messages exchanged between Foreign Agents and RKDCs.  The Home-RKDC
Authentication Extension MUST be present in all RA control messages
exchanged between RKDCs and HAs.

4.2 Agent Advertisement Extensions

RA also introduces one new Mobile IP extension to provide
advertisement of RA support by FAs.  The RA Advertisement Extension
follows the exact same format used in other Mobile IP extensions.  The
extension format is depicted below.

    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     |R|          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          ...  RKDC Addresses.....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            132



Sanchez, Troxel                                                 [Page 8]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


      Length          2-octets plus 4*N where N is the number of RKDC
                      addresses.

      R               Indicates whether or not this FA functions
                      as an RKDC.

      Reserved        Available for future use and expansion.  This
                      field is sent as zero and ignored at the
                      receiving end.

      RKDC Address    A variable length field containing the IP
                      address(es) of other RKDCs for which this FA has
                      a CMSA.

FAs supporting RA SHOULD append this extension to their agent
advertisement.  The R bit is set to 1 to indicate that the FAs
sending this advertisement are also functioning as RKDCs.  This
extension enables MNs to request RA with the Target via their common
RKDC.  This extension can only be used with ICMP router discovery
messages.  Note that an MN MAY request RA with a Target even if they
don't share a common RKDC.

5.0 Rapid Authentication Control Message Format

RA defines a set of new control messages with the following format:

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      |     Code      |          Lifetime             |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|                       Requestor Address                       |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|                        Target Address                         | RA
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
|                          RKDC Address                         |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|                                                               |   |
+                         Identification                        +   |
|                                                               |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| RA Data ...
+-+-+-+-+-+-+-+-
| Extensions ...
+-+-+-+-+-+-+-+-

Type
         A 1-octet field indicating the RA control message type.  See
         below for a list of currently defined code values.




Sanchez, Troxel                                                 [Page 9]

Internet Draft     Rapid Authentication for Mobile IP      November 1997


           Type             Message
           Value             Type

            04            RA-Req
            05            RA-Rep
            06            RA-Dist
            07            RA-Dist-Ack

Code
        A value indicating specific control information for each RA
        message.

Lifetime

        A 2-octet field indicating the number of seconds remaining
        before the association is considered expired.  A value of
        0xffff indicates infinity.

Requestor Address

        The home address of the MN requesting RA.  Only MNs MAY
        request RA.

Target Address

        A 4-octet field containing the IP address of the Foreign Agent
        that the MN wishes to establish a RMSA with.

RKDC Address

        A 4-octet field containing the IP address of the host acting
        as RKDC for a particular RMSA.

Identification

        This 8-octet field contains a random value (nonce) or a
        timestamp used for protecting against replay attacks.  This
        field is similar to the identification field found in Mobile
        IP Registration messages.  See section 9.0 for a detailed
        a description.

RA Data

        The RA data is of variable length and depends on the RA
        message type.

Extensions

        Any of the following Mobile IP control message extensions may
        appear in RA control messages:



Sanchez, Troxel                                                 [Page10]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


         Extension         Extension
          Number              Type

            129     Mobile-RKDC Authentication
            130     Foreign-RKDC Authentication
            131     Home-RKDC Authentication

5.1 Request Message (RA-Req)

The RA-Req message is comprised of the RA header, RA data and
appropriate extension.  The RA-Req type value is 04.  The following
values are defined for use within the code field:

          Code              Request
          Field               Type

           01      Direct Mode Request
           02      Target Mode Request

The RA data for the RA-Req message includes a 4-octet field containing
the requestor's key information required by the RKDC to generate the
appropriate keying material.  This information includes the
authentication algorithms requested and the size of authentication key
as specified below.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Authentication Algorithm    |   Authentication Key Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Authentication Algorithm

        This 2-octet field indicates a specific algorithm.  The value
        1 indicates MD5 as per RFC2002.  All hosts implementing RA
        MUST implement this algorithm.  Values from 64000-64999 are
        reserved for private use, and values 65000-65535 are
        experimental.

     Authentication Key Length

        This 2-octet field specifies the size in bits of the
        authentication key the requestor is asking the RKDC to
        generate.  A value of 0 means "do not generate key."

5.2 Reply Message (RA-Rep)

The RA-Rep message is comprised of the RA header and appropriate
authentication extension.  Reply messages DO NOT contain RA Data.  The
RA-Rep type value is 05.  The following values are defined for use
within the code field:


Sanchez, Troxel                                                 [Page11]


Internet Draft     Rapid Authentication for Mobile IP      November 1997



          Code               Action
          Field               Type

           01         request accepted
           02         denied, no CMSA with target
           03         denied, administratively prohibited
           04         denied, insufficient resources
           05         denied, failed authentication
           06         denied, requested Lifetime too long
           07         denied, reason unspecified
           08         denied, request mode mismatch
           09         denied, identification field mismatch

5.3 Distribution Message (RA-Dist)

The RA-Dist message is comprised of the RA header, RA data and
appropriate authentication extension.  The RA-Dist type value is
06.  The following values are defined for use within the code field:

          Code               Action
          Field               Type

           01      Direct Mode Distribution
           02      Target Mode Distribution

 The RA data has the following format:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index A (SPIA)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index B (SPIB)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key Lifetime   | Authentication Key Life Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Authentication Algorithm    | Authentication Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|                                                               |   |
+                                                               +Encrypt
|                                                               |   |
+       Authentication Key Payload (variable length)            +   w/
|                                                               |   |
+                                                               +  KEK
|                                                               |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------






Sanchez, Troxel                                                 [Page12]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


   SPIA

      The Security Parameter Index A is a 4-octet field with an
      arbitrary value that identifies either the security association
      between the target and the requestor, the target and the
      requestor's home agent or the home agent and the requestor, as
      specified by the code field.

   SPIB

      The Security Parameter Index B is a 4-octet field with an
      arbitrary value that identifies either the security association
      between the requestor and the target, the requestor's home agent
      and the target or the requestor and the home agent, as specified
      by the code field.

   Authentication Key Lifetime

      A 2-octet field that specifies the time to live of this key.
      The value could be in units of seconds or kilobytes.

   Authentication Key Life Type

      A 2-octet field that indicates if the Authentication Key
      Lifetime field is in units of seconds (value= 0x0001) or
      kilobytes(value= 0x0002)

   Authentication Algorithm

      This 2-octet field that indicates the authentication algorithm
      in used.  Default algorithm is keyed-MD5 in "prefix+suffix"
      mode. The code value is 0x0001.

   Authentication Payload Length

      A 2-octet field that specifies in octets the length of the
      Authentication Key Payload field.

   Authentication Key Payload

      A variable length field containing the key to be used to
      authenticate Mobile IP messages exchanged between mobile nodes
      and mobile agents.  This field includes Initialization
      Vectors(IVs), required padding and is encrypted with the
      appropriate Key Encryption Key (KEK) using the encryption
      algorithm negotiated during the establishment of the CMSA.  The
      default encryption algorithm is DES with 56 bit keys.  The value
      in the Authentication Payload Length field indicates the length
      of this field.




Sanchez, Troxel                                                 [Page13]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


RA-Dist messages for FAs contain the RA header, two RA data sets and
the appropriate authentication extension. They differ from RA-Dist
messages destined to MNs or HAs in that instead of containing one RA
Data set, these messages carry two sets of RA data. One RA data set is
for configuring the mobility security association between the home
agent and the foreign agent and the other is for configuring the mobile
security association between the mobile node and the foreign
agent. The RA-Dist message for FAs has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 RA-Dist Message Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   RA Data for HA-FA...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   RA Data for MN-FA...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             RKDC-FA Authentication Extension...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In RA-Dist messages destined for FAs, the RA Data format for both
HA-FA and MN-FA mobility security associations follows the general RA
Data format specified earlier in this section. The authentication key
payload in both RA data sets is encrypted with the same KEK. The CMSA
between the RKDC and the FA specifies the appropriate KEK to be used
to encrypt the payload. The RA-Dist message format for FA is the same
regardless of whether the RA-Req message is in direct or target mode.

5.4 Distribution Acknowledgment Message (RA-Dist-Ack)

The RA-Dist-Ack message is comprised of the RA header and appropriate
authentication extension.  Distribution messages DO NOT contain RA
Data.  The RA-Dist-Ack type value is 07.  The following values are
defined for use within the code field:

          Code               Action
          Field               Type

           01         Received Direct Mode Distribution Message
           02         Received Target Mode Distribution Message
           03         denied, identification field mismatch
           04         Encryption Failure
           05         Invalid SPI
           06         Authentication Failure

5.5 Rapid Authentication Message Generation

Mobile Nodes holding a valid CMSA with at least one RKDC MAY send
RA-Req messages.  A Mobile Node supporting RA SHOULD request RA with a
particular FA upon receipt of an agent advertisement from that FA or


Sanchez, Troxel                                                 [Page14]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


loss of binding with the original FA combined with agent advertisement
from a new FA.  In both cases, the foreign agent advertisement
received at the MN MUST have the RA Advertisement extension in order
for a Mobile Node to request RA.  The extension indicates support for
RA.  See section 4.2 for details about RA advertisements.

FAs MAY forward RA-Rep messages to MNs. However, only RKDCs MAY send
RA-Rep messages.  RKDCs MUST respond to all RA-Req messages by sending
a RA-Rep with the appropriate code field.  Only RKDCs MAY send RA-Dist
messages.  In response to each valid RA-Req message the RKDC sends a
RA-Rep message to the requestor (MN), creates RMSAs for those entities
for which it has CMSAs with and, transmits RA-Dist messages to the
agents and nodes.

RKDCs transmit three RA-Dist messages; one to the MN, one to the HA
and one to the FA. The RA-Dist messages for the MNs and HAs contain
only one RA data set per message. However, the RA-Dist messages for FA
contain two RA data sets per message. One RA data set for the HA-FA
mobility security association and one for the MN-FA mobility security
association. Section 5.3 specifies the format for the RA-Dist messages
destined to foreign agents.

Mobile Nodes and Agents MAY send RA-Dist-Ack messages.  FAs SHOULD
forward RA-Dist-Ack messages to MNs.  MNs, FAs and HAs MUST respond to
all RA-Dist messages addressed to them by sending a RA-Dist-Ack with
the appropriate code field.

6.0 Rapid Authentication Payload Processing

For RA-Req or RA-Dist control messages, the transmitting entity MUST
do the following:

1.  Set a timer and initialize a retry counter.
2.  If an RA-Rep or RA-Dist-Ack message corresponding to the
    appropriate RA-Req or RA-Dist message is received within the time
    interval or before the RETRY LIMIT is reached, the transmitting
    entity continues normal operation.
3.  If an RA-Rep or RA-Dist-Ack message corresponding to the
    appropriate RA-Req or RA-Dist message is not received within a
    time interval, the control message is resent and the retry counter
    is decremented.
4.  If the retry counter reaches zero (0) (i.e.  RETRY LIMIT is set)
    the event should be logged in the appropriate system audit file.
5.  At this point, Mobile Nodes transmitting RA-Req messages will clear
    RA state for this peer and fall back to conventional
    authentication setup using ISAKMP/Oakley or the MOIPS ZmKeyGen.
    RKDCs transmitting RA-Dist messages will clear RA state for the
    pending RMSA (and therefore take no further action unless another
    message is received).




Sanchez, Troxel                                                 [Page15]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


6.1 RA-Req Processing

When creating a RA-Req message, the MN MUST do the following:

1.  Set the value of the type field to 04
2.  Determine the appropriate code field
    a) Set the value of the code field to 01 if the RKDC is the current
       FA (direct mode)
    b) Set the value of the code field to 02 otherwise.  The MN sends
       the RMSA request to the target FA which in turn forwards the
       request to the RKDC (target mode)
3.  Set the association lifetime
4.  Set the Requestor Address to IP home address of the MN
5.  Set the Target Address to the FA's IP address found in the care of
    address field of the agent advertisement message
6.  Set the RKDC Address.  The MN SHOULD have a valid CMSA with this
    RKDC.
7.  Place the identification value used for anti-replay attack
    protection
8.  Construct the RA data payload
9.  Calculate an integrity check value over the RA header, RA data,
    and the type, length and SPI fields of the authentication
    extension using the authentication key created during the
    establishment of the CMSA with that RKDC

When an FA receives a RA-Req message it MUST do the following:

1) Check the code field.

 If the value is 01 (Direct Mode Request) then:
    a) Check the RKDC field
    b) If the FA is the intended RKDC, it verifies the MN-RKDC
       authenticator.
        If validation succeeds:
          - check identification field for anti-replay protection.  If
            a replayed message is detected:
            - discard message
            - send RA-Rep message with with appropriate code field (09)
            - the event MAY be logged
        If the message is original(not a replayed message):
          - the FA sends a reply message with code field 01
          - construct and transmit RA Distribution messages as
            specified in section 6.3
        If validation fails:
          - the FA sends a reply message with code field 05
          - the event MAY be logged
    c) If the FA is NOT the intended RKDC the FA sends a reply
       message with code field 08

 If the value is 02 (Target Mode Request) then:
    a) Check the RKDC field


Sanchez, Troxel                                                 [Page16]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


    b) If the FA is NOT the intended RKDC the FA forwards the RA-Req
       to the the address found in the RKDC field
    c) If the RKDC field contains the address of the FA, it verifies
       the MN-RKDC authenticator
        If validation succeeds:
          - check identification field for anti-replay protection.  If
            a replayed message is detected:
            - discard message
            - send RA-Rep message with with appropriate code field(09)
            - the event MAY be logged
        If the message is original(not a replayed message):
          - the FA sends a reply message with code field 01
          - construct and transmit RA Distribution messages as
            specified in section 6.3
        If validation fails:
          - the FA sends a reply message with code field 05
          - the event MAY be logged

6.2 RA-Rep Processing

When creating a RA-Rep message the transmitting entity MUST do the
following:

1.  Set the value of the type field to 05
2.  Determine the appropriate code field as specified in section 5.2
3.  Set the values for the Lifetime, Requestor Address, Target
    Address, and RKDC fields to the values found in the corresponding
    RA-Req message
4.  Set the identification value used for anti-replay attack
    protection
5.  Calculate an integrity check value over the RA header, RA data,
    and the type, length and SPI fields of the authentication
    extension using the authentication key created during the
    establishment of the CMSA with that entity
6.  Append the appropriate authentication extension to the reply
    message

When an MN receives a RA-Rep message it MUST do the following:

1.  Verify the authenticator
    If validation fails:
     - the message is silently discarded and the event MAY be logged
2.  Check identification field for AR protection.  If a replayed
    message is detected it is silently discarded and the event MAY be
    logged
3.  Read the code field and proceed accordingly

When an FA receives a RA-Rep message it MUST forward the message to
the address found in the requestor field.




Sanchez, Troxel                                                 [Page17]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


6.3 RA-Dist Processing

When creating a RA-Dist message the RKDC MUST do the following:

1.  Set the value of the type field to 06
2.  Set the code field
3.  Set the association lifetime
4.  Set the values for the Requestor Address, Target Address, and
    RKDC fields to the values found in the corresponding RA-Rep
    message
5.  Place the identification value used for anti-replay attack
    protection
6.  Construct the RA data sets following the steps specified below:
    a) Generate 2 random numbers of 4 octets each to be used as SPIA
       and SPIB for either MN-FA or FA-HA communication
    b) Generate Keys based on the information provided in the RA-Req
       message
       A key of size 00 indicates "do not generate key"
    c) Encrypt the keys using the appropriate KEK
    d) Set the authentication payload size
    e) Set keys lifetime and type accordingly
7.  Calculate an integrity check value over the RA header, RA data,
    and the type, length and SPI fields of the authentication
    extension using the authentication key created during the
    establishment of the CMSA with that entity
8.  Append the appropriate authentication extension to the message

When MNs or HAs receive a RA-Dist message they MUST do the following:

1.  Verify the authenticator
    If validation fails:
        - the message is discarded and the event MAY be logged
        - send an RA-Dist-Ack message with error code 06
2.  Check identification field for anti-replay protection.  If a
    replayed message is detected:
            - discard message
            - send RA-Rep message with with appropriate code field (03)
            - the event MAY be logged
3.  Read the Authentication Payload Length field.  Note that if the
    the payload fields equals 0 then no keys were created for that
    RMSA
4.  Decrypt Authentication Keys using the appropriate KEK.
    a) If decryption fails:
        - send an RA-Dist-Ack message with appropriate code field (04)
        - the event MAY be logged
    b) If decryption succeeds:

        - Search the security association data base for a matching SPI
          value, for the same destination address and security
          protocol (i.e a matching mobility security association tuple)



Sanchez, Troxel                                                 [Page18]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


          If one exists then:
                - do not create security association
                - send an RA-Dist-Ack message with error code (05)
                - the event MAY be logged
          If no SPI collision is detected then:
                - create a security association for the appropriate
                  target
                  using the SPIs and the MSA attributes in the RA Data.
                - send an RA-Dist-Ack message

When an FA receives a RA-Dist message it MUST do the following:

1.  Repeat steps 1 and 2 above
2.  Read the Authentication Payload Length field for the HA-FA RA data
    set.  Note that if the the payload fields equals 0 then no keys
    were created for that RMSA
3.  Decrypt Authentication Keys using the appropriate KEK.
4.  Read the Authentication Payload Length field for the MN-FA RA data
    set.  Note that if the the payload fields equals 0 then no keys
    were created for that RMSA
5.  Decrypt Authentication Keys using the appropriate KEK.
    a) If either decryption failed:
        - send an RA-Dist-Ack message with appropriate code field (04)
        - the event MAY be logged
    b) If both decryptions succeeded:
        - For each RMSA, search the security association data base for
          a matching SPI value, for the same destination address and
          security protocol (i.e a matching mobility security
          association tuple).
          If one exists then:
                - do not create any security association
                - send an RA-Dist-Ack message with error code (05)
                - the event MAY be logged
          If no SPI collision is detected then:
                - create both security association for the appropriate
                  targets using the SPIs and the MSA attributes in the
                  RA Data.
                - send an RA-Dist-Ack message with appropriate code
                  field

6.4 RA-Dist-Ack Processing

When creating a RA-Dist-Ack message, the transmitting entity MUST do
the following:

1.  Set the value of the type field to 07
2.  Determine the appropriate code field.
3.  Set the values for the Lifetime, Requestor Address, Target
    Address, and RKDC fields to the values found in the corresponding
    RA-Dist message.



Sanchez, Troxel                                                 [Page19]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


4.  Set the identification value used for anti-replay attack
    protection
5.  Calculate an integrity check value over the RA header, RA data,
    and the type, length and SPI fields of the authentication
    extension using the authentication key created during the
    establishment of the CMSA with that entity.
6.  Append the appropriate authentication extension to the message.

When an RKDC receives a RA-Dist-Ack message it MUST do the following:

1.  Verify the authenticator
    - If validation fails the message is silently discarded and the
      event
      MAY be logged
    - If validation succeeds:
    a) check identification field for AR protection.  If a replayed
       message is detected it is silently discarded and the event MAY
       be logged
    b) check the code field
       - If the value is 01 or 02 the RKDC destroys all keys
         corresponding to this particular RA exchange
       - If the value is 05 the RKDC SHOULD generate a new RA-Dist
         message following the procedure described in section 6.3

When an FA receives a RA-Dist-Ack Rep message it MUST check the RKDC
field in the RA header first. If the IP address is different than the
FA's address the FA MUST forward the message to that address.  If the
address is the FA's address then it MUST process the message in the
same way RKDCs do.

7.0 Agent Advertisement Processing

When supporting RA, a foreign agent MUST process received Agent
Advertisement from other FAs. Upon reception of an agent advertisement
with the RA advertisement extension, a foreign agent supporting RA
SHOULD establish a CMSA with the RKDCs listed in the extension.  If
the R bit is set, the foreign agent supporting RA SHOULD establish a
CMSA with the foreign agent that sent the RA advertisement since it is
serving as an RKDC. It is assumed that FAs are capable of establishing
CMSAs manually, using ZmKeyGen, ISAKMP/Oakley or some other mechanism.
If the FA does not support RA, Agent Advertisements from other FAs
MUST be ignored and the FA MUST continue with regular FA operations as
specified in RFC2002.

8.0 Performance Considerations

Requests from an MN to set up a RMSA MUST be authenticated to protect
against flooding attacks.  In particular, randomness for key
generation is a scarce resource.  It is important that message loss in
the RA protocol not cause authentication failures that should properly
be regarded as signs of an attack.  It is acceptable for a packet to


Sanchez, Troxel                                                 [Page20]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


arrive with an unknown SA identifier, but not for it to arrive with a
known identifier and then fail the authenticity check.

It might be possible for a message to arrive using an RMSA that has
not yet been created at the recipient.  We discuss a number of
strategies to avoid this problem and to deal with it.  An RMSA,
whether MN-FA or FA-HA, has an expected direction of use, since the
first use will be a registration request from the MN.  This suggests
two strategies.  One is that the message from FAi to FAj be sent
before the message from FAi to MN, assuming that it will arrive before
MN sends a message to FAj.  This will almost certainly be true in the
absence of loss.  The other is to include the message to FAj in the
message to MN, so that it may be included in the initial request.
Also, it may be both sent and included, so that in most cases it will
be processed before the message from MN arrives.

An entity creating an RMSA should cache response messages for a short
period of time (perhaps 30 seconds) so they may be resent.  This is
important both to conserve entropy used in key generation and to
ensure that the same response is generated to a subsequent
retransmission of the request, raising the likelihood that the
requesting pair for the RMSA will have a consistent RMSA.

An MN and an HA should be able to cache multiple associations with
RKDCs in multiple trust domains.  For example, assume foo.com has 30
FAs in "Corp", 30 FAs in "Research", and 5 each in "Dept-A" through
"Dept-Q".  As an MN roams, it creates MSAs with the first FA
encountered in each domain, and RMSAs with others.  Thus, as it
switches among FAs, it can encounter FAs from the various trust
domains, and still do only RA even though it may be switching from an
FA in one domain to an FA in another.  An MN (or HA) could use LRU
caching with a number of associations or some other strategy.

9.0 Security Considerations

Rapid Authentication uses a Kerberos-style key distribution approach,
to distribute the keying material and security contexts required by
mobility agents and nodes to generate Mobility Security Associations
for the purpose of authenticating Mobile IP control messages while in
a foreign domain.

Mobility Security Associations are uniquely identified by an SPI,
destination IP address and authentication protocol tuple. RKDCs have
no previous knowledge of exiting MSAs at the nodes and agents,
therefore making it possible for the RKDCs to generate SPI values
that match existing ones for a particular destination IP address and
authentication protocol pair. In the event of an SPI collision, either
the node or the agent will send an RA-Dist-Ack message to the RKDCs
with an invalid SPI error code. Upon reception of an RA-Dist-Ack
message with this error code, RKDCs generate new SPI and other
security contexts and transmit new RA-Dist messages.


Sanchez, Troxel                                                 [Page21]


Internet Draft     Rapid Authentication for Mobile IP      November 1997



Rapid Authentication protects against denial of service attacks using
replayed messages by using either timestamps or nonces.  The style of
replay protection is negotiated during the establisment of the CMSA.
Timestamping is the default anti-replay protection mechanism for Rapid
Authentication.  Timestamps require clock synchronization between the
sender and the receiver.  The use of Nonces for replay protection in
Rapid Authentication is optional.  RKDCs use the high-order bits of
the Identification field to insert its nonce value. Mobile nodes and
agents use the low-order bit of the identification field. RKDCs reply
to mobile nodes using RA-Rep messages. RKDCs copy the low order 32
bits of the Identification field found in the RA-Req message in
the Identification field of the reply. Mobile nodes and agents reply
to RA-Dist messages sent by RKDCs using RA-Dist-Ack messages. Nodes
and agents copy the high order 32 bits of the Identification field
found in the RA-Dist message in the identification field of the
reply. The value in the Identification field in RA control messages
should not repeat for the lifetime of the particular CMSA under which
the RA control messages are being protected.

Acknowledgments

The authors thank Andrea Lobo and Matt Condell for their participation
in requirements discussions for Rapid Authentication.  Our gratitude
to Isidro Castineyra, Matt Condell and Steve Kent for the significant
contributions to this document.  We thank Dennis Rockwell and Mary
Hendrix (INS Corp.) for reviewing this document.  We thank John Zao
and Steve Kent for their contributions to the early parts of this
work.

References

   [Bel89]   Steven M.  Bellovin, "Security Problems in the TCP/IP
             Protocol Suite", ACM Computer Communications Review, Vol.
             19, No.  2, March 1989.

   [Riv92]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
             April 1992.

   [Perk96]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [Kohl93]  Kohl, J., et.al, "The Kerberos Network Authentication
             Service (V5), RFC 1510, September 1993.

   [MOIPS97] J.Zao, et.al "A Public-Key Based Secure Mobile IP",
             Submitted to MobiCom 97.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.




Sanchez, Troxel                                                 [Page22]


Internet Draft     Rapid Authentication for Mobile IP      November 1997


Disclaimer

   The views and specification here are those of the authors and are
   not necessarily those of their employers.  The authors and their
   employers specifically disclaim responsibility for any problems
   arising from correct or incorrect implementation or use of this
   specification.

   Copyright (C) The Internet Society (November 1997).  All
   Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implmentation may be prepared, copied,
   published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the
   Internet Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards
   process must be followed, or as required to translate it into
   languages other than English. The limited permissions granted above
   are perpetual and will not be revoked by the Internet Society or
   its successors or assigns.

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS 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.

Author Information

   Luis A. Sanchez                  Gregory D. Troxel
   BBN Technologies                 BBN Technologies
   GTE Internetworking              GTE Internetworking
   10 Moulton Street                10 Moulton Street
   Cambridge, MA  02140             Cambridge, MA  02140
   USA                              USA
   Email: lsanchez@ir.bbn.com       Email: gdt@ir.bbn.com
   Telephone: +1 (617) 873-3351     Telephone: +1 (617) 873-2494


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