Re: Notification authentication in CPIM (proposed changes)
Graham Klyne <[email protected]>
| Newsgroups | gmane.ietf.impp |
|---|---|
| Message-ID | <[email protected]> |
I think I find these changes seem mostly reasonable (though I confess to finding the diff difficult to read). I'd like to check a couple of points: - The 'target' option is removed from the abstract notify operation because it's redundant with the 'entity=' attribute of the <presence> element in the PIDF payload? - The 'source' option is added to the abstract operation to identify the presence service. I'm not clear why this is needed -- maybe because I haven't followed the debate so closely. - I don't understand the discussion about alternative names an X.509 certificates. Alternative to *what*? Again, maybe I'm missing something because I haven't lately followed this discussion very closely. - Appendix B: I think your comments on wrapping the presence information (section 3.3) provide the main information for profiling the CPIM message format. Just commenting. (Hmmm... did we pick a MIME type for containing PIDF? Message/CPIM-Presence, maybe?) #g -- At 03:20 PM 7/20/02 -0400, John D. Ramsdell wrote: >Enclosed is a set of proposed changes to the CPIM document focused >only on the issue of allowing notifications to be authenticated. 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. > >The changes consist of replacing the target attribute of a notify >request with a source attribute that identifies originator of the >request, and then describing a CPIM-MSGFMT like format for >notifications that can be signed. > >Hope this helps, > >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 Sat Jul 20 15:01:59 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,30 @@ > 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 PRES >+ URI must not specify both a PRESENCE SERVICE and a PRESENTITY. >+ > 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:server@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 +616,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 +767,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 and >+ presence information (c.f. section 2.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 +896,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 +914,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 +979,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 +1065,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] ------------------- Graham Klyne <[email protected]> [reminder: [email protected] for non-technical discussions, please]