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

Richard Barnes <rlb@ipv.sx> Wed, 19 December 2018 16:15 UTC

Return-Path: <rlb@ipv.sx>
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 01FCC130E2B for <secdir@ietfa.amsl.com>; Wed, 19 Dec 2018 08:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 EepiwT3DTWy6 for <secdir@ietfa.amsl.com>; Wed, 19 Dec 2018 08:15:25 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCD512D4F2 for <secdir@ietf.org>; Wed, 19 Dec 2018 08:15:25 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id a11so19546870otr.10 for <secdir@ietf.org>; Wed, 19 Dec 2018 08:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kd5c8TLkuWE4qHVQHOj79TbhfvgBOaFy9GmlX52JTRI=; b=Z53wVU7wJERMTYPTYUUtG2vr4YFAxjMfdjegzu4CqX0jDgqH1PMPnzw2n8f/xn0tAk bOc/nTMDueRItagWwfnUUIwQtnAeq9qhXkPZbOKORJIkYRx2ukKG7aDzTio4yTwxHgna s2/8vp8pB/DL/Bt0J34h5Pgx8VmjOXiqG8qFRLDqScNcLbhCHcwTyeKB/wxAfMHVLp3i AUTa3lccWu5L6gvh7QD3tNzk69hDq3FsUsCEX6eB9MI6tXJnWzQ/lGsrqaeP/ErQBF8S 4sfrfs6+XkzR0/ni2/bLmtxHrmtZbZnujy5cMsoSjvYj3lud0dxQLAERVGDDvHpWdm0/ k1kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kd5c8TLkuWE4qHVQHOj79TbhfvgBOaFy9GmlX52JTRI=; b=GPg3ClWM49I3PVUeRUG4TEvA7WHswnQ4Njgi8v6F2p/icnIkk/RWWyRdEHnqr5H+hW TcOZi9/szeWvKveZj0OdqlsRCMjpr/owisqm6YTr+TMBmVEkUviBidQ6WvHF4h81bsfG ICbxmOGQ4bBDB9VtCuhAhylBZzXtQzq0qwULxTrBfae2Lq82t+yrtV5BgSL8Uhg6vamd bW9m/iE9UY2yheboNhW7RKTN8S4XK8uWV4dVwkWrIu7n6tZMt6gk0BPgdJ8sSBzkFo6N dpxE8Mdt+uO8nTlYlNBwx2CBapghPW3wkWXAqOYrljeJVKpCBJDzDYK7NNBACF7ZfIuO p+Rg==
X-Gm-Message-State: AA+aEWYe92Y0W8/q2brQz2Etoj11Qo4q+ja6HcU/RoiVvdewQbsAeL0t 8slUeIzPJrjdRCAlbm0K9ANhIFAIABEInqQ4IdTYuuhoa4J5cA==
X-Google-Smtp-Source: AFSGD/UT1POrfTOX2Xd18WaM/x5U7iqFVLz7vc1tIeaLRQXar/+8hskLXAyypV5kdw8mdNb8QUyiGzHqSxBJcRh0S2M=
X-Received: by 2002:a9d:191a:: with SMTP id j26mr6700950ota.81.1545236123730; Wed, 19 Dec 2018 08:15:23 -0800 (PST)
MIME-Version: 1.0
References: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com>
In-Reply-To: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 19 Dec 2018 11:15:08 -0500
Message-ID: <CAL02cgT5zfCG=cfTJGZ2QsEQcXK3HpXMhR3tbFSRiKQ-OpDrfA@mail.gmail.com>
To: Hilarie Orman <hilarie@purplestreak.com>
Cc: The IESG <iesg@ietf.org>, secdir <secdir@ietf.org>, draft-ietf-perc-srtp-ekt-diet.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003ff476057d6252eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/la_kf1PlH6PlwNp8-6unQmYelBM>
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: Wed, 19 Dec 2018 16:15:29 -0000

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 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.


>
> 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.



> 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.

--Richard



>
> Hilarie
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>