Re: Notification authentication in CPIM (proposed changes)

Graham Klyne <[email protected]> writes:

> - 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?

Yes

> - 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?)

I was not sure where my changes should be put, but my best guess was
they need to be in the main body.  I'll leave it to Dave to decide
this.

> - 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.

The key change I am proposing is that the source of a notification be
identified, and that it have its own identifier.  I seem to be having
trouble explaining the need for this change.  Let me try again.  Maybe
some of this text can be lifted as rationale in the CPIM document.

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 D. Ramsdell, 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.

For IMPP, we define 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 presentities.

For instant messaging, we chose to use the name of an instant inbox to
identify 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 in its
Subject Alternative Names field.  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 in its Subject
Alternative Names field.  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.  Although not covered by the IMPP WG, this
principal is also the obvious choice for operations that update
the subject's presence information, and can 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.

John



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