Wireless Networks 5 (1999) 373–390
`
`373
`
`A public-key based secure Mobile IP ∗
`
`John Zao a, Stephen Kent a, Joshua Gahm b, Gregory Troxel b, Matthew Condell b, Pam Helinek a,
`Nina Yuan c and Isidro Castineyra b
`a Network Security Department, GTE Internetworking/BBN Technologies Inc., Cambridge, MA, USA
`b Advanced Networking Department, GTE Internetworking/BBN Technologies Inc., Cambridge, MA, USA
`c Ernst & Young LLP, Boston, MA, USA
`
`In this
`The need of scaleable key management support for Mobile IP, especially the route-optimized Mobile IP, is well known.
`paper, we present the design and the implementation of a public key management system that can be used with IETF basic and route
`optimized Mobile IP. The system, known as the Mobile IP Security (MoIPS) system, was built upon a DNS based X.509 Public Key
`Infrastructure and the innovation in cross certification and zero-message key generation. The system can supply cryptographic keys for
`authenticating Mobile IPv.4 location management messages and establishing IPSec tunnels for Mobile IP redirected packets. It can also
`be used to augment firewall traversal of Mobile IP datagrams. A FreeBSD UNIX implementation of the MoIPS prototype is available
`for non-commercial uses.
`
`1. Introduction
`
`1.1. Review of Mobile IP protocols
`
`Mobile IP or IP mobility support [23] (abbreviated as
`MIP) is a protocol for passing IP datagrams between a
`Mobile Node (MN) and its Corresponding Nodes (CNs) as
`the Mobile Node changes it attachment point on the global
`Internet. The protocol employs network layer agents to
`capture IP datagrams that are destined to the Mobile Node’s
`permanent IP address in its home network and redirect these
`datagrams using IP–IP encapsulation [24] to a temporary
`IP address, called the care-of IP address (COA), that is
`assigned to the Mobile Node while it is visiting a foreign
`network. The agents in the home network are known as the
`Home Agents (HAs) and the ones in the foreign network
`are known as the Foreign Agents (FAs). Together, these
`Mobility Agents track the movement of Mobile Nodes by
`exchanging registration messages among themselves and
`the Mobile Nodes. Based on this registration process, a
`Home Agent may keep track of the locations of the Mobile
`Nodes under its administration. It also serves as the entry
`point to the IP–IP tunnels that redirect IP datagrams to
`the Mobile Nodes away from home. The Foreign Agents,
`however, may or may not be the exit points of these tunnels
`depending on the nature of care-of addresses. If the care-of
`address of a Mobile Node is the IP address of a network
`interface on a Foreign Agent then the care-of address is
`called a Foreign Agent care-of address and the Foreign
`Agent is a tunnel end-point. On the other hand, if the care-
`of address is an address assigned temporarily to a Mobile
`Node by DHCP or PPP then the address is called a co-
`located care-of address while the Foreign Agent serves only
`∗ This work reported in this paper was sponsored by Defense Advanced
`Research Project Agency (DARPA) and Air Force Material Command
`(AFMC) of the Department of Defense under contract number F19628-
`95-C-0150.
`
`© J.C. Baltzer AG, Science Publishers
`
`In addition
`as a last-hop router and a registration agent.
`to these basic Mobile IP tunnels, reverse tunnels may be
`established during the registration process from the Mobile
`Node care-of address to the Home Agent [21] (again using
`IP–IP encapsulation) to pass IP datagrams from the Mobile
`Nodes through the firewalls protecting the foreign network.
`A more sophisticated version of Mobile IP, called route-
`optimized Mobile IP [14], was also proposed to the IETF
`Mobile IP working group. In that protocol, additional mes-
`sages known as location binding requests and updates may
`be exchanged between a Mobile Node and its mobility
`aware Corresponding Nodes to inform them of the current
`care-of-address of the Mobile Node. Similarly, the binding
`update messages may be dispatched to the Foreign Agents
`visited by the Mobile Node to pass the information. With
`the knowledge of Mobile Node’s current care-of address,
`the Corresponding Nodes and the previous Foreign Agents
`may tunnel the IP datagrams destined to the Mobile Node
`to its current whereabout. These additional tunnels can
`shorten the transit time of redirected datagrams and thus
`reduce the number of datagrams dropped due to delivery
`failure. As a result, they will improve the performance of
`Mobile IP, especially if it is used to support a connection-
`oriented protocol such as TCP.
`Figure 1 shows the message flow of both basic and route-
`optimized Mobile IP.
`
`1.2. Security requirements of Mobile IP
`
`While Mobile IP promises uninterrupted IP connectiv-
`ity for the Mobile Nodes roaming over the Internet, it also
`increases the risk of causing remote redirection of Internet
`traffic [4] by introducing bogus registration and binding up-
`date messages. Besides, the attachment of a Mobile Node
`to a foreign network may cause security concerns to both
`its home network and the visiting network as the Mobile
`Node, which is not configured and managed by local net-
`
`Ex. 1010
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`

`

`374
`
`J. Zao et al. / A public-key based secure Mobile IP
`
`Figure 1. Message flow in Mobile IP protocols.
`
`work administration, may inject and intercept packets in the
`visiting network, and the home network must receive and
`process the packets apparently from the Mobile Node as if
`they are generated by a local node. Consequently, the entire
`mobile internet, including the Mobile Nodes, the Mobility
`Agents (Home and Foreign) and the networks accommodat-
`ing these nodes, must be protected by appropriate security
`measures.
`The ultimate goal of Mobile IP security is to fulfill two
`general expectations: (1) to allow a Mobile Node to enjoy
`similar internet connectivity and safety when it visits a for-
`eign network as it resides in its home network, and (2) to
`protect both the home and the foreign networks from pas-
`sive and active attacks when the Mobile Node is visiting the
`foreign network. Throughout the development of Mobile
`IP, the following security services have been considered for
`providing the necessary security measures:
`• data integrity, data origin authentication and anti-replay
`protection of Mobile IP registration and location update
`messages,
`• access control of the Mobile Nodes when they use re-
`sources on the visiting networks,
`• data integrity, data origin authentication and data con-
`fidentiality protection of IP packet redirecting tunnels,
`• location privacy of the Mobile Nodes, and
`• anonymity of the Mobile Nodes.
`
`Among these services, the first three are essential to
`the secure operation of Mobile IP. The Mobile IP Security
`
`(MoIPS) system discussed in this paper was developed to
`support these services.
`
`1.3. Organization of the paper
`
`In the remaining six sections of this paper, we will dis-
`cuss the design and implementation of the MoIPS system.
`Section 2 offers a system overview which explains our ap-
`proach to provide the three security services (section 2.1)
`and describes the public-key based MoIPS architecture.
`Sections 3–5 cover the three components of the system:
`the DNS-based X.509 public key infrastructure (PKI) in
`section 3, a lightweight key management scheme for Mo-
`bile IP control message authentication in section 4, and the
`IPSec protection of Mobile IP packet redirecting tunnels in
`section 5. The implementation of the first MoIPS prototype
`will be briefly described in section 6 before the conclusions
`are given in section 7.
`
`2. MoIPS system overview
`
`2.1. Design objectives
`
`The MoIPS system was developed to support three secu-
`rity services that are essential to the safe operation of Mo-
`bile IP: (1) authentication of Mobile IP control messages
`for location update, (2) access control of Mobile Nodes to
`resources in the foreign networks, and (3) secure tunneling
`of redirected IP datagrams. In this section, we examine the
`requirements of these services and explain our approach to
`provide them.
`
`

`

`J. Zao et al. / A public-key based secure Mobile IP
`
`375
`
`2.1.1. Authentication of location updates
`Among the Mobile IP messages shown in figure 1, the
`registration messages in Basic Mobile IP and the location
`binding update messages in the Route-Optimized Mobile
`IP (all displayed in bold italics) carry the location bind-
`ings of Mobile Nodes. These are the associations between
`the permanent addresses and the current care-of-addresses
`of the Mobile Nodes. By altering the location bindings in
`these control messages, creating bogus messages, or replay-
`ing pre-recorded messages, an adversary could redirect IP
`traffic for one node to another node.
`In order to frustrate the remote traffic redirection attack
`mentioned above, registration and binding update messages
`must be protected with data integrity, origin authentication
`and anti-replay services. Each of these messages hence in-
`cludes a 64-bit identification tag for detecting replays and
`one or more authentication extensions to provide message
`integrity and strong authentication using a hashed message
`authentication code (HMAC) [16,17]. Although the HMAC
`codes and the anti-replay tags are appropriate means to
`provide integrity, authentication and anti-replay services,
`the current Mobile IP lacks a scaleable key management
`scheme for dispatching cryptographic keys needed to sup-
`port these services. In order to protect the registration mes-
`sages, keys must be shared at least among Mobile Nodes
`and their Home Agents. In order to protect the binding up-
`date messages in the route-optimized Mobile IP, keys must
`be dispatched among MN-FA, FA-HA and MN-CN pairs.
`
`2.1.2. Access control of Mobile Nodes
`For the purposes of network protection, accounting
`and resource management, it is desirable that the Foreign
`Agents (in cooperation with the Home Agents) can verify
`the identity of a Mobile Node before allowing it to com-
`plete the Mobile IP registration and establish an attachment
`point on the visiting networks. The access control proce-
`dure should be conducted in two steps: (1) verifying the
`identity of the Mobile Node, and (2) checking the current
`status of the Mobile Node with a relevant authority such as
`the corresponding Home Agent.
`In MoIPS, both the end nodes (Mobile Nodes and Corre-
`sponding Nodes) and the Mobility Agents (Foreign Agents
`and Home Agents) possess X.509 public key certificates is-
`sued by hierarchies of certification authorities (CAs). The
`certificates contain information about identity and network
`affiliation of these entities as well as the public key para-
`meters necessary for key generation. By exchanging these
`certificates and challenge-response messages, the end hosts
`can identify themselves to the Mobility Agents and to one
`another.
`The checking of Mobile Node status, on the other hand,
`can be conducted implicitly by exchanging authenticated
`registration requests and replies. By forwarding a registra-
`tion request to a Home Agent, a Foreign Agent indicates
`that the Mobile Node has successfully passed its scrutiny.
`By returning a registration reply, the Home Agent informs
`the Foreign Agent of its approval or rejection of the regis-
`
`tration based on the factors such as Foreign Agent identity
`and affiliation, Mobile Node status, and Home Agent mo-
`bility control policy.
`
`2.1.3. Secure tunneling of redirected IP packets
`The traffic to/from a Mobile Node, while it is away from
`its home network, must travel through the visiting network
`and the public Internet before reaching the destination. Of-
`ten, the traffic may pass through wireless or other insecure
`communication media. This form of communication in-
`creases significantly the risks of passive eavesdropping and
`active attacks including packet alteration, insertion or dele-
`tion of Mobile IP data traffic. Consequently, the Mobile
`Node and the Mobility Agents should protect the data traf-
`fic with integrity, origin authentication and possibly confi-
`dentiality.
`In order for the home network to endow the same level
`of trust and hence provide the same amount of connectivity
`to a Mobile Node when it roams among foreign networks,
`the home network will require the traffic to be securely tun-
`neled to/from the Mobile Node (or a trusted agent such as
`the Foreign Agent connected to the Mobile Node). Sim-
`ilarly, in order for the foreign network to pass traffic for
`the Mobile Node, the Foreign Agents will require the traf-
`fic to be tunneled by an authenticated and trusted Home
`Agent that manages the Mobile Node. The secure tun-
`nels can be implemented using the Encapsulating Security
`Payload (ESP), tunneling mode of IP security protocols
`(IPSec). The protocol will transform each original IP data-
`gram with authentication and encryption mechanisms nego-
`tiated by the communicating parties and then encapsulate
`the datagram within an IPSec header and an external IP
`header, which specifies the end points of the IPSec tunnel.
`The MoIPS system provides the service by incorporating an
`IPSec and an ISAKMP [18] module into the system. Coor-
`dinating with the Mobile IP module, these modules impose
`IPSec protection to selected Mobile IP packet redirection
`tunnels.
`
`2.2. System architecture
`
`The three security services discussed in the previous sec-
`tion demand the following three kinds of security support:
`1. A scaleable key management infrastructure capable of
`generating or dispatching long-term key parameters
`among any pairs of network nodes – without this in-
`frastructure, route-optimized Mobile IP cannot send au-
`thenticated binding updates to Corresponding Nodes
`and establish secure tunnels between MN-CN and FA-
`HA pairs.
`2. A light-weight key generation algorithm for supplying
`the short-term keys needed for authenticating the Mo-
`bile IP registration and binding update messages – be-
`cause Mobile Nodes can only obtain network connec-
`tivity after successfully completing Mobile IP registra-
`tion, it is essential to have a key generation algorithm
`
`

`

`376
`
`J. Zao et al. / A public-key based secure Mobile IP
`
`Figure 2. MoIPS system block diagram.
`
`that can supply authentication keys without additional
`message exchange.
`3. Interaction between Mobile IP and IPSec protocols to
`enable IPSec protection of selected packet redirection
`tunnels and ISAKMP negotiation for necessary security
`associations with minimal disruption of Mobile Node
`handoffs.
`We decided to use public key technology to meet the key
`management requirements of MoIPS. More specifically, we
`chose to develop a public key infrastructure (PKI) for man-
`aging X.509 v.3 public key certificates and v.2 certificate
`revocation lists (CRLs) [11] issued to Internet nodes (in-
`stead of human subjects). We also chose to use the Internet
`domain name system (DNS) [20] as the certificate repos-
`itory. The main reason to use the PKI technology was
`scalability: in order to support global internet mobility, we
`must have a technology that can establish shared secrets
`among a large set of nodes spread across multiple Internet
`domains. A DNS-based PKI has clear advantage over a
`distributed system of key distribution centers (KDCs), such
`as a multi-realm Kerberos system for the use of DNS solves
`the potentially complicated server discovery problem, and
`the use of public key certificates eliminates the need for
`real-time key dispatches by the KDCs.
`Figure 2 shows the functional structure of MoIPS. The
`Mobile IP and the IPSec modules share their use of a key
`management module and a cryptographic engine. The key
`management module generates the short-term keys neces-
`sary for the security services while the crypto-engine per-
`forms the actual cryptographic processing. Keys and other
`security parameters are kept in a protected database and
`passed only to the crypto-engine. Users of security service
`such as Mobile IP or IPSec make use of security parame-
`ter indices (SPIs) to refer to the different security settings.
`The key management module derives the short-term keys
`from the long-term public keys obtained from the X.509
`PKI. In order to obtain the public keys, an X.509 certifi-
`cate verifier was developed to fetch certificates and CRLs
`
`via regular DNS lookup and/or receive them through direct
`exchanges using the certificate discovery protocol (CDP)
`[3]. The verifier then checks the signatures on the certifi-
`cates by following the trust relations existing among the
`hierarchies of certification authorities. The verifier also
`maintains a cache of verified certificates and CRLs in order
`to minimize the number of certificate fetch and verification
`operations.
`Wherever feasible, MoIPS makes use of emerging
`standard cryptographic application programming interfaces
`(CAPIs) to connect different modules. For example, it uses
`RSA CryptoKi CAPI as the interface between the users of
`security service and the crypto-engine; this interface en-
`ables MoIPS to use both the RSAREF crypto-library and
`the Fortezza crypto-token to perform the cryptographic op-
`erations. MoIPS also uses PF Key CAPI to support short-
`term key and security association management. PF Key is
`the standard key management interface between IPSec and
`ISAKMP in the UNIX environment. Due to the absence of
`a standard certificate management API, MoIPS developed
`its own simple interface (known as Cert API) to connect
`the certificate verifier with the key management module.
`
`3. DNS X.509 public key infrastructure
`
`We begin our study of MoIPS by examining the public
`key infrastructure (PKI) that issues certificates to Mobile
`IP nodes (Mobile Nodes and mobility-aware Corresponding
`Nodes), and Mobility Agents (Home Agents and Foreign
`Agents) and also publishes the certificate revocation lists
`(CRLs) to announce the invalid certificates.
`In this sec-
`tion, we shall explain our decision of developing a DNS-
`based X.509 PKI, answer the questions: “who should have
`a MoIPS certificate” and “what should be the proper sub-
`ject names”, and then highlight the important fields in the
`certificate and CRL profiles.
`
`

`

`J. Zao et al. / A public-key based secure Mobile IP
`
`377
`
`3.1. Reasons for developing a DNS X.509 PKI
`
`We made two conscious decisions during the PKI devel-
`opment:
`1. We adopted the X.509 v.3 profiles for the certificates
`and v.2 profiles for the CRLs.
`2. We used the Internet Domain Name System (DNS) as
`the primary mechanism for dispatching the certificates
`and the CRLs, and only supplemented it occasion-
`ally with direct certificate and CRL exchanges between
`communicating entities.
`Following are the tradeoffs we considered before making
`the decisions.
`
`Advantages of using X.509 certificates and CRLs
`There are two reasons to use X.509 PKI to support
`MoIPS: (1) its hierarchical trust relations among the cer-
`tification authorities (CAs) can be mapped onto the domain
`based topology of Mobile IP networks; this makes it a more
`scaleable and desirable choice than the PGP certificate in-
`frastructure [8]; (2) the X.509 v.3 certificates and v.2 CRLs
`include many extension fields that can be used to carry in-
`formation relevant to the use of key parameters, the trust
`relations among the CAs and the management of certifi-
`cates and CRLs. In particular, following fields enable us to
`add valuable features to the PKI:
`• IssuerAltName enables the establishment of a CA hier-
`archy independent of the DNS zone structure and thus
`allows the Mobility Agents and the CAs to be sepa-
`rated from DNS zone servers. In contrast, DNSSec uses
`the zone servers as the CAs and thus imposes a direct
`mapping of the DNS hierarchy onto the mobile network
`topology. In addition, we can use BasicConstraint and
`NameConstraint to limit the scope of authority of the
`CAs in issuing certificates.
`• CertificatePolicy allows policy information to be in-
`cluded in certificates and thus be used to conduct access
`control on the Mobile Nodes.
`• KeyUsage allows CAs to specify the intended use of
`key parameters while AuthorityKeyID and SubjectKeyID
`allow multiple CA signature keys to be distinguished
`from one another when they are used simultaneously
`during key rollovers. These extensions help to enforce
`correct use of the public keys.
`• By assigning status, required/optional and critical/non-
`critical, to each certificate and CRL extension, X.509
`PKI allows its CAs to issue different kinds of public
`key certificates with different profiles; for example, the
`certificates used for Mobile IP control message authen-
`tication can be different from those used for IPSec pro-
`tection.
`
`Advantages of using Domain Name System
`The ubiquitous use of DNS over the Internet moti-
`vated MoIPS to use it as the certificate/CRL dispatch sys-
`
`tem. The choice can be justified by the following reasons:
`(1) MoIPS uses certificates issued to network nodes, all of
`which should have corresponding entries in the DNS sys-
`tem, (2) the subjects are identified by domain names and/or
`IP addresses, that are information maintained by DNS, and
`(3) DNS lookups are often necessary for establishing an
`end-to-end communication, and thus the certificate fetches
`can be piggybacked easily onto the regular DNS transac-
`tions.
`
`Costs of using a DNS-based X.509 PKI
`The use of PKI always entails certain amount of over-
`head. Our consideration was whether the overhead can be
`justified when we compare the advantages of using X.509
`PKI with those of competing technologies, particularly the
`Kerberos key distribution centers (KDCs) and the DNSSec
`public key records.
`As mentioned in section 2.2, the advantages of X.509
`PKI over Kerberos KDC are obvious. The deployment
`of KDCs in multiple network domains (as in the case of
`multi-realm Kerberos system) is complicated by the server
`discovery problem – a node which intends to communicate
`with another node in a foreign domain/realm must have
`a universal mechanism to locate the KDC that serves the
`foreign domain – besides, the on-line operation of the KDCs
`are more time-critical and less scaleable than the off-line
`operation of the CAs.
`When comparing X.509 certificates with DNSSec key
`records, it is worth noting that although the X.509 certifi-
`cates are larger than the KEY and the SIG records, the cer-
`tificates carry a lot of valuable information including that
`which aids Mobile IP access control. Note that the retrieval
`of KEY and SIG records (like the certificate records) is of-
`ten conducted in TCP instead of UDP; hence, the effects
`of different record sizes are reduced. Furthermore, the use
`of CRLs allows the CAs to issue certificates with long va-
`lidity periods (which may span several months) and short
`revocation intervals (which can last less than an hour). In
`comparison, DNSSec only allows the resource records to
`be updated daily at fixed time. Obviously, the PKI per-
`forms much better in terms of state update and workload
`amortization. These performance advantages along with
`the complete independence between the CAs and the zone
`servers justified the insertion of certificate records into DNS
`entries.
`
`3.2. Certificate entitlement and policies
`
`All Mobile Nodes, mobility-aware Corresponding
`Nodes, Home Agents and Foreign Agents that intend to
`participate in MoIPS must possess X.509 v.3 certificates
`with the profile specified in section 3.4. These certificates
`are known as the MoIPS certificates, and they perform the
`following two functions:
`1. They supply the Diffie–Helman (DH) public values that
`are used to generate cryptographic keys for authenti-
`
`

`

`378
`
`J. Zao et al. / A public-key based secure Mobile IP
`
`cating the Mobile IP control messages and protecting
`packet redirection tunnels using IPSec protocols.
`
`2. They optionally supply information, including the func-
`tional types and the network affiliations of Mobile
`Nodes and Mobility Agents, which can be used to en-
`force access control on the Mobile Nodes as they attach
`themselves onto foreign networks.
`
`The certificates are issued by multiple hierarchies of cer-
`tification authorities (CAs) (section 3.6) that enforce the
`MoIPS security policies. The CertificatePolicy extension in
`these certificates specifies both the functional types and the
`network affiliations according to the following rules:
`• The MoIPS certificates issued to the Mobile Nodes and
`the mobility aware Corresponding Nodes must specify
`the host type, MN/CN, and the DNS domains that the
`nodes are affiliated with. The information may be used
`to exercise rule-based access control policies. A node
`can be marked as both MN and CN since it may allow
`to play the two roles simultaneously.
`• The MoIPS certificates issued to the Mobility Agents
`must specify the agent type, HA/FA, and either the DNS
`domains or the subnets in CIDR notation that the agents
`are serving. Again, the information may be used to
`aid access control. An agent can be marked as both a
`Foreign Agent and a Home Agent if it can provide both
`services to the corresponding groups of Mobile Nodes.
`• A Mobile Node that uses DHCP to obtain a temporary
`IP address should have a MoIPS certificate marking it
`as both MN and FA. However, the FA entry in the Certifi-
`catePolicy extension must restrict the node to serve only
`itself.
`• A mobile router should have a MoIPS certificate mark-
`ing it as both MN and HA. The HA role, however, must
`be restricted to serve only the mobile subnet reachable
`by the router.
`• The minimum security requirements of basic Mobile IP
`– to authenticate the registration exchanges between the
`Mobile Nodes and their Home Agents – can be met by
`issuing MoIPS certificates to those nodes or by estab-
`lishing shared secrets among them manually. By issu-
`ing certificates to the Foreign Agents, MoIPS enables
`authenticated registration exchanges among the Mobile
`Nodes, their Home Agents and their visiting Foreign
`Agents. The Corresponding Nodes only need to have
`MoIPS certificates if they intend to participate in secure
`route-optimized Mobile IP.
`
`The MoIPS system mandates the use of MoIPS certifi-
`cates with CertificatePolicy extension for protecting Mobile
`IP registration and conducting Mobile Node access control.
`Nevertheless, it allows the use of other X.509 certificates,
`that are issued for key encipherment, key agreement and/or
`authentication services (especially those to be used with
`IPSec protocols) to support secure packet redirection.
`
`3.3. Subject names
`
`There are two possible choices for the subject name of
`an Internet node:
`1. the IP address of the Internet node/interface, and
`2. the canonical domain name of the node, which is an
`unambiguous pointer to its DNS entry and the consis-
`tent result of reverse DNS lookups given any of the IP
`address(es) of the node.
`The two choices beg for a tradeoff in MoIPS, and their
`preferences differ slightly depending whether the subject is
`an Mobile IP node or a certification authority.
`For the Mobile Nodes, the Corresponding Nodes, the
`Foreign Agents and the Home Agents, the subject names in
`their MoIPS certificates must be their IP addresses because
`Mobile IP protocol uses IP addresses to identify the Mobile
`IP supporting entities. The use of IP addresses has two
`other advantages:
`1. It permits issuing of MoIPS certificates to interfaces
`rather than nodes on the Internet. This allows a multi-
`home node to have a certificate issued to each of its
`network interfaces as it functions as a Foreign/Home
`Agents on different interfaces. The configuration is
`particularly useful when the agent serves multiple sub-
`nets or functions as a firewall.
`2. It simplifies the verification of NameConstraint as the
`lowest level CAs may own blocks of IP addresses and
`issue MoIPS certificates only to the Mobile IP support-
`ing entities with their IP addresses falling within those
`address ranges.
`Nevertheless, the use of IP addresses has two disadvan-
`tages:
`1. IP addresses tend to have relatively short lifetimes;
`hence, a certificate must be re-issued whenever there is
`a change of the IP address of its subject, and a single
`DNS entry may contain multiple certificates that are
`issued to different network interfaces to the node.
`2. IP addresses do not refer to DNS entries directly; con-
`sequently, a reverse domain name look-up is needed to
`convert an IP address to a domain name before search-
`ing DNS for a MoIPS certificate.
`For the certificate authorities (CAs), their canonical do-
`main names should be the preferred subject names because
`the use of domain names eliminates the need for reverse
`DNS lookups. The only disadvantage of using domain
`names for the CAs and the IP addresses for the Mobile
`IP nodes is the use of a heterogeneous naming scheme into
`the PKI and hence a slight complication of the certificate
`verification process. It is possible to insert multiple Sub-
`jectAltName extensions into a certificate for the purpose of
`binding both IP address(es) and domain name to the subject.
`This practice is, however, discouraged in MoIPS because it
`further complicates certificate verification.
`
`

`

`J. Zao et al. / A public-key based secure Mobile IP
`
`379
`
`Table 1
`Profile of MoIPS certificates.
`Values and remarks
`
`Fields
`
`Version
`SerialNumber
`SignatureAlgorithm
`IssuerName
`Validity
`SubjectName
`SubjectPublicKeyInfo
`
`Status
`
`required
`required
`required
`required
`required
`required
`required
`
`AuthorityKeyID
`SubjectKeyID
`KeyUsage
`
`CertificatePolicy
`PolicyMap
`SubjectAltName
`
`IssuerAltName
`BasicConstraint
`
`optional/non-critical
`optional/non-critical (CA only)
`required/critical
`
`optional/critical
`not used
`required/critical
`
`required/critical
`required/critical
`
`NameConstraint
`PolicyConstraint
`CRLDistributionPoint
`ExtendKeyUsage
`AuthorityInfoAccess
`
`required/critical (CA only)
`not used
`optional/non-critical
`optional/non-critical
`not used
`
`= 2 (X.509 v3 Cert)
`unique number per CA
`= RSA signature with SHA-1 hash (default)
`= NULL
`certificate valid period
`= NULL
`DH public value (1024 bit) for end nodes
`RSA public key (1024 bit) for CAs
`SHA-1 hash of CA public key
`SHA-1 hash of subject public key
`= 0 × 10 (keyAgreement) for end nodes
`= 0 × 60 (keyCertSign + cRLSign) for CAs
`policy user notice
`
`IPv4 address for end nodes
`canonical domain name for CAs
`canonical domain name of CA
`flag cA = end nodes / CAs
`pathLenConstraint = max. certificate levels
`ranges of IP addresses owned by CA
`
`canonical domain name of distribution point
`= ipsecEndSys + ipsecTunnel + mobileipAuthen
`
`3.4. MoIPS certificate profile
`
`The MoIPS certificates adopt IETF-PKIX X.509 v.3 for-
`mat as specified in [11]. The certificates must be in v.3
`format in order to accommodate extension fields that carry
`additional information. As suggested by the PKIX stan-
`dard, the fields IssuerUniqueIdentifier, SubjectUniqueIdenti-
`fier, PrivateKeyUsagePeriod and SubjectDirectoryAttributes
`are omitted from the certificates.
`Table 1 presents a
`summary of the basic and the extension fields of MoIPS
`certificates along with their status, required/optional and
`critical/non-critical.
`In this and the next sections, we re-
`view selected fields in the MoIPS certificates and CRLs by
`collecting them into functional groups and commenting on
`their intended usage.
`
`3.4.1. Basic fields
`Version. The field must have the value two (2) to indicate
`that the certificate is in X.509 v.3 format.
`
`Serial Number. This field contains a unique unsigned in-
`teger assigned by the issuing CA. The number combined
`with issuerAltName should uniquely identify the certificate.
`
`Signature Algorithm. The MoIPS system chose to sign
`their certificates with SHA-1 one-way hash function and
`RSA encryption algorithm as defined by the OSI Interop-
`erability Workshop. Extra bits can be added as padding
`according to PKCS#1, section 8.1. The SignatureAlgo-
`rithm field specifies the digital signature algorithm1 used
`
`1 The actual value of the digital signature is contained as a bit string in the
`Signature field appended to the certificate along with the same signature
`algorithm identifier.
`
`to sign the certificate.
`NULL.
`
`Its parameter component is set to
`
`Validity. The field has two components, notBefore and
`notAfter components, which specify the beginning and the
`end time of the certificate validity period, respectively. The
`time may be encoded in UTCTime or GeneralizedTime, but
`must be Y2K complaint.
`
`3.4.2. Names and Name Constraints
`Like other PKIX certificates, the MoIPS certificates use
`SubjectName and SubjectAltName, IssuerName and Issuer-
`AltName to identify the certificate subjects and the issuing
`CAs. The CA certificates also use NameConstraint to spec-
`ify the name space owned by the CAs.
`
`SubjectName and SubjectAltName. The subject or princi-
`pal of a certificate is identified by its SubjectName field
`and SubjectAltName extension. SubjectName must contain
`either an X.500 distinguished name or a NULL value. In
`order to use IP address or domain name as a subject name,
`we must set SubjectName to NULL and place the chosen
`name in SubjectAltName extension.
`
`IssuerName and IssuerAltName. The CA that issues the
`certificate is identified by the IssuerName field and