RE: On the need for presence service identifiers

The example, as represented below, has not changed significantly from its
previous incarnation. The comments I would present on this case are more or
less the same as the ones I presented on the previous phrasing of this
pseudo-problem. 

This is a very simple reference integrity question. When someone subscribes
to presence information, they do so by subscribing to a URI. There is some
rule that allows the subscriber to deduce, when they receive notifications,
whether or not the presence information has been signed by someone who is
authorized to provide presence information for the presentity represented by
that URI. The simplest such rule is equality: if I send a subscription to
pres:[email protected], I expect that any notifications I receive will be
signed by [email protected] (that this string will be in a subjectAltName
field of the certificate used to sign the body of the notification). This
works - we are not missing any technical security properties here.

We could also admit of an alternative architecture, as you have encouraged
us to, in which some other entity than [email protected] signs the presence
information. This introduces complications for us, and makes our life
slightly harder, because it would require us to have some other rule for the
watcher to determine if the signature matches the URI to which they
subscribed. This model would ignore the end-to-end security requirements for
notification presented in RFC2779, but we can entertain it nervertheless for
the time being. However, I doubt there is a possible rule in which the
watcher would be assisted by some header that provided information about the
presence service - at best, that header would be redundant with the
subjectAltName of the cert. Therefore, the real question is how the
subjectAltName of the cert would be structured for the presence service. You
argue that it should be a URI, and therefore you need some elaborate way of
explaining the fact that this URI isn't the same URI to which the watcher
subscribed - I countered that a domainname seemed adequate and didn't suffer
from this problem.

The point is that there is no security property that is wanting if there is
no separate identifier for a presence service. No bad guy can forge presence
information generated by the presentity if we assume the 'equality' rule I
describe above (that the signator of notifications must be the same as the
URI to which one subscribed). If we allow that some third-party can generate
presence information on behalf of the presentity (which neither 2778 or 2779
seem to endorse), then we would have to come up with some other rule (like,
the domainname in the subjectAltName of the certificate (mitre.org) must be
identical to the domainname of the URI (pres:[email protected]) to which
the watcher subscribed, say). If you want to call that domainname a
'presence service identifier', then sure, the subjectAltName of a
certificate would contain one of those. But none of this particularly argues
that either URIs for presence services (with or without username
conventions), or From headers in some sort of wrapper around presence
information in notifications, are required. All of these are at best
redundant to existing security properties. As far as I can tell, all you
need is to know who you subscribed to, and to look at who signs the response
- period.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, August 20, 2002 5:16 AM
> To: [email protected]
> Cc: [email protected]
> Subject: On the need for presence service identifiers
> 
> 
> Let me clarify the example I provided that demonstrates a situation in
> which it is important that each presence service has an identifier
> that distinguishes it as a presences service.  In this 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.  The bad guy is creating
> presence information and signing it, so timestamping will not foil
> this attack.  

Timestamping prevents replay protection and out-of-order delivery and so on,
yes, not impersonation.

> Imagine that the subject that pres:[email protected]
> identifies is a good and honorable MITRE employee who has had their
> laptop stolen.
> 
> Here is the scenario.  Suppose you know my presentity is available at
> pres:[email protected].  You subscribe to it by doing a DNS lookup of
> mitre.org and say the APEX protocol to get a port and an Internet
> Protocol address of the presence service providing my presentity.
> Because the request was routed through a subverted host, you receive
> two signed notifications back immediately, one that looks like:
> 
>          Content-type: Message/CPIM
>  
>          To: pres:user@host
>          From: pres:[email protected]
>          Datetime: 2002-07-18T13:38:22-8:00
>  
>          Content-type: application/cpim-pdif+xml	
>  
>          <presence entity='pres:[email protected]>
>            <tuple id='im'>
>              <status><basic>open</basic></status>
>              <contact>im:[email protected]</contact>
>            </tuple>
>          </presence>
> 
> and the other one looks like:
> 
>          Content-type: Message/CPIM
>  
>          To: pres:user@host
>          From: pres:[email protected]
>          Datetime: 2002-07-18T13:37:29-8:00
>  
>          Content-type: application/cpim-pdif+xml	
>  
>          <presence entity='pres:[email protected]>
>            <tuple id='im'>
>              <status><basic>open</basic></status>
>              <contact>im:ramsdell@badhost</contact>
>            </tuple>
>          </presence>
> 
> Both notifications are signed and include a certificate with the
> presence URI in the 'From' header in its Subject Alternative Names.
> Which instant inbox are you going to use?
> 
> One way to correctly answer this question is to use the convention
> that a PRES URI's identifies a presence service if and only if it's
> local part is the string "notifier".  Of course, there are other
> conventions that can be used to distinguish presence service
> identifiers.
> 
> John
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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