Subject: [Isms] RE: interim meeting preparation

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 Jan 2006 13:08:57 -0500

Hi Juergen,

Sorry for the slow response; I was in China and email was challenging
at times.

Your list of issues looks good to drive the agenda. 

Recognize that I had moved the discussion from high-level discussion
to low-level details for a reason. It is fairly easy to answer your
high-level questions:
	SQ1: yes
	SQ2: yes
	SQ3: no
These answers could also be answered differently:
	SQ1: no (the notifications should be discarded if no session
exists)
	SQ2: no (they should establish their own sessions with reverse
direction)
	SQ3: yes
It really doesn't matter much which way they are answered; it's six
one way, half-a-dozen the other way - it doesn't matter much which the
answer is until you get into the details. Regardless of which way your
questions are answered, it is not clear WHEN and HOW it CAN be done.
And without knowing WHEN and HOW it should be done, we cannot advance
the documents.

A previous question asked at a high level:
	Does SSH need to pass the authenticated username to the SNMP
engine? Yes
	The high-level question was easy to answer; we've known since
long before ISMS was chartered that any lower security layer would
need to pass the username so we could map it to securityName.
	But it took months of asking the SSH experts to determine
where that information comes from to get a concrete answer that I
could use in the elements of procedure. The SSH experts disagreed on
whether it was reasonable to extract the user name field of the
SSH_MSG_USERAUTH_REQUEST. They finally agreed it could be done, but it
would have to be done in an implementation-dependent manner, partly
because it may not be possible to get access to the
SSH_MSG_USERAUTH_REQUEST with some SSH implementations.
	There is also the question of whether the securityName should
reflect the authenticated user name, because securityName is used by
SNMP, not for authentication purposes, but for authorization purposes,
and if the AAA subsystem used by the SSH subsystem returns an
*authorization* username to the SSH layer that is different than the
username used for authentication, should the username provided to SNMP
by SSH be the authenticated username or the authorized username?
	 The detailed answer (HOW?) was only decidied at the last IETF
meeting, and I hope that the detailed answer is final and not subject
to further debate.

So be careful about going for only the high-level answers, without
getting the low-level details of WHEN and HOW to do it. We need to
answer the HOW, to determine what information needs to be available to
do it, and we need to answer the WHEN to determine whether the
necessary information is available at the desired point in the
elements of procedure. Without those details, we cannot write the
elements of procedure, or the elements of procedure will need to be
filled with a bunch of "magic happens here" procedures.

The questions could be phrased differently:
SQ1: Are notifications originators responsible to establish sessions
for notification delivery, and if so, how and when do they do so?
SQ2: Can notification originators (re-)use already established
sessions for notification delivery, and if so, how and when do they
determine that a session does or does not exist, and how and when do
they choose a session with the appropriate security characteristics
(both SSH and SNMP)?
SQ3: Is it required that a session already exists before a
notification can be sent, and if so, when and how does the NG (or
message processor) determine whether a session exists or not, and what
happens if there is no session?
SQ4: Are sessions torn down when a logical operation is complete, and
if so, HOW and WHEN does the engine know that a logical operation is
complete (for example, when a message is discarded during processing
and no Report is generated)? 

And so on...

David Harrington
[email-masked]

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, January 24, 2006 4:58 PM
> To: Dave Harrington
> Cc: Juergen Quittek
> Subject: interim meeting preparation
> 
> Dave,
> 
> it is time that we prepare the interim and also entertain some
> discussion on the WG mailing list to better understand the design
> space. While looking at the open issues list again, I felt that
> they are too detailed and tend to hide the much more fundamental
> questions that we IMHO need to answer first.
> 
> I tried to formulate a set of questions to which I would like to get
> answers during the interim (see attachment). Please check whether
the
> questions make sense and feel free to add more questions as you see
> them (but lets avoid to go down to too much details).
> 
> I like to post a revised issue list to the WG mailing list by the
end
> of the week latest to get some people thinking about ISMS again.
> 
> /js
> 
> PS: The source of the issue list is on the ISMS wiki page at
>     <http://www.eecs.iu-bremen.de/wiki/index.php/ISMS_Working_Group>
> 
> -- 
> 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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jan 2006 21:06:00 +0100

On Tue, Jan 31, 2006 at 01:08:57PM -0500, David B Harrington wrote:
 
[...]

> filled with a bunch of "magic happens here" procedures.

My intention was indeed to look into the details (how and when) in
order to find answers to the questions or to see whether answers are
viable. (I would not travel to Boston to just count a few yes/nos.)
 
> and no Report is generated)? 

I have put the revised questions on the wiki page. Feel free to send
me more input. I think we now make progress towards a decent set of
questions we have to work through. Lets continue.

If someone has concrete input to the how and whens, please by all
means send your input to this list prior to the interim meeting.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany