Re: [Gen-art] [OPSAWG] Gen-ART LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt

[Brian E Carpenter]

On 2008-06-26 07:01, Randy Presuhn wrote:
> Hi -
> 
>> From: "Juergen Schoenwaelder" <[EMAIL PROTECTED]>
> ...
>> Sent: Wednesday, June 25, 2008 11:13 AM
>> Subject: Re: [OPSAWG] Gen-ART LC 
>> reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
> ... 
>> 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.
> 
> This looks fine to me.

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

   Brian
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [OPSAWG] Gen-ART LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt

[Juergen Schoenwaelder]

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

> > 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.
> 
> Though obviously not the same, I'd lump this in with RFC 3414's
> 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [OPSAWG] Gen-ART LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt

[Randy Presuhn]

Hi -

> From: "Juergen Schoenwaelder" <[EMAIL PROTECTED]>
...
> Sent: Wednesday, June 25, 2008 11:13 AM
> Subject: Re: [OPSAWG] Gen-ART LC 
> reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
... 
> 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.

This looks fine to me.

> > 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.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art