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

The reason for the original wrapping section was so that different
entities could construct a single multi-source presence document where
each of the sources could sign their own section. We determined that
this provision opened too large a can of worms as it tended to push
people towards discussing partial presence updates which we excluded
according to a minimalist approach to RFC 2778.

This means that the presence document can be treated as a single opaque
entity and as such can be transported securely by any mechanism that
allows the safe transmission of MIME data. As such, the PIDF format is
agnostic as far as transport is concerned - this is a matter for
whatever protocol is moving the data. If you consider the PIDF draft,
you see that it now defines the format of a data document and nothing
more.

Adrian.

On 16 May 2002 14:03, John D. Ramsdell wrote:
> 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]