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

Jouni Korhonen <jouni.nospam@gmail.com> Sat, 28 May 2016 00:52 UTC

Return-Path: <jouni.nospam@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 7316612D0BD; Fri, 27 May 2016 17:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 ZiaFXKOaxT7m; Fri, 27 May 2016 17:52:39 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 87DCF12D558; Fri, 27 May 2016 17:52:37 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id f144so33309432pfa.3; Fri, 27 May 2016 17:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dFLHhpqxUOoQHRa5+BZhBVhTjFIe5OF7QPd5jWUb9pQ=; b=mEXfs7bT4IaVZG4YPOUZgELqF0V65lzvnPsOkJb0PPKVXepIzkVwnh/6ykN3C0sfBy 3QR4X4L07sta+Wk9LAERb/FMaD12ReGBbTwYvDFYc7+omt+kygPyYf+15xaGBIJDILAe JuWDGoMACSjra/1z3kyfugEtzWQChNyz/ijEevJvWdvW4jSrX2WHOJ1/tMFrgumB4D/0 RtMcsqX/eHINQu5bSQakOEJWiXENbUAZxN7TY9SrAoz1aWmrfUheBrLr5nSfwE23wPns ycCrzJyjIPDLFYGo40IloTfCA6W3Bg5QbBn2yS977/DYqm2Q8KEkuIdgvvdS0yegB6Op zKzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dFLHhpqxUOoQHRa5+BZhBVhTjFIe5OF7QPd5jWUb9pQ=; b=WTcyFT6gYFo1unRtHgISmADeealfr2N3iRnHCjSOFapqJXU/z+r5zZLlOjiaMQZtqI D5jSvkrPxR5r2TLzAbvRsoNPDFmP/p2h+4PIrMln6nUJn4ENyoW8VEljGjFKhcJ1RAXl LJ5uZS3oIkbIlg1fHovuxVnDqyZLtVKhIux+WwTgTUrYchvEdMm3eRz+MYjWYqNBpAF3 IM8M8pZ9iJu7nWLpVA50+NQW7nzqZzHpFVYMmx/ALQMAFsW/Hhc+mHskH+O7huXSEweV ys2eGixr81ymS0vxarrbJgyC/MOpUd/M8F3EQdQtjlVKiGt6iv4psSKr1EG1h7QL4lfF hHiA==
X-Gm-Message-State: ALyK8tJLEDIhki2I1Gj+t9kl4pK8RNvpAdmh8R54PZLHBCqg/pEUgi0MjmhmsfriLevDvg==
X-Received: by 10.98.43.209 with SMTP id r200mr26602643pfr.24.1464396757079; Fri, 27 May 2016 17:52:37 -0700 (PDT)
Received: from [10.16.65.166] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 17sm16327124pfa.59.2016.05.27.17.52.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 17:52:36 -0700 (PDT)
References: <CAFOuuo5k0TuEZGuvKLqswjAXzKueS0sJ0fifG4uA-=Jxyf7n1Q@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dime-e2e-sec-req.all@tools.ietf.org
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <bf914214-801a-d84d-b40c-c943561f6348@gmail.com>
Date: Fri, 27 May 2016 17:52:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CAFOuuo5k0TuEZGuvKLqswjAXzKueS0sJ0fifG4uA-=Jxyf7n1Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/QFgEb6CIo4MeV_WF41xcvQnideI>
Subject: Re: [secdir] Secdir review of draft-ietf-dime-e2e-sec-req-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.nospam@gmail.com
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: Sat, 28 May 2016 00:52:40 -0000

Hi Radia,

Sorry for the lag.. and thank you for the review. See some comments inline.

5/18/2016, 4:29 PM, Radia Perlman kirjoitti:
> 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.

Ack.

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

In most cases one would be interested in just providing proof of the 
integrity and origin of AVPs. This is actually the most likely use case. 
For that purpose asymmetric cryptographic algorithms would fit well.

If confidentiality of AVPs is required then symmetric keys would most 
likely to be used for that purpose.

Regading the uses.. the used crypto-suites should/would eventually be 
described per Diameter application. In that situation we are likely to 
see both symmetric and asymmetric crypto be used in the same Diameter 
node that handles multiple applications.


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

Air interface == wireless link, yes. End device is not the Diameter 
client. The end device could e.g., be a mobile phone whereas the 
Diameter client could be an access point or a base station.

Network access server would be a node with a Diameter client. We need to 
add that into the diagrams.

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

Ack, agree in general with the usefullness of different notations. In 
the examples we got there was just no need to make difference between 
confidentiality and integrity protection.

Thanks,
	Jouni

>
> ---------
>
> Radia