The call flow diagram (Figure 6) depicts the message sequence and
operations for a typical IS-683A OTASP (provisioning) call. Any
data-OTASP solution must perform all the functions of the IS-683A
OTASP call. The proposed solution meets these requirements.
[Figure 6 -- see PostScript version]
7.3. OTAPA Operations
Data-OTAPA requires the ability to instruct mobiles to originate a
data call to the provisioning server. Several viable approaches are
discussed in sections 3.3 OTAPA Activity and 4.3 OTAPA
Requirements.
OTAPA over data has the potential to require far less channel
resources to download new information to mobile stations. The ACAP
server inherently only communicates changes to the clients, thus
only changed information needs to be downloaded to the mobile
stations using OTAPA over data via ACAP.
7.4. OTAPA Call Flow
The call flow diagram (Figure 7) depicts the message sequence for a
typical IS-683A OTAPA operation. Any data-OTAPA solution must
perform all the functions of the IS-683A OTAPA call. The proposed
solution meets these requirements.
[Figure 7 -- see PostScript version]
8. Alternative Methods
8.1. IS-683A over TCP/IP
One alternative is to port IS-683A to TCP, remaining as close as
possible to the IS-683A protocol exchange.
Figure 8 depicts the architecture and communications backbone to
support OTASP/OTAPA via IS-707 data services with a provisioning
server based on the IS-683A OTAF function.
[Figure 8 -- see PostScript version]
8.1.1. OTAF Server
This provisioning server is modeled after the IS-683A OTAF. The
OTAF server performs the specific operations and messaging of IS-
683A OTAF. This includes A-key reauthentication procedures.
Strongpoints:
(1) OTAF and mobile station behavior mirrors IS-683A (reduced
duplicate software in mobile station). Nearly all procedures fully
defined.
Drawbacks:
(1) The OTAF server would need to be custom-designed and built.
(2) No inherent data manipulation capabilities in the OTAF server.
All required or desired data management activities would have to be
built from scratch.
(3) Interface application would require a non-standard interface
(and therefore proprietary) to OTAF server.
(4) End-to-end encryption scheme still needed for full security.
8.1.2. Interface Application
This function loads all required provisioning-related information
from the CDMA network information system to the OTAF server. This
includes the queuing of provisioning transactions and data.
8.1.3. Protocol Handset Suite
Figure 9 depicts the mobile station protocol suite for the IS-683A
over TCP/IP solution. The OTASP client is capable of supporting
both IS-683A OTASP activities or OTASP activities over the data
transport.
[Figure 9 -- see PostScript version]
8.2. Browser-Based Forms
Another alternative is to use forms embedded in web pages.
Encapsulating the provisioning data into custom tags embedded in a
web form is an idea that at first seems attractive. There are a lot
of advantages in having a browser in the handset, web servers are
very widely deployed, and everyone is familiar on some level with
the web.
However, a meta-protocol for this would need to be designed, and a
fully detailed specification produced. This solution requires
custom software on the provider side to handle the meta-protocol.
It additionally requires handset vendors to add custom software in
the handset browser to handle this protocol.
This solution would require a provisioning-capable browser in every
phone. While it may be desirable to have a browser, the decision to
require it needs to be considered carefully, especially in light of
the memory requirements it would impose on all devices.
This solution would complicate the handset browser, by requiring it
to handle provisioning as well as browsing. As provisioning and
browsing are functionally dissimilar, this code is not a natural fit
within the browser. Implementing this solution would require a
significant increase in development and debug resources, and thus
negatively impact time-to-market and cost.
Also because the web is functionally dissimilar, a high level of
carrier-side customization would be needed, leading to reduced
vendor choice and increased deployment costs.
This approach would layer custom data on top of a standard protocol.
This would require design work, and would not have much time for
open review before deployment, greatly increasing the risk. By
contrast, ACAP has had years of open review and refinement.
This approach also limits the extensibility of the solution. ACAP,
conversely, is very extensible. Because ACAP is such a simple
protocol, it can be added to a wide variety of applications at low
cost. This allows increasing numbers of applications on the mobile
device to share information with servers as well as desktop
applications.
9. Conclusion
ACAP provides a high degree of extensibility, especially in
authentication mechanisms, custom attribute handling, and data
management. By using an Internet standard protocol,
interoperability and integration with a variety of equipment is
possible, and carriers are not locked into any vendor. It is also
easier to add new levels of service and capabilities, especially
integration with future subscriber devices and applications (e.g.,
email).
Since an ACAP client is so small, it can be incorporated into
virtually any device, even low-end ones without displays, and can be
added without sacrificing other features. The simplicity of the
client and protocol directly translate to shorter development cycles
and faster time-to-market.
Because the ACAP protocol was designed for precisely this type of
provisioning activity, its adoption can greatly reduce the cost,
time to market, and support required for the provisioning server as
well as the handsets. As an open standard, the ACAP protocol has
benefited from years of review and experience.
Another advantage of the ACAP solution is that is can easily coexist
with a WAP-based mechanism, giving carriers more options and
reducing the minimal requirement burden on mobile devices.
A carrier can deploy handsets into its service area which use WAP-
based provisioning, if desired, alongside those which use ACAP
provisioning. By using an ACAP server for provisioning, carriers
are free to simultaneously deploy mobile stations that use either
WAP or ACAP, as desired.
The lack of intellectual-property issues further adds to ACAP's
appeal.
10. References
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC2244, November 1997.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC2195,
September 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC2222, October 1997.
11. Security Considerations
Security is discussed in many sections of this document. In
particular, the need and methods to guard against unauthorized
updating of handsets, usurpation of newly-created accounts,
compromise of handset security values, and disclosure of carrier
proprietary data and handset parameters is covered.
12. Acknowledgments
Jim Willkie and Marc Phillips contributed greatly to this document.
Their help is very much appreciated.
13. Author's Address
Randall Gellens
QUALCOMM Incorporated
6455 Lusk Boulevard
San Diego, CA 92121-2779
Phone: +1 619 651 5115
EMail: randy@qualcomm.com
14. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.