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 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]