RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (3)

RFC 5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", April 2010

Note: This RFC has been obsoleted by RFC 8656

Note: This RFC has been updated by RFC 8155, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 5231
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Hannes Landeholm
Date Reported: 2018-01-09
Verifier Name: Spencer Dawkins
Date Verified: 2018-01-09

Section 16 says:

    |<-- Refresh success response -------|             |             |
    |    Transaction-Id=0x427BD3E625A85FC731DC4191     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=600 (10 minutes)       |             |             |

It should say:

    |<-- Refresh success response -------|             |             |
    |    Transaction-Id=0x427BD3E625A85FC731DC4191     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=600 (10 minutes)       |             |             |
    |    MESSAGE-INTEGRITY=...           |             |             |

Notes:

The last example refresh success response lacks message-integrity, incorrectly implying that the response after a stale nonce exchange does not have to be authenticated.

Errata ID: 3854
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Venu
Date Reported: 2013-12-31
Verifier Name: Spencer Dawkins
Date Verified: 2016-01-13

Section 11 says:

0x4000 through 0x7FFF: These values are the allowed channel
numbers (16,383 possible values).

It should say:

0x4000 through 0x7FFF: These values are the allowed channel
numbers (16,384 possible values).

Notes:

Section 11.2: The channel number is in the range 0x4000 through 0x7FFE
(inclusive);
Since both the values are inclusive it should be 16384 = (0x7FFF-0x4000 + 1)

Errata ID: 4815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Costin
Date Reported: 2016-09-28
Verifier Name: Magnus Westerlund
Date Verified: 2019-12-17

Section 11.2. says:

 The channel number is in the range 0x4000 through 0x7FFE
      (inclusive);

It should say:

 The channel number is in the range 0x4000 through 0x7FFF
      (inclusive);

Notes:

It seems in the rest of the channel numbers allowed range definitions the values are 0x4000 through 0x7FFF. See: 11. Channels, 18. IANA Considerations.

Status: Held for Document Update (1)

RFC 5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", April 2010

Note: This RFC has been obsoleted by RFC 8656

Note: This RFC has been updated by RFC 8155, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 4143
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Florian Waltersdorfer
Date Reported: 2014-10-23
Held for Document Update by: Spencer Dawkins
Date Held: 2016-01-13

Section 1.Intro... says:

attempt discover a direct communication path; that is, a

It should say:

attempt to discover a direct communication path; that is, a

Notes:

line 177 in the txt version, attempt *to* do something

Status: Rejected (1)

RFC 5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", April 2010

Note: This RFC has been obsoleted by RFC 8656

Note: This RFC has been updated by RFC 8155, RFC 8553

Source of RFC: behave (tsv)

Errata ID: 4933
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: shakeeb
Date Reported: 2017-02-15
Rejected by: Magnus Westerlund
Date Rejected: 2020-02-17

Section 17.3.3 says:

An attacker might attempt to disrupt service to other users of the
TURN server by sending Refresh requests or CreatePermission requests
that (through source address spoofing) appear to be coming from
another user of the TURN server.  TURN prevents this by requiring
that the credentials used in CreatePermission, Refresh, and
ChannelBind messages match those used to create the initial
allocation.  Thus, the fake requests from the attacker will be
rejected.

Notes:

When using short-term, credentials expire after a specific amount of time (such as 5
minutes) and clients get new credentials. The restriction imposed at section 17.3.3
prevents from refreshing allocation or permission using the new credentials.

This RFC approves RFC 5389. So one can use short-term credentials. But short-term credentials are useless if it can not be used to refresh allocation or permission.


The goal of 17.3.3 can be achieved by sending 438 with the new nonce.
--VERIFIER NOTES--
So TURN does not actually specify the usage of short-term credentials. It mandates support of long-term credentials as authentication mechanism. Also RFC 7635 (STUN for Third party Authorization) specifies how to handle expire of the access token. This is clearer in the replacement of RFC 5766 that will soon be published that specifies the following in Section 7.2:

If
the request is authenticated, the authentication MUST be done
either using the long-term credential mechanism of
[I-D.ietf-tram-stunbis] or the STUN Extension for Third-Party
Authorization [RFC7635] unless the client and server agree to
use another mechanism through some procedure outside the scope
of this document.

Report New Errata



Advanced Search