Subject: RE: [Isms] proposal comparison I-D

From: "Martin Soukup" <[email-masked]>
Date: Tue, 15 Feb 2005 08:01:30 -0500

All,

In section 3.5 of the proposal evaluation, a comparison between the key
provisioning for an external authentication source (AAA server) and the goal
of ISMS is made. It should be noted that the provisioning of a single key
per device rather than a key per-user-per-device is of a significantly
different complexity. Also, there are numerous solutions and solutions in
progress to remove the need for this communication key provisioning for
standard external authentication protocols (e.g. Kerberos, RADIUS), and this
should appropriately be solved in the context of the AAA protocol and not
SNMP, IMO.

Martin.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Feb 2005 15:23:43 -0800

Hi -

(Sorry for the delay - I've been off-line since January.)

> From: "Martin Soukup" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, February 15, 2005 5:01 AM
> Subject: RE: [Isms] proposal comparison I-D
...
> different complexity.

During my discussions with non-SNMP people about USM and VACM,
I've found that many had an important misconception about how key
provisioning works, despite our best efforts in RFC 3415 appendix A
and RFC 3414 Appendix A.  One needs to "manually" key exactly ONE
user, known as "initial".  All other user creation and keying would be
done in-band with SNMPv3.

If someone is manually setting keys for any users other than "initial",
they're not doing things the way the WG intended when the SNMPv3
documents were developed.

>                        Also, there are numerous solutions and solutions in
...

The point in the evaluation is that AAA provisioning, (currently) requiring a
key to be set in every device, needs the same amount of manual work as
does using  SNMPv3 as it was designed to be used.  (Of course, some
people seem intent on making more work for themselves.)  You're absolutely
right that *solving* that is AAA's problem, not SNMP's.  The only thing I've
seen in the SNMP space to address the problem is leap-of-faith solutions
like the kick-start in RFC 2786.

Randy