Subject: [Isms] Do Informs work

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 22 Mar 2007 14:03:07 +0100

Juergen asked me to check if INFORMS work, since this was
raised as a possible problem/issue.

I have reread Jeff Case's comments a few times, but it is
unclear as to where he thinks it cannot work.

There are tow things I focused on, based on the Jeff's message,

Jeff wrote:
> 2.  i mention this because the experience with the project
>     causes me to question one of the draft's fundamental
>     tenets -- that you can do what you want to do without being
>     forced to compromise anything in arch, v3mp, and/or usm
> 
>     in particular, while your design probably works flawlessly for
>     gets and sets, and might work for traps as well, it would
>     be helpful if you could explain to me how informs work in
>     a way that is consistent with the above specs
>     (yes, i read and reread page 15 several times including the
>     waffle words found therein but maybe i am just dense and/or
>     missed something somewhere else)
> 

So the 2 things that I used as hints are:

a). Can we do what we want to do without being
    forced to compromise anything in arch, v3mp, and/or usm

b). Is page 15 causing trouble. This was page 15 in rev 05, and so I
    take it to be section:
        3.3.1.  Session Establishment Requirements

W.r.t. point b), I have now also reread that secsion a few times,
and indeed, I am not sure what that section is telling me. It is 
saying things that I can't prove are wrong, but it also is not
clear to me what it wants to tell me.

W.r.t. point a), I went through the 3411, 3412 and 3414 documents
and checked as much as I could why a GET/SET would work flawlessly
and an why an INFORM would fail.

I cannot find it and prove that it will not work.
But I did find that the one thing that we CHANGE for INFORMs is
that we are fidddling with the AUTHORITATIVE securityEngineID.

In the USM model, we extract the authoritative EngineID from the
securityParameters in the SNMPv3 message. 
In the TMSM and transport-security-model, we do not extract it
from the SNMPv3 message at all, we just SET it to the engineID
of the receiving engine, as per sect 5.2, point 1) of
draft-ietf-isms-transport-security-model-03.txt.

If it is just security-model-related issue (some are claiming that
we only need/use that for the time sync), then  I believe our
security experts have told us it is not an issue.

BUT... the question still is if it is indeed ONLY a security-model
related issue. After all, we do pass a securityEngineID around
in the various ASIs outside of the securityModel. the ASI lists
the paramter as:

     OUT  securityEngineID          -- authoritative SNMP entity

so the "authoritative seems to have meaning outside of the
securityModel. WE asked Steve Waldbusser (some 1.5 year ago) if
he remembered why this was so important. I have included below
Steve's posting about the topic from oktober 2005. Specifically
the last para in his posting states:

   I haven't been following your discussion so I might be wrong about
the 
   implications, but it seems to me that the implication is that the
notion 
   of authoritative is really a snmpv3 notion and not just a USM notion.

I hope this helps in our discussions this afternoon.

If Steve reads this, maybe he can also chime in.

If Jeff Case (or one of his employees or close friends) reads this, 
maybe he can chime in too (or his employees/friends can motivate
him to chime in).

Bert
		-----Original Message-----
		From: [email-masked] 
		[mailto:[email-masked]]On
		Behalf Of Steve Waldbusser
		Sent: Thursday, October 06, 2005 05:13
		To: [email-masked]
		Subject: Re: [Isms] authoritative

		David H. and Bert asked me to give some background on
this because I 
		represented one end of a long debate on this issue about
10 years ago.
		
		My point back then was that it is very important for
responders to be 
		authoritative (as opposed to initiators being
authoritative)
		
		In this type of communication, one end is deemed
authoritative and 
		typically has keys stored in long-term storage. The
other end either 
		gets the key from a human or has a "cached" copy of the
key (I say 
		"cached" because in the event the authoritative end says
the key is 
		wrong, it is simply discarded at which point the usual
fallback is to 
		prompt the user for the correct key).
		
		We are very accustomed to the situation where the
responder is 
		authoritative and I guess we don't give it much thought.
A 
		transaction 
		initiated by a user asks the user for the key and sends
it. If the 
		responder says the key is wrong, the user is prompted
for a 
		new one. If 
		the transaction is initiated by unattended software, the
key 
		must be cached.
		
		But imagine the case if the initiator was authoritative.
Then the 
		responder must be the end with the human and/or the
cached 
		key. When a 
		request arrives at the responder, a human can't react
quickly 
		enough to 
		a prompt to type the key within the retransmit period so
this doesn't 
		work (and there may not be a human or the right human
sitting at the 
		responder anyway). So basically we are forced to cache
the 
		key. That's 
		not so bad until we ask which keys are we going to
cache? 
		Unfortunately, 
		one answer is *all of them*. If there are 1000 potential

		initiators each 
		with 10 users, then I have to cache all 10,000 keys
because only the 
		initiators will know if they ever have any intention of
sending me a 
		transaction and I need to be prepared in case they do.
An 
		alternative is 
		to treat it as a provisioning task: when I configure a
system to 
		initiate transactions, I must load the key into all
systems 
		that I plan 
		to communicate with which is a burden best avoided. Plus
it 
		seems that 
		having all of those keys floating around might not be in
the best 
		interests of security.
		
		To summarize, making the initiator authoritative means
either:
		- a massive configuration of all possible initiators in
all possible 
		responders; or,
		- an additional, expensive provisioning step for setting
up a new 
		initiator (or even if I'm just adding a new
communications 
		target for an 
		existing initiator).
		
		Most apps (email, fileshare, web, ssh) follow the
"responder is 
		authoritative" model. I can't think of any exceptions.
		
		I haven't been following your discussion so I might be
wrong 
		about the 
		implications, but it seems to me that the implication is
that 
		the notion 
		of authoritative is really a snmpv3 notion and not just
a USM notion.

		Steve

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

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