Re: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08

Benjamin Kaduk <kaduk@mit.edu> Mon, 18 February 2019 22:28 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81034131083; Mon, 18 Feb 2019 14:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 Z5X7dLgd4Htw; Mon, 18 Feb 2019 14:28:01 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780109.outbound.protection.outlook.com [40.107.78.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C1B131067; Mon, 18 Feb 2019 14:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qigp7GQyQg67BsnYNrtsAJm70nAdE8JnndT/KaoUChk=; b=iJUu479yUWAInhKSyqLu9zcVyuBMO5tVhLDrY/qyGvuLtHpA7EJW0JVH3/DVysUvZyQwfpcVz8MZgGtu0IrwXXr9hyQOSHhK9s3UgsCgt08sc3Adn+yNTZAjuPcnRsTtpbsAD0fNt3QhHxGoMYHnMP2uaTpy42Sgt+ziNILwv9A=
Received: from BYAPR01CA0031.prod.exchangelabs.com (2603:10b6:a02:80::44) by MN2PR01MB5614.prod.exchangelabs.com (2603:10b6:208:11c::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Mon, 18 Feb 2019 22:27:59 +0000
Received: from DM3NAM03FT003.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by BYAPR01CA0031.outlook.office365.com (2603:10b6:a02:80::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 18 Feb 2019 22:27:59 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT003.mail.protection.outlook.com (10.152.82.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 18 Feb 2019 22:27:58 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1IMRsJP027643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 17:27:56 -0500
Date: Mon, 18 Feb 2019 16:27:54 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Richard Barnes <rlb@ipv.sx>
CC: Hilarie Orman <hilarie@purplestreak.com>, <draft-ietf-perc-srtp-ekt-diet.all@ietf.org>, The IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Message-ID: <20190218222754.GO24387@kduck.mit.edu>
References: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com> <CAL02cgT5zfCG=cfTJGZ2QsEQcXK3HpXMhR3tbFSRiKQ-OpDrfA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL02cgT5zfCG=cfTJGZ2QsEQcXK3HpXMhR3tbFSRiKQ-OpDrfA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(396003)(39860400002)(2980300002)(51444003)(189003)(199004)(51914003)(356004)(336012)(16586007)(54906003)(8676002)(786003)(26005)(97756001)(58126008)(46406003)(106002)(36906005)(246002)(316002)(305945005)(186003)(76176011)(8936002)(7696005)(33656002)(126002)(53546011)(23726003)(426003)(956004)(476003)(446003)(2906002)(104016004)(53416004)(75432002)(1076003)(47776003)(14444005)(11346002)(6246003)(486006)(15650500001)(50466002)(88552002)(6916009)(4326008)(5660300002)(106466001)(229853002)(55016002)(86362001)(26826003)(478600001)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR01MB5614; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5e6c2ce6-c11c-4047-d306-08d695f05612
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:MN2PR01MB5614;
X-MS-TrafficTypeDiagnostic: MN2PR01MB5614:
X-Microsoft-Exchange-Diagnostics: 1; MN2PR01MB5614; 20:cG+9bvcFmlhib/z4EF6wm7/TcAGn7HoPjDkkEN0PYiOxX9871tfEYLz7Hk7cgzMs/nSrQtv91k5/L8sPakqHLr6XHODonVfBpknEOyjPY0a76Y5QyLL3CfxDCMuQX92P9A7n4kgYuvbskaSAuSSEQ7aBheUZNi1ZFBXuWvrz9h7hldk1TutbN+249or/mLCZyQUg7Ksx3EwNYa5SXRDFjSpqKQmnfJMszOIGc7j0DGiH/0Ap0mFm/Z8a7gZkhBEF2sSesOVp8F0/AgvMtlDCPzFbd2d6+n0CYrZBzC6wQIgWMEt5mLnXZxfe0Q+jEiawnzt/KLBo7smqregJFGmi1w/a+KyYm6IoiQvCiWqYEX20fnc306FD4iE4/4krR6Q400ZlYju71ao0HswrLioYkdM9JrvTb3yM4h1bgpi5EWoJAdjzJ9BsRM/5eOQvgp4R6O9tc8AgX4P6q5U/QhEqUtOCwc5wE1AYaCFAJ7m8o94yWeyDyoGsKgakwwFvSKPfoMVRBxh+p5f+wixOv1Ke6i3XNmxvPkXbQbAu5kkAQ6hc5RR7brCkch7PPwctpka6C8KoMSwhyQAJ+nESWKCYlaDZErZJ+SEbyve2xtS9ngg=
X-Microsoft-Antispam-PRVS: <MN2PR01MB561483871CFC2CD2A02269A5A0630@MN2PR01MB5614.prod.exchangelabs.com>
X-Forefront-PRVS: 09525C61DB
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MN2PR01MB5614; 23:FiJSbsSaao2y3F4w2t8JXFrLkoRHR3f1d3iu1ssza?= =?us-ascii?Q?Q2NxSpfq4bvLMFKzv+HWYmTl4KLWxP7wQK/IoD1+tSOqKiBbEjltkU/V2xRV?= =?us-ascii?Q?LySydtadxaeoXj+7eP/DVaUnFWVaMEgOKTr0Acw9ycEFwFEJIgj67LhfHAGa?= =?us-ascii?Q?rzyb0v9+Hj9CdD1SRunvCX9tpDyqgFSMuio4lo2C/ZhpLrdY2q3pKzFEJsdt?= =?us-ascii?Q?MSm6Uv+QyoKsxwn7qROhiNKmw3iAM19+av54u8EveOCBLdsIN9LCoUdq+G7N?= =?us-ascii?Q?zU+smAHCgkAj9s/06Q4O9NMTbrelJclZysG+sv3PJBZEf1PbsBGVr3GqKVxQ?= =?us-ascii?Q?2s2vFIuBwLzVb/gkPksqzq6/zNel9omNWBFxWQbMD3HuXAdKda1c/Fe46au3?= =?us-ascii?Q?J4h6S84AOhk7rlFdRnOF5X9vmifV6u283BZVn4h90bA3WnFIkgh0B2B29/eU?= =?us-ascii?Q?TDurqOmZZYKsDtwI3tRYtgyQ41Yn26xg8zzwhmU+Xd/sZAY75fn11OILc3wy?= =?us-ascii?Q?lSsfWSAPJ2KldRh1x+HZe+oa82edB5sGtFe60w5tFkNSUfYP+Ao89WzyKs0Y?= =?us-ascii?Q?U3LSRlJ5mHGN+EDS0VPPt7ZWhgthu3XeSHH8570dgubIDKGdk6PKkwblCoah?= =?us-ascii?Q?dooAoeGoUuyToa3Oa8NrGMTjPviHZ2UIBjZ6fcap4OEiwQfaWkJS3DyrgfZr?= =?us-ascii?Q?1hk1XimuprzCuQ32PBm7N80w4mSxIeE6oe6dDo0FmpiOKAVStifcq/eeUXH4?= =?us-ascii?Q?Jeiu10XxIYAYjyovraGSscT9uDM7of0rHJlSb9Hyl1g+tQQeo4StWMjtMMVT?= =?us-ascii?Q?AWZfXSDGtyx6QnYkgNcBHMvjNwjdpaSLtXVfY3C+r8p119Kt9f+PigiMDE8a?= =?us-ascii?Q?iod/LiCPUwbdQnNlxD0eOiG7tntr+k7pnZ/xed6ShTC9xGTdHRzZuTO4UDlk?= =?us-ascii?Q?60y4iT6d2lC4+v+Yr/p8zUFUz/efD+pndvy69dBBAe7Ffl97p39Ej4JrQWrV?= =?us-ascii?Q?f4oaJPfw7fHsOQj+an55RiJuEVbxseDpYoP6VBTfjcqQzXC1/JIjU4mur7QT?= =?us-ascii?Q?t7wCBwelbP9Zj2vGFQ3+qCXMch9pto4S+ERqzrNwielauPtDum2fT9IO7u/K?= =?us-ascii?Q?08hYJR6o03JBqJCWxUoSWMtwvnybZxmLtxRo7Zc7A5Jmu4rzwnJnbNeUtHfP?= =?us-ascii?Q?CQyz35m3SeZ6wsh9KrlvibDd9/uaXmW/EJl6SAQHSQqLOjLYN1O3pEYZeGl7?= =?us-ascii?Q?BV2VUmf9lhK29qc5z7F1LqTa2pNjCEEE7ZFbVYuOAGfmRZABPrbZU1G0nFRQ?= =?us-ascii?Q?lgFYOf5ECs3vjV7TLmhRf4=3D?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: 6j0CFOi0PlWkQvYoOD3xlelrF8DOkpYOZX43Vg2/ltacIJFCRumBxYRoAV+x8QH39+VkF0x5a2rWljWAnW9QWAKj8gJbCgUnbwhcgVmaTcNlj39F2Y6irc8kfr23Vk3iVhwwndmon14QPEf11waxPmxavbBVUi2aVCWXpL61yOSPAh6jGT7X0vfUUuWcPHLd1oAduhELYWGtf75KIC8l4PFoERKuj/LmPpJBEGDUHlMNr0qRa7hc/76E52O+W4K8KBBq7URS5Ae9p9acPwkt7Dm8Y07ahitQUEHjwgkeTXZ+oA/Zpiy/IOIpZrVVjYJdn+WzWZGFlVEmpInXQAxMQ+psCd5U1K92n6GQBIjni66+DA/yL48pD8zO9aKYk2lVDe3h/hUtWQGzbvLbnE2SaezYTpnRKiIHH5WFA6leCQM=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2019 22:27:58.4562 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e6c2ce6-c11c-4047-d306-08d695f05612
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR01MB5614
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/dJjsZrDEYGQ2ihH7O-YCZEq8Oq8>
Subject: Re: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 22:28:07 -0000

On Wed, Dec 19, 2018 at 11:15:08AM -0500, Richard Barnes wrote:
> Hi Hilarie,
> 
> Thanks for the review.  Sorry for the delay in responding.  Responses
> inline.
> 
> On Wed, Oct 31, 2018 at 4:39 PM Hilarie Orman <hilarie@purplestreak.com>
> wrote:
> 
> > Security review of Encrypted Key Transport for DTLS and Secure RTP
> > draft-ietf-perc-srtp-ekt-diet-08
> >
> > Do not be alarmed.  I have reviewed this document as part of the
> > security directorate's ongoing effort to review all IETF documents
> > being processed by the IESG.  These comments were written primarily
> > for the benefit of the security area directors.  Document editors and
> > WG chairs should treat these comments just like any other last call
> > comments.
> >
> > The draft defines a way by which each sender in a multi-participant
> > session can communicate its encrypting key (called a "master key") to
> > the other participants.  In this scheme, all participants learn a
> > key encrypting key (EKTKey) that is used to protect sender's
> > encrypting keys during transit.
> >
> > "This specification also defines a way to send the encrypted SRTP
> >    master key (with the EKTKey) along with the SRTP packet ...
> >    Endpoints that receive this and know the EKTKey can use the EKTKey
> >    to decrypt the SRTP master key which can then be used to decrypt
> >    the SRTP packet."
> >
> > I think that the paragraph above would be clearer if "(with the
> > EKTkey)" were changed to "(encrypted with the EKTkey)".
> >
> 
> Ack, queued pending resolution of other topics here.

(I don't see this in the -09; am I looking in the wrong place?)

> 
> 
> > I do not understand the security model.  If all participants know the
> > EKTkey, then why do senders need to separately select their own
> > individual keys?  Cannot all participants use something derived from
> > the EKTkey?  Is this a legacy thing?
> >
> 
> Yes, it's precisely a legacy thing, in a couple of ways.  The most
> important one is that in the SRTP conferencing context, there's not really
> an identifier that you can rely on being distinct per participant, so
> basically you don't have a label to put into the KDF.  A secondary
> consideration (not required for PERC AFAIK) is that this allows keys from
> external systems to be bridged into an EKT-enabled conference.
> 
> If there were only the first concern, you could do something like use the
> random value the endpoints make up as a KDF input (together with the master
> key) instead of a key.  But that would cut off the second use case, which I
> would hesitate to do without some list discussion.
> 
> Do you have a security concern here, or is this just a question for
> understanding?  I agree that there's some risk that endpoints will generate
> bad keys, but it seems like if you're unable to generate good keys, you
> have bigger problems.

I guess there's a little bit more overhead in schlepping around more key
material, but it's probably in the noise here.

> 
> >
> > Section 4.4 states that
> >    "EKT uses an authenticated cipher to encrypt and authenticate the
> >    EKTPlaintext."
> >
> > Also section 6 (security considerations) states:
> >    The EKT Cipher includes its own authentication/integrity check.  For
> >    an attacker to successfully forge a FullEKTField, it would need to
> >    defeat the authentication mechanisms of the EKT Cipher authentication
> >    mechanism.
> >
> > Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption
> >    Standard (AES) Key Wrap with Padding [RFC5649] algorithm."
> >
> > RFC5649 does not purport to define an authenticated cipher.  I am not
> > sure what properties of RFC5649 are the ones that are considered
> > important, so I cannot recommend appropriate wording, though I suspect
> > that "integrity" is the right word, not "authentication".
> >
> 
> What do you consider the difference between "integrity" and
> "authentication" here?  ISTM that these two are usually are very commonly
> conflated at the crypto layer (vs. higher layers of authentication like
> PKIs).  For example, message *authentication* codes are a commonly used for
> integrity protection.

Yes ... but an "authentication mechanism" I would tend to expect to provide
authentication that's strong enough to be useful for an authorization
decision (i.e., binding to some name or other identity).

> 
> 
> > I have one concern about the requirement that all senders change their
> > keys when the EKTKey changes.  Suppose a malicious participant manages
> > to create a replay attack that sends a EKTkey message with a key that
> > was previously used, perhaps even the same one that is currently used.
> > This would force all participants to change their keys, perhaps at a
> > very high rate, and this might lead to denial of service.
> > Participants might be advised to ignore EKTkey messages that repeat
> > the current EKTkey.
> >
> 
> This is a good idea.  Queued pending resolution of other topics here.

Thanks for that.

-Benjamin