Notification authentication in CPIM (proposed changes)

Enclosed is a set of proposed changes to the CPIM document focused
only on the issue of allowing notifications to be authenticated.  It
incorporates the idea of having a presence service identifier being
derived from the presentity's identifier it serves.  The changes are
supplied as a unified patch produced by diff against the CPIM V2
document.  Perform 'man patch' to see how to apply the patch.

John

bash-2.01$ diff -u draft-ietf-impp-cpim-02.txt draft-ietf-impp-jdr.txt
--- draft-ietf-impp-cpim-02.txt	Tue Dec  4 09:59:53 2001
+++ draft-ietf-impp-jdr.txt	Sun Jul 21 09:19:06 2002
@@ -444,9 +444,9 @@
           +-------+                    +-------+
           
           <notify watcher='pres:[email protected]'
-          target='pres:[email protected]'
+          source='pres:[email protected]'
           transID='1234'>
-          <presence entityInfo='http://www.example.com/fred/'>
+          <presence entity='pres:[email protected]'>
           <tuple destination='im:[email protected]' status='open'
           />
           </presence>
@@ -508,13 +508,36 @@
      lookup is performed for:
           _pres._pepp.example.com.
 
+3.2 1/2  Identification of PRESENCE SERVICES
+
+     A PRESENCE SEVICE is specified using the PRES URI scheme.  A
+     presence URI specifies a presence service only if its local part
+     is the string 'notifier'.  A presence URI that specifies a
+     presentity may not have a local part of 'notifier', and the
+     presence service identifier associated with a presentity is
+     derived from it by replacing the local part with the string
+     'notifier'.
+
+
 3.3. Format of Presence Information
      
-     The format of a Presence message is a MIME
-     "Message/cpim,profile=pres" object, as defined in
-     MESSAGE/CPIM PROFILE FOR PRESENCE and XML/MIME[6].
-     Representation of non-ASCII character sets in MIME is a
-     standard feature of MIME.
+     The format of a Presence message is a MIME "Message/cpim" object
+     that wraps a PIDF document with three headers, a 'To' header
+     giving the watcher attribute of the notification request, a
+     'Datetime' header to avoid replay, and a 'From' header used to
+     identify the PRESENCE SERVER, the source attribute of the
+     request.  The document can be signed using the same mechanisms
+     used for an instant message.  An example follows.
+
+         Content-type: Message/CPIM
+ 
+         To: pres:client@laptop
+         From: pres:notifier@rack
+         Datetime: 2002-07-18T13:38:22-8:00
+ 
+         Content-type: application/cpim-pdif+xml	
+ 
+         <presence entity='pres:info@rack'>...</presence>
 
 3.4. The Presence Service
      
@@ -599,16 +622,17 @@
      *    The watcher parameter specifies the WATCHER associated with
           the subscription;
 
-     *    The target parameter specifies the PRESENTITY associated
-          with the presence information;
+     *    The source parameter specifies the PRESENCE SERVICE providing
+          the presence information;
 
      *    The transID parameter specifies the transaction-identifier
           associated with this operation; and,
 
      *    The presence information for the PRESENTITY.
-     
-     There is no application response to the notify
-     operation.
+
+     The presence information specifies the PRESENTITY associated with
+     the presence information.  There is no application response to
+     the notify operation.
 
 3.4.3.    The Unsubscribe Operation
      
@@ -749,29 +773,32 @@
      of the public key across multiple messages, would
      greatly reduce instant messaging overhead.
 
-4.3.1.    Instant messages
+4.3.1.    Instant messages and presence service
      
-     End to end security for instant messages can be provided
-     using any of the MIME-based security mechanisms (S/MIME
-     [8], OpenPGP [7]), as instant message payload content is
-     not interpreted or reformatted in transit.
-     
-     This specification allows any pair of communicating
-     parties to use any MIME-based security framework for
-     instant messages (c.f. section 2.3), but mechanisms for
-     establishing the required bilateral arrangements and key
-     exchange are not specified here.
-
-4.3.2.    Presence service
-     
-     The situation regarding end-to-end security for presence
-     services is unclear, as there is no common encapsulation
-     framework specified for presence, and the presence data
-     itself is not invariant across different IM services.
-     
-     [[[NOTE: this raises a case for fixing the presence
-     information to a specific format if end-to-end security
-     capability is to be a requirement.]]]
+     End to end security for instant messages and presence information
+     can be provided using any of the MIME-based security mechanisms
+     (S/MIME [8], OpenPGP [7]), as the payload content is not
+     interpreted or reformatted in transit.
+     
+     This specification allows any pair of communicating parties to
+     use any MIME-based security framework for instant messages
+     (c.f. section 2.3) and presence information (c.f. section 3.3),
+     but mechanisms for establishing the required bilateral
+     arrangements and key exchange are not specified here.
+
+     The CPIM protocol has been designed so that the 'From' header of
+     an instant message or a presence notification can be used as an
+     alternative name for the request's originator.  When using X.509
+     V3 Certificates [?], these alternative names can be bound to a
+     public key by including them in the certificate's Subject
+     Alternative Names.  Clients and servers receiving signed requests
+     with an X.509 V3 Certificate, can determine if the sender is
+     allowed to place the given alternative name in the 'From' header
+     of the request.  When employed, this check prevents spoofing by
+     limiting the use of an alternative name to only the possessor of
+     the certificate's private key.  In secure applications, this
+     check should be employed whenever the 'From' header names a
+     trusted entity.
 
 
 5.   IANA Considerations
@@ -875,6 +902,7 @@
           =============================
           PRESENTITY c.f., Section 5.2 pres:[email protected] -->
           <!ENTITY % PRESENTITY "CDATA">
+          <!ENTITY % PRESENCESERVICE "CDATA">
           <!-- Abstract syntax for presence information -->
           <!ELEMENT presence (tuple+)>
           <!ATTLIST presence entityInfo %URI; "" >
@@ -892,7 +920,7 @@
           <!-- Abstract syntax for the notify operation -->
           <!ELEMENT notify (presence)>
           <!ATTLIST notify watcher %PRESENTITY;
-          #REQUIRED target %PRESENTITY;
+          #REQUIRED source %PRESENCESERVICE;
           #REQUIRED transID %UNIQID;
           #REQUIRED>
           <!-- Abstract syntax for the unsubscribe operation -->
@@ -957,6 +985,9 @@
            February 2000.
      [12]  Allocchio, C., "GSTN ADDRESS ELEMENT EXTENSIONS IN E-MAIL
           SERVICES", RFC 2846, June 2000.
+     [?] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509
+         Public Key Infrastructure Certificate and Certificate Revocation
+         List (CRL) Pro­ file", RFC 3280, April 2002.
 
 
 11.  Authors' Addresses
@@ -1040,7 +1071,8 @@
 
 Appendix B.    Message/CPIM for Presence
      
-     
+
+     [[ This needs work. ]]     
      <<<This section contains detail that creates a profile
      of Content-Type=Message/CPIM, to cover use for Presence
      transactions. Text to be partly extracted from draft-
bash-2.01$ 



  [reminder: [email protected] for non-technical discussions, please]