RE: Notification authentication -- more things left out of the PI DF draft

Since pidf allows extensions from any other namespace (in several places),
XML Digital Signatures can be used in what is available already in the
current draft.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, May 16, 2002 6:03 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: 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]
> 


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