Subject: [tram] Sharing nonces across allocations - allowed?

From: Jonathan Lennox <[email-masked]>
Date: Wed, 19 Feb 2014 17:36:40 +0000

So Oleg and I were having an argument in the rfc5766-turn-server bug tracker about whether it's valid to share nonces across TURN allocations.  (See <http://code.google.com/p/rfc5766-turn-server/issues/detail?id=107>).

I argued that this text from RFC 5389 means that a client can (and indeed should) re-use nonces across multiple allocations: 

   If the client has not completed a successful request/response
   transaction with the server (as identified by hostname, if the DNS
   procedures of Section 9 are used, else IP address if not), it SHOULD
   omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes.
   In other words, the very first request is sent as if there were no
   authentication or message integrity applied.

   Once a request/response transaction has completed successfully, the
   client will have been presented a realm and nonce by the server, and
   selected a username and password with which it authenticated.  The
   client SHOULD cache the username, password, realm, and nonce for
   subsequent communications with the server.  When the client sends a
   subsequent request, it SHOULD include the USERNAME, REALM, and NONCE
   attributes with these cached values.  It SHOULD include a MESSAGE-
   INTEGRITY attribute, computed as described in Section 15.4 using the
   cached password.

Since it says that a client identifies a server by hostname or IP address, I interpreted this to mean that the client SHOULD use the nonce established in setting up one allocation to authenticate itself for other allocations on the same server.

However, Oleg's implementation doesn't do this, requiring a separate nonce for each allocation, and he cites this text from RFC 2617 (cited normatively by RFC 5389) as justification:

   "server is free to construct the nonce such that it may only be used
   from a particular client, for a particular resource, for a limited
   period of time or number of uses, or any other restrictions.  Doing
   so strengthens the protection provided against, for example, replay
   attacks".

So -- is Oleg's server indeed within its rights, here?  It results in an extra round-trip per allocation, which can be problematic if a client has a large number of allocations it needs to set up.

Relatedly: what should a server do when presented with a nonce it's never before encountered?  RFC 5389 specifies 438 as the error code when a nonce is "no longer valid", but doesn't say what to do when a nonce is one that the server has never sent.  I argue that this should also result in a 438 -- with a new nonce -- or else the client state machine can get stuck, but the spec doesn't currently say this.  (rfc5766-turn-server currently returns 401 in this case.)

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 10:07:49 -0800

Johnathan you cannot violate the wording of the original rfc 2617. That is saying "for a particular resource". An allocation is a resource. So we can limit nonce to a single allocation. 

That must not be a problem for a clean client implementation. I believe that stun-bis must clarify that.

With your approach there is a logical inconsistency. What is "client" in you case ? Same program ? Different program in the same system ? Different system with the same username ? It opens a can of worms. How about different threads, virtual machines etc - are they the same client ?

Each allocation must be treated independently from other allocations , that would allow consistent processing.

Also, we have to think about security. Your proposal would make the intruders tasks easier.

Sent from my iPhone

On Feb 19, 2014, at 9:36 AM, Jonathan Lennox <[email-masked]> wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 10:25:52 -0800

Also consider a situation when an intruder is behind the same nat as the real client. If the nonces can be reused then the intruder can just replay the original allocation request and get a new allocation. 

Stronger nonce usage pattern prevent that replay problem. You cannot say that the stun rfc does not allow stronger nonces.

Also look at nonces in SIP worlds, for example. There are implementations with unique nonces per session.

Sent from my iPhone

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 13:52:28 -0500

> Since it says that a client identifies a server by hostname or IP address, I interpreted this to mean that the client SHOULD use the nonce established in setting up one allocation to authenticate i…

Well, your client may try it, in an attempt to save a round-trip, but it
still has no idea for how long a nonce is going to be valid. The server
has absolute authority to declare a nonce stale whenever it wants, and
the client must be ready for it.

There's also this:

   For each allocation, the server SHOULD generate a new
   random nonce when the allocation is first attempted following the
   randomness recommendations in [RFC4086]

I suppose it could be interpreted either way, but I understand the above
to mean that previous nonces are expired when the new one is generated.

> Relatedly: what should a server do when presented with a nonce it's never before encountered?

Servers are not required to remember the nonces they generate. They can
use HMAC magic to detect invalid/expired nonces. (FWIW, that's what our
server, Numb, does.)

I suppose we could define a new "invalid nonce" error code in STUN-bis.
However, there would no point to doing that unless it resulted in
different client behaviour.

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: Jonathan Lennox <[email-masked]>
Date: Wed, 19 Feb 2014 19:46:57 +0000

> Stronger nonce usage pattern prevent that replay problem. You cannot say that the stun rfc does not allow stronger nonces.

Yes, that’s a good point — thinking about that case, this forces a per-allocation challenge/response, which does prevent that attack.

I agree this needs to be clarified in STUN-bis, though.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 19 Feb 2014 19:47:21 +0000

> the client must be ready for it.

Sure, absolutely.

> to mean that previous nonces are expired when the new one is generated.

That also makes sense to me.

> different client behaviour.

Right, I think this should be the 438; I can’t think of any reason to want client behavior to be different for expired nonces and invalid nonces.  (And, as you say, the server can’t always distinguish them.)  But right now the spec only says what to do for expired nonces.

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 11:51:08 -0800

Thanks Simon for the insight. That was helpful for the clarification.

I just checked how the industry is using the nonces. SIP is using the same
RFC 2617 guideline. I checked several "blueprint" SIP stack implementations
(which are used for the verification of the production SIP
implementations). They all are using unique-per-session nonces. SIP uses
the same nonce standards as TURN; so I assume that the industry is
consolidated behind the more secure nonce option. I've never heard that
anybody ever complained about that.

The problem is that some older initial TURN server implementations used
single nonce per TURN server. And there were several client libraries
written which explored that - and which expected that behavior. Now we have
a "backward compatibility" problem when the newer TURN servers enforce
stricter standards but the client libraries are incompatible.

We have had this issue multiple time thru the life of our TURN server,
there are endless requests to tweak the implementation so that the older
substandard clients can be used.

In our TURN server, we do remember the older nonces. But we limit the scope
of the nonce per separate session - just like the SIP implementations which
I am familiar with.

One thing that I can change is that if the client sends a nonce with the
initial allocation, we can return the value 438 ("stale nonce"). Currently
we just ignore nonce in the initial allocation and we return 401. A new
"illegal nonce" code would be more definite outcome but I am not sure that
it is necessary.

Regards,
Oleg

On Wed, Feb 19, 2014 at 10:52 AM, Simon Perreault <
[email-masked]> wrote:

> > Since it says that a client identifies a server by hostname or IP
> address, I interpreted this to mean that the client SHOULD use the nonce
> established in setting up one allocation to authenticate itself for other
> allocations on the same server.
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 11:55:11 -0800

On Wed, Feb 19, 2014 at 11:47 AM, Jonathan Lennox <[email-masked]>wrote:

>
>
> Right, I think this should be the 438; I can't think of any reason to want
> client behavior to be different for expired nonces and invalid nonces.
>  (And, as you say, the server can't always distinguish them.)  But right
> now the spec only says what to do for expired nonces.
>
> _
>

OK, I agree with that.

Now let's hope that the change will not brake some other TURN client
implementations...

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 19 Feb 2014 19:56:12 +0000

> I agree this needs to be clarified in STUN-bis, though.

+1

We really should start an issues list (on a wiki or something) that we all agree need to be addressed as part of the STUNbis and TURNbis efforts.  Since these milestones are left as intentionally longer-term items, it  would be helpful when we circle back a year from now to have a list of what we learned working through these shorter-term milestones.

-G

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 14:58:00 -0500

Le 2014-02-19 14:56, Gonzalo Salgueiro (gsalguei) a écrit :
> We really should start an issues list (on a wiki or something)

As soon as we become a real WG (tomorrow?), we will have the IETF tools
at our disposal for that!

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 19 Feb 2014 19:59:05 +0000

> at our disposal for that!

Perfect.

-G

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Feb 2014 13:33:05 -0500

> at our disposal for that!

Done!

http://trac.tools.ietf.org/wg/tram/trac/report/1

Simon