RE: Sub/Not Security, Presence service identifiers

I don't disagree with your example, but I think it relies on particular
properties of the 'closed' presence state. If you're offline, you can't
update your presence, and therefore your last reported presence state will
always be stale (if we consider freshness to correspond to the timestamp
internal to presence information, as I contend we should), I agree. However,
if I have no fresh presence state from you, I'm going to assume you're
off-line anyway. So the message that you're off-line may be stale, but I
will draw the right conclusion - that you're off-line.

The same wouldn't be true for a similar example in which the information
that you are on-line becomes stale. If you're on-line, then you are capable
of publishing new presence information regularly (with fresh timestamps). If
your presence state of 'open' becomes stale, however, I will be led to the
conclusion that you are off-line (if you weren't, I'd have more recent
information from you), and my client should change its picture of your
state. After all, it has to be possible for your client to crash
ungracefully and be unable to send a notification of closure - eventually, I
have to time out and assume you're off-line; there has to be some sort of
concept of a keep-alive. Nothing's broken here. Having timestamps in
notifications doesn't improve on this in any way I can immediately see.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, August 21, 2002 7:07 AM
> To: [email protected]; [email protected]
> Cc: [email protected]; [email protected]
> Subject: RE: Sub/Not Security, Presence service identifiers
> 
> 
> 
> 
> > -----Original Message-----
> > From: ext Peterson, Jon [mailto:[email protected]]
> > Sent: Wednesday, August 21, 2002 1:07 PM
> > To: '[email protected]'
> > Cc: '[email protected]'; [email protected]
> > Subject: RE: Sub/Not Security, Presence service identifiers
> > 
> > 
> > I addressed this issue in a previous note today - I think 
> > that the timestamp
> > that is important for replay protection is a timestamp of 
> > when the presence
> > information is generated, not when a notification is sent. 
> > I'm not aware of
> > any interesting additional security properties that we could 
> > derive from
> > knowing when the notification is sent.
> 
> Presence information could have been generated a week ago 
> because I went on holiday and haven't updated my presence 
> info from saying "On holiday". You subscribe to my presence 
> info today. You get a week old presence info. Does that mean 
> my presence info cannot be authentic?
> 
> Timestamp of when the notification is sent makes more sense to me.
> 
> Regards,
> Hisham
> 
> 
> > 
> > On a meta-issue, let me also suggest that you commit only 
> > your considered
> > reflections to the mailing list, rather than following up 
> > your own notes
> > after further thinking on the subject. It really creates 
> > quite a bit of
> > unnecessary spam when you think out loud.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: Tuesday, August 20, 2002 11:57 AM
> > > To: Peterson, Jon
> > > Cc: '[email protected]'; [email protected]
> > > Subject: Re: Sub/Not Security, Presence service identifiers
> > > 
> > > 
> > > "Peterson, Jon" <[email protected]> writes:
> > > 
> > > > Was there some reason that a wrapper seemed more 
> > > attractive? Especially
> > > > considering that a <timestamp> element is defined in PIDF? 
> > > 
> > > This is a follow up to my last note on timestamps.
> > > 
> > > If you look at the 05 draft of the PIDF document, it is clear the
> > > <timestamp> element is an inapproprate replacement for 
> the timestamp
> > > in the wrapper I proposed.  The wrapper's timestamp 
> records the time
> > > at which a notification request was initiated.  A watcher 
> uses this
> > > information to make sure the information in the request was 
> > extracted
> > > from the presence service's database in a timely fashion.  
> > You use it
> > > the same way you use the timestamp in an instant message.
> > > 
> > > The <timestamp> element in PIDF appears to serve a 
> > different purpose.
> > > Here as a quote:
> > > 
> > >    (b) The presence format should be able to contain the 
> > timestamp of
> > >        the creation of the PRESENCE INFORMATION.  The 
> > timestamp in the
> > >        presence document lets the receiver know the time of 
> > the creation
> > >        of the data even if the message containing it 
> > arrives late for
> > >        some reason.  It can also be used to detect a 
> replay attack,
> > >        independent of the underlying signature mechanism.
> > > 
> > > In other words, it records the last time the presence information
> > > changed.  In summary, the <timestamp> element cannot replace the
> > > timestamp in the wrapper I proposed, but you could add another
> > > element, such as <servedate> to replace the instant messaging like
> > > syntax in the wrapper.
> > > 
> > > John
> > > 
> > 
> > 
> > 
> >   [reminder: [email protected] for non-technical 
> > discussions, please]
> > 
> > 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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