rfc2636.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

    * Update roaming lists










Gellens                      Informational                      [Page 6]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


3.  Operation

3.1.  Initial Provisioning Activity

    A new subscriber needs to give the intended service provider
    sufficient information (e.g., name, address, etc.) to prove credit-
    worthiness and establish a record within the service provider's
    billing system.  In addition, the ESN of the mobile station needs to
    be given to the provider.  This may occur in three ways:

    Voice scenario -- A customer care representative collects credit
    information during a voice conversation.  This call is made from a
    different phone (e.g., wired service) or is initiated using the IS-
    683A OTASP dialing scheme (i.e., *228xx).

    Once the user has been authorized, the customer care representative
    creates a record in the CDMA network HLR, thus allowing use of the
    CDMA network.  In addition, a limited-time N-digit password is
    created which is tied to the ESN.  The choice of N (how many digits)
    is up to the carrier (as a trade-off between security and user
    inconvenience).  All required provisioning information (including
    the limited-time password) is loaded into the provisioning server.

    The user is then told to hang up and call a special number, of the
    form *228 XX <N-digit password> SEND (the XX code is the same as
    used in the initial voice call).  This causes the mobile station to
    initiate a provisioning session.

    The mobile station and the provisioning server authenticate, and all
    required provisioning information is downloaded into the mobile
    station.  The user receives some form of notification once the
    activity is complete.  This notification can be an audible tone or a
    text message on the mobile station display. (The form and content of
    this notification can be part of the provisioning data downloaded by
    the mobile station.) Once this initial provisioning activity is
    complete the user has a fully authorized mobile station ready for
    use.

    Forms scenario -- An interactive user interface is presented via a
    browser on the mobile station.  The subscriber fills in the
    requested information. (Note that entering non-numeric data presents
    some user interface challenges on many mobile devices.)

    A back-end server validates the information, and if possible, the
    customer is authorized, a limited-time password is generated, HLR
    and provisioning server records are created and the actual OTASP
    operation begins.  Otherwise, a voice call is made to a customer
    care representative.



Gellens                      Informational                      [Page 7]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


    Desktop scenario -- The subscriber uses a desktop (or in-store
    kiosk) web browser to contact the carrier, and enters the usual
    personal information.

    The carrier's server validates the information, and if possible, the
    customer is authorized, a limited-time password is generated, HLR
    and provisioning server records are created, and the subscriber is
    told to dial a special number on the handset.  Once this code is
    entered, the actual OTASP operation begins.  Otherwise, the user is
    asked to make a voice call to a customer care representative.

3.2.  OTASP for Authorized Users

    Users already authorized for use of the CDMA network can also
    initiate provisioning activity.  This could happen after being
    directed to do so by a Customer Care representative, either from a
    phone conversation or via mail notification.  This type of OTASP
    activity is needed in cases where the carrier desires to upgrade
    CDMA parameters in the mobile stations or in cases where mobile
    station troubleshooting is needed.

    This type of OTASP occurs in similar fashion to the initial OTASP
    activity.  The mobile station downloads the new provisioning
    information in the same way.

3.3  OTAPA Activity

    Typical OTAPA capability involves upgrading a large number of mobile
    stations.  OTAPA activity needs to be performed in a manner that
    does not impose on revenue bearing CDMA network activity.  OTAPA
    operations are initiated at the customer care center.  This can be
    accomplished by queuing a notification to the mobile station (via
    1-way SMS or special caller-ID) after the provisioning server has
    the updated configuration data.  OTAPA activity will not occur until
    the mobile station has acquired CDMA service on the carrier's
    network and the notification has reached the mobile station.

    Alternatively, OTAPA can be handled by including a recheck interval
    in the set of data used to provision the mobile station.  When using
    a low-overhead protocol, such as ACAP [ACAP], it is reasonable to
    have a mobile station check in periodically to see if anything has
    changed.  The time of day and/or day of week that such rechecks
    should occur could be included in the provisioning data.

    OTAPA activity can be terminated at any time due to user call
    activity.





Gellens                      Informational                      [Page 8]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


4.  Requirements

4.1.  General Requirements

    IS-683A OTASP operations occur between a mobile station and an
    over-the-air service provisioning function (OTAF) using IS-95A
    traffic channel data burst messages.  OTASP/OTAPA via data services
    require that the CDMA carrier have an IS-707 data services capable
    network.  The IS-707 service must be either Packet Data Service
    (IS-707.5) or Quick-Net-Connect (QNC).

    The mobile station must support:

    * IS-707 Data Service capability

    * Packet/QNC RLP protocol

    * PPP protocol to peer to the IS-707 IWF

    * IP protocol to provide the network layer for routing to the
    provisioning server

    * A transport layer for end-to-end communication (such as TCP)

    * Authentication and optionally encryption

    * Application software to handle the provisioning protocol and
    memory access.

    * Domain Name System (DNS) query capabilities sufficient to obtain
    the (IP) address of the provisioning server (or the provisioning
    server's address could be provided during PPP negotiation).

    Lastly, the ability must exist for the mobile to make a data call
    (optionally) a voice call without a MIN.

4.2.  OTASP Requirements

    The OTASP function requires the mobile station to originate an IS-
    707 data call and (optionally) a voice call using a completely
    unprovisioned mobile station.  The CDMA network must support this
    capability.

    OTASP via data services uses a provisioning server that contains the
    parameter information for mobile stations.  The authorizing agent
    (or software) at the customer care center must be able to add user
    and mobile station information into both the CDMA network HLR and




Gellens                      Informational                      [Page 9]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


    the provisioning server during the initial authorizing process.  The
    provisioning server must be capable of servicing a mobile as soon as
    its record is created.

4.3.  OTAPA Requirements

    IS-683A OTAPA is performed by a mobile-terminated call that
    downloads parameters to the mobile station.  OTAPA calls occur
    without user interaction.

    In order to perform OTAPA via data services the network needs to
    direct the mobile station to initiate a special-purpose data call.
    Several existing methods can be used to implement this capability,
    for example, a mobile-terminated one-way SMS message.  The SMS
    message content can contain any information required by the mobile
    station.  The mobile station would need a simple parser of SMS
    messages in order to know when to originate an OTAPA call, as
    opposed to normal SMS message processing.  The OTAPA call would be
    performed in similar fashion to a registration call.  More
    specifically, the user would not be informed of the call activity.

    There are alternative means that can be employed to initiate OTAPA
    activity; for example, a mobile-terminated voice call with caller-ID
    using a specialized telephone number.  Another alternative is for
    mobile stations to periodically check in with the provisioning
    server to check for updated information.  ACAP, for example, is
    designed for such a model.  The recheck interval, as well as the
    time of day and/or day of week that such checks should be used, can
    be part of the provisioning data sent to the mobile stations.

4.4.  Provisioning Server Requirements

    IS-683A utilizes an over-the-air service provisioning function
    (OTAF) to perform the network-side provisioning activity.
    OTASP/OTAPA via data services replaces the OTAF with a provisioning
    server.  The provisioning server resides on an IP network within the
    controlled confines of the carrier.  The provisioning server must
    perform all the service provisioning and parameter administration
    functions that the OTAF provides.  The provisioning server must also
    have an interface to the carrier's Mobile Terminal Authorizing
    System (MTAS).  This interface serves to synchronize the
    provisioning server with the information in the MTAS.  The specific
    requirements of this interface depend on the capabilities and
    interfaces of the carrier's customer care center system(s).  The
    provisioning server must be capable of receiving dynamic updates
    from the MTAS and have the provisioning information immediately





Gellens                      Informational                     [Page 10]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


    available for downloading into the chosen mobile station.  A
    standard ACAP server provides an excellent means to meet these
    requirements.

    The provisioning server must be capable of performing an
    authentication procedure with the mobile station.  This
    authentication mechanism must be capable of authenticating both the
    mobile station and the provisioning server.

4.5.  Security Requirements

    OTASP requires that an authentication procedure be performed to
    validate the mobile station to the provisioning server, while OTAPA
    requires a mechanism where the mobile validates the server.

    The provisioning server must be capable of either:

    * OTAF A-key generation using a Diffie-Hellman mechanism

    Or:

    * Receiving A-keys from the carrier network.

    Since data OTASP/OTAPA operates over IP within the carrier's
    network, end-to-end encryption between the mobile station and the
    provisioning server should be considered as a future enhancement.
    End-to-end encryption protects against attacks from within a
    carrier's network, and safeguards the provisioning data (for
    example, roaming lists).

5.  Architecture

5.1.  ACAP over TCP/IP

    Figure 1 shows a provisioning server in the carrier's intranet which
    supports the Application Configuration Access Protocol (ACAP, RFC
    2244).  An administrative client in the customer care domain updates
    this server using ACAP.  Handsets are provisioned and configured
    using a small ACAP client.

                    [Figure 1 -- see PostScript version]

    ACAP is an open Internet protocol designed to solve the problem of
    client access to configuration and related data.  Among its primary
    goals are protocol simplicity, support for thin clients, and ease of
    operation over limited bandwidth.  ACAP provides a high degree of
    extensibility, especially in authentication mechanisms, specialized
    attribute handling, and data management.



Gellens                      Informational                     [Page 11]

RFC 2636                  OTASP/OTAPA via ACAP                 July 1999


5.1.1.  Mobile Authentication and A-Key Generation

    The mobile client authenticates with the ACAP server prior to
    performing any activities.  Authentication uses the mobile's ESN and
    a shared secret.  Provisioned mobiles derive the shared secret from
    the A-Key; unprovisioned mobiles use a limited-time password as the
    secret.

    The limited-time password is provided to the user by the Customer
    Care representative during the initial call (as instructions to dial
    a specific number).  This code is N digits long.  The carrier
    selects the number of digits, as a trade-off between security and
    user convenience.

    The baseline ACAP authentication mechanism uses the shared secret
    plus a random challenge from the server as input to a one-way
    cryptographic hash function (specifically, keyed-MD5).  This is
    analogous to the existing IS-683A authentication mechanism which
    uses a random challenge and the CAVE algorithm.

    An A-Key is generated using a Diffie-Hellman exchange, as is done in
    IS-683A.

5.1.2.  Mobile Identification

    Provisioning records are identified using the ESN and the current
    NAM in use.

5.1.3.  ACAP Server