tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6080

 
 
 

A Framework for Session Initiation Protocol User Agent Profile Delivery

Part 3 of 3, p. 33 to 54
Prev RFC Part

 


prevText      Top      Up      ToC       Page 33 
6.  Event Package Definition

   The framework specified in this document proposes and specifies a new
   SIP event package, as allowed by [RFC3265].  The purpose is to allow
   for devices to subscribe to specific profile types with PDSs and for
   the PDSs to notify the devices with the profile data or content
   indirection information.

   The requirements specified in [RFC3265] apply to this package.  The
   following subsections specify the event package description and the
   associated requirements.  The framework requirements are defined in
   Section 5.

6.1.  Event Package Name

   The name of this package is "ua-profile".  This value appears in the
   Event header field present in SUBSCRIBE and NOTIFY requests for this
   package, as defined in [RFC3265].

6.2.  Event Package Parameters

   This package defines the following new parameters for the event
   header:

      "profile-type", "vendor", "model", "version", and "effective-by"

   The following rules apply:

   o  All the new parameters, with the exception of the "effective-by"
      parameter, MUST only be used in SUBSCRIBE requests and ignored if
      they appear in NOTIFY requests.

   o  The "effective-by" parameter is for use in NOTIFY requests only
      and MUST be ignored if it appears in SUBSCRIBE requests.

   The semantics of these new parameters are specified in the following
   subsections.

Top      Up      ToC       Page 34 
6.2.1.  "profile-type" Parameter

   The "profile-type" parameter is used to indicate the token name of
   the profile type the user agent wishes to obtain and to be notified
   of subsequent changes.  This document defines three logical types of
   profiles and their token names.  They are as follows:

   local-network:  specifying the "local-network" type profile indicates
      the desire for profile data, and potentially, profile change
      notifications specific to the local network.

   device:  specifying the "device" type profile(s) indicates the desire
      for the profile data, and potentially, profile change notification
      that is specific to the device or user agent.

   user:  specifying the "user" type profile indicates the desire for
      the profile data, and potentially, profile change notification
      specific to the user.

   The profile type is identified in the Event header parameter:
   "profile-type".  A separate SUBSCRIBE dialog is used for each profile
   type.  Thus, the subscription dialog on which a NOTIFY arrives
   implies which profile's data is contained in, or referred to, by the
   NOTIFY message body.  The Accept header of the SUBSCRIBE request MUST
   include the MIME types for all profile content types for which the
   subscribing user agent wishes to retrieve profiles, or receive change
   notifications.

   In the following syntax definition using ABNF, EQUAL and token are
   defined in [RFC3261].  It is to be noted that additional profile
   types may be defined in subsequent documents.

   Profile-type   = "profile-type" EQUAL profile-value
   profile-value  =  profile-types / token
   profile-types  = "device" / "user" / "local-network"

   The "device", "user", or "local-network" token in the profile-type
   parameter may represent a class or set of profile properties.
   Follow-on standards defining specific profile contents may find it
   desirable to define additional tokens for the profile-type parameter.
   Also, additional content types may be defined along with the profile
   formats that can be used in the Accept header of the SUBSCRIBE to
   filter or indicate what data sets of the profile are desired.

Top      Up      ToC       Page 35 
6.2.2.  "vendor", "model", and "version" Parameters

   The "vendor", "model", and "version" parameter values are tokens
   specified by the implementer of the user agent.  These parameters
   MUST be provided in the SUBSCRIBE request for all profile types.  The
   implementer SHOULD use their DNS domain name (e.g., example.com) as
   the value of the "vendor" parameter so that it is known to be unique,
   unless there is a good reason not to.  Examples of exceptions
   include: if the vendor does not have an assigned DNS domain name, if
   they are using a different vendor's implementation, etc.  These
   parameters are useful to the PDS to affect the profiles provided.  In
   some scenarios, it is desirable to provide different profiles based
   upon these parameters.  For example, feature property X in a profile
   may work differently on two versions of the same user agent.  This
   gives the PDS the ability to compensate for or take advantage of the
   differences.  In the following ABNF defining the syntax, EQUAL and
   quoted-string are defined in [RFC3261].

   Vendor       =  "vendor" EQUAL quoted-string
   Model        =  "model" EQUAL quoted-string
   Version      =  "version" EQUAL quoted-string

6.2.3.  "effective-by" Parameter

   The "effective-by" parameter in the Event header of the NOTIFY
   request specifies the maximum number of seconds before the user agent
   MUST attempt to make the new profile effective.  The "effective-by"
   parameter MAY be provided in the NOTIFY request for any of the
   profile types.  A value of 0 (zero) indicates that the subscribing
   user agent MUST attempt to make the profiles effective immediately
   (despite possible service interruptions).  This gives the PDS the
   power to control when the profile is effective.  This may be
   important to resolve an emergency problem or disable a user agent
   immediately.  If it is absent, the device SHOULD attempt to make the
   profile data effective at the earliest possible opportunity that does
   not disrupt any services being offered.  The "effective-by" parameter
   is ignored in all messages other than the NOTIFY request.  In the
   following ABNF, EQUAL and DIGIT are defined in [RFC3261].

   Effective-By =  "effective-by" EQUAL 1*DIGIT

6.2.4.  Summary of Event Parameters

   The following are example Event headers that may occur in SUBSCRIBE
   requests.  These examples are not intended to be complete SUBSCRIBE
   requests.

Top      Up      ToC       Page 36 
   Event: ua-profile;profile-type=device;
          vendor="vendor.example.com";model="Z100";version="1.2.3"

   Event: ua-profile;profile-type=user;
          vendor="premier.example.com";model="trs8000";version="5.5"

   The following are example Event headers that may occur in NOTIFY
   requests.  These example headers are not intended to be complete
   SUBSCRIBE requests.

   Event: ua-profile;effective-by=0

   Event: ua-profile;effective-by=3600

   The following table shows the use of Event header parameters in
   SUBSCRIBE requests for the three profile types:

   profile-type || device | user | local-network
   =============================================
   vendor       ||   m    |  m   |        m
   model        ||   m    |  m   |        m
   version      ||   m    |  m   |        m
   effective-by ||        |      |

   m - MUST be provided
   s - SHOULD be provided
   o - OPTIONAL to be provided

   Non-specified means that the parameter has no meaning and should be
   ignored.

   The following table shows the use of Event header parameters in
   NOTIFY requests for the three profile types:

   profile-type || device | user | local-network
   =============================================
   vendor       ||        |      |
   model        ||        |      |
   version      ||        |      |
   effective-by ||   o    |  o   |        o

6.3.  SUBSCRIBE Bodies

   This package defines no use of the SUBSCRIBE request body.  If
   present, it SHOULD be ignored.  Exceptions include future
   enhancements to the framework that may specify a use for the
   SUBSCRIBE request body.

Top      Up      ToC       Page 37 
6.4.  Subscription Duration

   The duration of a subscription is specific to SIP deployments, and no
   specific recommendation is made by this event package.  If absent, a
   value of 86400 seconds (24 hours; 1 day) is RECOMMENDED since the
   presence (or absence) of a device subscription is not time critical
   to the regular functioning of the PDS.

   It is to be noted that a one-time fetch of a profile, without ongoing
   subscription, can be accomplished by setting the 'Expires' parameter
   to a value of Zero, as specified in [RFC3265].

6.5.  NOTIFY Bodies

   The framework specifying the event package allows for the NOTIFY body
   to contain the profile data, or a pointer to the profile data using
   content indirection.  For profile data delivered via content
   indirection, i.e., a pointer to a PCC, then the Content-ID MIME
   header, as described in [RFC4483], MUST be used for each profile
   document URI.  At a minimum, the "http:" [RFC2616] and "https:"
   [RFC2818] URI schemes MUST be supported; other URI schemes MAY be
   supported based on the Profile Data Frameworks (examples include FTP
   [RFC0959], Lightweight Directory Access Protocol (LDAP) [RFC4510],
   and XCAP [RFC4825] ).

   A non-empty NOTIFY body MUST include a MIME type specified in the
   Accept header of the SUBSCRIBE.  Further, if the Accept header of the
   SUBSCRIBE included the MIME type message/external-body (indicating
   support for content indirection) then the PDS MAY use content
   indirection in the NOTIFY body for providing the profiles.

6.6.  Notifier Processing of SUBSCRIBE Requests

   A successful SUBSCRIBE request results in a NOTIFY with either
   profile contents or a pointer to it (via content indirection).  The
   SUBSCRIBE SHOULD be either authenticated or transmitted over an
   integrity protected SIP communications channel.  Exceptions include
   cases where the identity of the Subscriber is unknown and the
   Notifier is configured to accept such requests.

   The Notifier MAY also authenticate SUBSCRIBE messages even if the
   NOTIFY is expected to only contain a pointer to profile data.
   Securing data sent via content indirection is covered in Section 9.

   If the profile type indicated in the "profile-type" Event header
   parameter is unavailable or the Notifier is configured not to provide
   it, the Notifier SHOULD return a 404 response to the SUBSCRIBE

Top      Up      ToC       Page 38 
   request.  If the specific user or device is unknown, the Notifier MAY
   accept the subscription, or else it may reject the subscription (with
   a 403 response).

6.7.  Notifier Generation of NOTIFY Requests

   As specified in [RFC3265], the Notifier MUST always send a NOTIFY
   request upon accepting a subscription.  If the device or user is
   unknown and the Notifier chooses to accept the subscription, the
   Notifier MAY either respond with profile data (e.g., default profile
   data) or provide no profile information (i.e., empty NOTIFY).

   If the identity indicated in the SUBSCRIBE request (From header) is a
   known identity and the requested profile information is available
   (i.e., as specified in the "profile-type" parameter of the Event
   header), the Notifier SHOULD send a NOTIFY with profile data.
   Profile data MAY be sent as profile contents or via content
   indirection (if the content indirection MIME type was included in the
   Accept header).  The Notifier MUST NOT use any scheme that was not
   indicated in the "schemes" Contact header field.

   The Notifier MAY specify when the new profiles must be made effective
   by the Subscriber by specifying a maximum time in seconds (zero or
   more) in the "effective-by" Event header parameter.

   If the SUBSCRIBE was received over an integrity protected SIP
   communications channel, the Notifier SHOULD send the NOTIFY over the
   same channel.

6.8.  Subscriber Processing of NOTIFY Requests

   A Subscriber to this event package MUST adhere to the NOTIFY request
   processing behavior specified in [RFC3265].  If the Notifier
   indicated an effective time (using the "effective-by" Event header
   parameter), the Subscriber SHOULD attempt to make the profiles
   effective within the specified time.  Exceptions include deployments
   that prohibit such behavior in certain cases (e.g., emergency
   sessions are in progress).  When profile data cannot be applied
   within the recommended time frame and this affects device behavior,
   any actions to be taken SHOULD be defined by the profile data
   definitions.  By default, the Subscriber is RECOMMENDED to make the
   profiles effective as soon as possible.

   When accepting content indirection, the Subscriber MUST always
   support "http:" or "https:" and be prepared to accept NOTIFY messages
   with those URI schemes.  If the Subscriber wishes to support
   alternative URI schemes they MUST each be indicated in the "schemes"
   Contact header field parameter as defined in [RFC4483].  The

Top      Up      ToC       Page 39 
   Subscriber MUST also be prepared to receive a NOTIFY request with no
   body.  The subscriber MUST NOT reject the NOTIFY request with no
   body.  The subscription dialog MUST NOT be terminated by a empty
   NOTIFY, i.e., with no body.

6.9.  Handling of Forked Requests

   This event package allows the creation of only one dialog as a result
   of an initial SUBSCRIBE request as described in Section 4.4.9 of
   [RFC3265].  It does not support the creation of multiple
   subscriptions using forked SUBSCRIBE requests.

6.10.  Rate of Notifications

   The rate of notifications for the profiles in this framework is
   deployment specific, but expected to be infrequent.  Hence, the event
   package specification does not specify a throttling or minimum period
   between NOTIFY requests.

6.11.  State Agents

   State agents are not applicable to this event package.

7.  Examples

   This section provides examples along with sample SIP message bodies
   relevant to this framework.  Both the examples are derived from the
   use case illustrated in Section 4.1, specifically the request for the
   device profile.  The examples are informative only.

7.1.  Example 1: Device Requesting Profile

   This example illustrates the detailed message flows between the
   device and the SIP service provider's network for requesting and
   retrieving the profile (the flow uses the device profile as an
   example).

   The following are assumed for this example:

   o  Device is assumed to have established local network connectivity;
      NAT and firewall considerations are assumed to have been addressed
      by the SIP service provider.

   o  Examples are snapshots only and do not illustrate all the
      interactions between the device and the service provider's network
      (and none between the entities in the SIP service provider's
      network).

Top      Up      ToC       Page 40 
   o  All SIP communication with the SIP service provider happens via a
      SIP proxy.

   o  HTTP over TLS is assumed to be the Content Retrieval method used
      (any suitable alternative can be used as well).

   The flow diagram and an explanation of the messages follow.

                                      +----------------------+
    +--------+                        | SIP Service Provider |
    | Device |                        |                      |
    |(SIP UA)|                        |  SIP     PDS   HTTP  |
    +--------+                        | PROXY         Server |
                                      |                      |
                                      +----------------------+
         |                                |       |      |
         |                                |       |      |
         |          SUBSCRIBE             |       |      |
   (SReq)|--------device profile--------->|       |      |
         |                                |------>|      |
         |                                |200 OK |      |
         |            200 OK              |<------|      |
   (SRes)|<-------------------------------|       |      |
         |                                |       |      |
         |                                | NOTIFY|      |
         |    NOTIFY (Content Indirection)|<------|      |
   (NTFY)|<-------------------------------|       |      |
         |            200 OK              |       |      |
   (NRes)|------------------------------->|200 OK |      |
         |                                |------>|      |
         |                                               |
         |                                               |
         |                                               |
         |<<<<<<<<<<<<<  TLS establishment  >>>>>>>>>>>>>|
         |                                               |
         |                HTTP Request                   |
   (XReq)|---------------------------------------------->|
         |                                               |
         |                HTTP Response                  |
   (XRes)|<----------------------------------------------|
         |                                               |

Top      Up      ToC       Page 41 
   (SReq)
      the device transmits a request for the 'device' profile using the
      SIP SUBSCRIBE utilizing the event package specified in this
      framework.

      *  Note: Some of the header fields (e.g., SUBSCRIBE, Event, Via)
         are continued on a separate line due to format constraints of
         this document.

   SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
             @example.com  SIP/2.0
   Event: ua-profile;profile-type=device;vendor="vendor.example.net";
          model="Z100";version="1.2.3"
   From: anonymous@example.com;tag=1234
   To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
   Call-ID: 3573853342923422@192.0.2.44
   CSeq: 2131 SUBSCRIBE
   Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
      @192.168.1.44
      ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-123456789AB0>"
      ;schemes="http,https"
   Via: SIP/2.0/TCP 192.0.2.41;
     branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
   Accept: message/external-body, application/x-z100-device-profile
   Content-Length: 0

   (SRes)  the SUBSCRIBE request is received by a SIP proxy in the
      service provider's network, which transmits it to the PDS.  The
      PDS accepts the response and responds with a 200 OK.

      *  Note: The device and the SIP proxy may have established a
         secure communications channel (e.g., TLS).

   (NTFY)  subsequently, the PDS transmits a SIP NOTIFY message
      indicating the profile location.

      *  Note: Some of the fields (e.g., content-type) are continued on
         a separate line due to format constraints of this document.

Top      Up      ToC       Page 42 
 NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
        @192.168.1.44 SIP/2.0
 Event: ua-profile;effective-by=3600
 From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
       ;tag=abca
 To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
     ;tag=1234
 Call-ID: 3573853342923422@192.0.2.44
 CSeq: 322 NOTIFY
 Via: SIP/2.0/UDP 192.0.2.3;
   branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0
 MIME-Version: 1.0
 Content-Type: message/external-body; access-type="URL";
               expiration="Mon, 01 Jan 2010 09:00:00 UTC";
               URL="http://example.com/z100-000000000000.html";
               size=9999;
               hash=10AB568E91245681AC1B

 Content-Type: application/x-z100-device-profile
 Content-ID: <39EHF78SA@example.com>
 .
 .
 .

   (NRes)  Device accepts the NOTIFY message and responds with a 200 OK.

   (XReq)  once the necessary secure communications channel is
      established, the device sends an HTTP request to the HTTP server
      indicated in the NOTIFY.

   (XRes)  the HTTP server responds to the request via a HTTP response
      containing the profile contents.

7.2.  Example 2: Device Obtaining Change Notification

   The following example illustrates the case where a user (X) is
   simultaneously accessing services via two different devices (e.g.,
   multimedia entities on a PC and PDA) and has access to a user
   interface that allows for changes to the user profile.

   The following are assumed for this example:

   o  The devices (A & B) obtain the necessary profiles from the same
      SIP service provider.

   o  The SIP service provider also provides a user interface that
      allows the user to change preferences that impact the user
      profile.

Top      Up      ToC       Page 43 
   The flow diagram and an explanation of the messages follow.

   o  Note: The example only shows retrieval of user X's profile, but it
      may request and retrieve other profiles (e.g., local-network,
      device).

               -----           -----
              |User |_________| UI* | * = User Interface
              |  X  |         |     |
               -----           -----
             /       \
            /         \
           /           \              +----------------------+
    +--------+      +--------+        | SIP Service Provider |
    | Device |      | Device |        |                      |
    |    A   |      |    B   |        |  SIP     PDS   HTTP  |
    +--------+      +--------+        | PROXY         Server |
                                      +----------------------+
         |                                |       |      |
         |                                |       |      |
   (A-EX)|<=Enrolls for User X's profile=>|<=====>|      |
         |                                |       |      |
         |                                               |
   (A-RX)|<===Retrieves User X's profile================>|
         |                                               |
         |               |                |       |      |
         |               |  Enrolls for   |       |      |
         |         (B-EX)|<== User X's ==>|<=====>|      |
         |               |    profile     |       |      |
         |               |                |       |      |
         |               |                               |
         |         (B-RX)|<= Retrieves User X's profile=>|
         |                                               |
         |                       |                       |
         |                 (HPut)|---------------------->|
         |                       |                       |
         |                 (HRes)|<----------------------|
         |                                               |
         |                                |       |      |
         |                                | NOTIFY|      |
         |            NOTIFY              |<------|      |
   (A-NT)|<-------------------------------|       |      |
         |            200 OK              |       |      |
   (A-RS)|------------------------------->|200 OK |      |
         |                                |------>|      |

Top      Up      ToC       Page 44 
         |                                               |
         |               |                | NOTIFY|      |
         |               |    NOTIFY      |<------|      |
         |         (B-NT)|<---------------|       |      |
         |               |    200 OK      |       |      |
         |         (B-RS)|--------------->|200 OK |      |
         |               |                |------>|      |
         |                                               |
         |                                               |
   (A-RX)|<===Retrieves User X's profile================>|
         |                                               |
         |               |                               |
         |               |                               |
         |         (B-RX)|<= Retrieves User X's profile=>|
         |               |                               |

   (A-EX)   Device A discovers, enrolls, and obtains notification
            related to user X's profile.

   (A-RX)   Device A retrieves user X's profile.

   (B-EX)   Device B discovers, enrolls, and obtains notification
            related to user X's profile.

   (B-RX)   Device B retrieves user X's profile.

   (HPut)   Changes affected by the user via the user interface are
            uploaded to the HTTP server.

            *  Note: The Unique Identifier (UI) itself can act as a
               device and subscribe to user X's profile.  This is not
               the case in the example shown.

   (HRes)   Changes are accepted by the HTTP server.

   (A-NT)   PDS transmits a NOTIFY message to device A indicating the
            changed profile.  A sample message is shown below:

            *  Note: Some of the fields (e.g., Via) are continued on a
               separate line due to format constraints of this document.

Top      Up      ToC       Page 45 
   NOTIFY sip:userX@192.0.2.44 SIP/2.0
   Event: ua-profile;effective-by=3600
   From: sip:userX@sip.example.net;tag=abcd
   To: sip:userX@sip.example.net.net;tag=1234
   Call-ID: 3573853342923422@192.0.2.44
   CSeq: 322 NOTIFY
   Via: SIP/2.0/UDP 192.0.2.3;
     branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1
   MIME-Version: 1.0
   Content-Type: message/external-body; access-type="URL";
                 expiration="Mon, 01 Jan 2010 09:00:00 UTC";
                 URL="http://www.example.com/user-x-profile.html";
                 size=9999;
                 hash=123456789AAABBBCCCDD
   .
   .
   .

   (A-RS)   Device A accepts the NOTIFY and sends a 200 OK.

   (B-NT)   PDS transmits a NOTIFY message to device B indicating the
            changed profile.  A sample message is shown below:

            *  Note: Some of the fields (e.g., Via) are continued on a
               separate line due to format constraints of this document.

   NOTIFY sip:userX@192.0.2.43 SIP/2.0
   Event: ua-profile;effective-by=3600
   From: sip:userX@sip.example.net;tag=abce
   To: sip:userX@sip.example.net.net;tag=1234
   Call-ID: 3573853342923422@192.0.2.43
   CSeq: 322 NOTIFY
   Via: SIP/2.0/UDP 192.0.2.3;
     branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2
   MIME-Version: 1.0
   Content-Type: message/external-body; access-type="URL";
                 expiration="Mon, 01 Jan 2010 09:00:00 UTC";
                 URL="http://www.example.com/user-x-profile.html";
                 size=9999;
                 hash=123456789AAABBBCCCDD
   .
   .
   .

   (B-RS)   Device B accepts the NOTIFY and sends a 200 OK.

   (A-RX)   Device A retrieves the updated profile pertaining to user X.

Top      Up      ToC       Page 46 
   (B-RX)   Device B retrieves the updated profile pertaining to user X.

8.  IANA Considerations

   IANA has registered a SIP event package, event header parameters, and
   SIP configuration profile types as outlined in the following
   subsections.

8.1.  SIP Event Package

   This specification registers a new event package as defined in
   [RFC3265].  The registration is as follows:

   Package Name:  ua-profile

   Package or Template-Package:  This is a package

   Published Document:  RFC 6080

   Persons to Contact:  Daniel Petrie <dan.ietf@SIPez.com>,
      Sumanth Channabasappa <sumanth@cablelabs.com>

   New event header parameters:  profile-type, vendor, model, version,
      effective-by (The profile-type parameter has predefined values.
      The new event header parameters do not.)

   The following table illustrates the additions to the IANA SIP "Header
   Field Parameters and Parameter Values" registry:

                                                   Predefined
   Header Field                  Parameter Name    Values      Reference
   ----------------------------  ---------------   ----------  ---------
   Event                         profile-type      Yes         [RFC6080]
   Event                         vendor            No          [RFC6080]
   Event                         model             No          [RFC6080]
   Event                         version           No          [RFC6080]
   Event                         effective-by      No          [RFC6080]

8.2.  Registry of SIP Configuration Profile Types

   IANA has registered new SIP configuration profile types at
   http://www.iana.org in the "SIP Configuration Profile Types"
   registry.

   The registration procedures are "Specification Required", as
   explained in "Guidelines for Writing an IANA Considerations Section
   in RFCs" ([RFC5226]).

Top      Up      ToC       Page 47 
   Registrations with the IANA MUST include the profile type, and a
   published document that describes its purpose and usage.

   As this document specifies three SIP configuration profile types, the
   initial IANA registration contains the information shown in the table
   below.

         Profile Type                          Reference
         --------------                         ---------
         local-network                          [RFC6080]
         device                                 [RFC6080]
         user                                   [RFC6080]

9.  Security Considerations

   The framework specified in this document specifies profile delivery
   stages, an event package, and three profile types to enable profile
   delivery.  The profile delivery stages are enrollment, content
   retrieval, and change notification.  The event package helps with
   enrollment and change notifications.  Each profile type allows for
   profile retrieval from a PDS belonging to a specific provider.

   Enrollment allows a device to request, and if successful, enroll with
   a PDS to obtain profile data.  To transmit the request the device
   relies on configured, cached, or discovered data.  Such data includes
   provider domain names, identities, and credentials.  The device
   either uses configured outbound proxies or discovers the next-hop
   entity using [RFC3263] that can result in a SIP proxy or the PDS.  It
   then transmits the request.  A SIP proxy receiving the request uses
   the Request-URI and event header contents to route it to a PDS (via
   other SIP proxies, if required).

   When a PDS receives the enrollment request, it can either challenge
   any contained identity or admit the enrollment.  Authorization rules
   then decide if the enrollment gets accepted.  If accepted, the PDS
   sends an initial notification that contains either the profile data,
   or content indirection information.  The profile data can contain
   generic profile data (common across multiple devices) or information
   specific to an entity (such as the device or a user).  If specific to
   an entity, it may contain sensitive information such as credentials.
   Disclosure of sensitive data can lead to threats such as
   impersonation attacks (establishing rogue sessions), theft of service
   (if services are obtainable), and zombie attacks.  It is important
   for the device to ensure the authenticity of the PNC and the PCC
   since impersonation of the SIP service provider can lead to DoS and
   man-in-the-middle (MITM) attacks.

Top      Up      ToC       Page 48 
   Profile content retrieval allows a device to retrieve profile data
   via content indirection from a PCC.  This communication is
   accomplished using one of many profile delivery protocols or
   frameworks, such as HTTP or HTTPS as specified in this document.
   However, since the profile data returned is subject to the same
   considerations as that sent via profile notification, similar threats
   exist.  For example, DoS attacks (rogue devices bombard the PCC with
   requests for a specific profile) and attempts to modify erroneous
   data onto the PCC (since the location and format may be known).
   Thus, for the delivery of any sensitive profile data, authentication
   of the entity requesting profile data is required.  It is also
   important for the requesting entity to authenticate the profile
   source via content indirection and ensure that the sensitive profile
   data is protected via data integrity.  For sensitive data that should
   not be disclosed to unauthorized parties, data confidentiality is
   also required.

   The following subsections highlight the security considerations that
   are specific to each profile type.

9.1.  Local-Network Profile

   A local network may or may not (e.g., home router) support local-
   network profiles as specified in this framework.  Even if supported,
   the PDS may only be configured with a generic local-network profile
   that is provided to every device that requests the local-network
   profile.  Such a PDS may not implement any authentication
   requirements or TLS.

   Alternatively, certain deployments may require the entities -- device
   and the PDS -- to authenticate each other prior to successful profile
   enrollment.  Such networks may pre-configure user identities to the
   devices and allow user-specific local-network profiles.  In such
   networks, the PDS will support digest authentication, and the devices
   are configured with user identities and credentials as specified in
   Section 5.3.1.  If sensitive profile data is being transmitted, the
   user identity is a SIPS URI that results in TLS with the next-hop
   (which is authenticated), and digest authentication is used by the
   PDS and the device.

   This framework supports both use cases and any variations in between.
   However, devices obtaining local-network profiles from an
   unauthenticated PDS are cautioned against potential MITM or PDS
   impersonation attacks.  This framework requires that a device reject
   sensitive data, such as credentials, from unauthenticated local-
   network sources.  It also prohibits devices from responding to
   authentication challenges in the absence of TLS on all hops as a
   result of using a SIPS URI.  Responding to unauthenticated challenges

Top      Up      ToC       Page 49 
   allows for dictionary attacks that can reveal weak passwords.  The
   only exception to accepting such sensitive data without
   authentication of the PDS is in the case of bootstrapping (see
   Section 5.3.1).  In the case of bootstrapping, the methods employed
   need to be aware of potential security threats such as impersonation.

   SIP Identity is useful for the device to validate notifications in
   the absence of a secure channel such as TLS when a SIPS URI is used.
   In such cases, the device can validate the SIP Identity header to
   verify the source of the profile notification, and the source of the
   profile data when content indirection is not used.  However, the
   presence of the header does not guarantee the validity of the data.
   It verifies the source and confirms data integrity, but the data
   obtained from an undesired source may still be invalid, e.g., invalid
   outbound proxy information, resulting in DoS.  Thus, devices
   requesting the local-network profile from unknown networks need to be
   prepared to discard information that prevent retrieval of other,
   required, profiles.

9.2.  Device Profile

   Device profiles deal with device-specific configuration.  They may be
   provided to unknown devices that are attempting to obtaining profiles
   for purposes such as trials, self-subscription (not to be confused
   with [RFC3265]), and emergency services [PHONEBCP].

   This framework allows the device profile to be used for bootstrapping
   a device.  Such bootstrapping profile data may contain enough
   information to connect to a Provider.  For example, it may enable the
   device to communicate with a device provider, allowing for trial or
   self-subscription services via visual or audio interfaces (e.g.,
   interactive voice response), or customer service representatives.
   The profile data may also allow the device a choice of device
   providers and allow the end-user to choose one.  The profile data may
   also contain identities and credentials (temporary or long-term) that
   can be used to obtain further profile data from the network.  This
   framework recommends the use of the SIP Identity header by the PDS.
   However, to be able to validate the SIP Identity header, the device
   needs to be pre-configured with the knowledge of allowable domains or
   certificates for validation (e.g., using PKI).  If not, the device
   can still guarantee header and body integrity if the profile data
   contains the domain certificate (but the data can still be invalid or
   malicious).  In such cases, devices supporting user interfaces may
   obtain confirmation from the user trying to bootstrap the device
   (confirming header and body integrity).  However, when the SIP
   Identity header is not present, or the device is not capable of
   validating it, the bootstrapping data is unauthenticated and obtained
   without any integrity protection.  Such bootstrapping data, however,

Top      Up      ToC       Page 50 
   may contain only temporary credentials (SIPS URI and digest
   credentials) that can be used to reconnect to the network to ensure
   data integrity and data confidentiality prior to obtaining long-term
   credentials.  It is to be noted that such devices are at the mercy of
   the network they request the device profile from.  If they are
   initialized in a rogue network, or get hijacked by a rogue PDS, the
   end-user may be left without desired device operation or, worse,
   unwanted operation.  To mitigate such factors the device provider may
   communicate temporary credentials (e.g., passwords that can be
   entered via an interface) or permanent credentials (e.g., a USB
   device) to the end-user for connectivity.  If such methods are used,
   those credentials MUST be quickly replaced by large-entropy
   credentials, to minimize the impact of dictionary attacks.  Future
   enhancements to this framework may specify device capabilities that
   allow for authentication without any provider-specific configuration
   (e.g., X.509 certificates using PKI can allow for authentication by
   any provider with access to the CA certificate).  Alternatively, the
   device may be pre-configured with credentials for use with content
   indirection mechanisms.  In such circumstances a PDS can use secure
   content indirection mechanism, such as HTTPS, to provide the
   bootstrapping data.

   Once a device is associated with a device provider the device profile
   is vital to device operation.  This is because the device profile can
   contain important operational information such as users that are to
   be allowed access (white-list or black-list), user credentials (if
   required) and other sensitive information.  Thus, it is necessary to
   ensure that any device profile containing sensitive information is
   obtained via an authenticated source, with integrity protection, and
   delivered to an authenticated device.  For sensitive information such
   as credentials, data confidentiality is also required.  The framework
   requires that devices obtain sensitive information only from
   authenticated entities except while it is being bootstrapped.  In
   cases where data confidentiality needs to be mandated for
   notifications, the device provider can configure the device with a
   SIPS URI, to be used as the Subscription URI, during profile
   enrollment.  The framework also requires a PDS presenting sensitive
   profile data to use digest authentication.  This ensures that the
   data is delivered to an authenticated entity.  Authentication of
   profile retrieval via content indirection for sensitive profiles is
   via HTTPS utilizing HTTP digest.

9.3.  User Profile

   Devices can only request user profiles for users that are known by a
   SIP service provider.  PDSs are required to reject user profile
   enrollment requests for any users that are unknown in the network.

Top      Up      ToC       Page 51 
   For known user AoRs that are allowed to retrieve profiles, the
   security considerations are similar to that of the device profile
   (except for bootstrapping).

10.  Acknowledgements

   The author appreciates all those who contributed and commented on the
   many iterations of this document.  Detailed comments were provided by
   the following individuals: Jonathan Rosenberg, Henning Schulzrinne,
   Cullen Jennings, Rohan Mahy, Rich Schaaf, Volker Hilt, Adam Roach,
   Hisham Khartabil, Henry Sinnreich, Martin Dolly, John Elwell, Elliot
   Eichen, Robert Liao, Dale Worley, Francois Audet, Roni Even, Jason
   Fischl, Josh Littlefield, and Nhut Nguyen.

   The final revisions of this document were a product of design team
   discussions.  The editor wishes to extend special appreciation to the
   following design team members for their numerous reviews and specific
   contributions to various sections: Josh Littlefield (Overview,
   Section 6), Peter Blatherwick (Section 6), Cullen Jennings
   (Security), Sam Ganesan (Section 6), and Mary Barnes (layout, Section
   6).

   The following design team members are thanked for numerous reviews
   and general contributions: Martin Dolly, Jason Fischl, Alvin Jiang,
   and Francois Audet.

   The following SIPPING WG members are thanked for numerous reviews,
   comments and recommendations: John Elwell, Donald Lukacs, Roni Even,
   David Robbins, Shida Schubert, and Eugene Nechamkin.  The editor
   would also like to extend a special thanks to the comments and
   recommendations provided by the SIPPING WG, specifically Keith Drage
   (restructuring proposal) and John Elwell (numerous reviews and
   recommendations).

   Additionally, appreciation is also due to Peter Koch for expert DNS
   advice.

   Finally, sincere appreciation is extended to the chairs (Mary Barnes
   and Gonzalo Camarillo); the past/current Area Directors (Cullen
   Jennings, Jon Peterson, and Robert Sparks) for facilitating
   discussions, reviews, and contributions; and, the expert reviewers
   from the IESG (Peter McCann, Catherine Meadows).

Top      Up      ToC       Page 52 
11.  References

11.1.  Normative References

   [FIPS-180-3]  National Institute of Standards and Technology (NIST),
                 "Secure Hash Standard (SHS)", FIPS PUB 180-3,
                 October 2008.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]     Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
                 S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
                 Authentication: Basic and Digest Access
                 Authentication", RFC 2617, June 1999.

   [RFC2818]     Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3261]     Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                 Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                 and E. Schooler, "SIP: Session Initiation Protocol",
                 RFC 3261, June 2002.

   [RFC3263]     Rosenberg, J. and H. Schulzrinne, "Session Initiation
                 Protocol (SIP): Locating SIP Servers", RFC 3263,
                 June 2002.

   [RFC3265]     Roach, A., "Session Initiation Protocol (SIP)-Specific
                 Event Notification", RFC 3265, June 2002.

   [RFC3319]     Schulzrinne, H. and B. Volz, "Dynamic Host
                 Configuration Protocol (DHCPv6) Options for Session
                 Initiation Protocol (SIP) Servers", RFC 3319,
                 July 2003.

   [RFC3361]     Schulzrinne, H., "Dynamic Host Configuration Protocol
                 (DHCP-for-IPv4) Option for Session Initiation Protocol
                 (SIP) Servers", RFC 3361, August 2002.

   [RFC4122]     Leach, P., Mealling, M., and R. Salz, "A Universally
                 Unique IDentifier (UUID) URN Namespace", RFC 4122,
                 July 2005.

Top      Up      ToC       Page 53 
   [RFC4474]     Peterson, J. and C. Jennings, "Enhancements for
                 Authenticated Identity Management in the Session
                 Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC4483]     Burger, E., "A Mechanism for Content Indirection in
                 Session Initiation Protocol (SIP) Messages", RFC 4483,
                 May 2006.

   [RFC4704]     Volz, B., "The Dynamic Host Configuration Protocol for
                 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
                 Option", RFC 4704, October 2006.

   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26,
                 RFC 5226, May 2008.

   [RFC5234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5246]     Dierks, T. and E. Rescorla, "The Transport Layer
                 Security (TLS) Protocol Version 1.2", RFC 5246,
                 August 2008.

   [RFC5626]     Jennings, C., Mahy, R., and F. Audet, "Managing Client-
                 Initiated Connections in the Session Initiation
                 Protocol (SIP)", RFC 5626, October 2009.

11.2.  Informative References

   [PHONEBCP]    Rosen, B. and J. Polk, "Best Current Practice for
                 Communications Services in support of Emergency
                 Calling", Work in Progress, October 2010.

   [RFC0959]     Postel, J. and J. Reynolds, "File Transfer Protocol",
                 STD 9, RFC 959, October 1985.

   [RFC2132]     Alexander, S. and R. Droms, "DHCP Options and BOOTP
                 Vendor Extensions", RFC 2132, March 1997.

   [RFC4510]     Zeilenga, K., "Lightweight Directory Access Protocol
                 (LDAP): Technical Specification Road Map", RFC 4510,
                 June 2006.

   [RFC4634]     Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
                 (SHA and HMAC-SHA)", RFC 4634, July 2006.

Top      Up      ToC       Page 54 
   [RFC4825]     Rosenberg, J., "The Extensible Markup Language (XML)
                 Configuration Access Protocol (XCAP)", RFC 4825,
                 May 2007.

Authors' Addresses

   Daniel Petrie
   SIPez LLC
   246A Park Ave
   Arlington, MA  02476
   USA

   EMail: dan.ietf@SIPez.com
   URI:   http://www.SIPez.com/


   Sumanth Channabasappa (editor)
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   EMail: sumanth@cablelabs.com
   URI:   http://www.cablelabs.com/