[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/
- [secdir] secdir review of draft-ietf-isms-transpo… Barry Leiba
- Re: [secdir] secdir review ofdraft-ietf-isms-tran… David B Harrington
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… Jeffrey Hutzelman
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… David B Harrington
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… Jeffrey Hutzelman
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… David B Harrington
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… Barry Leiba
- Re: [secdir] [Isms] secdirreview ofdraft-ietf-ism… Randy Presuhn
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… Glen Zorn
- Re: [secdir] [Isms] secdir review ofdraft-ietf-is… Juergen Schoenwaelder
- Re: [secdir] [Isms] secdir review of draft-ietf-i… David B. Nelson
- Re: [secdir] [Isms] secdir review of draft-ietf-i… Sam Hartman
- Re: [secdir] [Isms] secdir review of draft-ietf-i… Barry Leiba
- Re: [secdir] [Isms] secdir reviewofdraft-ietf-ism… Barry Leiba
- Re: [secdir] [Isms] secdir reviewofdraft-ietf-ism… Juergen Schoenwaelder
- Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms… David Harrington
- Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms… David Harrington
- Re: [secdir] [Isms] secdir reviewofdraft-ietf-ism… David Harrington
- Re: [secdir] [Isms] secdir reviewofdraft-ietf-ism… tom.petch
- Re: [secdir] [Isms] secdir reviewofdraft-ietf-ism… tom.petch
- Re: [secdir] secdir reviewofdraft-ietf-isms-trans… Wes Hardaker
- Re: [secdir] secdir reviewofdraft-ietf-isms-trans… Wes Hardaker
- Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms… tom.petch