[Isms] [secdir] secdir review of draft-ietf-isms-transport-security-model-12

Barry Leiba <barryleiba@computer.org> Tue, 05 May 2009 07:28 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E18B3A6C12 for <isms@core3.amsl.com>; Tue, 5 May 2009 00:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level:
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0JcMkIwOnsg for <isms@core3.amsl.com>; Tue, 5 May 2009 00:28:36 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECD373A6AE2 for <isms@ietf.org>; Tue, 5 May 2009 00:28:35 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03685C00E6 for <isms@ietf.org>; Tue, 5 May 2009 09:28:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RZ27hqTSNsmJ for <isms@ietf.org>; Tue, 5 May 2009 09:28:40 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 866CFC00EB for <isms@ietf.org>; Tue, 5 May 2009 09:28:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0A9F7ADA2DC; Tue, 5 May 2009 09:28:21 +0200 (CEST)
Resent-From: j.schoenwaelder@jacobs-university.de
Resent-Date: Tue, 05 May 2009 09:28:21 +0200
Resent-Message-ID: <20090505072821.GE18821@elstar.local>
Resent-To: isms@ietf.org
Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.122) with Microsoft SMTP Server id 8.1.358.0; Sat, 2 May 2009 22:33:48 +0200
Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A9BCC002A for <j.schoenwaelder@jacobs-university.de>; Sat, 2 May 2009 22:33:48 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 70E155EC for <j.schoenwaelder@jacobs-university.de>; Sat, 2 May 2009 22:33:48 +0200 (CEST)
Received: from atlas1a.jacobs-university.de ([212.201.44.13]) by localhost (demetrius1.jacobs-university.de [212.201.44.46]) (amavisd-new, port 10030) with ESMTP id fF7x8FJalUZE for <j.schoenwaelder@jacobs-university.de>; Sat, 2 May 2009 22:33:46 +0200 (CEST)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by atlas1a.jacobs-university.de (Postfix) with ESMTP for <j.schoenwaelder@jacobs-university.de>; Sat, 2 May 2009 22:33:46 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463503A6C13; Sat, 2 May 2009 13:32:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB753A6BAD; Sat, 2 May 2009 13:32:18 -0700 (PDT)
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bap-gkfA8pKq; Sat, 2 May 2009 13:32:17 -0700 (PDT)
Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 86B603A695D; Sat, 2 May 2009 13:32:16 -0700 (PDT)
Received: by fxm2 with SMTP id 2so2881642fxm.37 for <multiple recipients>; Sat, 02 May 2009 13:33:40 -0700 (PDT)
Received: by 10.223.108.211 with SMTP id g19mr1508050fap.39.1241296418792; Sat, 02 May 2009 13:33:38 -0700 (PDT)
From: Barry Leiba <barryleiba@computer.org>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Sender: "secdir-bounces@ietf.org" <secdir-bounces@ietf.org>
Date: Sat, 02 May 2009 22:33:38 +0200
Thread-Topic: [secdir] secdir review of draft-ietf-isms-transport-security-model-12
Thread-Index: AcnLZUwu2W1Vd7VvT4OWm2HjF/zAmA==
Message-ID: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de
X-MS-Has-Attach:
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator:
x-beenthere: secdir@ietf.org
x-original-to: secdir@core3.amsl.com
x-mailman-version: 2.1.9
Errors-To: secdir-bounces@ietf.org
x-virus-scanned: amavisd-new at amsl.com
delivered-to: secdir@core3.amsl.com
x-jacobsispwhitelisted: med ietf.org DNSWLId 1703
dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fy2uYmSw5rN/Pkf8xt7e0mSigt4cAQWXutHm2qCKnpg=; b=JtsOIL/Vu3SllFQvuERsB4hMdgtE2xwH3vSN2+JDDIQ3QgZkX/5JBkBk5VqcugSMZ/ ye3gp/fLPg1TlQFB9c0sV0R1sXHDrTYRb2RkvXPQWnxR4kLpmLkgTQHeA6qhOkSSJAta zEpNLZ7aDQ2rC+Kh5r3lG1yjBkjUA9tIX/AHc=
domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=WfVkeWoNpOxGGx/5RDCnLeYIkgt3GHhDqtMAf9iaIcd/4t1TLq5RjYjy8XthXuaTW2 siP9Clb+KFNDrjMFaWMU+zpzTYqwigei5swnFVwbHOT0CSNlcw4O52RudN09feRZ5IIO vQBpqk0yHp2FwsQoQoRj7V6T+I3P/neui+idI=
x-google-sender-auth: 583d759322804ec8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-isms-transport-security-model@tools.ietf.org" <draft-ietf-isms-transport-security-model@tools.ietf.org>, "isms-chairs@tools.ietf.org" <isms-chairs@tools.ietf.org>
Subject: [Isms] [secdir] secdir review of draft-ietf-isms-transport-security-model-12
X-BeenThere: isms@ietf.org
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isms>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2009 07:28:42 -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.

This document defines a type of Security Model, as defined in RFC
3411, designed to go with a Transport Model, as defined in
draft-ietf-isms-tmsm.  I have no expertise in MIBs, and must presume
that people who do have reviewed this.

For that matter, I don't have expertise in SNMP, so please take these
comments with that in mind.  I've briefly gone through the associated
documents, and I think I understand how the pieces fit into the
architecture, but my understanding isn't thorough.

My comments:

Section 1.5: bullets 1 & 2 use normative RFC 2119 language.  Should
bullets 4 & 5 do so also?  E.g., "A Security Model SHOULD NOT require
changes to the SNMP architecture."

Section 2.1.1: I'm confused by this.  RFC 3411 section 3.1.1.4.1 says
that a Security Model specifies "the security protocols used to
provide security services such as authentication and privacy."  Yet
this section says that the Transport Security Model does NOT provide
these things.

And if it doesn't provide them, how can the admonition to use it "with
a Transport Model that provides appropriate security" be a SHOULD, and
not a MUST (noting that "appropriate" security could include no
authentication, if that's appropriate to the system in question)?
Some component has to take responsibility for the security, even if
it's to determine that no authentication or no privacy controls are
needed.

The same goes for the discussion of this in section 8, Security
Considerations.  "The security threats and how these threats are
mitigated should be covered in detail in the specifications of the
Transport Models and the underlying secure transports."  It looks like
this needs to be stronger than plain-English "should", or RFC 2119
"SHOULD", no?

I think this is a key point to make clear, so it's well understood
where the responsibility lies for the assurance of "appropriate"
security in the Transport Model, and what happens when a system uses
multiple Security Models, one of which is this one.

Again, my confusion here might simply be due to my understanding of
the architecture being only superficial.

Barry
-- 
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir