Subject: [Gen-art] Gen-ART LC review of draft-ietf-opsawg-snmp-engineid-discovery-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jun 2008 13:41:35 +1200

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2008 09:23:00 +0200

On Wed, Jun 25, 2008 at 01:41:35PM +1200, Brian E Carpenter wrote:

> I have been selected as the General Area Review Team (Gen-ART) reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> Please resolve these comments along with any other Last Call comments
> you may receive.
> Document: draft-ietf-opsawg-snmp-engineid-discovery-02.txt
> Reviewer: Brian Carpenter
> Review Date: 2008-06-25
> IETF LC End Date: 2008-06-30
> IESG Telechat date: (if known)
> 
> Summary: Almost ready
> 
> Comments: 
> 
> ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

easy fix
 
> 5.  Security Considerations
> ...
>    If a device configuration permits non-secure SNMPv1/v2c access to a
>    target system, then reading the snmpEngineID variable of the SNMP-
>    FRAMEWORK-MIB will also reveal a suitable contextEngineID value for
>    subsequent SNMPv3 usage.  However, implementations should not rely on
>    non-secure SNMPv1/v2c access and therefore MUST implement this
>    specification to enable secure contextEngineID discovery.
> 
> This is a little odd, since, as the previous paragraph indicates,
> the localEngineID mechanism is not intrinsically secure. I think the
> second sentence should be extended to:
> 
>                              However, implementations should not rely on
>    non-secure SNMPv1/v2c access and therefore MUST implement this
>    specification to enable secure contextEngineID discovery whenever
>    an SNMPv3 security mechanism is in use.

The paragraph in question establishes an implementation requirement.
Your proposed addition "whenever an SNMPv3 security mechanisms is in
use" hints to a deployment decision, which for me does not go along
with an implementation requirement.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 Jun 2008 09:52:42 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Brian E Carpenter" <[email-masked]>
> Cc: "General Area Review Team" <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Sent: Wednesday, June 25, 2008 12:23 AM
> Subject: Re: [OPSAWG] Gen-ART LC reviewof draft-ietf-opsawg-snmp-engineid-discovery-02.txt
...
> with an implementation requirement.

I have another problem with both versions of the text in question:
both versions seem to imply that one must not use the USM method for
discovery, referenced in the last paragraph of section 2 of the draft, and
in contradiction to the first paragraph of section 3.2.  I think the statements
about when this technique MUST be implemented and SHOULD be used
need to be more carefully scoped.

BTW, I admit to being a bit baffled by the second paragraph of the security
considerations section - why are we worried about attackers learning
snmpEngineID values?  Just exactly what attack would having this
information facilitate?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2008 20:13:05 +0200

On Wed, Jun 25, 2008 at 09:52:42AM -0700, Randy Presuhn wrote:
 
> discovery, referenced in the last paragraph of section 2 of the
> draft, and in contradiction to the first paragraph of section 3.2.
> I think the statements about when this technique MUST be implemented
> and SHOULD be used need to be more carefully scoped.

Any suggestion how to fix this? Would if be sufficient to add "if a
security model does not provide a suitable discovery mechanism for
contextEngineIDs", that is:

   If a device configuration permits non-secure SNMPv1/v2c access to a
   target system, then reading the snmpEngineID variable of the SNMP-
   FRAMEWORK-MIB will also reveal a suitable contextEngineID value for
   subsequent SNMPv3 usage.  However, implementations should not rely
   on non-secure SNMPv1/v2c access and therefore MUST implement this
   specification to enable secure contextEngineID discovery if a
   security model does not provide a suitable discovery mechanism for
   contextEngineIDs.
 
> BTW, I admit to being a bit baffled by the second paragraph of the
> security considerations section - why are we worried about attackers
> learning snmpEngineID values?  Just exactly what attack would having
> this information facilitate?

Depending on how the snmpEngineID is constructed, it may contain the
enterprise ID identifying the device manufacturer or it may contain a
MAC address which is otherwise not accessibe (and which also gives a
hint about the manufacturer), or it might contain an administratively
assigned text that might be useful to further target an attack.

Is this something to be seriously worried about? I can't judge. Do we
have such text in USM RFC 3414? Obviously not. Is the fact that USM is
silent about this sufficient to not be worried? Again, I can't judge.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 Jun 2008 12:01:46 -0700

Hi -

...
> Sent: Wednesday, June 25, 2008 11:13 AM
> Subject: Re: [OPSAWG] Gen-ART LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
... 
>    security model does not provide a suitable discovery mechanism for

This looks fine to me.

> silent about this sufficient to not be worried? Again, I can't judge.

Though obviously not the same, I'd lump this in with RFC 3414's
commentary on traffic analysis attacks.  The recommended VACM
configuration in appendix A of RFC 3415 gives noAuthNoPriv read
access to this information anyway.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2008 22:02:41 +0200

On Wed, Jun 25, 2008 at 12:01:46PM -0700, Randy Presuhn wrote:

> commentary on traffic analysis attacks.

Well, as you said, this is not the same. ;-)

> The recommended VACM configuration in appendix A of RFC 3415 gives
> noAuthNoPriv read access to this information anyway.

Not necessarily if you choose an "initial-no-access-configuration" (or
I am misreading the A.1 item 5).

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Jun 2008 09:13:39 +1200

>>    security model does not provide a suitable discovery mechanism for

I agree. That was the intention of my suggested change (but as Juergen
noted, it can be read differently).

   Brian

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 Jun 2008 15:06:36 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "General Area Review Team" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 25, 2008 1:02 PM
> Subject: Re: [OPSAWG] Gen-ART LCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
...
> I am misreading the A.1 item 5).

True, though the "initial-no-access-configuration" is in some ways a
pathological case.  It begs the question of how the system *ever*
comes to be managed.  :-)

I'm still not persuaded that SnmpEngineIDs should be regarded as
sensitive information in general.  With USM, they show up on  the
wire in the clear, perhaps revealing the most in the case of notifications.
(msgAuthoritativeEngineID in the UsmSecurityParameters carried
as msgSecurityParameters of SNMPv3Message)

Randy

---

From: "David Harrington" <[email-masked]>
Date: Thu, 26 Jun 2008 08:56:14 +0800

Hi,

Just a touch of perspective.

I joined the SNMP community because SNMPv2-party was so secure,
network management applications would no longer be able to do
autodiscovery of SNMP-capable devices. The autodiscovery we wanted to
be able to do included being able to detect what type of device it was
we were talking to, so we better understood how to monitor and manage
it. 
An attacker might benefit from knowing the type of device as well, so
they can better understand how to attack it. 

When doing autodiscovery, we typically used sysObjectID, not
snmpEngineID. I think the system group is still recommended to be
accessible via noAuthNoPriv, so I can already learn most of what an
snmpEngineID might reveal via other accessible objects.

>From my point of view, and I think it was consensus, the snmpEngineID
is meant to be accessible via noAuthNoPriv so even SNMPv1/2c
implementatins that implement this MIB could be identified independent
of the currently-assigned IP address. (I know the reality is that all
the application developers who identified nodes by IP address did not
change their applications to use engineIDs, but that was part of the
original purpose).

I think the benefit to operators is greater than the risk of giving
the same benefit to attackers. I am not convinced this information is
sensitive.

How about "Making this accessible via noAuthNoPriv will benefit
legitimate tools that try to algorithmically determine some basic
information about the device. This information may also benefit
attackers trying to fine-tune their attacks. The information exposed
can usually be gotten through traffic analysis. For interoperability,
we RECOMMEND making this information accessible using noAuthNoPriv."

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Thursday, June 26, 2008 6:07 AM
> To: General Area Review Team; [email-masked]; 
> [email-masked]
> Subject: Re: [OPSAWG] 
> Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
> 
> Hi -
> 
> > Cc: "General Area Review Team" <[email-masked]>; 
> <[email-masked]>; 
> > Subject: Re: [OPSAWG] Gen-ART 
> LCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
> ...
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jun 2008 09:59:30 +0200

> the same benefit to attackers. I am not convinced this information is

I though security considerations should spell out potential risks so
that people deploying technology can think about them and take an
informed decision. How can we claim that we understand the benefit
risk trade-offs?

An an editor, I need to understand the WG consensus. I currently see
three options on the table:

a) document the potential information leakage associated with
   snmpEngineID discovery

b) declare that this potential information leakage is a feature that
   is RECOMMENDED to support

c) remove all discussion about this issue and simply stay silent,
   following the spirit of the USM standard

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Jun 2008 10:36:52 +0200

Speaking as a contributor I support option b) - (actually a+b) 

Dan

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, June 26, 2008 11:00 AM
> To: David Harrington
> Cc: 'General Area Review Team'; [email-masked]; 
> Subject: Re: 
> [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-disco
> very-02.txt
> 
> I though security considerations should spell out potential 
> risks so that people deploying technology can think about 
> them and take an informed decision. How can we claim that we 
> understand the benefit risk trade-offs?
> 
> An an editor, I need to understand the WG consensus. I 
> currently see three options on the table:
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 26 Jun 2008 17:57:46 +0800

a+b

dbh 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, June 26, 2008 4:00 PM
> To: David Harrington
> Cc: 'Randy Presuhn'; 'General Area Review Team'; 
> [email-masked];

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 26 Jun 2008 10:56:38 -0700

Hi -

> To: "David Harrington" <[email-masked]>
> Cc: "'Randy Presuhn'" <[email-masked]>; "'General Area Review Team'" <[email-masked]>; <[email-masked]>;
> Sent: Thursday, June 26, 2008 12:59 AM
> Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
...
> a) document the potential information leakage associated with

perhaps with a note that this information can get out in other ways

>    is RECOMMENDED to support

 I'd quibble with the "to support" - we're not talking about
an implementation decision, but rather a deployment / usage decision,
since the VACM configuration is what would determine how much "leaks",
beyond what the protocol itself exposes.

...

So I agree in spirit with a+b

Randy