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

Barry Leiba <barryleiba@computer.org> Sat, 02 May 2009 20:32 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
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)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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)
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=
MIME-Version: 1.0
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.223.108.211 with SMTP id g19mr1508050fap.39.1241296418792; Sat, 02 May 2009 13:33:38 -0700 (PDT)
Date: Sat, 02 May 2009 16:33:38 -0400
X-Google-Sender-Auth: 583d759322804ec8
Message-ID: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms-chairs@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-isms-transport-security-model-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 02 May 2009 20:32:18 -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/