Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 1 Jun 2005 10:00:11 -0700

I am confused by this exchange. I trust that the group is not confusing
SSL with SSH (i.e., the Secure Sockets Layer is the ancestor of and
equivilent of (e.g., SSLv3.1) the Transport Layer Security (TLS)
standard). SSL/TLS operate at the transport layer. Secure Shell (SSH)
operates at the application layer. Both protocols SSL/TLS and SSH are
frequently used to provide a secure session to application layer
protocols. For example, SSL/TLS is well known for securing HTTP and SSH
for securing FTP, though both have many other uses. I assume that you
know this, but I'm just verifying that this is so since I am perhaps
misreading the exchange below as showing confusion on this point.

Now when you speak of SSH, do you mean SSHv1 or SSHv2? My own personal
belief is that SSHv2 has superior security attributes over SSHv1 and
thus I would prefer us using SSHv2 if we choose to use SSH at all for
ISMS.

In any case, the view from my knot-hole is that if we leverage either
SSH or SSL/TLS, I'd like ISMS to benefit from both its authentication
and privacy provisions. In fact, I'd like to see authentication occur at
two layers (which is the normal way these session transports are usually
used): at the transport/session layer (using either SSH or SSL/TLS,
well, actually, my own preference is DTLS) and at the application layer,
perhaps using USM but preferably using a variant to SNMP that leverages
existing authentication systems, preferably Kerberos and/or PKI, but
optionally also server-based authentication approachs such as Radius,
Diameter, COPS Servers or TACACS+.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
>I think it doesn't matter so much what we call tls 
>or ssh.  Tom's question still stands: how do you see 
>ssh interacting with your protocol?

>Are you expecting to use the ssh authentication 
>protocol without the ssh transport?  I don't think 
>that's within the scope of that protocol.

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

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 1 Jun 2005 16:34:29 -0400

Hi,

Comments inline 

> From: Fleischman, Eric [mailto:[email-masked]] 

> I trust that the group is not 
> confusing
> SSL with SSH 

Nope.

> SSL/TLS operate at the transport layer. Secure Shell (SSH)
> operates at the application layer. 
I think the answer is really immaterial to our needs, but at what
layer would you say the SSH Transport Layer Protocol operates?
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-secsh-tra
nsport-24.txt says "The SSH transport layer is a secure low level
transport protocol." I agree that other aspects operate at the
application layer. Ultimately, I don't think it makes much difference,
since SNMP in the TMSM approach would operate above all the SSH
functionality that SNMP would likely use.

> Now when you speak of SSH, do you mean SSHv1 or SSHv2? 

Personally, I mean the work of the IETF SecSH WG - "the protocol being
defined in this set of documents is version 2.0"

> and privacy provisions. 

Agreed.

> In fact, I'd like to see 
> authentication occur at

I think there might be benefits of having an SNMP-level authentication
to supplement the transport layer authentication, but I have concerns
that this puts us back to square one having to do another level of key
distribution. If we decide to distribute keys to the SNMP engine for
SNMP-level authentication, then I don't see a lot of benefit from also
tying the transport layer authentication into SNMP. The transport
layer security can be provided independent of SNMP. 

As always, another security model could be developed to provide the
hook from SNMP to RADIUS or Kerberos that you want, and operators who
want double authentication at the SNMP level could deploy both a
transport-layer security model tied into to SNMP, and a second
SNMP-level authentication model, but I think most operators won't
require double authentication, and I think double authentication is
not the goal of this WG.

David Harrington
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2005 19:11:47 +0200

On Wed, Jun 01, 2005 at 10:00:11AM -0700, Fleischman, Eric wrote:

> [...] SSL/TLS operate at the transport layer. Secure Shell (SSH)

I do not necessarily agree to this distinction nor do I believe such
a distinction is in any way useful. The real question is indeed what
is authenticated where by which mechanism and how to leverage this
(if we want to leverage this). And finding answers to this question
requires to dive into concrete details since there is no abstract
architectural answer here as far as I can tell. And we really need
security experts who know TLS, SSH, SASL, you name it inside out
to sit together with SNMP folks to figure out the details.

Any volunteers? Can the chairs help to organize this?

/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: Thu, 2 Jun 2005 15:32:21 +0200

I wonder if someone can identify which, if any, of the TLS options are in
widespread use. As I increase my understanding of TLS from the
specifications, I do find the large number of alternatives increase the
complexity and hope some can be ignored on the basis that the market place will
have chosen some at the expense of others.

Like,
- which ciphersuites or families of cipher suites (thinking of a family as
defined by key exchange method, if you will allow me that term)?
- DSS v RSA?
- stream or block encryption?

And a general question; why does TLS define ciphersuites at all when SSH has a
more mix
and match approach to the choice of algorithms?

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Jun 2005 13:11:44 -0400

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> I wonder if someone can identify which, if any, of the TLS
    Tom> options are in widespread use. As I increase my understanding
    Tom> of TLS from the specifications, I do find the large number of
    Tom> alternatives increase the complexity and hope some can be
    Tom> ignored on the basis that the market place will have chosen
    Tom> some at the expense of others.
At a protocol level you probably don't care much: if your protocol
doesn't work with all the options you are probably doing something
wrong.  Naturally you'll want to pick mandatory to implement options.
For the most part the TLS 1.1 spec should do this for you.

    Tom> Like, - which ciphersuites or families of cipher suites
    Tom> (thinking of a family as defined by key exchange method, if
    Tom> you will allow me that term)?  - DSS v RSA?  

RSA

    Tom> - stream or
    Tom> block encryption?

I think both are in reasonably common use although I suspect that for
now block will be increasing in usage and stream decreasing.

    Tom> And a general question; why does TLS define ciphersuites at
    Tom> all when SSH has a more mix and match approach to the choice
    Tom> of algorithms?

Preference of the designers involved.  I really wish they had at least
separated key exchange from the rest.

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 3 Jun 2005 15:32:08 +0200

I thought I would fit SSH in David's and Juergen's TMSM to see how different it
looked.  I include it below.  It does not seem significantly different, at least
at the level of abstraction in TMSM.  I would glad to hear of any mistakes in
it; in fact, given my knowledge of SSH, if noone finds anything wrong with it,
then I will not believe those with skills in SSH have read it:-)

I did wonder why the tmStateReference should be passing so much information
about the session to the MPSP; I would have expected the master secret, eg,  to
have stayed in the TMSP

I also wonder about the multiplexing of upper layers onto lower.  SSH has
connections and I have assumed that SNMP uses them and so the state includes a
channel number, as opposed to using raw ssh transport.  But for TLS, application
data
seems to map directly onto the TLS Record Protocol with no intervening
multiplexing.

Tom Petch
=================================================================
(is the original TLS specific text - grep out as you will)
[is my idea of the SSH equivalent]

5.1  [SSH](TLS)/TCP Transport Mapping Security Model

   SNMP supports multiple transports.  The preferred transport for SNMP
   over IP is UDP [RFC3417].  An experimental transport for SNMP over
   TCP is defined in [RFC3430].

   [SSH](TLS)/TCP will create an association between the TMSM of one SNMP
   entity and the TMSM of another SNMP entity.  The created "tunnel" may
   provide encryption and data integrity.  Both encryption and data
   integrity are optional features in [SSH](TLS).  The [SSH](TLS) TMSP MUST
provide
   authentication if auth is requested in the securityLevel of the SNMP
   message request (RFC3412 4.1.1).  The [SSH](TLS) TM-security model MUST
   specify that the messages be encrypted if priv is requested in the
   securityLevel parameter of the SNMP message request (RFC3412 4.1.1).

   The [SSH](TLS) TM-security model MUST support the [SSH Transport Layer
Protocol and User Authentication Protocol] (TLS Handshake Protocol with mutual
authentication).

5.1.1  tmStateReference for [SSH](TLS)

   Upon establishment of a [SSH](TLS) session, the TMSP will cache the state
   information.  A unique tmStateReference will be passed to the
   corresponding MPSP.  The MPSP will pass the securityStateReference to
   the Message Processing Model for memory management.

   The tmStateReference cache:
      tmStateReference
      tmSecurityStateReference
      tmTransportDomain = TCP/IPv4
      tmTransportAddress = x.x.x.x:y
      tmSecurityModel - [SSH](TLS) TMSM
      tmSecurityName = "tba"
      tmSecurityLevel = "authPriv"
      tmAuthProtocol = [SSH-2.0 hmac-sha1] (Handshake MD5)
      tmPrivProtocol = [SSH-2.0 3des-cbc](Handshake DES)

{**I am unclear why all these session parameters need passing to the MPSP}

      tmSessionID = [SSH session_id H] (Handshake session identifier)
      tmSessionKey = [SSH shared secret K] (Handshake peer certificate)
      [{**no SSH equivalent}] (tmSessionMasterSecret = master secret)
      tmSessionParameters = compression method, cipher spec(, is-
      resumable)
      [tmChannelNumber = nn]({**no TLS equivalent})

5.1.2  MPSP for [SSH](TLS) TM-Security Model

      messageProcessingModel   = SNMPv3
      securityModel            = [SSH](TLS) TMSM
      securityName             = tmSecurityName
      securityLevel            = msgSecurityLevel

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 3 Jun 2005 13:47:46 -0400

Hi Tom,

Comments inline. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Friday, June 03, 2005 9:32 AM
> To: [email-masked]
> Subject: [Isms] SSH in TMSM
> 
[...]
> about the session to the MPSP; I would have expected the 

The requirements of ISMS are not clear regarding sessions. The RFC3411
architecture does not have sessions, so if sessions are only supported
at the transport mapping, and are not seen by the applications or the
messaging subsystems, then the session data should not need to be
passed to the MPSP.
> seems to map directly onto the TLS Record Protocol with no
intervening

RFC3413 applications make the transport address decision, such as
whether to use UDP port 161 or port 162. There is little discussion
about how the application knows which transport mappings exist and
should be used, unless the RFC3413 MIB modules are used. For
Responses, the Command Responder sends the stateReference to the
dispatcher via returnResponsePDU(); stateReference is a "reference to
state information needed when sending a response." 

The RFC3413 applications do not support sessions or channels, unless
that information is passed in the stateReference, or made available
via the SNMP-TARGET-MIB suite.

If sessions or channels can somehow be encoded into a transportDomain
and transportAddress, they could fit into the existing stateReference
and SNMP-TARGET-MIB suite. Whether various expectations of usage would
fit into stateReference and the RFC3413 MIB modules is another thing.
I expect the RFC3413 MIB modules are SET with a static configuration,
representing administrative policy; I don't know how dynamic sessions
can be configured into those MIB modules.

If the expectation is that different SSH connections or channels will
be used for request/response traffic and for notifications (Cf: ports
161/162), then the information "needed when sending a response" must
be passed in the stateReference, and for non-response messages, the
applications need to know how to request the different channels, and
need to make the distinction in the transportDomain/transportaddress
parameters of sendPDU(). 

RFC3430 discusses some issues regarding connections. I think that the
description of a transport-mapping for snmp-over-TLS or snmp-over-SSH
would probably need to be as comprehensive as RFC3430. Such a
transport mapping should include definition of a suitable
trasnportDomain and transportAddress format, how to manage
connections, how to use the RFC3413 MIB modules to store
(dynamically-generated-channel) addresses for RFC3413 applications,
and the security considerations.

If the expectation is that different SSH connections/channels are used
for different securityLevels, then the same applies. However, the
RFC3413 applications do not know how to decide which securityLevel is
needed for different types of data, so a new application model would
probably need to be written that describes how the channel selection
is made based on data sensitivity, and it would need to be discussed
how the application would register itself with the dispatcher (new
verbs - GETsensitive and GETinsensitive??). That is definitely outside
the scope of this WG.

David Harrington
[email-masked]

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 8 Jun 2005 23:45:03 -0700 (PDT)

HI,

Juegen - VERY WELL said!

However, I tried to do this at the last IETF, and found that
the security experts don't talk to each other.

Consider a group in, say, the security area saying we need
help from the management folks in working out how to use
these management protocols of SNMP, CMIP, COPS, etc.
(Hope this example is illustrative!)

> Any volunteers? Can the chairs help to organize this?
Regards,
/david t. perkins

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Jun 2005 21:43:13 -0400

>>>>> "David" == David T Perkins <[email-masked]> writes:

    David> HI, Juegen - VERY WELL said!

    David> However, I tried to do this at the last IETF, and found
    David> that the security experts don't talk to each other.

    David> Consider a group in, say, the security area saying we need
    David> help from the management folks in working out how to use
    David> these management protocols of SNMP, CMIP, COPS, etc.  (Hope
    David> this example is illustrative!)

There's a reason Ken is a co-chair of this working group.  He has
enough experience with ssh, tls, SASL and Kerberos that I think he can
answer these sorts of questions.  So can ekr.  I think I can too.  I
think Joe Salowey (who I believe was following ISMS at least at IETF
62) can do so too.  All of these people should understand tls, sasl,
ssh enough to explain difference.  A good subset understand IPsec, EAP
and DTLS.

I
am personally not following things closely enough that I'm guaranteed
to catch specific unanswered questions.  I'd rather not be the primary
explainer of security protocols to ISMS although I'd prefer to take on
that role instead of seeing ISMS fail.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Jun 2005 06:15:13 -0400

I've read this and it seems sort of OK as far as it goes, but it
doesn't deal with the tricky bits such as what connection subsystem is
used and the over-the-wire encoding of messages.

I think that exposing the authentication/integrity protocol, the
confidentiality protocol, and some of the other ssh parameters exposes
too much low-level ssh state to higher levels.