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

From: Alper Yegin <[email-masked]>
Date: Fri, 4 Jan 2013 12:06:47 +0200

Sam,

So, the main concern you have is, if the server has an outstanding message to send to the client and if there is no live SA, then the server has to queue the message until the SA is generated. The queueing of that message is your concern. 

How is that such a big concern to the extent that we should define an inadequately secured protocol at IETF? I don't get that.
The protocol allowing some of the server-side messages fly w/o integrity protection is a "glaring (security) hole".

I'd say we are spending way too much time on some approach that's just plain broken. (Just add server-initiated re-auth to your solution and be done with this issue. Simple and straightforward. Not sure why you're resisting that.).

Is there anyone other than Sam who believes this path is worth spending more time? 

If not, can we start directing our energy to other aspects?

Alper

On Dec 11, 2012, at 4:37 PM, Sam Hartman wrote:

> 
> 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.
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: [email-masked] (Eric W. Biederman)
Date: Fri, 04 Jan 2013 23:22:00 -0800

Alper Yegin <[email-masked]> writes:

> Sam,
>
> So, the main concern you have is, if the server has an outstanding
> message to send to the client and if there is no live SA, then the
> server has to queue the message until the SA is generated. The
> queueing of that message is your concern.

>
> How is that such a big concern to the extent that we should define an
> inadequately secured protocol at IETF? I don't get that.  The protocol
> allowing some of the server-side messages fly w/o integrity protection
> is a "glaring (security) hole".

Definitely.  It allows MITM attacks and predicting and controlling when
the client sends packets.

> I'd say we are spending way too much time on some approach that's just
> plain broken. (Just add server-initiated re-auth to your solution and
> be done with this issue. Simple and straightforward. Not sure why
> you're resisting that.).

I agree all of your binding lifetimes should be strictly less than
your SA lifetimes which makes server-initiated-reauthentication
unneeded, and guarantees you have no unathenticated messages.

> Is there anyone other than Sam who believes this path is worth

Generally unused code paths are invariably coded incorrectly.  Both
server-initiated-reathentication and sometimes encrypted sometimes not
encrypted messages are both cases that will essentially never happen
in practice, and add considerable complexity to the implementation.

I suspect a lot of clients won't even bother to implement either code
path (think iterative rapid development) let alone test them.

I certainly believe it is worth spending enough time to remove the over
design that is allowing bindings to have lifetimes larger than your
security association.

PCP is simple please keep it that way.

> If not, can we start directing our energy to other aspects?

I think this complaint just proves my point.  It is hard to care enough
about this detail to spend the time to get it right.  If you can't do
that in protocol design I really can't imagine many developers caring.

So as someone who occassionally implements this kind of code, any
solution other than having the lifteime of your bindings _always_
_always_ _always_ be less than the lifetime of your SA is desiging in a
mistake waiting to happen.  Don't do it.

If the SA lifetime is less than the minimal binding lifetime the request
should be denied.

As long as there is a somewhat reasonable SA lifetime there won't be any
meaningful operational limitation and it seriously simplifies everyone's
implementations.

Eric

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 11:03:03 +0100

Le 2013-01-04 11:06, Alper Yegin a écrit :
> allowing some of the server-side messages fly w/o integrity
> protection is a "glaring (security) hole".

IMHO it would be nice if we didn't need to add such a queue on the
server. I've said that before.

Now, Sam has explained how he sees no security hole in sending
server-initiated messages in the clear. I also am uneasy about this, but
I cannot come up with an attack.

Calling this a "glaring hole" is fine, but explaining the attack you see
would help further the discussion.

Unless there's an attack, it actually makes implementation easier and
the server more scalable.

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: Alper Yegin <[email-masked]>
Date: Tue, 8 Jan 2013 13:00:18 +0200

Hi Simon,

Sam's remedy (i.e., unsolicited message from server triggering the client to re-auth and request the same message this time securely) is simply reinventing the server-side re-auth in a hacky way. I did explain this well before.  http://www.ietf.org/mail-archive/web/pcp/current/msg02666.html

Besides, how does that really circumvent the server's need to queue the request? Server needs to hold on to the copy of the unsolicited message even after it sent the message insecurely, so that when the client performs re-auth and requests the message again the server has the same message securely delivered to the client.

Alper

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Jan 2013 13:26:27 +0100

Le 2013-01-08 12:00, Alper Yegin a écrit :
> Besides, how does that really circumvent the server's need to queue
> the request? Server needs to hold on to the copy of the unsolicited
> message even after it sent the message insecurely, so that when the
> client performs re-auth and requests the message again the server has
> the same message securely delivered to the client.

The client doesn't ask for a *retransmission*. It would ask for a brand 
new message, which would usually have the same content as the previous one.

How I see it:

1. Server: "(unauthenticated) Mapping XYZ is now at a.b.c.d:1234."
2. Client: "Tell me about mapping XYZ using these auth bits: ..."
3. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234."

You see, in message 2 the client only asks for mapping XYZ's status. The 
only link between message 1 and message 2 is the implicit fact that 
message 1 triggered message 2 in the client's state machine, as well as 
the "XYZ" piece of data which uniquely identifies a mapping (which is 
effectively the mapping's internal address, port, and nonce).

The server forgets all about message 1 right after sending it. It can 
generate message 3 from message 2 and from its NAT state table. There is 
no guarantee that message 3 would have the same content as message 1 
because the NAT state table may have changed in the meantime. But it 
doesn't matter. What matters to the client is the latest state of the 
mapping.

Sam, feel free to correct any misunderstanding of mine.

Simon

---

From: Alper Yegin <[email-masked]>
Date: Thu, 10 Jan 2013 20:38:59 +0200

More complete sequence in Sam's case is this:

1a. Server: "(unauthenticated) Mapping XYZ is now at a.b.c.d:1234."
2a. Client: Initiate re-auth (upon detecting that server is trying to send a message and there is no SA)
3a. Mutual re-auth takes place
4a. Client: "Tell me about mapping XYZ using these auth bits: ..."
5a. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234."

The  call-flow we are proposing is:

1b. Server: Initiate re-auth (upon detecting that there is a pending message and there is no SA)
2b. Mutual re-auth takes place
3b. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234."

First one is unnecessarily cumbersome. (Look, first one is simply a hacked up version of server-initiated re-auth. Message #1a is implicitly used to improvise the effect of Message #1b).

It does save the server from buffering. But it moves the buffering to the client. Client has to remember the unauthenticated message to ask for it again. So, it's just moving the problem around.

What if the server sent the mapping for ABC and not XYZ, and a intermediate entity overwritten it with XYZ?  Client cannot assume the server has something to say about XYZ. In fact, the client shall not use any of the information in Message 1a. 

Alper

On Jan 8, 2013, at 2:26 PM, Simon Perreault wrote:

> The client doesn't ask for a *retransmission*. It would ask for a brand new message, which would usually have the same content as the previous one.
> 
> How I see it:
> 
> You see, in message 2 the client only asks for mapping XYZ's status. The only link between message 1 and message 2 is the implicit fact that message 1 triggered message 2 in the client's state machine, as well as the "XYZ" piece of data which uniquely identifies a mapping (which is effectively the mapping's internal address, port, and nonce).
> 
> The server forgets all about message 1 right after sending it. It can generate message 3 from message 2 and from its NAT state table. There is no guarantee that message 3 would have the same content as message 1 because the NAT state table may have changed in the meantime. But it doesn't matter. What matters to the client is the latest state of the mapping.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Jan 2013 09:12:22 -0500

At this point I favor servers requesting re-auth if they have an
unsolicited message to send and there was a previous SA in place.

I think moving the buffering problem to the client is a significant
advantage, however:

1) It adds a constraint to the problem that all unsolicited messages
need to be things that can be reconstructed given client
prompting. Certainly true today, probably true in the future, but a real issue.

2) People are nervous about it. I'm fairly sure there is not a
significant security issue, but it seems like it's easier to build
consensus and go on with a simpler proposal.

If the server buffering were a huge deal people would be screaming about
it more. So, I think simplicity and a proposal people find easier to
analyze is valuable.

I'll note that describing things as "hacks," or "simply moving problems
around," doesn't really add to the discussion.  It's quite obvious that
participants have different design esthetics here and that some of us
will disagree on what is a clean solution vs what is an ugly
solution. Moving things around is very commonly desirable in security
protocols especially where state is concerned.

--Sam