Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt

Christian Franke <nobody@nowhere.ws> Fri, 08 April 2016 13:40 UTC

Return-Path: <nobody@nowhere.ws>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3104012D0FF; Fri, 8 Apr 2016 06:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 2na0yiz8YZkD; Fri, 8 Apr 2016 06:40:46 -0700 (PDT)
Received: from athena.nowhere.ws (athena.nowhere.ws [146.0.105.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6154712D8B3; Fri, 8 Apr 2016 06:40:46 -0700 (PDT)
Received: from [31.133.176.90] (dhcp-b05a.meeting.ietf.org [31.133.176.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by athena.nowhere.ws (qmail) with ESMTPSA id C62DFE005; Fri, 8 Apr 2016 13:40:43 +0000 (UTC)
To: Stefan Winter <stefan.winter@restena.lu>, IETF OPSEC <opsec@ietf.org>
References: <20160321092737.6013.75371.idtracker@ietfa.amsl.com> <56EFBF2D.5090904@restena.lu>
From: Christian Franke <nobody@nowhere.ws>
Message-ID: <5707B4D9.9010508@nowhere.ws>
Date: Fri, 08 Apr 2016 10:40:41 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <56EFBF2D.5090904@restena.lu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsec/CbQLgDyd83_ifHUnNotgXPUjpD0>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2016 13:40:58 -0000

On 03/21/2016 06:30 AM, Stefan Winter wrote:
> this is the draft corresponding to my agenda slot request from last week.
> Name:		draft-winter-opsec-netconfig-metadata
> Revision:	00

I have just read through your draft. In my opinion, it would be very
useful to have a standardized way to provide configuration profiles to
users. Looking through the draft and the yang file, I came up with the
following notes:

Comments on the draft:
 - it would be useful if subject alt match could be configured
   for usage with e.g. EAP-TTLS
 - how would the private key for a client certificate be stored,
   also in `cert-data`? I don't see another suitable field
 - which information does `allow-save` apply to? If it applies to
   the private key of a client certificate, how would public
   key authentication work without storing it?
 - can you provide a usecase for the `valid-until` field?
 - it is not obvious to me how the current model applies to VPN or
   E-Mail Server connections as named in the draft
 - it is not clear to me how an anonymous identify for EAP-TTLS or
   EAP-PEAP would be configured
 - I think it would be useful to have some consideration, either in
   this or another document, about how the files procuded according to
   this model should be processed, i.e. requirements on how their
   authenticity must be verified, how they should be displayed to the
   users and in what configuration they should actually result.

Yang related:
 - there is a type leafref which should probably used when referring
   to config parts by UUID
 - there are types for ipv4 and ipv6 addresses that should be used
   instead of string
 - list IPAddress has dynamic and static as keys, keys need to be
   unique, so how to enable both dhcpv4 and dhcpv6? Same thing e.g.
   for DNS

-Christian