INTERNET DRAFT S. Jacobs Category: Standards Track GTE Laboratories Title: draft-jacobs-mobileip-pki-auth-02.txt March 1999 Mobile IP Public Key Based Authentication 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 and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Many uses are surfacing for Mobile IP. Researchers are establishing test beds. Businesses are looking to use Mobile IP in office and warehouse situations. Mobile IP has been incorporated into the CDMA digital cellular standards as Service Option 7. The military is interested in Mobile IP for tactical communications. These varied uses have differing needs for security and authentication. This document proposes an extension to the Mobile IP base protocol 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 in addition to secret key authentication. The use of these mechanisms will allow Mobile IP to scale from small research environments to potentially millions of mobile nodes across thousands of networks owned-operated by different organizations and service providers. Jacobs Expires September 1999 [Page i]
INTERNET DRAFT March 1999 Contents Abstract............................................................... i 1. Introduction................................................... 1 1.1. Mobile Networking Bandwidth and Security Tradeoffs............. 1 1.2. Security Deficiencies of RFC-2002 Mobile IP.................... 2 1.3. Terminology.................................................... 4 1.4. Specification Language......................................... 7 1.5. Security Enhancement........................................... 7 2. Message and Extension Formats.................................. 8 2.1. Mobility Agent Advertisement Extension......................... 8 2.2. Registration Request Message................................... 9 2.3. Registration Reply............................................ 10 2.4. Mobile IP Authentication Extensions........................... 12 2.4.1. Mobile Node Authentication Extension.......................... 12 2.4.2. Foreign Agent Authentication Extension........................ 13 2.4.3. Home Agent Authentication Extension........................... 14 2.4.4 Certificate Extension......................................... 15 3. Protocol Overview............................................. 16 3.1. Agent Discovery with Public key Authentication................ 16 3.2. MN Processing of Agent Advertisements with Public key Authentication............................. 17 3.3. MN Registration Request Generation............................ 18 3.3.1. MN Registration Request Generation and FAs.................... 18 3.3.2. MN Registration Request Generation and DHCP................... 18 3.4. Registration Request Processing by FA......................... 18 3.5. FA Forwarding Registration Requests to HA..................... 19 3.6. Registration Request Authentication verification by HA........ 19 3.6.1. Authentication of FA Forwarded Registration Request by HA..... 19 3.6.2. Authentication of Registration Request by HA in DHCP Mode..... 20 3.7. HA Generation of Registration Reply........................... 21 3.7.1. HA Generation of Registration Reply With FAs Involved......... 21 3.7.2. HA Generation of Registration Reply With DHCP Involved........ 21 3.8. Registration Reply Authentication verification by FA.......... 21 3.9. FA Forwarding Registration Reply to MN........................ 22 3.10. MN Receipt of Registration Reply.............................. 22 3.10.1. MN Receipt of Registration Reply forwarded by FA.............. 22 3.10.2. MN Receipt of Registration Reply Sent Directly from HA........ 22 3.11. FA Generation of Registration Reply........................... 23 3.12. MN Receipt of Registration Reply Generated by FA.............. 23 4. Certificates.................................................. 23 4.1 Self-Signed Certificates...................................... 24 4.2. Certificate Authority Signed Certificates..................... 24 5. Trust Hierarchy Paths......................................... 25 6. Certificate Revocation Lists.................................. 26 7. Security Considerations....................................... 26 A. Patent Issues................................................. 27 A.1. Massachusetts Institute of Technology Patent #4405829......... 27 References............................................................ 27 Authors' Address...................................................... 28 Jacobs Expires September 1999 [Page ii]
INTERNET DRAFT March 1999 1. Introduction 1.1. Mobile Networking Bandwidth and Security Tradeoffs The Mobile IP base protocol [RFC2002] provides a scalable mechanism for node mobility. When examining the various types of Mobile IP deployments being considered, one sees significantly different networking environments. Research test beds are relatively benign environments, provide network bandwidth from a few Kbps to Gbps within a single organization. Office and warehouse networks face a greater level of threats, are typically a mixture of wired and wireless media with bandwidth ranging from Mbps to Gpbs, and may span a number of organizations. Service provider deployments are focused on a wireless environment, face many possible threats, provide bandwidth from 4.8Kbps to a few 100Kbps, interoperability across many organizations, and assure the ability to account and bill for services rendered. Military deployments must contend with very hostile security environments, use a mix of wired and wireless media, contend with available bandwidth from 4.8Kbps to Mbps, and allow personnel from many organizations to interact with a very high level of security. The number and frequency of protocol control messages has a direct impact on a protocol like Mobile IP; especially for frequently roaming nodes. The impact of control message size and control message size frequency have a direct impact on network bandwidth. As available network bandwidth decreases, network control overhead needs to be minimized. Frequent network control messages increased network overhead. Mobile IP deployment environments face different types of threats and associated degrees of risk ranging from very few threats and low risks to many threats and very high risks. A Mobile IP deploying organization faces a trade-off between their expected threats, the degree of risk acceptable and the cost in network security overhead necessary to mitigate risk in a specific threat context. There are a number of Mobile IP control message authentication Methodologies by deployment environment, such as Secret Key, Public Key & Self-signed Certificates, and Public Key & CA signed Certificates. For each authentication method there are both manual and dynamic key distribution approaches. Secret Keys may be distributed manually or dynamically, such as with the Internet Key Exchange (IKE) protocol, LDAP or DNS. Certificates containing Public keys may also be distributed manually or dynamically (via LDAP, DNS, X.500 or some other protocol). Manual key distribution approaches necessitate distributing key information to all nodes prior to deployment yet have no impact on network overhead. Dynamic key distribution approaches eliminate pre-deployment key distribution yet increase network overhead as keys are established/exchanged over the network. As the number of nodes deployed increases, the number of secret keys increases even faster, namely ((#nodes * (#nodes-1))**2)/2 which becomes unworkable quite quickly. With public keys, the number of key Jacobs Expires September 1999 [Page 1]
INTERNET DRAFT March 1999 pairs = #nodes but one must consider certificates and certificate revocation and the network overhead managing certificates. This document proposes an extension to the Mobile IP base protocol that defines how Mobile Nodes (Hosts) and Mobility Agents (both home network and foreign network) may use secret key or public key base authentication via digital signatures. Also covered are: - the use of X.509 digital certificates - digital certificates issued by Certificate Authorities (CAs) - digital certificates issued by the subject of the certificate (self-signed certificates for a PGP-like informal web of trust) - use of either IP address or host name for identifying mobile nodes and mobility agents - digital certificate revocation and verification. This Mobile IP authentication extension, for Secure Scaleable Authentication (SSA), is designed to minimally change the Mobile IP defined in [RFC-2002]. The SSA makes use of a few reserved fields in the existing Mobile IP message definitions. Given the increased functionality of the SSA approach the RFC-2002 authentication extension has been modified to accommodate different authentication types, different sizes of authenticators (digital signatures) and the use of either IP address or host name for identifying mobile nodes and mobility agents. The SSA changes to Mobile IP do not prevent using Mobile IP with DHCP on visited networks (if one is willing to forgo visited network authentication, access control and non-repudiation). The greatest security benefit from SSA is achieved when using Foreign Agents. 1.2 Security Deficiencies of RFC-2002 Mobile IP Mobile IP currently only requires that registration messages between an MN and its HA be authenticated. Registration messages between a Home Agent (HA) and a Foreign Agent (FA), or between an Mobile Node (MN) and an FA, may be optionally authenticated. Many 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 required, 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 Jacobs Expires September 1999 [Page 2]
INTERNET DRAFT March 1999 - 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. The 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. Jacobs Expires September 1999 [Page 3]
INTERNET DRAFT March 1999 USING A FOREIGN AGENT PUBLIC KEY The only real difference between this approach and that of using the 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 [RFC1321] 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. Use of public keys contained in Digital Certificates (Certificates) issued by trusted third parties, in the form of Certificate Authorities (CAs), provides the strongest basis for 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. 1.3. 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 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 Jacobs Expires September 1999 [Page 4]
INTERNET DRAFT March 1999 the Distinguished Name (DN) contained within the Certificate. 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. Mobile Security Association (MSA) A collection of security contexts, between a pair of nodes, which may be applied to Mobile IP control messages exchanged between them. Each context indicates an authentication algorithm and mode. 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 Jacobs Expires September 1999 [Page 5]
INTERNET DRAFT March 1999 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. 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. Security Context A security context between two nodes defines the manner in which these two nodes choose to mutually authentication each other, and indicates an authentication algorithm and mode. Security Parameter Index (SPI) An index, used with Secret Key authentication mechanisms, identifying a security context between a pair of Nodes among the contexts available. Self-Signed Digital Certificate (Self-Signed Certificate) A Digital Certificate, or Certificate, is a Digital Certificate that has been signed by the entity to which the Certificate appies to. This data structure is defined in [X.509] and contains information, such as identify and public key, about an entity where the entity itself has cryptographicly linked the information together using a digital signature. X.509 Digital Certificate An X.509 Digital 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]. X.509 Digital Certification X.509 Digital Certification is the mechanism in which a Jacobs Expires September 1999 [Page 6]
INTERNET DRAFT March 1999 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. 1.4. Specification Language This document uses the terms "MUST", "SHOULD", and "MAY" as defined in RFC-2119, along with the negated forms of those terms. 1.5. Security Enhancement The design goal of the Scaleable Secure Authentication (SSA) model presented herein is to add scaleable strong authentication to Mobile IP. The SSA enabled Mobile IP protocol works exactly the same way as the base protocol except for the mechanism responsible for generating/verifying message authenticators (digital signatures) and the data structures supporting the proposed digital signature based authenticators. The Co-located Care-of Address (COA) mode (sometimes referred to as "pop-up" mode) relies on the use of DHCP [RFC1541] which 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 SSA Mobile IP model does support the Mobile IP "pop-up" mode of operation by using host names in place of IP addresses as the relative name in digital certificates. Each SSA enabled Mobile IP Node SHOULD be able to support multiple authentication options ranging from simple to complex, while also permitting the possibility of no authentication (the default mode). Mobile IP messages between Mobile Nodes and Mobility Agents are authenticated with the SSA Authentication Extension. The SSA Authentication Extension identifies the Authentication type to be used and a Security Context between a pair of Mobile IP Nodes and is fundamental to defining the Mobility Security Association (MSA) between these nodes. The Authentication Extension MAY be followed by a Certificate Extension if the MSA, between the Mobile Nodes utilizes public key based authentication and Certificates. 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 which applies to the sender of a Mobile IP message. There may also be present in the Certificate Extension, Certificates belonging to one of more CAs. When Mobile Nodes share a common CA, the Certificate of the common CA would appear in the Certificate Extension. In the case where the communicating Nodes do not share a common CA then the Certificate Extension may contain multiple CA Jacobs Expires September 1999 [Page 7]
INTERNET DRAFT March 1999 Certificates from which a trust hierarchy path Between the CA of one Node and the CA of the other Node may be established. 2. Message and Extension Formats 2.1. 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| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 16 (Mobility Agent Advertisement) Length Unchanged from base Mobile IP protocol. Sequence Number Unchanged from base Mobile IP protocol. Registration Lifetime Unchanged from base Mobile IP protocol. R bit Unchanged from base Mobile IP protocol. B bit Unchanged from base Mobile IP protocol. H bit Unchanged from base Mobile IP protocol. F bit Unchanged from base Mobile IP protocol. M bit Unchanged from base Mobile IP protocol. G bit Unchanged from base Mobile IP protocol. V bit Unchanged from base Mobile IP protocol. A bit Identifies that authorization is by either secret key (bit not set) or public key (bit set). (Previously reserved in RFC-2002) Jacobs Expires September 1999 [Page 8]
INTERNET DRAFT March 1999 Care-of Address(es) Unchanged from base Mobile IP protocol. Extensions Usage is as follows - Foreign Agent Authentication Extension appended - Certificate Extension appended 2.2. 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 MAY be relayed to the HA by an FA through which the MN is registering. 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|D|M|G|V|A|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 1 (Registration Request) S bit Unchanged from base Mobile IP protocol. B bit Unchanged from base Mobile IP protocol. D bit Unchanged from base Mobile IP protocol. M bit Unchanged from base Mobile IP protocol. G bit Unchanged from base Mobile IP protocol. V bit Unchanged from base Mobile IP protocol. A bit Identifies that authorization is by either secret key (bit not set) or public key (bit set). (Previously reserved in RFC-2002) Jacobs Expires September 1999 [Page 9]
INTERNET DRAFT March 1999 r bit Unchanged from base Mobile IP protocol. 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. Extensions Usage is follows - Mobile Node Authentication Extension which must be included in all Registration Requests sent by an MN. - Foreign Agent 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 authenticated using public key methods. 2.3. Registration Reply A mobility agent (FA or HA) returns a Registration Reply message to an MN which was the source of a Registration Request message. 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 |A| Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 3 (Registration Reply) A bit Identifies that authorization is by either secret key (bit not set) or public key (bit set). (replaces high order bit in RFC-2002 Code field) Jacobs Expires September 1999 [Page 10]
INTERNET DRAFT March 1999 Code A value indicating the result of the Registration Request. Currently defined Code values are shown In Table 2.3 below.(redefined from 8 bits in RFC-2002 to now 7 bits) 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. Extensions Usage is as follows - Home Agent Authentication Extension which must be included in all Registration Replies issued by a HA. - Foreign Agent 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 Requests authenticated using public key methods. Table 2.3 -- Currently defined Code values are 0 = Unchanged from base Mobile IP protocol. 1 = Unchanged from base Mobile IP protocol. 64 = Unchanged from base Mobile IP protocol. 65 = Unchanged from base Mobile IP protocol. 66 = Unchanged from base Mobile IP protocol. 67 = Unchanged from base Mobile IP protocol. 68 = Unchanged from base Mobile IP protocol. 69 = Unchanged from base Mobile IP protocol. 70 = Unchanged from base Mobile IP protocol. 71 = Unchanged from base Mobile IP protocol. 72 = Unchanged from base Mobile IP protocol. 73 = Unchanged from base Mobile IP protocol. 80 = Unchanged from base Mobile IP protocol. 81 = Unchanged from base Mobile IP protocol. 82 = Unchanged from base Mobile IP protocol. 88 = Unchanged from base Mobile IP protocol. 89 = foreign agent failed authentication Jacobs Expires September 1999 [Page 11]
INTERNET DRAFT March 1999 2.4. Mobile IP Authentication Extensions SSA Mobile IP uses Authentication extensions appended to Agent Advertisements, Registration Requests and Registration Reply messages to provide receiving nodes the information to verify the authenticity and integrity of received Mobile IP control messages. 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. Note that the digital signature field itself and the UDP header are NOT included in the computation of the digital signature value. Table 2.4 -- Valid Authentication types. Auth Type | Authentication | Key Length | Digital Signature Value | Algorithm | in bits | Length in bytes -----------|----------------|--------------|------------------ 001 | MD5 | 128 | 16 002 to 009 | User Defined | User Defined | User Defined 011 | RSA | 512 | 64 012 | RSA | 768 | 97 013 | RSA | 1024 | 128 014 | RSA | 2048 | 256 021 | Elliptic Curve | 80 | 10 022 | Elliptic Curve | 120 | 15 023 | Elliptic Curve | 160 | 20 030 | DSA | 512 | 64 Other Authentication types will be defined in the future. When Auth Type = 001 then authentication is performed in a Prefix-Postfix keyed MD5 fashion as specified in RFC-2002. 2.4.1. Mobile Node Authentication Extension Exactly one Mobile Node Authentication Extension must be appended to all Registration Requests. The format of the Mobile Node Authentication Extension is: 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 | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node (MN) Digital Signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jacobs Expires September 1999 [Page 12]
INTERNET DRAFT March 1999 Type 32 (Mobile Node Authentication Extension) Length 4 plus the number of bytes in the digital signature Auth Type When the A bit is set, the SPI must be set to 0 and the Auth Type identifies the public key cryptographic method (algorithm) and key Length used to generate digital signatures. Valid Authentication types are shown in Table 2.4. SPI When the A bit is not set then, the Auth Type must be set to 0 and the Security Parameter Index (SPI) defines the Security Association (SA) used to compute the Digital Signature value by the sender and used by the receiver to check that value. In particular, the SA identifies the secret shared key used with the MD5 message digest algorithm in a prefix-postfix mode of operation in computing the Digital Signature Mobile Node The computed MN Private key based Digital Signature. Digital Signature 2.4.2. Foreign Agent Authentication Extension Exactly one Foreign Agent Authentication Extension must be appended to all Registration Requests being passed from an FA to an HA or Registration Replies sent from an FA to a MN. The format of the Foreign Agent Authentication Extension is: 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 | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent (FA) Digital Signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 33 (Foreign Agent Authentication Extension) Length 4 plus the number of bytes in the digital signature Auth Type When the A bit is set, the SPI must be set to 0 and the Auth Type identifies the public key cryptographic method (algorithm) and key Length used to generate digital signatures. Valid Authentication types are shown in Table 2.4. Jacobs Expires September 1999 [Page 13]
INTERNET DRAFT March 1999 SPI When the A bit is not set then, the Auth Type must be set to 0 and the Security Parameter Index (SPI) defines the Security Association (SA) used to compute the Digital Signature value by the sender and used by the receiver to check that value. In particular, the SA identifies the secret shared key used with the MD5 message digest algorithm in a prefix-postfix mode of operation in computing the Digital Signature. Foreign Agent The computed FA Private key based Digital Signature. Digital Signature 2.4.3. Home Agent Authentication Extension Exactly one Home Agent Authentication Extension must be appended to all Registration Replies being sent from an HA to an MN. The format of the Home Agent Authentication Extension is: 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 | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digital Signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 34 (Home Agent Authentication Extension) Length 4 plus the number of bytes in the digital signature Auth Type When the A bit is set, the SPI must be set to 0 and the Auth Type identifies the public key cryptographic method (algorithm) and key Length used to generate digital signatures. Valid Authentication types are shown in Table 2.4. SPI When the A bit is not set then, the Auth Type must be set to 0 and the Security Parameter Index (SPI) defines the Security Association (SA) used to compute the Digital Signature value by the sender and used by the receiver to check that value. In particular, the SA identifies the secret shared key used with the MD5 message digest algorithm in a prefix-postfix mode of operation in computing the Digital Signature. Jacobs Expires September 1999 [Page 14]
INTERNET DRAFT March 1999 Home Agent The computed HA Private key based Digital Signature. Digital Signature 2.4.4 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional CA-Certificate-Length| Optional CA-Certificate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CA-Certificate, continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | additional <CA_CERT>s as necessary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 10 Identifies this as a Certificate Extension. Ext Length: The length of the Certificate Extension in bytes. set to 6 + value of Sender-Certificate-Length field The value is increased again for each additional certificate in the Extension by 2 plus the value found in each additional CA-Certificate-Length Field. Sender-Certificate-Length: Length in bytes of the X.509 Type 3 formatted Certificate of the message sender. Sender-Certificate: The X.509 Type 3 Formatted Certificate of the message sender which contains the public key of the message sender. CA-Certificate-Length: Length in bytes of the X.509 Type 3 formatted certificate of a Certificate Authority (CA). This field MUST be present if authentication relies on public keys and Certificate Authorities. Jacobs Expires September 1999 [Page 15]
INTERNET DRAFT March 1999 CA-Certificate: The X.509 Type 3 formatted certificate of a CA which contains the public key of the CA used to sign Certificates. This field MUST be present if authentication relies on public keys and Certificate Authorities. 3. Protocol Overview With SSA Mobile IP, a complete registration cycle with FAs consists of: a) the MN receiving a Mobility Agent Advertisement b) the MN sending a Registration Request to the FA c) the FA preprocessing the received Registration Request and, if tentatively approved, passing the Registration Request to the MN's HA d) the HA receiving the Registration from the MN via the FA e) the HA processing the Registration Request and sending a Registration Reply to the FA f) the FA receiving the Registration Reply, updating visiting MN data structures g) the FA 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 registration cycle with DHCP consists of: a) the MN registering with a DHCP server and being assigned a temporary IP address b) the MN sending a Registration Request to it's HA c) the HA receiving the Registration from the MN d) the HA processing the Registration Request and sending a Registration Reply to the MN In the DHCP case Mobile IP messages are only exchanged between the MN and it's HA. When secret key based authentication is being used then MNs, FAs and HAs follow the procedures specified in RFC-2002. The Following sections (3.1 through 3.12) describe Mobile IP authentication based upon public keys for both the FA and DHCP modes of Mobile IP. 3.1. Agent Discovery with Public key Authentication 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 Care-OF-Address (COA) from these Mobility Agent Advertisement Extensions (Agent Advertisements). With SSA the Agent Advertisement has a Foreign Agent Authentication Extension appended which includes a digital signature that is used to authenticate the contents of the Agent Advertisement message followed Jacobs Expires September 1999 [Page 16]
INTERNET DRAFT March 1999 by an appended Certificate Extension so that MNs can quickly obtain an authentic copy of the FA's public key. 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 fields and places this digital signature in a Foreign Agent Authentication Extension. 2. The FA creates a Certificate Extension placing a copy of its Certificate, and any Certificates belonging to CAs necessary for trust hierarchy creation, into the Certificate Extension. 3. The FA appends the Foreign Agent Authentication Extension and the Certificate Extension to the Agent Advertisement message. The FA follows RFC-2002 regarding the transmission of Agent Advertisement messages. 3.2. MN Processing of Agent Advertisements with Public key Authentication 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 necessary for trust hierarchy creation 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 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 in the Foreign Agent Authentication Extension, created using the FA's private key. 6. Upon successful verification of the Foreign Agent Authentication Extension digital signature, the MN continues with normal processing of the Agent Advertisement message as specified in the base Mobile IP protocol. 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 Foreign Agent Advertisement message. Jacobs Expires September 1999 [Page 17]
INTERNET DRAFT March 1999 3.3. MN Registration Request Generation 3.3.1. MN Registration Request Generation and FAs 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 and places this digital signature in a Mobile Node Authentication Extension. 2. The MN then creates a Certificate Extension placing a copy of its Certificate, and any Certificates belonging to CAs necessary for trust hierarchy creation, into the Certificate Extension. 3. The MN appends the Certificate Extension to the end of the Registration Request message following the Mobile Node Authentication Extension. The MN continues with the actions specified in RFC-2002 for sending out Registrations Requests. 3.3.2. MN Registration Request Generation and DHCP 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 and places this digital signature in a Mobile Node Authentication Extension. 2. The MN appends the Mobile Node Authentication Extension to the end of the Registration Request message . The MN continues with the actions specified in RFC-2002 for sending out Registrations Requests directly to it's HA (proceed to section 3.6). 3.4. Registration Request Processing 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 informing the MN that the Jacobs Expires September 1999 [Page 18]
INTERNET DRAFT March 1999 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 Node Authentication Extension, created using the MN's private key. 6. Upon successful verification of the Mobile Node 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. 7. Should the Mobile Node 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 informing the MN that the MN's Registration Request is not allowed having failed authentication. 3.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 and places the digital signature in a Foreign Agent Authentication Extension appended following the Mobile Node Authentication Extension. 3. The FA places a copy of its Certificate, and copies of any other Certificates necessary for establishing a trust hierarchy, into a new Certificate Extension. 4. The FA appends the Certificate Extension to the end of the Registration Request message following the Foreign Agent Authentication Extension. 5. The FA continues with the actions specified in RFC-2002 for sending out Registrations Requests. 3.6. Registration Request Authentication verification by HA 3.6.1. Authentication of FA Forwarded Registration Request 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 Jacobs Expires September 1999 [Page 19]
INTERNET DRAFT March 1999 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 Agent 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 Node 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 message informing the FA and the MN that the MN's Registration Request is not allowed having failed authentication. 3.6.2. Authentication of Registration Request by HA in DHCP Mode When the HA receives a Registration Request sent directly from an MN Using a DHCP allocated IP address (no FA Authentication Extension present), the HA follows RFC-2002 except for the following authentication actions: 1. 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 Node Authentication Extension, created using the MN's private key. 2. Upon successful verification of the Registration Request message digital signature, the HA continues with normal processing of the Registration Request message as specified in the base Mobile IP protocol except for authentication actions. 3. Should the MN Registration Request message digital signature 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 message Jacobs Expires September 1999 [Page 20]
INTERNET DRAFT March 1999 informing the MN that the MN's Registration Request is not allowed having failed authentication. 3.7. HA Generation of Registration Reply 3.7.1. HA Generation of Registration Reply With FAs Involved 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 and places the digital signature in an Home Agent 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 Agent Authentication Extension. 4. The HA continues with the actions specified in RFC-2002 for sending out Registrations Requests. 3.7.2. HA Generation of Registration Reply With DHCP Involved When the HA generates a Registration Reply message, the HA follows RFC-2002 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 and places the digital signature in an Home Agent Authentication Extension which it appends to the Registration Reply. 2. The HA continues with the actions specified in RFC-2002 for sending out Registrations Requests. 3.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. 2. The FA uses the HA's public key from the HA Certificate to verify the digital signature in the Home Agent Authentication Extension, created using the HA's private key. 3. Upon successful verification of the Home Agent 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. 4. Should the Registration Reply message digital signature not pass verification, the FA ceases further authentication processing and Jacobs Expires September 1999 [Page 21]
INTERNET DRAFT March 1999 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. 3.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: 1. The FA deletes the Certificate Extension received from the HA. 2. The FA uses it's private key to produce a digital signature spanning all Registration Reply message fields and places the digital signature in a Foreign Agent Authentication Extension following the Home Agent Authentication Extension. 3. The FA continues with the actions specified in RFC-2002 for sending out Registrations Replies. 3.10. MN Receipt of Registration Reply 3.10.1. 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 uses the FA's public key from the FA Certificate, that the MN already possesses, to verify the FA digital signature in the Foreign Agent Authentication Extension, created using the FA's private key. 2. 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 Agent Authentication Extension, created using the HA's private key. 3. 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. 4. 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. 3.10.2. MN Receipt of Registration Reply Sent Directly from HA When the MN receives a Registration Reply directly from it's HA, the MN follows the base Mobile IP protocol except for the following authentication actions: 1. 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 Jacobs Expires September 1999 [Page 22]
INTERNET DRAFT March 1999 Home Agent Authentication Extension, created using the HA's private key. 2. 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. 3. 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. 3.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 and places the digital signature into a Foreign Agent Authentication Extension appended to the Registration Reply. 2. The FA continues with the actions specified in RFC-2002 for sending out Registrations Replies. 3.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 uses the FA's public key from the FA Certificate, which the MN already possesses, to verify the FA digital signature in the Foreign Agent Authentication Extension, created using the FA's private key. 2. 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. 3. 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. 4. Certificates SSA provides for two forms of certificates: 1) certificates signed by the subject of the certificate and issued by the subject and 2) certificates signed by Certificate Authorities and issued on behalf of the certificate subject by a ertificate Authority. Jacobs Expires September 1999 [Page 23]
INTERNET DRAFT March 1999 4.1 Self-Signed Certificates With self-signed certificates each node acts as its own CA by creating a certificate for itself containing a public key that the node "certifies" as it's public key. This form of public key authentication is typically called an informal web of trust similar to that used with Pretty Good Privacy (PGP) public keys. Self-signed Certificates used with SSA Mobile IP MUST include the same fields as Certificate Authority Signed Certificates except for the following: Signer Distinguished Name - This field replaces the CA Distinguished Name field and contains the Distinguished Name (DN) of the node which created the certificate. Signer Digital Signature - This field replace the CA Digital Signature field and contains the digital Signature, generated by the certificate creator, that binds the other fields of the Certificate together cryptocraphicly. Certificate Serial Number - A unique number assigned to a Certificate by the node that creates and digitally signs the Certificate. This serial number is used to positively identify the Certificate 4.2. Certificate Authority Signed Certificates Certificate Authority Signed Certificates used with SSA 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) or the sender's host name. 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 Jacobs Expires September 1999 [Page 24]
INTERNET DRAFT March 1999 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 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. Jacobs Expires September 1999 [Page 25]
INTERNET DRAFT March 1999 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 CA signed digital certificate should be checked against the current Certificate Revocation List (CRL) from the issuing CA to ensure that revoked Certificate are not employed. SSA Mobile IP recognizes that network performance could be seriously degraded if a receiving node always retrieves the most recent CRL when ever a new CA Signed Certificate is received. Consequently, a node (be it an MN, FA or HA) should cache received CA signed 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 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). 7. Security Considerations Use of Mobile IP without authentication between the MN and the FA, such as with DHCP, do not provide for visited network access control and accounting. Likewise the MN has no basis to trust the visited network not to miss-direct or copy MN sourced packets. Mobile IP relies on the use of the Address Resolution Protocol (ARP) for intercepting packets destined for a traveling MN. Unfortunately ARP does not include authentication mechanisms. 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 SSA Mobile IP provide a user tunable Jacobs Expires September 1999 [Page 26]
INTERNET DRAFT March 1999 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. References [Diffie76] Diffie, W., Hellman, M. E., "New directions in cryptography", IEEE Transactions on Information Theory, IT-22(6):644--654, November 1976. [NIST94] National Institute of Standards and Technology, NIST FIPS PUB 186, "Digital Signature Standard", US. Department of Commerce, May 1994 [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 Jacobs Expires September 1999 [Page 27]
INTERNET DRAFT March 1999 [RFC1541] Droms, R., "Dynamic Host Configuration Protocol", October 1993 [RFC2002] Perkins, C., editor, "IP mobility support", October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", March 1997. [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 Secure Systems Department GTE Laboratories, 40 Sylvan Road, Waltham, MA 02451-1128, USA. Phone: 781-466-3076 Fax: 781-466-2838 Email: sjacobs@gte.com Jacobs Expires July 1999 [Page 28]