Subject: Re: [pcp] Unsolicited Messages to Client with no security association

From: Alper Yegin <[email-masked]>
Date: Mon, 3 Dec 2012 10:59:34 +0200

On Nov 30, 2012, at 1:58 PM, Sam Hartman wrote:

>>>>>> "Alper" == Alper Yegin <[email-masked]> writes:
> 
>    Alper> Sam, Even if what you were saying made sense (which I
>    Alper> strongly disagree for the very reasons Yoshi has been
>    Alper> explaining), it does not matter. Let me explain:
> 
>    Alper> You are claiming there is a deployment case where unsolicited
>    Alper> messages from the server does not need to be
>    Alper> integrity-protected.  Nevertheless, there would also be
>    Alper> deployment cases where server wants to integrity-protect all
>    Alper> of the messages.
> 
> Alper, saying a thing again and again does not make it true.
> I claim there is no security reason for a server  to want to integrity
> protect all its messages.
> That is precisely the disagreement, and asserting your position again
> and again  doesn't move the discussion forward.
> I've provided you with a framework of threats and security requirements
> in which to argue about whether  there is a reason for a server to
> require  that responses be integrity protected.
> Please construct an argument rather than repeat yourself. If you don't
> like my framework, please propose your own.

Are you not reading? I already stated that. Simple solution is to let the server initiate re-auth when it has a message to send to the client but it does not have a live SA with the client.
(I still don't understand why this is not OK to the extent that you keep coming up with really "creative" ideas such as below).

> Alternatively, step aside and let us move on and get some work done.
> 

I'm afraid we have a different definition of work. I don't count reinventing the wheel as work.

> We both agree that clients need to be able to validate the integrity of
> responses.  That means the response either needs to be sent with
> integrity, or the client needs to be able to solicit the same
> information with integrity protection.
> 

Let's say we do that.

Next time the client receives a message from the server, if the message is not integrity protected, that tells the client "the server has something to tell you".
Well, the client shall in no way try to parse the content of the message because it's not integrity protected. All it says is "the server has something to tell you".
In your approach, in response to such a message, the client shall initiate re-auth.
Once re-auth is done, now the client sends a solicitation: "please send me that last message again".

Now, this is funky. Never seen such a design before. Have you, or has anyone?

And…. It simply has "server initiated re-auth" hidden in it. Look, the very first message sent by the server in fact is the message that initiates the re-authentication. 
Instead of sending the PCP message, the server could send a trigger to initiate re-auth. 
Much simpler.

You just re-invented server initiated re-auth in a really non-straight forward way, with more intrusion into the PCP design.

Alper

> --Sam

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Dec 2012 11:21:04 +0100

>> information with integrity protection.

"That" meaning "let the client solicit the same information with 
integrity protection", I assume.

> Now, this is funky. Never seen such a design before. Have you, or has anyone?

Another problem with this design is that it will surely be 
mis-implemented by clients that will not do re-auth and will instead 
trust the contents of the initial message as if it was protected. It's a 
trap for implementers.

> You just re-invented server initiated re-auth in a really non-straight forward way, with more intrusion into the PCP design.

I still share Alper's understanding fully.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Dec 2012 09:37:00 -0500

Simon and I spoke about the server-initiated messages last Friday. It
was an interesting conversation and we'd like to report on our different
approaches to the WG in the hopes of informing the discussion and moving
things forward.
Simon was approaching PCP authentication from the ISP standpoint, where
the primary goal is to protect the client. I was approaching things
assuming the primary user of authentication will be enterprise
authentication and protecting the authorization of the server will be
one of the important goals of PCP authentication.

The big attack that we're concerned about when we consider unsolicited
updates is a change in mappings. For example consider a case where a
client is using a mapping for media announcements in SDP. The server
sends an unsolicited update because the mapping has changed and so the
client starts using the new address in new SDP announcements. If an
attacker convinces the client to use an external address of the
attacker's choice, then the attacker can potentially intercept media.
Simon said that he's most concerned about this type of attack when
considering unsolicited messages.

Neither of us could come up with very significant attacks on announce
messages. Potentially you could cause a client to spend a lot of time
updating mappings with a fake announce message.

However, there's a significant gap in our defense against this
attack. We support clients that that only authenticate when the server
requires it.
Such a client sends an unauthenticated request and performs
authentication when it receives an authentication required error.
Rather than attacking an unsolicited update, an attacker could simply
reply to the initial request with an unauthenticated answer. There are
some circumstances where the attacker might not be able to do that but
would be able to attack an unsolicited update. 
However, in most circumstances, the same sorts of attacks that could be
mounted against unsolicited updates can be mounted against initial
responses.

The full defense against this sort of attack is for the client to
require authentication all the time. I think this is going to require
explicit configuration of the client. Simon and I both agree that
clients that require authentication all the time MUST verify the
integrity of the contents of unsolicited responses. If there are
circumstances where these responses do not include integrity related to
a current security association, then those messages MUST NOT be trusted
without soliciting an integrity protected version. Obviously if we end
up with a solution where we have server initiated re-auth that servers
are required to use, then the responses will always be protected by a
current security association.

Simon is concerned about a solution where integrity protection is
sometimes absent from unsolicited responses. He's concerned that people
will make an implementation error and accept unprotected responses when
they should not. he said that having some security information in the
message , including a protected indication that a SA had been deleted,
reduced this concern somewhat. I pointed out that under my proposal, an
attacker could not generate a valid unprotected message until the
attacker had seen an unprotected message. If the client did
re-authenticate at that point, then the attacker would no longer be able
to produce an valid unprotected message.

In my mind the biggest advantage of my proposal is that servers do not
need to queue messages while authentication takes place.
Clients may need to queue information on what mappings to solicit
updates for.

I think the biggest question to the WG is whether partially defending
against the mapping change attack is worth requiring servers to queue
outgoing unsolicited messages.

Simon has reviewed this summary and agrees that it describes our
meeting.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 12 Dec 2012 05:23:00 +0000

Hello Sam/Simon,

Some comments inline..

>mounted against unsolicited updates can be mounted against initial

With one detail. The window of opportunity to attack unsolicited responses
is much larger than initial response.

>attacker had seen an unprotected message.

Could you explain this part? I looked at the draft and was under the
impression that as long as the attacker could look at PCP messages going
by it could at any point send an unprotected unsolicited response. Even
before seeing an unprotected message from server.

>If the client did
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp