RE: Sub/Not Security, Presence service identifiers

A few more notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, August 20, 2002 5:41 AM
> To: Peterson, Jon
> Cc: [email protected]; [email protected]
> Subject: Re: Sub/Not Security, Presence service identifiers
> 
> 
> "Peterson, Jon" <[email protected]> writes:
> 
> > Actually, I'm not sure this is true. The presence information could be
> > signed by the presentity. If so, it's irrelevant how the signed presence
> > information is transported to the watcher, provided it is
> > transported intact
> 
> I completely disagree with this analysis.  Let's look at the
> requirement.
> 
> 5.2.4 of RFC2779 says
> 
>    The protocol MUST provide means of protecting B from another
>    PRINCIPAL C "spoofing" notification messages about B.
> 
> The requirement is about giving B the means to distinguish between
> notification messages sent by authoritative sources from those sent by
> non-authoritative sources.  

Actually, I don't think that's what 5.2.4 is about. Principal B is the
generator of notifications in this instance, not the recipient. It is A, not
B, that would be distinguishing a notification created by B from a
notification created by C. It could do so if B provided a signature over the
message that could not be replicated or replayed by C. This is completely
orthogonal to the issue of whether or not a presence service handles the
notification after B signs it. It is not at all clear how a presence service
adds any value to this requirement. I note that this requirement doesn't
mention a presence service.

There is no concept of 'authoritative notification' in RFC2779 AFAIK. It is
assumed that presence information is generated by the presentity.

> The path by which the presence information
> is relevant.  In particular, a bad guy can take perfectly good
> presence information, and spoof B by delaying and/or changing the order
> of delivery of presence information.
> 

Again, the path is not relevant if the presence information has some
internal safeguards that prevent replay protection, like a timestamp.
Timestamping would seem to take care of both of issues you describe above.
Wouldn't it be best if B, the creator of the presence information, inserted
the timestamp when the presence information was created?

> Jon, I updated my example on the need for presence service identifiers
> and set it to the list.  See if that helps you decide who must sign
> presence notifications.
> 
> John
> 



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