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

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 15 Apr 2005 14:20:45 -0400

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.

Sam, I'm only stating that these things require extra work, both by us -
architecting/designing it, *and* by customers (IT departments) that
deploy it. And it seems that the deployment efforts is exactly what
people are complaining about. 

> 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.

OK. SNMP engine generates an SSH key for itself (it can be certified
with extra work, or just accepted as today's SSH host keys are). Where
will SNMP engine get the user list? I mean - filling it is likely to be
as easy or difficult, as is filling the USM user table. How will
notifications be protected? By the SSH SNMP engine key itself?

> 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.

This seems easy. The only configuration for SNMP engine is its Kerberos
long-term shared-key. No need to fill the user list in advance.

Notifications are somewhat problematic: who to send it to, and under
what protection? Because in Kerberos model, users acquire tickets to
servers but not vs. versa (unless I'm out-of-date on how Kerberos works
- then please explain).

> 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.

I assume you mean "users have name and password with RADIUS", not with
SNMP engines (so user table doesn't have to be filled). Looks fine.
Notifications do cause some problem, like in Kerberos case.

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Apr 2005 14:32:11 -0400

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

    >> 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.

    Blumenthal,> Sam, I'm only stating that these things require extra
    Blumenthal,> work, both by us - architecting/designing it, *and*
    Blumenthal,> by customers (IT departments) that deploy it. And it
    Blumenthal,> seems that the deployment efforts is exactly what
    Blumenthal,> people are complaining about.

Agreed on all counts.

    >> 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.

    Blumenthal,> OK. SNMP engine generates an SSH key for itself (it
    Blumenthal,> can be certified with extra work, or just accepted as
    Blumenthal,> today's SSH host keys are). Where will SNMP engine
    Blumenthal,> get the user list? I mean - filling it is likely to
    Blumenthal,> be as easy or difficult, as is filling the USM user
    Blumenthal,> table. How will notifications be protected? By the
    Blumenthal,> SSH SNMP engine key itself?

I'd think RADIUS would be a good solution for this particularly because it can convey authorization informatino.

You probably actually want to use the key itself (in ssh publickey
mode) for notifications, but for gets/sets you will often end up using
username/password.  Backing the usernames/passwords with RADIUS seems
reasonable.

    >> 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.

    Blumenthal,> This seems easy. The only configuration for SNMP
    Blumenthal,> engine is its Kerberos long-term shared-key. No need
    Blumenthal,> to fill the user list in advance.

    Blumenthal,> Notifications are somewhat problematic: who to send
    Blumenthal,> it to, and under what protection? Because in Kerberos
    Blumenthal,> model, users acquire tickets to servers but not
    Blumenthal,> vs. versa (unless I'm out-of-date on how Kerberos

Ke    Blumenthal,> works - then please explain).

Kerberos has a model called user-to-user where you can get a ticket
for a user.  however I'd expect that most notification deployments
would have some long running service that you send the notifications
to.  I'd expect such a service to be a service in the Kerberos sense
as well and thus be something you could get a ticket for.

    >> 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.

    Blumenthal,> I assume you mean "users have name and password with
    Blumenthal,> RADIUS", not with SNMP engines (so user table doesn't
    Blumenthal,> have to be filled). Looks fine.  Notifications do
    Blumenthal,> cause some problem, like in Kerberos case.

No.  RADIUS is not a trusted third party protocol; it is a callout
protocol.  It allows one party (the command responder probably) to
avoid having a local username table but instead to use RADIUS.

However whether RADIUS is actually used is a local matter.  We
probably want to specify how to use RADIUS because for our solution to
be easy to deploy people will want something like RADIUS.  however
RADIUS should not show up in the protocol between the two SNMP
engines.  As far as the command generator is concerned, the command
responder may well have a local table.
In practice the responder will use RADIUS for deployment simplicity.

--Sam