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

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Wed, 1 Jun 2005 16:47:50 -0700

Nice summaries!  A few things to add about TLS auth (beside x509 cert):

+ Fortezza auth is supported in SSLv3 but not TLS as far as I know.
+ Kerberos auth for TLS is defined in
http://www.faqs.org/rfcs/rfc2712.html
+ SRP and PSK auth are being considered by TLS WG:
http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-09.txt
http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-08.txt

The last two may be of interests for SNMP since they facilitate
user auth.  Sam may have some insight about their ietf status.

Khanh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fleischman, Eric
> Sent: Wednesday, June 01, 2005 3:50 PM
> To: [email-masked]
> Cc: [email-masked]; Sam Hartman; [email-masked]
> Subject: RE: [Isms] draft-schoenw-snmp-tlsm-02.txt
> 
> 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
> 

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