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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: tram <[e-mail]> On Behalf Of Noriyuki Torii
> Sent: Thursday, July 11, 2019 11:03 AM
> To: [e-mail]
> Subject: [tram] some more nits in draft-ietf-tram-turnbis-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> 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.)

Yes, it looks like a nit in STUNbis.

> Likely, the example response must
> have the MESSAGE-INTEGRITY-SHA256 in place of the MESSAGE-INTEGRITY.

Thanks, Ben (ISEG review) raised the same comment. It will be fixed in the next revision, PASSWORD-ALGORITHMS, PASSWORD-ALGORITHM and MESSAGE-INTEGRITY-SHA256 is used in all requests 
starting from Allocate success response. 

Cheers,
-Tiru

> 
> 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
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram