Subject: RE: [Isms] TLS / SSH scalability concerns

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 13 May 2005 11:43:42 -0400

> FYI (in case you not already know):
> 
> http://www.umiacs.umd.edu/docs/Du.ppt
>
> They concluded that SNMP/TLS was more efficient than USM. 

And I have a very nice bridge for sale in the vicinity of NYC. :-)

> Anyway, these results need to be taken w/ a grain of salt as
> there are many factors (e.g. # msgs per session) that may
> affect the results.

The facts are:
  - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping;
  - TLS spends extra cycles on TCP overhead;
  - TLS has large session establishment overhead;
  - DES/AES and MD5/SHA1 is done by both, and the cost is similar.

Therefore, the more messages are sent within one long session - the
greater the chance of amortizing the session establishment cost and come
out even (seems rather obvious). As for TLS solution turning out *more*
efficient - forgive me for not entirely trusting those results (assuming
apples-to-apples comparison, i.e. using SNMPv3 in both cases).

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 May 2005 18:39:11 +0200

I think there might be some truth on both sides of this issue.  For 
instance, maintaining established sessions goes to Juergen's point that 
you need to keep getting the biggest baddest largest server to manage 
"All of This".  On the other hand, if you're not taking authentication 
steps on each packet there's something to be gained, I'm sure.

I think it's safe to say that people know how to deal with both.  And I 
actually think a whole lot of people know a whole lot more about TLS. 
That has certain benefits.  I would imagine the same thing will be able 
to be said about DTLS, assuming a major app picks it up.  SIP? 
Something else?

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 May 2005 19:19:27 +0200

On Fri, May 13, 2005 at 11:43:42AM -0400, Blumenthal, Uri wrote:

> As for TLS solution turning out *more*

Larger message sizes, reduced overhead due to session state, perhaps
better optimized libraries. Message size is a very important parameter.
There is a paper in the Fall issue of the IEEE electronic Transactions
on Network and Service Management (eTNSM) which compares SNMP performance
with Web Services and one of the conclusion is that several commercial
SNMP implementations exhibit interesting performance behaviour. It 
seems that SNMP performance does not get that much attention and 
things sometimes are less optimized than what one would expect. 

/js

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

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 25 May 2005 15:37:40 +0200

Juergen

You have in the past expressed support for SSH (and TLS) on the grounds that
they are best understood in your organisation.  As I understand it, both depend
on public/private key distribution.  How are these created and distributed,
particularly how do you get the private key into a low powered, remote device
(comparable to a desktop switch or access router:-) because this is the issue
that keeps making me shy away from them as options for isms?

Tom Petch

 Schoenwaelder" <[email-masked]>
To: "Blumenthal, Uri" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 13, 2005 7:19 PM
Subject: Re: [Isms] TLS / SSH scalability concerns

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2005 02:09:35 +0200

On Wed, May 25, 2005 at 03:37:40PM +0200, Tom Petch wrote:
> Juergen
> 
> You have in the past expressed support for SSH (and TLS) on the grounds 
> that they are best understood in your organisation.  As I understand it, 
> both depend on public/private key distribution.  How are these created 
> and distributed, particularly how do you get the private key into a low 
> powered, remote device (comparable to a desktop switch or access 
> router:-) because this is the issue that keeps making me shy away from 
> them as options for isms?

My understanding is that SSH can be used in different ways. The first 
basic mechanism is that ssh has a notion of a hostkey which is generated
when you install the ssh server and exchanged when you setup a connection.
Clients usually learn hostkeys (by accepting them) and keep a list of
previously accepted hostkeys. Once the hostkey has been accepted, a session
key is generated which is used to encrypt subsequent interactions. In
other words, the hostkey to some extend automatically propagates (of
course it should be checked when a new client accepts it) and you simply
get an encrypted pipe to the server.

Once you have the encrypted pipe, you do user authentication. You can
use different authentication mechanisms - the most important ones are
probably passwords and public/private key pairs. If you use passwords,
the box of course needs to know your password. If you use keys, then
of course the public part of your key must have been copied to the box
in some way. I have seen routers where I can install a user's public
key and I have seen switches where I can only work with passwords (which 
happen to be the same as the good old CLI password).

I believe TLS is in many applications used in a very similar way. You
have to create a certificate which you store of the server and which is
presented to the client. When the client connects to the server, it tries
to validate the certificate and if successful sets up encryption. A common
pattern is that a SASL exchange is then used to authenticate a user. Due
to a weak cryptographic binding between SASL and TLS, there are some
security concerns here. (But I believe that this issue will be solved
sooner or later since this combination is quite popular in the context
of SMTP/IMAP at least). You can use TLS to authenticate users based on
certificates without SASL but then you have to manage certificates not
only on the server but also on the clients, which in my very limited
experience seems to be more hassle than dealing with ssh user keys.

This description above is rather high-level and simplified and I am 
sure totally wrong from the security area member's perspective so I do 
apologize in advance. Back to your main question:

> As I understand it, 
> both depend on public/private key distribution.  How are these created 
> and distributed, particularly how do you get the private key into a low 
> powered, remote device (comparable to a desktop switch or access 
> router:-) because this is the issue that keeps making me shy away from 
> them as options for isms?

If you use ssh with password authentication, basically the whole procedure
is kind of automatic (you only have to create the hostkey once on the box).
You directly reuse the local accounts (or radius accounts) configured on
the box. If you use public key user authentication, you have to copy
public keys on the box (and later remove them). The copying itself is
not too much resource consuming - the question is more how you manage
those keys on the boxes if people come and go. So the complexity is
probably similar to managing USM keys. The difference, however, is that
these ssh keys may be used to authenticate the same identity regardless
whether she uses the CLI, SNMP or NETCONF.

[The same is probably true as well for TLS certificates. However, I must
 admit that so far I only have practical experience with the combination
 of TLS and SASL (and of course TLS with HTTP authentication).]

If I were allowed to make a choice, I would prefer ssh since ssh is well
understood by operators and already on many boxes that I personally care 
about. That said, I do accept that there are other environments where 
other conclusions would be drawn (and in some environments SNMPv3/USM 
might actually be the best choice). But if I recall correctly the operator 
input we received in various places before this WG was created, I do 
believe that the operators who provided input liked to use ssh and this
group should therefore be the most important target group. This seems to 
be inline with the decisions in other WG such as NETCONF where ssh was 
adopted as the mandatory to implement transport. (And it was kind of
interesting to observe that nobody ever wrote a document specifying 
plain TLS transport for NETCONF - although I know that there was at 
least an attempt to implement something like that.)

/js