RE: On the need for presence service identifiers

A few more notes below. Sorry for the length...

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, August 21, 2002 6:29 AM
> To: Peterson, Jon
> Cc: [email protected]; [email protected]
> Subject: Re: On the need for presence service identifiers
> 
> 
> "Peterson, Jon" <[email protected]> writes:
> 
[snip]
> 
> Maybe this will calm your fears.  Let's look at the big picture.  The
> goal is to produce a protocol that meets the requirements outlined in
> RFC 2779.  The requirement in focus is 5.2.4 of RFC 2779.
> 
>    The protocol MUST provide means of protecting B from another
>    PRINCIPAL C "spoofing" notification messages about B.
> 
> I have proposed an anti-spoofing mechanism that uses X.509 V3
> Certificates, presence service identifiers, and notification content
> that is timestamped and signed when a notification operation is
> invoked.  If the protocol supports this mechanism, I believe we will
> have a protocol that satisfies 5.2.4.
> 

There are a number of other requirements the CPIM protocol must satisfy,
including:

   5.2.1. The protocol MUST provide means of ensuring that only the
   PRINCIPAL A being sent the NOTIFICATION by B can read the
   NOTIFICATION.

I don't think this bodes well for any architecture in which we stage
security (particularly confidentiality) at some intermediary that isn't
under the control of the principal B. I think 5.2.1 says that the device
that generates presence information MUST be able to apply its own security
properties to presence information. Presumably, any further security added
by a presence service would therefore have to be an additional layer around
any security added by the presentity (unless the presence service and
presentity roles were performed by the same device).

> The requirement does not force implementors to protect a watcher from
> being spoofed.  Implementors are free to provide no support for
> digital signatures.  Furthermore, implementors are free to provide
> some means of protecting a watcher against being spoofed even if the
> mechanism contains known vulnerabilities.
> 

Um... this is a smaller point, but I think the requirements in RFC2779 do
entail that CPIM-compliant applications MUST implement an end-to-end
security mechanism. However, this does not compel anyone to use said
security, just that devices which are compliant with CPIM have to support a
common mechanism. 

> For example, an implementation of the protocol could provide presence
> services that distribute presence information that is signed by the
> person that created the information, not by the services themselves.
> Since this mechanism is vulnerable to the attack I will describe next,
> this mechanism cannot be the only one allowed by the protocol, for it
> would then not satisfy 5.2.4.
> 

I'm going to try saying this again; let's see if it works this time:

If a party C sends A some information about B that is true, I'm not sure why
this would be considered spoofing. In this attack, C is sending A
information about B that says "at this time, B's presence was X", and this
information is accurate. This is only a problem if A assumes it means
something other than it does; that is, if A assumes that this is B's current
presence. Having the presence service add a timestamp to the message when it
sends a notification is not the only way, at a protocol level, to make sure
that A understands that this is not B's current presence.

> Assume Alice <pres:[email protected]> and Bob <pres:[email protected]>
> communicate with each other via instant messaging.  On Sunday, both of
> them publish presence information giving their inbox and stating their
> inbox is closed.  Each individual signs and dates the information.
> 
> Eve subscribes to both Alice's and Bob's presentity and saves Sunday's
> version of their presence information.  On Monday, either by playing
> with DNS or by intercepting traffic between alice.com and bob.com, Eve
> sends Bob's old presence information to Alice, and Alice's old
> information to Bob.  Because of this, all day Monday, Alice and Bob
> think each other is offline, and fail to communicate.  Alice and Bob
> have no way of knowing that the presence information they have is
> stale.  This attack is foiled if notification content is timestamped
> and signed when a notification operation is invoked.
> 

This is good, because this reveals another difference in our assumptions -
the attack you describe above is an active attack, whereas up until now I've
been working under the assumption that we are only trying to prevent passive
attacks.

<security background>
In passive attacks, the attacker can read traffic on the wire, and inject
arbitrary traffic onto the wire. In active attacks, attackers can also
remove any traffic on the wire. There is a big difference between these two
sorts of attacks. All protocols usually want to develop protection against
passive attacks, but some do not choose to build mechanisms to defend
against active attacks, for basically two reasons:

- Because it is much harder to stage an attack active than a passive attack.
Active attacks basically entail compromising some machine that is in the
path of all traffic coming two and from the target, like a router, and then
running code that inspects packets and decides to remove some of them in
real time. This requires a significant amount of sophistication and
investment in acquiring compromised machines. Passive attacks, by way of
contrast, just require that the attacker can read packets, which entails no
real-time decision making.
- Because an active attacker can remove arbitrary packets from the network,
they can trivially deny any service to the victim, and thus defending your
IM&P traffic is the least of your problems. Seriously, an active attacker
can walk all over you in any number of ways - if someone is able to stage an
active attack on you, no security properties that are built into any
higher-layer protocol are going to improve your condition. An active
attacker could, for example, just discard all instant messages or other
communications that Alice or Bob might send to one another on the basis of
their beliefs about presence information, which sort of defeats the purpose
of sharing presence in the first place. There tends to be very little return
on an investment in security that defends against an active attack. 
</security background>

Above you correctly note that in order to stage this attack, Eve must be
capable of intercepting traffic between alice.com and bob.com. Otherwise,
when Alice comes online, their Monday presence notification (with a more
recent signature than the Sunday data) would be transmitted to Bob.
Presumably, if Alice saw a chunk of presence information that was signed and
timestamped by the presentity recently, and one that was so signed and
timestamped yesterday (generated by a passive attacker), Alice could make an
easy decision to use the more recent information. So I would contend that
your example is essentially an active attack.

I also contend that 5.2.4 does not require us to defend against active
attacks. C can send a 'spoofed' message as a passive attacker, and from the
way 5.2.4 reads, I believe it is describing the threat of passive attack,
not active attack. It does say anything about C intercepting messages sent
by B; and note 5.2.2 as well.

I also must reiterate that I don't believe RFC2779 requires us to protect
against replay attacks (see Security Expectation A7) - though I agree it
would be nice.

But all that said, to consider your attack: I'm confused - if this type of
attack is launched, you say that Alice and Bob have no way of knowing that
the information they've received is stale? I mean, if the presence
information were internally timestamped, then they would know that the most
recent presence report they had received was timestamped a long time ago,
correct? I think they do have a way of knowing that it's not current -
because the information says that it describes the state of a principal
yesterday. Just because it is old doesn't mean that it's wrong, that's true
- but just because it's the most recent presence report they've received,
that doesn't mean it's valid at this minute. What if Alice or Bob crashes
ungracefully, or a fiber cut occurs, and one of them cannot publish new
presence information saying that they have gone off-line (assuming they had
published something saying they were on-line to start with)? Surely the last
received presence information (saying that they are on-line) becomes stale
at some point, right?

Because otherwise, an active attacker like Eve wouldn't even have to resend
the old presence information, presumably - Alice and Bob would go on
indefinitely believing that the last presence information they received from
one another is still good. So why, in your attack, does Eve have to send new
notifications to Alice and Bob containing the old presence information?
Because you're assuming that Alice and Bob only consider the information to
be stale when the timestamp on the notification is stale, that is, when they
haven't received a notification recently. I could just easily contend that
they should consider the information to be stale when the timestamp within
the latest presence information they received is similarly stale.

[As an aside, note that in your example, if Eve wants to convince Alice and
Bob that one another are off-line, if Eve is an active attacker, why bother
replaying presence information at all? Why not just send nothing and
intercept all notifications? Wouldn't that always be interpreted as
'offline' by Alice and Bob? Spoofing isn't really helping Eve to deny
service here - but as an active attacker, again, Eve doesn't really need to
spoof. More reason to think that 5.2.4 probably doesn't cover defense
against an active attack.]

Now, let's talk about what it would be like if the notification were
timestamped, but the presence information generated by the presentity were
not timestamped. Consider another scenario involving an active attacker.
What if the active attacker filters the link between the presentity and its
presence service? In other words, when Alice tries to publish her presence
information to her presence service from her presentity, the attacker does
not allow Alice's publication to reach the presence service. What will the
presence service report then? It does not have the latest presence
information that Alice has generated, but it will happily sign and timestamp
its notifications containing this outdated presence information as if this
was the latest presence information about Alice. If we follow your model,
then Bob would believe this information to be current, because the timestamp
on the notification is current. In this case it would be very valuable to
have a timestamp inside the presence information at well, so Bob could know
that Alice generated this information some time ago.

There may be some value in timestamping notifications if we want to protect
against active attacks - but I think even if this timestamp were included, I
think we would still need to have the timestamp within the presence
information that shows when the presentity generated it.

> > If you mean here that end users (i.e. presentities) wouldn't be
permitted to
> > sign their own presence information, then your model directly violates
> > RFC2778/RFC2779. This simply isn't acceptable.
> 
> I mean that sites using X.509 certificates can set up a policy that
> restricts which certificates can be used to sign presence
> notifications.  You don't get that kind of control otherwise.
> 

I still don't think I understand what you mean here - but designing
protocols which somehow deprive end-users of the capability to secure
private information about themselves is unwise, and I believe against the
spirit of the 2778/2779 model.

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



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