Subject: [Isms] isms wg status and actions

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2009 13:53:43 +0100

I like to summarize how I see the status of the ISMS WG at this point
in time by looking at our four chartered documents:

1) Remote Authentication Dial-In User Service (RADIUS) Usage for Simple
   Network Management Protocol (SNMP) Transport Models
   <draft-ietf-isms-radius-usage-05.txt>

   A new version was posted by David Nelson on March 8th incorporating
   WG last call feedback. I asked people to check the changes until
   March 23rd. Dan Romascanu was so kind to forward this message to
   the RADIUSEXT WG and so far we received one editorial nit. If no
   technical issues are raised, then this document will be ready to be
   delivered to Pasi by the upcoming IETF meeting.

2) Transport Subsystem for the Simple Network Management Protocol (SNMP)
   <draft-ietf-isms-tmsm-16.txt>

   The latest version was posted on February 25th and I asked people
   on February 26th to check the changes and to report by March 6th.
   My reading of the mailing list is that no issues were raised and
   hence I conclude that this document is ready to be delivered to
   Pasi. I take the token to produce the necessary document writeups.

3) Transport Security Model for SNMP
   <draft-ietf-isms-transport-security-model-12.txt>

   A new version was posted on March 9th incorporating changes
   discussed recently on the mailing list. The changes are very minor,
   essentially removing the rtr-nyc4@ example since the user@ notation
   is considered with rough consensus to be SSH specific. I do not
   think there are any other outstanding open issues with this
   document. So please check the changes and if I do not hear about
   technical problems by March 23rd, I consider this document ready to
   be delivered to Pasi by the upcoming IETF meeting.

4) Secure Shell Transport Model for SNMP
   <draft-ietf-isms-secshell-15.txt>

   Most of the recent email discussion (which I think we quite
   productive in moving things forward - thanks folks!) centered
   around this document. A new version was posted on March 9th
   incorporating changes that were discussed on the mailing list. In
   short, additional explanatory text was added to motivate the user@
   notation and the elements of procedure have been rewritten in an
   attempt to simplify them. Please review this new version and let us
   know by March 23rd whether there are any technical showstoppers
   left. Please post issues as soon as possible so that we can
   continue working on resolutions as much as possible here on the
   list before the IETF meeting.

Please let me know if you disagree with my assessment where we are
with our chartered work item. I believe we are really very close to be
done - so lets try to finish this and deliver by the next IETF.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 10 Mar 2009 18:19:19 +0100

Juergen

tmsm has a 'implementatioins' in 3.3.1 to be revised at some point.

Tom Petch

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Cc: "Pasi Eronen" <[email-masked]>
Sent: Tuesday, March 10, 2009 1:53 PM
Subject: [Isms] isms wg status and actions

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 11 Mar 2009 10:24:33 +0100

sshtm Editorial (I think)

3.1.2 "  requirements of securityLevel were met The SSH Transport Model"
lacks a period

3.1.4 (end) " and/or port numbers) will each result in individual SSH sessions."
suggest "different SSH sessions" since different is used earlier in the
sentence.

4.1.2 tmSessionID is also used to identify sessions in an SSH client as per 5.3
6) which 4.1.2 sort of omits stressing only its role in a CR
Suggest adding

"tmSessionID is also used when the Secure Shell Transport Model  is an SSH
client in order to identify the session over which a message is received."

although that might be a bit too coy.  I am thinking of answering the queries
from Jeff about the role of tmSessionID.

5.1.1) I read "session identifier" as code for tmSessionID. If so, I would
rather see that stated explicitly. 5.3 6) does explicitly mention tmSessionID in
this role.

5.1 2) C "(e.g. the value from step"
suggest "(i.e. the value from step"

5.1 3) C "(e.g. the value from step"
suggest "(i.e. the value from step"

5.2 3) B I think that as per Jeff's e-mail 3/9/9, this should start
" B.  If tmSameSecurity is true and there is a session with a matching
sessionID, "

5.2.3) C ditto
" C.  If tmSameSecurity is false and there is a session that matches the
tmTransportAddress "

5.2 3) D is interesting in that it caches the destTransport... parameters and
not the tmTransport.. ones.  This is correct, in the sense that the dest..
variants have come from application to Dispatcher to sshtm and need to go back
to the Dispatcher with any response.  But it is interesting in that sshtm has
just used the tm.. variants in tmStateReference, which have come from Dispatcher
to MPP to Security Model to cache to sshtm,  to open a session.  Could they be
different?  I do not think so with tsm as currently written, could be with a
different Security Model.  So I think that the text is correct but we might get
asked if this is really right.

5.3 3) 1) "that user-name string that should be presented to the ssh server "
spurious second that

5.3 3) 2) "SSH principal" should be "SSH user"

5.3 generally hyphenates user-name while the earlier parts of the I-D do not,
and the MIB module throws in a few username.  I would prefer consistency.
RFC4252 uses user name so I would suggest that.

That apart, I have not looked at the MIB module.

Tom Petch

ps I read in the newspapers that my ISP might go bankrupt today, so if I
disappear from this list, that is why.  Reading posts in the archives is easy,
posting becomes rather harder:-(

---

From: "tom.petch" <[email-masked]>
Date: Tue, 17 Mar 2009 10:32:41 +0100

I would like to give one of these topics another prod.

sshtm is correct but could confuse, indeed I believe that it may already have
done so.

 4.1.2 gives a clear description of the role of tmSessionID in the cache and
covers the case in the CR when a Response must use the same session as the
Request.  No other use case is mentioned there.

This is fine until you reach 5.3 6) when tmSessionID appears again in the
context of openSession which is clearly CG and not CR; and there is no other
reference to its use in a CG.

I think that this can confuse, indeed may be why Jeff suggested a fortnight ago
JH> My reading was that tmSessionID was meaningless unless tmSameSecurity
JH> is true, and so I was trying to arrive at wording that ensures that
JH> the sessionID is not used when tmSameSecurity is not true.
ie the only use case for tmSessionID is in the CR with tmSameSecurity set to
true which is what 4.1.2 suggests.

There is a need in the CG, as we have agreed, to identify on an inbound message
the parameters with which the session was set up so that these can be passed to
the Dispatcher else the message cannot get to the right application with the
right parameters.  I see this as so close to the use of tmSessionID in a CR that
we should call it tmSessionID, indeed that is what I read into the current text
in openSession.  But then I think this needs alluding to in 4.1.2 eg by adding

"tmSessionID may also be used to ensure that the correct parameters are
associated with an incoming Response so that the message is passed correctly to
the
application"

and by slotting into the middle of 5.1 1)
"This may be achieved by the use of tmSessionID".

Wes's response is 'too much implementation detail'.  Agreed, but that is the
house style of these memos and it is far too late to change that; rather, make
the level of detail consistent where I believe that what we say for the CR is
currently much more detailed than what we say for the CG.  Hence my proposed
additions.  As I say, not wrong but could be clearer.

Tom Petch

----- Original Message -----
From: "tom.petch" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Cc: "Pasi Eronen" <[email-masked]>
Sent: Wednesday, March 11, 2009 10:24 AM
Subject: Re: [Isms] isms wg status and actions sshtm