Subject: Re: [Isms] Where I find answers about USM?

From: Keith McCloghrie <[email-masked]>
Date: Mon, 6 Nov 2006 07:18:56 -0800 (PST)

>   this is my first msg here :)
    
Welcome.

>   I have recently started investigating SNMP, and SNMP security particulary.
>   I read the RFC 3414 (USM) and I have questions about it. The problem is 
>   that there is no longer an active working group for that.
>
>   I will be glad if you will tell me who can help,
    
The ISMS WG is defining a new Security Model for SNMPv3 to augment USM,
and you could ask your questions in that WG.  Alternatively, you could ask
on one of the OPS area mailing lists (see http://www.ops.ietf.org/), e.g.,
[email-masked].

> or just answer the next q's:

I'll try.

>   1. What is the need for two counters of time
> latestReceivedEngineTime and snmpEngineTime that are saved against all
> source engine.  The paragraph 2.3 says that it is against a threat of
> DoS by Replay attack but does not ellaborate. I think there is no such
> threat.

If I recall correctly, snmpEngineTime is adjusted (based on received
authentic messages) in order to prevent clock drift.  Such adjustments
could be used in a DOS attack to prevent the clock from moving forward.
E.g., capturing authentic messages and replaying them while they are
still authentic as a means of preventing the time window from moving
forward.  latestReceivedEngineTime prevents such an attack.

>   2. The process of Discovery (chapter 4) seems not to be supported
> by chapter 3. examples: how the discover gets the key that will be used
> by him in order to secure the 2nd message of his? where in 3.2 there is
> handling of incoming messages with zero values like the discovery (2nd
> message also)

Discovery is about discovering the presence of other engines, so that
(unprotected) communication can can occur.  It does not discover the
secrets which are necessary for protected communcation.

Keith.

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

---

From: Ziv Artzi <[email-masked]>
Date: Sun, 12 Nov 2006 04:12:56 -0800 (PST)

Hi Keith,
   
  Thanks for the fast reply.
   
  However, I still don't understand the threat of preventing the snmpEngineTime from advancing. I will explain it in 2 ways:
  1. Replaying authentic message cannot cause the snmpEngineTime to move downward since it's defined that this value is changed only in the next cases:
     a. reset, initialization => keeping another variable won't help, it will suffer the same behvior
     b. getting a message with equal snmpEngingBoots in the SNMP header and in local notion, but with snmpEngineTime bigger in the header than the local notion => snmpEngineTime got bigger
    c. getting a message with snmpEngingBoots bigger in the SNMP header than local notion and then snmpEngineTime will get the value from the SNMP header => (snmpEngingBoots , snmpEngineTime ) got bigger lexicographically as an ordered couple.
   
  in all cases, i don't see how the time window isn't advancing (it can stay in place, but the attacker cannot prevent it from advancing by real authentic messages!).
   
  2. snmpEngineTime and latestReceivedEngineTime seem to be updated together to the same value (from the SNMP header) so when are they different?
   
  can you or anyone check it up please? 
   
  thanks,
  Ziv

 
---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Nov 2006 22:00:26 -0500

Hi Ziv,
 
We did a great deal of work considering all the possible variations,
felt there was a DoS attack, and detailed how to avoid the DoS attack.

I do not see what the community will gain from having this threat
re-examined and re-justified. Doing so will cost the community
resources that could be allocated to doing other things that are more
beneficial. Can you justify our spending time revisiting this design
decision?
 
If I were to check this, the way I would do it would be to go through
rfc3414 elements of procedure and detail the conditional logic steps
and the relevant processing steps, in a flowchart or something
similar. Then I would assign some reasonable values to the relevant
variables, and then vary them to see how they would impact the
processing. I would make it a point to **identify the relevant
clauses** that cause certain processing to occur, given the values of
the variables. I think you might find the answer to your question if
you do this time-consuming exercise.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]
co-chair SNMPv3 WG, concluded

  _____  

From: Ziv Artzi [mailto:[email-masked]] 
Sent: Sunday, November 12, 2006 4:13 AM
To: Keith McCloghrie
Cc: [email-masked]
Subject: Re: [Isms] Where I find answers about USM?

Hi Keith,

However, I still don't understand the threat of preventing the
snmpEngineTime from advancing. I will explain it in 2 ways:
1. Replaying authentic message cannot cause the snmpEngineTime to move
downward since it's defined that this value is changed only in the
next cases:
   a. reset, initialization => keeping another variable won't help, it
will suffer the same behvior
   b. getting a message with equal snmpEngingBoots in the SNMP header
and in local notion, but with snmpEngineTime bigger in the header than
the local notion => snmpEngineTime got bigger
  c. getting a message with snmpEngingBoots bigger in the SNMP header
than local notion and then snmpEngineTime will get the value from the
SNMP header => (snmpEngingBoots , snmpEngineTime ) got bigger
lexicographically as an ordered couple.
 
in all cases, i don't see how the time window isn't advancing (it can
stay in place, but the attacker cannot prevent it from advancing by
real authentic messages!).
 
2. snmpEngineTime and latestReceivedEngineTime seem to be updated
together to the same value (from the SNMP header) so when are they
different?

thanks,
Ziv

could be used in a DOS attack to prevent the clock from moving
forward.

  _____  

Want to start your own business? Learn how on Yahoo!
<http://us.rd.yahoo.com/evt=41244/*http://smallbusiness.yahoo.com/r-in
dex> Small Business.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 17 Nov 2006 14:03:46 +0100

Hello All,
After participating in the Isms wg meeting in San Diego I would like to make some comments 
as a potential user of ISMS. Sorry if I misunderstand the situation.

Isms is proceeding well with their work but only officially.

In reallity ISMS gave up on applying their new security solution to
agent initiated traffic (notifications, traps). This means that for
these to be secured you still need USM security. But the whole Isms
started by hating USM, as it is too much work to configure.

Alternatives:
1) Forget the whole Isms as useless
2) Use Isms for get, set type operations and use USM security for
notifications/traps. In this case we have 2 security models to configure
instead of one, so SNMP security configuration got even more complicated.
3) Use Isms for get,set type of operations and do not secure
notifications. This assumes that notifications are inherently less
sensitive then get/set commands. While this might be true in some cases
it is not generally accepted. We might still try to propose this
alternative to customers and have USM security as a backup.

Personal opinion: push Isms to solve the problem of notifications or forget
about Isms.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Nov 2006 15:28:37 +0100

> started by hating USM, as it is too much work to configure.

I do not think this is a correct summary if you happen to read the
specifications. The documents do not state that notifications are
dropped somehow on the floor if you try to send them.

What ISMS did not figure out (yet?) is how to send notifications over
SSH without having to provision extra credentials and not reversing
authenticated identities. Several options were discussed, none did
really convince so far. Perhaps we simply have to accept that
notifications over SSH require credentials to be provisioned.

Concerning USM: What really bothers me personally is the lack of
context engineID discovery. I want to do something as simple as

   snmpwalk ssh:myagent ifTable

and we are close to that except that the context engineID is missing.
>From my understanding of the problem, the easiest solution seems to
follow a proposal by Dave Perkins to introduce a default context
engineID, much like the default context name. Having to send USM
messages or SNMPv1 messages just to get ISMS going seems like an ugly
hack.

Introduction of a default context engineID probably falls out of the
charter of this WG; not sure whether something like this can be
introduced by means of an individual submission as an enhancement of
SNMPv3. Without a working context engineID discovery solution, it will
be much more difficult to upgrade the many applications that are
internally still SNMPv1/SNMPv2c and do not maintain engineIDs to use a
secure transport.

/js

-- 
Juergen Schoenwaelder		 International University Bremen
				 (Jacobs University Bremen as of Spring 2007)
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 17 Nov 2006 16:29:06 +0100

Hello,
Thanks for the info. From the meeting I had the feeling that Isms intends to drop the 
issue of notifications. It seems that this was my misunderstanding. I am really happy that 
you are working on the solution.
Balazs

PS. I did read much of the drafts.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 17 Nov 2006 12:51:44 -0500

Hi Balazs,

I think you misunderstand what was said at the ISMS meeting. Since I
did the presentation, I apologize for not being clearer.

Notifications are supported by ISMS. There are some wrinkles however
to make the support different than the support provided by USM.

1) There may be some events that occur before the SSH session is
created, especially if the creation of the session fails for some
reason. Since SSH authentication may depend on a third party, such as
a RADIUS server, to perform authentication, in a "broken" network it
may be impossible to establish the session to send such notifications.
USM has no third-party dependencies, so it does not face this problem.
This is a corner case and would probably have very little impact on
the day-to-day management of the network.

One solution for this would be to have the snmp application choose to
send the notification over USM if sending it over SSH fails.

The necessary configuration of USM would involve provisioning one USM
user (e.g. superuser) to send corner case notifications.

2) SNMPv3 usage (with USM) has been described with an implicit
assumption that the same principals that perform request-response
interactions would be the targets of notifications, and therefore one
VACM entry for a principal suffices for both usages. This works
because USM uses symmetric authentication - regardless of direction,
the authentication is done for the same level of principal (e.g.
user).

SSH uses assymmetric authentication - the client side typically
authenticates at a "user" level, while the server is authenticated at
the host level. This is different than the implicit assumption of
SNMPv3, and we need to decide if this is acceptable.

3) In reality the applications that receive notifications are
frequently not the same applications that perform R/R processing. In
practical terms what this means is that there are likely to be
different entries in the authentication system and the access control
system for the R/R applications and for the notifications application.

It may be acceptable for the notification receiver to be authenticated
at the host level, while the R/R application is authenticated at the
"user" level, but we have not gotten any feedback from operators on
this point.

4) If it is not acceptable to use asymmetric authentication, then we
need to determine how to provide symmetric (or at least equivalent
level) authentication.  

The apparently simplest way to reuse existing security mechanisms
would be to have the agent open a connection as the client for
notifications, and the manager open a connection as the client for R/R
commands. However, since there is no operator at the agent to initiate
communications and provide credentials, the agent would need to be
provisioned with the credentials for the notification sender. That is
considered undesirable.

--
So ISMS is facing some problems regarding notifications, but ISMS has
not given up applying SSH secure transport to notifications.

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

> -----Original Message-----
> From: Balazs Lengyel [mailto:[email-masked]] 
> Sent: Friday, November 17, 2006 8:04 AM
> To: [email-masked]
> Subject: [Isms] ISMS without support for notifications, is it
useful?

---

From: "David Harrington" <[email-masked]>
Date: Fri, 17 Nov 2006 13:02:08 -0500

useful?
> Personal opinion: push Isms to solve the problem of 
Hi Balzs,

Just to make it very clear, if you know how to solve the problems we
are facing with notifications, we welcome your input.

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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 20 Nov 2006 09:10:25 +0100

Thanks, for clarifying the question. Balazs