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

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 1 Jun 2005 15:50:29 -0700

Well, Juergen, since you directly sent this request to me, I will give
you a tentative answer. However, a more complete (and adequate) answer
will require digging, including knowing specifically how we intend to
use these protocols, a topic that is not exactly clear to me at this
moment. Regardless, this email contains a terse summary of SSH and then
another terse summary for TLS. It is written from a perspective of
router security though end system uses are also touched on.

The following is a terse summary I wrote about SSH back in 2002:

Although many computers and SSH implementations currently support RSA
(digital certificate)-based authentication for SSH accesses today,
routers currently only support account-password based authentication
according to the Cisco documentation. 

Within select Cisco System products (i.e., 7200, 75000, 12000 series
only), SSH is configured by configuring a host name and domain name on
the router. This is done via the hostname and ip domain-name IOS
commands. Then an RSA key-pair needs to be generated and either local or
AAA authentication needs to be enabled. If AAA authentication is being
used, then it must be disabled on the console port. If local
account-password authentication is being used, then it should be enabled
via the username command. Finally, optional SSH parameters need to be
configured. These optional parameters modify the default connection
behavior. This includes the timeout value for the SSH negotiation phase
and the number of authentication retries which are permitted.

SSH is automatically enabled on these Cisco products when the RSA
key-pair is generated and disabled when the RSA key pair is deleted. The
command crypto key generate rsa generates the RSA key pair and enables
SSH.

Commercial versions of SSH using X.509-based PKI certificates are
available from http://www.ssh.fi/products/. 

Linux (and other Unix)-based systems require that the end user generate
a RSA asymmetric key pair in order to authenticate himself or herself to
a secure shell by using the ssh-keygen command. The resulting public key
(i.e., the key contained within the resulting .pub file) needs to be
added into the ~/.ssh/authorized_keys file on the Linux O/S. All keys
listed in that file are subsequently allowed access to the secure shell
of that Linux instance (i.e., either Red or Black) if the user correctly
types the pass phrase associated with that key during login.

The Internet Engineering Task Force (IETF) has recently begun working on
updating and standardizing SSH, including the Secure Copy (SCP).
Information about their work is found at
http://www.ietf.org/html.charters/secsh-charter.html, including pointers
to the many internet-draft documents they are currently working on. The
current implementation of SSH is SSHv1. The IETF is currently defining
(and standardizing) SSHv2. 

The RSA  public keys of the managers using SSH within Linux applications
will be extracted from their PKI Identity Certificates and loaded onto
the ~/.ssh/authorized.key file in the normal Unix manner. These managers
will be required to have their entire public key pair (i.e., both public
and private keys) on the client system from which they will access their
Linux (SSH) accounts). They also will need to have established a
password on their Linux (SSH) account(s) in order to access the stored
public key on the JTR. 

The following is a terse summary I wrote about TLS back in 2002:

The Transport Layer Security (TLS) standard is used to secure
applications running over TCP. This is a formal standardization of the
SSLv3 protocol that was created by Netscape and widely used for web
(HTTP) security. TLS is currently widely used to secure applications
that use the TCP transport, including LDAP and HTTP.

TLS is defined in RFC 2246 (see http://www.ietf.org/rfc/rfc2246.txt). It
provides privacy and integrity to TCP traffic. TLS is described within
Section 1 of RFC 2246 as follows:

"The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable transport
protocol (e.g., TCP), is the TLS Record Protocol. The TLS Record
Protocol provides connection security that has two basic properties:
*	The connection is private. Symmetric cryptography is used for
data encryption (e.g., DES, RC4, etc.) The keys for this symmetric
encryption are generated uniquely for each connection and are based on a
secret negotiated by another protocol (such as the TLS Handshake
Protocol). The Record Protocol can also be used without encryption.
*	The connection is reliable. Message transport includes a message
integrity check using a keyed MAC (i.e., HMAC). Secure hash functions
(e.g., SHA, MD5, etc.) are used for MAC computations. The Record
Protocol can operate without a MAC, but is generally only used in this
mode while another protocol is using the Record Protocol as a transport
for negotiating security parameters."

Among the functions supported by TLS is the TLS Handshake Protocol,
which uses the TLS Cipher Suite parameter to indicate which key exchange
alternative is to be used. Five different alternatives are available:
three different Diffie-Hellman protocol variants, the RSA key exchange
(which encrypts the secret key with the receivers RSA public key), and
Fortessa. The key exchange enables the client and the server to define a
shared secret key for the session. That shared symmetric key is
subsequently used for conventional encryption of SSL payloads (i.e.,
privacy) and to sign a keyed message authentication code (HMAC) for
integrity protection during the remainder of the session. The client and
server may each optionally also formally establish each other's identity
during the handshake protocol using X.509v3-compliant PKI certificates
(i.e., asymmetric (public key) cryptography (e.g., RSA, DSS)). This
latter authentication can be made optional, but is generally required
for at least one of the peers. This means that TLS is designed to work
with X.509 version 3-compliant (PKI) digital certificates, such as PKI.
Devices (e.g., servers) can also have PKI digital certificates assigned
to them. The specific mechanism by which the latter is done is operating
system (and sometimes application) specific.

Changing topics, I was impressed by Eric Rescorla's book "SSL and TLS",
published by Addison Wesley in 2001. Eric also co-authored the DTLS ID.
Eric has contributed to this WG. He could doublessly answer any
technical questions we could ask him. I have also been impressed by two
O'Reilly books about SSH: SSH the Secure Shell by Janiel Barrett and
Richard Silverman and OpenSSL by John Viega, Matt Messier, and Pravir
Chandra. Although they haven't yet contributed to our WG, perhaps we
could appeal to them for insight as well?

--Eric

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, June 01, 2005 10:12 AM
To: Fleischman, Eric
Cc: Sam Hartman; [email-masked]; [email-masked]
Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt

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

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

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

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