Subject: [pcp] Problem with nonce checking

From: Stuart Cheshire <[email-masked]>
Date: Tue, 04 Jun 2013 16:39:58 -0700

It looks like we're starting to accumulate a growing list of issues to document in an addendum to RFC 6887.

   If operating in the Simple Threat Model (Section 18.1), and the
   internal port, protocol, and internal address match an existing
   explicit dynamic mapping, but the mapping nonce does not match, the
   request MUST be rejected with a NOT_AUTHORIZED error with the
   lifetime of the error indicating duration of that existing mapping.
   The PCP server only needs to remember one Mapping Nonce value for
   each explicit dynamic mapping.

Here's the problem:

1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins.
2. Client reboots, or similar, and picks new nonce.
3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins.
4. NOT_AUTHORIZED!

And now the client is locked out of listening on its own TCP port 22 for the next 24 hours. Ironically, it *does* still have an external address and port mapped to its internal TCP port 22 -- but the NAT gateway won't tell it *what* external address and port, making it not very useful.

I think we need to remove the server nonce check.

If the client asks for a mapping to 10.0.0.2:22, and there is in fact *already* a mapping to 10.0.0.2:22, the the server should say so, and not pretend otherwise.

And if the server were to delete the old mapping in this situation, it creates an easy DoS attack were someone can delete your mapping just by trying to renew it with the wrong nonce.

Stuart Cheshire

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 5 Jun 2013 00:06:35 +0000

Hi Stuart,

I think this scenario is not new, but now more people are getting more
operational experience and bring more voices to the discussions.

This specific scenario was discussed on this list a few times.

Med and I documented on
http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#page-4 under
"PCP Client crash".

"If the PCP Client does not store the explicit dynamic mappings and
   new Mapping Nonces are assigned, the PCP Server will reject to
   refresh these mappings.

      Proposed Action: This issue can be solved if the PCP Client uses
      GET OpCode (Appendix B) to recover the mapping nonces used when
      instantiating the mappings if PCP authentication is used or
      Mapping Nonce validation check is disabled.

"

Thanks,

Reinaldo

On 6/4/13 8:39 PM, "Stuart Cheshire" <[email-masked]> wrote:

>And now the client is locked out of listening on its own TCP port 22 for
>the next 24 hours. Ironically, it *does* still have an external address
>and port mapped to its internal TCP port 22 -- but the NAT gateway won't
>tell it *what* external address and port, making it not very useful.
>
>If the client asks for a mapping to 10.0.0.2:22, and there is in fact
>*already* a mapping to 10.0.0.2:22, the the server should say so, and not
>pretend otherwise.
>
>And if the server were to delete the old mapping in this situation, it
>creates an easy DoS attack were someone can delete your mapping just by
>trying to renew it with the wrong nonce.
>
>Stuart Cheshire
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Jun 2013 21:11:12 -0400

>>>>> "Stuart" == Stuart Cheshire <[email-masked]> writes:

we added the nonce to avoid introducing security attacks against PCP.
We explicitly realized that we were making certain usability issues more
difficult; I believe we had explicit discussion of approximately this
issue when we discussed removing the ability to flush mappings under the
simple threat model.

I have two recommendations:

1) make it easier for the client to retrieve the existing mapping (but
not learn the nonce).
We'd need to do security analysis of that but I think it's OK.

2) Implement authentication.  Once you have an MTI security mechanism
and are giving your users an option, it seems reasonable to relax the
configuration when your users do not choose to turn onauthentication.
This particular relaxation seems like one of the more common cases that
should come up when advanced threat model is used with auth disabled.

however I do not support changing our minds about what the simple threat
model means.  If the simple threat model really is unworkable, I'd
support replacing PCP with a new version including a MTI security
mechanism.

--Sam

---

From: Dan Wing <[email-masked]>
Date: Tue, 4 Jun 2013 19:26:59 -0700

> 2. Client reboots, or similar, and picks new nonce.

Can the client remember its nonce across reboots, or similar?

-d

---

From: Dan Wing <[email-masked]>
Date: Tue, 4 Jun 2013 19:27:03 -0700

>      Mapping Nonce validation check is disabled.

That destroys the security protection of Nonce.

visitor: Let me into the castle.
guard: To enter the castle, tell me the password.
visitor: Ok.  What is the password?
guard: 385932
visitor: Let me in to the castle.
guard: To enter the castle, tell me the password.
visitor: 385932
guard: <opens door to the castle>

Didn't Monte Python do that skit?

-d

---

From: Dan Wing <[email-masked]>
Date: Tue, 4 Jun 2013 19:29:46 -0700

> We'd need to do security analysis of that but I think it's OK.

I like that approach to retrieve the existing mapping.  Seems that solves Stuart's case without adding new burden for storing state on the client.

-d

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 5 Jun 2013 05:19:47 +0000

Yes, sounds like Monty Python.

And no, does not destroy protection of nonce because it assumes
authentication is enabled. "..if PCP authentication is enabled..". Or
alternatively if nonce is disabled which means there was no nonce check to
begin with.

On 6/4/13 11:27 PM, "Dan Wing" <[email-masked]> wrote:

>>> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive
>>>ssh
>>> logins.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Jun 2013 10:39:22 +0200

> I like that approach to retrieve the existing mapping.  Seems that solves Stuart's case without adding new burden for storing state on the client.

What if, when the server receives a MAP request matching an 
already-mapped internal port but with the wrong nonce, instead of 
returning NOT_AUTHORIZED, it would send a success response containing 
the external address+port, remaining lifetime, and a dummy nonce? I 
can't see anything that would break.

Seems like we don't need a different opcode at all to make this use case 
work. And one round-trip saved.

(But seriously the client should just remember nonces across reboots.)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Jun 2013 10:41:30 +0200

Le 2013-06-05 10:39, Simon Perreault a écrit :
>> I like that approach to retrieve the existing mapping.  Seems that
>> solves Stuart's case without adding new burden for storing state on
>> the client.
>

Further insight: from the point of view of the client, the existing 
mapping with a nonce it doesn't know about is just like a static 
mapping. The client can't modify it, but it can use MAP to discover its 
existence.

Simon

---

From: <[email-masked]>
Date: Wed, 5 Jun 2013 10:59:11 +0200

Hi Stuart,

This is indeed a failure scenario we should be aware of. 

We have documented various failure scenarios which are exacerbated by nonce validation checks. You may refer to http://tools.ietf.org/html/draft-boucadair-pcp-failure-06 (search for nonce).

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Stuart Cheshire
>Envoyé : mercredi 5 juin 2013 01:40
>À : [email-masked]
>Objet : [pcp] Problem with nonce checking
>
>the next 24 hours. Ironically, it *does* still have an external address and
>port mapped to its internal TCP port 22 -- but the NAT gateway won't tell
>it *what* external address and port, making it not very useful.
>

---

From: <[email-masked]>
Date: Wed, 5 Jun 2013 13:58:57 +0200

Hi Dan,

It doesn't. Please re-read the text.

This point is explicitly discussed in Section 2.2 of the failure draft:

   If the same port number is used but a distinct Mapping Nonce is
   generated, the request will be rejected with a NOT_AUTHORIZED error
   with the Lifetime of the error indicating duration of that existing
   mapping (see Section 2.7 of [I-D.boucadair-pcp-flow-examples]).

      Proposed Action: A solution to recover the Mapping Nonce used when
      instantiating the mapping may be envisaged; this solution may not
      be viable if PCP authentication is not in use.  Mapping Nonce
      recovery in the simple PCP threat model (especially when Mapping
      Check validation is enabled) induces the same security threated as
      those discussed in [RFC6887].

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Dan
>Wing
>Envoyé : mercredi 5 juin 2013 04:27
>À : Reinaldo Penno
>Cc : Stuart Cheshire; [email-masked]
>Objet : Re: [pcp] Problem with nonce checking
>
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Jun 2013 09:28:31 -0400

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

Rather than a dummy nonce, I think the server should use the client's
nonce from the new map request.
And yes, it's like a static mapping from the POV of the client as you
suggest.

--Sam

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Jun 2013 15:50:41 +0200

> nonce from the new map request.

Makes total sense.

Simon

---

From: Dan Wing <[email-masked]>
Date: Wed, 5 Jun 2013 07:12:53 -0700

On Jun 5, 2013, at 4:58 AM, <[email-masked]> wrote:

>      be viable if PCP authentication is not in use.  

Sorry I misread the double negative.

-d

> Mapping Nonce

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 5 Jun 2013 15:41:46 +0000

Good suggestion. Whether the PCP application crashed or the host got a new
IP, a client should be able to find out existing mappings to certain ports
it would like to use.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 06 Jun 2013 16:53:47 -0700

> Can the client remember its nonce across reboots, or similar?

RFC 6887 says:

   The client MUST use a different mapping
   nonce for each PCP server it communicates with, and it is RECOMMENDED
   to choose a new random mapping nonce whenever the PCP client is
   initialized.

How does the PCP client know for sure when it's talking to a new PCP server? Practically speaking, it has to err on the side of caution and pick a new nonce if it *might* be talking to a new PCP server.

My broader point is this: If the NAT gateway is actually forwarding inbound traffic to 10.0.0.2:22, how is it useful for it to lie to the client and claim that it is not?

i.e.:

1. Client says, "Please forward inbound SYNs to me at 10.0.0.2:22."
2. Server says, "No! NOT_AUTHORIZED!" but then proceeds to forward inbound SYNs to the client at 10.0.0.2:22 anyway.

Stuart Cheshire

---

From: Dan Wing <[email-masked]>
Date: Fri, 7 Jun 2013 14:03:20 -0700

> 2. Server says, "No! NOT_AUTHORIZED!" but then proceeds to forward inbound SYNs to the client at 10.0.0.2:22 anyway.

It could then do (3), which would be retrieving its previous Nonce from disk, and tries that Nonce value.  Yes, that step (3) is worse than the suggestion in this thread to just allow the server to communicate the existing mapping lifetime.  I support that suggestion; let's aim for doing that.

-d

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jun 2013 20:44:28 -0400

I also think it might be possible to relax the restrictions on nonce
re-use.

In particular if we do the analysis and confirm that the client is the
one harmed by enabling potential off-path attacks, then I think it's
reasonable for the client to make that security tradeoff.  I might for
example implement re-using a nonce if the address I am sending to is the
same and the IP address I have is the same.

--Sam

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Jun 2013 21:39:39 +0900

> 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins.

It merely means that what is necessary is not any nonce but a
transaction ID.

> I think we need to remove the server nonce check.

Right.

As the nonce, as an transaction ID, is specified by a client.
servers MUST accept any transaction IDs offered by their clients,
which initiate the transaction.

Using transaction ID straightly makes security implications a
lot clearer than insisting on a nonce as a poor alternative as
the required-by-IESG transaction ID.

						Masataka Ohta