Re: Notification authentication in CPIM (proposed changes)
[email protected] (John D. Ramsdell)
| Newsgroups | gmane.ietf.impp |
|---|---|
| Message-ID | <[email protected]> |
A listing of the SIMP release directory shows that the complete
security story was part of SIMP 1.1 and released on May 12, 2000, yet
Graham's note suggests I still cannot explain this model behind strong
end-to-end authentication. Please give me another chance. The only
thing new in this diff is the expanded rationale in the "Instant
messages and presence service" section. In another improvement, the
new text states the situation reguarding CPIM and allowing end-to-end
security for subscription requests.
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 Fri Jul 26 13:51:36 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,76 @@
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 to
+ authenticate the request. Recall the Subject-Object-Operation
+ model of access control. In that model, a subject applies an
+ operation to an object. A subject may be any entity, such as a
+ person or a service. Every subject has a set of identities.
+ Each identity is called a principal. People have a name
+ principal, e.g. John Doe, and in the USA, a SSN principal. Some
+ services have a IP:port principal given by their IP address and
+ port.
+
+ In this model, access to controlled objects involves determining
+ if a subject has permission to apply a given operation to an
+ object. Since a subject is identified by a principal, the
+ question reduces to deciding if a principal has permission to
+ apply a given operation to an object.
+
+ In CPIM, there are three types of operations, send message,
+ notify, and subscribe, and two types of objects, instant inboxes
+ and presentities. A send message operation is applied to an
+ instant inbox, and notify and subscribe operations apply to a
+ presentity.
+
+ For instant messaging, the name of an instant inbox identifies
+ the subject that is sending an instant message. The 'From'
+ header of an instant message contains the appropriate principal.
+ In secure settings, it is important to ensure only authorized
+ persons are allowed to place their principal in the 'From'
+ header. One way a person can prove it is authorized, is by
+ signing the message, and also including an X.509 certificate [?]
+ that includes the principal as one of its Subject Alternative
+ Names. This practice provides strong end-to-end authentication.
+
+ For presence notification operations, the same method can be used
+ to provide strong end-to-end authentication. The 'From' header
+ of a notification must contain a principal that identifies the
+ subject of the operation, the presence service. The service
+ proves it is authorized to use this principal by signing the
+ message, and including an X.509 certificate that includes the
+ principal as one of its Subject Alternative Names. Note that
+ this principal does not identify a presentity, as a presence
+ service is allowed to serve many presentities. It is impractical
+ to include all presentities served by a service, because the
+ certificate would be large, and have to be changed whenever the
+ list of allowed presentities changes.
+
+ For subscription operations, the natural principal is the name of
+ the presentity that provides presence information for the subject
+ of the subscription operation, the watcher attribute. Since CPIM
+ does not yet define a common format for the subscription
+ operation, it cannot be signed, however, this principal is also
+ the obvious choice for operations that update the subject's
+ presence information, and can also be used to sign elements in
+ the presence information. In any event, the principal that
+ identifies a presence service must never identify a presentity,
+ otherwise, the subject identified by the presentity can
+ masquerade as a presence service.
5. IANA Considerations
@@ -875,6 +946,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 +964,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 +1029,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 +1115,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]