Hi Pushpa,
  Yes, your results were expected. They use the same encryption algorithm
but are identified under either the Cisco or ESO enterprise OID.  There is
probably no way of knowing in advance which one a particular piece of
equipment will use.

 - Craig



On Tue, 21 Sept 2021 at 04:22, Pushpa Thimmaiah <pushpa.thimma...@gmail.com>
wrote:

> Hi Craig,
>
> Following are my observations. Please let me know if the behaviour is
> correct.
>
> ----------snmp agent
> 192.168.1.12-------------------------------------------
> I added two snmpv3 users
> createUser pushaaes129 SHA mypassword AES192 mypassword
> createUser pushaaes129c SHA mypassword AES192C mypassword
>
> --------snmp manager  192.168.1.13 --------------------------
> pushpat@pushpat-ThinkPad-L480:~$ snmpget -D -t50  -v3 -u pushaaes129c -l
> authPriv -a SHA1 -A mypassword -x *AES192C* -X mypassword 192.168.1.12
> SNMPv2-MIB::sysDescr.0
> registered debug token t50, 0
> SNMPv2-MIB::sysDescr.0 = STRING: Microsemi
> pushpat@pushpat-ThinkPad-L480:~$ snmpget -D -t50  -v3 -u pushaaes129c -l
> authPriv -a SHA1 -A mypassword -x* AES192 *-X mypassword 192.168.1.12
> SNMPv2-MIB::sysDescr.0
> registered debug token t50, 0
> Timeout: No Response from 192.168.1.12.
> pushpat@pushpat-ThinkPad-L480:~$
>
> I thought AES192, AES192C are same. It looks like they are not. Any idea
> when to use AES192 and AES192C(cisco algorithm)
>
>
>
>
> =========== USM entries in snmp agent persistent
> config=================================
> usmUser 1 3 0x<engineid> "pushaaes129" "pushaaes129"   NULL
> .1.3.6.1.6.3.10.1.1.3 0x837954cd0cadfa4c198f22bf7b1b15db1141b8b1
> .1.3.6.1.4.1.14832.1.3  0x837954cd0cadfa4c198f22bf7b1b15db1141b8b18f973286
> 0x
> usmUser 1 3 0x<engineid> "pushaaes129c" "pushaaes129c" NULL
> .1.3.6.1.6.3.10.1.1.3 0x837954cd0cadfa4c198f22bf7b1b15db1141b8b1
> .1.3.6.1.4.1.9.12.6.1.1 0x837954cd0cadfa4c198f22bf7b1b15db1141b8b15aeeb711
> 0x
>
> .1.3.6.1.4.1.9.12.6.1.1 : iso(1) identified-organization(3) dod(6)
> internet(1) private(4) enterprise(1) cisco(9)
> .1.3.6.1.4.1.14832.1.3  : iso(1) org(3) dod(6) internet(1) private(4)
> enterprise(1) esoConsortiumMIB(14832)
>
>
>
>
> On Thu, Sep 16, 2021 at 5:07 AM Craig Small <csm...@dropbear.xyz> wrote:
>
>> Hi Pushpa,
>>   It's a matter of identifying it.
>>
>> When the packet comes in, the receiver looks at the authentication
>> protocol and sees one value or the other. That's why you need to specify
>> which method you are using.
>> In theory, I expect that the receiver could just look at the auth
>> protocol and use the same method for both values, but they don't.
>>
>>  - Craig
>>
>>
>> On Wed, 15 Sept 2021 at 15:44, Pushpa Thimmaiah <
>> pushpa.thimma...@gmail.com> wrote:
>>
>>> Hi Craig Small,
>>>
>>> Thank you . This is really helpful.
>>> If AES192 and AES192C are AES standard from different entity  then are
>>> they interchangeable ?
>>> Eg: I did configure AES192 on snmpd and use AES192C from mibbrowser.
>>> Tool 'snmpget'  fails.
>>>
>>> It would help me if I know why CFB-AES192 (on silvercreek browser)
>>> fails  with AES192 configured on snmp-agent.  It works fine when AES192C
>>> configured on snmpd.
>>>
>>>
>>> On Wed, Sep 15, 2021 at 4:10 AM Craig Small <csm...@dropbear.xyz> wrote:
>>>
>>>> Hi Pushpa,
>>>>   As you have discovered, there are two AES192 standards.
>>>>
>>>> When you select AES192 (with no C) this is the IETF draft Blumenthal
>>>> standard.
>>>>
>>>> When you select AES192C this is the Cisco "standard".
>>>>
>>>> What is the actual difference? As far as I can tell, it comes down to
>>>> the OID used for some of the parameters like the IV.
>>>>
>>>> The Cisco standard uses something under enterprises.Cisco, as you would
>>>> expect, while the draft IETF standard uses something under enterprises.ESO
>>>> ESO is Extended Security Options consortium, you can see their MIB at
>>>> http://www.snmp.com/eso/esoConsortiumMIB.txt
>>>>
>>>> To me, it looks like the same protocol, just how it identifies itself
>>>> and where it stores things changes. So it's not like one is doing CFB and
>>>> the other thought for some reason ECB was the way to go.
>>>>
>>>> If you look online for SNMP and AES 192 or 256, you can see this
>>>> confuses a bunch of people (e.g. AES192 works for device X, but not device
>>>> Y, why?)
>>>>
>>>>  - Craig
>>>>
>>>> ObXKCD https://xkcd.com/927/
>>>>
>>>>
>>>> On Wed, 15 Sept 2021 at 01:51, Pushpa Thimmaiah <
>>>> pushpa.thimma...@gmail.com> wrote:
>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I am using SilverCreek as mib browser(windows10)  and net-snmp-.5.9 on
>>>>> snmp-agent(linux).
>>>>>
>>>>> *snmp-agent*
>>>>> creatUser testmd5aes192 MD5  testingauth AES192 testingpriv
>>>>>
>>>>> *SilverCreek*
>>>>> It provides CFB-AES192 option for privprotocol . So I selected
>>>>> authprotocol as 'MD5' and priv protocol 'CFB-AES192'
>>>>> snmpquery on fails for this
>>>>>
>>>>> So, I  changed AES192 to AES192C at snmp-agent side as mentioned below
>>>>> and it works
>>>>> creatUser testmd5aes192 MD5  testingauth AES192C testingpriv
>>>>>
>>>>> Kindly let me know when to use AES192 and AES192C. Is it based on
>>>>> cipher methods of AES?
>>>>>
>>>>> Thanks,
>>>>> Pushpa.T
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Net-snmp-coders mailing list
>>>>> Net-snmp-coders@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>>>>
>>>>
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to