[tram] some more nits in draft-ietf-tram-turnbis-27

[Noriyuki Torii <[e-mail]>]

To whom it may concern,

I found some more points in draft-ietf-tram-turnbis-27, in addition to
my previos mail.
So I would like to report here. Hope this may help for improvements.

in page 67

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |                                    |             |             |
    |--- Allocate request -------------->|             |             |
    |    Transaction-Id=0xA56250D3F17ABE679422DE85     |             |
    |    SOFTWARE="Example client, version 1.03"       |             |
    |    LIFETIME=3600 (1 hour)          |             |             |
    |    REQUESTED-TRANSPORT=17 (UDP)    |             |             |
    |    DONT-FRAGMENT                   |             |             |
    |                                    |             |             |
    |<-- Allocate error response --------|             |             |
    |    Transaction-Id=0xA56250D3F17ABE679422DE85     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    ERROR-CODE=401 (Unauthorized)   |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda"      |             |
    |    PASSWORD-ALGORITHMS=MD5 and SHA256            |             |
    |                                    |             |             |
    |--- Allocate request -------------->|             |             |
    |    Transaction-Id=0xC271E932AD7446A32C234492     |             |
    |    SOFTWARE="Example client 1.03"  |             |             |
    |    LIFETIME=3600 (1 hour)          |             |             |
    |    REQUESTED-TRANSPORT=17 (UDP)    |             |             |
    |    DONT-FRAGMENT                   |             |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda"      |             |
    |    PASSWORD-ALGORITHMS=MD5 and SHA256            |             |
    |    PASSWORD-ALGORITHM=SHA256       |             |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |    MESSAGE-INTEGRITY-SHA256=...    |             |             |
    |                                    |             |             |
    |<-- Allocate success response ------|             |             |
    |    Transaction-Id=0xC271E932AD7446A32C234492     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=1200 (20 minutes)      |             |             |
    |    XOR-RELAYED-ADDRESS=192.0.2.15:50000          |             |
    |    XOR-MAPPED-ADDRESS=192.0.2.1:7000             |             |
    |    MESSAGE-INTEGRITY=...           |             |             |

Above example shows the server's final response includes MESSAGE-INTEGRITY.
But the section 9.2.4 of STUNbis says
---
   If these checks pass, the server continues to process the request.
   Any response generated by the server MUST include MESSAGE-INTEGRITY-
   SHA256 attribute, computed using the username and password utilized
   to authenticate the request, unless the request was processed as
   though PASSWORD-ALGORITHM was MD5 (because the request contained
   neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM).  In that case
   the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE-
   INTEGRITY-SHA256 attribute.
---
So, the final response in this diagram must include the MESSAGE-INTEGRITY-
SHA256, not the MESSAGE-INTEGRITY.

in page 71 (and subsequent diagrams ...)

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |--- CreatePermission request ------>|             |             |
    |    Transaction-Id=0xE5913A8F460956CA277D3319     |             |
    |    XOR-PEER-ADDRESS=192.0.2.150:0  |             |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda"      |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |                                    |             |             |
    |<-- CreatePermission success resp.--|             |             |
    |    Transaction-Id=0xE5913A8F460956CA277D3319     |             |
    |    MESSAGE-INTEGRITY=...           |             |             |

The MESSAGE-INTEGRITY is utilized here nevertheless the
MESSAGE-INTEGRITY-SHA256 should be chosen in previous Allocate example.
As a result, the authentication strength is degraded.

Section 9.2.3.2 of STUNbis says
---
   The client SHOULD
   cache the username, password, realm, and nonce for subsequent
   communications with the server. When the client sends a subsequent
   request, it MUST include either the USERNAME or USERHASH, REALM,
   NONCE, and PASSWORD-ALGORITHM attributes with these cached values.
   It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY-
   SHA256 attribute, computed as described in Section 14.5 and
   Section 14.6 using the cached password.  The choice between the two
   attributes depends on the attribute received in the response to the
   first request.
---
Thus, the example CreatePermission request must have the PASSWORD-ALGORITHM
and also the MESSAGE-INTEGRITY-SHA256, not the MESSAGE-INTEGRITY.
In fact, the PASSWORD-ALGORITHMS also would be required because any requests
having only the PASSWORD-ALGORITHM without the PASSWORD-ALGORITHMS will be
rejected by the server, according to the section 9.2.4 of STUNbis.
 (Although the section 9.2.3.2 of STUNbis does not explicitly point it out.
  I wonder it might be a nit of STUNbis.)
Likely, the example response must have the MESSAGE-INTEGRITY-SHA256 in place
of the MESSAGE-INTEGRITY.

These points will apply to all subsequent example diagrams which are involved
in authentication.

Please note that such a degradation may be regarded as a result of bid-down
attack therefore the request will be probably rejected by the server.

Best regards,

Noriyuki Torii