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

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2005 06:18:00 +0200

On Tue, May 31, 2005 at 11:42:25PM -0400, David B Harrington wrote:

> Netconf punted on the notification channel because not all their
> "transports" could handle such a thing. SNMP obviously requires
> notification capabilities, so we'd need to determine how that could be
> done with SSH, as with any other possible transport layer security
> protocols. 

The original netconf approach was to use basically one transport layer
connection to multiplex different channels over it, some carrying
netconf 1.0 interactions and others carrying notifications and whatever
you might invent in the future. The biggest technical problem with
this (and notifications in general) was as far as I recall the 
SOAP/HTTP mapping (plus some concerns how independent the channels
really are when the underlying transport is TCP rather than SCTP).

RFC 3430 (SNMP over TCP) suggests that TCP connections are initiated
by notification originators in case there is no currently established
connection that can be used to send the notification. Following this 
approach with ssh would require to provision authentication
credentials on the agent so that agents can successfully authenticate
to a notification receiver. There might be other approaches, like
the reuse of manager initiated secure transport connections for
notifications. There is some text in Appendix A in RFC 3430 which
captures some of these discussions when RFC 3430 was written.

/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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Jun 2005 17:08:09 -0400

I suspect in many environments agents capable of accepting commands
using ssh for authentication will have sufficient credentials to do
outbound authentication.  This is because host keys are also useful
for ssh userauth.

What I'm less clear about is whether people will typically be able to
authorize these credentials to generate notifications.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 7 Jun 2005 15:40:12 -0400

Hi Sam,

I am having difficulty reconciling my understanding of how an SNMP
agent works, and the terminology you have used in your comments.
Please help me to bridge the gap.

You talk about "agents capable of accepting commands using ssh for
authentication" . As I see the SNMP approach, commands are the payload
encapsulated within an SNMP message, and a message is authenticated as
having been sent on behalf of a known user. I envision SSH providing
the transport of SNMP messages, and authenticating the message as
having been sent on behalf of a known user. Do you mean "agents
capable of accepting SNMP messages using SSH for authentication"?

You say "agents ... will have sufficient credentials". The user's
credentials are somehow made available to the authentication process
implemented within the agent (or are made available to an
authentication process external to the engine, such as RADIUS), and
the authentication process uses the credentials to verify the identity
of the user, but the agent does not itself have SNMP-related
credentials to identify itself (although it may have non-SNMP-related
crdentials, e.g. RADIUS-client credentials). Do you mean "agents will
have (access to) sufficient credentials to authenticate the message as
having been sent on behalf of the claimed user"?

In the TMSM approach, the agent may not have the credentials at all. A
lower layer security mechanism (SSH) would have access to the
credentials and perform the authentication, and the SNMP engine would
only have a mechanism to accept an assertion from the lower layer
security mechanism that suitable authentication has been performed and
the message is asserted as being authentic and on behalf of a known
identity. 

I don't understand your comment about utilizing host keys for userauth
for outbound authentication, and how that relates to SNMP-related
message authentication. Can you expand on this?

Recognize that SNMPv3 provides user-based access control for
notifications, so a user not authorized to GET the value of a variable
cannot typically gain access to the value of that variable using a
notification. You probably do not want to support user-based
authentication for access control for request/response operations, but
only use host-based authentication for access control for
notifications.

Am I correct in reading your second sentence as meaning, "What I'm
less clear about is whether administrators will typically have a
mechanism (in SSH or SNMP) to authorize these credentials to be used
when an SNMP notification generator application generates
notifications."? 

If that is what you mean, then a MIB module (such as those found in
RFC3413) might be able to provide the user interface for the
administrator. I am not clear whether the administrator (or the SNMP
engine) has sufficient access to the SSH credentials (or a way to
reference an appropriate set of unseen SSH credentials) to be able to
populate a MIB module. 

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Wednesday, June 01, 2005 5:08 PM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt
>

---

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

HI,

I believe that continuing to use USM for notifications would
be a VERY bad choice. Having spent the last 6 months adding
support for SNMPv3/USM to a product, the MOST troubling
part is explaining to people the concept of "authoritative
engineID" and then explaining that for traps, the sender
is the authoritative engine, but for informs the receiver
is the authoritative engine, which requires a double
configuration of user entries in the USM user table.

Give me a fricking break!

Then, look at the silly engineID discovery that is done
on sending informs. Who designed this stuff?

This issue just drive me crazy. Hardly anyone understands
the need to authoritative engineID. Many, if not all,
would not believe that it is technically possible for
either side to be the authoritative engine, and could
not list the trade-offs for each side.
(I'm stopping now...)

I truely believe that if a reasonable ISMS definition
is developed, that no one will use USM, if given the
choice between USM and ISMS.

Enjoy,
/david t. perkins
On Tue, 31 May 2005, David B Harrington wrote:
> Hi Sam,
> 
> I would use SSH as it was designed to be used. 
> 
> I am not very knowledgeable about the SSH suite, but I would expect to
> use the SSH transport layer, and the SSH authentication protocol. 
> 
> Netconf also runs over SSH, using the SSH transport and
> authentication; then the SSH connection protocol creates a session,
> and runs an SSH subsystem called netconf. I expect something
> comparable for SNMP. I consider it desirable to utilize a similar
> approach between netconf and SNMP, to the degree the two management
> protocols are similar.
> 
> I have not worked on the details of how the binary formatted SNMP
> messages might impact the SSH approach differently than the netconf
> approach. 
> 
> If it is difficult to make protocols not designed to support
> notifications meet notification requirements, and it is expected that
> USM will continue to be deployed for troubleshooting purposes when a
> TMSM solution is deployed for non-troubleshooting purposes, it might
> be reasonable to expect that notifications be sent using the USM
> security model rather than the TMSM security model. The cost of USM
> configuration for a security association with one or a few
> presumably-centralized notification receiver applications would be
> small compared to configuring the notification and filter tables and
> the VACM access tables of the SNMP engine, and once a security
> association is created between a "manager" and "agent" using TMSM, it
> should be easy to configure USM "users" that represent the
> notification receiver applications. 
> 
> David Harrington
> [email-masked]
> 
> > From: Sam Hartman [mailto:[email-masked]] 
> > Sent: Tuesday, May 31, 2005 10:40 PM
> > To: [email-masked]
> > Cc: 'Tom Petch'; [email-masked]
> > >>>>> "David" == David B Harrington <[email-masked]>
> writes:
> > 
> >     David> Hi Tom, TLS is "transport layer security", so it appears
> to
> >     David> me to be categorized as being an extension of the
> transport
> >     David> layer. But I could be wrong.
> > 
> >     David> SSH, SASL, BEEP, and other security-related protocols
> that
> >     David> are often layered atop TLS seem to be application layer
> >     David> protocols.
> > 
> >     David> I would be happy to modify the document to reflect the
> >     David> official categories.
> > 
> > 
> > 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.
> > 
> 
> 
>

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 9 Jun 2005 11:42:06 +0200

I have many times explained authoritative engine ids to users and know well the
bewildered look on their faces.

But the idea I think sound, and this has been reinforced by my recent
exploration of SSH and TLS.  Both are strongly asymmetric.  SSH has host key (ie
server) built in and crucial (I was going to say key) whereas going the other
way, client authentication is a separate, optional protocol.  Likewise in TLS,
it is the server certificate that is fundamental, the server may ask for a
client certificate.

Sad thing is, this is back to front (for me).  My #1 want is client
authentication when acting as a Command Generator and this SSH and TLS seem to
consider optional; whereas server authentication I can live without..

Tom Petch

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 09 Jun 2005 09:02:04 -0400

Tom Petch wrote:

> [...I did ...] recent

This is where the zero-client-preconfiguration magic originates (e.g. 
unauthenticated web client browsing is nonetheless "secure" according to 
consultant-backed risk analyses). A party's authentication requires this 
party's pre-configuration.

> consider optional; whereas server authentication I can live without..

The goal of isms has been stated as *zero* incremental authentication 
configuration requirement. Perhaps you need that your definition of SNMP 
client to be the exact same as the one in some AAA scheme. Then you 
would look at the AAA details to see if you can piggyback the SNMP 
application on it.

If any isms-specific authentication pre-configuration is totally out of 
the picture, I don't see another way.

Sincerely,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Sat, 18 Jun 2005 17:40:50 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Hi Sam, I am having difficulty reconciling my understanding
    David> of how an SNMP agent works, and the terminology you have
    David> used in your comments.  Please help me to bridge the gap.

    David> You talk about "agents capable of accepting commands using
    David> ssh for authentication" . As I see the SNMP approach,
    David> commands are the payload encapsulated within an SNMP
    David> message, and a message is authenticated as having been sent
    David> on behalf of a known user. 

So far, I agree.

    David> I envision SSH providing the
    David> transport of SNMP messages, and authenticating the message
    David> as having been sent on behalf of a known user. 

I'm not sure user is the right term here particularly when looking at
notifications.

    David> Do you mean
    David> "agents capable of accepting SNMP messages using SSH for
    David> authentication"?

No I'm not sure that means the same thing.  I mean what I said;)

    David> You say "agents ... will have sufficient credentials". The
    David> user's credentials are somehow made available to the

I mean agents as an architectural entity, including any security
services they rely on.  So yes, the credential may be part of the TLS
implementation or the ssh implementation.  But the point is that if
I'm going to contact an agent and send it a command, there is some
credential involved on the agent accepting the command.  In USM, the
credential is user (and engineid ) specific.  For a typical ssh cli
session and thus presumably for a typical ssh SNMP session if that
ever exists, there is a host key or GSS credential the agent uses to
authenticate the server side of the credential.  

Really agent is the wrong term here; I need a term that encompases the
whole engine and the security transport that it is using.

My point though is that if you can accept commands you have some
credential.  It turns out that ssh server credentials are roughly
symmetric and can be used as ssh client credentials.  The same is not
true for client credentials: most ssh clients do not have a sufficient
credential to act as an ssh server.

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 24 Jun 2005 18:48:42 +0200

<inline - perhaps a different set of words will help>
Tom Petch
----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 18, 2005 11:40 PM
Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt

> >>>>> "David" == David B Harrington <[email-masked]> writes:
<snip>
> I'm not sure user is the right term here particularly when looking at
I think the right term is principal.  SNMP Architecture (RFC 3411) defines all
activitities as taking place on behalf of a principal, who/which is identified
by a (model
independent) securityName, an abstract concept but something outside the snmp
entity (a bit like users versus user agents in e-mail).  In the USM, the
principal is a user, but given the use of securityName in the interchanges
between elements of the model, the idea of principal is part of the architecture
and not part of USM and so is a given for isms, whatever security model is used;
the architecture implies that it is a principal that has security credentials.
(I do not think this fits well with transport level security, where servers have
host keys and principals do not feature).

> No I'm not sure that means the same thing.  I mean what I said;)

Again, SNMP Architecture defines messages as the unit (containing a SNMP PDU)
which the security model sends on its way, not commands.
> whole engine and the security transport that it is using.

There isn't such a term at present:-)  SNMP Architecture defines SNMP engine
(dispatcher, message processing, access control, security subsystem) and SNMP
entity (SNMP engine plus SNMP applications); the transport, secure or not, is
beyond the pale.  We can invent terms for engine+transport or entity+transport
but their absence from SNMP Architecture will always leave some inconsistency.

> credential to act as an ssh server.
I agree but the credentials are of the server and have to be made into something
principal related because that is what SNMP Architecture says.

So, I wish the SNMP Architecture did not say what it does, but it does, and that
is where we are:-(

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 24 Jun 2005 15:52:37 -0400

Hi,

Tom, thanks for acting as interpreter. I agree with almost everything
you interpreted. It's close enough that I choose not to spend time
correcting the minor differences.
I'd rather discuss the SNMPv3 philosophy, and how that relates to the
current issues.

In SNMPv3, we deliberately provided for application-specific (SNMP)
authentication of the principal, because it is that authenticated
principal to which the application-specific access control is applied.
The operators who provided input to the SNMPv3 design process
requested the ability to distinguish users, so they could control and
audit who made which modifications to a device via SNMP. 

Some felt that authenticating an application (such as HPOV) was
adequate for many purposes, where a specific application is used to
configure certain aspects of network behavior via SNMP. 

It might be acceptable to have a combinations of users and
applications authenticated. Authenticating a notification receiver
application might be sufficient, but operators would need to be
careful about the information contained in notification varbinds to
ensure that information not read-accessible to a user-principal is not
revealed to the user via an application-principal.

I don't recall proponents for authenticating at the host level (except
for making the ASIs capable of passing transport info for
backwards-compatibility reasons). At the time, certificates were not
being used widely for the types of devices SNMP managed, and would
have been (and still frequently are) considered heavy-weight for
low-end SNMP-manageable devices. The consensus was that the SNMPv1
approach of authenticating based on a source address was inadequately
secure for access control and auditing purposes, as well as being hard
to achieve given address spoofing, DHCP, NAT, and so on. We
deliberately did not include transport info in the ASIs between the
transport-mapping and the secuirty models to discourage the very-weak
authentication based on source-address.

Trying to leverage an existing transport-layer authentication
infrastructure, there are a number of different approaches we could
use.

1) We could provide for two levels of authentication - one to
authenticate the message, and the other to authenticate the SNMP
principal for access control purposes. Thus it would be possible to
use TLS or SSH or IPSec to transport the message securely, and then
use another mechanism to authenticate the SNMP principal. There are
problems of getting an appropriate binding to prevent masquerade, but
that is one approach we could use. Of course, if we need to have an
SNMP-specific principal authentication anyway, then we might as well
use it to secure the message as well, as was done with USM.

2) We can have one level of authentication, that serves to
authenticate both the message and the principal to which we can apply
SNMP-specific access control. 

2a) If the transport-layer "principal" is a host, and we used the same
principal for the SNMP-access control, the granularity may not be
adequate for the requested SNMP access control and auditing.

2b) If the transport "principal" is an application, such as an
authenticated SSH-client, that may be adequate for both SNMP access
control and auditing, if access control/auditing at the application
granularity is adequate; I am of the impression it would not meet
operators' requirements. It may be adequate if the application has the
responsibility of authenticating the user that logs into the
application, and that is considered "good enough" for access control
and auditing purposes. 

2c) If the principal is a user, such as an operator, that seems to
best meet the requirements that the operators identified. The SNMPv3
(USM) approach is to provide the ability to identify a principal that
might be a user, an application, or a host (or other "principal" of
whatever nature. Ideally, a transport-layer security model would
permit the same levels of authentication where desired.

It might be possible to use SSH hostbased authentication. According to
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-secsh-use
rauth-27.txt, section 9, "Once the client host's identity is
established, authorization (but no further authentication) is
performed based on the user names on the server and the client, and
the client host name."  Note that the Internet Draft says the
hostbased "form of authentication is not suitable for high-security
sites". If we permit different types of authentication in SSH, we may
need to have different security models or the ability to assign
securityLevels based on the approach, so the access control system can
be configured accordingly.

David Harrington
[email-masked]

> From: Tom Petch [mailto:[email-masked]] 
> Sent: Friday, June 24, 2005 12:49 PM
> To: [email-masked]; Sam Hartman
> Cc: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 25 Jun 2005 06:37:37 -0700

David> 2b) If the transport "principal" is an application, such as an
David> authenticated SSH-client, that may be adequate for both SNMP
David> access control and auditing, if access control/auditing at the
David> application granularity is adequate;

David, I think your concept of where authentication here is slightly
broken.  You seem to be saying that a ssh client is authenticating the
user behind it and thus won't meet operator needs, which is bogus.  A
SSH connection authenticates the user just as much as SNMP does.  The
application will always have access to the credentials to send
authentication information to the other side, be it a SNMPv3/USM proof
of identity through a authenticated hash or via a SSH public/private
key pair signing or through a ...

The whole point of a transport underneath SNMP, which is at the
application layer (not at the host layer like IPsec or other lowere
protocols) is that a user has been authenticated already and the SNMP
application should have knowledge of that authentication.  SSH is
actually the easiest case of this, because it does operate at a
user-level authentication.  TLS is actually harder because by default
it doesn't without something like SASL combined with it.

-- 
Wes Hardaker
Sparta, Inc.