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=
 &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">magfr@lysato=
r.liu.se</a>&gt; 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>
&gt; Hi All,<br>
&gt; <br>
&gt; I would like to understand why does oid of AES128 and AES192 not in sa=
me<br>
&gt; branch.<br>
&gt; AES128=C2=A0 : .1.3.6.1.6.3.10.1.2.4<br>
&gt; AES192 : .1.3.6.1.4.1.14832.1.3<br>
&gt; <br>
<br>
It has to do with timing and processes.<br>
<br>
If you look up the OID&#39;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 &quot;priv=
ate<br>
organisation&quot; (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>
&quot;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.&quot;<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&#39;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>
&gt; I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x.=C2=
=A0 as OID<br>
&gt; of AES192.<br>
&gt; 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>
&gt; 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>
&gt; <br>
&gt; Thank you,<br>
&gt; Pushpa.T<br>
<br>
<br>
&gt; _______________________________________________<br>
&gt; Net-snmp-coders mailing list<br>
&gt; <a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a><br>
&gt; <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==--