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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 16 July 2019 06:17 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB922120073 for <tram@ietfa.amsl.com>; Mon, 15 Jul 2019 23:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFUEsapqYgN8 for <tram@ietfa.amsl.com>; Mon, 15 Jul 2019 23:17:45 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D48120020 for <tram@ietf.org>; Mon, 15 Jul 2019 23:17:44 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563257209; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=FzbHR+mo8WVHKGYYbpyWCSyPrj00+27ChyfxN6 Weppw=; b=OpmKdwESqwxUvKPsJZGty62jgwPFNDP5cKtH671o 5W/RSZGXSP2LxvNpLMG4x5gotnlG1L2NuumszdwWJ1NrjvEeY7 tccr6zffNg1IHqs6u6+jOAwkkyudsf327usCf5fYlHukhOGnDT VrgOsH6CIu8nFySbTS/dX7u4zjdW2l8=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-46-AIoOFgJgOrivtXSS2F-qpA-1; Tue, 16 Jul 2019 02:17:39 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2aa4_4ec7_8fe089d3_0b6b_4792_a433_54ccfee4f1ec; Tue, 16 Jul 2019 00:06:48 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Jul 2019 00:17:34 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 16 Jul 2019 00:17:34 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Jul 2019 00:17:34 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MVF7o2R/GQeF9p8j+flqq8BjqT8Bcsd4S+yCQeJgxiNvWLniYKCy8kumP5TI8O05IKisMtZLXodMF3wUx91vF3S8rgmvJwHQGFeN/gWx6LKASq9qNLZXcpEkhUm4y6wk73Ecyq+JsgYkYBBPBvqrzAzBh/V0+rjzjjTostMdSJCPJJ0Y7abEALcDGGggAcnB/J5GFEwbEMT2hdKfbUOiYFwfxP7hJ1Kh9btwiNV6Wpn+BA6Qi1QK91MT3Hi9IoiUaUHWvFaQG5lsN6UsmZtzn6kBclzPlmLqM7MCHOKk/oVzAjoODigreuv0qcTeAwzbkL35jM9ODSmzyYY60WpPGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzbHR+mo8WVHKGYYbpyWCSyPrj00+27ChyfxN6Weppw=; b=CNRxi7hDpjgS5ZtMJls7B4CQ5Yr9TaAU3u8ivlm9XI4Rh+13XySqu8qAXMMBcafXgsCWuJLZSTgCg691BEiTH3Za6NNLuZgjwUOIllubyDw3sN7IulCmHmyxfUQFYMWtmfSWu9V4yZl8rCzYViXwfoJougztOdc0DijyphRGhN0WlPbE6CN9Hn67rnA/guKqFEpHKyeB6UrR4nRaFqELB5Xxzo+uZQS4enx/+OEQyKUyy52pJuZ6vypM/9n2xkgZtd9UlzzXFjKRlJuGDeovYARcBdU3KDGDBpHN+N/h3q4bz8mutScj4tpGQNCa+3abBHxrmmcWVOj8l+TNhEK0Jw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1804.namprd16.prod.outlook.com (10.172.44.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 16 Jul 2019 06:17:32 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 06:17:32 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Noriyuki Torii <torii0573@gmail.com>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] some more nits in draft-ietf-tram-turnbis-27
Thread-Index: AQHVN6ofh2Ycokq7FUGkLsu3UcGxaabL1VNA
Date: Tue, 16 Jul 2019 06:17:32 +0000
Message-ID: <DM5PR16MB1705CB64CFCE159D2EF69AA4EACE0@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <CABEjbRLmB4S3ot70iLxrNmUx_2f1ato8X1kTHeby9LGske+mew@mail.gmail.com>
In-Reply-To: <CABEjbRLmB4S3ot70iLxrNmUx_2f1ato8X1kTHeby9LGske+mew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f73483a3-5a76-4af5-3f9e-08d709b549c3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR16MB1804;
x-ms-traffictypediagnostic: DM5PR16MB1804:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DM5PR16MB1804D12539D3F1BDE5F12292EACE0@DM5PR16MB1804.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0100732B76
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(32952001)(13464003)(189003)(199004)(76176011)(6506007)(53546011)(6306002)(66066001)(52536014)(6436002)(7696005)(86362001)(2501003)(2906002)(99286004)(55016002)(25786009)(7736002)(80792005)(68736007)(66556008)(486006)(9686003)(64756008)(102836004)(5660300002)(71200400001)(476003)(478600001)(66446008)(66946007)(71190400001)(76116006)(66476007)(8676002)(229853002)(305945005)(11346002)(53936002)(14454004)(446003)(966005)(3846002)(6116002)(110136005)(26005)(74316002)(81156014)(316002)(6246003)(19627235002)(81166006)(8936002)(5024004)(14444005)(256004)(186003)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1804; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cFxrTemEr6+zrhKFfd1nMcLRdcvHuookFipQbxXfeG6CGMOe+UiAH+VvE8Wmk4Q9Bk+diNLsZQACrMzDC8HtUxqhS9awbe7oiUFipF2bp0wfgC6WxyG1vT0r+La8W3cREUHYCF9FNpuzbCEUhxGw5DBIdS21ALUeFRx8WCZThlqePtid4NqVthEoTFrNQHulKA4WBkNHOyHtxtDdAM3l16BulPRHCGkZ/c9Oqb1Ve8/1pfpuxZ6rlbKhfA7bgJuB6x97Yydqrx5Vm+TZ39bE139AugEyg4DO/7FNc4MaUFdKwqk9FwZDCMVqYfV+BsDNwAXZbO1RW7G5skM8/XY0XpKt9aveYcw8rFSDGgNHXnX/WtQ7lnlQLbJZX5KxgGS1clp1JTfgDvSEgFzX55PnqS9BQGujbXQX9z8kAl68wD4=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f73483a3-5a76-4af5-3f9e-08d709b549c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 06:17:32.4635 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1804
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6590> : inlines <7120> : streams <1827494> : uri <2868104>
X-MC-Unique: AIoOFgJgOrivtXSS2F-qpA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/V5E8uA3_lOk0Q9sVz--KFbpEXqI>
Subject: Re: [tram] some more nits in draft-ietf-tram-turnbis-27
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 06:17:48 -0000

> -----Original Message-----
> From: tram <tram-bounces@ietf.org>; On Behalf Of Noriyuki Torii
> Sent: Thursday, July 11, 2019 11:03 AM
> To: tram@ietf.org
> 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
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram