On Tue, Feb 18, 2025 at 03:19:27PM +0530, Pushpa Thimmaiah wrote:
> Hi All,
>
> I would like to understand why does oid of AES128 and AES192 not in same
> branch.
> AES128 : .1.3.6.1.6.3.10.1.2.4
> AES192 : .1.3.6.1.4.1.14832.1.3
>
It has to do with timing and processes.
If you look up the OID's you see that .1.3.6.1.6.3.10.1.2.4 is defined in
SMIv2 - that is STD58 - and changing that document is a rather involved
process.
In order to get some kind of identifier out there faster a "private
organisation" (1.3.6.1.4.1) have defined some other values in order to,
as taken from the DESCRIPTION in their MIB
"The ESO Consortium is an umbrella organization for registration of
not-yet-standardized Simple Network Management Protocol (SNMP) security
modules in the enterprise space. The objects published here are intended to
provide a common naming and registration for authentication and privacy
protocol extensions to the SNMP User-based Security Model (USM)
Module (RFC3414). The authentication and privacy protocol objects specified
herein are intended to be used as values for usmUserAuthProtocol and
usmUserPrivProtocol when managing SNMPv3 users via the snmpUsmMIB."
but it seems as if they (SNMP research?) stopped pushing new values towards
IETF at some point and decided to just use their own values.
In our source code we have the following:
#ifdef NETSNMP_DRAFT_BLUMENTHAL_AES_04
/* OIDs from http://www.snmp.com/eso/esoConsortiumMIB.txt */
const oid usmAES192PrivProtocol[9] = { 1,3,6,1,4,1,14832,1,3 };
const oid usmAES256PrivProtocol[9] = { 1,3,6,1,4,1,14832,1,4 };
/* OIDs from CISCO MIB */
const oid usmAES192CiscoPrivProtocol[11] = { 1,3,6,1,4,1,9,12,6,1,1 };
const oid usmAES256CiscoPrivProtocol[11] = { 1,3,6,1,4,1,9,12,6,1,2 };
/*
* these OIDs are in pySNMP source as OIDs for AES+Reeder. We'll just
* use OIDS from CISCO-SNMP-USM-OIDS-MIB
*
const oid usmAES192Cisco2PrivProtocol[11] = { 1,3,6,1,4,1,9,12,6,1,101 };
const oid usmAES256Cisco2PrivProtocol[11] = { 1,3,6,1,4,1,9,12,6,1,102 };
*/
#endif /* NETSNMP_DRAFT_BLUMENTHAL_AES_04 */
where you can see that ESO have defined AES-192 once and Cisco have done it
twice as they seem to have teo variations of it.
Now, given the above code it looks like net-snmp should recognize
.1.3.6.1.4.1.14832.1.3 if it is configured that way. The easiest way to
check is by means of running
snmptrap --help
and look at the -x option, if it lists AES-192 then it should be there.
> I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x. as OID
> of AES192.
> Does snmptrap receiver recognise OID 1.3.6.1.4.1.4976.2.2.x.x.x. as
> AES192?
1.3.6.1.4.1.4976 is agentpp, another snmp implementor, just like net-snmp and
snmp reserch, I found a copy of their MIB on
https://github.com/brettwooldridge/snmp4j/blob/master/mibs/OOSNMP-USM-MIB.txt
and it does in deed declare yet another value for the supposedly same thing,
but in a less proper way.
Net-SNMP does not, as far as I know, recognize the agentpp definition.
/MF
I have always been surprised by the willingness to try to enumerate the
world that people show.
>
> Thank you,
> 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
