idnits 2.17.1 draft-ietf-mobileip-ra-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 9) being 59 lines 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 are 58 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 21, 1997) is 9651 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 2119' is mentioned on line 149, but not defined == Unused Reference: 'RFC2119' is defined on line 1118, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'Riv92') ** Obsolete normative reference: RFC 2002 (ref. 'Perk96') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1510 (ref. 'Kohl93') (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'MOIPS97' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Luis A. Sanchez 2 Internet Draft Gregory D. Troxel 3 Expire in six months BBN Technologies 4 November 21, 1997 6 Rapid Authentication for Mobile IP 7 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Copyright (C) The Internet Society (November 1997). All Rights 29 Reserved. 31 Abstract 33 This document describes a mechanism that provides Mobile IP nodes 34 and agents with the necessary keys and information 35 needed to establish mobility security associations within a 36 foreign network. This mechanism aims at reducing the latency and 37 computational burden introduced by public-key based key management 38 protocols in network topologies where visiting mobile nodes register 39 with their respective home agents several times through different 40 foreign agents requiring Mobile-Foreign Authentication. This 41 mechanism employs a key distribution center capable of generating 42 the security contexts needed to authenticate Mobile IP control 43 messages. This mechanism, designed as an extension to the Mobile IP 44 protocol, preservs backward compatibility and interoperability with 45 RFC2002 compliant implementations of Mobile IP. 47 Table of Contents 49 1.0 Introduction 50 1.1 Requirements Terminology 51 1.2 Technical Definitions 52 2.0 Rapid Authentication Overview 53 3.0 Conventional Mobility Security Association (CMSA) 54 4.0 Rapid Authentication Extensions for Mobile IP 55 4.1 Authentication Extensions 56 4.2 Agent Advertisement Extension 57 5.0 Rapid Authentication Control Messages for Mobile IP 58 5.1 Request Message (RA-Req) 59 5.2 Reply Message (RA-Rep) 60 5.3 Distribution Message (RA-Dist) 61 5.4 Distribution Acknowledgment Message (RA-Dist-Ack) 62 5.5 Rapid Authentication Message Generation 63 6.0 Rapid Authentication Payload Processing 64 6.1 RA-Req Processing 65 6.2 RA-Rep Processing 66 6.3 RA-Dist Processing 67 6.4 RA-Dist-Ack Processing 68 7.0 Agent Advertisement Processing 69 8.0 Performance Considerations 70 Acknowledgments 71 References 72 Disclaimer 73 Author Information 75 1.0 Introduction 77 The Mobile IP protocol as described in RFC2002 relies on control 78 messages transmitted from mobile hosts to establish IP tunnels. These 79 tunnels provide the mechanism needed to redirect traffic addressed to 80 the mobile host using an IP address associated with its current 81 topological location. This new feature would be a security 82 vulnerability if request messages sent by hosts masquerading as 83 authorized hosts were honored without cryptographically verifying the 84 authenticity of such messages. This vulnerability has been identified 85 as a security problem in the Internet today[Bel89]. In order to avoid 86 such security problems, Mobile IP requires that all request messages 87 transmitted by a Mobile Node (MN) to a Home Agent (HA) be 88 authenticated using a message authentication code. The default 89 mechanism uses the keyed-MD5 algorithm [Riv92] in preffix+suffix mode 90 with a key size of 128 bits. 92 Mobile Node to Home Agent authentication is not the only case where 93 authentication is useful. For instance, an MN might want to verify 94 that a Foreign Agent (FA) is trustworthy before authenticating a 95 request to the HA to bind the MN's address to the Care-of Address 96 (COA) given by that particular FA. Another possibility is for the FA 97 to be able to choose to provide or decline service to the MN based 98 upon some policy; the MN must be able to authenticate requests to the 99 FA for this to be possible with authentication-based access control. 100 Another scenario where authentication might be useful is when the FA 101 wishes the HA to authenticate itself to the FA in order to avoid 102 denial-of-service (DoS) attacks by an attacker injecting false binding 103 rejections claiming to be from the HA. In all these cases the use of 104 keyed-MD5 or other MAC algorithms to authenticate registration and 105 reply messages is sufficient to establish the authenticity of the 106 messages exchanged between FAs and MNs. 108 Mobile IP does not mandate a protocol to establish the security 109 contexts (shared key, authentication algorithm, type of replay 110 protection, etc.) between a pair of nodes. It is the collection of 111 these security contexts that encompases a Mobilility Security 112 Association [Perk96]. Mobile Agents and nodes establish pairwise 113 Mobility Security Associations (MSA) manually using shared secrets 114 previously agreed upon. Manual configurations don't scale, making 115 this authentication scheme a management nightmare even for small size 116 networks. Using a key management protocol such as ISAKMP provides the 117 scalability and flexibility needed when establishing security 118 associations with a performance cost. For example, consider an MN 119 which has been unregistered for a long time contacting a foreign agent 120 in some domain where there are multiple FAs. This will likely require 121 some certificate fetches and public-key operations to validate and 122 perform a key exchange. If the MN has not recently registered with 123 any foreign agents, this is acceptable. However, we would like to 124 avoid this burden when the MN moves to another FA in the same domain. 125 Regardless of the reason for an MSA to be present between an MN and an 126 FA or an FA and an HA, it is desirable for these MSAs to be created 127 quickly for subsequent authentications. 129 Rapid Authentication (RA) is a mechanism that allows the establishment 130 of Mobility Security Associations between mobile nodes and agents in a 131 particular foreign domain without using any public key operations, 132 generating multiple round trips, or key lookups that leave the foreign 133 domain. Rapid Authentication uses a key exchange approach with 134 symmetric cryptography, to distribute the keying material needed to 135 authenticate Mobile IP control messages among mobility agents and 136 nodes while in a foreign domain. Rapid Authentication is designed to 137 be a compatible extension to the standards-track Mobile IP protocols, 138 so that if a host does not implement RA, interoperability will not be 139 impaired. This document assumes that there is some mechanism for MSA 140 creation between mobility entities and the Key Distribution Center. 142 In order to understand this document, the reader should be thoroughly 143 familiar with most of RFC2002. 145 1.1 Requirement Terminology 147 In this document, the words that are used to define the significance 148 of each particular requirement are usually capitalized. These words 149 are defined in [RFC 2119] and are inlcuded in this document for 150 completeness. These key words are: 152 - MUST 154 This word or the adjective "REQUIRED" means that implementation of 155 the item is an absolute requirement of the specification. 157 - SHOULD 159 This word or the adjective "RECOMMENDED" means that there might 160 exist valid reasons in particular circumstances to not implement 161 this item, but the full implications should be understood and the 162 case carefully weighed before not implementing this or not 163 implementing it in a conforming manner. 165 - MAY 167 This word or the adjective "OPTIONAL" means that implementation of 168 this item is truly optional. One vendor might choose to include 169 the item because particular buyers require it or it enhances the 170 product, while another vendor may omit the same item. 172 1.2 Technical Definitions 174 This section provides definition of terms applicable to Rapid 175 Authentication. 177 Mobility Security Association 179 A Mobility Security Association (MSA) denotes the association 180 between a pair of nodes (nodes A and B) by a collection of 181 security contexts comprised of the identities of the nodes, 182 SPI values by which each locates the MSA, authentication 183 algorithm and mode, authentication key, and style of replay 184 protection. 186 Conventional Mobility Security Association 188 A Conventional Mobility Security Association (CMSA) denotes 189 the association between a pair of nodes (nodes A and B) by a 190 collection of security contexts comprised of the identities of 191 the nodes, SPI values by which each locates the CMSA, 192 an authentication algorithm and mode, an encryption algorithm 193 and mode, an authentication key, an key-encrypting key, a 194 style of replay protection and expiration time. 196 Rapid Mobility Security Association 198 A Rapid Mobility Security Association (RMSA) denotes the 199 association between a pair of nodes (nodes A and B) by a 200 collection of security contexts comprised of the identities of 201 the nodes, SPI values by which each locates the RMSA, the 202 identity of the party that functioned as the RKDC, 203 the authentication algorithm and mode, the authentication key, 204 the style of replay protection and the expiration time. 206 Rapid Key Distribution Center 208 A host functioning as Key Distribution Center for Rapid 209 Authentication in Mobile IP. RKDCs generate keys, SPIs and 210 other related information required to establish a Mobility 211 Security Association between Mobile Agents and Mobile Nodes. 212 Foreign Agents serve as RKDCs. 214 2.0 Rapid Authentication Overview 216 Rapid Authentication (RA) is a mechanism that allows establishment of 217 MSAs between the mobile nodes and agents in a particular foreign 218 domain without using any public key operations, generating multiple 219 round trips, or key lookups that leave the foreign domain. The 220 central idea of Rapid Authentication is to allow Foreign Agents to 221 function as a Kerberos-style [Kohl93] Key Distribution Centers 222 (KDC). These Foreign Agents are capable of creating the security 223 contexts that Mobile Nodes and Agents require in order to generate 224 Mobility Security Associations among themselves. Foreign Agents 225 supporting Rapid Authentication and functioning as key distribution 226 centers are known as Rapid Key Distribution Centers or RKDCs. In order 227 for this mechanism to work, security associations must exist between 228 the RKDC and the Mobile Node requesting Rapid authentication, the RKDC 229 and the Home Agent of the Mobile Node and between the RKDC and the 230 nearby Foreign Agent. These security associations, also known as 231 Conventional Mobile Security Associations (CMSA), include among other 232 security contexts, a key encrypting key and an authentication 233 key. RKDCs use the key encrypting keys to encrypt the authentication 234 keys required by both mobile nodes and agents to authenticate Mobile 235 IP control messages. These security associations could be in place a 236 priori (before a Mobile Node requests Rapid Authentication) or be 237 established as a result of a request message sent from a Mobile Node 238 to an RKDC. CMSAs could be created manually, via ISAKMP/Oakley, 239 ZmKeyGen [MOIPS97] or some other key management mechanism. 241 Rapid Authentication introduces four new Mobile IP control messages: 243 1) RA-Req 244 2) RA-Rep 245 3) RA-Dist 246 4) RA-Dist-Ack 248 All RA control messages follow the same format: a Rapid Authentication 249 header, Rapid Authentication data and an authentication extension. The 250 RA header is common to all messages and it includes among other 251 fields: the home IP address of the Mobile Node requesting RA, the IP 252 address of the target Foreign Agent, the IP address of RKDC and an 253 Identification Field to be used for anti-replay protection. The 254 authentication extensions provide authentication and integrity for 255 the RA control messages exchanged among nodes and agents. 257 The Rapid Authentication process begins with the RA-Req message. The 258 RA data in this message indicates the authentication algorithm and the 259 length of the key required by the Mobile Node. The RA-Rep messages do 260 not contain RA data. RKDCs use this message to indicate to Mobile 261 Nodes the status of their requests. RKDCs employ RA-Dist messages to 262 distribute the security contexts needed to create MSAs among nodes and 263 agents. These contexts include SPI values, Key Lifetime, 264 Authentication Key, etc. RA-Dist messages are acknowledge by their 265 recipient using the RA-Dist-Ack message. Like the RA-Rep message, the 266 RA-Dist-Ack message does not contain RA data and is used by nodes and 267 agents to indicate RKDCs the status of a particular RA-Dist message 268 received. Rapid Authentication also introduces a new Agent 269 Advertisement extension to provide advertisement of RA support by 270 Foreign Agents. This extension allows Foreign Agents to advertise 271 whether or not they are functioning as RKDCs since it is possible that 272 FAs supporting RA MAY not function as RKDCs for administrative 273 reasons. This extension also allows Foreign Agents to announce the 274 list of RKDCs for which they have valid CMSA enabling Mobile Nodes to 275 request RA with a target Foreign Agent via their common RKDC. 277 Rapid Authentication operates in two modes: direct and target mode. 278 In direct mode operation, Mobile Nodes have IP connectivity with the 279 RKDC. In target mode operation, Mobile Nodes do not have IP 280 connectivity with RKDCs, only link connectivity. In this mode, Mobile 281 Nodes send RA-Req messages via Foreign Agents for which they have link 282 layer connectivity. Foreign Agents supporting RA forward these request 283 messages to the appropriate RKDC. The basic Rapid Authentication 284 operation is straight forward. Mobile Nodes send RA-Req messages to 285 RKDCs. The request messages come directly from the Mobile Node (direct 286 mode operation) or get forwarded by a Foreign Agent (target mode 287 operation). RKDCs send RA-Rep messages indicating whether or not they 288 can generate the security contexts required for the mobile nodes and 289 agents to establish MSAs among themselves. In target mode operation, 290 RKDCs send reply messages to the Mobile Nodes via Foreign 291 Agents. RKDCs verify if they have CMSAs established with both the 292 Mobile Node and the target Foreign Agent. If so established, the RKDC 293 creates SPIs, authentication keys and all other required 294 information. The RKDC encrypts the authentication keys using the 295 default encryption algorithm, DES with 56-bit keys. RKDCs generate 296 RA-Dist messages containing the SPIs, algorithm information, 297 authentication keys, etc. and transmit them to the mobile nodes and 298 agents. All nodes and agents receive one message containing the SPI 299 values that they will use to identify the MSAs. Since the MSAs are 300 simplex, each nodes receives two SPIs, one for outgoing and one for 301 incoming traffic for that communication. Foreign Agents however, 302 receive two sets of SPI values (a total of four); two for identifying 303 the MSA between the Foreign Agent and the Home Agent and two for 304 identifying the MSA between the Foreign Agent and the Mobile 305 Node. Once both the mobile nodes and agents receive the RA-Dist 306 messages and the mobility security associations are established, they 307 reply to the RKDCs by transmitting RA-Dist-Ack messages indicating the 308 status of the transaction. Upon reception of a RA-Dist-Ack message 309 reporting good status, RKDCs destroy all keying information and clear 310 all states. 312 3.0 CMSA Generation 314 We will assume that two FAs are capable of creating a security 315 association with each other for use in the Rapid Mobility protocol. 316 This association, known as a CMSA, includes an authentication key, a 317 key-encrypting key, type of replay protection, encryption and 318 authentication algorithm identifiers, SPI values and expiration times. 319 CMSAs could be created manually, via ISAKMP/Oakley, ZmKeyGen [MOIPS97] 320 or some other mechanism. The KEK is used to encrypt the keying 321 material generated at the RKDCs before is sent to the final 322 destination. The destination uses the corresponding KEK to decrypt 323 the keying material. A possible scheme for generating CMSAs will be 324 defined in a separate document. 326 4.0 New Mobile IP Extensions 328 4.1 Authentication Extensions 330 RA introduces three new Mobile IP extensions to provide authentication 331 to control messages exchanged between mobile nodes and agents with 332 RKDCs as specified below. 334 Type Authentication 335 Value Extension 337 129 Mobile-RKDC Authentication 338 130 Foreign-RKDC Authentication Extension 339 131 Home-RKDC Authentication Extension 341 These extensions follow the same format used in other Mobile IP 342 authentication extensions. The extension format is depicted below for 343 reference. 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | SPI .... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 ... SPI (cont.) | Authenticator ... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Type 129,130,or 131. 355 Length 4-octets plus the number of octets in the 356 Authenticator. 358 SPI Security Parameter Index is a 4-octet field with 359 an arbitrary value that combined with a 360 destination IP address identifies a security 361 association. 363 Authenticator This is a variable length field that depends upon 364 the algorithm used. Default authentication 365 algorithm is keyed-MD5 in prefix+suffix 366 mode. This algorithm produces a 16-octet value. 368 The Mobile-RKDC Authentication Extension MUST be present in all 369 RA control messages exchanged between Mobile Nodes and RKDCs. The 370 Foreign-RKDC Authentication Extension MUST be present in all RA control 371 messages exchanged between Foreign Agents and RKDCs. The Home-RKDC 372 Authentication Extension MUST be present in all RA control messages 373 exchanged between RKDCs and HAs. 375 4.2 Agent Advertisement Extensions 377 RA also introduces one new Mobile IP extension to provide 378 advertisement of RA support by FAs. The RA Advertisement Extension 379 follows the exact same format used in other Mobile IP extensions. The 380 extension format is depicted below. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length |R| Reserved | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 ... RKDC Addresses..... 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Type 132 391 Length 2-octets plus 4*N where N is the number of RKDC 392 addresses. 394 R Indicates whether or not this FA functions 395 as an RKDC. 397 Reserved Available for future use and expansion. This 398 field is sent as zero and ignored at the 399 receiving end. 401 RKDC Address A variable length field containing the IP 402 address(es) of other RKDCs for which this FA has 403 a CMSA. 405 FAs supporting RA SHOULD append this extension to their agent 406 advertisement. The R bit is set to 1 to indicate that the FAs 407 sending this advertisement are also functioning as RKDCs. This 408 extension enables MNs to request RA with the Target via their common 409 RKDC. This extension can only be used with ICMP router discovery 410 messages. Note that an MN MAY request RA with a Target even if they 411 don't share a common RKDC. 413 5.0 Rapid Authentication Control Message Format 415 RA defines a set of new control messages with the following format: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 420 | Type | Code | Lifetime | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 422 | Requestor Address | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 424 | Target Address | RA 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 426 | RKDC Address | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 428 | | | 429 + Identification + | 430 | | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 432 | RA Data ... 433 +-+-+-+-+-+-+-+- 434 | Extensions ... 435 +-+-+-+-+-+-+-+- 437 Type 438 A 1-octet field indicating the RA control message type. See 439 below for a list of currently defined code values. 441 Type Message 442 Value Type 444 04 RA-Req 445 05 RA-Rep 446 06 RA-Dist 447 07 RA-Dist-Ack 449 Code 450 A value indicating specific control information for each RA 451 message. 453 Lifetime 455 A 2-octet field indicating the number of seconds remaining 456 before the association is considered expired. A value of 457 0xffff indicates infinity. 459 Requestor Address 461 The home address of the MN requesting RA. Only MNs MAY 462 request RA. 464 Target Address 466 A 4-octet field containing the IP address of the Foreign Agent 467 that the MN wishes to establish a RMSA with. 469 RKDC Address 471 A 4-octet field containing the IP address of the host acting 472 as RKDC for a particular RMSA. 474 Identification 476 This 8-octet field contains a random value (nonce) or a 477 timestamp used for protecting against replay attacks. This 478 field is similar to the identification field found in Mobile 479 IP Registration messages. See section 9.0 for a detailed 480 a description. 482 RA Data 484 The RA data is of variable length and depends on the RA 485 message type. 487 Extensions 489 Any of the following Mobile IP control message extensions may 490 appear in RA control messages: 492 Sanchez, Troxel [Page10] 493 Extension Extension 494 Number Type 496 129 Mobile-RKDC Authentication 497 130 Foreign-RKDC Authentication 498 131 Home-RKDC Authentication 500 5.1 Request Message (RA-Req) 502 The RA-Req message is comprised of the RA header, RA data and 503 appropriate extension. The RA-Req type value is 04. The following 504 values are defined for use within the code field: 506 Code Request 507 Field Type 509 01 Direct Mode Request 510 02 Target Mode Request 512 The RA data for the RA-Req message includes a 4-octet field containing 513 the requestor's key information required by the RKDC to generate the 514 appropriate keying material. This information includes the 515 authentication algorithms requested and the size of authentication key 516 as specified below. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Authentication Algorithm | Authentication Key Length | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Authentication Algorithm 526 This 2-octet field indicates a specific algorithm. The value 527 1 indicates MD5 as per RFC2002. All hosts implementing RA 528 MUST implement this algorithm. Values from 64000-64999 are 529 reserved for private use, and values 65000-65535 are 530 experimental. 532 Authentication Key Length 534 This 2-octet field specifies the size in bits of the 535 authentication key the requestor is asking the RKDC to 536 generate. A value of 0 means "do not generate key." 538 5.2 Reply Message (RA-Rep) 540 The RA-Rep message is comprised of the RA header and appropriate 541 authentication extension. Reply messages DO NOT contain RA Data. The 542 RA-Rep type value is 05. The following values are defined for use 543 within the code field: 545 Sanchez, Troxel [Page11] 546 Code Action 547 Field Type 549 01 request accepted 550 02 denied, no CMSA with target 551 03 denied, administratively prohibited 552 04 denied, insufficient resources 553 05 denied, failed authentication 554 06 denied, requested Lifetime too long 555 07 denied, reason unspecified 556 08 denied, request mode mismatch 557 09 denied, identification field mismatch 559 5.3 Distribution Message (RA-Dist) 561 The RA-Dist message is comprised of the RA header, RA data and 562 appropriate authentication extension. The RA-Dist type value is 563 06. The following values are defined for use within the code field: 565 Code Action 566 Field Type 568 01 Direct Mode Distribution 569 02 Target Mode Distribution 571 The RA data has the following format: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Security Parameters Index A (SPIA) | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Security Parameters Index B (SPIB) | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Authentication Key Lifetime | Authentication Key Life Type | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Authentication Algorithm | Authentication Payload Length | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 584 | | | 585 + +Encrypt 586 | | | 587 + Authentication Key Payload (variable length) + w/ 588 | | | 589 + + KEK 590 | | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 593 Sanchez, Troxel [Page12] 595 SPIA 597 The Security Parameter Index A is a 4-octet field with an 598 arbitrary value that identifies either the security association 599 between the target and the requestor, the target and the 600 requestor's home agent or the home agent and the requestor, as 601 specified by the code field. 603 SPIB 605 The Security Parameter Index B is a 4-octet field with an 606 arbitrary value that identifies either the security association 607 between the requestor and the target, the requestor's home agent 608 and the target or the requestor and the home agent, as specified 609 by the code field. 611 Authentication Key Lifetime 613 A 2-octet field that specifies the time to live of this key. 614 The value could be in units of seconds or kilobytes. 616 Authentication Key Life Type 618 A 2-octet field that indicates if the Authentication Key 619 Lifetime field is in units of seconds (value= 0x0001) or 620 kilobytes(value= 0x0002) 622 Authentication Algorithm 624 This 2-octet field that indicates the authentication algorithm 625 in used. Default algorithm is keyed-MD5 in "prefix+suffix" 626 mode. The code value is 0x0001. 628 Authentication Payload Length 630 A 2-octet field that specifies in octets the length of the 631 Authentication Key Payload field. 633 Authentication Key Payload 635 A variable length field containing the key to be used to 636 authenticate Mobile IP messages exchanged between mobile nodes 637 and mobile agents. This field includes Initialization 638 Vectors(IVs), required padding and is encrypted with the 639 appropriate Key Encryption Key (KEK) using the encryption 640 algorithm negotiated during the establishment of the CMSA. The 641 default encryption algorithm is DES with 56 bit keys. The value 642 in the Authentication Payload Length field indicates the length 643 of this field. 645 Sanchez, Troxel [Page13] 647 RA-Dist messages for FAs contain the RA header, two RA data sets and 648 the appropriate authentication extension. They differ from RA-Dist 649 messages destined to MNs or HAs in that instead of containing one RA 650 Data set, these messages carry two sets of RA data. One RA data set is 651 for configuring the mobility security association between the home 652 agent and the foreign agent and the other is for configuring the mobile 653 security association between the mobile node and the foreign 654 agent. The RA-Dist message for FAs has the following format: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | RA-Dist Message Header | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | RA Data for HA-FA... 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | RA Data for MN-FA... 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | RKDC-FA Authentication Extension... 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 In RA-Dist messages destined for FAs, the RA Data format for both 669 HA-FA and MN-FA mobility security associations follows the general RA 670 Data format specified earlier in this section. The authentication key 671 payload in both RA data sets is encrypted with the same KEK. The CMSA 672 between the RKDC and the FA specifies the appropriate KEK to be used 673 to encrypt the payload. The RA-Dist message format for FA is the same 674 regardless of whether the RA-Req message is in direct or target mode. 676 5.4 Distribution Acknowledgment Message (RA-Dist-Ack) 678 The RA-Dist-Ack message is comprised of the RA header and appropriate 679 authentication extension. Distribution messages DO NOT contain RA 680 Data. The RA-Dist-Ack type value is 07. The following values are 681 defined for use within the code field: 683 Code Action 684 Field Type 686 01 Received Direct Mode Distribution Message 687 02 Received Target Mode Distribution Message 688 03 denied, identification field mismatch 689 04 Encryption Failure 690 05 Invalid SPI 691 06 Authentication Failure 693 5.5 Rapid Authentication Message Generation 695 Mobile Nodes holding a valid CMSA with at least one RKDC MAY send 696 RA-Req messages. A Mobile Node supporting RA SHOULD request RA with a 697 particular FA upon receipt of an agent advertisement from that FA or 699 Sanchez, Troxel [Page14] 701 loss of binding with the original FA combined with agent advertisement 702 from a new FA. In both cases, the foreign agent advertisement 703 received at the MN MUST have the RA Advertisement extension in order 704 for a Mobile Node to request RA. The extension indicates support for 705 RA. See section 4.2 for details about RA advertisements. 707 FAs MAY forward RA-Rep messages to MNs. However, only RKDCs MAY send 708 RA-Rep messages. RKDCs MUST respond to all RA-Req messages by sending 709 a RA-Rep with the appropriate code field. Only RKDCs MAY send RA-Dist 710 messages. In response to each valid RA-Req message the RKDC sends a 711 RA-Rep message to the requestor (MN), creates RMSAs for those entities 712 for which it has CMSAs with and, transmits RA-Dist messages to the 713 agents and nodes. 715 RKDCs transmit three RA-Dist messages; one to the MN, one to the HA 716 and one to the FA. The RA-Dist messages for the MNs and HAs contain 717 only one RA data set per message. However, the RA-Dist messages for FA 718 contain two RA data sets per message. One RA data set for the HA-FA 719 mobility security association and one for the MN-FA mobility security 720 association. Section 5.3 specifies the format for the RA-Dist messages 721 destined to foreign agents. 723 Mobile Nodes and Agents MAY send RA-Dist-Ack messages. FAs SHOULD 724 forward RA-Dist-Ack messages to MNs. MNs, FAs and HAs MUST respond to 725 all RA-Dist messages addressed to them by sending a RA-Dist-Ack with 726 the appropriate code field. 728 6.0 Rapid Authentication Payload Processing 730 For RA-Req or RA-Dist control messages, the transmitting entity MUST 731 do the following: 733 1. Set a timer and initialize a retry counter. 734 2. If an RA-Rep or RA-Dist-Ack message corresponding to the 735 appropriate RA-Req or RA-Dist message is received within the time 736 interval or before the RETRY LIMIT is reached, the transmitting 737 entity continues normal operation. 738 3. If an RA-Rep or RA-Dist-Ack message corresponding to the 739 appropriate RA-Req or RA-Dist message is not received within a 740 time interval, the control message is resent and the retry counter 741 is decremented. 742 4. If the retry counter reaches zero (0) (i.e. RETRY LIMIT is set) 743 the event should be logged in the appropriate system audit file. 744 5. At this point, Mobile Nodes transmitting RA-Req messages will clear 745 RA state for this peer and fall back to conventional 746 authentication setup using ISAKMP/Oakley or the MOIPS ZmKeyGen. 747 RKDCs transmitting RA-Dist messages will clear RA state for the 748 pending RMSA (and therefore take no further action unless another 749 message is received). 751 Sanchez, Troxel [Page15] 753 6.1 RA-Req Processing 755 When creating a RA-Req message, the MN MUST do the following: 757 1. Set the value of the type field to 04 758 2. Determine the appropriate code field 759 a) Set the value of the code field to 01 if the RKDC is the current 760 FA (direct mode) 761 b) Set the value of the code field to 02 otherwise. The MN sends 762 the RMSA request to the target FA which in turn forwards the 763 request to the RKDC (target mode) 764 3. Set the association lifetime 765 4. Set the Requestor Address to IP home address of the MN 766 5. Set the Target Address to the FA's IP address found in the care of 767 address field of the agent advertisement message 768 6. Set the RKDC Address. The MN SHOULD have a valid CMSA with this 769 RKDC. 770 7. Place the identification value used for anti-replay attack 771 protection 772 8. Construct the RA data payload 773 9. Calculate an integrity check value over the RA header, RA data, 774 and the type, length and SPI fields of the authentication 775 extension using the authentication key created during the 776 establishment of the CMSA with that RKDC 778 When an FA receives a RA-Req message it MUST do the following: 780 1) Check the code field. 782 If the value is 01 (Direct Mode Request) then: 783 a) Check the RKDC field 784 b) If the FA is the intended RKDC, it verifies the MN-RKDC 785 authenticator. 786 If validation succeeds: 787 - check identification field for anti-replay protection. If 788 a replayed message is detected: 789 - discard message 790 - send RA-Rep message with with appropriate code field (09) 791 - the event MAY be logged 792 If the message is original(not a replayed message): 793 - the FA sends a reply message with code field 01 794 - construct and transmit RA Distribution messages as 795 specified in section 6.3 796 If validation fails: 797 - the FA sends a reply message with code field 05 798 - the event MAY be logged 799 c) If the FA is NOT the intended RKDC the FA sends a reply 800 message with code field 08 802 If the value is 02 (Target Mode Request) then: 803 a) Check the RKDC field 805 Sanchez, Troxel [Page16] 807 b) If the FA is NOT the intended RKDC the FA forwards the RA-Req 808 to the the address found in the RKDC field 809 c) If the RKDC field contains the address of the FA, it verifies 810 the MN-RKDC authenticator 811 If validation succeeds: 812 - check identification field for anti-replay protection. If 813 a replayed message is detected: 814 - discard message 815 - send RA-Rep message with with appropriate code field(09) 816 - the event MAY be logged 817 If the message is original(not a replayed message): 818 - the FA sends a reply message with code field 01 819 - construct and transmit RA Distribution messages as 820 specified in section 6.3 821 If validation fails: 822 - the FA sends a reply message with code field 05 823 - the event MAY be logged 825 6.2 RA-Rep Processing 827 When creating a RA-Rep message the transmitting entity MUST do the 828 following: 830 1. Set the value of the type field to 05 831 2. Determine the appropriate code field as specified in section 5.2 832 3. Set the values for the Lifetime, Requestor Address, Target 833 Address, and RKDC fields to the values found in the corresponding 834 RA-Req message 835 4. Set the identification value used for anti-replay attack 836 protection 837 5. Calculate an integrity check value over the RA header, RA data, 838 and the type, length and SPI fields of the authentication 839 extension using the authentication key created during the 840 establishment of the CMSA with that entity 841 6. Append the appropriate authentication extension to the reply 842 message 844 When an MN receives a RA-Rep message it MUST do the following: 846 1. Verify the authenticator 847 If validation fails: 848 - the message is silently discarded and the event MAY be logged 849 2. Check identification field for AR protection. If a replayed 850 message is detected it is silently discarded and the event MAY be 851 logged 852 3. Read the code field and proceed accordingly 854 When an FA receives a RA-Rep message it MUST forward the message to 855 the address found in the requestor field. 857 Sanchez, Troxel [Page17] 859 6.3 RA-Dist Processing 861 When creating a RA-Dist message the RKDC MUST do the following: 863 1. Set the value of the type field to 06 864 2. Set the code field 865 3. Set the association lifetime 866 4. Set the values for the Requestor Address, Target Address, and 867 RKDC fields to the values found in the corresponding RA-Rep 868 message 869 5. Place the identification value used for anti-replay attack 870 protection 871 6. Construct the RA data sets following the steps specified below: 872 a) Generate 2 random numbers of 4 octets each to be used as SPIA 873 and SPIB for either MN-FA or FA-HA communication 874 b) Generate Keys based on the information provided in the RA-Req 875 message 876 A key of size 00 indicates "do not generate key" 877 c) Encrypt the keys using the appropriate KEK 878 d) Set the authentication payload size 879 e) Set keys lifetime and type accordingly 880 7. Calculate an integrity check value over the RA header, RA data, 881 and the type, length and SPI fields of the authentication 882 extension using the authentication key created during the 883 establishment of the CMSA with that entity 884 8. Append the appropriate authentication extension to the message 886 When MNs or HAs receive a RA-Dist message they MUST do the following: 888 1. Verify the authenticator 889 If validation fails: 890 - the message is discarded and the event MAY be logged 891 - send an RA-Dist-Ack message with error code 06 892 2. Check identification field for anti-replay protection. If a 893 replayed message is detected: 894 - discard message 895 - send RA-Rep message with with appropriate code field (03) 896 - the event MAY be logged 897 3. Read the Authentication Payload Length field. Note that if the 898 the payload fields equals 0 then no keys were created for that 899 RMSA 900 4. Decrypt Authentication Keys using the appropriate KEK. 901 a) If decryption fails: 902 - send an RA-Dist-Ack message with appropriate code field (04) 903 - the event MAY be logged 904 b) If decryption succeeds: 906 - Search the security association data base for a matching SPI 907 value, for the same destination address and security 908 protocol (i.e a matching mobility security association tuple) 910 Sanchez, Troxel [Page18] 911 If one exists then: 912 - do not create security association 913 - send an RA-Dist-Ack message with error code (05) 914 - the event MAY be logged 915 If no SPI collision is detected then: 916 - create a security association for the appropriate 917 target 918 using the SPIs and the MSA attributes in the RA Data. 919 - send an RA-Dist-Ack message 921 When an FA receives a RA-Dist message it MUST do the following: 923 1. Repeat steps 1 and 2 above 924 2. Read the Authentication Payload Length field for the HA-FA RA data 925 set. Note that if the the payload fields equals 0 then no keys 926 were created for that RMSA 927 3. Decrypt Authentication Keys using the appropriate KEK. 928 4. Read the Authentication Payload Length field for the MN-FA RA data 929 set. Note that if the the payload fields equals 0 then no keys 930 were created for that RMSA 931 5. Decrypt Authentication Keys using the appropriate KEK. 932 a) If either decryption failed: 933 - send an RA-Dist-Ack message with appropriate code field (04) 934 - the event MAY be logged 935 b) If both decryptions succeeded: 936 - For each RMSA, search the security association data base for 937 a matching SPI value, for the same destination address and 938 security protocol (i.e a matching mobility security 939 association tuple). 940 If one exists then: 941 - do not create any security association 942 - send an RA-Dist-Ack message with error code (05) 943 - the event MAY be logged 944 If no SPI collision is detected then: 945 - create both security association for the appropriate 946 targets using the SPIs and the MSA attributes in the 947 RA Data. 948 - send an RA-Dist-Ack message with appropriate code 949 field 951 6.4 RA-Dist-Ack Processing 953 When creating a RA-Dist-Ack message, the transmitting entity MUST do 954 the following: 956 1. Set the value of the type field to 07 957 2. Determine the appropriate code field. 958 3. Set the values for the Lifetime, Requestor Address, Target 959 Address, and RKDC fields to the values found in the corresponding 960 RA-Dist message. 962 Sanchez, Troxel [Page19] 964 4. Set the identification value used for anti-replay attack 965 protection 966 5. Calculate an integrity check value over the RA header, RA data, 967 and the type, length and SPI fields of the authentication 968 extension using the authentication key created during the 969 establishment of the CMSA with that entity. 970 6. Append the appropriate authentication extension to the message. 972 When an RKDC receives a RA-Dist-Ack message it MUST do the following: 974 1. Verify the authenticator 975 - If validation fails the message is silently discarded and the 976 event 977 MAY be logged 978 - If validation succeeds: 979 a) check identification field for AR protection. If a replayed 980 message is detected it is silently discarded and the event MAY 981 be logged 982 b) check the code field 983 - If the value is 01 or 02 the RKDC destroys all keys 984 corresponding to this particular RA exchange 985 - If the value is 05 the RKDC SHOULD generate a new RA-Dist 986 message following the procedure described in section 6.3 988 When an FA receives a RA-Dist-Ack Rep message it MUST check the RKDC 989 field in the RA header first. If the IP address is different than the 990 FA's address the FA MUST forward the message to that address. If the 991 address is the FA's address then it MUST process the message in the 992 same way RKDCs do. 994 7.0 Agent Advertisement Processing 996 When supporting RA, a foreign agent MUST process received Agent 997 Advertisement from other FAs. Upon reception of an agent advertisement 998 with the RA advertisement extension, a foreign agent supporting RA 999 SHOULD establish a CMSA with the RKDCs listed in the extension. If 1000 the R bit is set, the foreign agent supporting RA SHOULD establish a 1001 CMSA with the foreign agent that sent the RA advertisement since it is 1002 serving as an RKDC. It is assumed that FAs are capable of establishing 1003 CMSAs manually, using ZmKeyGen, ISAKMP/Oakley or some other mechanism. 1004 If the FA does not support RA, Agent Advertisements from other FAs 1005 MUST be ignored and the FA MUST continue with regular FA operations as 1006 specified in RFC2002. 1008 8.0 Performance Considerations 1010 Requests from an MN to set up a RMSA MUST be authenticated to protect 1011 against flooding attacks. In particular, randomness for key 1012 generation is a scarce resource. It is important that message loss in 1013 the RA protocol not cause authentication failures that should properly 1014 be regarded as signs of an attack. It is acceptable for a packet to 1016 Sanchez, Troxel [Page20] 1018 arrive with an unknown SA identifier, but not for it to arrive with a 1019 known identifier and then fail the authenticity check. 1021 It might be possible for a message to arrive using an RMSA that has 1022 not yet been created at the recipient. We discuss a number of 1023 strategies to avoid this problem and to deal with it. An RMSA, 1024 whether MN-FA or FA-HA, has an expected direction of use, since the 1025 first use will be a registration request from the MN. This suggests 1026 two strategies. One is that the message from FAi to FAj be sent 1027 before the message from FAi to MN, assuming that it will arrive before 1028 MN sends a message to FAj. This will almost certainly be true in the 1029 absence of loss. The other is to include the message to FAj in the 1030 message to MN, so that it may be included in the initial request. 1031 Also, it may be both sent and included, so that in most cases it will 1032 be processed before the message from MN arrives. 1034 An entity creating an RMSA should cache response messages for a short 1035 period of time (perhaps 30 seconds) so they may be resent. This is 1036 important both to conserve entropy used in key generation and to 1037 ensure that the same response is generated to a subsequent 1038 retransmission of the request, raising the likelihood that the 1039 requesting pair for the RMSA will have a consistent RMSA. 1041 An MN and an HA should be able to cache multiple associations with 1042 RKDCs in multiple trust domains. For example, assume foo.com has 30 1043 FAs in "Corp", 30 FAs in "Research", and 5 each in "Dept-A" through 1044 "Dept-Q". As an MN roams, it creates MSAs with the first FA 1045 encountered in each domain, and RMSAs with others. Thus, as it 1046 switches among FAs, it can encounter FAs from the various trust 1047 domains, and still do only RA even though it may be switching from an 1048 FA in one domain to an FA in another. An MN (or HA) could use LRU 1049 caching with a number of associations or some other strategy. 1051 9.0 Security Considerations 1053 Rapid Authentication uses a Kerberos-style key distribution approach, 1054 to distribute the keying material and security contexts required by 1055 mobility agents and nodes to generate Mobility Security Associations 1056 for the purpose of authenticating Mobile IP control messages while in 1057 a foreign domain. 1059 Mobility Security Associations are uniquely identified by an SPI, 1060 destination IP address and authentication protocol tuple. RKDCs have 1061 no previous knowledge of exiting MSAs at the nodes and agents, 1062 therefore making it possible for the RKDCs to generate SPI values 1063 that match existing ones for a particular destination IP address and 1064 authentication protocol pair. In the event of an SPI collision, either 1065 the node or the agent will send an RA-Dist-Ack message to the RKDCs 1066 with an invalid SPI error code. Upon reception of an RA-Dist-Ack 1067 message with this error code, RKDCs generate new SPI and other 1068 security contexts and transmit new RA-Dist messages. 1070 Sanchez, Troxel [Page21] 1072 Rapid Authentication protects against denial of service attacks using 1073 replayed messages by using either timestamps or nonces. The style of 1074 replay protection is negotiated during the establisment of the CMSA. 1075 Timestamping is the default anti-replay protection mechanism for Rapid 1076 Authentication. Timestamps require clock synchronization between the 1077 sender and the receiver. The use of Nonces for replay protection in 1078 Rapid Authentication is optional. RKDCs use the high-order bits of 1079 the Identification field to insert its nonce value. Mobile nodes and 1080 agents use the low-order bit of the identification field. RKDCs reply 1081 to mobile nodes using RA-Rep messages. RKDCs copy the low order 32 1082 bits of the Identification field found in the RA-Req message in 1083 the Identification field of the reply. Mobile nodes and agents reply 1084 to RA-Dist messages sent by RKDCs using RA-Dist-Ack messages. Nodes 1085 and agents copy the high order 32 bits of the Identification field 1086 found in the RA-Dist message in the identification field of the 1087 reply. The value in the Identification field in RA control messages 1088 should not repeat for the lifetime of the particular CMSA under which 1089 the RA control messages are being protected. 1091 Acknowledgments 1093 The authors thank Andrea Lobo and Matt Condell for their participation 1094 in requirements discussions for Rapid Authentication. Our gratitude 1095 to Isidro Castineyra, Matt Condell and Steve Kent for the significant 1096 contributions to this document. We thank Dennis Rockwell and Mary 1097 Hendrix (INS Corp.) for reviewing this document. We thank John Zao 1098 and Steve Kent for their contributions to the early parts of this 1099 work. 1101 References 1103 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP 1104 Protocol Suite", ACM Computer Communications Review, Vol. 1105 19, No. 2, March 1989. 1107 [Riv92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1108 April 1992. 1110 [Perk96] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 1112 [Kohl93] Kohl, J., et.al, "The Kerberos Network Authentication 1113 Service (V5), RFC 1510, September 1993. 1115 [MOIPS97] J.Zao, et.al "A Public-Key Based Secure Mobile IP", 1116 Submitted to MobiCom 97. 1118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1119 Requirement Levels", RFC 2119, March 1997. 1121 Sanchez, Troxel [Page22] 1123 Disclaimer 1125 The views and specification here are those of the authors and are 1126 not necessarily those of their employers. The authors and their 1127 employers specifically disclaim responsibility for any problems 1128 arising from correct or incorrect implementation or use of this 1129 specification. 1131 Copyright (C) The Internet Society (November 1997). All 1132 Rights Reserved. 1134 This document and translations of it may be copied and furnished 1135 to others, and derivative works that comment on or otherwise 1136 explain it or assist in its implmentation may be prepared, copied, 1137 published and distributed, in whole or in part, without 1138 restriction of any kind, provided that the above copyright notice 1139 and this paragraph are included on all such copies and derivative 1140 works. However, this document itself may not be modified in any 1141 way, such as by removing the copyright notice or references to the 1142 Internet Society or other Internet organizations, except as needed 1143 for the purpose of developing Internet standards in which case the 1144 procedures for copyrights defined in the Internet Standards 1145 process must be followed, or as required to translate it into 1146 languages other than English. The limited permissions granted above 1147 are perpetual and will not be revoked by the Internet Society or 1148 its successors or assigns. 1150 This document and the information contained herein is provided on 1151 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1152 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1153 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1154 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1155 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1157 Author Information 1159 Luis A. Sanchez Gregory D. Troxel 1160 BBN Technologies BBN Technologies 1161 GTE Internetworking GTE Internetworking 1162 10 Moulton Street 10 Moulton Street 1163 Cambridge, MA 02140 Cambridge, MA 02140 1164 USA USA 1165 Email: lsanchez@ir.bbn.com Email: gdt@ir.bbn.com 1166 Telephone: +1 (617) 873-3351 Telephone: +1 (617) 873-2494