Re: [MIB-DOCTORS] Updates to the Guidelines of theSecurityConsiderations section of the MIB documents

"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 08 November 2011 16:44 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ADwnKh/zi9G+gaQzhOHs2TUQmCrR7ruNlw4uqS/Jc8sBvSbLfD1WlJskqInUgOdF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Message-ID: <001701cc9e35$bc4203c0$6b01a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: mib-doctors@ietf.org
References: <4E8CA1F8.5040807@ieca.com> <20111005201335.GA48603@elstar.local> <4E8CCCB5.9090501@ieca.com> <EDC652A26FB23C4EB6384A4584434A0403BE90B0@307622ANEX5.global.avaya.com> <4E8D7F85.6070106@ieca.com> <EDC652A26FB23C4EB6384A4584434A04048EE355@307622ANEX5.global.avaya.com> <002401cc9d7d$d97ca840$6b01a8c0@oemcomputer> <EDC652A26FB23C4EB6384A4584434A0404E0274D@307622ANEX5.global.avaya.com> <20111108102357.GA2559@elstar.local>
Date: Tue, 08 Nov 2011 08:44:50 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of theSecurityConsiderations section of the MIB documents
Precedence: list

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> Cc: "Randy Presuhn" <randy_presuhn@mindspring.com>; <mib-doctors@ietf.org>
> Sent: Tuesday, November 08, 2011 2:23 AM
> Subject: Re: [MIB-DOCTORS] Updates to the Guidelines of theSecurityConsiderations section of the MIB documents
...
> Do we also remove the 'even then,' from the previous paragraph? Can we
> also drop some of the 'at a minimum' phrases from the text suggested
> by Randy? And why do we refer to section 8 of RFC 3410, which talks
> about standardization status and movement of SNMPv1 to historic? So
> summing up, I have:
> 
> OLD
> 
>    SNMP versions prior to SNMPv3 did not include adequate security.
>    Even if the network itself is secure (for example by using IPsec),
>    even then, there is no control as to who on the secure network is
>    allowed to access and GET/SET (read/change/create/delete) the objects
>    in this MIB module.
> 
>    It is RECOMMENDED that implementers consider the security features as
>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
> 
> NEW
> 
>    SNMP versions prior to SNMPv3 did not include adequate security.
>    Even if the network itself is secure (for example by using IPsec),
>    there is no control as to who on the secure network is
>    allowed to access and GET/SET (read/change/create/delete) the objects
>    in this MIB module.
> 
>    Implementations MUST provide the security features described by the
>    SNMPv3 framework (see [RFC3410]), including full support for
>    authentication and privacy via the User-based Security Model (USM)
>    [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
>    MAY also provide support for the Transport Security Model (TSM)
>    [RFC5591] in combination with a secure transport such as SSH
>    [RFC5592] or TLS/DTLS [RFC6353].
> 
> (I am not sure "described by" is the best wording but I happily leave
>  it to native speakers to figure this out.)

Juergen's proposed text looks good to me.  (Definitely better than what
I sent out.)

As a native speaker...  I think the "described" is ok (other possibilities
might be "outlined", or "identified", because RFC 3410 doesn't really
go very far in describing them).  The "by" is also ok, though I think
"in" might be slightly better; it would be less anthropomorphic.

(RFC 3410 section 4 just gives a laundry list of generic requirements,
and section 6.4 lists the original SNMPv3 specifications related
to security.  For practical purposes, this normative reference to an
informational document just functions as a shorthand for "STD 62",
in my opinion.)

Randy

[MIB-DOCTORS] Updates to the Guidelines of the Se… Sean Turner
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Randy Presuhn
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Juergen Schoenwaelder
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Sean Turner
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Romascanu, Dan (Dan)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Sean Turner
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Romascanu, Dan (Dan)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Bert Wijnen (IETF)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Romascanu, Dan (Dan)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Bert Wijnen (IETF)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Randy Presuhn
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Romascanu, Dan (Dan)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Juergen Schoenwaelder
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Bert Wijnen (IETF)
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Randy Presuhn
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Sean Turner
Re: [MIB-DOCTORS] Updates to the Guidelines of th… Romascanu, Dan (Dan)