Subject: RE: [Isms] SSH / Reusability / etc

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 15 Apr 2005 17:05:30 -0400

I don't think this is what people want. IMHO the choices are:

1. Use encapsulation (SNMP messages with different security model) to
obtain keys from RADIUS or Kerberos, use USM with those keys.
2. Use encapsulation (as above) to obtain keys to use some other
security model with them.
3. Somehow invoke TLS or SSH, tunnel SNMP messages through it, somehow
for every packet get the mapping to VACM. Unless "somehow" is replaced
by something tangible and aceptable, I don't like this approach.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wes Hardaker
Sent: Friday, April 15, 2005 1:26 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [Isms] SSH / Reusability / etc

>>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman
<[email-masked]> said:

Sam> no.  It is OK to explore use of the ssh keys, although I'm
personally
Sam> against it.  As an AD, you'd need to get the secsh wg's
cooperation.

Sam> Re use of the ssh protocol is clearly OK if you can make it work.

I think there have been multiple people who have "almost" suggested
using another protocols like TLS and SSH in such a way as to bootstrap
USM with the keys, and then dump the other transport since it was only
used to define keys.  IE, I think there are a number of people that
want to functionally this:

  1) start SSH or TLS between a command generator (CG) and a command
     receiver (CR), for example (obviously not limited to just CG/CR
     pairs).  This would include user authentication in the process
     (anything from Radius, SASL, SSH-keys, ... works here)

  2) once that secure "link" is open, steal its keys (Ks).

  3) close transport

  4) throw Ks into engines for CR/CG

  5) continue with SNMP/USM (over the standard transport port 161 or
     whatever) using Ks and, um, some user name and engineID as yet
     not well discussed.

I *think* people are hinting at this, but no one has stated it clearly
so I can't be sure.

1) I really don't see the benefit in this.  You're starting up
   perfectly secure transport that is actually more secure and
   flexible than USM and then dumping it so you can fall back use
   something that isn't needed.  I don't see how this is simpler than
   merely tunneling SNMP through TLS/SSH or whatever as DTLS wants to
   do.  Heck, you could even do USM processing of the resulting SNMP
   packet that was tunneled if you wanted as long as you ignore the
   results and the security model number was actually different.  I
   won't go farther into this unless someone agrees that what I've
   described is actually what they're wishing to do.

2) this is, in fact, an out of band keying mechanism *not* a
   encapsulated keying mechanism and I hope everyone sees that.  [not
   that it couldn't be a solution, but there is a difference].

-- 
Wes Hardaker
Sparta, Inc.

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Apr 2005 23:43:46 +0200

> by something tangible and aceptable, I don't like this approach.

All you need to do is an authentication exchange once the secure 
transport is open which gives you a securityName.

I fail to see why SNMP is fundamentally different from other protocols
where you establish a secure tunnel, some sort of authentication exchange 
over the secure tunnel and then finally access control decisions based 
on the authenticated identity.  The only reason this may look ugly is 
the way the SNMP architecture forces the complete security subsystem 
into the middle of the SNMP blob, to be called in the middle of the 
message processing.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 15 Apr 2005 21:04:29 -0400

> transport is open which gives you a securityName.

I concur. And the securityName could be utilized for the length of the
authenticated session.

While it might be possible to get a securityname from the transport
portocol (e.g. TLS), I think it unlikely that the transport protocol
can offer any authorization information for the tie-in to VACM.

I would prefer to see the authentication exchange done at layer 7,
followed by an authorization exchange to the same or different
mechanism. This may mean doing something like having the
transport/security model in the SNMP engine also serve as (or call) a
RADIUS client or a SASL client, after securing the message at the
transport layer.

David Harrington
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Apr 2005 09:46:01 +0200

I'm not an SNMP expert and CERTAINLY NOT an expert on VACM, but...

> by something tangible and aceptable, I don't like this approach.

Why wouldn't this simply be a new <securityModel, securityName> tuple? 
You'd probably have to use SASL w/ TLS because securityName is limited 
to SnmpAdminString(1..32), and OBTW you get that externally.  Were I to 
do this I would perform substantial surgey on the command so that 
securityNames are not sent with every command to avoid conflicts.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 16 Apr 2005 07:01:34 -0400

Hi Eliot,

I think I agree with you (mostly), but I need to have you help me
understand what you're saying.

What is OBTW? I'm not sure if the presence of the term here impacts
the semantics of the sentence. I could assume it means oh-by-the-way,
and simply remove it from the sentence, but OBTW might mean something
that would seriously change the meaning of the sentence.

I can't fully comprehend the impact of "substantial surgery on the
command"
What command are you referring to?
I understand there is substantial work to be done; did you have
specific surgery in mind?

Dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Saturday, April 16, 2005 3:46 AM
> To: Blumenthal, Uri
> Cc: Sam Hartman; [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 16 Apr 2005 11:49:05 -0700

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "Blumenthal, Uri" <[email-masked]>
> Cc: "Sam Hartman" <[email-masked]>; <[email-masked]>
> Sent: Saturday, April 16, 2005 12:46 AM

> Why wouldn't this simply be a new <securityModel, securityName> tuple?
...

Not quite, if the objective is to minimize the number of systems that need
to be touched whenever a new user is added or deleted.
There are two mappings of interest:
    1) the security-model-specific-name -> the security-model-neutral-name
    2) the security-model-neutral-name -> the group-name used in vacm

One could skirt around the first by specifying that for this particular security
model, the name that is carried in protocol is the model-neutral name, though
it makes things tougher when federating.
The second is needed to associate that particular user with the set of
users with identical permissions.  Without it, the user cannot access
anything.

The name->group mapping could be obtained several ways:
    a) pre-provisioned by configuring the user to group table in VACM.
        This is how things work today, and has the disadvantage that whenever
        a new user is added, one has to touch all the managed systems that
        that user might need to access.
    b) obtained in real time by the snmp engine  asking some
        system that can securely supply these mappings
    c) supplied by some system *telling* the snmp engine
        what it will need to know before the snmp engine receives the request.
        (This is a generalization of (a) to include other protocols.)
    d) carried along with the request.  This information would have to be
        signed/certified in some way, since we'd hardly trust users to choose
        their own groups.

For *all* of these options, I think there is value to providing a mechanism
to limit the lifetime of the user->group entry.  This reduces the need to
touch managed systems when users are removed or their privileges
are revoked, and could also make managed systems a little more resistant
to some off-line attacks.

> securityNames are not sent with every command to avoid conflicts.
...

Randy