RE: Sub/Not Security, Presence service identifiers

A few notes for John below. I think this exchange may demonstrate how our
assumptions differ - we're making progress, I believe.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, August 19, 2002 5:13 AM
> To: [email protected]
> Cc: 'Peterson, Jon'; [email protected]
> Subject: Re: Sub/Not Security, Presence service identifiers
> 
[snip]
> 
> When receiving a notification, a watcher would like to know that the
> presence service that is sending the notification is authorize to do
> so on behalf of the person that provided presence information.
> Without the authentication of the presence service, a watch could be
> spoofed into receiving presence information from an invalid source.
> 

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
- the watcher makes its decision based the signature on the presence
information (and its contents), not the party that delivered the information
to the watcher. There would be no need for a principal to bestow any special
authority on a presence service in that case. To which you respond:

> Signing the presence information by the person that created it does
> not fix the problem, because a spoofing presence service could collect
> signed presence information and replay them in an order that
> misinforms the watcher. 

Not if replay protection is staged inside the signed presence information
(with a 'wrapper' or not - as long as the signature is over the timestamp).
In any event, this argument motivates the need for a timestamp, not the need
to stage security at a presence service - a presence service alone wouldn't
address this vulnerability without a timestamp on the presence information.
Or is there something I'm missing here?
 
> In addition, in some systems, a presence
> service generates the online information in a presence information
> document based on whether there is an open TCP/IP connection to the
> person's client.  In these systems, only the presence service can sign
> all of the presence information, because the person does not
> contribute the online status elements.  
> 

I think I'm a little confused by the model presented here as well. RFC2778
defines logical roles for a presentity and a presence service. No doubt a
presentity and presence service can be implemented on the same device or as
decomposed devices, and these entities could be operated by an end user, or
be under the control of some kind of service provider that merely receives
input from unrelated devices controlled by end users. None of this changes
the fact that a presentity generates presence information and gives this
presence information to presence services that distribute it to watchers in
notifications. The requirements in RFC2779 do not, to my knowledge, describe
a presence service creating presence information. Just look at the
definitions in RFC2778:

   PRESENTITY (presence entity): provides PRESENCE INFORMATION to a
      PRESENCE SERVICE.

   PRESENCE SERVICE: accepts, stores, and distributes PRESENCE
      INFORMATION.

I think the sort of 'presence service' you describe above (that generates
presence information from monitoring sockets) is actually a presentity,
probably what we'd call a distributed presentity, in the RFC2778 model.

Note that the need for identifiers for presentities is not up for debate,
though of course this identitifer is already provided in the PIDF format.

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

Well, there are two cases in which this might be required:

- After a watcher sends a subscription, when a subscription reply from the
presence service arrives.
- When the presence service sends a notification to the watcher.

Authentication requirements could be different for these two cases. Anyway,
of the three reqs in 5.3 of 2779, I don't think any corresponds to the
second of these cases. Could you dig up the requirement in question?

Well, maybe we need to understand the need to authenticate a presence
service a little better. RFC2778 seems to suggest that a presentity, not the
presence service, is the right place to stage end-to-end security. Note that
sections 5.2 and 5.3 of RFC2779 do not mention presence services; there is
no requirement there that the recipient of a notification be able to
authenticate the presence service, only that the recipient of a notification
is able to 'verify that the notification was sent by B [the target
principal]'. This is at best agnostic about the authentication of presence
services, and I think it admits of a sensible reading in which the watcher
could use the digital signature on the presence information (which was
generated by the presentitiy) as the only required mechanism for
authentication.

Maybe we don't really need to authenticate presence services when a
notification is received.

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



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