Re: Sub/Not Security, Presence service identifiers

"Mark Day" <[email protected]> writes:

> 5.2.4 of RFC2779 says
> 
>    The protocol MUST provide means of protecting B from another
>    PRINCIPAL C "spoofing" notification messages about B.
> 
> It is not otherwise specific about the mechanism to be used. I think one
> approach could be to authenticate presence services, but (speaking as a
> non-expert) I don't think that exhausts the space of possible ways to meet
> the requirement.  

I cannot say there exists no other solution, but in all the time I
have working on this topic, digital signatures are the only mechanism
I have considered for end-to-end authentication.  With Email, the use
of PGP and X.509 Certificates with digital signatures are the
mechanisms of choice for strong authentication.  The CPIM MSGFMT makes
it easy to apply these mechanisms to authenticate instant messages,
and I expect many people will.  I believe it would be very difficult
to ask people to use another form of strong authentication for
presence given that infrastructure for digital certificates is in
place and will be used with instant messaging.

> I think the replay attack cited as an example could be foiled by
> some form of timestamping.

I assume you are referring to the example in

  http://www.imppwg.org/ml-archive/IMPP-WG/200208/msg00003.html

The purpose of the example is to demonstrate a situation in which it
is important that a presence service has an identifier that
distinguishes it as a presences service.  In that example, a bad guy
that is not approved to behave as a presence service, is fabricating
presence information in an effort to spoof a watcher into using the
wrong inbox for instant messaging.  Since the bad guy is creating
presence information and signing it, timestamping will not foil this
attack.

> I would appreciate a focus on this *requirement* and reasonable ways that we
> can ensure that CPIM meets it, rather than narrowing prematurely to a
> particular implementation and its characteristics.

This is always a good idea.

> [Unless we think that presence-service authentication really is the
> only approach, in which case we should say so explicitly somewhere.]

Or it may be the only approach that fits well with existing
authentication mechanisms.

> > One final point, I believe there is an explicit requirement in one of
> > the RFC's that says a watcher has to be able to authenticate a
> > presence service.  I'm too lazy to look it up now.
> 
> Pretty much all of the security requirements in 2779 are phrased in terms of
> the ways that principals must be able to communicate or protected from one
> another, not in terms of specific constraints on the entities between those
> principals.
> 
> --Mark

John



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