Subject: RE: [Isms] Re: SSH USERNAME

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 24 Oct 2007 13:11:26 -0400

On Friday, September 14, 2007 11:31:39 AM -0400 "David B. Nelson" 
<[email-masked]> wrote:

> Does SNMP have a way to know that SSH has performed a "meaningful"
> authentication?

The answer to that is implementation-specific.  An SSH implementation might 
provide information about the name of the client, what auth methods were 
used, etc.  That could be done via environment variables or via some other 
mechanism; for example, I could envision an environment in which the 
interface between SSH and SNMP is richer than a simple file descriptor or 
two-way pipe, and includes a way to discover things about the connection. 
But all of that is implementation-specific; the interface between SSH and 
an application running on top of it is not standardized.

> If not, is there a way for the system administrator to configure the
> combination of SSH and SNMP such that insufficiently "meaningful" levels
> of authentication are not employed with Transport Security Models?

I guess that depends on what you consider "meaningful", and to me, that is 
an operator policy decision.  You could certainly configure SSH to allow 
unauthenticated access via the "none" method.  You could also give it a 
password database backend which accept any username with the password 
"foo".  Whether these are meaningful depends on your environment.  Neither 
of these things would prevent the channel from being encrypted and 
integrity-protected, though of course one could choose null encryption 
and/or MAC algorithms.  All of these are NOT RECOMMENDED in SSH, but are 
available for testing and special situations.

I don't think we need to say anything in ISMS about this; it is sufficient 
to assume that if SSH is in use, then messages arriving via an SSH 
connection were sent by the user whose name SSH reports.  The whole point 
of reusing SSH is to avoid revisiting those issues in SNMP.

-- Jeff

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 25 Oct 2007 08:41:26 +0800

Hi,

The SNMPv3 WG deliberately reduced all security capabilities down to
auth and priv, without concern for rating the strength of different
mechanisms for authentication and encryption.

How strong a security mechanism is depends on the environment in which
it is being deployed, and the perceived strength of mechanisms can of
course change over time as hackers find vulnerabilities in existing
mechanisms. 

The SNMPv3 WG chose not to try to classify all mechanisms according to
strength, and chose not to rely on the security area to do so either.

It is a deployment decision how to configure the combination of
various security mechanisms to provide "meaningful" levels of security
service.

The SSH Transport Model assumes (and states so) that an operator
should not use "none" or other non-meaningful security mechanisms with
SSH for securing SNMP, and assumes that all operator-configured
support for the SSH-Transport model will provide "meaningful"
authentication and encryption.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 1:11 AM
> To: David B. Nelson; [email-masked]
> Cc: Jeffrey Hutzelman
> Subject: RE: [Isms] Re: SSH USERNAME
> 
> 
>

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Thu, 25 Oct 2007 08:15:55 +0200

I mainly agree with David here.

But we do include the securityModel as a parameter (in VACM) for
our decisions to grant or deny access to certain MIB views. So at
deployment time, operators can take that into account.

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 2:41 AM
> To: 'Jeffrey Hutzelman'; 'David B. Nelson'; [email-masked]
> The SNMPv3 WG deliberately reduced all security capabilities 
> down to auth and priv, without concern for rating the 
> strength of different mechanisms for authentication and encryption.
> 
> How strong a security mechanism is depends on the environment 
> in which it is being deployed, and the perceived strength of 
> mechanisms can of course change over time as hackers find 
> vulnerabilities in existing mechanisms. 
> 
> The SNMPv3 WG chose not to try to classify all mechanisms 
> according to strength, and chose not to rely on the security 
> area to do so either.
> 
> It is a deployment decision how to configure the combination 
> of various security mechanisms to provide "meaningful" levels 
> of security service.
> 
> The SSH Transport Model assumes (and states so) that an 
> operator should not use "none" or other non-meaningful 
> security mechanisms with SSH for securing SNMP, and assumes 
> that all operator-configured support for the SSH-Transport 
> model will provide "meaningful"
> > The answer to that is implementation-specific.  An SSH 
> implementation 
> > might provide information about the name of the client, what auth 
> > methods were used, etc.  That could be done via environment 
> variables 
> > or via some other mechanism; for example, I could envision an 
> > environment in which the
> 
> > interface between SSH and SNMP is richer than a simple file 
> descriptor 
> > or two-way pipe, and includes a way to discover things about the 
> > connection.
> > But all of that is implementation-specific; the interface 
> between SSH 
> > and an application running on top of it is not standardized.
> > 
> > 
> > I guess that depends on what you consider "meaningful", and to me, 
> > that is an operator policy decision.  You could certainly configure 
> > SSH to allow unauthenticated access via the "none" method.  
> You could 
> > also give it a password database backend which accept any username 
> > with the
> password 
> > "foo".  Whether these are meaningful depends on your environment.  
> > Neither of these things would prevent the channel from 
> being encrypted 
> > and integrity-protected, though of course one could choose null 
> > encryption and/or MAC algorithms.  All of these are NOT 
> RECOMMENDED in 
> > SSH, but are available for testing and special situations.
> > 
> > I don't think we need to say anything in ISMS about this; it is 
> > sufficient to assume that if SSH is in use, then messages 
> arriving via 
> > an SSH connection were sent by the user whose name SSH 
> reports.  The 
> > whole point of reusing SSH is to avoid revisiting those issues in 
> > SNMP.
> > 
> > -- Jeff
> >

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 25 Oct 2007 11:13:16 -0400 (EDT)

> authentication and encryption.

And I believe this is sufficient.