Subject: RE: [Simple] Why do we need Presence Caching?

From: "Arnaud Weil" <[email-masked]>
Date: Wed, 8 Aug 2001 15:53:17 +0200

Errr... yes, that's what I just wrote at the end of my previous reply.
Just like you I'd like to know how this is effectively implemented by
SIMPLE. It might even already be secured by SIP.

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: mercredi 8 août 2001 15:53
To: Arnaud Weil; [email-masked]
Subject: RE: [Simple] Why do we need Presence Caching?

Unfortunately, none of this tells you HOW to secure it; it tells you
what security you're supposed to have.

> -----Original Message-----
> From: Arnaud Weil [mailto:[email-masked]] 
> Sent: Wednesday, August 08, 2001 9:46 AM
> To: David R. Oran; [email-masked]
> Subject: RE: [Simple] Why do we need Presence Caching?
> 
> 
> How this should be secured is another part of the CPIM 
> requirements, as stated in the following parts of RFC 2779:
> 
>    2.5.1. The protocol MUST provide means to ensure confidence that a
>    received message (NOTIFICATION or INSTANT MESSAGE) has not been
>    corrupted or tampered with.
> 
>    3.3.3 The protocol caching facilities MUST NOT circumvent 
> established
>    ACCESS RULES or restrict choice of authentication/encryption
>    mechanisms.
> 
>    5.3.1. The protocol MUST provide A means of verifying that the
>    presence information is accurate, as sent by B.
> 
>    5.3.3. The protocol MUST provide A means of verifying that the
>    notification was sent by B.
> 
> However, I'like to point out that these are the requirements 
> that SIMPLE is supposed to meet as a protocol that conforms 
> with CPIM. I'm too new to SIMPLE to tell you how they are 
> effectively met by SIMPLE, and hope someone more experienced 
> could answer this.
> 
> Arnaud
> 
> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: mercredi 8 août 2001 15:24
> To: [email-masked]
> Subject: RE: [Simple] Why do we need Presence Caching?
> 
> 
> How do you secure this without transitive trust among A, B 
> and C? Or are you happy with requiring C to trust B to 
> properly represent A's state and not be a "man in the middle"
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of 
> Arnaud Weil
> > Sent: Wednesday, August 08, 2001 8:20 AM
> > To: Simon; [email-masked]
> > Subject: RE: [Simple] Why do we need Presence Caching?
> > 
> > 
> > Hi Simon,
> > 
> > It seems to me that caching presence information would allow
> > for a more sensible use of the available resources. The idea 
> > is that if B knows about A's presence, it can give it to C 
> > without the need for C to ask it to A. This relieves the 
> > pressure on A. And this will be quite interesting in the case 
> > of servers handling thousands of subscriptions.
> > 
> > Of course, as part of CPIM, a timing mechanism has been set
> > up so that B doesn't give to C any inacurate presence info about A.
> > 
> > Regards,
> > Arnaud Weil
> > 
> > -----Original Message-----
> > From: Simon [mailto:[email-masked]]
> > Sent: mercredi 8 août 2001 09:26
> > To: [email-masked]
> > Subject: [Simple] Why do we need Presence Caching?
> > 
> > 
> > Hi,
> > 
> > In the section 3.3 of RFC 2779, there are some requirements
> > about presence caching and replication. But I cannot 
> > understand when we need to cache the PRESENCE INFORMATION. 
> > Would you like to give me some explantions?
> > 
> > Thanks.
> > 
> > Regards,
> > Simon Young
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinf> o/simple
> > 
> > _______________________________________________
> > 
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinf> o/simple
> > 
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Tony Hansen <[email-masked]>
Date: Wed, 08 Aug 2001 10:07:29 -0400

You have to establish a trust relationship with some systems. THESE
systems you believe to be giving you good data. And you can use their
system certificate via TLS to verify their identity, or use some other
mechanism of server identity verification. 

For example, do you feel you can trust xyz.com to act as a proxy server
for watchers on XYZ's system? If yes, and you can verify that it really
is xyz.com that's sending you a subscription request, then you can
consider that to be a trusted subscription. If the answer to either
question is no, then it's untrusted information.

	Tony Hansen
	[email-masked]