idnits 2.17.1 draft-ietf-mobileip-aaa-reqs-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** 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 262: '...he AAA framework MUST provide for more...' RFC 2119 keyword, line 280: '... SHOULD be unusable in any future ne...' RFC 2119 keyword, line 294: '...in its home domain, it MUST be able to...' RFC 2119 keyword, line 299: '... other intermediate nodes) MUST NOT be...' RFC 2119 keyword, line 336: '...- The attendant MUST protect against ...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-auth (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Unexpected draft version: The latest known version of draft-ietf-mobileip-mn-nai is -06, but you're referring to -07. ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1510 (ref. '9') (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '11') ** Obsolete normative reference: RFC 2002 (ref. '13') (Obsoleted by RFC 3220) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '15' ** Obsolete normative reference: RFC 2138 (ref. '16') (Obsoleted by RFC 2865) Summary: 17 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group S. Glass 2 INTERNET DRAFT Sun Microsystems 3 1 June 2000 T. Hiller 4 Lucent Technologies 5 S. Jacobs 6 GTE Laboratories 7 C. Perkins 8 Nokia Research Center 10 Mobile IP Authentication, Authorization, and Accounting Requirements 11 draft-ietf-mobileip-aaa-reqs-04.txt 13 Status of This Memo 15 This document is a submission by the mobile-ip Working Group of the 16 Internet Engineering Task Force (IETF). Comments should be submitted 17 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 19 Distribution of this memo is unlimited. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at 29 any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at: 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The Mobile IP and AAA working groups are currently looking at 40 defining the requirements for Authentication, Authorization, and 41 Accounting. This document contains the requirements which would 42 have to be supported by a AAA service to aid in providing Mobile IP 43 services. 45 1. Introduction 47 Clients obtain Internet services by negotiating a point of attachment 48 to a "home domain", generally from an ISP, or other organization from 49 which service requests are made, and fulfilled. With the increasing 50 popularity of mobile devices, a need has been generated to allow 51 users to attach to any domain convenient to their current location. 52 In this way, a client needs access to resources being provided by 53 an administrative domain different than their home domain (called 54 a "foreign domain"). The need for service from a foreign domain 55 requires, in many models, Authorization, which leads directly to 56 Authentication, and of course Accounting (whence, "AAA"). There 57 is some argument which of these leads to, or is derived from the 58 others, but there is common agreement that the three AAA functions 59 are closely interdependent. 61 An agent in a foreign domain, being called on to provide access to a 62 resource by a mobile user, is likely to request or require the client 63 to provide credentials which can be authenticated before access to 64 resources is permitted. The resource may be as simple as a conduit 65 to the Internet, or may be as complex as access to specific private 66 resources within the foreign domain. Credentials can be exchanged 67 in many different ways, all of which are beyond the scope of this 68 document. Once authenticated, the mobile user may be authorized to 69 access services within the foreign domain. An accounting of the 70 actual resources may then be assembled. 72 Mobile IP is a technology that allows a network node ("mobile 73 node") to migrate from its "home" network to other networks, either 74 within the same administrative domain, or to other administrative 75 domains. The possibility of movement between domains which require 76 AAA services has created an immediate demand to design and specify 77 AAA protocols. Once available, the AAA protocols and infrastructure 78 will provide the economic incentive for a wide-ranging deployment of 79 Mobile IP. This document will identify, describe, and discuss the 80 functional and performance requirements that Mobile IP places on AAA 81 protocols. 83 The formal description of Mobile IP can be found in [13, 12, 14, 17]. 85 In this document, we have attempted to exhibit requirements in a 86 progressive fashion. After showing the basic AAA model for Mobile 87 IP, we derive requirements as follows: 89 - requirements based on the general model 90 - requirements based on providing IP service for mobile nodes 91 - requirements derived from specific Mobile IP protocol needs 93 Then, we exhibit some related AAA models and describe requirements 94 derived from the related models. 96 2. Terminology 98 This document frequently uses the following terms in addition to 99 those defined in RFC 2002 [13]: 101 Accounting The act of collecting information on resource usage 102 for the purpose of trend analysis, auditing, billing, 103 or cost allocation. 105 Administrative Domain 106 An intranet, or a collection of networks, 107 computers, and databases under a common 108 administration. Computer entities operating in 109 a common administration may be assumed to share 110 administratively created security associations. 112 Attendant A node designed to provide the service interface 113 between a client and the local domain. 115 Authentication 116 The act of verifying a claimed identity, in the 117 form of a pre-existing label from a mutually known 118 name space, as the originator of a message (message 119 authentication) or as the end-point of a channel 120 (entity authentication). 122 Authorization 123 The act of determining if a particular right, such 124 as access to some resource, can be granted to the 125 presenter of a particular credential. 127 Billing The act of preparing an invoice. 129 Broker An intermediary agent, trusted by two other AAA 130 servers, able to obtain and provide security services 131 from those AAA servers. For instance, a broker may 132 obtain and provide authorizations, or assurances that 133 credentials are valid. 135 Client A node wishing to obtain service from an attendant 136 within an administrative domain. 138 Foreign Domain 139 An administrative domain, visited by a Mobile IP 140 client, and containing the AAA infrastructure needed 141 to carry out the necessary operations enabling 142 Mobile IP registrations. From the point of view of 143 the foreign agent, the foreign domain is the local 144 domain. 146 Inter-domain Accounting 147 Inter-domain accounting is the collection of 148 information on resource usage of an entity with 149 an administrative domain, for use within another 150 administrative domain. In inter-domain accounting, 151 accounting packets and session records will typically 152 cross administrative boundaries. 154 Intra-domain Accounting 155 Intra-domain accounting is the collection of 156 information on resource within an administrative 157 domain, for use within that domain. In intra-domain 158 accounting, accounting packets and session records 159 typically do not cross administrative boundaries. 161 Local Domain 162 An administrative domain containing the AAA 163 infrastructure of immediate interest to a Mobile IP 164 client when it is away from home. 166 Real-time Accounting 167 Real-time accounting involves the processing of 168 information on resource usage within a defined time 169 window. Time constraints are typically imposed in 170 order to limit financial risk. 172 Session record 173 A session record represents a summary of the resource 174 consumption of a user over the entire session. 175 Accounting gateways creating the session record may 176 do so by processing interim accounting events. 178 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 179 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 180 described in [4]. 182 3. Basic Model 184 In this section, we attempt to capture the main features of a basic 185 model for operation of AAA servers that seems to have good support 186 within the Mobile IP working group. Within the Internet, a client 187 belonging to one administrative domain (called the home domain) often 188 needs to use resources provided by another administrative domain 189 (called the foreign domain). An agent in the foreign domain that 190 attends to the client's request (call the agent the "attendant") 191 is likely to require that the client provide some credentials that 192 can be authenticated before access to the resources is permitted. 193 These credentials may be something the foreign domain understands, 194 but in most cases they are assigned by, and understood only by the 195 home domain, and may be used for setting up secure channels with the 196 mobile node. 198 Local Domain Home Domain 199 +--------------+ +----------------------+ 200 | +------+ | | +------+ | 201 | | | | | | | | 202 | | AAAL | | | | AAAH | | 203 | | +-------------------+ | | 204 | +---+--+ | | +------+ | 205 | | | | | 206 | | | +----------------------+ 207 +------+ | +---+--+ | 208 | | | | | | C = client 209 | C |- -|- -| A | | A = attendant 210 | | | | | | AAAL = local authority 211 +------+ | +------+ | AAAH = home authority 212 | | 213 +--------------+ 215 Figure 1: AAA Servers in Home and Local Domains 217 The attendant often does not have direct access to the data needed 218 to complete the transaction. Instead, the attendant is expected 219 to consult an authority (typically in the same foreign domain) in 220 order to request proof that the client has acceptable credentials. 221 Since the attendant and the local authority are part of the same 222 administrative domain, they are expected to have established, or 223 be able to establish for the necessary lifetime, a secure channel 224 for the purposes of exchanging sensitive (access) information, and 225 keeping it private from (at least) the visiting mobile node. 227 The local authority (AAAL) itself may not have enough information 228 stored locally to carry out the verification for the credentials 229 of the client. In contrast to the attendant, however, the AAAL 230 is expected to be configured with enough information to negotiate 231 the verification of client credentials with external authorities. 232 The local and the external authorities should be configured with 233 sufficient security relationships and access controls so that they, 234 possibly without the need for any other AAA agents, can negotiate the 235 authorization that may enable the client to have access to any/all 236 requested resources. In many typical cases, the authorization 237 depends only upon secure authentication of the client's credentials. 239 Once the authorization has been obtained by the local authority, 240 and the authority has notified the attendant about the successful 241 negotiation, the attendant can provide the requested resources to the 242 client. 244 In the picture, there might be many attendants for each AAAL, and 245 there might be many clients from many different Home Domains. Each 246 Home Domain provides a AAAH that can check credentials originating 247 from clients administered by that Home Domain. 249 There is a security model implicit in the above figure, and it is 250 crucial to identify the specific security associations assumed in the 251 security model. 253 First, it is natural to assume that the client has a security 254 association with the AAAH, since that is roughly what it means for 255 the client to belong to the home domain. 257 Second, from the model illustrated in figure 1 it is clear that AAAL 258 and AAAH have to share a security association, because otherwise 259 they could not rely on the authentication results, authorizations, 260 nor even the accounting data which might be transacted between them. 261 Requiring such bilateral security relationships is, however, in the 262 end not scalable; the AAA framework MUST provide for more scalable 263 mechanisms, as suggested below in section 6. 265 Finally, in the figure, it is clear that the attendant can naturally 266 share a security association with the AAAL. This is necessary in 267 order for the model to work because the attendant has to know that it 268 is permissible to allocate the local resources to the client. 270 As an example in today's Internet, we can cite the deployment of 271 RADIUS [16] to allow mobile computer clients to have access to the 272 Internet by way of a local ISP. The ISP wants to make sure that 273 the mobile client can pay for the connection. Once the client 274 has provided credentials (e.g., identification, unique data, and 275 an unforgeable signature), the ISP checks with the client's home 276 authority to verify the signature, and to obtain assurance that the 277 client will pay for the connection. Here, the attendant function can 278 be carried out by the NAS, and the local and home authorities can use 279 RADIUS servers. Credentials allowing authorization at one attendant 280 SHOULD be unusable in any future negotiations at the same or any 281 other attendant. 283 From the description and example above, we can identify several 284 requirements. 286 - Each local attendant has to have a security relationship with the 287 local AAA server (AAAL) 288 - The local authority has to share, or dynamically establish, 289 security relationships with external authorities that are able to 290 check client credentials 291 - The attendant has to keep state for pending client requests while 292 the local authority contacts the appropriate external authority 293 - Since the mobile node may not necessarily initiate network 294 connectivity from within its home domain, it MUST be able to 295 provide complete, yet unforgeable credentials without ever having 296 been in touch with its home domain. 297 - Since the mobile node's credentials have to remain unforgeable, 298 intervening nodes (e.g., neither the attendant or the local 299 authority (AAAL) or any other intermediate nodes) MUST NOT be 300 able to learn any (secret) information which may enable them to 301 reconstruct and reuse the credentials. 303 From this last requirement, we can see the reasons for the natural 304 requirement that the client has to share, or dynamically establish, 305 a security relationship with the external authority in the Home 306 Domain. Otherwise, it is technically infeasible (given the implied 307 network topology) for the client to produce unforgeable signatures 308 that can be checked by the AAAH. Figure 2 illustrates the natural 309 security associations we understand from our proposed model. Note 310 that, according to the discussion in section 6, there may, by mutual 311 agreement between AAAL and AAAH, be a third party inserted between 312 AAAL and AAAH to help them arbitrate secure transactions in a more 313 scalable fashion. 315 +------+ +------+ 316 | | | | 317 | AAAL +--------------+ AAAH | 318 | | | | 319 +---+--+ +--+---+ 320 | | 321 | | 322 +---+--+ +--+---+ 323 C = client | | | | 324 A = attendant | A | | C | 325 AAAL = local authority | | | | 326 AAAH = home authority +------+ +------+ 328 Figure 2: Security Associations 330 In addition to the requirements listed above, we specify the 331 following requirements which derive from operational experience with 332 today's roaming protocols. 334 - There are scenarios in which an attendant will have to manage 335 requests for many clients at the same time. 336 - The attendant MUST protect against replay attacks. 337 - The attendant equipment should be as inexpensive as possible, 338 since it will be replicated as many times as possible to handle 339 as many clients as possible in the foreign domain. 340 - Attendants SHOULD be configured to obtain authorization, 341 from a trusted local AAA server (AAAL) for Quality of Service 342 requirements placed by the client. 344 Nodes in two separate administrative domains (for instance, AAAH 345 and AAAL) often must take additional steps to verify the identity 346 of their communication partners, or alternatively to guarantee 347 the privacy of the data making up the communication. While these 348 considerations lead to important security requirements, as mentioned 349 above in the context of security between servers, we consider the 350 exact choice of security associations between the AAA servers to be 351 beyond the scope of this document. The choices are unlikely even to 352 depend upon any specific features of the general model illustrated 353 in figure 1. On the other hand, the security associations needed 354 between Mobile IP entities will be of central importance in the 355 design of a suitable AAA infrastructure for Mobile IP. The general 356 model shown above is generally compatible with the needs of Mobile 357 IP. However, some basic changes are needed in the security model of 358 Mobile IP, as detailed in section 5. 360 Lastly, recent discussion in the mobile-ip working group has 361 indicated that the attendant MUST be able to terminate service to the 362 client based on policy determination by either AAAH or AAAL server. 364 3.1. AAA Protocol Roaming Requirements 366 In this section we will detail additional requirements based on 367 issues discovered through operational experience of existing roaming 368 RADIUS networks. The AAA protocol MUST satisfy these requirements in 369 order for providers to offer a robust service. These requirements 370 have been identified by TR45.6 as part of their involvement with the 371 Mobile IP working group. 373 - Support a reliable AAA transport mechanism. 374 * There must be an effective hop-by-hop retransmission and 375 failover mechanism so that reliability does not solely depend 376 on end-to-end retransmission 377 * This transport mechanism will be able indicate to an AAA 378 application that a message was delivered to the next peer AAA 379 application or that a time out occurred. 380 * Retransmission is controlled by the reliable AAA transport 381 mechanism, and not by lower layer protocols such as TCP. 382 * Even if the AAA message is to be forwarded, or the message's 383 options or semantics do not conform with the AAA protocol, 384 the transport mechanism will acknowledge that the peer 385 received the AAA message. 386 * Acknowledgements SHOULD be allowed to be piggybacked in AAA 387 messages 388 * AAA responses have to be delivered in a timely fashion so 389 that Mobile IP does not timeout and retransmit 390 - Transport a digital certificate in an AAA message, in order 391 to minimize the number of round trips associated with AAA 392 transactions. Note: This requirement applies to AAA 393 applications and not mobile stations. The certificates could be 394 used by foreign and home agents to establish an IPSec security 395 association to secure the mobile node's tunneled data. In this 396 case, the AAA infrastructure could assist by obtaining the 397 revocation status of such a certificate (either by performing 398 online checks or otherwise validating the certificate) so that 399 home and foreign agents could avoid a costly online certificate 400 status check. 401 - Provide message integrity and identity authentication on a 402 hop-by-hop (AAA node) basis. 403 - Support replay protection and optional non-repudiation 404 capabilities for all authorization and accounting messages. The 405 AAA protocol must provide the capability for accounting messages 406 to be matched with prior authorization messages. 407 - Support accounting via both bilateral arrangements and via broker 408 AAA servers providing accounting clearinghouse and reconciliation 409 between serving and home networks. There is an explicit 410 agreement that if the private network or home ISP authenticates 411 the mobile station requesting service, then the private network 412 or home ISP network also agrees to reconcile charges with the 413 home service provider or broker. Real time accounting must 414 be supported. Timestamps must be included in all accounting 415 packets. 417 4. Requirements related to basic IP connectivity 419 The requirements listed in the previous section pertain to the 420 relationships between the functional units, and don't depend on the 421 underlying network addressing. On the other hand, many nodes (mobile 422 or merely portable) are programmed to receive some IP-specific 423 resources during the initialization phase of their attempt to connect 424 to the Internet. 426 We place the following additional requirements on the AAA services in 427 order to satisfy such clients. 429 - Either AAA server MUST be able to obtain, or to coordinate the 430 allocation of, a suitable IP address for the customer, upon 431 request by the customer. 432 - AAA servers MUST be able to identify the client by some means 433 other than its IP address. 435 Policy in the home domain may dictate that the home agent instead 436 of the AAAH manages the allocation of an IP address for the mobile 437 node. AAA servers MUST be able to coordinate the allocation of an IP 438 address for the mobile node at least in this way. 440 AAA servers today identify clients by using the Network Access 441 Identifier (NAI) [1]. A mobile node can identify itself by including 442 the NAI along with the Mobile IP Registration Request [6]. The 443 NAI is of the form "user@realm"; it is unique and well suited for 444 use in the AAA model illustrated in figure 1. Using a NAI (e.g., 445 "user@realm") allows AAAL to easily determine the home domain (e.g., 446 "realm") for the client. Both the AAAL and the AAAH can use the NAI 447 to keep records indexed by the client's specific identity. 449 5. AAA for Mobile IP 451 Clients using Mobile IP require specific features from the AAA 452 services, in addition to the requirements already mentioned in 453 connection with the basic AAA functionality and what is needed for 454 IP connectivity. To understand the application of the general model 455 for Mobile IP, we consider the mobile node (MN) to be the client 456 in figure 1, and the attendant to be the foreign agent (FA). If a 457 situation arises that there is no foreign agent present, e.g. in the 458 case of an IPv4 mobile node with a co-located care of address or an 459 IPv6 mobile node, the equivalent attendant functionality is to be 460 provided by the address allocation entity, e.g. a DHCP server. Such 461 an attendant functionality is outside the scope of this document. 462 The home agent, while important to Mobile IP, is allowed to play 463 a role during the initial registration that is subordinate to the 464 role played by the AAAH. For application to Mobile IP, we modify 465 the general model (as illustrated in figure 3). After the initial 466 registration, the mobile node is authorized to continue using Mobile 467 IP at the foreign domain without requiring further involvement by 468 the AAA servers. Thus, the initial registration will probably take 469 longer than subsequent Mobile IP registrations. 471 In order to reduce this extra time overhead as much as possible, it 472 is important to reduce the time taken for communications between 473 the AAA servers. A major component of this communications latency 474 is the time taken to traverse the wide-area Internet that is likely 475 to separate the AAAL and the AAAH. This leads to a further strong 476 motivation for integration of the AAA functions themselves, as 477 well as integration of AAA functions with the initial Mobile IP 478 registration. In order to reduce the number of messages that 479 traverse the network for initial registration of a Mobile Node, the 480 AAA functions in the visited network (AAAL) and the home network 481 (AAAH) need to interface with the foreign agent and the home agent 482 to handle the registration message. Latency would be reduced as a 483 result of initial registration being handled in conjunction with 484 AAA and the mobile IP mobility agents. Subsequent registrations, 485 however, would be handled according to RFC 2002 [13]. Another way 486 to reduce latency as to accounting would be the exchange of small 487 records. 489 As there are many different types of sub-services attendants may 490 provide to mobile clients, there MUST be extensible accounting 491 formats. In this way, the specific services being provided can be 492 identified, as well as accounting support should more services be 493 identified in the future. 495 The AAA home domain and the HA home domain of the mobile node need 496 not be part of the same administrative domain. Such an situation 497 can occur if the home address of the mobile node is provided by one 498 domain, e.g. an ISP that the mobile user uses while at home, and the 499 authorization and accounting by another (specialized) domain, e.g. a 500 credit card company. The foreign agent sends only the authentication 501 information of the mobile node to the AAAL, which interfaces to 502 the AAAH. After a successful authorization of the mobile node, the 503 foreign agent is able to continue with the mobile IP registration 504 procedure. Such a scheme introduces more delay if the access to 505 the AAA functionality and the mobile IP protocol is sequentialized. 506 Subsequent registrations would be handled according to RFC2002 [13] 507 without further interaction with the AAA. Whether to combine or 508 separate the Mobile IP protocol data with/from the AAA messages is 509 ultimately a policy decision. A separation of the Mobile IP protocol 510 data and the AAA messages can be successfully accomplished only if 511 the IP address of the mobile node's home agent is provided to the 512 foreign agent performing the attendant function. 514 All needed AAA and Mobile IP functions SHOULD be processed during 515 a single Internet traversal. This MUST be done without requiring 516 AAA servers to process protocol messages sent to Mobile IP agents. 517 The AAA servers MUST identify the Mobile IP agents and security 518 associations necessary to process the Mobile IP registration, pass 519 the necessary registration data to those Mobile IP agents, and 520 remain uninvolved in the routing and authentication processing steps 521 particular to Mobile IP registration. 523 For Mobile IP, the AAAL and the AAAH servers have the following 524 additional general tasks: 526 - enable [re]authentication for Mobile IP registration 527 - authorize the mobile node (once its identity has been 528 established) to use at least the set of resources for minimal 529 Mobile IP functionality, plus potentially other services 530 requested by the mobile node 531 - initiate accounting for service utilization 532 - use AAA protocol extensions specifically for including Mobile 533 IP registration messages as part of the initial registration 534 sequence to be handled by the AAA servers. 536 These tasks, and the resulting more specific tasks to be listed later 537 in this section, are beneficially handled and expedited by the AAA 538 servers shown in figure 1 because the tasks often happen together, 539 and task processing needs access to the same data at the same time. 541 Local Domain Home Domain 542 +--------------+ +----------------------+ 543 | +------+ | | +------+ | 544 | | | | | | | | 545 | | AAAL | | | | AAAH | | 546 | | +-------------------+ | | 547 | +---+--+ | | +--+---+ | 548 | | | | | | 549 | | | | | | 550 +------+ | +---+--+ | | +--+---+ | 551 | | | | | | | | | | 552 | MN +- -|- -+ FA + -- -- -- -- - + HA | | 553 | | | | | | | | | | 554 +------+ | +------+ | | +------+ | 555 | | | | 556 +--------------+ +----------------------+ 558 Figure 3: AAA Servers with Mobile IP agents 560 In the model in figure 1, the initial AAA transactions are handled 561 without needing the home agent, but Mobile IP requires every 562 registration to be handled between the home agent (HA) and the 563 foreign agent (FA), as shown by the sparse dashed (lower) line in 564 figure 3. This means that during the initial registration, something 565 has to happen that enables the home agent and foreign agent to 566 perform subsequent Mobile IP registrations. After the initial 567 registration, the AAAH and AAAL in figure 3 would not be needed, 568 and subsequent Mobile IP registrations would only follow the lower 569 control path between the foreign agent and the home agent. 571 Any Mobile IP data that is sent by FA through the AAAL to AAAH MUST 572 be considered opaque to the AAA servers. Authorization data needed 573 by the AAA servers then MUST be delivered to them by the foreign 574 agent from the data supplied by the mobile node. The foreign agent 575 becomes a translation agent between the Mobile IP registration 576 protocol and AAA. 578 As mentioned in section 3, nodes in two separate administrative 579 domains often must take additional steps to guarantee their security 580 and privacy,, as well as the security and privacy of the data they 581 are exchanging. In today's Internet, such security measures may be 582 provided by using several different algorithms. Some algorithms rely 583 on the existence of a public-key infrastructure [8]; others rely on 584 distribution of symmetric keys to the communicating nodes [9]. AAA 585 servers SHOULD be able to verify credentials using either style in 586 their interactions with Mobile IP entities. 588 In order to enable subsequent registrations, the AAA servers MUST 589 be able to perform some key distribution during the initial Mobile 590 IP registration process from any particular administrative domain. 592 This key distribution MUST be able to provide the following security 593 functions: 595 - identify or create a security association between MN and 596 home agent (HA); this is required for the MN to produce the 597 [re]authentication data for the MN--HA authentication extension, 598 which is mandatory on Mobile IP registrations. 599 - identify or create a security association between mobile node and 600 foreign agent, for use with subsequent registrations at the same 601 foreign agent, so that the foreign agent can continue to obtain 602 assurance that the same mobile node has requested the continued 603 authorization for Mobile IP services. 604 - identify or create a security association between home agent 605 and foreign agent, for use with subsequent registrations at 606 the same foreign agent, so that the foreign agent can continue 607 to obtain assurance that the same home agent has continued the 608 authorization for Mobile IP services for the mobile node. 609 - participate in the distribution of the security association (and 610 Security Parameter Index, or SPI) to the Mobile IP entities 611 - The AAA server MUST also be able to validate certificates 612 provided by the mobile node and provide reliable indication to 613 the foreign agent. 614 - The AAAL SHOULD accept an indication from the foreign agent about 615 the acceptable lifetime for its security associations with the 616 mobile node and/or the mobile node's home agent. This lifetime 617 for those security associations SHOULD be an integer multiple of 618 registration lifetime offered by the foreign agent to the mobile 619 node. This MAY allow for Mobile IP reauthentication to take 620 place without the need for reauthentication to take place on the 621 AAA level, thereby shortenning the time required for mobile node 622 reregistration. 623 - The AAA servers SHOULD be able to condition their acceptance of 624 a Mobile IP registration authorization depending upon whether 625 the registration requires broadcast or multicast service to the 626 mobile node tunneled through the foreign agent. 627 - In addition, reverse tunneling may also be a necessary 628 requirement for mobile node connectivity. Therefore, AAA 629 servers SHOULD also be able to condition their acceptance of 630 Mobile IP registration authorization depending upon whether the 631 registration requires reverse tunnelling support to the home 632 domain through the foreign agent. 634 The lifetime of any security associations distributed by the AAA 635 server for use with Mobile IP SHOULD be great enough to avoid 636 too-frequent initiation of the AAA key distribution, since each 637 invocation of this process is likely to cause lengthy delays between 638 [re]registrations [5]. Registration delays in Mobile IP cause 639 dropped packets and noticeable disruptions in service. Note that any 640 key distributed by AAAH to the foreign agent and home agent MAY be 641 used to initiate Internet Key Exchange (IKE) [7]. 643 Note further that the mobile node and home agent may well have a 644 security association established that does not depend upon any action 645 by the AAAH. 647 5.1. Mobile IP with Dynamic IP Addresses 649 According to section 4, many people would like their mobile nodes to 650 be identified by their NAI, and to obtain a dynamically allocated 651 home address for use in the foreign domain. These people may often 652 be unconcerned with details about how their computers implement 653 Mobile IP, and indeed may not have any knowledge of their home agent 654 or any security association except that between themselves and the 655 AAAH (see figure 2. In this case the Mobile IP registration data has 656 to be carried along with the AAA messages. The AAA home domain and 657 the HA home domain have to be part of the same administrative domain. 659 Mobile IP requires the home address assigned to the mobile node 660 belong to the same subnet as the Home Agent providing service to the 661 mobile node. For effective use of IP home addresses, the home AAA 662 (AAAH) SHOULD be able to select a home agent for use with the newly 663 allocated home address. In many cases, the mobile node will already 664 know the address of its home agent, even if the mobile node does 665 not already have an existing home address. Therefore, the home AAA 666 (AAAH) MUST be able to coordinate the allocation of a home address 667 with a home agent that might be designated by the mobile node. 669 Allocating a home address and a home agent for the mobile would 670 provide a further simplification in the configuration needs for the 671 client's mobile node. Currently, in the Proposed Standard Mobile IP 672 specification [13] a mobile node has to be configured with a home 673 address and the address of a home agent, as well as with a security 674 association with that home agent. In contrast, the proposed AAA 675 features would only require the mobile node to be configured with 676 its NAI and a secure shared secret for use by the AAAH. The mobile 677 node's home address, the address of its home agent, the security 678 association between the mobile node and the home agent, and even the 679 identity (DNS name or IP address) of the AAAH can all be dynamically 680 determined as part of Mobile IP initial registration with the 681 mobility agent in the foreign domain (i.e., a foreign agent with AAA 682 interface features). Nevertheless, the mobile node may choose to 683 include the MN-HA security extension as well as AAA credentials, and 684 the proposed Mobile IP and AAA server model MUST work when both are 685 present. 687 The reason for all this simplification is that the NAI encodes the 688 client's identity as well as the name of the client's home domain; 689 this follows existing industry practice for the way NAIs are used 690 today (see section 4). The home domain name is then available for 691 use by the local AAA (AAAL) to locate the home AAA serving the 692 client's home domain. In the general model, the AAAL would also have 693 to identify the appropriate security association for use with that 694 AAAH. Section 6 discusses a way to reduce the number of security 695 associations that have to be maintained between pairs of AAA servers 696 such as the AAAL and AAAH just described. 698 5.2. Firewalls and AAA 700 Mobile IP has encountered some deployment difficulties related to 701 firewall traversal; see for instance [11]. Since the firewall and 702 AAA server can be part of the same administrative domain, we propose 703 that the AAA server SHOULD be able to issue control messages and keys 704 to the firewall at the boundary of its administrative domain that 705 will configure the firewall to be permeable to Mobile IP registration 706 and data traffic from the mobile node. 708 5.3. Mobile IP with Local Home Agents 710 +-------------------------+ +--------------+ 711 | +------+ +------+ | | +------+ | 712 | | | | | | | | | | 713 | | HA +----+ AAAL | | | | AAAH | | 714 | | | | +-------------------+ | | 715 | +-+----+ +---+--+ | | +------+ | 716 | | | | | Home Domain | 717 | | +- - - - - + | +--------------+ 718 +------+ | +-+--+-+ | 719 | | | | | | 720 | MN +------+ FA | | 721 | | | | | Local Domain | 722 +------+ | +------+ | 723 +-------------------------+ 725 Figure 4: Home Agent Allocated by AAAL 727 In some Mobile IP models, mobile nodes boot on subnets which are 728 technically foreign subnets, but the services they need are local, 729 and hence communication with the home subnet as if they were residing 730 on the home is not necessary. As long as the mobile node can get an 731 address routable from within the current domain (be it publicly, or 732 privately addressed) it can use mobile IP to roam around that domain, 733 calling the subnet on which it booted its temporary home. This 734 address is likely to be dynamically allocated upon request by the 735 mobile node. 737 In such situations, when the client is willing to use a dynamically 738 allocated IP address and does not have any preference for the 739 location of the home network (either geographical or topological), 740 the local AAA server (AAAL) may be able to offer this additional 741 allocation service to the client. Then, the home agent will be 742 located in the local domain, which is likely to be offer smaller 743 delays for new Mobile IP registrations. 745 In figure 4, AAAL has received a request from the mobile node to 746 allocate a home agent in the local domain. The new home agent 747 receives keys from AAAL to enable future Mobile IP registrations. 748 From the picture, it is evident that such a configuration avoids 749 problems with firewall protection at the domain boundaries, such 750 as were described briefly in section 5.2. On the other hand, this 751 configuration makes it difficult for the mobile node to receive 752 data from any communications partners in the mobile node's home 753 administrative domain. Note that, in this model, the mobile node's 754 home address is affiliated with the foreign domain for routing 755 purposes. Thus, any dynamic update to DNS, to associate the mobile 756 node's home FQDN (Fully Qualified Domain Name [10]) with its new IP 757 address, will require insertion of a foreign IP address into the home 758 DNS server database. 760 5.4. Mobile IP with Local Payments 762 Since the AAAL is expected to be enabled to allocate a local home 763 agent upon demand, we can make a further simplification. In cases 764 where the AAAL can manage any necessary authorization function 765 locally (e.g., if the client pays with cash or a credit card), then 766 there is no need for an AAA protocol or infrastructure to interact 767 with the AAAH. The resulting simple configuration is illustrated in 768 figure 5. 770 In this simplified model, we may consider that the role of the AAAH 771 is taken over either by a national government (in the case of a 772 cash payment), or by a card authorization service if payment is by 773 credit card, or some such authority acceptable to all parties. Then, 774 the AAAL expects those external authorities to guarantee the value 775 represented by the client's payment credentials (cash or credit). 776 There are likely to be other cases where clients are granted access 777 to local resources, or access to the Internet, without any charges at 778 all. Such configurations may be found in airports and other common 779 +-------------------------+ 780 | +------+ +------+ | 781 | | | | | | 782 | | HA +----+ AAAL | | 783 | | | | | | 784 | +--+---+ +----+-+ | 785 | | | | 786 | +- - - - - + | | 787 +------+ | +-+--+-+ | 788 | | | | | | 789 | MN +- -|- - - - - - - + FA | | 790 | | | Local Domain | | | 791 +------+ | +------+ | 792 +-------------------------+ 794 Figure 5: Local Payment for Local Mobile IP services 796 areas where business clients are likely to spend time. The service 797 provider may find sufficient reward in the goodwill of the clients, 798 or from advertisements displayed on Internet portals that are to 799 be used by the clients. In such situations, the AAAL SHOULD still 800 allocate a home agent, appropriate keys, and the mobile node's home 801 address. 803 5.5. Fast Handover 805 Since the movement from coverage area to coverage area may be 806 frequent in Mobile IP networks, it is imperative that the latency 807 involved in the handoff process be minimized. See, for instance, the 808 Route Optimization draft [15] for one way to do this using Binding 809 Updates. When the mobile node enters a new visited subnet, it would 810 be desirable for it to provide the previous foreign agent's NAI. 811 The new FA can use this information to either contact the previous 812 FA to retrieve the KDC session key information, or it can attempt 813 to retrieve the keys from the AAAL. If the AAAL cannot provide the 814 necessary keying information, the request will have to be sent to the 815 mobile node's AAAH to retrieve new keying information. After initial 816 authorization, further authorizations SHOULD be done locally within 817 the Local Domain. 819 When a MN moves into a new foreign subnet as a result of a handover 820 and is now served by a different FA, the AAAL in this domain may 821 contact the AAAL in the domain that the MN has just been handed 822 off from to verify the authenticity of the MN and/or to obtain the 823 session keys. The new serving AAAL may determine the address of 824 the AAAL in the previously visited domain from the previous FA NAI 825 information supplied by the MN. 827 6. Broker Model 829 The picture in Figure 1 shows a configuration in which the local and 830 the home authority have to share trust. Depending on the security 831 model used, this configuration can cause a quadratic growth in the 832 number of trust relationships, as the number of AAA authorities 833 (AAAL and AAAH) increases. This has been identified as a problem 834 by the roamops working group [3], and any AAA proposal MUST solve 835 this problem. Using brokers solves many of the scalability problems 836 associated with requiring direct business/roaming relationships 837 between every two administrative domains. In order to provide 838 scalable networks in highly diverse service provider networks in 839 which there are many domains (e.g. many service providers and large 840 numbers of private networks), multiple layers of brokers MUST be 841 supported for both of the broker models described. 843 Integrity or privacy of information between the home and serving 844 domains may be achieved by either hop-by-hop security associations 845 or end-to-end security associations established with the help of the 846 broker infrastructure. A broker may play the role of a proxy between 847 two administrative domains which have security associations with the 848 broker, and relay AAA messages back and forth securely. 850 Alternatively, a broker may also enable the two domains with which 851 it has associations, but the domains themselves do not have a 852 direct association, in establishing a security association, thereby 853 bypassing the broker for carrying the messages between the domains. 854 This may be established by virtue of having the broker relay a shared 855 secret key to both the domains that are trying to establish secure 856 communication and then have the domains use the keys supplied by the 857 broker in setting up a security association. 859 Assuming that AAAB accepts responsibility for payment to the serving 860 domain on behalf of the home domain, the serving domain is assured of 861 receiving payments for services offered. However, the redirection 862 broker will usually require a copy of authorization messages from the 863 home domain and accounting messages from the serving domain, in order 864 for the broker to determine if it is willing to accept responsibility 865 for the services being authorized and utilized. If the broker does 866 not accept such responsibility for any reason, then it must be able 867 to terminate service to a mobile node in the serving network. In 868 the event that multiple brokers are involved, in most situations all 869 brokers must be so copied. This may represent an additional burden 870 on foreign agents and AAALs. 872 Though this mechanism may reduce latency in the transit of messages 873 between the domains after the broker has completed its involvement, 874 there may be many more messages involved as a result of additional 875 copies of authorization and accounting messages to the brokers 876 involved. There may also be additional latency for initial access to 877 the network, especially when a new security association needs to be 878 created between AAAL and AAAH (for example, from the use of ISAKMP). 879 These delays may become important factors for latency- critical 880 applications. 882 Local Domain Home Domain 883 +--------------+ +----------------------+ 884 | +------+ | +------+ | +------+ | 885 | | | | | | | | | | 886 | | AAAL +-------+ AAAB +--------+ AAAH | | 887 | | | | | | | | | | 888 | +------+ | +------+ | +------+ | 889 | | | | | 890 | | | +----------------------+ 891 +------+ | +---+--+ | 892 | | | | | | C = client 893 | C +- -|- -+ A | | A = attendant 894 | | | | | | AAAL = local authority 895 +------+ | +------+ | AAAH = home authority 896 | | AAAB = broker authority 897 +--------------+ 899 Figure 6: AAA Servers Using a Broker 901 The AAAB in figure 6 is the broker's authority server. The broker 902 acts as a settlement agent, providing security and a central point of 903 contact for many service providers and enterprises. 905 The AAAB enables the local and home domains to cooperate without 906 requiring each of the networks to have a direct business or security 907 relationship with all the other networks. Thus, brokers offer the 908 needed scalability for managing trust relationships between otherwise 909 independent network domains. Use of the broker does not preclude 910 managing separate trust relationships between domains, but it does 911 offer an alternative to doing so. Just as with the AAAH and AAAL 912 (see section 5), data specific to Mobile IP control messages MUST 913 NOT be processed by the AAAB. Any credentials or accounting data to 914 be processed by the AAAB must be present in AAA message units, not 915 extracted from Mobile IP protocol extensions. 917 The following requirements come mostly from [2], which discusses 918 use of brokers in the particular case of authorization for roaming 919 dial-up users. 921 - allowing management of trust with external domains by way of 922 brokered AAA. 923 - accounting reliability. Accounting data that traverses 924 the Internet may suffer substantial packet loss. Since 925 accounting packets may traverse one or more intermediate 926 authorization points (e.g., brokers), retransmission is needed 927 from intermediate points to avoid long end-to-end delays. 928 - End to End security. The Local Domain and Home Domain must be 929 able to verify signatures within the message, even though the 930 message is passed through an intermediate authority server. 931 - Since the AAAH in the home domain MAY be sending sensitive 932 information, such as registration keys, the broker MUST be able 933 to pass encrypted data between the AAA servers. 935 The need for End-to-End security results from the following attacks 936 which were identified when brokered operation uses RADIUS [16] 937 (see [2] for more information on the individual attacks): 939 + Message editing 940 + Attribute editing 941 + Theft of shared secrets 942 + Theft and modification of accounting data 943 + Replay attacks 944 + Connection hijacking 945 + Fraudulent accounting 947 These are serious problems which cannot be allowed to persist in any 948 acceptable AAA protocol and infrastructure. 950 7. Security Considerations 952 This is a requirements draft for AAA based on Mobile IP. Because AAA 953 is security driven, most of this document addresses the security 954 considerations AAA MUST make on behalf of Mobile IP. As with any 955 security proposal, adding more entities that interact using security 956 protocols creates new administrative requirements for maintaining 957 the appropriate security associations between the entities. In the 958 case of the AAA services proposed however, these administrative 959 requirements are natural, and already well understood in today's 960 Internet because of experience with dial up network access. 962 8. IPv6 Considerations 964 The main difference between Mobile IP for IPv4 and Mobile IPv6 is 965 that in IPv6 there is no foreign agent. The attendant function, 966 therefore, has to be located elsewhere. Logical repositories for 967 that function are either at the local router, for stateless address 968 autoconfiguration, or else at the nearest DHCPv6 server, for stateful 969 address autoconfiguration. In the latter case, it is possible that 970 there would be a close relationship between the DHCPv6 server and the 971 AAALv6, but we believe that the protocol functions should still be 972 maintained separately. 974 The MN-NAI would be equally useful for identifying the mobile node to 975 the AAALv6 as is described in earlier sections of this document. 977 9. Acknowledgements 979 Thanks to Gopal Dommety and Basavaraj Patil for participating in 980 the Mobile IP subcommittee of the aaa-wg which was charged with 981 formulating the requirements detailed in this document. Thanks to N. 982 Asokan for perceptive comments to the mobile-ip mailing list. Some 983 of the text of this document was taken from a draft co-authored by 984 Pat Calhoun. Patrik Flykt suggested text about allowing AAA home 985 domain functions to be separated from the domain managing the home 986 address of the mobile computer. 988 The requirements in section 5.5 and section 3.1 were taken from 989 a draft submitted by members of the TIA's TR45.6 Working Group. 990 We would like to acknowledge the work done by the authors of that 991 draft: Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety, 992 Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman, 993 Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric 994 Jaques, Ed Campbell, and Yingchun Xu. 996 References 998 [1] B. Aboba and M. Beadles. The Network Access Identifier. 999 Request for Comments (Proposed Standard) 2486, Internet 1000 Engineering Task Force, January 1999. 1002 [2] B. Aboba and J. Vollbrecht. Proxy Chaining and Policy 1003 Implementation in Roaming. Internet Draft, Internet Engineering 1004 Task Force. 1005 draft-ietf-roamops-auth-10.txt, February 1999. Work in 1006 progress. 1008 [3] B. Aboba and G. Zorn. Criteria for Evaluating Roaming 1009 Protocols. Request for Comments (Informational) 2477, Internet 1010 Engineering Task Force, December 1998. 1012 [4] S. Bradner. Key words for use in RFCs to Indicate Requirement 1013 Levels. Request for Comments (Best Current Practice) 2119, 1014 Internet Engineering Task Force, March 1997. 1016 [5] Ramon Caceres and Liviu Iftode. Improving the Performance 1017 of Reliable Transport Protocols in Mobile Computing 1018 Environments. IEEE Journal on Selected Areas in Communications, 1019 13(5):850--857, June 1995. 1021 [6] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 1022 Address Identifier Extension. 1023 draft-ietf-mobileip-mn-nai-07.txt, January 2000. (work in 1024 progress). 1026 [7] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). 1027 Request for Comments (Proposed Standard) 2409, Internet 1028 Engineering Task Force, November 1998. 1030 [8] R. Housley, W. Ford, T. Polk, and D. Solo. Internet X.509 1031 Public Key Infrastructure Certificate and CRL Profile. Internet 1032 Draft, Internet Engineering Task Force. 1033 draft-ietf-pkix-ipki-part1-11.txt, September 1998. Work in 1034 progress. 1036 [9] J. Kohl and C. Neuman. The Kerberos Network Authentication 1037 Service (V5). Request for Comments (Proposed Standard) 1510, 1038 Internet Engineering Task Force, September 1993. 1040 [10] P. V. Mockapetris. Domain names - implementation and 1041 specification. Request for Comments (Standard) 1035, Internet 1042 Engineering Task Force, November 1987. 1044 [11] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 1045 Mobile IP. Request for Comments (Informational) 2356, Internet 1046 Engineering Task Force, June 1998. 1048 [12] C. Perkins. IP Encapsulation within IP. Request for Comments 1049 (Proposed Standard) 2003, Internet Engineering Task Force, 1050 October 1996. 1052 [13] C. Perkins. IP Mobility Support. Request for Comments 1053 (Proposed Standard) 2002, Internet Engineering Task Force, 1054 October 1996. 1056 [14] C. Perkins. Minimal Encapsulation within IP. Request for 1057 Comments (Proposed Standard) 2004, Internet Engineering Task 1058 Force, October 1996. 1060 [15] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 1061 Internet Draft, Internet Engineering Task Force. 1062 draft-ietf-mobileip-optim-08.txt, February 1999. Work in 1063 progress. 1065 [16] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 1066 Authentication Dial In User Service (RADIUS). Request for 1067 Comments (Proposed Standard) 2138, Internet Engineering Task 1068 Force, April 1997. 1070 [17] J. Solomon and S. Glass. Mobile-IPv4 Configuration Option 1071 for PPP IPCP. Request for Comments (Proposed Standard) 2290, 1072 Internet Engineering Task Force, February 1998. 1074 Addresses 1076 The working group can be contacted via the current chairs: 1078 Basavaraj Patil Phil Roberts 1079 Nokia Motorola 1081 6000 Connection Drive 1501 West Shure Drive 1082 Irving, TX 75039 Arlington Heights, IL 60004 1083 USA USA 1084 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1085 Basavaraj.Patil@nokia.com QA3445@email.mot.com 1087 Questions about this memo can be directed to: 1089 Pat R. Calhoun Gopal Dommety 1090 Network and Security Center IOS Network Protocols 1091 Sun Microsystems Laboratories Cisco Systems, Inc. 1092 15 Network Circle 170 West Tasman Drive 1093 Menlo Park, California 94025 San Jose, CA 95134-1706 1094 USA USA 1095 Phone: +1 650-786-7733 Phone: +1-408-525-1404 1096 pcalhoun@eng.sun.co EMail: gdommety@cisco.com 1097 Fax: +1 650-786-6445 Fax: +1 408-526-4952 1099 Steven M. Glass Stuart Jacobs 1100 Sun Microsystems Secure Systems Department 1101 1 Network Drive GTE Laboratories 1102 Burlington, MA 40 Sylvan Road 1103 01803 Waltham, MA 02451-1128 1104 USA USA 1105 Phone: +1-781-442-0504 Phone: +1 781-466-3076 1106 EMail: steven.glass@sun.com EMail: sjacobs@gte.com 1107 Fax: +1 781-466-2838 1109 Tom Hiller Peter J. McCann 1110 Lucent Technologies Lucent Technologies 1111 Rm 2F-218 Rm 2Z-305 1112 263 Shuman Blvd 263 Shuman Blvd 1113 Naperville, IL 60566 Naperville, IL 60566 1114 USA USA 1115 email: tomhiller@lucent.com email: mccap@lucent.com 1116 phone: +1 630 979 7673 phone: +1 630 713 9359 1117 fax: +1 630 713 3663 fax: +1 630 713 4982 1119 Basavaraj Patil Charles E. Perkins 1120 Nokia Communications Systems Lab 1121 Nokia Research Center 1122 6000 Connection Drive 313 Fairchild Drive 1123 Irving, TX 75039 Mountain View, California 94043 1124 USA USA 1125 Phone: +1 972-894-6709 Phone: +1-650 625-2986 1126 EMail: Basavaraj.Patil@nokia.com EMail: charliep@iprg.nokia.com 1127 Fax : +1 972-894-5349 Fax: +1 650 625-2502