idnits 2.17.1 draft-jacobs-mobileip-pki-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 880: '...ion by digital signature, MUST be set....' RFC 2119 keyword, line 949: '...ion by digital signature, MUST be set....' RFC 2119 keyword, line 970: '...Authentication Extension which MUST be...' RFC 2119 keyword, line 972: '...Authentication Extension which MUST be...' RFC 2119 keyword, line 1033: '...Authentication Extension which MUST be...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 481 has weird spacing: '...used to authe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1, 1998) is 9400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2002' is mentioned on line 674, but not defined ** Obsolete undefined reference: RFC 2002 (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'Diffie76' ** Obsolete normative reference: RFC 1319 (Obsoleted by RFC 6149) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Obsolete normative reference: RFC 1541 (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA78' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier96' Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Jacobs 2 INTERNET DRAFT GTE Laboratories 3 August 1, 1998 5 Mobile IP Public Key Based Authentication 6 draft-jacobs-mobileip-pki-auth-00.txt 8 Status of This Memo 10 This document is a submission to the Mobile-IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the mobile-ip@smallworks.com mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or made obsolete by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This document proposes an extension to the Mobile IP base protocol. 35 The purpose of this extension is to allow Mobile Nodes (Hosts) and 36 Mobility Agents (both home network and foreign network) to use X.509 37 digital certificates, public keys and digital signatures as the basis 38 of authenticating Mobile IP control messages. The use of these 39 mechanisms will allow Mobile IP to scale to tens of thousands of 40 mobile nodes across networks owned-operated by different 41 organizations and service providers. 43 Contents 45 Abstract ........................................................... i 47 1. Introduction................................................. 1 48 1.1. Mobility Security Requirements .............................. 1 49 1.2. Security Deficiencies of Mobile IP .......................... 3 50 1.3. Trusted Third Party needed .................................. 5 51 1.4. Terminology ................................................. 5 52 1.5. Security Enhancement ........................................ 7 53 2. Protocol Overview ........................................... 7 54 2.1 Agent Discovery ............................................. 8 55 2.2 MN Processing of Agent Advertisements ....................... 9 56 2.3 MN Registration Request Generation .......................... 9 57 2.4 Registration Request Authentication verification by FA ...... 10 58 2.5 FA Forwarding Registration Requests to HA ................... 10 59 2.6 Registration Request Authentication verification by HA ...... 11 60 2.7 HA Generation of Registration Reply ......................... 12 61 2.8 Registration Reply Authentication verification by FA ........ 12 62 2.9 FA Forwarding Registration Reply to MN ...................... 12 63 2.10 MN Receipt of Registration Reply forwarded by FA ............ 13 64 2.11 FA Generation of Registration Reply ......................... 13 65 2.12 MN Receipt of Registration Reply Generated by FA ............ 14 66 3. Message and Extension Formats ............................... 14 67 3.1 Certificate Extension ....................................... 14 68 3.2. Mobility Agent Advertisement Extension ...................... 15 69 3.3. Registration Request Message ................................ 16 70 3.4. Registration Reply .......................................... 18 71 3.5. Mobile IP Authentication Extensions ......................... 19 72 3.5.1. Computing Authentication Extension Values ................... 19 73 3.5.2. Mobile Authentication Extension ............................. 19 74 3.5.3. Foreign Authentication Extension ............................ 20 75 3.5.4. Home Authentication Extension ............................... 21 76 3.5.5 Correct Sequence of Extension ............................... 21 77 4. Certificates ................................................ 23 78 5. Trust Hierarchy Paths ....................................... 24 79 6. Certificate Revocation Lists ................................ 24 80 7. Security Considerations ..................................... 26 81 A. Patent Issues ............................................... 26 83 References ......................................................... 27 84 Authors' Address ................................................... 27 85 1. Introduction 87 The Mobile IP base protocol [RFC2002] provides an efficient, scalable 88 mechanism for node mobility within the Internet. However, so long as 89 the authentication of Mobile IP control messages rely on the use of 90 secret key mechanisms, then key management remains a major hindrance 91 to large scale deployment of Mobile IP. 93 1.1. Mobility Security Requirements 95 As the use of mobile nodes becomes more common, five security related 96 requirements become vital: 97 - Authentication. The receiver of a message must be able to 98 ascertain who the actual originator of the message is; thereby 99 preventing an intruder from masquerading as a legitimate source of 100 the message in question. 101 - Authorization. The organization which owns/operates a network 102 must have the ability to decide who may attach to the network 103 and what network resources may be used by the attaching (visiting) 104 node. 105 - Integrity. The receiver of a message must be able to ascertain 106 whether a message has been modified in transit; thereby preventing 107 an intruder from altering messages. 108 - Nonrepudiation. The sender of a message must not be able to 109 falsely deny that it originated a message at a later time. 110 - Key Management. The only method available to accurately enforce 111 authentication, integrity and nonrepudiation is by using some form 112 of cryptography; which requires the distribution/exchange of 113 encryption key information amongst message senders and receivers. 115 Expanding on these points: 117 AUTHENTICATION 119 Authentication may be provided in many forms with varying degrees of 120 assurance; from simple passwords transmitted in the clear to digital 121 signatures based on either secret or public key cryptographic 122 algorithms. The majority of networks mobile nodes visit will be 123 wireless nets which are subject to eavesdropping and unable to 124 control actual attachment via physical controls. Unless a commercial 125 or military wireless network provides encryption, frequency hopping 126 or other form of link layer access controls or privacy mechanisms, a 127 rogue or hostile Foreign Agent (FA) could transmit messages 128 indistinguishable from legitimate FA messages. 130 When a Mobile Node (MN) receives an Agent Advertisement message, the 131 MN needs to know that the advertisement comes from a valid FA on the 132 network the MN wants to register with. In those cases where no 133 authentication process between a FA and an MN occurs, or the 134 authentication process used is computationally easy to negate, a 135 hostile FA could easily masquerade as a legitimate FA and present a 136 denial-of-service threat by: 138 - issuing Registration Reply messages stating the MN registration 139 request is denied 140 - forwarding MN Registration Requests to an address other than that 141 of the MN's Home Agent (HA) causing the MN to never receive a 142 Registration Reply from it's HA, or 143 - discarding MN Registration Requests causing the MN to never 144 receive a Registration Reply from it's HA. 145 When a MN wants to attach to a foreign network, the FA needs to know 146 the authentic identity of the MN so the FA can determine whether to 147 allow the MN it's requested attachment. The actual decision to allow 148 the attachment falls within the area of authorization but the FA 149 cannot make a valid decision unless it knows, with some defined 150 degree of assurance, that the MN is who it says it is. 152 It becomes readily apparent that authentication plays a key role in 153 IP mobility in avoiding denial-of-service risks and as the 154 foundation for access control decisions. 156 AUTHORIZATION 158 Access control (authorization) at a foreign network being visited by 159 an MN is critical within a mobile node context. Networks supporting 160 visiting MNs need the ability to decide which MNs are allowed 161 visiting rights. These networks also need a mechanism by which 162 access control information may be defined, stored, validated and 163 applied to requested MN visits. An IP mobility protocol needs to 164 address the mechanism(s) by which a network node obtains 165 authorization information and guidelines to ensure interoperability 166 between different implementations. 168 INTEGRITY 170 Any messages sent between MNs, HAs and FAs that affect how IP packets 171 are routed must be received at the destination exactly as sent by the 172 message source. Failure to validate the integrity of these types of 173 messages allows a hostile node to modify these messages while in 174 transit. Modification could easily result in an MN's attempt to 175 register at a foreign network being denied or the registration 176 occurring but packets destined for the MN, at the foreign network, 177 being miss-routed/lost. 179 NONREPUDIATION 181 When a MN visits a foreign network the MN will consume network 182 resources (i.e., number of packets sent/received, number of packets 183 detunneled by the FA, assigned IP address space, etc.). From the 184 perspective of the organization responsible for the visited network, 185 a record of what resources are consumed by the visiting MN needs to 186 be kept for performance and accounting management purposes. Should 187 the organization want to charge/bill for the use of these resources, 188 then the FA must have a way of identifying which MN consumed what 189 resources such that the owner of the MN cannot deny the visit or 190 resources consumed. 192 KEY MANAGEMENT 194 Industrial strength authentication, integrity and nonrepudiation 195 approaches are based primarily on the use of cryptographic 196 algorithms. Modern cryptographic algorithms base their security 197 capabilities on the use of a key, or keys, which allows the 198 algorithm(s) to be publicly available so long as the keying 199 information is kept and distributed in a private (i.e., secure) 200 manner. 202 One method for distributing the key information is to manually load 203 it into each node. This is fine for a small number of nodes but runs 204 into administrative problems. Page 29 of [Schneier96] highlights 205 this problem by noting that if a separate key is used by each pair of 206 nodes for authentication purposes, the total number of keys increases 207 rapidly as the number of users increases. N users requires N(N-1)/2 208 keys. Authentication amongst 100 nodes would require 4950 key pairs 209 and amongst a 1000 nodes would require 499,500 keys, where each key 210 must be kept private and distributed in a secure manner. It quickly 211 becomes apparent that a manual key distribution approach is not 212 feasible for use in IP mobility authentication except with a very 213 small number of nodes. 215 A truly viable solution for Mobile Nodes must scale well to large 216 numbers of mobile nodes by providing a secure dynamic key 217 distribution function. 219 1.2 Security Deficiencies of Mobile IP 221 As already noted strong authentication is the corner-stone upon which 222 access control, integrity, and non-repudiation rely. Mobile IP 223 currently only requires that registration messages between an MN and 224 its HA be authenticated. Registration messages between an HA and an 225 FA, or between an MN and an FA, may be optionally authenticated. 227 The majority of networks MNs visit will be wireless nets which are 228 subject to eavesdropping and unable to control actual attachment via 229 physical controls. Unless authentication between FAs and HAs and 230 between FAs and MNs is mandatory, Mobile IP will never succeed 231 commercially. 233 A number of alternative approaches are under consideration for 234 Mobile IP authentication, and associated key management/distribution. 235 Although not part of any RFC at this time, these approaches are 236 considered here. 237 THE HA AS A KEY DISTRIBUTION CENTER (KDC) 239 The approach of using the HA as a KDC, requires: 240 - the HA have a secret key based security association with the MN 241 - the HA have a secret key based security association with the FA 242 - the HA to generate, encrypt and distribute Registration keys for 243 use by the FA and MN. 245 This approach requires the use of three separate secret keys for one 246 MN to register with one FA. When scaled to large networks we are 247 facing the need for thousands of secret keys, two thirds of which are 248 manually distributed and one third generated, encrypted and 249 distributed dynamically as MNs register on foreign networks. An HA, 250 supporting 20 MNs who roam to new foreign networks every 5 minutes, 251 is faced with having to generate, encrypt and distribute as many as 252 120 secret keys per hour (30 seconds for each new key). An HA, 253 supporting 100 MNs who roam to new foreign networks every 2 minutes, 254 is faced with having to generate, encrypt and distribute as many as 255 3000 secret keys per hour (1200 milliseconds for each new key. These 256 HA functions of generating, encrypting and distributing the MN-FA 257 secret keys are in addition to all other HA activities. Can an HA 258 perform these KDC functions on top of its responsibilities for 259 handling traffic being tunneled to roaming MNs? Another problem is 260 how will the secret keys be distributed? Manual distribution of the 261 secret key will not scale as previously discussed. This approach 262 does not deal with the trust relationship between the MN and the FA 263 for access control and non-repudiation. Again a trusted third party 264 is necessary for the FA to trust the MN from an identity standpoint. 266 USING DIFFIE-HELLMAN WITH THE FOREIGN AGENT 268 This approach allows MNs and FAs to establish registration keys by 269 executing the Diffie-Hellman key exchange algorithm [Diffie76] as 270 part of the MN's registration. Using the Diffie-Hellman algorithm 271 allows the MN and the FA to establish a registration key without any 272 pre-existing mobility security associations. One is still faced with 273 the problem of manually distributing secret keys between MNs and HAs. 274 This approach also does not deal with the trust relationship between 275 the MN and the FA for access control and non-repudiation. Again a 276 trusted third party is necessary for the FA to trust the MN from an 277 identity standpoint. 279 USING A MOBILE NODE PUBLIC KEY 281 With this approach the FA is charged with generating the new 282 registration key and returning a copy of it encrypted with the MN's 283 Public Key, received in a MN Public Key extension. However the FA has 284 no way of verifying if the public key received from the MN is valid 285 for that MN since there is no authentication associated with the 286 Public Key sent by the MN. This approach also does not deal with the 287 trust relationship between the MN and the FA for access control and 288 non-repudiation. Again a trusted third party is necessary for the FA 289 to trust the MN from an identity standpoint. 291 USING A FOREIGN AGENT PUBLIC KEY 293 The only real difference between this approach and that of using the 294 HA as a KDC is that the HA uses an unauthenticated Public Key from 295 the FA for encrypting the newly generated registration key being sent 296 to the FA rather that an existing secret key security association 297 between the HA and the FA. The inclusion of an MD5 digest of the FA's 298 public key in a Registration Key Request Public Key Digest extension 299 only establishes that the public key supplied by the FA in the FA 300 Public Key extension is the same as received by the MN in an Agent 301 Advertisement message. 303 1.3. Trusted Third Party needed 305 Use of public keys contained in Digital Certificates (Certificates) 306 issued by trusted third parties, in the form of Certificate 307 Authorities (CAs), provides the key ingredient for establishing trust 308 Relationships between HAs, MNs and FAs. When an FA receives a message 309 from an MN digitally signed with the MNs private key, the FA is able 310 to validate the digital signature using a copy of the MN's public key 311 from a copy of the MN's Certificate. If the FA shares the same CA as 312 the MN, then the FA can easily authenticate the MN's Certificate by 313 checking the CA digital signature within the MN's Certificate using 314 the CA's public key from the copy of the CA's Certificate already in 315 the FA's possession. Should the FA and the MN not use the same CA, 316 the FA can establish a trust hierarchy path between the FA's CA and 317 the CA of the MN. The converse is true for MNs authenticating digital 318 signatures generated with FA private key and the same is true between 319 HAs and FAs. The inclusion of the CA, or trust hierarchy path between 320 CAs, allows Mobile IP aware systems to establish strong trust 321 relationships to base authentication, access control and 322 non-repudiation decisions on. 324 1.4. Terminology 326 Certification Authority (CA) 327 A third party trusted by one or more users to create and assign 328 digital certificates. All CAs are required to maintain a 329 database of the Distinguished Names (DNs) which they have 330 certified and to take measures to ensure that they do not 331 certify duplicate DNs. 333 Certificate-Revocation List (CRL) 334 A data structure that contains that contains information about 335 certificates whose validity an issuer has prematurely revoked. 336 The information consists of an issuer name, the time of issue, 337 the next scheduled time of issue, and a list of certificate 338 serial numbers and their associated revocation times. The CRL 339 is signed by the issuer. The data structure is defined in 340 [RFC1422] 342 Certificate Subject (Subject) 343 A Certificate Subject, or Subject, is the entity referred to by 344 the Distinguished Name (DN) contained within the Certificate. 346 Digital Certificate (Certificate) 347 A Digital Certificate, or Certificate, is a data structure 348 that binds an entity's Distinguished Name (DN) to a public key 349 with a digital signature. This data structure is defined in 350 [X.509]. and contains information, such as identify and public 351 key, about an entity where an authority, called a Certification 352 Authority, has cryptographicly linked the information together 353 using a digital signature. 355 Digital Certification 356 Digital Certification is the mechanism in which a Certification 357 Authority (CA) "signs" a special data structure containing the 358 name of some entity, or Subject, and their public key in such a 359 way that anyone can "verify" that the message was signed by no 360 one other than the certification authority and thereby develop 361 trust in the subject's public key. 363 Digital Signature 364 the content to be signed is first reduced to a message digest 365 with a message-digest algorithm (such as MD5), and then the 366 octet string containing the message digest is encrypted with 367 the RSA private key of the signer of the content. 369 Distinguished Name (DN) 370 A Distinguished Name, or DN, defines a "path" through an X.500 371 directory tree from the root of the tree to an object of 372 interest. 374 Message-Digest Algorithm 375 A message-digest algorithm is a method of reducing a message of 376 Any length to a string of a fixed length, called the message 377 digest, in such a way that it is computationally infeasible to 378 find a collision (two messages with the same message digest) or 379 to find a message with a given, predetermined message digest. 380 MD2 and MD5 are message-digest algorithms described in 381 [RFC1319] and [RFC1321]. Each inputs an arbitrary message and 382 outputs a 128-bit message digest. 384 Public-key algorithm 385 An algorithm for encrypting or decrypting data with a public or 386 Private key. When a private key is used to encrypt a message 387 digest the public-key algorithm is called a message-digest 388 encryption algorithm and the encrypted output is called a 389 Digital Signature. This algorithm transforms a message of any 390 length under a private key to a signature in such a way that it 391 is computationally infeasible to find two messages with the 392 same signature, to find a message with a given, predetermined 393 signature, or to find the signature of a given message without 394 knowledge of the private key. Typically, a digital signature is 395 created by computing a message digest on the message, then 396 encrypting the message digest with the private key. 398 Public-key cryptography 399 Public-key cryptography is the technology first identified by 400 Diffie and Hellman [Diffie76] in which encryption and 401 Decryption involve different keys. The two keys are the public 402 key and the private key, and either can encrypt or decrypt 403 data. A user gives his or her public key to other users, 404 keeping the Private key to himself or herself. 406 RSA 407 RSA is a public-key algorithm invented by Rivest, Shamir, and 408 Adleman [RSA78] involving exponentiation modulo the product of 409 two large prime numbers. The difficulty of breaking RSA is 410 generally considered to be equal to the difficulty of factoring 411 integers that are the product of two large prime numbers of 412 approximately equal size. 414 1.5. Security Enhancement 416 The design goal of the Public Key Authentication (PKA) model is to 417 add scaleable strong authentication to Mobile IP. The PKA enabled 418 Mobile IP protocol works exactly the same way as the base protocol 419 for the FA supplied card-of-address (COA) mode of operation except 420 for the mechanism responsible for generating/verifying message 421 authenticators and the data structures supporting the proposed 422 digital signature based authenticators. 424 The Co-located COA mode (sometimes referred to as "pop-up" mode) 425 relies on the use of DHCP [RFC1541] and cannot be considered 426 deployable on a wide scale since DHCP does not include any 427 authentication and assumes that nodes requesting DHCP assigned 428 addresses either belong to the same organization operating the DHCP 429 server or these nodes will be authenticated for network use outside 430 of DHCP. The typical uses of DHCP are to: 1) simplify IP address 431 management in an organizations LAN campus environment, or 2) allow 432 ISP customers to remotely connect to the ISP' infrastructure. ISPs 433 using DHCP require the connecting customer to provide a user ID and a 434 password before the ISP will accept user traffic from the connecting 435 customer. 437 2. Protocol Overview 439 Under the PKA model, a complete registration cycle consists of: 440 - the MN receiving a Mobility Agent Advertisement 441 - the MN sending a Registration Request to the FA 442 - the FA preprocessing the received Registration Request and, if 443 tentatively approved, passing the Registration Request to the MN's 444 HA 445 - the HA receiving the Registration from the MN via the FA 446 - the HA processing the Registration Request and sending a 447 Registration Reply to the FA 449 - the FA receiving the Registration Reply, updating visiting MN data 450 structures, and sending the completed Registration Reply to the 451 visiting MN. 452 Proposed authentication changes apply to the messages associated with 453 both the Agent Discovery and the Registration procedures. The primary 454 message change supporting the PKA model is the use of a Certificate 455 Extension appended to Mobile IP control messages (Mobility Agent 456 Advertisement Extension, Registration Requests and Registration 457 Replies). 459 The Certificate Extension includes a copy, or copies, of Certificates 460 that bind system "distinguished names" to public keys using a digital 461 signature. A Certificate Extension will always contain at least one 462 Certificate issued by a Certificate Authority (CA) to the sender, or 463 forwarder, of a message. There may also be present in the Certificate 464 Extension Certificates belonging to one of more CAs. When FAs and MNs 465 share a common CA, only the Certificate of the common CA would ever 466 appear in the Certificate Extension. In the case where the FA and the 467 MN do not have a common CA, the Certificate Extension will contain 468 multiple CA Certificates from which a trust hierarchy path between 469 the CA of the MN and the CA of the FA may be established (see Section 470 4. For details on establishing trust hierarchy paths) 472 2.1 Agent Discovery 474 In the base protocol, FAs advertise their presence via a Mobility 475 Agent Advertisement Extension appended to ICMP Router Advertisements 476 generated by Mobility Agents acting as Foreign Agents. The visiting 477 MN obtains a COA (which usually is the FA's address)from these 478 Mobility Agent Advertisement Extensions (Agent Advertisements). 480 The PKA model requires that the Agent Advertisement include a digital 481 signature that is used to authenticate the contents of the Agent 482 Advertisement message and a Certificate Extension so that prospective 483 MNs can quickly obtain an authentic copy of the FA's public key, 484 necessary to verify the digital signature. The specific 485 authentication steps the FA follows are: 486 1. the FA uses it's private key to produce a digital signature 487 spanning all Agent Advertisement message fields, as specified in 488 [RFC2002]. 489 2. The FA creates a Certificate Extension placing a copy of its 490 Certificate and a copy of the Certificate belonging to FA's CA 491 into the Certificate Extension. 492 3. The FA also places copies of the Certificates of those CAs 493 necessary for an MN to establish a trust hierarchy path between 494 CAs into the Certificate Extension. 495 4. The FA appends the Certificate Extension to the Agent 496 Advertisement message (Extension). 497 5. The FA follows the base Mobile IP protocol regarding the 498 transmission of Agent Advertisement messages. 500 2.2 MN Processing of Agent Advertisements 502 When the MN receives an Agent Advertisement, the MN follows the base 503 Mobile IP protocol except for the following authentication actions: 504 1. the MN extracts the Certificates from the Certificate Extension 505 and, in the case where the FA and the MN share the same CA, the 506 MN uses the CA's public key to validate the FA's Certificate. 507 2. In the case where the MN and the FA do not share a common CA, the 508 MN uses any other CA Certificates contained in the Certificate 509 Extension to establish a trust hierarchy path between the MN's CA 510 and the FA's CA (see Section 5.0). 511 3. In the case where the MN is unable to establish a trust hierarchy 512 path between the CAs, the MN ceases further authentication 513 processing and considers the Agent Advertisement message not 514 authentic, the sending FA as not a valid candidate to register 515 with and the MN ignores this Agent Advertisement message. 516 4. Should the MN be able to establish a trust hierarchy path between 517 CAs, the MN proceeds down the path verifying CA Certificates 518 stopping when the Certificate of the advertising FA has been 519 verified. 520 5. Upon verification of the FA's Certificate, the MN uses 521 the FA's public key from the FA Certificate to verify the 522 digital signature, created using the FA's private key. 523 6. Upon successful verification of the Agent Advertisement digital 524 signature, the MN continues with normal processing of the Agent 525 Advertisement message as specified in the base Mobile IP 526 protocol. 527 7. Should the Agent Advertisement digital signature not pass 528 verification, the MN ceases further processing and considers the 529 Agent Advertisement message as not authentic, the sending FA as 530 not a valid candidate to register with and the MN ignores this 531 Agent Advertisement message. 533 2.3 MN Registration Request Generation 535 When the MN generates a Registration Request message, the MN follows 536 The base Mobile IP protocol except for the following authentication 537 actions: 538 1. the MN uses it's private key to produce a digital signature 539 spanning all Registration Request message fields as specified in 540 Section 3.5.5 and places this digital signature in a Mobile 541 Authentication Extension. 542 2. The MN then creates a Certificate Extension placing a copy of its 543 Certificate and a copy of the Certificate of the MN's CA into the 544 Certificate Extension. 545 3. Should the MN and the FA not share a common CA, the MN also 546 places copies of the Certificates of those CAs necessary for the 547 FA to establish a trust hierarchy path between CAs. 548 4. The MN appends the Certificate Extension to the end of the 549 Registration Request message following the Mobile Authentication 550 Extension. 551 5. The MN continues with the actions specified in RFC2002 for 552 sending out Registrations Requests. 554 2.4 Registration Request Authentication verification by FA 556 When the FA receives a Registration Request from an MN, the FA 557 follows the base Mobile IP protocol except for the following 558 authentication actions: 559 1. the FA extracts the Certificates from the Certificate Extension 560 and, in the case where the FA and the MN share the same 561 CA, the FA uses the CA's public key to validate the MN's 562 Certificate. 563 2. In the case where the MN and the FA do not share a common CA, 564 then the FA uses any other CA Certificates contained in 565 the Certificate Extension to establish a trust hierarchy path 566 between the FA's CA and the MN's CA. 567 3. In the case where the FA is unable to establish a trust hierarchy 568 path between the CAs, the FA ceases further authentication 569 processing and considers the Registration Request message not 570 authentic, the sending MN as not allowed to attach to the FA's 571 network, the FA logs the authentication failure and creates a 572 Registration Reply message (see Section 2.11) informing the MN 573 that the MN's Registration Request is not allowed having failed 574 authentication. 575 4. Should the FA be able to establish a trust hierarchy path between 576 CAs. The FA proceeds down the path verifying CA Certificates 577 stopping when the Certificate of the MN has been verified. 578 5. The FA uses the MN's public key from the MN Certificate 579 to verify the digital signature in the Mobile Authentication 580 Extension, created using the MN's private key. 581 6. Upon successful verification of the Mobile Authentication 582 Extension digital signature, the FA continues with normal 583 processing of the Registration Request message as specified in 584 the base Mobile IP protocol except for authentication actions 585 (see Section 2.5). 586 7. Should the Mobile Authentication Extension digital signature not 587 pass verification, the FA ceases further authentication 588 processing and considers the Registration Request message not 589 authentic, the sending MN as not allowed to attach to the FA's 590 network, the FA logs the authentication failure and creates a 591 Registration Reply message (see Section 2.11) informing the MN 592 that the MN's Registration Request is not allowed having failed 593 authentication. 595 2.5 FA Forwarding Registration Requests to HA 597 When the FA finishes basic Registration Request processing and is 598 preparing to forward the Registration Request to the MN's Home Agent 599 (HA), the FA performs the following authentication actions: 600 1. The FA deletes the received Certificate Extension. 601 2. the FA uses it's private key to produce a digital signature 602 spanning all Registration Request message fields as specified in 603 Section 3.5.5 and places the digital signature in a Foreign 604 Authentication Extension located following the Mobile 605 Authentication Extension. 606 3. The FA places a copy of its Certificate and a copy of the 607 Certificate belonging to FA's CA into a new Certificate 608 Extension. 609 4. Should the MN and the FA not share a common CA, then the FA also 610 places copies of the Certificates of those CAs necessary for the 611 HA to establish a trust hierarchy path between CAs. 612 5. The FA appends the Certificate Extension to the end of the 613 Registration Request message following the Foreign Authentication 614 Extension. 615 6. The FA continues with the actions specified in [RFC2002] for 616 sending out Registrations Requests. 618 2.6 Registration Request Authentication verification by HA 620 When the HA receives a Registration Request forwarded from an FA, the 621 HA follows the base Mobile IP protocol except for the following 622 authentication actions: 623 1. the HA extracts the Certificates from the Certificate Extension 624 and, in the case where the FA and the HA share the same CA, the 625 HA uses the CA's public key to validate the FA's Certificate. 626 2. In the case where the HA and the FA do not share a common CA, 627 then the HA uses any other CA Certificates contained in 628 the Certificate Extension to establish a trust hierarchy path 629 between the HA's CA and the FA's CA. 630 3. In the case where the HA is unable to establish a trust hierarchy 631 path between the CAs, the HA ceases further authentication 632 processing and considers the Registration Request message 633 invalid, the forwarding FA as untrustworthy as a Foreign Agent, 634 the HA logs the authentication failure and creates a Registration 635 Reply message informing the FA that the MN's Registration Request 636 is not allowed having failed FA authentication. 637 4. Should the HA be able to establish a trust hierarchy path between 638 CAs. The HA proceeds down the path verifying CA Certificates 639 stopping when the Certificate of the FA has been verified. 640 5. The HA uses the FA's public key from the FA Certificate 641 to verify the FA digital signature in the Foreign Authentication 642 Extension, created using the FA's private key. 643 6. The HA uses the MN's public key, from the MN Certificate 644 that the HA already possesses, to verify the MN digital signature 645 in the Mobile Authentication Extension, created using the MN's 646 private key. 647 7. Upon successful verification of the Registration Request message 648 digital signatures, the HA continues with normal processing of 649 the Registration Request message as specified in the base Mobile 650 IP protocol except for authentication actions. 651 8. Should the Registration Request message digital signatures not 652 pass verification, the HA ceases further authentication 653 processing and considers the Registration Request message not 654 authentic, the requested registration as prohibited, the HA logs 655 the authentication failure and creates a Registration Reply 656 message informing the FA and the MN that the MN's Registration 657 Request is not allowed having failed authentication. 659 2.7 HA Generation of Registration Reply 661 When the HA generates a Registration Reply message, the HA follows 662 the base Mobile IP protocol except for the following authentication 663 actions: 664 1. the HA uses it's private key to produce a digital signature 665 spanning all Registration Request message fields as specified in 666 Section 3.5.5 and places the digital signature in an Home 667 Authentication Extension which it appends to the Registration 668 Reply. 669 2. The HA then creates a Certificate Extension placing a copy of its 670 Certificate into the Certificate Extension. 671 3. The HA appends the Certificate Extension to the end of the 672 Registration Request message following the Home Authentication 673 Extension. 674 4. The HA continues with the actions specified in [RFC 2002] for 675 sending out Registrations Requests. 677 2.8 Registration Reply Authentication verification by FA 679 When the FA receives a Registration Reply from an HA, the FA follows 680 the base Mobile IP protocol except for the following authentication 681 actions: 682 1. the FA extracts the HA's Certificate from the Certificate 683 Extension and uses the public key from the Certificate of 684 the HA's CA to validate the HA's Certificate. The FA already has 685 a validated copy of the Certificate for the HA's CA from when the 686 FA established the trust hierarchy path for the Certificate of 687 MN's CA since the MN and the HA will share a common CA. 688 2. The FA uses the HA's public key from the HA Certificate 689 to verify the digital signature in the Home Authentication 690 Extension, created using the HA's private key. 691 3. Upon successful verification of the Home Authentication Extension 692 digital signature, the FA continues with normal processing of the 693 Registration Reply message as specified in the base Mobile IP 694 protocol except for authentication actions (see Section 2.9). 695 4. Should the Registration Reply message digital signature not pass 696 verification, the FA ceases further authentication processing and 697 considers the Registration Reply message not authentic, the 698 sending HA as not a valid HA, the FA logs the authentication 699 failure and creates a Registration Reply message informing the MN 700 that the MN's Registration Request is not allowed having failed 701 authentication. 703 2.9 FA Forwarding Registration Reply to MN 705 When the FA finishes basic Registration Reply processing and is 706 preparing to forward the Registration Reply to the MN, the FA 707 performs the following authentication actions: 709 1. The FA deletes the Certificate Extension. 710 2. the FA uses it's private key to produce a digital signature 711 spanning all Registration Reply message fields as specified in 712 Section 3.5.5 and places the digital signature in a Foreign 713 Authentication Extension following the Home Authentication 714 Extension. 715 3. The FA places a copy of its Certificate into a new 716 Certificate Extension. 717 4. The FA appends the Certificate Extension to the end of the 718 Registration Request message following the Foreign Authentication 719 Extension. 720 5. The FA continues with the actions specified in [RFC2002] for 721 sending out Registrations Replies. 723 2.10 MN Receipt of Registration Reply forwarded by FA 725 When the MN receives a Registration Reply forwarded from an FA, the 726 MN follows the base Mobile IP protocol except for the following 727 authentication actions: 728 1. the MN extracts the FA's Certificate from the Certificate 729 Extension. 730 2. The MN uses the FA's public key from the FA Certificate to verify 731 the FA digital signature in the Foreign Authentication Extension, 732 created using the FA's private key. 733 3. The MN uses the HA's public key, from the HA Certificate, 734 that the MN already possesses, to verify the HA digital signature 735 in the Home Authentication Extension, created using the HA's 736 private key. 737 4. Upon successful verification of the Registration Reply message 738 digital signatures, the MN continues with normal processing of 739 the Registration Reply message as specified in the base Mobile IP 740 protocol except for authentication actions. 741 5. Should the Registration Reply message digital signatures not pass 742 verification, the MN ceases further authentication processing and 743 considers the Registration Reply message not authentic, the MN 744 logs the authentication failure and restarts its efforts to find 745 a foreign network the MN can register with. 747 2.11 FA Generation of Registration Reply 749 When the FA generates a Registration Reply message rejecting an MN's 750 request to register with the FA's network, the FA follows the base 751 Mobile IP protocol except for the following authentication actions: 752 1. The FA uses it's private key to produce a digital signature 753 spanning all Registration Rely message fields as specified in 754 Section 3.5.5 and places the digital signature into a Foreign 755 Authentication Extension appended to the Registration Reply. 756 2. The FA then creates a Certificate Extension placing a copy of its 757 Certificate into the Certificate Extension. 758 3. The FA appends the Certificate Extension to the end of the 759 Registration Reply message following the Foreign Authentication 760 Extension. 762 4. The FA continues with the actions specified in [RFC2002] for 763 sending out Registrations Replies. 765 2.12 MN Receipt of Registration Reply Generated by FA 767 When the MN receives a Registration Reply generated by an FA, the MN 768 follows the base Mobile IP protocol except for the following 769 authentication actions: 770 1. the MN extracts the FA's Certificate from the Certificate 771 Extension. 772 2. The MN uses the FA's public key from the FA Certificate 773 to verify the FA digital signature in the Foreign Authentication 774 Extension, created using the FA's private key. 775 3. Upon successful verification of the Registration Reply message FA 776 digital signature, the MN continues with normal processing of the 777 Registration Reply message as specified in the base Mobile IP 778 protocol except for authentication actions. 779 4. Should the Registration Reply message FA digital signature not 780 pass verification, the MN ceases further authentication 781 processing and considers the Registration Reply message not 782 authentic, the MN logs the authentication failure and restarts 783 its efforts to find a foreign network the MN can register with. 784 3. Message and Extension Formats 786 3.1 Certificate Extension 788 The Certificate Extension is used to transfer authentication 789 information (Certificates) between MNs, FAs and HAs. The fields of 790 the Certificate Extension are: 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type | Ext-Length | Cert-cnt | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Sender-Certificate-Length | Sender-Certificate 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Sender-Certificate, continued ... | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | CA-Certificate-Length | CA-Certificate 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | CA-Certificate, continued ... | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Type: 10 (1 byte), identifies this as a Certificate Extension. 808 Ext Length: (2 bytes) The length of the Certificate Extension 809 in bytes. 810 set to 4 + value of Authenticator-Length field 811 + value of Source-Certificate-Length field 812 + value of CA-Certificate-Length field 814 Sender-Certificate-Length: (2 bytes) Length in bytes of the 815 X.509 Type 3 formatted Certificate 816 of the message sender. 818 Sender-Certificate: (variable length), The X.509 Type 3 819 Formatted Certificate of the message sender 820 which contains the public key of the 821 message sender. 823 CA-Certificate-Length: (2 bytes) Length in bytes of the X.509 824 Type 3 formatted certificate of a 825 Certificate Authority (CA). 827 CA-Certificate: (variable length), The X.509 Type 3 formatted 828 certificate of a CA which contains the public 829 key of the CA used to sign Certificates. 831 3.2. Mobility Agent Advertisement Extension 833 The Mobility Agent Advertisement Extension follows the ICMP Router 834 Advertisement fields. It is used to indicate that an ICMP Router 835 Advertisement message is also an Agent Advertisement being sent by a 836 mobility agent. The Mobility Agent Advertisement Extension is 837 defined as follows: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Type | Length | Sequence Number | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Registration Lifetime |R|B|H|F|M|G|V|A| Auth Type | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | zero or more Care-of Addresses | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Foreign Agent Digital Signature | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Type 16 853 Length (6 + 4*N + S), where N is the number of care-of addresses 854 Advertised and S is the length of the Digital Signature 855 used by an FA to authenticate the other fields in the 856 Mobility Agent Advertisement Extension. 858 Sequence Number 859 Unchanged from base Mobile IP protocol. 861 Registration Lifetime 862 Unchanged from base Mobile IP protocol. 864 R Registration required. Registration with this foreign 865 agent (or another foreign agent on this link) is 866 required. Must be always set. 868 B Unchanged from base Mobile IP protocol. 870 H Unchanged from base Mobile IP protocol. 872 F Unchanged from base Mobile IP protocol. 874 M Unchanged from base Mobile IP protocol. 876 G Unchanged from base Mobile IP protocol. 878 V Unchanged from base Mobile IP protocol. 880 A Authorization by digital signature, MUST be set. 882 Auth Type 883 Identifies the cryptographic method (algorithm) and key 884 Length used to generate digital signatures. Valid 885 Authentication types are: 887 Auth. Type Key Length Digital Signature 888 Value Algorithm in bits Length in bytes 889 --------- --------- ---------- ----------------- 890 101 RSA 512 64 891 102 RSA 1024 128 893 Other Authentication types will be defined in the future. 895 Care-of Address(es) 896 Unchanged from base Mobile IP protocol. 898 3.3. Registration Request Message 900 An MN registers with its HA using a Registration Request message so 901 that its HA can create or modify a mobility binding for that MN. The 902 Request is always relayed to the HA by the FA through which the MN is 903 registering. 905 IP fields: 907 Unchanged from base Mobile IP protocol. 909 UDP fields: 911 Source Port variable 913 Destination Port 434 915 The UDP header is followed by the Mobile IP fields shown below: 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Type |S|B|r|M|G|V|A|t| Lifetime | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Home Address | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Home Agent | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Care-of Address | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | | 929 + Identification + 930 | | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Extensions ... 933 +-+-+-+-+-+-+-+- 935 Type 1 (Registration Request) 937 S Unchanged from base Mobile IP protocol. 939 B Unchanged from base Mobile IP protocol. 941 r Reserved bit; sent as zero. 943 M Unchanged from base Mobile IP protocol. 945 G Unchanged from base Mobile IP protocol. 947 V Unchanged from base Mobile IP protocol. 949 A Authorization by digital signature, MUST be set. 951 t Reserved bit; sent as zero 953 Lifetime 954 Unchanged from base Mobile IP protocol. 956 Home Address 957 Unchanged from base Mobile IP protocol. 959 Home Agent 960 Unchanged from base Mobile IP protocol. 962 Care-of Address 963 Unchanged from base Mobile IP protocol. 965 Identification 966 Unchanged from base Mobile IP protocol. 968 Extensions 969 Usage is same as in base Mobile IP protocol except for 970 - Mobile-Home Authentication Extension which MUST be 971 included in all Registration Requests. 972 - Foreign-Home Authentication Extension which MUST be 973 included for all Registration Requests being forwarded 974 from an FA to an HA 975 - Certificate Extension which must be included on all 976 Registration Requests. 978 3.4. Registration Reply 980 A mobility agent (FA or HA) returns a Registration Reply message to an MN 981 which has sent a Registration Request (Section 3.3) message. 983 IP fields: 985 Source Address Unchanged from base Mobile IP protocol. 987 Destination Address Unchanged from base Mobile IP protocol. 989 UDP fields: 991 Source Port 993 Destination Port Unchanged from base Mobile IP protocol. 995 The UDP header is followed by the Mobile IP fields shown below: 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Type | Code | Lifetime | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Home Address | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Home Agent | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | | 1007 + Identification + 1008 | | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Extensions ... 1011 +-+-+-+-+-+-+-+- 1013 Type 3 (Registration Reply) 1015 Code A value indicating the result of the Registration 1016 Request. See below for a list of currently defined Code 1017 values. 1019 Lifetime 1020 Unchanged from base Mobile IP protocol. 1022 Home Address 1023 Unchanged from base Mobile IP protocol. 1025 Home Agent 1026 Unchanged from base Mobile IP protocol. 1028 Identification 1029 Unchanged from base Mobile IP protocol. 1031 Extensions 1032 Usage is same as in base Mobile IP protocol except for 1033 - Mobile-Home Authentication Extension which MUST be 1034 included in all Registration Replies. 1035 - Foreign-Home Authentication Extension which MUST be 1036 included for all Registration Replies being forwarded 1037 from an FA to an MN 1038 - Certificate Extension which must be included on all 1039 Registration Replies. 1041 No new values defined for use within the Code field. 1043 3.5. Mobile IP Authentication Extensions 1045 3.5.1. Computing Authentication Extension Values 1047 The digital signature computed for each authentication Extension MUST 1048 protect the following fields from the registration message: 1050 - the UDP payload (that is, the Registration Request or 1051 Registration Reply data), 1053 - all prior Extensions in their entirety, and 1055 - the Type and Length of this Extension. 1057 The default authentication algorithm uses RSA and a 512 bit private 1058 key to compute a 512-bit cryptographic "message digest" of the 1059 registration message. The default digital signature is a 512-bit 1060 value computed over the protected fields from the registration 1061 message. 1063 Note that the digital signature field itself and the UDP header are 1064 NOT included in the computation of the digital signature value. 1066 3.5.2. Mobile Authentication Extension 1068 Exactly one Mobile Authentication Extension MUST be present in all 1069 Registration Requests. The location of the extension marks the end 1070 of the authenticated data. 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Type | Length | Auth Type | reserved | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Mobile Node (MN) Digital Signature | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 Type 32 1082 Length 4 plus the number of bytes in the digital 1083 signature. 1085 Auth Type 1086 Valid if the A bit set, in which case this field 1087 identifies the cryptographic method (algorithm) and key 1088 length used to generate digital signatures. Valid 1089 Authentication types are: 1091 Auth. Type Key Length Digital Signature 1092 Value Algorithm in bits Length in bytes 1093 --------- --------- ---------- ----------------- 1094 101 RSA 512 64 1095 102 RSA 1024 128 1097 Other Authentication types will be defined in the future. 1099 Digital Signature (variable length) (See Section 3.5.1.) 1101 3.5.3. Foreign Authentication Extension 1103 This Extension MUST be included in Registration Requests being passed 1104 from an FA to an HA or Registration Replies sent from an FA to a MN. 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type | Length | Auth Type | reserved | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Foreign Agent (FA) Digital Signature | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 Type 33 1116 Length 4 plus the number of bytes in the digital 1117 signature. 1119 Auth Type 1120 Valid if the A bit set, in which case this field 1121 identifies the cryptographic method (algorithm) and key 1122 length used to generate digital signatures. Valid 1123 Authentication types are: 1125 Auth. Type Key Length Digital Signature 1126 Value Algorithm in bits Length in bytes 1127 --------- --------- ---------- ----------------- 1128 101 RSA 512 64 1129 102 RSA 1024 128 1131 Other Authentication types will be defined in the future. 1133 Digital Signature (variable length) (See Section 3.5.1.) 1135 3.5.4. Home Authentication Extension 1137 This Extension MUST be included in Registration Replies being passed 1138 from an HA to an FA. 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Type | Length | Auth Type | reserved | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Home Agent (HA) Digital Signature | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 Type 34 1150 Length 4 plus the number of bytes in the digital 1151 signature. 1153 Auth Type 1154 Valid if the A bit set, in which case this field 1155 identifies the cryptographic method (algorithm) and key 1156 length used to generate digital signatures. Valid 1157 Authentication types are: 1159 Auth. Type Key Length Digital Signature 1160 Value Algorithm in bits Length in bytes 1161 --------- --------- ---------- ----------------- 1162 101 RSA 512 64 1163 102 RSA 1024 128 1165 Other Authentication types will be defined in the future. 1167 Digital Signature (variable length) (See Section 3.5.1.) 1169 3.5.5 Correct Sequence of Extension. 1171 Mobile IP Extensions MUST occur in the following sequences. 1173 For Registration Request sent from MN to FA: 1175 Registration Request 1176 Mobile Authentication Extension 1177 Certificate Extension 1179 The digital signature in the Mobile Authentication Extension MUST 1180 be generated over all the fields in the Registration Request 1181 starting with the Type field (inclusively) and continuing through 1182 the fields of the Mobile Authentication Extension ending with the 1183 Auth Type field (inclusively) in the Mobile Authentication 1184 Extension. 1186 For Registration Request sent to HA from FA: 1188 UDP Header 1189 Registration Request 1190 Mobile Authentication Extension 1191 Foreign Authentication Extension 1192 Certificate Extension 1194 The digital signature in the Foreign Authentication Extension MUST 1195 be generated over all the fields in the Registration Request 1196 starting with the Type field (inclusively) and continuing through 1197 the fields of the Mobile Authentication Extension and the Foreign 1198 Authentication Extension ending with the Auth Type field 1199 (inclusively) in the Foreign Authentication Extension. 1201 For Registration Reply sent to FA from HA: 1203 UDP Header 1204 Registration Reply 1205 Home Authentication Extension 1206 Certificate Extension 1208 The digital signature in the Home Authentication Extension MUST be 1209 generated over all the fields in the Registration Reply starting 1210 with the Type field (inclusively) and continuing through the 1211 fields of the Home Authentication Extension ending with the Auth 1212 Type field (inclusively) in the Home Authentication Extension. 1214 For Registration Reply forwarded to MN from FA: 1216 UDP Header 1217 Registration Reply 1218 Home Authentication Extension 1219 Foreign Authentication Extension 1220 Certificate Extension 1222 The digital signature in the Foreign Authentication Extension MUST 1223 be generated over all the fields in the Registration Reply 1224 starting with the Type field (inclusively) and Home Authentication 1225 Extension through the fields of the Foreign Authentication 1226 Extension ending with the Auth Type field (inclusively) in the 1227 Foreign Authentication Extension. 1229 For Registration Reply sent to MN from FA: 1231 UDP Header 1232 Registration Reply 1233 Foreign Authentication Extension 1234 Certificate Extension 1236 The digital signature in the Foreign Authentication Extension MUST 1237 be generated over all the fields in the Registration Reply 1238 starting with the Type field (inclusively) and continuing through 1239 the fields of the Foreign Authentication Extension ending with the 1240 Auth Type field (inclusively) in the Foreign Authentication 1241 Extension. 1243 4. Certificates 1245 All Certificates used with Mobile IP MUST include the following 1246 Fields: 1248 Distinguished Name - The Distinguished Name (DN) is the sender's 1249 IP address in dot-decimal notation 1250 (aaaa.bbb.ccc.ddd). The use of this field is 1251 a variation of the DN approach defined in 1252 [X.500] given that the identity that needs to 1253 be verified, and bound to a specific public 1254 key, is the IP address of the network 1255 interface the MN, FA or HA uses in the 1256 context of PKA Mobile IP. 1258 Not Valid Before Date - Not Valid Before Date (NVBD) is that date 1259 prior to which the Certificate is not 1260 valid 1262 Not Valid After Date - Not Valid After Date (NVAD) is that date 1263 After which the Certificate is not valid 1265 CA Distinguished Name - The CA Distinguished Name (DN) is as 1266 defined in [X.500] 1268 Subject Public Key - Subject Public Key is the binary string of 1269 Octets containing the public key of the 1270 sender 1272 Public Key Algorithm - Public Key Algorithm is the field that 1273 Identifies the type of public key algorithm 1274 the sender's public key must be used with 1276 Public Key Size - Public Key Size is the field that identifies 1277 the size of the sender's public key in octets 1279 CA Digital Signature - CA Digital Signature is the digital 1280 Signature generated by the sender's CA that 1281 binds the other fields of the Certificate 1282 together cryptocraphicly 1284 Certificate Serial Number - A unique number assigned to a 1285 Certificate by the CA that creates and 1286 digitally signs the Certificate. This 1287 serial number is used to positively 1288 identify the Certificate 1290 5. Trust Hierarchy Paths 1292 A Trust Hierarchy Path is the establishment of a logical chain 1293 between two Certificate Authorities (CAs) and reflects a trust 1294 relationship that can be established through intervening CAs. 1295 Validation of a Certificate involves constructing a Trust Hierarchy 1296 Path between the sender Certificate, the CA that issued the sender 1297 Certificate and the CA of the validating system. The validity 1298 interval for every Certificate in this path must be checked. 1299 Establishing a trust hierarchy path MUST be performed to verify the 1300 authenticity and usability of Certificates within Mobile IP. 1302 This process assumes that the receiver knows the public key of the 1303 Sender's CA. The receiver can develop trust in the public key of the 1304 Sender's CA recursively, if the receiver has a Certificate containing 1305 the CA's public key signed by a superior CA whom the receiver already 1306 trusts. In this sense, a certificate is a stepping stone in digital 1307 trust. Each certificate is processed in turn, starting with that 1308 signed using the input trusted public key. 1310 The following checks are applied to all Certificates: 1311 - Check that the signature verifies 1312 - That dates are valid 1313 - The subject and issuer names chain correctly 1314 - The certificate has not been revoked. 1315 If any of the above checks fails, the procedure terminates, returning 1316 a failure indication. If none of the above checks fail on each 1317 Certificate, the procedure terminates successfully. 1319 6. Certificate Revocation Lists 1321 Each digital certificate should be checked against the current 1322 Certificate Revocation List (CRL) from the issuing CA to ensure that 1323 revoked Certificate are not employed. PKA Mobile IP recognizes that 1324 network performance could be seriously degraded if a receiving node 1325 always retrieves the most recent CRL when ever a new Certificate is 1326 received. Consequently, a node (be it an MN, FA or HA) should cache 1327 received Certificates along with a value ("staleness value") that 1328 indicates the last time each Certificate was checked against a CRL 1329 from the issuing CA. The node should also provide a value that 1330 indicates the maximum degree ("staleness threshold") of Certificate 1331 staleness a given node may tolerate before the node has to retrieve 1332 the appropriate CRL and verify that the Certificate has not been 1333 revoked. 1335 This staleness checking function is a compromise between the effect 1336 on available bandwidth vs. the risk of using a revoked Certificate. 1337 In those cases where the node has high network bandwidth available 1338 (usually FAs and HAs), via wired network attachments, then the 1339 staleness threshold should be set to a relatively low value (eg. 10 1340 seconds). Where the node has less than good network bandwidth 1341 available (usually MNs) via wireless network attachments then the 1342 staleness threshold should be set to a higher value (eg. 10 minutes). 1344 7. Security Considerations 1346 Those implementations of Mobile IP which do not include 1347 authentication Between the MN and the FA run the risk of denial of 1348 service attacks. MIPv4 relies on the use of the Address Resolution 1349 Protocol (ARP), which does not provide any authentication, for 1350 intercepting packets destined for a traveling MN. Any wireless Home 1351 network is consequently vulnerable to MN traffic stealing by having a 1352 hostile node on the wireless network issue ARP messages which cause 1353 these packets to be sent to a destination other than an MN, when at 1354 home, or the MN's HA when the MN is on the road. Ideally the ARP 1355 protocol should include authentication but this would require 1356 significant changes to the currently deployed protocol. 1358 Staleness of Certificates and frequency for Certification Revocation 1359 List retrieval is a trade-off between exposure and potential 1360 threat resulting in a degree of risk from a revoked Certificate. By 1361 having implementations of PKA Mobile IP provide a user tunable 1362 staleness threshold the degree of risk becomes a user managed 1363 function. 1365 A. Patent Issues 1367 As of the time of publication, there exists a patent that is 1368 relevant to implementers of the Protocol extensions described 1369 herein: 1371 A.1. Massachusetts Institute of Technology Patent #4405829 1373 Ronald L. Rivest, Adi Shamir, Leonard M. Adleman are the 1374 co-inventors of U.S. Patent No. 4405829, assigned to the 1375 Massachusetts Institute of Technology (MIT). The patent was filed 1376 December 14, 1977 and will expire on December 15, 1999, at which 1377 time the technology covered by the patent reverts to the public 1378 domain. 1380 Furthermore the US Government has rights to this technology pursuant 1381 to Contract No. N00014-67-A-0204, awarded to the Department of the 1382 Navy, and Grant No. MCS76-14249, awarded by the National Science 1383 Foundation. 1385 Should implementers wish to immediately proceed with implementing 1386 commercial versions of PKA Mobile IP they may obtain a license from 1387 RSA Data Securities Inc. for use of the RSA asymmetric public key 1388 algorithm. 1390 This statement is for the IETF's assistance in its standard-setting 1391 procedure, and should not be relied upon by any party as an opinion 1392 or guarantee that any implementation it might make or use would not 1393 be covered by the MIT Patent and any other patents. 1395 References 1397 [Diffie76] Diffie, W., Hellman, M. E., "New directions in 1398 cryptography", IEEE Transactions on Information Theory, 1399 IT-22(6):644--654, November 1976. 1401 [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm", 1402 April 1992. 1404 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992. 1406 [RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic 1407 Mail: Part II: Certificate-Based Key Management", 1408 February 1993 1410 [RFC1541] Droms, R., "Dynamic Host Configuration Protocol", 1411 October 1993 1413 [RFC2002] Perkins, C., editor, "IP mobility support", October 1996. 1415 [RSA78] Rivest, R.L., Shamir, A., Adleman, L., "A method for 1416 obtaining digital signatures and public-key cryptosystems", 1417 Communications of the ACM, 21(2):120-126, February 1978. 1419 [Schneier96] Schneier, B., "Applied Cryptography 2nd Edition", 1420 Chapter 22 pp. 513-514, John Wiley & Sons Inc., 1996 1422 [X.500] "CCITT. Recommendation X.500: The Directory-Overview of 1423 Concepts, Models and Services", 1988 1425 [X.509] "CCITT. Recommendation X.509: The Directory-Authentication 1426 Framework", 1988. 1428 Authors' Address 1430 Questions about this memo can also be directed to: 1432 Stuart Jacobs 1433 Network Security Department 1434 GTE Laboratories, 1435 40 Sylvan Road, 1436 Waltham, MA 02454, USA. 1437 Phone: 781-466-3076 1438 Fax: 781-466-2838 1439 Email: sjacobs@gte.com