Re: Notification authentication -- more things left out of the PIDF draft

Let me spell out in detail how the PIDF draft can be changed to be
supportive of digitial signatures.  It turns out that little need be
done.  The only change that really must be made is that the section
titled "Wrapping 'application/cpim-pidf+xml' Data" that was present in
draft version 2 should be added back with one simple modification.
The description of the 'From' header should be vague enough to allow a
signing presence server the ability to place a presence URI in that
header that does not name the PRESENTITY of the contents.

Consider using this text:

5.1.1. The 'From' header

   The 'From' header contains a presence URI that names the origin of
   the PRESENCE INFORMATION.  Any application compliant to this
   specification MUST recognize the 'From' header.

   The contents of the 'From' header may differ from the presentity
   attribute of the <presence> element in the presence document.  This
   header is needed when the presence server explicitly states the
   publisher regardless of the content of presence documents, or when
   the presence server is signing content.

Once this change is made, the Security Consideration section could be
amended to include text something like:

6. Security Considerations

....

The CPIM Presence Information Data Format provides a SUBSCRIBER means
of identifying and authenticating the PRESENCE SERVICE that is
supplying notifications using digital signatures.  The use of both
digital signatures and the PIDF provides a protocol with a strong
mechanism to meet the requirement for authentication stated in
[RFC2779, Section 5.3.3].  Failure to provide some mechanism to
authenticate notification requests makes a SUBSCRIBER vulnerable to
being spoofed by a PRESENCE SERVICE or other entity.

A SUBSCRIBER MAY make access control decisions based on the presence
URI in the 'From' header of a notification request, and the existence
of a valid signature.  To ensure that the 'From' header identifies the
signer, a signed request SHOULD include a certificate that binds it to
the presence URI in the 'From' header.  For example, when using X.509
Version 3 Certificates [X.509V3], the presence URI in the 'From'
header SHOULD be one of the certificate's Subject Alternate Names.

.... [ Added Reference ]


[X.509V3]
   R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 Public Key
   Infrastructure Certificate and Certificate Revocation List (CRL)
   Profile", RFC 3280, April 2002.

....

John



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



[email protected] (John D. Ramsdell) writes:

> In a setting in which security is important, one must provide a means
> for a client that is watching a presence entity to verify that
> notifications about the presence entity originated at the presence
> server to which the watcher is subscribed.  To allow a notification to
> be signed, it is important to define a standard way in which PIDF is
> embedded into CPIM-MSGFMT content, but the most important aspect of
> this embedding is that the From field identify the server that is
> sending the notification, and not identify the presence entity that is
> contained in the content.  The From field of a subscription request
> names a presence entity and identifies the principal that originated
> the request.  If the From field of a notification names a presence
> entity, than it is erroneously identifying a client as the source of a
> notification, where as the true originator of the notification is the
> presence server.  Failure to correctly identify the principal of a
> notification negates the value of using digital signatures for
> authentication.
> 
> For more on this topic, see:
> 
>    http://simp.mitre.org/drafts/simp_server.html#security
> 
> and 
> 
>    http://simp.mitre.org/drafts/simp_server.html#notify
> 
> John
> 
> 
>   [reminder: [email protected] for non-technical discussions, please]
> 


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