The SNMP architecture in RFC3411 has 'Abstract Service Interfaces' between 'Subsystems'. What we are talking about here is a possible 'extension point' within a specific Model implementing a specific Subsystem. I think these are different things and it remains unclear whether it is worth to define 'extension points' of Models (USM is a Model implementing the Security Subsystem Abstract Service Interface).
At least, we should not confuse 'Abstract Service Interfaces', 'Subsystems', 'Models' and 'extension points' (which is a new concept since so far Models do not have such plugin extension points). /js On Thu, Aug 28, 2014 at 01:33:54PM -0400, Sam Hartman wrote: > Hi. > > My concern in describing things as diffs to the md5 algorithm in 3414 s > that there's not a well defined abstraction there at that layer. > > The SNMP community has been very careful to define rules of procedure > and very well-defined interfaces afor extension and for variability in > SNMP. When we started work on the transport security model we > considered providing differences to the existing SNMP processing. > It would have been a lot less text. > However, we were not using proper SNMP extension points in doing so. > Extending SNMP only at its proper extension points helps in reasoning > about SNMP correctness, security, etc. > For the same reason abstraction helps you when coding, it helps you when > working on specifications for large complex systems. > > Authentication algorithms in USM are a valid extension point today. > However, as I read 3414, HMAC-based algorithms that work approximately > like hmac-md5 are *not* a well-defined extension point. > > I think it is important to create a new extension point that plugs into > the existing extension point of USM authentication algorithm and > provides hmac-based authentication with an extensible hash function. > > draft-hartman tries to do that today. draft-hmac does not. > > I think it is important for SNMP forward evolution that we do that and > only extend at maintainable extension points. > For that reason, regardless of which draft the working group chooses, I > believe it is important to first define a new extension point for > generic hmac-based authentication algorithms that plug into the USM > authentication algorithm extension point in 3414, and then to plug sha-2 > into that newly created extension point. > > --Sam > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
