[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
Internet Engineering Task Force                       S. Jacobs
INTERNET DRAFT                                        GTE Laboratories
                                                      August 1, 1998



                Mobile IP Public Key Based Authentication
                  draft-jacobs-mobileip-pki-auth-00.txt


Status of This Memo

   This document is a submission to the Mobile-IP Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to the mobile-ip@smallworks.com mailing list.

   Distribution of this memo is unlimited.

   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 made obsolete 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 learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This document proposes an extension to the Mobile IP base protocol.
   The purpose of this extension is to allow Mobile Nodes (Hosts) and
   Mobility Agents (both home network and foreign network) to use X.509
   digital certificates, public keys and digital signatures as the basis
   of authenticating Mobile IP control messages. The use of these
   mechanisms will allow Mobile IP to scale to tens of thousands of
   mobile nodes across networks owned-operated by different
   organizations and service providers.











Expires March 1, 1999                                           [Page i]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998


                                 Contents


Abstract ...........................................................  i

1.     Introduction.................................................  1
1.1.   Mobility Security Requirements ..............................  1
1.2.   Security Deficiencies of Mobile IP ..........................  3
1.3.   Trusted Third Party needed ..................................  5
1.4.   Terminology .................................................  5
1.5.   Security Enhancement ........................................  7
2.     Protocol Overview ...........................................  7
2.1    Agent Discovery .............................................  8
2.2    MN Processing of Agent Advertisements .......................  9
2.3    MN Registration Request Generation ..........................  9
2.4    Registration Request Authentication verification by FA ...... 10
2.5    FA Forwarding Registration Requests to HA ................... 10
2.6    Registration Request Authentication verification by HA ...... 11
2.7    HA Generation of Registration Reply ......................... 12
2.8    Registration Reply Authentication verification by FA ........ 12
2.9    FA Forwarding Registration Reply to MN ...................... 12
2.10   MN Receipt of Registration Reply forwarded by FA ............ 13
2.11   FA Generation of Registration Reply ......................... 13
2.12   MN Receipt of Registration Reply Generated by FA ............ 14
3.     Message and Extension Formats ............................... 14
3.1    Certificate Extension ....................................... 14
3.2.   Mobility Agent Advertisement Extension ...................... 15
3.3.   Registration Request Message ................................ 16
3.4.   Registration Reply .......................................... 18
3.5.   Mobile IP Authentication Extensions ......................... 19
3.5.1. Computing Authentication Extension Values ................... 19
3.5.2. Mobile Authentication Extension ............................. 19
3.5.3. Foreign Authentication Extension ............................ 20
3.5.4. Home Authentication Extension ............................... 21
3.5.5  Correct Sequence of Extension ............................... 21
4.     Certificates ................................................ 23
5.     Trust Hierarchy Paths ....................................... 24
6.     Certificate Revocation Lists ................................ 24
7.     Security Considerations ..................................... 26
A.     Patent Issues ............................................... 26

References ......................................................... 27
Authors' Address ................................................... 27









Expires March 1, 1999                                          [Page ii]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

1.    Introduction

   The Mobile IP base protocol [RFC2002] provides an efficient, scalable
   mechanism for node mobility within the Internet. However, so long as
   the authentication of Mobile IP control messages rely on the use of
   secret key mechanisms, then key management remains a major hindrance
   to large scale deployment of Mobile IP.

1.1.  Mobility Security Requirements

   As the use of mobile nodes becomes more common, five security related
   requirements become vital:
   -  Authentication. The receiver of a message must be able to
      ascertain who the actual originator of the message is; thereby
      preventing an intruder from masquerading as a legitimate source of
      the message in question.
   -  Authorization. The organization which owns/operates a network
      must have the ability to decide who may attach to the network
      and what network resources may be used by the attaching (visiting)
      node.
   -  Integrity. The receiver of a message must be able to ascertain
      whether a message has been modified in transit; thereby preventing
      an intruder from altering messages.
   -  Nonrepudiation. The sender of a message must not be able to
      falsely deny that it originated a message at a later time.
   -  Key Management. The only method available to accurately enforce
      authentication, integrity and nonrepudiation is by using some form
      of cryptography; which requires the distribution/exchange of
      encryption key information amongst message senders and receivers.

   Expanding on these points:

   AUTHENTICATION

   Authentication may be provided in many forms with varying degrees of
   assurance; from simple passwords transmitted in the clear to digital
   signatures based on either secret or public key cryptographic
   algorithms. The majority of networks mobile nodes visit will be
   wireless nets which are subject to eavesdropping and unable to
   control actual attachment via physical controls. Unless a commercial
   or military wireless network provides encryption, frequency hopping
   or other form of link layer access controls or privacy mechanisms, a
   rogue or hostile Foreign Agent (FA) could transmit messages
   indistinguishable from legitimate FA messages.

   When a Mobile Node (MN) receives an Agent Advertisement message, the
   MN needs to know that the advertisement comes from a valid FA on the
   network the MN wants to register with. In those cases where no
   authentication process between a FA and an MN occurs, or the
   authentication process used is computationally easy to negate, a
   hostile FA could easily masquerade as a legitimate FA and present a
   denial-of-service threat by:

Expires March 1, 1999                                           [Page 1]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   -  issuing Registration Reply messages stating the MN registration
      request is denied
   -  forwarding MN Registration Requests to an address other than that
      of the MN's Home Agent (HA) causing the MN to never receive a
      Registration Reply from it's HA, or
   -  discarding MN Registration Requests causing the MN to never
      receive a Registration Reply from it's HA.
   When a MN wants to attach to a foreign network, the FA needs to know
   the authentic identity of the MN so the FA can determine whether to
   allow the MN it's requested attachment. The actual decision to allow
   the attachment falls within the area of authorization but the FA
   cannot make a valid decision unless it knows, with some defined
   degree of assurance, that the MN is who it says it is.

   It becomes readily apparent that authentication plays a key role in
   IP mobility in avoiding denial-of-service risks and as the
   foundation for access control decisions.

   AUTHORIZATION

   Access control (authorization) at a foreign network being visited by
   an MN is critical within a mobile node context. Networks supporting
   visiting MNs need the ability to decide which MNs are allowed
   visiting rights. These networks also need a mechanism by which
   access control information may be defined, stored, validated and
   applied to requested MN visits. An IP mobility protocol needs to
   address the mechanism(s) by which a network node obtains
   authorization information and guidelines to ensure interoperability
   between different implementations.

   INTEGRITY

   Any messages sent between MNs, HAs and FAs that affect how IP packets
   are routed must be received at the destination exactly as sent by the
   message source. Failure to validate the integrity of these types of
   messages allows a hostile node to modify these messages while in
   transit. Modification could easily result in an MN's attempt to
   register at a foreign network being denied or the registration
   occurring but packets destined for the MN, at the foreign network,
   being miss-routed/lost.

   NONREPUDIATION

   When a MN visits a foreign network the MN will consume network
   resources (i.e., number of packets sent/received, number of packets
   detunneled by the FA, assigned IP address space, etc.). From the
   perspective of the organization responsible for the visited network,
   a record of what resources are consumed by the visiting MN needs to
   be kept for performance and accounting management purposes. Should
   the organization want to charge/bill for the use of these resources,
   then the FA must have a way of identifying which MN consumed what
   resources such that the owner of the MN cannot deny the visit or

Expires March 1, 1999                                           [Page 2]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   resources consumed.

   KEY MANAGEMENT

   Industrial strength authentication, integrity and nonrepudiation
   approaches are based primarily on the use of cryptographic
   algorithms. Modern cryptographic algorithms base their security
   capabilities on the use of a key, or keys, which allows the
   algorithm(s) to be publicly available so long as the keying
   information is kept and distributed in a private (i.e., secure)
   manner.

   One method for distributing the key information is to manually load
   it into each node. This is fine for a small number of nodes but runs
   into administrative problems. Page 29 of [Schneier96] highlights
   this problem by noting that if a separate key is used by each pair of
   nodes for authentication purposes, the total number of keys increases
   rapidly as the number of users increases. N users requires N(N-1)/2
   keys. Authentication amongst 100 nodes would require 4950 key pairs
   and amongst a 1000 nodes would require 499,500 keys, where each key
   must be kept private and distributed in a secure manner. It quickly
   becomes apparent that a manual key distribution approach is not
   feasible for use in IP mobility authentication except with a very
   small number of nodes.

   A truly viable solution for Mobile Nodes must scale well to large
   numbers of mobile nodes by providing a secure dynamic key
   distribution function.

1.2    Security Deficiencies of Mobile IP

   As already noted strong authentication is the corner-stone upon which
   access control, integrity, and non-repudiation rely. Mobile IP
   currently only requires that registration messages between an MN and
   its HA be authenticated. Registration messages between an HA and an
   FA, or between an MN and an FA, may be optionally authenticated.

   The majority of networks MNs visit will be wireless nets which are
   subject to eavesdropping and unable to control actual attachment via
   physical controls. Unless authentication between FAs and HAs and
   between FAs and MNs is mandatory, Mobile IP will never succeed
   commercially.

   A number of alternative approaches are under consideration for
   Mobile IP authentication, and associated key management/distribution.
   Although not part of any RFC at this time, these approaches are
   considered here.
   THE HA AS A KEY DISTRIBUTION CENTER (KDC)

   The approach of using the HA as a KDC, requires:
   -  the HA have a secret key based security association with the MN
   -  the HA have a secret key based security association with the FA

Expires March 1, 1999                                           [Page 3]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   -  the HA to generate, encrypt and distribute Registration keys for
      use by the FA and MN.

   This approach requires the use of three separate secret keys for one
   MN to register with one FA. When scaled to large networks we are
   facing the need for thousands of secret keys, two thirds of which are
   manually distributed and one third generated, encrypted and
   distributed dynamically as MNs register on foreign networks. An HA,
   supporting 20 MNs who roam to new foreign networks every 5 minutes,
   is faced with having to generate, encrypt and distribute as many as
   120 secret keys per hour (30 seconds for each new key). An HA,
   supporting 100 MNs who roam to new foreign networks every 2 minutes,
   is faced with having to generate, encrypt and distribute as many as
   3000 secret keys per hour (1200 milliseconds for each new key. These
   HA functions of generating, encrypting and distributing the MN-FA
   secret keys are in addition to all other HA activities. Can an HA
   perform these KDC functions on top of its responsibilities for
   handling traffic being tunneled to roaming MNs?  Another problem is
   how will the secret keys be distributed? Manual distribution of the
   secret key will not scale as previously discussed. This approach
   does not deal with the trust relationship between the MN and the FA
   for access control and non-repudiation. Again a  trusted third party
   is necessary for the FA to trust the MN from an identity standpoint.

   USING DIFFIE-HELLMAN WITH THE FOREIGN AGENT

   This approach allows MNs and FAs to establish registration keys by
   executing the Diffie-Hellman key exchange algorithm [Diffie76] as
   part of the MN's registration. Using the Diffie-Hellman algorithm
   allows the MN and the FA to establish a registration key without any
   pre-existing mobility security associations. One is still faced with
   the problem of manually distributing secret keys between MNs and HAs.
   This approach also does not deal with the trust relationship between
   the MN and the FA for access control and non-repudiation. Again a
   trusted third party is necessary for the FA to trust the MN from an
   identity standpoint.

   USING A MOBILE NODE PUBLIC KEY

   With this approach the FA is charged with generating the new
   registration key and returning a copy of it encrypted with the MN's
   Public Key, received in a MN Public Key extension. However the FA has
   no way of verifying if the public key received from the MN is valid
   for that MN since there is no authentication associated with the
   Public Key sent by the MN. This approach also does not deal with the
   trust relationship between the MN and the FA for access control and
   non-repudiation. Again a  trusted third party is necessary for the FA
   to trust the MN from an identity standpoint.

   USING A FOREIGN AGENT PUBLIC KEY

   The only real difference between this approach and that of using the

Expires March 1, 1999                                           [Page 4]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   HA as a KDC is that the HA uses an unauthenticated Public Key from
   the FA for encrypting the newly generated registration key being sent
   to the FA rather that an existing secret key security association
   between the HA and the FA. The inclusion of an MD5 digest of the FA's
   public key in a Registration Key Request Public Key Digest extension
   only establishes that the public key supplied by the FA in the FA
   Public Key extension is the same as received by the MN in an Agent
   Advertisement message.

1.3.   Trusted Third Party needed

   Use of public keys contained in Digital Certificates (Certificates)
   issued by trusted third parties, in the form of Certificate
   Authorities (CAs), provides the key ingredient for establishing trust
   Relationships between HAs, MNs and FAs. When an FA receives a message
   from an MN digitally signed with the MNs private key, the FA is able
   to validate the digital signature using a copy of the MN's public key
   from a copy of the MN's Certificate. If the FA shares the same CA as
   the MN, then the FA can easily authenticate the MN's Certificate by
   checking the CA digital signature within the MN's Certificate using
   the CA's public key from the copy of the CA's Certificate already in
   the FA's possession. Should the FA and the MN not use the same CA,
   the FA can establish a trust hierarchy path between the FA's CA and
   the CA of the MN. The converse is true for MNs authenticating digital
   signatures generated with FA private key and the same is true between
   HAs and FAs. The inclusion of the CA, or trust hierarchy path between
   CAs, allows Mobile IP aware systems to establish strong trust
   relationships to base authentication, access control and
   non-repudiation decisions on.

1.4.   Terminology

     Certification Authority (CA)
         A third party trusted by one or more users to create and assign
         digital certificates. All CAs are required to maintain a
         database of the Distinguished Names (DNs) which they have
         certified and to take measures to ensure that they do not
         certify duplicate DNs.

     Certificate-Revocation List (CRL)
         A data structure that contains that contains information about
         certificates whose validity an issuer has prematurely revoked.
         The information consists of an issuer name, the time of issue,
         the next scheduled time of issue, and a list of certificate
         serial numbers and their associated revocation times. The CRL
         is signed by the issuer. The data structure is defined in
         [RFC1422]

     Certificate Subject (Subject)
         A Certificate Subject, or Subject, is the entity referred to by
         the Distinguished Name (DN) contained within the Certificate.


Expires March 1, 1999                                           [Page 5]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

     Digital Certificate (Certificate)
         A Digital Certificate, or Certificate, is a data structure
         that binds an entity's Distinguished Name (DN) to a public key
         with a digital signature. This data structure is defined in
         [X.509]. and contains information, such as identify and public
         key, about an entity where an authority, called a Certification
         Authority, has cryptographicly linked the information together
         using a digital signature.

     Digital Certification
         Digital Certification is the mechanism in which a Certification
         Authority (CA) "signs" a special data structure containing the
         name of some entity, or Subject, and their public key in such a
         way that anyone can "verify" that the message was signed by no
         one other than the certification authority and thereby develop
         trust in the subject's public key.

     Digital Signature
         the content to be signed is first reduced to a message digest
         with a message-digest algorithm (such as MD5), and then the
         octet string containing the message digest is encrypted with
         the RSA private key of the signer of the content.

     Distinguished Name (DN)
         A Distinguished Name, or DN, defines a "path" through an X.500
         directory tree from the root of the tree to an object of
         interest.

     Message-Digest Algorithm
         A message-digest algorithm is a method of reducing a message of
         Any length to a string of a fixed length, called the message
         digest, in such a way that it is computationally infeasible to
         find a collision (two messages with the same message digest) or
         to find a message with a given, predetermined message digest.
         MD2 and MD5 are message-digest algorithms described in
         [RFC1319] and [RFC1321]. Each inputs an arbitrary message and
         outputs a 128-bit message digest.

     Public-key algorithm
         An algorithm for encrypting or decrypting data with a public or
         Private key. When a private key is used to encrypt a message
         digest the public-key algorithm is called a message-digest
         encryption algorithm and the encrypted output is called a
         Digital Signature. This algorithm transforms a message of any
         length under a private key to a signature in such a way that it
         is computationally infeasible to find two messages with the
         same signature, to find a message with a given, predetermined
         signature, or to find the signature of a given message without
         knowledge of the private key. Typically, a digital signature is
         created by computing a message digest on the message, then
         encrypting the message digest with the private key.


Expires March 1, 1999                                           [Page 6]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

     Public-key cryptography
         Public-key cryptography is the technology first identified by
         Diffie and Hellman [Diffie76] in which encryption and
         Decryption involve different keys. The two keys are the public
         key and the private key, and either can encrypt or decrypt
         data. A user gives his or her public key to other users,
         keeping the Private key to himself or herself.

     RSA
         RSA is a public-key algorithm invented by Rivest, Shamir, and
         Adleman [RSA78] involving exponentiation modulo the product of
         two large prime numbers. The difficulty of breaking RSA is
         generally considered to be equal to the difficulty of factoring
         integers that are the product of two large prime numbers of
         approximately equal size.

1.5.   Security Enhancement

   The design goal of the Public Key Authentication (PKA) model is to
   add scaleable strong authentication to Mobile IP. The PKA enabled
   Mobile IP protocol works exactly the same way as the base protocol
   for the FA supplied card-of-address (COA) mode of operation except
   for the mechanism responsible for generating/verifying message
   authenticators and the data structures supporting the proposed
   digital signature based authenticators.

   The Co-located COA mode (sometimes referred to as "pop-up" mode)
   relies on the use of DHCP [RFC1541] and cannot be considered
   deployable on a wide scale since DHCP does not include any
   authentication and assumes that nodes requesting DHCP assigned
   addresses either belong to the same organization operating the DHCP
   server or these nodes will be authenticated for network use outside
   of DHCP. The typical uses of DHCP are to: 1) simplify IP address
   management in an organizations LAN campus environment, or 2) allow
   ISP customers to remotely connect to the ISP' infrastructure. ISPs
   using DHCP require the connecting customer to provide a user ID and a
   password before the ISP will accept user traffic from the connecting
   customer.

2.     Protocol Overview

   Under the PKA model, a complete registration cycle consists of:
   -  the MN receiving a Mobility Agent Advertisement
   -  the MN sending a Registration Request to the FA
   -  the FA preprocessing the received Registration Request and, if
      tentatively approved, passing the Registration Request to the MN's
      HA
   -  the HA receiving the Registration from the MN via the FA
   -  the HA processing the Registration Request and sending a
      Registration Reply to the FA



Expires March 1, 1999                                           [Page 7]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   -  the FA receiving the Registration Reply, updating visiting MN data
      structures, and sending the completed Registration Reply to the
      visiting MN.
   Proposed authentication changes apply to the messages associated with
   both the Agent Discovery and the Registration procedures. The primary
   message change supporting the PKA model is the use of a Certificate
   Extension appended to Mobile IP control messages (Mobility Agent
   Advertisement Extension, Registration Requests and Registration
   Replies).

   The Certificate Extension includes a copy, or copies, of Certificates
   that bind system "distinguished names" to public keys using a digital
   signature. A Certificate Extension will always contain at least one
   Certificate issued by a Certificate Authority (CA) to the sender, or
   forwarder, of a message. There may also be present in the Certificate
   Extension Certificates belonging to one of more CAs. When FAs and MNs
   share a common CA, only the Certificate of the common CA would ever
   appear in the Certificate Extension. In the case where the FA and the
   MN do not have a common CA, the Certificate Extension will contain
   multiple CA Certificates from which a trust hierarchy path between
   the CA of the MN and the CA of the FA may be established (see Section
   4. For details on establishing trust hierarchy paths)

2.1    Agent Discovery

   In the base protocol, FAs advertise their presence via a Mobility
   Agent Advertisement Extension appended to ICMP Router Advertisements
   generated by Mobility Agents acting as Foreign Agents. The visiting
   MN obtains a COA (which usually is the FA's address)from these
   Mobility Agent Advertisement Extensions (Agent Advertisements).

   The PKA model requires that the Agent Advertisement include a digital
   signature that is used to  authenticate the contents of the Agent
   Advertisement message and a Certificate Extension so that prospective
   MNs can quickly obtain an authentic copy of the FA's public key,
   necessary to verify the digital signature. The specific
   authentication steps the FA follows are:
   1.  the FA uses it's private key to produce a digital signature
       spanning all Agent Advertisement message fields, as specified in
       [RFC2002].
   2.  The FA creates a Certificate Extension placing a copy of its
       Certificate and a copy of the Certificate belonging to FA's CA
       into the Certificate Extension.
   3.  The FA also places copies of the Certificates of those CAs
       necessary for an MN to establish a trust hierarchy path between
       CAs into the Certificate Extension.
   4.  The FA appends the Certificate Extension to the Agent
       Advertisement message (Extension).
   5.  The FA follows the base Mobile IP protocol regarding the
       transmission of Agent Advertisement messages.



Expires March 1, 1999                                           [Page 8]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

2.2    MN Processing of Agent Advertisements

   When the MN receives an Agent Advertisement, the MN follows the base
   Mobile IP protocol except for the following authentication actions:
   1.  the MN extracts the Certificates from the Certificate Extension
       and, in the case where the FA and the MN share the same CA, the
       MN uses the CA's public key to validate the FA's Certificate.
   2.  In the case where the MN and the FA do not share a common CA, the
       MN uses any other CA Certificates contained in the Certificate
       Extension to establish a trust hierarchy path between the MN's CA
       and the FA's CA (see Section 5.0).
   3.  In the case where the MN is unable to establish a trust hierarchy
       path between the CAs, the MN ceases further authentication
       processing and considers the Agent Advertisement message not
       authentic, the sending FA as not a valid candidate to register
       with and the MN ignores this Agent Advertisement message.
   4.  Should the MN be able to establish a trust hierarchy path between
       CAs, the MN proceeds down the path verifying CA Certificates
       stopping when the Certificate of the advertising FA has been
       verified.
   5.  Upon verification of the FA's Certificate, the MN uses
       the FA's public key from the FA Certificate to verify the
       digital signature, created using the FA's private key.
   6.  Upon successful verification of the Agent Advertisement digital
       signature, the MN continues with normal processing of the Agent
       Advertisement message as specified in the base Mobile IP
       protocol.
   7.  Should the Agent Advertisement digital signature not pass
       verification, the MN ceases further processing and considers the
       Agent Advertisement message as not authentic, the sending FA as
       not a valid candidate to register with and the MN ignores this
       Agent Advertisement message.

2.3    MN Registration Request Generation

   When the MN generates a Registration Request message, the MN follows
   The base Mobile IP protocol except for the following authentication
   actions:
   1.  the MN uses it's private key to produce a digital signature
       spanning all Registration Request message fields as specified in
       Section 3.5.5 and places this digital signature in a Mobile
       Authentication Extension.
   2.  The MN then creates a Certificate Extension placing a copy of its
       Certificate and a copy of the Certificate of the MN's CA into the
       Certificate Extension.
   3.  Should the MN and the FA not share a common CA, the MN also
       places copies of the Certificates of those CAs necessary for the
       FA to establish a trust hierarchy path between CAs.
   4.  The MN appends the Certificate Extension to the end of the
       Registration Request message following the Mobile Authentication
       Extension.
   5.  The MN continues with the actions specified in RFC2002 for

Expires March 1, 1999                                           [Page 9]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

       sending out Registrations Requests.

2.4    Registration Request Authentication verification by FA

   When the FA receives a Registration Request from an MN, the FA
   follows the base Mobile IP protocol except for the following
   authentication actions:
   1.  the FA extracts the Certificates from the Certificate Extension
       and, in the case where the FA and the MN share the same
       CA, the FA uses the CA's public key to validate the MN's
       Certificate.
   2.  In the case where the MN and the FA do not share a common CA,
       then the FA uses any other CA Certificates contained in
       the Certificate Extension to establish a trust hierarchy path
       between the FA's CA and the MN's CA.
   3.  In the case where the FA is unable to establish a trust hierarchy
       path between the CAs, the FA ceases further authentication
       processing and considers the Registration Request message not
       authentic, the sending MN as not allowed to attach to the FA's
       network, the FA logs the authentication failure and creates a
       Registration Reply message (see Section 2.11) informing the MN
       that the MN's Registration Request is not allowed having failed
       authentication.
   4.  Should the FA be able to establish a trust hierarchy path between
       CAs. The FA proceeds down the path verifying CA Certificates
       stopping when the Certificate of the MN has been verified.
   5.  The FA uses the MN's public key from the MN Certificate
       to verify the digital signature in the Mobile Authentication
       Extension, created using the MN's private key.
   6. Upon successful verification of the Mobile Authentication
       Extension digital signature, the FA continues with normal
       processing of the Registration Request message as specified in
       the base Mobile IP protocol except for authentication actions
       (see Section 2.5).
   7.  Should the Mobile Authentication Extension digital signature not
       pass verification, the FA ceases further authentication
       processing and considers the Registration Request message not
       authentic, the sending MN as not allowed to attach to the FA's
       network, the FA logs the authentication failure and creates a
       Registration Reply message (see Section 2.11) informing the MN
       that the MN's Registration Request is not allowed having failed
       authentication.

2.5    FA Forwarding Registration Requests to HA

   When the FA finishes basic Registration Request processing and is
   preparing to forward the Registration Request to the MN's Home Agent
   (HA), the FA performs the following authentication actions:
   1.  The FA deletes the received Certificate Extension.
   2.  the FA uses it's private key to produce a digital signature
       spanning all Registration Request message fields as specified in
       Section 3.5.5 and places the digital signature in a Foreign

Expires March 1, 1999                                          [Page 10]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

       Authentication Extension located following the Mobile
       Authentication Extension.
   3.  The FA places a copy of its Certificate and a copy of the
        Certificate belonging to FA's CA into a new Certificate
       Extension.
   4.  Should the MN and the FA not share a common CA, then the FA also
       places copies of the Certificates of those CAs necessary for the
       HA to establish a trust hierarchy path between CAs.
   5.  The FA appends the Certificate Extension to the end of the
       Registration Request message following the Foreign Authentication
       Extension.
   6.  The FA continues with the actions specified in [RFC2002] for
       sending out Registrations Requests.

2.6    Registration Request Authentication verification by HA

   When the HA receives a Registration Request forwarded from an FA, the
   HA follows the base Mobile IP protocol except for the following
   authentication actions:
   1.  the HA extracts the Certificates from the Certificate Extension
       and, in the case where the FA and the HA share the same CA, the
       HA uses the CA's public key to validate the FA's Certificate.
   2.  In the case where the HA and the FA do not share a common CA,
       then the HA uses any other CA Certificates contained in
       the Certificate Extension to establish a trust hierarchy path
       between the HA's CA and the FA's CA.
   3.  In the case where the HA is unable to establish a trust hierarchy
       path between the CAs, the HA ceases further authentication
       processing and considers the Registration Request message
       invalid, the forwarding FA as untrustworthy as a Foreign Agent,
       the HA logs the authentication failure and creates a Registration
       Reply message informing the FA that the MN's Registration Request
       is not allowed having failed FA authentication.
   4.  Should the HA be able to establish a trust hierarchy path between
       CAs. The HA proceeds down the path verifying CA Certificates
       stopping when the Certificate of the FA has been verified.
   5.  The HA uses the FA's public key from the FA Certificate
       to verify the FA digital signature in the Foreign Authentication
       Extension, created using the FA's private key.
   6.  The HA uses the MN's public key, from the MN Certificate
       that the HA already possesses, to verify the MN digital signature
       in the Mobile Authentication Extension, created using the MN's
       private key.
   7.  Upon successful verification of the Registration Request message
       digital signatures, the HA continues with normal processing of
       the Registration Request message as specified in the base Mobile
       IP protocol except for authentication actions.
   8.  Should the Registration Request message digital signatures not
       pass verification, the HA ceases further authentication
       processing and considers the Registration Request message not
       authentic, the requested registration as prohibited, the HA logs
       the authentication failure and creates a Registration Reply

Expires March 1, 1999                                          [Page 11]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

       message informing the FA and the MN that the MN's Registration
       Request is not allowed having failed authentication.

2.7    HA Generation of Registration Reply

   When the HA generates a Registration Reply message, the HA follows
   the base Mobile IP protocol except for the following authentication
   actions:
   1.  the HA uses it's private key to produce a digital signature
       spanning all Registration Request message fields as specified in
       Section 3.5.5 and places the digital signature in an Home
       Authentication Extension which it appends to the Registration
       Reply.
   2.  The HA then creates a Certificate Extension placing a copy of its
       Certificate into the Certificate Extension.
   3.  The HA appends the Certificate Extension to the end of the
       Registration Request message following the Home Authentication
       Extension.
   4.  The HA continues with the actions specified in [RFC 2002] for
       sending out Registrations Requests.

2.8    Registration Reply Authentication verification by FA

   When the FA receives a Registration Reply from an HA, the FA follows
   the base Mobile IP protocol except for the following authentication
   actions:
   1.  the FA extracts the HA's Certificate from the Certificate
       Extension and uses the public key from the Certificate of
       the HA's CA to validate the HA's Certificate. The FA already has
       a validated copy of the Certificate for the HA's CA from when the
       FA established the trust hierarchy path for the Certificate of
       MN's CA since the MN and the HA will share a common CA.
   2.  The FA uses the HA's public key from the HA Certificate
       to verify the digital signature in the Home Authentication
       Extension, created using the HA's private key.
   3.  Upon successful verification of the Home Authentication Extension
       digital signature, the FA continues with normal processing of the
       Registration Reply message as specified in the base Mobile IP
       protocol except for authentication actions (see Section 2.9).
   4.  Should the Registration Reply message digital signature not pass
       verification, the FA ceases further authentication processing and
       considers the Registration Reply message not authentic, the
       sending HA as not a valid HA, the FA logs the authentication
       failure and creates a Registration Reply message informing the MN
       that the MN's Registration Request is not allowed having failed
       authentication.

2.9   FA Forwarding Registration Reply to MN

   When the FA finishes basic Registration Reply processing and is
   preparing to forward the Registration Reply to the MN, the FA
   performs the following authentication actions:

Expires March 1, 1999                                          [Page 12]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   1.  The FA deletes the Certificate Extension.
   2.  the FA uses it's private key to produce a digital signature
       spanning all Registration Reply message fields as specified in
       Section 3.5.5 and places the digital signature in a Foreign
       Authentication Extension following the Home Authentication
       Extension.
   3.  The FA places a copy of its Certificate into a new
       Certificate Extension.
   4.  The FA appends the Certificate Extension to the end of the
       Registration Request message following the Foreign Authentication
       Extension.
   5.  The FA continues with the actions specified in [RFC2002] for
       sending out Registrations Replies.

2.10   MN Receipt of Registration Reply forwarded by FA

   When the MN receives a Registration Reply forwarded from an FA, the
   MN follows the base Mobile IP protocol except for the following
   authentication actions:
   1.  the MN extracts the FA's Certificate from the Certificate
       Extension.
   2.  The MN uses the FA's public key from the FA Certificate to verify
       the FA digital signature in the Foreign Authentication Extension,
       created using the FA's private key.
   3.  The MN uses the HA's public key, from the HA Certificate,
       that the MN already possesses, to verify the HA digital signature
       in the Home Authentication Extension, created using the HA's
       private key.
   4.  Upon successful verification of the Registration Reply message
       digital signatures, the MN continues with normal processing of
       the Registration Reply message as specified in the base Mobile IP
       protocol except for authentication actions.
   5.  Should the Registration Reply message digital signatures not pass
       verification, the MN ceases further authentication processing and
       considers the Registration Reply message not authentic, the MN
       logs the authentication failure and restarts its efforts to find
       a foreign network the MN can register with.

2.11    FA Generation of Registration Reply

   When the FA generates a Registration Reply message rejecting an MN's
   request to register with the FA's network, the FA follows the base
   Mobile IP protocol except for the following authentication actions:
   1.  The FA uses it's private key to produce a digital signature
       spanning all Registration Rely message fields as specified in
       Section 3.5.5 and places the digital signature into a Foreign
       Authentication Extension appended to the Registration Reply.
   2.  The FA then creates a Certificate Extension placing a copy of its
       Certificate into the Certificate Extension.
   3.  The FA appends the Certificate Extension to the end of the
       Registration Reply message following the Foreign Authentication
       Extension.

Expires March 1, 1999                                          [Page 13]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   4.  The FA continues with the actions specified in [RFC2002] for
       sending out Registrations Replies.

2.12   MN Receipt of Registration Reply Generated by FA

   When the MN receives a Registration Reply generated by an FA, the MN
   follows the base Mobile IP protocol except for the following
   authentication actions:
   1.  the MN extracts the FA's Certificate from the Certificate
       Extension.
   2.  The MN uses the FA's public key from the FA Certificate
       to verify the FA digital signature in the Foreign Authentication
       Extension, created using the FA's private key.
   3.  Upon successful verification of the Registration Reply message FA
       digital signature, the MN continues with normal processing of the
       Registration Reply message as specified in the base Mobile IP
       protocol except for authentication actions.
   4.  Should the Registration Reply message FA digital signature not
       pass verification, the MN ceases further authentication
       processing and considers the Registration Reply message not
       authentic, the MN logs the authentication failure and restarts
       its efforts to find a foreign network the MN can register with.
3.     Message and Extension Formats

3.1    Certificate Extension

   The Certificate Extension is used to transfer authentication
   information (Certificates) between MNs, FAs and HAs. The fields of
   the Certificate Extension are:

    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      |           Ext-Length          |   Cert-cnt    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sender-Certificate-Length    |        Sender-Certificate
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Sender-Certificate, continued ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     CA-Certificate-Length     |        CA-Certificate
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   CA-Certificate, continued ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type:   10   (1 byte), identifies this as a Certificate Extension.

      Ext Length:   (2 bytes) The length of the Certificate Extension
                    in bytes.
                    set to 4 + value of Authenticator-Length field
                              + value of Source-Certificate-Length field
                              + value of CA-Certificate-Length field


Expires March 1, 1999                                          [Page 14]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998


      Sender-Certificate-Length:   (2 bytes) Length in bytes of the
                                    X.509 Type 3 formatted Certificate
                                    of the message sender.

      Sender-Certificate:   (variable length), The X.509 Type 3
                             Formatted Certificate of the message sender
                             which contains the public key of the
                             message sender.

      CA-Certificate-Length:   (2 bytes) Length in bytes of the X.509
                                Type 3 formatted certificate of a
                                Certificate Authority (CA).

      CA-Certificate:   (variable length), The X.509 Type 3 formatted
                         certificate of a CA which contains the public
                         key of the CA used to sign Certificates.

3.2.   Mobility Agent Advertisement Extension

   The Mobility Agent Advertisement Extension follows the ICMP Router
   Advertisement fields. It is used to indicate that an ICMP Router
   Advertisement message is also an Agent Advertisement being sent by a
   mobility agent. The Mobility Agent Advertisement Extension is
   defined as follows:

    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     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Registration Lifetime      |R|B|H|F|M|G|V|A|   Auth Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Foreign Agent Digital Signature             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     16

      Length   (6 + 4*N + S), where N is the number of care-of addresses
               Advertised and S is the length of the Digital Signature
               used by an FA to authenticate the other fields in the
               Mobility Agent Advertisement Extension.

      Sequence Number
               Unchanged from base Mobile IP protocol.

      Registration Lifetime
               Unchanged from base Mobile IP protocol.



Expires March 1, 1999                                          [Page 15]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

      R        Registration required. Registration with this foreign
               agent (or another foreign agent on this link) is
               required. Must be always set.

      B        Unchanged from base Mobile IP protocol.

      H        Unchanged from base Mobile IP protocol.

      F        Unchanged from base Mobile IP protocol.

      M        Unchanged from base Mobile IP protocol.

      G        Unchanged from base Mobile IP protocol.

      V        Unchanged from base Mobile IP protocol.

      A        Authorization by digital signature, MUST be set.

      Auth Type
               Identifies the cryptographic method (algorithm) and key
               Length used to generate digital signatures. Valid
               Authentication types are:

                 Auth. Type                Key Length  Digital Signature
                   Value     Algorithm     in bits     Length in bytes
                 ---------   ---------     ----------  -----------------
                    101         RSA           512             64
                    102         RSA          1024            128

               Other Authentication types will be defined in the future.

      Care-of Address(es)
               Unchanged from base Mobile IP protocol.

3.3.   Registration Request Message

   An MN registers with its HA using a Registration Request message so
   that its HA can create or modify a mobility binding for that MN. The
   Request is always relayed to the HA by the FA through which the MN is
   registering.

   IP fields:

      Unchanged from base Mobile IP protocol.

   UDP fields:

      Source Port        variable

      Destination Port   434



Expires March 1, 1999                                          [Page 16]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   The UDP header is followed by the Mobile IP fields shown 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      |S|B|r|M|G|V|A|t|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     1 (Registration Request)

      S        Unchanged from base Mobile IP protocol.

      B        Unchanged from base Mobile IP protocol.

      r        Reserved bit; sent as zero.

      M        Unchanged from base Mobile IP protocol.

      G        Unchanged from base Mobile IP protocol.

      V        Unchanged from base Mobile IP protocol.

      A        Authorization by digital signature, MUST be set.

      t        Reserved bit; sent as zero

      Lifetime
               Unchanged from base Mobile IP protocol.

      Home Address
               Unchanged from base Mobile IP protocol.

      Home Agent
               Unchanged from base Mobile IP protocol.

      Care-of Address
               Unchanged from base Mobile IP protocol.

      Identification
               Unchanged from base Mobile IP protocol.

Expires March 1, 1999                                          [Page 17]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

      Extensions
               Usage is same as in base Mobile IP protocol except for
               -  Mobile-Home Authentication Extension which MUST be
                  included in all Registration Requests.
               -  Foreign-Home Authentication Extension which MUST be
                  included for all Registration Requests being forwarded
                  from an FA to an HA
               -  Certificate Extension which must be included on all
                  Registration Requests.

3.4.   Registration Reply

   A mobility agent (FA or HA) returns a Registration Reply message to an MN
   which has sent a Registration Request (Section 3.3) message.

   IP fields:

      Source Address        Unchanged from base Mobile IP protocol.

      Destination Address   Unchanged from base Mobile IP protocol.

   UDP fields:

      Source Port           <variable>

      Destination Port      Unchanged from base Mobile IP protocol.

   The UDP header is followed by the Mobile IP fields shown 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      |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     3 (Registration Reply)

      Code     A value indicating the result of the Registration
               Request. See below for a list of currently defined Code
               values.



Expires March 1, 1999                                          [Page 18]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

      Lifetime
               Unchanged from base Mobile IP protocol.

      Home Address
               Unchanged from base Mobile IP protocol.

      Home Agent
               Unchanged from base Mobile IP protocol.

      Identification
               Unchanged from base Mobile IP protocol.

      Extensions
               Usage is same as in base Mobile IP protocol except for
               -  Mobile-Home Authentication Extension which MUST be
                  included in all Registration Replies.
               -  Foreign-Home Authentication Extension which MUST be
                  included for all Registration Replies being forwarded
                  from an FA to an MN
               -  Certificate Extension which must be included on all
                  Registration Replies.

   No new values defined for use within the Code field.

3.5.   Mobile IP Authentication Extensions

3.5.1. Computing Authentication Extension Values

   The digital signature computed for each authentication Extension MUST
   protect the following fields from the registration message:

    -  the UDP payload (that is, the Registration Request or
       Registration Reply data),

    -  all prior Extensions in their entirety, and

    -  the Type and Length of this Extension.

   The default authentication algorithm uses RSA and a 512 bit private
   key to compute a 512-bit cryptographic "message digest" of the
   registration message. The default digital signature is a 512-bit
   value computed over the protected fields from the registration
   message.

   Note that the digital signature field itself and the UDP header are
   NOT included in the computation of the digital signature value.

3.5.2. Mobile Authentication Extension

   Exactly one Mobile Authentication Extension MUST be present in all
   Registration Requests. The location of the extension marks the end
   of the authenticated data.

Expires March 1, 1999                                          [Page 19]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

    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    |   Auth Type   |    reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Mobile Node (MN) Digital Signature            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            32

      Length          4 plus the number of bytes in the digital
                      signature.

      Auth Type
               Valid if the A bit set, in which case this field
               identifies the cryptographic method (algorithm) and key
               length used to generate digital signatures. Valid
               Authentication types are:

                 Auth. Type                Key Length  Digital Signature
                   Value     Algorithm     in bits     Length in bytes
                 ---------   ---------    ----------  -----------------
                    101         RSA           512             64
                    102         RSA          1024            128

               Other Authentication types will be defined in the future.

      Digital Signature   (variable length) (See Section 3.5.1.)

3.5.3. Foreign Authentication Extension

   This Extension MUST be included in Registration Requests being passed
   from an FA to an HA or Registration Replies sent from an FA to a MN.

    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    |   Auth Type   |    reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Foreign Agent (FA) Digital Signature               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            33

      Length          4 plus the number of bytes in the digital
                      signature.

      Auth Type
               Valid if the A bit set, in which case this field
               identifies the cryptographic method (algorithm) and key
               length used to generate digital signatures. Valid
               Authentication types are:

Expires March 1, 1999                                          [Page 20]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

                 Auth. Type                Key Length  Digital Signature
                   Value     Algorithm     in bits     Length in bytes
                 ---------   ---------    ----------  -----------------
                    101         RSA           512             64
                    102         RSA          1024            128

               Other Authentication types will be defined in the future.

      Digital Signature   (variable length) (See Section 3.5.1.)

3.5.4. Home Authentication Extension

   This Extension MUST be included in Registration Replies being passed
   from an HA to an FA.

    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    |   Auth Type   |    reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Home Agent (HA) Digital Signature                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            34

      Length          4 plus the number of bytes in the digital
                      signature.

      Auth Type
               Valid if the A bit set, in which case this field
               identifies the cryptographic method (algorithm) and key
               length used to generate digital signatures. Valid
               Authentication types are:

                 Auth. Type               Key Length  Digital Signature
                   Value     Algorithm     in bits     Length in bytes
                 ---------   ---------    ----------  -----------------
                    101         RSA           512             64
                    102         RSA          1024            128

               Other Authentication types will be defined in the future.

      Digital Signature   (variable length) (See Section 3.5.1.)

3.5.5  Correct Sequence of Extension.

   Mobile IP Extensions MUST occur in the following sequences.

   For Registration Request sent from MN to FA:




Expires March 1, 1999                                          [Page 21]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998


         Registration Request
         Mobile Authentication Extension
         Certificate Extension

      The digital signature in the Mobile Authentication Extension MUST
      be generated over all the fields in the Registration Request
      starting with the Type field (inclusively) and continuing through
      the fields of the Mobile Authentication Extension ending with the
      Auth Type field (inclusively) in the Mobile Authentication
      Extension.

   For Registration Request sent to HA from FA:

         UDP Header
         Registration Request
         Mobile Authentication Extension
         Foreign Authentication Extension
         Certificate Extension

      The digital signature in the Foreign Authentication Extension MUST
      be generated over all the fields in the Registration Request
      starting with the Type field (inclusively) and continuing through
      the fields of the Mobile Authentication Extension and the Foreign
      Authentication Extension ending with the Auth Type field
      (inclusively) in the Foreign Authentication Extension.

   For Registration Reply sent to FA from HA:

         UDP Header
         Registration Reply
         Home Authentication Extension
         Certificate Extension

      The digital signature in the Home Authentication Extension MUST be
      generated over all the fields in the Registration Reply starting
      with the Type field (inclusively) and continuing through the
      fields of the Home Authentication Extension ending with the Auth
      Type field (inclusively) in the Home Authentication Extension.

   For Registration Reply forwarded to MN from FA:

         UDP Header
         Registration Reply
         Home Authentication Extension
         Foreign Authentication Extension
         Certificate Extension

      The digital signature in the Foreign Authentication Extension MUST
      be generated over all the fields in the Registration Reply
      starting with the Type field (inclusively) and Home Authentication
      Extension through the fields of the Foreign Authentication

Expires March 1, 1999                                          [Page 22]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

      Extension ending with the Auth Type field (inclusively) in the
      Foreign Authentication Extension.

   For Registration Reply sent to MN from FA:

         UDP Header
         Registration Reply
         Foreign Authentication Extension
         Certificate Extension

      The digital signature in the Foreign Authentication Extension MUST
      be generated over all the fields in the Registration Reply
      starting with the Type field (inclusively) and continuing through
      the fields of the Foreign Authentication Extension ending with the
      Auth Type field (inclusively) in the Foreign Authentication
      Extension.

4.      Certificates

   All Certificates used with Mobile IP MUST include the following
   Fields:

      Distinguished Name - The Distinguished Name (DN) is the sender's
                           IP address in dot-decimal notation
                           (aaaa.bbb.ccc.ddd). The use of this field is
                           a variation of the DN approach defined in
                           [X.500] given that the identity that needs to
                           be verified, and bound to a specific public
                           key, is the IP address of the network
                           interface the MN, FA or HA uses in the
                           context of PKA Mobile IP.

      Not Valid Before Date - Not Valid Before Date (NVBD) is that date
                              prior to which the Certificate is not
                              valid

      Not Valid After Date - Not Valid After Date (NVAD) is that date
                             After which the Certificate is not valid

      CA Distinguished Name - The CA Distinguished Name (DN) is as
                              defined in [X.500]

      Subject Public Key - Subject Public Key is the binary string of
                           Octets containing the public key of the
                           sender

      Public Key Algorithm - Public Key Algorithm is the field that
                             Identifies the type of public key algorithm
                             the sender's public key must be used with

      Public Key Size - Public Key Size is the field that identifies
                        the size of the sender's public key in octets

Expires March 1, 1999                                          [Page 23]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

      CA Digital Signature - CA Digital Signature is the digital
                             Signature generated by the sender's CA that
                             binds the other fields of the Certificate
                             together cryptocraphicly

      Certificate Serial Number - A unique number assigned to a
                                  Certificate by the CA that creates and
                                  digitally signs the Certificate. This
                                  serial number is used to positively
                                  identify the Certificate

5.      Trust Hierarchy Paths

   A Trust Hierarchy Path is the establishment of a logical chain
   between two Certificate Authorities (CAs) and reflects a trust
   relationship that can be established through intervening CAs.
   Validation of a Certificate involves constructing a Trust Hierarchy
   Path between the sender Certificate, the CA that issued the sender
   Certificate and the CA of the validating system. The validity
   interval for every Certificate in this path must be checked.
   Establishing a trust hierarchy path MUST be performed to verify the
   authenticity and usability of Certificates within Mobile IP.

   This process assumes that the receiver knows the public key of the
   Sender's CA. The receiver can develop trust in the public key of the
   Sender's CA recursively, if the receiver has a Certificate containing
   the CA's public key signed by a superior CA whom the receiver already
   trusts. In this sense, a certificate is a stepping stone in digital
   trust. Each certificate is processed in turn, starting with that
   signed using the input trusted public key.

   The following checks are applied to all Certificates:
   -   Check that the signature verifies
   -   That dates are valid
   -   The subject and issuer names chain correctly
   -   The certificate has not been revoked.
   If any of the above checks fails, the procedure terminates, returning
   a failure indication. If none of the above checks fail on each
   Certificate, the procedure terminates successfully.

6.      Certificate Revocation Lists

   Each digital certificate should be checked against the current
   Certificate Revocation List (CRL) from the issuing CA to ensure that
   revoked Certificate are not employed. PKA Mobile IP recognizes that
   network performance could be seriously degraded if a receiving node
   always retrieves the most recent CRL when ever a new Certificate is
   received. Consequently, a node (be it an MN, FA or HA) should cache
   received Certificates along with a value ("staleness value") that
   indicates the last time each Certificate was checked against a CRL
   from the issuing CA. The node should also provide a value that
   indicates the maximum degree ("staleness threshold") of Certificate

Expires March 1, 1999                                          [Page 24]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

   staleness a given node may tolerate before the node has to retrieve
   the appropriate CRL and verify that the Certificate has not been
   revoked.

   This staleness checking function is a compromise between the effect
   on available bandwidth vs. the risk of using a revoked Certificate.
   In those cases where the node has high network bandwidth available
   (usually FAs and HAs), via wired network attachments, then the
   staleness threshold should be set to a relatively low value (eg. 10
   seconds). Where the node has less than good network bandwidth
   available (usually MNs) via wireless network attachments then the
   staleness threshold should be set to a higher value (eg. 10 minutes).









































Expires March 1, 1999                                          [Page 25]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998

7.      Security Considerations

   Those implementations of Mobile IP which do not include
   authentication Between the MN and the FA run the risk of denial of
   service attacks. MIPv4 relies on the use of the Address Resolution
   Protocol (ARP), which does not provide any authentication, for
   intercepting packets destined for a traveling MN. Any wireless Home
   network is consequently vulnerable to MN traffic stealing by having a
   hostile node on the wireless network issue ARP messages which cause
   these packets to be sent to a destination other than an MN, when at
   home, or the MN's HA when the MN is on the road. Ideally the ARP
   protocol should include authentication but this would require
   significant changes to the currently deployed protocol.

   Staleness of Certificates and frequency for Certification Revocation
   List retrieval is a trade-off between exposure and potential
   threat resulting in a degree of risk from a revoked Certificate. By
   having implementations of PKA Mobile IP provide a user tunable
   staleness threshold the degree of risk becomes a user managed
   function.

A.      Patent Issues

   As of the time of publication, there exists a patent that is
   relevant to implementers of the Protocol extensions described
   herein:

A.1. Massachusetts Institute of Technology Patent #4405829

   Ronald L. Rivest, Adi Shamir, Leonard M. Adleman are the
   co-inventors of U.S. Patent No. 4405829, assigned to the
   Massachusetts Institute of Technology (MIT). The patent was filed
   December 14, 1977 and will expire on December 15, 1999, at which
   time the technology covered by the patent reverts to the public
   domain.

   Furthermore the US Government has rights to this technology pursuant
   to Contract No. N00014-67-A-0204, awarded to the Department of the
   Navy, and Grant No. MCS76-14249, awarded by the National Science
   Foundation.

   Should implementers wish to immediately proceed with implementing
   commercial versions of PKA Mobile IP they may obtain a license from
   RSA Data Securities Inc. for use of the RSA asymmetric public key
   algorithm.

   This statement is for the IETF's assistance in its standard-setting
   procedure, and should not be relied upon by any party as an opinion
   or guarantee that any implementation it might make or use would not
   be covered by the MIT Patent and any other patents.



Expires March 1, 1999                                          [Page 26]


Internet Draft  Mobile IP Public Key Based Authentication August 1, 1998


References

   [Diffie76] Diffie, W., Hellman, M. E., "New directions in
              cryptography", IEEE Transactions on Information Theory,
              IT-22(6):644--654, November 1976.

   [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm",
             April 1992.

   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992.

   [RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic
             Mail: Part II: Certificate-Based Key Management",
             February 1993

   [RFC1541] Droms, R., "Dynamic Host Configuration Protocol",
             October 1993

   [RFC2002] Perkins, C., editor, "IP mobility support", October 1996.

   [RSA78] Rivest, R.L., Shamir, A., Adleman, L., "A method for
           obtaining digital signatures and public-key cryptosystems",
           Communications of the ACM, 21(2):120-126, February 1978.

   [Schneier96] Schneier, B., "Applied Cryptography 2nd Edition",
                Chapter 22 pp. 513-514, John Wiley & Sons Inc., 1996

   [X.500] "CCITT. Recommendation X.500: The Directory-Overview of
           Concepts, Models and Services", 1988

   [X.509] "CCITT. Recommendation X.509: The Directory-Authentication
           Framework", 1988.

Authors' Address

     Questions about this memo can also be directed to:

      Stuart Jacobs
      Network Security Department
      GTE Laboratories,
      40 Sylvan Road,
      Waltham, MA 02454, USA.
      Phone: 781-466-3076
      Fax: 781-466-2838
      Email: sjacobs@gte.com







Expires March 1, 1999                                          [Page 27]