Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12
"David B Harrington" <dbharrington@comcast.net> Tue, 05 May 2009 17:49 UTC
Return-Path: <dbharrington@comcast.net>
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 5DC1C28C144 for <isms@core3.amsl.com>; Tue, 5 May 2009 10:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
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 qinKivR+wPH9 for <isms@core3.amsl.com>; Tue, 5 May 2009 10:49:21 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id EA0CC3A71C0 for <isms@ietf.org>; Tue, 5 May 2009 10:49:20 -0700 (PDT)
Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id nosY1b03j1HzFnQ5Btqn5k; Tue, 05 May 2009 17:50:47 +0000
Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id ntqm1b00n0UQ6dC3atqnEa; Tue, 05 May 2009 17:50:47 +0000
From: David B Harrington <dbharrington@comcast.net>
To: 'Barry Leiba' <barryleiba@computer.org>, secdir@ietf.org, iesg@ietf.org
References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com>
Date: Tue, 05 May 2009 13:50:46 -0400
Message-ID: <069801c9cdaa$050fb660$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcnLZUwu2W1Vd7VvT4OWm2HjF/zAmACQXncg
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com>
Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org
Subject: Re: [Isms] [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.9
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 17:49:22 -0000
Hi, Thanks fo rthe review. I am updating the sources. comments inline David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Saturday, May 02, 2009 4:34 PM > To: secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-transport-security-model@tools.ietf.org; > isms-chairs@tools.ietf.org > Subject: [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > 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." fixed. > > 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. Hmmm. two parts to this answer: 1) RFC3411 says the security model **specifies**; it does not say it must provide the security services itself. This section says this security model "does not provide security mechanisms such as authentication and encryption itself." So they are consistent. 2) They are slightly inconsistent, because the WG realized that the interface to different security protocols would require much the same thing, so we made the Transport Security Model capable of working with multiple underlying security-providing security protocols, and rather than **specifying** each possible protocol, we specify how an administrator can specify the protocol as a parameter used by the Security Model. > > 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. That is a deployment decision made by an administrator who has an understanding of what is appropriate to the system in question. MUST is for implementers and SHOULD is for deployers. > > 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? fixed. > > 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 >
- [Isms] [secdir] secdir review of draft-ietf-isms-… Barry Leiba
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… David B Harrington
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… Jeffrey Hutzelman
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… David B Harrington
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… Jeffrey Hutzelman
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… David B Harrington
- Re: [Isms] [secdir] secdirreview ofdraft-ietf-ism… Randy Presuhn
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… Juergen Schoenwaelder
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… Barry Leiba
- Re: [Isms] [secdir] secdir review ofdraft-ietf-is… Glen Zorn
- Re: [Isms] [secdir] secdir review of draft-ietf-i… Sam Hartman
- Re: [Isms] [secdir] secdir reviewofdraft-ietf-ism… tom.petch
- Re: [Isms] [secdir] secdir reviewofdraft-ietf-ism… tom.petch
- Re: [Isms] [secdir] secdir reviewofdraft-ietf-ism… Juergen Schoenwaelder
- Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms… David Harrington
- Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms… David Harrington
- Re: [Isms] [secdir] secdir reviewofdraft-ietf-ism… Wes Hardaker
- Re: [Isms] [secdir]secdir reviewofdraft-ietf-isms… David Harrington
- Re: [Isms] [secdir]secdir reviewofdraft-ietf-isms… Wes Hardaker
- Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms… tom.petch
- Re: [Isms] [secdir] secdir review of draft-ietf-i… Barry Leiba
- Re: [Isms] [secdir] secdir reviewofdraft-ietf-ism… Barry Leiba