Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 14 Apr 2005 17:59:13 -0400

Please see below.

>>>>> "Blumenthal" == Blumenthal, Uri <[email-masked]> writes:

    Blumenthal> Please point me at the reference in the SNMPv3 RFCs
    Blumenthal> that says anything about credentials that SNMP engine
    Blumenthal> *itself* has - as opposite to storing credentials for
    Blumenthal> *users* that are allowed to talk to this engine.

> I think you are perhaps a bit too focused on USM here.

Not USM as much as SNMPv3 in general. But your point is taken.

> The premis of this working group is that people have infrastructure
> today that has credentials.  They would like to use that
> infrastructure to secure SNMP engines.  They have described several
> such infrastructures.

It's the relation between those infrastructures and SNMP identities, and
mapping to SNMP Access Control that is missing.

> In these infrastructures--at least in the infrastructures I mentioned
> in my previous message--an engine acting in one of these
> infrastructures has a natural credential to use.

I must have missed that message. What infrastructure is that, and what
credential is natural for SNMP engine in it?

> It's taken as a given within the scope of this working group that
> USM--particularly USM's credential model--does not meet deployment
> needs.

Deployment needs long-term credentials to establish connections and
define their life-time, and short-term secrets to protect the traffic
itself. There has been much dissent wrt. existing long-term secrets
living indpendently of existing infrastructures, and lack of short-time
secrets. USM model can play reasonably well as traffic protector
(dissenting opinion points at its weakness in anti-replay).

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Apr 2005 12:56:51 -0400

>>>>> "Blumenthal," == Blumenthal, Uri <[email-masked]> writes:

    Blumenthal,> Please see below.
>>>>> "Blumenthal" == Blumenthal, Uri <[email-masked]>
    Blumenthal,> writes:

    >> I think you are perhaps a bit too focused on USM here.

    Blumenthal,> Not USM as much as SNMPv3 in general. But your point
    Blumenthal,> is taken.

    >> The premis of this working group is that people have
    >> infrastructure today that has credentials.  They would like to
    >> use that infrastructure to secure SNMP engines.  They have
    >> described several such infrastructures.

    Blumenthal,> It's the relation between those infrastructures and
    Blumenthal,> SNMP identities, and mapping to SNMP Access Control
    Blumenthal,> that is missing.

Yes, I agree that is part of a solution to the charter of this working
group.  You seem to believe that it will be the hardest part of the
solution/the part that drives a lot of other decisions.  I'm not sure
I would go that far.  I do agree it needs to be done and I do agree
some propoproposals in this WG have not focused on that at all.

    >> In these infrastructures--at least in the infrastructures I
    >> mentioned in my previous message--an engine acting in one of
    >> these infrastructures has a natural credential to use.

    Blumenthal,> I must have missed that message. What infrastructure
    Blumenthal,> is that, and what credential is natural for SNMP
    Blumenthal,> engine in it?

I can go dig up the message if you like, but I'd rather just reiterate
the infrastructures I was discussing.

In the ssh case, I'd expect one SNMP engine to have a host key and the
other to be acting as a user and thus have some username/password,
public key or something like that.

For Kerberos, I'd expect one SNMP engine to have a long-term service
key, and the other to have a TGT or something like that.

In the RADIUS case, I'd expect one SNMP engine to have a shared key
with the RADIUS infrastructure and the other to have a username and
password.  This case is actually a bit problematic for the
notification example.