idnits 2.17.1 draft-gellens-otasp-acap-01.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-gellens-otasp-acap-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-gellens-otasp-acap-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-gellens-otasp-acap-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-gellens-otasp-acap-00.txt,', but the file name used is 'draft-gellens-otasp-acap-01' == 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 Abstract section. ** The document seems to lack an Introduction section. ** 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.) ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (29 March 1999) is 9160 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 section? 'ACAP' on line 1288 looks like a reference -- Missing reference section? 'SASL' on line 1295 looks like a reference -- Missing reference section? 'CRAM-MD5' on line 1291 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Gellens 2 Document: draft-gellens-otasp-acap-00.txt, .ps Qualcomm 3 Expires: 29 September 1999 29 March 1999 5 Wireless Device Configuration (OTASP/OTAPA) via ACAP 7 Status of this Memo: 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 . 25 The list of Internet-Draft Shadow Directories can be accessed at 26 . 28 Note: This document (with Section 8 as an appendix, and an appendix 29 listing IS-683-A Parameter Block Definitions) was previously 30 published by QUALCOMM Incorporated as document 80-67980-1 Rev X1, 31 dated 28 December 1998. 33 Abstract: 35 Wireless carriers today are faced with creating more efficient 36 distribution channels, increasing customer satisfaction, while also 37 improving margin and profitability. Industry trends are pushing the 38 sale of handsets further into the retail channel. The cost and 39 effort of provisioning handsets, activating users, and updating 40 handset parameters can be greatly reduced by using over-the-air 41 activation mechanisms. A comprehensive and extensible means for 42 over-the-air provisioning and handset parameter updating is 43 required. 45 One approach is to purchase EIA/TIA/IS-683A (Over-the-air Service 46 Provisioning of Mobile Stations in Spread Spectrum Systems) 47 equipment. The cost of this has led carriers to seek alternative 48 solutions. A very viable means for providing over-the-air (OTA) 49 provisioning is to leverage the rollout of IS-707 data services 50 equipment, which most carriers are in the process of deploying. 51 This paper presents an approach to OTA provisioning that utilizes 52 the deployment of IS-707 to deliver OTA provisioning and parameter 53 upgrading. 55 IS-707 data services makes available several methods of providing 56 over-the-air provisioning and parameter updating. A well 57 thought-out approach utilizing Internet-based open standard 58 mechanisms can provide an extensible platform for further carrier 59 service offerings, enhanced interoperability among back-end 60 services, and vendor independence. 62 This paper describes a viable and attractive means to provide 63 OTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. 65 Table of Contents 67 1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Feature Descriptions . . . . . . . . . . . . . . . . . . . 6 69 2.1. OTASP Feature Description . . . . . . . . . . . . . . . 6 70 2.2. OTAPA Feature Description . . . . . . . . . . . . . . . 7 71 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Initial Provisioning Activity . . . . . . . . . . . . . 7 73 3.2. OTASP for Authorized Users . . . . . . . . . . . . . . . 8 74 3.3. OTAPA Activity . . . . . . . . . . . . . . . . . . . . 9 75 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. General Requirements . . . . . . . . . . . . . . . . . 9 77 4.2. OTASP Requirements . . . . . . . . . . . . . . . . . . . 10 78 4.3. OTAPA Requirements . . . . . . . . . . . . . . . . . . 10 79 4.4. Provisioning Server Requirements . . . . . . . . . . . . 10 80 4.5. Security Requirements . . . . . . . . . . . . . . . . . 11 81 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 11 83 5.1.1. Mobile Authentication and A-Key Generation . . . . . 12 84 5.1.2. Mobile Identification . . . . . . . . . . . . . . . 12 85 5.1.3. ACAP Server . . . . . . . . . . . . . . . . . . . . 12 86 5.1.4. Overview of ACAP Structure . . . . . . . . . . . . 13 87 5.1.5. Data Organization and Capabilities . . . . . . . . . 14 88 5.1.5.1. Structure . . . . . . . . . . . . . . . . . . . 14 89 5.1.5.2. Conventions . . . . . . . . . . . . . . . . . . 15 90 5.1.6. Dataset . . . . . . . . . . . . . . . . . . . . . . 15 91 5.1.6.1. Entries and Attributes . . . . . . . . . . . . . 15 92 5.1.6.2. NAM Records . . . . . . . . . . . . . . . . . . 16 93 5.1.6.3. Server Roaming Lists . . . . . . . . . . . . . . 17 94 5.1.6.4. Requested-Data Record . . . . . . . . . . . . . 17 95 5.1.6.5. Sample Server Entry . . . . . . . . . . . . . . 18 96 5.1.7. Administrative Client . . . . . . . . . . . . . . . 19 97 5.1.8. Mobile Client . . . . . . . . . . . . . . . . . . . 19 98 5.2. WAP with ACAP . . . . . . . . . . . . . . . . . . . . . 22 99 5.3. Network-Resident vs. Configuration Data . . . . . . . . 22 100 5.4. Intellectual Property Issues . . . . . . . . . . . . . 23 101 6. Handset Protocol Suites . . . . . . . . . . . . . . . . . . 23 102 6.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 23 103 7. IS-683A Compatibility . . . . . . . . . . . . . . . . . . . 23 104 7.1. OTASP Operations . . . . . . . . . . . . . . . . . . . 23 105 7.2. OTASP Call Flow . . . . . . . . . . . . . . . . . . . . 24 106 7.3. OTAPA Operations . . . . . . . . . . . . . . . . . . . 24 107 7.4. OTAPA Call Flow . . . . . . . . . . . . . . . . . . . . 24 108 8. Alternative Methods . . . . . . . . . . . . . . . . . . . . 24 109 8.1. IS-683A over TCP/IP . . . . . . . . . . . . . . . . . . 24 110 8.1.1. OTAF Server . . . . . . . . . . . . . . . . . . . . 24 111 8.1.2. Interface Application . . . . . . . . . . . . . . . 25 112 8.1.3. Protocol Handset Suite . . . . . . . . . . . . . . 25 113 8.2. Browser-Based Forms . . . . . . . . . . . . . . . . . . 25 114 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 26 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 116 11. Security Considerations . . . . . . . . . . . . . . . . . . 27 117 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 118 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 27 120 1. Terms 122 Application Configuration Access Protocol (ACAP) -- An Internet 123 protocol (RFC-2244) that provides remote storage and access of 124 configuration and preference information. 126 Activation -- A process in which a mobile station and network become 127 programmed so that a mobile station becomes operable and can be used 128 for cellular service once authorized by the service provider. 130 Authentication -- A procedure used to validate a mobile station's 131 identity. 133 Authentication Center -- An entity that manages the authentication 134 information related to the mobile station. 136 Authentication Key (A-key) -- A secret 64-bit pattern stored in the 137 mobile station. It is used to generate and update the mobile 138 station's shared secret data. The A-key is used in the 139 authentication process. 141 Authorization -- An action by a service provider to make cellular 142 service available to a subscriber. 144 Call -- A temporary communication between telecommunications users 145 for the purpose of exchanging information. A call includes the 146 sequence of events that allocates and assigns resources and 147 signaling channels required to establish a communications 148 connection. 150 Cellular Service Provider -- A licensee of the responsible 151 government agency (in the U.S. a licensee of the Federal 152 Communications Commission) authorized to provide Cellular 153 Radiotelephone Service. 155 Challenge/Response Authentication Mechanism using Message Digest 5 156 (CRAM-MD5) -- An authentication mechanism which is easy to 157 implement, and provides reasonable security against various attacks, 158 including replay. Supported in a variety of Internet protocols. 159 Specified as baseline mechanism in ACAP. CRAM-MD5 is published as 160 RFC 2195. 162 Code Division Multiple Access -- A technique for spread-spectrum 163 multiple-access digital communications that creates channels through 164 the use of unique code sequences. 166 Customer Service Center -- An entity of a service provider that 167 provides user support and assistance to subscribers. 169 Customer Service Representative -- A person that operates from a 170 customer service center and provides user support and assistance to 171 subscribers. 173 Diffie-Hellman Algorithm -- A public-key cryptography algorithm for 174 exchanging secret keys. Uses the equation , where k is the secret 175 key. The equation is executed by each party of the session based on 176 the exchange of independently generated public values. 178 Digits -- Digits consist of the decimal integers 0,1,2,3,4,5,6,7,8, 179 and 9. 181 Dual-mode Mobile Station -- A mobile station capable of both analog 182 and digital operation. 184 Electronic Serial Number (ESN) -- A 32-bit number assigned by the 185 mobile station manufacturer used to identify a mobile station. The 186 ESN is unique for each legitimate mobile station. 188 Home Location Registry (HLR) -- The location register or database to 189 which a MIN is assigned for record purposes such as subscriber 190 information. 192 Message Digest 5 (MD5) -- A one-way cryptographic hash function. 193 Widely deployed in Internet protocols. Published as RFC 1321. 195 Mobile Identification Number (MIN) -- The 10-digit number that 196 represents a mobile station's directory number. 198 Mobile Station (MS) -- A station, fixed or mobile, which serves as 199 the end user's wireless communications link with the base station. 200 Mobile stations include portable units (e.g., hand-held personal 201 units) and units installed in vehicles. 203 Mobile Switching Center (MSC) -- A configuration of equipment that 204 provides cellular radiotelephone service. 206 Mobile Terminal Authorizing System (MTAS) -- A control system that 207 provides the capability to load the CDMA network HLR with mobile 208 station profile information. 210 Number Assignment Module (NAM) -- The mobile station's electronic 211 memory module where the MIN and other subscriber-specific parameters 212 are stored. Mobile stations that have multi-NAM features offer 213 users the option of using their units in several different markets 214 by registering with a local number in each location. 216 Over-the-air Service Provisioning Function (OTAF) -- A configuration 217 of network equipment that controls OTASP functionality and messaging 218 protocol. 220 Over-the-air Parameter Administration (OTAPA) -- Network initiated 221 OTASP process of provisioning mobile station operational parameters 222 over the air interface. 224 Over-the-air Service Provisioning (OTASP) -- A process of 225 provisioning mobile station operational parameters over the air 226 interface. 228 Quick-Net-Connect (QNC) -- An IS-707 data service capability that 229 utilizes the Async Data Service Option number but bypasses the modem 230 connection for a direct connection to an IP-based internet. 232 Roamer -- A mobile station operating in a cellular system or network 233 other than the one from which service was subscribed. 235 Simple Authentication and Security Layer (SASL) -- An Internet 236 protocol (RFC-2222) that provides a framework for negotiating 237 authentication and encryption mechanisms. 239 Service Provider -- A company, organization, business, etc. which 240 sells, administers, maintains, and charges for the service. The 241 service provider may or may not be the provider of the network. 243 Shared Secret Data (SSD) -- A 128-bit pattern stored in the mobile 244 station (in semi-permanent memory) and known by the network. The 245 A-key is used to generate the SSD at the network and in the mobile 246 station for comparison. 248 Wireless Application Protocol (WAP) -- A set of network and 249 application protocols including a datagram protocol (WDP), Transport 250 Layer Security (WTLS), Transaction Protocol (WTP), Session Protocol 251 (WSP), and Application Environment (WAE), which use carrier-based 252 gateways to enable wireless devices to access Web resources. See 253 for specifications and details. 255 2. Feature Descriptions 257 2.1. OTASP Feature Description 259 The Over the Air Service Provisioning (OTASP) feature allows a 260 potential wireless service subscriber to activate new wireless 261 services, and allows an existing wireless subscriber to make 262 services changes without the intervention of a third party. OTASP 263 includes the following: 265 * A way to establish a user profile. 267 * "Over-The-Air" programming of a Number Assignment Module (NAM), 268 IMSI and Roaming Lists, including Data option parameters, and 269 optionally, service provider or manufacturer specific parameters 270 (e.g., lock code, call timer). 272 * An Authentication Key (A-key) Generation procedure. 274 * A-key storage 276 2.2. OTAPA Feature Description 278 The Over-the-Air Parameter Administration (OTAPA) feature allows 279 wireless service providers to update a NAM, IMSI, and Roaming List 280 information in the mobile station remotely without the intervention 281 of a third party. This capability increases flexibility and reduces 282 costs for carriers involved with mass changes that affect every 283 handset, such as area-code splits. 285 OTAPA includes the following: 287 * Update a user's Number Assignment Module (NAM) 289 * Update Data option parameters 291 * Update service provider or manufacturer specific parameters (e.g., 292 Server address(es), lock code, call timer). 294 * Update roaming lists 296 3. Operation 298 3.1. Initial Provisioning Activity 300 A new subscriber needs to give the intended service provider 301 sufficient information (e.g., name, address, etc.) to prove 302 credit-worthiness and establish a record within the service 303 provider's billing system. In addition, the ESN of the mobile 304 station needs to be given to the provider. This may occur in three 305 ways: 307 Voice scenario - A customer care representative collects credit 308 information during a voice conversation. This call is made from a 309 different phone (e.g., wired service) or is initiated using the 310 IS-683A OTASP dialing scheme (i.e., *228xx). 312 Once the user has been authorized, the customer care representative 313 creates a record in the CDMA network HLR, thus allowing use of the 314 CDMA network. In addition, a limited-time N-digit password is 315 created which is tied to the ESN. The choice of N (how many digits) 316 is up to the carrier (as a trade-off between security and user 317 inconvenience). All required provisioning information (including 318 the limited-time password) is loaded into the provisioning server. 320 The user is then told to hang up and call a special number, of the 321 form *228 XX SEND (the XX code is the same as 322 used in the initial voice call). This causes the mobile station to 323 initiate a provisioning session. 325 The mobile station and the provisioning server authenticate, and all 326 required provisioning information is downloaded into the mobile 327 station. The user receives some form of notification once the 328 activity is complete. This notification can be an audible tone or a 329 text message on the mobile station display. (The form and content of 330 this notification can be part of the provisioning data downloaded by 331 the mobile station.) Once this initial provisioning activity is 332 complete the user has a fully authorized mobile station ready for 333 use. 335 Forms scenario - An interactive user interface is presented via a 336 browser on the mobile station. The subscriber fills in the 337 requested information. (Note that entering non-numeric data presents 338 some user interface challenges on many mobile devices.) 340 A back-end server validates the information, and if possible, the 341 customer is authorized, a limited-time password is generated, HLR 342 and provisioning server records are created and the actual OTASP 343 operation begins. Otherwise, a voice call is made to a customer 344 care representative. 346 Desktop scenario - The subscriber uses a desktop (or in-store kiosk) 347 web browser to contact the carrier, and enters the usual personal 348 information. 350 The carrier's server validates the information, and if possible, the 351 customer is authorized, a limited-time password is generated, HLR 352 and provisioning server records are created, and the subscriber is 353 told to dial a special number on the handset. Once this code is 354 entered, the actual OTASP operation begins. Otherwise, the user is 355 asked to make a voice call to a customer care representative. 357 3.2. OTASP for Authorized Users 359 Users already authorized for use of the CDMA network can also 360 initiate provisioning activity. This could happen after being 361 directed to do so by a Customer Care representative, either from a 362 phone conversation or via mail notification. This type of OTASP 363 activity is needed in cases where the carrier desires to upgrade 364 CDMA parameters in the mobile stations or in cases where mobile 365 station troubleshooting is needed. 367 This type of OTASP occurs in similar fashion to the initial OTASP 368 activity. The mobile station downloads the new provisioning 369 information in the same way. 371 3.3. OTAPA Activity 373 Typical OTAPA capability involves upgrading a large number of mobile 374 stations. OTAPA activity needs to be performed in a manner that 375 does not impose on revenue bearing CDMA network activity. OTAPA 376 operations are initiated at the customer care center. This can be 377 accomplished by queuing a notification to the mobile station (via 378 1-way SMS or special caller-ID) after the provisioning server has 379 the updated configuration data. OTAPA activity will not occur until 380 the mobile station has acquired CDMA service on the carrier's 381 network and the notification has reached the mobile station. 383 Alternatively, OTAPA can be handled by including a recheck interval 384 in the set of data used to provision the mobile station. When using 385 a low-overhead protocol, such as ACAP [ACAP], it is reasonable to 386 have a mobile station check in periodically to see if anything has 387 changed. The time of day and/or day of week that such rechecks 388 should occur could be included in the provisioning data. 390 OTAPA activity can be terminated at any time due to user call 391 activity. 393 4. Requirements 395 4.1. General Requirements 397 IS-683A OTASP operations occur between a mobile station and an 398 over-the-air service provisioning function (OTAF) using IS-95A 399 traffic channel data burst messages. OTASP/OTAPA via data services 400 require that the CDMA carrier have an IS-707 data services capable 401 network. The IS-707 service must be either Packet Data Service 402 (IS-707.5) or Quick-Net-Connect (QNC). 404 The mobile station must support: 406 * IS-707 Data Service capability 408 * Packet/QNC RLP protocol 410 * PPP protocol to peer to the IS-707 IWF 412 * IP protocol to provide the network layer for routing to the 413 provisioning server 415 * A transport layer for end-to-end communication (such as TCP) 417 * Authentication and optionally encryption 419 * Application software to handle the provisioning protocol and 420 memory access. 422 * Domain Name System (DNS) query capabilities sufficient to obtain 423 the (IP) address of the provisioning server (or the provisioning 424 server's address could be provided during PPP negotiation). 426 Lastly, the ability must exist for the mobile to make a data call 427 and (optionally) a voice call without a MIN. 429 4.2. OTASP Requirements 431 The OTASP function requires the mobile station to originate an 432 IS-707 data call and (optionally) a voice call using a completely 433 unprovisioned mobile station. The CDMA network must support this 434 capability. 436 OTASP via data services uses a provisioning server that contains the 437 parameter information for mobile stations. The authorizing agent 438 (or software) at the customer care center must be able to add user 439 and mobile station information into both the CDMA network HLR and 440 the provisioning server during the initial authorizing process. The 441 provisioning server must be capable of servicing a mobile as soon as 442 its record is created. 444 4.3. OTAPA Requirements 446 IS-683A OTAPA is performed by a mobile-terminated call that 447 downloads parameters to the mobile station. OTAPA calls occur 448 without user interaction. 450 In order to perform OTAPA via data services the network needs to 451 direct the mobile station to initiate a special-purpose data call. 452 Several existing methods can be used to implement this capability, 453 for example, a mobile-terminated one-way SMS message. The SMS 454 message content can contain any information required by the mobile 455 station. The mobile station would need a simple parser of SMS 456 messages in order to know when to originate an OTAPA call, as 457 opposed to normal SMS message processing. The OTAPA call would be 458 performed in similar fashion to a registration call. More 459 specifically, the user would not be informed of the call activity. 461 There are alternative means that can be employed to initiate OTAPA 462 activity; for example, a mobile-terminated voice call with caller-ID 463 using a specialized telephone number. Another alternative is for 464 mobile stations to periodically check in with the provisioning 465 server to check for updated information. ACAP, for example, is 466 designed for such a model. The recheck interval, as well as the 467 time of day and/or day of week that such checks should be used, can 468 be part of the provisioning data sent to the mobile stations. 470 4.4. Provisioning Server Requirements 471 IS-683A utilizes an over-the-air service provisioning function 472 (OTAF) to perform the network-side provisioning activity. 473 OTASP/OTAPA via data services replaces the OTAF with a provisioning 474 server. The provisioning server resides on an IP network within the 475 controlled confines of the carrier. The provisioning server must 476 perform all the service provisioning and parameter administration 477 functions that the OTAF provides. The provisioning server must also 478 have an interface to the carrier's Mobile Terminal Authorizing 479 System (MTAS). This interface serves to synchronize the 480 provisioning server with the information in the MTAS. The specific 481 requirements of this interface depend on the capabilities and 482 interfaces of the carrier's customer care center system(s). The 483 provisioning server must be capable of receiving dynamic updates 484 from the MTAS and have the provisioning information immediately 485 available for downloading into the chosen mobile station. A 486 standard ACAP server provides an excellent means to meet these 487 requirements. 489 The provisioning server must be capable of performing an 490 authentication procedure with the mobile station. This 491 authentication mechanism must be capable of authenticating both the 492 mobile station and the provisioning server. 494 4.5. Security Requirements 496 OTASP requires that an authentication procedure be performed to 497 validate the mobile station to the provisioning server, while OTAPA 498 requires a mechanism where the mobile validates the server. 500 The provisioning server must be capable of either: 502 * OTAF A-key generation using a Diffie-Hellman mechanism 504 Or: 506 * Receiving A-keys from the carrier network. 508 Since data OTASP/OTAPA operates over IP within the carrier's 509 network, end-to-end encryption between the mobile station and the 510 provisioning server should be considered as a future enhancement. 511 End-to-end encryption protects against attacks from within a 512 carrier's network, and safeguards the provisioning data (for 513 example, roaming lists). 515 5. Architecture 517 5.1. ACAP over TCP/IP 519 Figure 1 shows a provisioning server in the carrier's intranet which 520 supports the Application Configuration Access Protocol (ACAP, RFC 521 2244). An administrative client in the customer care domain updates 522 this server using ACAP. Handsets are provisioned and configured 523 using a small ACAP client. 525 [Figure 1 -- see PostScript version] 527 ACAP is an open Internet protocol designed to solve the problem of 528 client access to configuration and related data. Among its primary 529 goals are protocol simplicity, support for thin clients, and ease of 530 operation over limited bandwidth. ACAP provides a high degree of 531 extensibility, especially in authentication mechanisms, specialized 532 attribute handling, and data management. 534 5.1.1. Mobile Authentication and A-Key Generation 536 The mobile client authenticates with the ACAP server prior to 537 performing any activities. Authentication uses the mobile's ESN and 538 a shared secret. Provisioned mobiles derive the shared secret from 539 the A-Key; unprovisioned mobiles use a limited-time password as the 540 secret. 542 The limited-time password is provided to the user by the Customer 543 Care representative during the initial call (as instructions to dial 544 a specific number). This code is N digits long. The carrier 545 selects the number of digits, as a trade-off between security and 546 user convenience. 548 The baseline ACAP authentication mechanism uses the shared secret 549 plus a random challenge from the server as input to a one-way 550 cryptographic hash function (specifically, keyed-MD5). This is 551 analogous to the existing IS-683A authentication mechanism which 552 uses a random challenge and the CAVE algorithm. 554 An A-Key is generated using a Diffie-Hellman exchange, as is done in 555 IS-683A. 557 5.1.2. Mobile Identification 559 Provisioning records are identified using the ESN and the current 560 NAM in use. 562 5.1.3. ACAP Server 564 As a standard ACAP server, the provisioning server includes 565 configurable datasets and dataset inheritance for the management of 566 the data stores. 568 The administrative client can use the same simple ACAP protocol to 569 load and modify the ACAP server as the mobile stations uses for 570 provisioning. While any implementation-specific mechanisms 571 available from the server vendor could instead be used for this 572 purpose, the ability to use ACAP can greatly simplify the 573 administrative client, as well as make it independent of the server. 575 ACAP includes an authentication framework (Simple Authentication and 576 Security Layer, SASL, RFC 2222)[SASL]. SASL allows any standard or 577 custom authentication and encryption mechanism to be used. One of 578 the most important features of SASL is that it is designed for a 579 world in which what is "good enough" security today isn't good 580 enough tomorrow. As the threat model changes, SASL allows 581 higher-strength mechanisms to be easily added while supporting 582 already deployed clients and servers. SASL is achieving widespread 583 deployment in a number of Internet protocols. 585 Strongpoints: Since the ACAP protocol was designed for precisely 586 this type of provisioning activity, its adoption can greatly reduce 587 the cost, time to market, and support required for the provisioning 588 server. Additionally, the ACAP protocol provides an open standard 589 method for mobile stations and other systems to access the 590 provisioning server. Commercial ACAP servers are being developed by 591 numerous companies. The ACAP client code is very small and simple, 592 and thus can be incorporated into virtually any mobile device at 593 minimal cost. As an open standard, the ACAP protocol has benefited 594 from years of review and experience. 596 5.1.4. Overview of ACAP Structure 598 ACAP organizes data by datasets. The structure of a dataset is 599 defined by the dataset class. Generally, ACAP servers do not have 600 knowledge of dataset classes. This allows the dataset to be 601 expanded without modifying the server in any way. A dataset is an 602 instantiation of the dataset class, which is a logical definition of 603 what is in a dataset, and how it is used. 605 Datasets contain entries. Entries contain attributes and values. 606 Attributes and values are actually metadata, such as name, length, 607 and value. Any entry can also be a dataset (datasets are 608 hierarchical). 610 For example, consider the ACAP addressbook dataset class, designed 611 to hold names, email addresses, phone numbers, and related 612 information for a person's contacts. A given user may have one or 613 more addressbook datasets. Each entry holds information about one 614 person or entity. Attributes in the entry hold specific items of 615 information, such as the given name, surname, various email 616 addresses, phone numbers, and so forth. If an entry is a list of 617 people (such as a mailing list or specific group of people), it is a 618 subdataset, containing its own entries. 620 Some clients may look at only a subset of the attributes. For 621 example, a mobile handset ACAP client may download only the alias 622 (nickname), name, primary phone number and email address of each 623 entry, while a desktop client may access all attributes. 625 5.1.5. Data Organization and Capabilities 627 ACAP provides custom hierarchical datasets. Server data can be 628 organized to fit the needs of the applications using the dataset. 630 In OTASP/OTAPA over ACAP, data on the server is organized to both 631 take advantage of ACAP capabilities and to use items that are 632 identical to IS-683A, allowing for reuse of IS-683A handset engines. 634 ACAP servers also support data inheritance. All data items which 635 are physically in the inherited dataset and not in the inheriting 636 dataset logically also exist in the inheriting dataset. This is 637 recursive, as the inherited dataset can itself inherit from another 638 dataset. This powerful concept allows potentially large groups of 639 mobile stations to inherit items from a single common entity. For 640 example, preferred roaming lists can be stored in datasets based on 641 geographic areas, and automatically inherited by an individual 642 mobile station in that area. The roaming lists could be further 643 subdivided, for example based on tiers of free NVRAM in the mobile. 644 The mobile client need not be aware of this; it happens entirely on 645 the server. 647 ACAP uses trees to provide the data hierarchy. These data trees can 648 be viewed as similar to the directory/file structure used with all 649 common operating systems. The built-in inheritance mechanism, 650 together with the hierarchical structure, makes it extremely easy to 651 update general data without disturbing specific data. 653 Datasets exist within the user, group, and host hierarchies. The 654 user hierarchy holds datasets which belong to individual users. The 655 group hierarchy holds datasets which belong to groups (for example, 656 the "Region." groups in section 5.1.6.3). The host hierarchy holds 657 datasets which are for specific machines or systems. 659 In addition to providing customizable data trees, ACAP also provides 660 several standard datasets for all clients. There is a capabilities 661 dataset that contains information on custom functionality and 662 enhanced features available to a specific client or at the site 663 generally. This allows a server to advertise any protocol 664 extensions, specialized attribute handling, or other enhanced 665 functionality it supports. A client that needs to use these 666 features can thus easily determine what is available before trying 667 to use them. 669 5.1.5.1. Structure 670 We divide the data accessed by the client into provisioning items, 671 group items, and client state items. Provisioning data contains NAM 672 items and requested-data items. Group items (such as preferred 673 roaming lists), are not specific to any mobile device. Group items 674 physically exist in their own datasets, but through inheritance 675 logically appear in client datasets. 677 The mobile stations always read data from provisioning entries and 678 write data to client state entries. This structure makes both 679 mobile clients and server configuration easy and simple, while 680 allowing for extensive custom and diagnostic capabilities. 682 5.1.5.2. Conventions 684 "" This signifies the empty string (used here for ACAP entries). 686 ~ This is shorthand for "user/". It is part of the ACAP 687 protocol. 689 5.1.6.3 Dataset 691 Provisioning information is located in the "OTAP" dataset class. 692 (The full specification of this dataset will be published in a 693 subsequent document.) The prefix "Provision." is used for items that 694 are to be downloaded to the mobile, and the prefix "Client." is used 695 for items which the client stores on the server. 697 Provisioning data within the OTAP dataset is organized as a series 698 of items, each of which is stored in its own entry. The entry name 699 is the item name, and the "OTAP.VALUE" attribute contains the item 700 value. This structure permits change notification on a per-item 701 basis. 703 We chose the "Provision" and "Client" names to simplify various 704 operations. For example, the mobile client can easily download all 705 changed provisioning items by performing a search which returns the 706 "OTAP.VALUE" attribute of all entries whose name begins with 707 "Provision" and whose modtime is greater than the last time the 708 client retrieved data. An administrative client can easily generate 709 a report of all clients which have not received the most recent 710 update by searching for all entries named "Client" whose 711 "OTAP.modtime" attribute is less than the desired value. 713 A partial list of items follows. 715 5.1.6.1. Entries and Attributes 717 dataset.inherit 718 This is a standard ACAP attribute that identifies the location of 719 inherited data. It exists in the "" entry (the entry with the empty 720 name) within each dataset. 722 5.1.6.2. NAM Records 724 The OTAP dataset class contains an entry for each provisioned 725 mobile. The standard location for provisioning records is: 727 /OTAP/USER/// 729 This tree format allows multiple NAMs per ESN. The specific entries 730 contain data in IS-683A parameter block types. 732 For example, the CDMA NAM would be stored in an entry called: 734 /OTAP/USER///Provision.CDMA-NAM/ 736 The entries below show how NAM records would be organized on the 737 ACAP server: 739 CDMA/Analog NAM 741 Entry-Path: /OTAP/USER///Provision.CDMA-AMPS-NAM/ 743 OTAP.Value: {17} xx xx xx ... xx 745 The CDMA/Analog NAM entry from IS-683A (section 4.5.2.1) 746 consists of at least 129 information bits, depending on the 747 number of SID NID list entries. This is stored as 17 (or more) 748 octets of binary data (padding is used to ensure an integral 749 number of octets). 751 Mobile Directory Number 753 Entry-Path: /OTAP/USER///Provision.MOBILE-DN/ 755 OTAP.Value: {10} nnnnnnnnnn 757 The Mobile Directory Number from IS-683A contains BCD-encoded 758 digits representing the phone number. This is stored as a 759 string of 10 or more ASCII digits, e.g., "6195551212". 761 CDMA NAM 763 Entry-Path: /OTAP/USER/// Provision.CDMA-NAM/ 765 OTAP.Value: {13} xx xx xx ... xx 767 The CDMA-NAM entry from IS-683A (section 4.5.2.3) consists of at 768 least 100 information bits, depending on the number of SID-NID 769 list entries. This is stored as 13 (or more) octets of binary 770 data (padding is used to ensure an integral number of octets). 772 IMSI_T 774 Entry-Path: /OTAP/USER/// Provision.IMSI_T/ 776 OTAP.Value: {7} xx xx xx xx xx xx xx 778 The IMSI_T entry from IS-683A (section 4.5.2.4) consists of 55 779 bits of information in five fields. This is stored 780 left-justified in 7 octets of binary data. 782 5.1.6.3. Server Roaming Lists 784 The ACAP Server will have an entry for each different roaming list 785 configuration for a carrier. The example below assumes that the 786 desired differentiation for the roaming list is geographic, with 787 subdivisions for tiers of mobile free NVRAM It shows that for each 788 region there exists a set of roaming lists per free NVRAM range. 789 Note that a carrier can easily implement different or further 790 differentiation (e.g., by phone vendor or product type) by simply 791 changing the dataset tree and assigned the appropriate value to the 792 "dataset.inherit" attribute in the provisioning records. 794 /OTAP/GROUP/region.NorthEast/free-nv.128-512/ 795 preferred.roaming.list/OTAP.Value 796 /OTAP/GROUP/region.NorthEast/free-nv.512-1024/ 797 preferred.roaming.list/OTAP.Value 798 /OTAP/GROUP/region.SouthEast/free-nv.128-512/ 799 preferred.roaming.list/OTAP.Value 800 /OTAP/GROUP/region.SouthEast/free-nv.512-1024/ 801 preferred.roaming.list/OTAP.Value 802 /OTAP/GROUP/region.NorthWest/free-nv.128-512/ 803 preferred.roaming.list/OTAP.Value 804 /OTAP/GROUP/region.NorthWest/free-nv.512-1024/ 805 preferred.roaming.list/OTAP.Value 806 /OTAP/GROUP/region.SouthWest/free-nv.128-512/ 807 preferred.roaming.list/OTAP.Value 808 /OTAP/GROUP/region.SouthWest/free-nv.512-1024/ 809 preferred.roaming.list/OTAP.Value 811 5.1.6.4. Requested-Data Record 813 Inside the OTAP dataset is an entry with the name 814 "Provision.Requested-Data", which contains one attribute called 815 "OTAP.Requested-Data". This attribute is multi-valued. It is 816 either NIL or contains a list of strings. Each string is the name 817 of one element of data that the server requests the client to 818 supply. 820 After authenticating, the ACAP client issues a SEARCH command to 821 retrieve the values of the "OTAP.Requested-Data" attribute of the 822 "Provision.Requested-Data" entry. The client processes the returned 823 values (if any) by issuing a STORE command to set one or more 824 attributes in the "Client" entry. The value of each attribute is 825 either the corresponding mobile value (which may be an empty string 826 if the item has no value), or the special value "[N/A]" if the item 827 does not exist or is unknown on the mobile. 829 This mechanism is quite general, and can be used in the normal OTASP 830 case to modify the mobile's dataset as appropriate for the condition 831 of the mobile. For example, the inheritance could be set based on 832 the amount of NVRAM available, to cause one set of preferred roaming 833 list data or another to be used. This mechanism can also be used in 834 other situations, such as to retrieve a complete set of mobile 835 configuration parameters for diagnostic reasons. 837 5.1.6.5. Sample Server Entry 839 The entry below is an excerpt of a sample ACAP server dataset entry 840 for a single mobile station, with an ESN of FB9876E and using NAM 1: 842 /OTAP/USER/FB9876E/1/ 844 entry = "" 845 dataset.inherit = "/OTAP/GROUP/region.NorthEast/ 846 free-nv.128-512/preferred.roaming.list/ 847 OTAP.Value/" 849 entry = "Provision.Requested-Data" 850 OTAP.Requested-Data = ("Phone-Make" "Phone-Model" "SW-Rev" 851 "Free-NVRAM") 853 entry = "Client" 854 OTAP.Phone-Make = "Qualcomm" 855 OTAP.Phone-Model" = "pdQ1900" 856 OTAP.SW-Rev = "001.030.0908" 857 OTAP.Free-NVRAM = "65536" 858 OTAP.Last-Modtime = "199812181703" 860 entry = "Provision.Mobile-DN" 861 OTAP.Value = {10} 619 555 1234 863 entry = "Provision.CDMA-NAM" 864 OTAP.Value = {13} xx xx xx xx xx xx xx xx xx xx xx 865 xx xx 867 This dataset shows not only provisioning data which was downloaded 868 into the mobile station, but also the items of client data requested 869 by the server (the Requested-Data attribute) and the values of those 870 items (the "Client" entry). It also indicates that the mobile 871 client successfully stored the values associated with the modtime 872 "199812181703". In addition, it shows that this client inherits 873 data (i.e., roaming lists) from the "NorthEast" region. 875 5.1.7. Administrative Client 877 The administrative client loads initial provisioning information 878 into the server, including specifying the roaming list to inherit. 879 The administrative client also updates provisioning server records 880 as needed, and retrieves data for reports (such as a list of clients 881 which have not yet been updated). 883 Data is loaded into provisioning records by using the ACAP STORE 884 command. The administrative client authenticates to the ACAP server 885 using credentials that permit access to datasets for mobiles. 887 When a new mobile is authorized for service, the administrative 888 client creates the dataset by storing into it values that are 889 specific for the device. It also sets the "dataset.inherit" 890 attribute so that values which are not tied to the specific mobile 891 are inherited as appropriate. 893 * Updates to user records 895 Existing user records may need updating from time to time. For 896 example, a user may change service plans or purchase an 897 additional or replacement mobile device, or the carrier may 898 need to modify some aspect of provisioned data. 900 * Perusal and editing of provisioning records 902 The administrative client can provide general browse and edit 903 capability for user records. 905 * Report generation 907 The administrative client can extract data from the ACAP server 908 in order to generate reports. For example, after OTAPA 909 activity, a carrier may wish to identify those mobiles which 910 have not yet been updated. 912 * Queuing of OTAPA sessions 914 Depending on the OTAPA update procedures chosen (e.g., SMS, 915 CLID, periodic recheck), the administrative client may be 916 involved in initiating the activity. This may or may not use 917 an interface to the provisioning server. 919 5.1.8. Mobile Client 920 The ACAP mobile client is implemented as a state machine that 921 performs the equivalent of IS-683A provisioning parameter 922 information exchange and non-volatile memory storage. The ACAP 923 Client state machine diagram (Figure 2) and descriptions are below. 925 [Figure 2 -- see PostScript version] 927 * Establish Transport Layer/Authenticate 929 Authentication and/or encryption can occur at the application 930 layer and/or at the network/transport layer. 932 Basic ACAP authentication occurs in the application layer 933 (i.e., within the ACAP session), and in its baseline form uses 934 the CRAM-MD5[CRAM-MD5] mechanism. If desired, other mechanisms 935 can be used which provide more protection and encryption. This 936 occurs after the transport layer is established, as shown in 937 the client state machine diagram above 939 Figure 3 shows the CRAM-MD5 authentication mechanism for an 940 unprovisioned mobile. In the case of provisioned mobiles, the 941 shared secret is derived from the A-Key, instead of the 942 limited-time N-digit code used for unprovisioned devices. 944 Use of basic ACAP authentication is preferred for initial 945 implementations of data-OTASP because it is simple, easy to 946 implement, and all procedures and methods are in place. 947 Stronger SASL mechanisms and/or IPSec can be rolled out in the 948 future without disrupting the deployed base. 950 [Figure 3 -- see PostScript version] 952 * Requested-data SEARCH 954 The mobile ACAP client issues a search command asking the 955 server to return the attribute "OTAP.Requested-Data" in the 956 entry "Requested-Data". 958 * Receive requested-data values 960 The server instructs the client to store attributes by 961 returning one or more values of requested-data in response to 962 the Requested-Data SEARCH. 964 For example, the attribute "OTAP.Requested-Data" in the entry 965 "Requested-Data" might contain four values: "phone-make", 966 "phone-model", "SW-Rev", and "Free-NVRAM". 968 * STORE attribute list 970 If the response to the requested-data SEARCH returns any 971 values, the client issues a STORE command. Each attribute in 972 the STORE command corresponds to one item of requested-data. 973 If the client does not recognize an item, it stores the string 974 "[n/a]". 976 Continuing with our example, the client uses this STORE command 977 to write four attributes into the "Client" entry. Each 978 attribute name is identical to one value of the 979 OTAP.Requested-Data" attribute (with the prefix "OTAP." added). 980 Each attribute value is determined by the respective mobile 981 value. 983 In our example, this STORE command sets the following 984 attributes and values: 986 - "OTAP.Phone-Make" = "Qualcomm 987 - "OTAP.Phone-Model" = "pdQ1900 988 - "OTAP.SW-Rev" = "001.030.0908" 989 - "OTAP.Free-NVRAM" = "65536" 991 * Provisioning data SEARCH 993 The mobile ACAP client issues a search command to retrieve any 994 items of provisioning data that have changed since it last 995 checked in (which in the initial session retrieves all 996 provisioning data). 998 This SEARCH command asks the server to return the "OTAP.Value" 999 attribute of any entries whose name starts with "provision." 1000 (case-insensitive) and whose modtime is greater than the 1001 supplied value (which is zero for an unprovisioned mobile). 1003 * Receive provisioning data and modtime 1005 The server returns the provisioning items, each as one entry 1006 name and one attribute value. The server response to the 1007 SEARCH command includes the modtime of the latest entry 1008 returned. 1010 * Save values 1012 The mobile writes the returned values into NVRAM. 1014 * STORE modtime 1016 The ACAP client stores the returned modtime on the server as an 1017 acknowledgement that the data was received and NVRAM updated. 1019 * LOGOUT 1021 The client issues the LOGOUT command. 1023 * Close transport layer 1024 The client closes the TCP connection. 1026 * End call 1028 The data call is terminated. 1030 5.2. WAP with ACAP 1032 An advantage of the ACAP solution is that is can easily coexist with 1033 a WAP-based mechanism, giving carriers more options. 1035 A carrier can deploy handsets into its service area which use 1036 WAP-based provisioning, if desired, alongside those which use ACAP 1037 provisioning. All that is required is that the WAP server contain a 1038 small ACAP client (or an interface to an ACAP server). 1040 Figure 4 shows how mobile stations can be configured using a WAP 1041 browser. By using an ACAP server for provisioning, carriers are 1042 free to simultaneously deploy mobile stations that use either WAP or 1043 ACAP, as desired. In either case, the ACAP server is the source for 1044 provisioning data. 1046 [Figure 4 -- see PostScript version] 1048 5.3. Network-Resident vs. Configuration Data 1050 It is useful to recognize that wireless devices access two different 1051 types of carrier-provided data: network-resident and configuration. 1052 Network-resident data exists primarily within the carrier's network. 1053 Examples include account status, billing detail, service plan 1054 options, etc. While mobiles may access this information for user 1055 display, it resides in the network. Configuration data, in 1056 contrast, affects the operation of the handset, is usually not shown 1057 to the user, and must persist in the device. 1059 For network-resident data access, the obvious choice is the web. 1060 The data is highly interactive and time-variant, making web browsers 1061 a reasonable solution. Any appropriate web browser can be used. 1062 There are many good reasons for having a web browser in a wireless 1063 device which contains a display and is capable of user interaction. 1065 For configuration data, the best solution is to use ACAP. ACAP is 1066 optimized for the job, can be implemented quickly, requires a very 1067 small amount of memory, and does not depend on a display or any user 1068 interaction capability. 1070 Trying to use the same access method for both types of data 1071 unnecessarily complicates the solution, leading to increased design, 1072 development, and debug time and expense. It makes it more difficult 1073 to offer low-cost devices. Since the two types of data 1074 fundamentally differ, it is good engineering practice to select 1075 optimal code and protocols for each. 1077 5.4. Intellectual Property Issues 1079 There are no known intellectual property issues with the ACAP 1080 solution. The ACAP specification was developed within the IETF, and 1081 no ownership, patent, or other IP claims have been asserted. 1082 Multiple independent vendors are developing ACAP clients and 1083 servers, in addition to the existing usage in deployed products. 1085 6. Handset Protocol Suites 1087 6.1. ACAP over TCP/IP 1089 Figure 5 depicts the mobile station protocol suite for the ACAP over 1090 TCP/IP solution. The mobile station is capable of supporting both 1091 IS-683A OTASP and OTASP over ACAP. 1093 [Figure 5 -- see PostScript version] 1095 7. IS-683A Compatibility 1097 7.1. OTASP Operations 1099 To maximize compatibility and allow for reuse of IS-683A handset 1100 code, the data formats used in OTASP over ACAP are identical to 1101 those used in IS-683A. Section Data Organization and Capabilities 1102 discusses this in more detail. 1104 OTASP via IS-683A requires custom design and development for the 1105 specific CDMA infrastructure used by a carrier. This can greatly 1106 limit the data management capabilities and significantly reduces the 1107 extensibility of the solution. Conversely, OTASP over data can be 1108 implemented on a generic IP network using an Internet 1109 standards-based capability that provides extensible provisioning 1110 activities for carriers. 1112 OTASP over data uses a traffic channel whereas IS-683A OTASP runs 1113 over the limited-bandwidth signaling channel. 1115 IS-683A OTASP operations are inherently simultaneous voice and data. 1116 This allows the customer care representative to extract information 1117 from the mobile station while conversing with the user. OTASP over 1118 data services is a data-only solution (at least for now). This 1119 makes OTASP operations slightly more sequential and potentially 1120 problematic. Simultaneous voice and data will alleviate this issue. 1122 7.2. OTASP Call Flow 1124 The call flow diagram (Figure 6) depicts the message sequence and 1125 operations for a typical IS-683A OTASP (provisioning) call. Any 1126 data-OTASP solution must perform all the functions of the IS-683A 1127 OTASP call. The proposed solution meets these requirements. 1129 [Figure 6 -- see PostScript version] 1131 7.3. OTAPA Operations 1133 Data-OTAPA requires the ability to instruct mobiles to originate a 1134 data call to the provisioning server. Several viable approaches are 1135 discussed in sections 3.3 and 4.3. 1137 OTAPA over data has the potential to require far less channel 1138 resources to download new information to mobile stations. The ACAP 1139 server inherently only communicates changes to the clients, thus 1140 only changed information needs to be downloaded to the mobile 1141 stations using OTAPA over data via ACAP. 1143 7.4. OTAPA Call Flow 1145 The call flow diagram (Figure 7) depicts the message sequence for a 1146 typical IS-683A OTAPA operation. Any data-OTAPA solution must 1147 perform all the functions of the IS-683A OTAPA call. The proposed 1148 solution meets these requirements. 1150 [Figure 7 -- see PostScript version] 1152 8. Alternative Methods 1154 8.1. IS-683A over TCP/IP 1156 One alternative is to port IS-683A to TCP, remaining as close as 1157 possible to the IS-683A protocol exchange. 1159 Figure 8 depicts the architecture and communications backbone to 1160 support OTASP/OTAPA via IS-707 data services with a provisioning 1161 server based on the IS-683A OTAF function. 1163 [Figure 8 -- see PostScript version] 1165 8.1.1. OTAF Server 1167 This provisioning server is modeled after the IS-683A OTAF. The 1168 OTAF server performs the specific operations and messaging of 1169 IS-683A OTAF. This includes A-key reauthentication procedures. 1171 Strongpoints: 1173 (1) OTAF and mobile station behavior mirrors IS-683A (reduced 1174 duplicate software in mobile station). Nearly all procedures fully 1175 defined. 1177 Drawbacks: 1179 (1) The OTAF server would need to be custom-designed and built. 1181 (2) No inherent data manipulation capabilities in the OTAF server. 1182 All required or desired data management activities would have to be 1183 built from scratch. 1185 (3) Interface application would require a non-standard interface 1186 (and therefore proprietary) to OTAF server. 1188 (4) End-to-end encryption scheme still needed for full security. 1190 8.1.2. Interface Application 1192 This function loads all required provisioning-related information 1193 from the CDMA network information system to the OTAF server. This 1194 includes the queuing of provisioning transactions and data. 1196 8.1.3. Protocol Handset Suite 1198 Figure 9 depicts the mobile station protocol suite for the IS-683A 1199 over TCP/IP solution. The OTASP client is capable of supporting 1200 both IS-683A OTASP activities or OTASP activities over the data 1201 transport. 1203 [Figure 9 -- see PostScript version] 1205 8.2. Browser-Based Forms 1207 Another alternative is to use forms embedded in web pages. 1209 Encapsulating the provisioning data into custom tags embedded in a 1210 web form is an idea that at first seems attractive. There are a lot 1211 of advantages in having a browser in the handset, web servers are 1212 very widely deployed, and everyone is familiar on some level with 1213 the web. 1215 However, a meta-protocol for this would need to be designed, and a 1216 fully detailed specification produced. This solution requires 1217 custom software on the provider side to handle the meta-protocol. 1219 It additionally requires handset vendors to add custom software in 1220 the handset browser to handle this protocol. 1222 This solution would require a provisioning-capable browser in every 1223 phone. While it may be desirable to have a browser, the decision to 1224 require it needs to be considered carefully, especially in light of 1225 the memory requirements it would impose on all devices. 1227 This solution would complicate the handset browser, by requiring it 1228 to handle provisioning as well as browsing. As provisioning and 1229 browsing are functionally dissimilar, this code is not a natural fit 1230 within the browser. Implementing this solution would require a 1231 significant increase in development and debug resources, and thus 1232 negatively impact time-to-market and cost. 1234 Also because the web is functionally dissimilar, a high level of 1235 carrier-side customization would be needed, leading to reduced 1236 vendor choice and increased deployment costs. 1238 This approach would layer custom data on top of a standard protocol. 1239 This would require design work, and would not have much time for 1240 open review before deployment, greatly increasing the risk. By 1241 contrast, ACAP has had years of open review and refinement. 1243 This approach also limits the extensibility of the solution. ACAP, 1244 conversely, is very extensible. Because ACAP is such a simple 1245 protocol, it can be added to a wide variety of applications at low 1246 cost. This allows increasing numbers of applications on the mobile 1247 device to share information with servers as well as desktop 1248 applications. 1250 9. Conclusion 1252 ACAP provides a high degree of extensibility, especially in 1253 authentication mechanisms, custom attribute handling, and data 1254 management. By using an Internet standard protocol, 1255 interoperability and integration with a variety of equipment is 1256 possible, and carriers are not locked into any vendor. It is also 1257 easier to add new levels of service and capabilities, especially 1258 integration with future subscriber devices and applications (e.g., 1259 email). 1261 Since an ACAP client is so small, it can be incorporated into 1262 virtually any device, even low-end ones without displays, and can be 1263 added without sacrificing other features. The simplicity of the 1264 client and protocol directly translate to shorter development cycles 1265 and faster time-to-market. 1267 Because the ACAP protocol was designed for precisely this type of 1268 provisioning activity, its adoption can greatly reduce the cost, 1269 time to market, and support required for the provisioning server as 1270 well as the handsets. As an open standard, the ACAP protocol has 1271 benefited from years of review and experience. 1273 Another advantage of the ACAP solution is that is can easily coexist 1274 with a WAP-based mechanism, giving carriers more options and 1275 reducing the minimal requirement burden on mobile devices. 1277 A carrier can deploy handsets into its service area which use 1278 WAP-based provisioning, if desired, alongside those which use ACAP 1279 provisioning. By using an ACAP server for provisioning, carriers 1280 are free to simultaneously deploy mobile stations that use either 1281 WAP or ACAP, as desired. 1283 The lack of intellectual-property issues further adds to ACAP's 1284 appeal. 1286 10. References 1288 [ACAP] Newman, C., Myers, J., "ACAP -- Application Configuration 1289 Access Protocol", RFC 2244, November 1997 1291 [CRAM-MD5] Klensin, J., Catoe, R., Krumviede, P., "IMAP/POP 1292 AUTHorize Extension for Simple Challenge/Response", RFC 2195, 1293 September 1997 1295 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 1296 RFC 2222, October 1997 1298 11. Security Considerations 1300 Security is discussed in many sections of this document. In 1301 particular, the need and methods to guard against unauthorized 1302 updating of handsets, usurpation of newly-created accounts, 1303 compromise of handset security values, and disclosure of carrier 1304 proprietary data and handset parameters is covered. 1306 12. Acknowledgments 1308 Jim Willkie and Marc Phillips contributed greatly to this document. 1309 Their help is very much appreciated. 1311 13. Author's Address 1313 Randall Gellens +1 619 651 5115 1314 QUALCOMM Incorporated randy@qualcomm.com 1315 6455 Lusk Boulevard 1316 San Diego, CA 92121-2779 1318 Gellens [Page 27] Expires September 1999