Subject: Re: SNMPv3, last call

From: [email-masked] (Quality Quorum)
Date: Tue, 11 Nov 1997 08:37:52 -0500 (EST)

> 
> Aleksey,
> 
>      You don't know me, and I'm not involved with SNMPv3 at all.
> (I do work with SNMPv1 though :-)
> 
>      I have been following this discussion for a while, and I'm
> wondering, if there is such a large security hole in SNMPv3 (and I
> don't doubt that there is), why not challenge the WG to a "bake off".

There is no doubt for WG members that this security hole exists - 
consensus is that it is OK to be open for attack of this kind.

>      They can put up their reference implementation of SNMPv3 (assuming
> there is one), and if you can create a program that permanently wedges
> their manager or their agent, then they have to go back to the drawing
> board, and fix the RFCs.  If you cannot, then the RFCs proceed as is.

Nobody has any doubts that I can, but again consensus is that RFCs
should proceed as is :).

>      My two cents,
>      --Rich

Aleksey

---

From: "Brian O'Keefe" <[email-masked]>
Date: Tue, 11 Nov 1997 12:01:00 -0700

> Nobody has any doubts that I can, but again consensus is that RFCs

Aleksey, I have doubts you can.  Further, never once have you
actually detailed your proposed solution for the working group
(e.g., elements of procedure).

Either put up or shut up.

bok

---

From: [email-masked] (Quality Quorum)
Date: Tue, 11 Nov 1997 15:14:54 -0500 (EST)

> (e.g., elements of procedure).

Apparently you are not reading this group too often. My proposal is
on the table a loooong time - get rid of unsecure reports - they
do not buy anything good anyway.

And just to refresh you and others memeory, I am attaching nice
desctiption of the problme posted by Uri not so long time ago.
He was responding to  R.G. Mundy.

> Either put up or shut up.

If we are talking aout ideas and solutions I have no problems to
put up, what about you ?

> bok

Aleksey
========================================================================

: From [email-masked]  Sun Sep 21 02:05:14 1997
: Received: from igw3.watson.ibm.com by world.std.com (5.65c/Spike-2.0)
: 	id AA16477; Sat, 20 Sep 1997 22:05:21 -0400
: Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA15320; Sat, 20 Sep 1997 22:05:15 -0400
: Received: from v9n4fi0.watson.ibm.com (v9n4fi0.watson.ibm.com [9.2.122.13]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id WAA23000; Sat, 20 Sep 1997 22:05:14 -0400
: Received: by v9n4fi0.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96)
:           id AA49362; Sat, 20 Sep 1997 22:05:14 -0400
: From: Uri Blumenthal <[email-masked]>
: Message-Id: <[email-masked]>
: Subject: Re: "Secure" Reports (was:Re: Delayed/Revised I-D release Date)
: To: [email-masked] (G R Mundy)
: Date: Sat, 20 Sep 1997 22:05:14 -0400 (EDT)
: Cc: [email-masked], [email-masked] (Uri Blumenthal)
: In-Reply-To: <[email-masked]> from "G R Mundy" at Sep 19, 97 05:13:52 pm
: Reply-To: [email-masked]
: X-Mailer: ELM [version 2.4 PL25]
: Content-Type: text
: Status: RO
: 
: One big argument for the reports  [back when  adding those was 
: discussed] was:  "Now if you mistyped your password, you don't
: have to wait three minutes and then guess whether the password
: was incorrect, or your packet hasn't made it through, or maybe
: the response was lost."  
: 
: Of course, securing report "Wrong digest" makes little sense, 
: because if it's mistyped password that we worry about, the 
: report won't be authenticate-able anyway (guess why :-).
: 
: When there are no hostiles with capabilities to transmit on the 
: wire (i.e. the highest threat level is eavesdropping), insecure 
: reports have no undesirable side-effects. 
: 
: But this is not a realistic picture.
: 
: Imagine me on the wire, listening to your communications with your 
: agents. At some point when I see you sending a request to an agent,
: I immediately send to you (spoof) a report message as-if from that 
: agent, saying "Wrong Digest" (with the correct message-ID etc).
: 
: As a manager (NMS), what are you going to do?  [Note: the number of
: choices isn't overwhelming.]
: 
: Naturally I can watch your reaction and fine-tune the attack.
: In general, it is of the denial-of-service class and nothing 
: more. However, the ease of mounting it does mean our results 
: are less than superb. Plus, see below.
: 
: > This illustration does not provide any compelling reason to "secure
: > all reports".
: 
: It is not feasible to secure them all, regardless. In the above
: example, what is one supposed to do, receiving a "Wrong Digest"
: report that doesn't authenticate correctly? Is it a spoof or is 
: my password mistyped,  or were both  the request and the report 
: damaged en-route? Your action?
: 
: >   - The first assumption seems to be that an implementation and/or
: > operational use cannot be "more secure" than what is required by the
: > specs.  If users want to make greater use of the available
: > cryptographic mechanisms because of their operational environment,
: > there is nothing in the specs prevents that.
: 
: Would you care to amplify? What mechanisms did you have in mind? To
: the best of my knowledge, there are no applicable cryptographic 
: mechanisms  [plus, it used to be SNMP position not to rely 
: on any outside service, cryptographic or otherwise].
: 
: > ...attackers will be able predict the specific reaction of management
: > station software (& possibly the human operator reaction to the
: > software reaction)....
: 
: There are rather few choices and they're all easily observed on the wire.
: 
: > -- It would be difficult for an attacker to know the reaction of a
: > specific management station software package to a particular incoming
: > report.  
: 
: Easily determined by spoofing such report and observing the reaction.
: 
: >     -- If a successful attack required the operator to take a specific
: > action, this would be even harder to predict than the management
: > station software reaction.
: 
: (a) set of reasonable actions is usually very limited, plus the choice
: is often clear from watching the subsequent traffic; and (b) success
: here means more than a simple denial-of-service - but a combination 
: attack [i.e. attack on SNMP expecting a certain (possibly verifiable) 
: reaction from the operator, exploitable in a parallel attack using
: another protocol].
: 
: >     -- An operational use that is concerned with meeting certain
: > security requirements should not permit the use of a lower
: > securityLevel (even if the operator tries).
: 
: >From SNMP point of view,  report-related attacks appear to be only of
: denial-of-service class. However,the highest security level provided
: by SNMPv3 does not foil these. Plus, what may be denial-of-service
: only for SNMP, can be a part of a wider attack, crossing over 
: more than one protocol.
: 
: > If there is something we're missing perhaps a better description of
: > your concern or different illustration will clarify things.
: 
: I don't think it's practical (or even possible) to completely foil
: denial-of-service attacks. However, the concern here is that we're
: making it too easy to mount a successful attack on SNMPv3 NMS.
: 
: > > I think it is really simple to fix reports, there is simple no will to 
: > > do it - I feel the reason is that some of you just fall in love with
: > > the concept.
: 
: How do you propose to fix them? Can you explain "while I'm standing
: on one foot"?
: -- 
: Regards,
: Uri		[email-masked]
: -=-=-=-=-=-=-
: <Disclaimer>
: 
: