Hi Ulrich,

A SNMP entity is any command generator or command responder instance. An 
instance of org.snmp4j.Snmp is a SNMP entity too.

Bes regards,
Frank

> On 8. Aug 2018, at 09:16, ulrich berl <ulrich.b...@gmx.net> wrote:
> 
> Hi Frank,
>  
> Thanks for your explanation.
>  
>>>> With non-localised users, you can use a single user entry for several SNMP 
>>>> entities. To be able to do so,
> the agent must know the passphrase which is stored unencrypted in the local 
> persistent storage.
>  
> What exactly do you mean by 'SNMP entities' ? Is this an instance of class 
> org.snmp4j.Snmp ?
> In this sentence the 'agent' is the SnmpManager ?
> 
>>>> With localised users, you will not have this security drawback. The stored 
>>>> key, is only usable with a target it has been localised for.
> No passphrase is stored persistently (only the localised key).
> 
> Yep, i saw this during debugging of a snmp request.
>  
>>>> You can mix both approaches too, but that would require more additional 
>>>> management overhead, because localised instances of a generic user need to 
>>>> be explicitly deleted if the generic user is updated.
> Thats the case using snmp.getUSM().addUser(...): user must be removed in case 
> of update.
>  
> br, Ulrich
>  
> 
> Gesendet: Dienstag, 07. August 2018 um 19:46 Uhr
> Von: "Frank Fock" <f...@agentpp.com <mailto:f...@agentpp.com>>
> An: "ulrich berl" <ulrich.b...@gmx.net <mailto:ulrich.b...@gmx.net>>
> Cc: snmp4j@agentpp.org <mailto:snmp4j@agentpp.org>
> Betreff: Re: [SNMP4J] Consecutive SNMPv3 GET Requests using same User
> Hi Ulrich,
> 
> If you need highest security, then use localised users only.
> With non-localised users, you can use a single user entry for several SNMP 
> entities. To be able to do so,
> the agent must know the passphrase which is stored unencrypted in the local 
> persistent storage.
> 
> With localised users, you will not have this security drawback. The stored 
> key, is only usable with a target it has been localised for.
> No passphrase is stored persistently (only the localised key).
> 
> SNMP4J offers both approaches, users have to choose which one best fits to 
> their requirements.
> You can mix both approaches too, but that would require more additional 
> management overhead, because localised instances of a generic user need to be 
> explicitly deleted if the generic user is updated.
> 
> Best regards,
> Frank
> 
> 
>> On 7. Aug 2018, at 14:30, ulrich berl <ulrich.b...@gmx.net> wrote:
>> 
>> Take the following:
>> 
>> A SnmpManager application creates one (global) instance of class 
>> org.snmp4j.Snmp after startup.
>> 
>> SnmpManager application will do consecutive SNMPv3 GET Requests (sysDescr) 
>> with user MD5 using global snmp instance.
>> The authPassphrase for user MD5 is changeable between GET Requests.
>> 
>> 
>> If i do an snmp.getUSM().addUser(...) in the getRequest(...):
>> 
>> [OK] Request 1 - CorrectAuthPassphrase -> sysDescr returned
>> --- change authPassphrase in SnmpManager application
>> [NOK] Request 2 - WrongAuthPassphrase -> sysDescr returned <-- should be an 
>> authentication failure
>> 
>> 
>> If i do an snmp.getUSM().addLocalizedUser(...) in the getRequest(...):
>> 
>> [OK] Request 1 - CorrectAuthPassphrase -> sysDescr returned
>> --- change authPassphrase in SnmpManager application
>> [OK] Request 2 - WrongAuthPassphrase -> error
>> 
>> So for such an application i should always use localized users 
>> (https://oosnmp.net/confluence/pages/viewpage.action?pageId=1441800) or 
>> clearing the user table before next request ?
>> What about the snmp.getUSM().addUser(...) method - when to use this method ?
>> 
>> br, Ulrich
>> 
>> 
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J@agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j[https://oosnmp.net/mailman/listinfo/snmp4j
>>  
>> <https://oosnmp.net/mailman/listinfo/snmp4j[https://oosnmp.net/mailman/listinfo/snmp4j>]

_______________________________________________
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j

Reply via email to