Re: [secdir] secdir review of draft-ietf-lmap-information-model-17

Leif Johansson <leifj@sunet.se> Mon, 13 March 2017 07:46 UTC

Return-Path: <leifj@sunet.se>
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 4FF51129549 for <secdir@ietfa.amsl.com>; Mon, 13 Mar 2017 00:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.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 81NOli1vK21K for <secdir@ietfa.amsl.com>; Mon, 13 Mar 2017 00:46:08 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 6B5F4129502 for <secdir@ietf.org>; Mon, 13 Mar 2017 00:46:08 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id l37so97923307wrc.1 for <secdir@ietf.org>; Mon, 13 Mar 2017 00:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0554eQA7VfYvNyUyzsXNu7vsXpKYKL2yj3OPNp9WKxM=; b=yRut22T9ppd0OG5g26y5Xx/qBrKBNjxAXK5L2HcC6uIKeG7lDHmWmlgb71N74Xz5b9 bD64P2XXWIxOEgIBzgoW0jJ/lvf0EUINFGICpWie6JqtW+mGItbVSS7pR+XF63kfA64x LmNaJZN/DHVqAmT8J27LiabqarVDNbR55k62SdaB2Lz7byl6xUihkjfV6Vm/ZRGNFX5J eANjTVQuKBQUfV7M+a0jZpJexEQLfJctuLuMC6epMTqs97+UnSs75zbpphzNQAyqeH0l vAW45yMio4Pqdl+AL3IGzbPYlNx6Tl2YZRT3fFUB3qukRe7dR03gOrXWBCKxvvIMx4jk r1pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0554eQA7VfYvNyUyzsXNu7vsXpKYKL2yj3OPNp9WKxM=; b=BR0/v7A4VGeohGon06TFM5Z9bMB6lySqxKKg1yT/L7PNhI9oIzGSB8WHGByLhB8uIZ d6ykLxi0NxgZLbbRzF6Vyq9+pXRRaS6RGpy6G/w841VNUVDkU3u8oyaOIT+YAlLH1tij 6plLimH8yL+WMJdxwTZqGOlKO9CRPl6vZFBr55URH/DsUeiuhZc6DIFjpE/TdLkzZJ2i WkcIyK5lWQe8kZvwURL5vj+GEmVu2EjOvmcAOot+587Ef6ycI7H0+7vdwQE6pOQ1pnvh LAk/foutm5N3SlnQzrI6TKZuNm8juh1FZbgZVvbBfZFwvh6T6RWRerinnot4hRmma5v0 kDxQ==
X-Gm-Message-State: AMke39kF/vYaJkgzpFnl7FqsBylEGQ7CdOvE2p3w50++iQG+tBuZhsETbXdFW1rPmOLmCw==
X-Received: by 10.223.173.76 with SMTP id p70mr25121134wrc.168.1489391166720; Mon, 13 Mar 2017 00:46:06 -0700 (PDT)
Received: from [109.105.104.193] (dhcp59.se-tug.nordu.net. [109.105.104.193]) by smtp.gmail.com with ESMTPSA id x18sm10193158wmd.14.2017.03.13.00.46.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 00:46:06 -0700 (PDT)
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-lmap-information-model.all@ietf.org
References: <f9524559-f516-eb58-f989-8c333daba9cf@sunet.se> <20170312115200.GD50035@elstar.local>
From: Leif Johansson <leifj@sunet.se>
Message-ID: <4250948b-3919-2ebc-5d93-d0f1bbc41605@sunet.se>
Date: Mon, 13 Mar 2017 08:46:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170312115200.GD50035@elstar.local>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MzRZYKsz8o3HrWX8Ftnhbp2J4-E>
Subject: Re: [secdir] secdir review of draft-ietf-lmap-information-model-17
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: Mon, 13 Mar 2017 07:46:10 -0000

On 2017-03-12 12:52, Juergen Schoenwaelder wrote:
> On Thu, Mar 09, 2017 at 05:06:00PM +0100, Leif Johansson wrote:
>>
>> Reviewer: Leif Johansson
>> Review result: Has issues
>>
>> 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.
>>
>> Review:
>>
>> Section 3.8 begins "A Channel defines a bi-directional communication
>> channel". First of all it is probably a good idea avoid using the
>> term you're defining in the definition.
> 
> I can s/channel/mechanism/ to avoid the usage of channel while
> defining Channel (not sure it adds clarity though).
>  
>> Also in the text a Channel is described as a URL with the cert or CA
>> of the endpoint but in the channel object definition there is only a
>> reference to the credentials which I understood to be the client authn
>> credential and not the server identity.
>>
>> This leads me to a larger issue (which may be answered in another LMAP
>> document for all I know): what is the authentication model for LMAP?
>> Specifically, does LMAP assume the standard Web PKI for channel end-
>> points? If not, then you probably need to specify how to validate the
>> server cert which may lead you to want to represent a private CA (say)
>> in the channel object. In any case the authentication model should be
>> referenced from the Security Considerations section and clearly match
>> the information model for channels.
> 
> This being an information model, we aim at staying away from being too
> specific. The information model is mapped today to a YANG data model
> (IETF) and a data model for TR-69 (BBF). The YANG data model may be
> accessed today via NETCONF or RESTCONF. There may be other protocols
> in the future.  RESTCONF runs over HTTP/TLS, NETCONF runs by default
> over SSH (which supportes a number of authentication mechanisms),
> NETCONF may also run over TLS. In other words, the concrete details
> how authentication is done is specific to the protocols used to access
> instantiations of specific data models. This is why we talk about
> rather opaque credentials in the definition of ma-channel-obj and
> section 2 "Notation" says:
> 
>    credentials An opaque type representing credentials needed by a
>                cryptographic mechanism to secure communication.  Data
> 	       models must expand this opaque type as needed and
>                required by the security protocols utilized.
> 
> /js
> 

The level of abstraction is beside the point. If you want your model
to reflect authentication for client then you need a credential in the
model (which you have).

If in addition, you need to control how you validate the server cert
then you need something in the model that represents that. Given your
model that could be a credential too. It depends on what you want to
do but it doesn't depend on the level of abstraction of your model.

	Cheers Leif