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

From: "Martin Soukup" <[email-masked]>
Date: Wed, 13 Apr 2005 21:52:58 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: April 13, 2005 4:24 AM
> To: Blumenthal, Uri
> Cc: [email-masked]
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> On Wed, Apr 13, 2005 at 03:03:30AM -0400, Blumenthal, Uri wrote:
> > >> Yes using existing keying of USM is the most easily 
> implementable. 
> > >> I strongly favor AUGMENTing the usmUserTable with the relevant
> > life-time
> > >> etc. attributes.
> > >
> > >Easy implementation is a nice feature but at the end can't be the 
> > >goal of this WG. This WG is about integration and ultimately 
> > >deployment.
> > 
> > Complex implementation to prove a point is even less of a goal.
> 
> You are missing the point. Nobody said complex implementation 
> is a goal.
> 
> > Integration is about getting keying and authorization 
> information from 
> > already-deployed security infrastructure and mapping it 
> onto VACM and 
> > hopefully USM (because it's already there, and 
> well-analyzed). If the 
> > result allows [almost] direct hook-up to that existing 
> infrastructure 
> > - deployment's likely to be easy, and hopefully wide.
> 
> At the end, someone needs to understand and debug things. If the 
> machinery for oobk is getting increasingly complex, the need for 
> this sort of debugging will grow in heterogenous environments. 

It is true that we need to reduce complexity, that is why I like OOBK. The
modularity provides a separation of concerns which is easier to debug and
test. 

> > I've tracked SNMP from v2 through its variations and to v3, so I'm 
> > speaking from experience. I've stated my opinion. Others 
> are entitled 
> > to theirs.
> 
> Seems like we share some history but draw different lessons from 
> the shared history.
>  
> > >In my University, the number of people who know how to 
> deal with TLS 
> > >certificates or SSH keys is much much bigger compared to 
> the number 
> > >of people who know IKE, SNMPv3/USM and such things. And I believe 
> > >this is true in many enterprise networks.
> > 
> > 1. TLS certs aren't any different from IKE certs, conceptually at 
> > least.
> 
> Conceptually the same and knowing the tools to get certs 
> created, signed and so on does make a difference. Using 
> SNMPv3/USM is also conceptually simple. But people are simply 
> not willing to do extra work in order to get secure SNMP. 
> Either SNMP security comes almost for free for the 
> operator (means integrates out of the box with other device access 
> methods (CLIs, Web Server, netconf, ...) or people will not use it.
> 
> > 2. Your belief doesn't match market analysis that I'm seeing.
> 
> Conclusion: Lets simply disagree on the lessons learned from 
> the history and disagree on the properties of the target 
> environments we have in mind.

Is there any reason OOBK couldn't use SSH keys, or SSH for that matter. I'm
not sure the ease of use of a certain existing protocol is relevant to the
architectural discussion?

> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> 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: Thu, 14 Apr 2005 09:43:51 +0200

> architectural discussion?

An architecture where do not have suitable protocols in place to 
instantiate it is IMHO useless. 

So far, I heard things like IKE and EAP in the context of OOBK. I must 
have missed the document explaining how to use ssh or ssh keys to 
establish usm session keys.

/js

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Apr 2005 17:12:34 -0400

>>>>> "Martin" == Martin Soukup <[email-masked]> writes:

    Martin> Is there any reason OOBK couldn't use SSH keys, or SSH for
    Martin> that matter. I'm not sure the ease of use of a certain
    Martin> existing protocol is relevant to the architectural
    Martin> discussion?

You would need to coordinate with the ssh working group.  UNlike IKE
and EAP they don't have an explicit applicability statement for their
keys.  I talked to the working group chair and he was less negative
than I expected.

I'd be somewhat concerned about such a use.  In particular, you would
need to make sure that your protocol didn't end up being an oracle for
ssh authentication or something like that.  The ssh keys were designed
to be simple for ssh to use not a general mechanism.

Also, note that when you reuse a protocol like ssh, you hopefully at
least eventually get to a point where you reuse implementatinos.  That
means you get to take advantage of all the non-protocol deployment
simplifications of an implementation.  For example you get to reuse
the authorization infrastructure, the account creation infrastructure,
etc.

Given that it seems possible to re-use the ssh protocol not just the
keys my personal preference is to do so.  However coordinating with
the secsh working group and getting them to write an applicability
statement for their keys or just to come to consensus that your
proposed use is OK is certainly an option.

--Sam

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Apr 2005 10:34:08 +0200

Sam,

If I read your messages your are saying that it is okay to explore use 
of the ssh protocol, but that use of just the keys wouldn't float your 
boat.  Is that a fair summary?

Eliot

---

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

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam, If I read your messages your are saying that it is
    Eliot> okay to explore use of the ssh protocol, but that use of
    Eliot> just the keys wouldn't float your boat.  Is that a fair
    Eliot> summary?

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

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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 15 Apr 2005 13:25:39 -0700

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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 15 Apr 2005 14:13:04 -0700

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

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

Sam> I'm mostly not OK with this.

We're in agreement then :-)

-- 
Wes Hardaker
Sparta, Inc.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Apr 2005 16:45:37 -0400

>>>>> "Wes" == Wes Hardaker <[email-masked]> writes:

    Wes> other transport since it was only used to define keys.  IE, I
    Wes> think there are a number of people that want to functionally
    Wes> this:

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

I'm OK with this.

I'm mostly not OK with this.  For TLS it is acceptable to run
something through the PRF as EAP does and use that as a key.  I don't
think ssh has a similar mechanism.

Using some key intended for one uprpose (such as ssh session
encryption) for another purpose (keying USM) is generally not
acceptable.

One thing you can do once you have a secure transport is send your own
randomly generated (or DHed) keys over that transport.

    Wes>   4) throw Ks into engines for CR/CG

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

Yes, I believe people have been hinting at this.

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

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

Personally I agree with you.  I think this is the wrong approach.  I
do not have any blanket objections as an AD to the approach, although
there are a lot of things to get right.  The appropriate use of keys
or confirming that you are within a protocol's applicability statement
are just two examples.

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

Agreed.  I assume that the people currently proposing OOBK mean
something exactly like what you propose.

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 15 Apr 2005 20:11:46 -0400

Hi,

So there is no ambiguity, 

1) I do not support copying the keys from another protocol to stuff
into USM. I think that approach creates the potential for exposure of
the keys, which would weaken both protocols.

2) I can live with having the SNMP keys delivered to an SNMP security
model over a secure protocol, but that would not be my preference
because I think it creates the potential for exposure of the keys.
This could be slightly problematic remaining in sync with a
centralized server ( a fired operator whose credentials are removed
from RADIUS, might still have access to SNMP devices until the keys
were removed from the SNMP entity.)

3) My preference is to have SNMP be ignorant of the authentication
credentials used by another protocol, and to have that protocol simply
inform the SNMP security model of the authenticated user identity. The
security model might then dynamically stuff the securityname and other
necessary parameters into the USM MIB or a similar MIB so the SNMP
engine components can utilize the securityName to provide access
control, audit logging, etc. based on the securityName.

4) I would like to see the authentication server also provide
authorization information that ties into the VACM groupname table or a
similar approach to identifying which acceess control "policy" should
be applied for this security principal. I support the use of RADIUS or
other AAA server as one source for authorization policy.

David Harrington
[email-masked]

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