[secdir] Secdir review of draft-ietf-dime-e2e-sec-req-04

Radia Perlman <radiaperlman@gmail.com> Wed, 18 May 2016 23:29 UTC

Return-Path: <radiaperlman@gmail.com>
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 A8C8812D7C8; Wed, 18 May 2016 16:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uXdDIefiXX4g; Wed, 18 May 2016 16:29:05 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 512D512D7CD; Wed, 18 May 2016 16:29:05 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id v145so102280679oie.0; Wed, 18 May 2016 16:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=S7+oj1uz/h2bVGS/2barvO7xDC8vHbt+l1TWEDNEmr8=; b=BWZ4RDvYzW5O13s8a52+T8ztdt24Kh3EvP4k49FUCQ/p34WETc0m6r2/eMnAUY9Iuo hENQuHjJSNDPXwVdf80ejzS160UJftl/BiThKRXzPn/AcMZkSRzfmvqjLjeQrMOI/JrV 20vnPuHtdY8jBCFagr46mX321Omz3cLthGaGe8iN0dTswtDLmv27gGYkfHZIX3kxW0nC kEwVRAN1fThcHut0eQWPOfXSbSU+eIVpmXU6ihSWBE0pCAcDn6lKiCRl8/NFWzQptBwF RaoyORcBynx0xHON74THYCHwkc7ydhaFpEUfLcRhH9d4s/4+GtJrJ50yt+YVgOOWLTfe VtxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=S7+oj1uz/h2bVGS/2barvO7xDC8vHbt+l1TWEDNEmr8=; b=mODITezuL8IoVlwQOtBDJqZpLTymxEy30mjDHJ+pU42EidKecaXTGxu/4DSgIjjFMb r4/L/dD2ySVDTrjG8uj7t0KRXMPWCQtnINNSHmyUmWNoEnUELy0ga4G+tZ19BB0Jytjj lC7rVXmtXEW6LKXq4yl8TWV5UDVNzFzkBqDx7Zlof+vqVZgBNmSYN9/Xu9+Mw/6FR7+g gN5EOicJ1YrQuuyNAiDBu4uHqJVNhC/AuXGFJMDc+f3XJGT7rQ9n8BrPIDyRTmQFeQNc SUJc7zRDPreISrkawv4w7Zvuf9m6wLyKHahxfGM/pbt/i1yHj4mFGdJcj6/0Is1EO4fR DqLg==
X-Gm-Message-State: AOPr4FWcKqOH08QJmKYpe6BPuimkBfqlSihGAmpN4m6bzkQFekz3KQDZz+iNEYmHO9/HapbLc9/mPc5nHqU5FA==
MIME-Version: 1.0
X-Received: by 10.157.56.51 with SMTP id i48mr5779659otc.130.1463614144738; Wed, 18 May 2016 16:29:04 -0700 (PDT)
Received: by 10.182.188.7 with HTTP; Wed, 18 May 2016 16:29:04 -0700 (PDT)
Date: Wed, 18 May 2016 19:29:04 -0400
Message-ID: <CAFOuuo5k0TuEZGuvKLqswjAXzKueS0sJ0fifG4uA-=Jxyf7n1Q@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dime-e2e-sec-req.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a113dc9be2f7d6d05332639ba
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/JUMEekYrc3CNhKIg0nWYe3EDp8c>
Subject: [secdir] Secdir review of draft-ietf-dime-e2e-sec-req-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 23:29:06 -0000

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 document is readable, though a pass through for simple grammar would be
helpful.  However, a more important editorial comment is that AVP should be
defined under terminology and not wait until section 3 to expand the
acronym.

-----------

Some things are confusing to me.  For instance,

     Requirement #7:  The solution MUST support symmetric keys and
      asymmetric keys.

         Motivation: Symmetric and asymmetric cryptographic algorithms
         provide different security services.  Asymmetric algorithms,
         for example, allow non-repudiation services to be offered.

I'm not sure what the motivation was for putting this in. Why would
diameter need nonrepudiation?  And if it's using asymmetric, because it
wants nonrepudiation, why would it also need symmetric keys?  Indeed,
usually protocols that use asymmetric keys also use symmetric.  Or is it
saying that preshared secret keys, or Kerberos must be supported even if a
public key scheme is fully deployed? Why would that be?

--------

I found this sentence confusing:

      As an example, consider the Diameter EAP
      application [4] that allows the transport of keying material
      between the Diameter server to the Diameter client (using the EAP-
      Master-Session-Key AVP) for the protection of air interface
      between the end device and the network access server.

What is "air interface"?  Do you mean the wireless link?  Is the "diameter
client" the same as the "end device"?  What is the "network access
server"?  None of these things are in the diagram.

------------
Also,

   {AVP}k refers to an AVP that
   experiences security protection (using key "k") without further
   distinguishing between integrity and confidentiality protection.

I think it's a good idea to have different notation for confidentiality and
integrity, because sometimes things need one, and sometimes they need both.

---------

Radia