Re: Regarding OID of AES192
Pushpa Thimmaiah <[email protected]> Wed, 19 Feb 2025 11:54:34 +0530
| Newsgroups | gmane.network.net-snmp.devel |
|---|---|
| Message-ID | <CAASqVJVPoGs_z8w23Bbw7gRDkkb-XzjnrZeuuDG2WKNm-Vr9Pw@mail.gmail.com> |
--===============4089406256272912285== Content-Type: multipart/alternative; boundary="000000000000e7dff5062e789ca4" --000000000000e7dff5062e789ca4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you Menase, Laurent, Craig Small and Magnus Fromreide. I am using snmp4j as snmp-agent and snmptrapd as trap-receiver. I would like to know how snmptrapd can be configured to authenticate AES192 of snmp4j ? If company develop support for AES192 then how will the generic snmp-manager(snmptrapd) can recognize the protocol.. I have seen that if snmpagent using AES192C in snmpv3traps and snmp-manager configured with AES192 then manager will not authenticate traps-with-AES192C. Thanks, Pushpa.T On Wed, Feb 19, 2025 at 8:50=E2=80=AFAM Magnus Fromreide <[email protected]= .se> wrote: > 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 sam= e > > 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 specifi= ed > 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 towar= ds > 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] =3D { 1,3,6,1,4,1,14832,1,3 }; > const oid usmAES256PrivProtocol[9] =3D { 1,3,6,1,4,1,14832,1,4 }; > /* OIDs from CISCO MIB */ > const oid usmAES192CiscoPrivProtocol[11] =3D { 1,3,6,1,4,1,9,12,6,1,1 }; > const oid usmAES256CiscoPrivProtocol[11] =3D { 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] =3D { 1,3,6,1,4,1,9,12,6,1,101= }; > const oid usmAES256Cisco2PrivProtocol[11] =3D { 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 O= ID > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > > --000000000000e7dff5062e789ca4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi,</div><div><br></div><div>Thank you <span><span>Me= nase, Laurent,=C2=A0 <span><span>Craig Small and <span><span>Magnus Fromrei= de.</span></span></span></span></span></span></div><div><span><span><span><= span><span><span><br></span></span></span></span></span></span></div><div><= div><span><span><span><span><span><span><br></span></span></span></span></s= pan></span></div><div><span><span><span><span><span><span>I am using=C2=A0 = snmp4j=C2=A0 as snmp-agent and snmptrapd as trap-receiver.=C2=A0 I=C2=A0 wo= uld like to know how=C2=A0 snmptrapd can be configured to authenticate AES1= 92 of snmp4j ?<br></span></span></span></span></span></span></div><div><spa= n><span><span><span><span><span>If company develop support for AES192 then = how will=C2=A0 the generic snmp-manager(snmptrapd) can recognize the protoc= ol..<br></span></span></span></span></span></span></div><div><span><span><s= pan><span><span><span><br></span></span></span></span></span></span></div><= span><span><span><span><span><span></span></span></span></span></span></spa= n></div><div><span><span><span><span><span><span>I have seen that if snmpag= ent using AES192C in snmpv3traps and snmp-manager configured with AES192 th= en manager will not authenticate traps-with-AES192C.</span></span></span></= span></span></span></div><div><span><span><span><span><span><span><br></spa= n></span></span></span></span></span></div><div><span><span><span><span><sp= an><span>Thanks,</span></span></span></span></span></span></div><div><span>= <span><span><span><span><span>Pushpa.T<br></span></span></span></span></spa= n></span></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Wed, Feb 19, 2025 at 8:50=E2=80=AFAM Magnus Fromreide= <<a href=3D"mailto:[email protected]" target=3D"_blank">magfr@lysato= r.liu.se</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex">On Tue, Feb 18, 2025 at 03:19:27PM +0530, Pushpa Thimmaiah wrote:<b= r> > Hi All,<br> > <br> > I would like to understand why does oid of AES128 and AES192 not in sa= me<br> > branch.<br> > AES128=C2=A0 : .1.3.6.1.6.3.10.1.2.4<br> > AES192 : .1.3.6.1.4.1.14832.1.3<br> > <br> <br> It has to do with timing and processes.<br> <br> If you look up the OID's you see that .1.3.6.1.6.3.10.1.2.4 is defined = in<br> SMIv2 - that is STD58 - and changing that document is a rather involved<br> process.<br> <br> In order to get some kind of identifier out there faster=C2=A0 a "priv= ate<br> organisation" (1.3.6.1.4.1) have defined some other values in order to= ,<br> as taken from the DESCRIPTION in their MIB<br> <br> "The ESO Consortium is an umbrella organization for registration of<br= > not-yet-standardized Simple Network Management Protocol (SNMP) security<br> modules in the enterprise space. The objects published here are intended to= <br> provide a common naming and registration for authentication and privacy<br> protocol extensions to the SNMP User-based Security Model (USM)<br> Module (RFC3414). The authentication and privacy protocol objects specified= <br> herein are intended to be used as values for usmUserAuthProtocol and<br> usmUserPrivProtocol when managing SNMPv3 users via the snmpUsmMIB."<br= > <br> but it seems as if they (SNMP research?) stopped pushing new values towards= <br> IETF at some point and decided to just use their own values.<br> <br> In our source code we have the following:<br> <br> #ifdef NETSNMP_DRAFT_BLUMENTHAL_AES_04<br> =C2=A0 =C2=A0 /* OIDs from <a href=3D"http://www.snmp.com/eso/esoConsortium= MIB.txt" rel=3D"noreferrer" target=3D"_blank">http://www.snmp.com/eso/esoCo= nsortiumMIB.txt</a> */<br> const oid usmAES192PrivProtocol[9] =3D { 1,3,6,1,4,1,14832,1,3 };<br> const oid usmAES256PrivProtocol[9] =3D { 1,3,6,1,4,1,14832,1,4 };<br> =C2=A0 =C2=A0 /* OIDs from CISCO MIB */<br> const oid usmAES192CiscoPrivProtocol[11]=C2=A0 =3D { 1,3,6,1,4,1,9,12,6,1,1= };<br> const oid usmAES256CiscoPrivProtocol[11]=C2=A0 =3D { 1,3,6,1,4,1,9,12,6,1,2= };<br> /*<br> =C2=A0* these OIDs are in pySNMP source as OIDs for AES+Reeder. We'll j= ust<br> =C2=A0* use OIDS from CISCO-SNMP-USM-OIDS-MIB<br> =C2=A0*<br> const oid usmAES192Cisco2PrivProtocol[11]=C2=A0 =3D { 1,3,6,1,4,1,9,12,6,1,= 101 };<br> const oid usmAES256Cisco2PrivProtocol[11]=C2=A0 =3D { 1,3,6,1,4,1,9,12,6,1,= 102 };<br> =C2=A0*/<br> #endif /* NETSNMP_DRAFT_BLUMENTHAL_AES_04 */<br> <br> where you can see that ESO have defined AES-192 once and Cisco have done it= <br> twice as they seem to have teo variations of it.<br> <br> Now, given the above code it looks like net-snmp should recognize<br> .1.3.6.1.4.1.14832.1.3 if it is configured that way. The easiest way to<br> check is by means of running<br> <br> snmptrap --help<br> <br> and look at the -x option, if it lists AES-192 then it should be there.<br> <br> > I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x.=C2= =A0 as OID<br> > of AES192.<br> > Does snmptrap receiver=C2=A0 recognise OID=C2=A0 =C2=A01.3.6.1.4.1.497= 6.2.2.x.x.x. as<br> > AES192?<br> <br> 1.3.6.1.4.1.4976 is agentpp, another snmp implementor, just like net-snmp a= nd<br> snmp reserch, I found a copy of their MIB on<br> <br> <a href=3D"https://github.com/brettwooldridge/snmp4j/blob/master/mibs/OOSNM= P-USM-MIB.txt" rel=3D"noreferrer" target=3D"_blank">https://github.com/bret= twooldridge/snmp4j/blob/master/mibs/OOSNMP-USM-MIB.txt</a><br> <br> and it does in deed declare yet another value for the supposedly same thing= ,<br> but in a less proper way.<br> <br> Net-SNMP does not, as far as I know, recognize the agentpp definition.<br> <br> /MF<br> <br> I have always been surprised by the willingness to try to enumerate the<br> world that people show.<br> <br> > <br> > Thank you,<br> > Pushpa.T<br> <br> <br> > _______________________________________________<br> > Net-snmp-coders mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/net-snmp-coder= s" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists= /listinfo/net-snmp-coders</a><br> <br> </blockquote></div> --000000000000e7dff5062e789ca4-- --===============4089406256272912285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4089406256272912285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders --===============4089406256272912285==--