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

"Adrian Bateman" <[email protected]> writes:

> The PIDF XML document doesn't have a 'From' header - I think the issue
> you are describing is a protocol one, not a data format one. I'm not
> saying it doesn't need to be considered, but that it should be part of
> the protocol that deals with transmitting the presence data documents
> themselves (and in our context therefor, probably in CPIM too).

The key to reliable request accountability is the use of a single
mechanism to link a request with its principal.  For instant messages,
we can do what is done with Email.  The CPIM-MSGFMT specifies a format
that is Email like.  The 'From' header names the inbox to which
replies should be sent, but in practice, it also identifies the sender
of the message.  A digital signature can be attached to a message so
that a client can display the distinguished name of the signer for
added authentication, however, a signature alone does not allow the
receiver to know if the signer is authorized to send a message using
the given Email address.

As I am sure you know, secure implementations of Email reject signed
messages if the attached certificate does not include the Email
address in the 'From' header as one of its Subject Alternate Names.
By including Email addresses in certificates, servers and gateways can
perform this filtering based on the address in the 'From' header and
the validity of the signature.  Application of policy becomes simple
and uniform.

The beauty of the current IMPP CPIM-MSGFMT approach to instant
messages is that all existing, well-honed practice used for Email can
be applied to instant messages.  It's all straightforward.

When extending request accountability to non-SEND operations, it is
far better to reuse existing, well-proven mechanisms, i.e., the ones
in place for SEND operations.  For notifications, all that need be
done is to define a common way of embedding PIDF into CPIM-MSGFMT such
that the 'From' header can be used to identify the presence service
making the request.  Using this procedure to achieve request
accountability allows the reuse of security sensitive code, and eases
the task of implementing access control mechanisms.

The purpose of the PIDF document is to define a standard format that
allows the exchange of presence information.  Notification request
accountability requires a standard format, the data to which on
attaches a signature.  Therefore, the PIDF is the appropriate document
in which to define an embedding of presence information into
CPIM-MSGFMT.  If not in the PIDF document, where else would it go?

John


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