Re: On the need for presence service identifiers

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

> (Note that to a degree, I'm playing devil's advocate here in the
> interest of the discussion - I see some merit in your proposal, but I'm
> not yet convinced that it is the only solution.)
> 
> If the presence service is acting with authority on behalf of the
> principal in the signing of presence notifications, why could it not do
> the same thing for subscriptions? 

I see your point.  One can imagine an architecture in which a person's
presence service signs the both notification and subscription
requests.  Each presence client would establish a TCP/IP connection to
the presence service and authenticate the connection.  The
authentication process would convince the service that it is okay to
sign a subscription request that originates from this connection.
Some other security mechanism would be used to ensure the integrity of
subscription requests between the client and the presence service, but
that's okay because it's a local matter.

Your insight suggests to me that for subscriptions, a presence service
should accept a signed request if is signed using the watcher's
presentity private key (the usual case), or if it is signed by the
presence service's private key.  In other words, when X.509
certificates are being used, the subjectAltName must contain either
the presentity identifier of the watcher, OR the watcher's presence
service identifier.

Playing devil's advocate was a good thing.  Now it's my turn.

One can imagine the same architecture for instant messaging.  If an
instant messaging service had a identity, it could sign messages
coming from authenticated sources that are routed through it.  I can
imagine a site that has single system login by deploying Kerberos.  By
this I mean, people login once, and every application uses Kerberos to
acquire a user's credentials.  As a result, a user could create an
authenticated connection to an instant messaging service without
exchanging passwords, or instant messaging specific certificates.

Do we really want to pursue this idea?

By the way, Jon Peterson is clearly promoting the idea that the signed
content of a presence notification need not contain the presence
service's identifier, since in secure situations, this identifier
would be in the subjectAltName of the X.509 V3 Certificate, and
otherwise could be forged.  What do you think of this idea?  It
certainly works in environments that use X.509 Version 3 Certificates.

John



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