Subject: (mobile-ip) Comments on draft-ietf-mobileip-regkey-00.txt

From: Stuart Jacobs <[email-masked]>
Date: Thu, 05 Mar 1998 16:08:46 -0500

Following are some comments I have on draft-ietf-mobileip-regkey-00.txt

3. Establishing Registration Keys

   Foreign agents are expected to be cheap and widely available, as
   Mobile IP becomes fully deployed.  Mobile nodes will likely find it
   difficult to manage long-term security relationships with so many
   foreign agents.  To securely perform the operations needed for smooth
   handoffs from one foreign agent to the next, however, any careful
   foreign agent should require assurance that it is getting authentic
   handoff information, and not arranging to forward in-flight datagrams
   to a bogus destination.

Comment -->   The foreign agent needs to know the identity of the mobile node
Comment -->   before it allows the mobile node to use any significant
amount of
Comment -->   bandwidth from an access control standpoint..  From a billing
Comment -->   perspective, the foreign agent MUST have a non-reputable
identity
Comment -->   for the mobile node so the service provider, owning the visited
Comment -->   subnet, is able to capture network utilization information and,
Comment -->   thereby, generate bills for service consumers.

                            The messages described in this document are
   used with the Mobile IP Registration Request and Registration Reply
   messages to create (sufficient) trust between mobile node and foreign
   agent when none exists beforehand, while allowing the use of fully
   trustworthy security associations between foreign agents and mobile
   nodes whenever they do exist.

Comment -->   In a commercial setting there has to be strong trust between
Comment -->   mobility agents and mobile nodes.  Between mobility agents in
Comment -->   different networks owned/run by different service providers, the
Comment -->   trust relationship is key to allowing nodes to roam between
Comment -->   different service providers.  As noted above, the foreign agent
Comment -->   trust relationship with the mobile node is key to foreign
network
Comment -->   access control, billing and assurance to the mobile node that
the
Comment -->   foreign agent it is communicating with is a legitimate agent in
Comment -->   the network the mobile node wants to visit.

   Note that the mobile node can only rarely verify the identity of
   the foreign agent in any absolute terms.

Comment -->   By using public keys and X.509v3 digital certificates the mobile
Comment -->   node CAN verify the identity of the foreign agent in as absolute
Comment -->   sense as possible.  The use of a Public Key Infrastructure (PKI)
Comment -->   makes this approach feasible, scaleable and secure.

                                             It can only act on the
   presumption that the foreign agent is performing its duties by
   correct adherence to protocol.  The exact identity of the foreign
   agent is not crucial to the process of establishing a registration
   key.  Only an agreement to follow protocol can be expected or
   enforced.

Comment -->   The exact identity is crucial, the mobile node needs to know
it's
Comment -->   communicating with a legitimate foreign agent for the foreign
Comment -->   subnet, Not just that the foreign agent will follow the protocol
Comment -->   correctly.

              If the mobile node has a way to obtain a certified public
   key for the foreign agent, then the identity may be established in a
   firmer fashion, but the needed public key infrastructure seems to be
   at least five years distant.

Comment -->   A public key infrastructure across the Internet may be five
Comment -->   years out.  However a minimal PKI could be put in place in
Comment -->   many organizations now, using currently available mechanisms,
Comment -->   and would include:
Comment -->   -    X.509v3 digital certificates for all mobility agents,
mobile
Comment -->        nodes, the Certificate Authorities, the certificate
Comment -->        repositories (i.e., DNS, DNSSEC, LDAP, X.500) and
Comment -->   -    A certificate retrieval protocol (i.e., bind, LDAP, CDP).
Comment -->   If current validity of digital certificates is necessary then
Comment -->   Certificate Revocation Lists (CRLs) would also be needed.

                                 Therefore, the methods in this document
   enable a mobile node to create a registration key with an anonymous
   foreign agent (i.e., one whose identity we cannot establish) during
   the registration process.

Comment -->   By using a PKI, identities can be positively ascertained
during the
Comment -->   registration process; including verification of revoked
credentials

                              There are several proposed methods for
   establishing a registration key, discussed in order of declining
   preference.  Other methods of establishing keys may become available
   in the future.

    1. If the foreign agent and mobile node share a security
       association, it can be used to secure the Previous Foreign Agent
       Notification without need to establish a registration key.

Comment -->   Not reasonable to expect a mobile node and a foreign agent to
Comment -->   share an existing security association when the mobile node is
Comment -->   roaming across subnets owned/operated by different organizations

    2. If the home agent and foreign agent share a security association,
       the home agent can choose the new registration key.

Comment -->   With this approach, the home agent becomes a single point of
Comment -->   failure.  If it is compromised, then all registration keys could
Comment -->   become compromised.  However with a
Comment -->   PKI in place the foreign agent and home agent can strongly
Comment -->   authenticate themselves to the other by using their PKI
Comment -->   credentials and not have to use registration keys at all.

    3. If the foreign agent has a public key, it can again use the home
       agent to supply a registration key.

Comment -->   The foreign agent's public key has to be bound to the foreign
Comment -->   agent's identity by a trusted third party for the public key
to be
Comment -->   trustable.  Namely a public key from a foreign agent must be
Comment -->   transferred to the home agent as part of a digital certificate
Comment -->   which uses a trusted third party's (the Certificate Authority)
Comment -->   digital signature to formally establish the binding of the
public
Comment -->   key with the identity.  Otherwise the home agent has no way to
Comment -->   verify that the public key received belongs to the foreign
agent.

    4. If the mobile node includes its public key in its Registration
       Request, the foreign agent can choose the new registration key.

Comment -->   The mobile node's public key has to be bound to the mobile
node's
Comment -->   identity by a trusted third party (the Certificate Authority)
for the
Comment -->   public key to be trustable.  Namely a public key from a
mobile node
Comment -->   must be transferred to the foreign agent as part of a digital
certificate
Comment -->   which uses a trusted third party's
Comment -->   digital signature to formally establish the binding of the
public
Comment -->   key with the identity.  Otherwise the foreign agent has no
way to
Comment -->   verify that the public key received belongs to the mobile node.

    5. The mobile node and its foreign agent can execute a
       Diffie-Hellman key exchange protocol [2] as part of the
       registration protocol.

Comment -->   This approach does not provide any form of authentication and is
Comment -->   Tvulnerable to a man-in-the-middle attack nor allow the foreign
Comment -->   Tagent to perform access control.

The patents on the RSA public key algorithm are expiring within the next 18
months
so this technology will become un-emcumbered by licensing issues.
Consequently a PKI
for route optimized mobile IP could be defined and implemented using RSA.
Emperical
work has shown that a 150MHz pentium running Linux can generate RSA 512 bit
key
based signatures in under 12ms and validate these signatures in under 5ms;
both time
frames are sufficiently fast as to be usable with mobile IP.

==========================
Stuart Jacobs CISSP
Network Security
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
USA
telephone: (781) 466-3076
fax: (781) 466-2838
==========================
-----------------------------------------------------------------------------
IETF Mobile IP Working Group Mailing List - Archives:  software.watson.ibm.com
Unsubscribe:	unsubscribe mobile-ip		(as message body, not subject)
Direct all administrative requests to [email-masked]