Subject: [RTG-DIR] RTG DIR Review of draft-ietf-tram-turn-mobility-03

From: Antoni Przygienda <[email-masked]>
Date: Thu, 18 Aug 2016 02:01:21 +0000

Hello,
I have been selected as the Routing Directorate reviewer for draft-ietf-tram-turn-mobility-03. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-tram-turn-mobility-03.txt
Reviewer: Tony Przygienda
Review Date: 18 Aug 16
Intended Status: Standards

Summary:

Overall, clear draft, fairly straight-forward extension to STUN. Possible improvement and minor security holes.

I have some concerns about this document that I think should be commented on/addressed/resolved before publication.

Comments:

To prevent an in-path attack with replying mobility tickets I would add a sentence to the draft saying that the newly generated mobility ticket on refresh response MUST be different from the previous one (that can be assured by including a nonce or something even if the refresh doesn’t change the allocation). An even stronger replay attack could include a client nonce in the mobility ticket on the allocate request that MUST be used to generate the ticket. The nonce would be repeated in the Refresh request with the ticket. In a sense it would be best if the mobility ticket could not be reused without a client and a server context stored.

Omission: If the ticket is reused/corrupt, I’m missing according procedures for an error in the Refresh Response, i.e. an error response code with “mobility ticket invalid” and description what happens (is the allocation dropped, old value retained?)

Thanks

--- tony

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 05:04:56 +0000

Hi Tony,

Thanks for the review. Please see inline

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 7:31 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RTG DIR Review of draft-ietf-tram-turn-mobility-03

Hello,

Summary:

Comments:

To prevent an in-path attack with replying mobility tickets I would add a sentence to the draft saying that the newly generated mobility ticket on refresh response MUST be different from the previous one (that can be assured by including a nonce or something even if the refresh doesn’t change the allocation).

[TR] Added the following line:
The new ticket sent in the refresh response MUST be different from the old ticket.

An even stronger replay attack could include a client nonce in the mobility ticket on the allocate request that MUST be used to generate the ticket. The nonce would be repeated in the Refresh request with the ticket. In a sense it would be best if the mobility ticket could not be reused without a client and a server context stored.

[TR] Mobility ticket can only be re-used by the same client, any other client cannot use the ticket issued to a client. Security considerations section discusses either to use client authentication or (D)TLS to avoid misuse of the ticket.

[TR] Good point, added the following line:
NEW:
If the ticket is invalid then then server MUST reject the request with a 400 (Bad Request) error.

Cheers,
-Tiru

Thanks

--- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 18 Aug 2016 06:31:27 +0000

Hello,

Summary:

Comments:

Ø  OK

a)      OK, the change above with the additional requirement of strong authentication this should prevent replays. Except there is a corner case where the mobility refresh is for the _same_ IP and port as before (I don’t see anything in the spec preventing that). If an attacker gets hold of that ticket and reuses it, it can mount a DDoS with the server replaying the client’s refresh with the old ticket already used (it has the packet & the mobility ticket will come from the same, i.e. right, place). The behavior from here on is unspecified. The client and/or the server may get confused and start reissuing refreshes and tickets with the attacker reusing the packets.  Very, very corner obviously. Server side nonces would help with it (i.e. a mobility ticket can never be used twice unless the SHA covers new server nonce) _or_ specifying that the mobility refresh must NOT refresh to the same IP/port … I hope you can parse what I wrote.

Ø  OK, still missing whether the allocation is dropped or persists (i.e. what happens to the state).

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 06:44:48 +0000

Inline [TR2]

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 12:01 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: RTG DIR Review of draft-ietf-tram-turn-mobility-03

Hello,

Summary:

Comments:

Ø  OK

a)      OK, the change above with the additional requirement of strong authentication this should prevent replays. Except there is a corner case where the mobility refresh is for the _same_ IP and port as before (I don’t see anything in the spec preventing that). If an attacker gets hold of that ticket and reuses it, it can mount a DDoS with the server replaying the client’s refresh with the old ticket already used (it has the packet & the mobility ticket will come from the same, i.e. right, place).

[TR2] I don’t see how this attack is possible with STUN authentication. Attacker will not know the client secret and will not be able to calculate the HMAC for the Refresh request.

The behavior from here on is unspecified. The client and/or the server may get confused and start reissuing refreshes and tickets with the attacker reusing the packets.  Very, very corner obviously. Server side nonces would help with it (i.e. a mobility ticket can never be used twice unless the SHA covers new server nonce) _or_ specifying that the mobility refresh must NOT refresh to the same IP/port … I hope you can parse what I wrote.

[TR2] Allocation persists, no change in the state.

-Tiru

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 18 Aug 2016 07:40:06 +0000

Ø  In this corner case it can simply replay the refresh packet with all the hashes (unless strong authentication precludes UDP, I don’t remember STUN that far). Did I miss something?  No nonce changes, the refresh looks the same and comes from the correct place (refresh didn’t change location). Again, very, very cornery.

Ø  If that has been spelled out in the doc somewhere already, ignore my comment. I must have missed it.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 11:09:04 +0000

Inline [TR3]

Sent: Thursday, August 18, 2016 1:10 PM

a)      OK, the change above with the additional requirement of strong authentication this should prevent replays. Except there is a corner case where the mobility refresh is for the _same_ IP and port as before (I don’t see anything in the spec preventing that).

[TR3] ] Added following line to address the above comment:
If the source IP address and port of the Refresh Request with STUN MOBILITY-TICKET attribute is same as the stored 5-tuple allocation then the TURN server rejects the request with 400 (Bad Request) error.

If an attacker gets hold of that ticket and reuses it, it can mount a DDoS with the server replaying the client’s refresh with the old ticket already used (it has the packet & the mobility ticket will come from the same, i.e. right, place).

Ø  In this corner case it can simply replay the refresh packet with all the hashes (unless strong authentication precludes UDP, I don’t remember STUN that far). Did I miss something?

[TR3] STUN supports three authentication mechanisms, out of which two are used for TURN, long-term credential mechanism https://tools.ietf.org/html/rfc5389#section-10.2 and third-party authorization using OAuth 2.0 https://tools.ietf.org/html/rfc7635. STUN also has been recently enhanced to support DTLS over UDP.

No nonce changes, the refresh looks the same and comes from the correct place (refresh didn’t change location). Again, very, very cornery.

[TR3] 400 error code means that server only considers that the current transaction has failed.

-Tiru

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 18 Aug 2016 14:38:55 +0000

On [prz3]

Last clarification, otherwise I think it’s all resolved with the additions suggested.

Thanks

n  Tony

<[email-masked]<mailto:[email-masked]>> spake:

Inline [TR3]

[PRZ3]: The client, even without moving, may need to refresh the allocations per normal STUN procedures RFC5766 7.1 if not mistaken. Do I understand correctly that it would have to omit the mobility ticket in such a case?  May merit a sentence.

        [PRZ3] OK, with the addition [TR3] that’s resolved then.

Ø  [PRZ3] OK, resolved

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 14:56:24 +0000

Please see inline [TR4]

Sent: Thursday, August 18, 2016 8:09 PM

On [prz3]

Thanks

n  Tony

Inline [TR3]

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 1:10 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RTG DIR Review of draft-ietf-tram-turn-mobility-03

[TR4] Yes, it’s already discussed in https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-04#section-3.2.1.

[TR4] Security considerations section in this doc discusses the above mechanisms.

Ø  [PRZ3] OK, resolved

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 18 Aug 2016 15:09:47 +0000

[TR4] comment from your side is correct, thanks. With the additions you suggested in this thread all my comments should be resolved on the next rev then  …

Thanks

--- tony

Please see inline [TR4]

On [prz3]

Thanks

n  Tony

Inline [TR3]

Ø  [PRZ3] OK, resolved