[13:52:26] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[14:12:01] --- Dave Nelson has joined
[14:12:42] <Dave Nelson> BTW, we are in Ming.
[14:13:13] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Ming does not have audio, right?
[14:13:31] <Dave Nelson> No, it does not.
[14:13:58] --- dbh2 has joined
[14:15:43] <Dave Nelson> Discussion ow what we need to do at this meeting...
[14:15:59] <Dave Nelson> Notifications at the top of hte list?
[14:16:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> For me, this is the biggest open issue to be solved.
[14:16:46] <Dave Nelson> Prepare discussion points for the session tomorrow.
[14:18:08] <Dave Nelson> Dave Perkins syaing that everyting with security is session based.
[14:18:53] <Dave Nelson> Session means you have authenticated, and have a handle -- could be session keys.
[14:19:20] <Dave Nelson> Dave H. not every security solution will be session based.
[14:19:47] <Dave Nelson> Jeff H. depends on how you define the bounds of the session.
[14:21:08] <Dave Nelson> Jeff H. setting up keys is setting up credentials for futrure authentication.
[14:22:02] <Dave Nelson> Jeff H. no session context for traps.
[14:22:27] <Dave Nelson> Jeff H> SSH-SM as defined to date does have sesson context.
[14:24:08] <Dave Nelson> Dave H. take session discussion out of the SSH-SM document?
[14:24:37] <Dave Nelson> Dave H. put it in the TMSM document?
[14:25:59] <Dave Nelson> Dave H every TMSM model be session based?
[14:26:30] <dbh2> I have already moved all session discussion to TMSM, but don't make session-based mandatory.
[14:26:38] <Dave Nelson> Jeff H. stop short of requring every method to behave this way.
[14:29:35] <dbh2> DN: in RADEXT session this morning, there was some discussion of secdurity issues with authorize only.
[14:29:57] <dbh2> DN: authorize-only without authn could leave a server ope to DoS.
[14:30:22] <dbh2> JH,JO: there would be message authn, in the authz-only request.
[14:31:04] <dbh2> DN: the internal of ASIs can wait until some things gel, and the authors know generally what they are. There is some radext work to embrace authz-only.
[14:35:17] <dbh2> JH updates Eliot and Chris Lonvick about decision to separate authn and authz.
[14:36:32] <dbh2> JH and Eliot discuss what is in scope for ISMS.
[14:37:12] <Dave Nelson> JH questions utility of separating authentication adnauthorization.
[14:37:44] <Dave Nelson> JH assertion based on what he's hear from operators.
[14:37:47] <dbh2> JH: te point is to use existing authn; what authz-only does is allow operators to use their existig authn and to then use radius fr authz.
[14:42:18] <dbh2> JQ: wat questions do we need to address during the meeting tomorrow?
[14:42:47] <dbh2> DN: note that RADEXT does not have the charter to change the protocol for ISMS.
[14:47:15] <dbh2> action item: JQ will ask that the wiki link be acdded to the charter.
[14:48:18] <dbh2> link: http://www.eecs.iu-bremen.de/wiki/index.php/ISMS_Working_Group
[14:50:12] <dbh2> After the meeting, sam and jeff spoke about the noritifcation and the reverse connection issue, and they reached a conclusion that was obvious, but jeff cannot remeber what it was.
[14:51:02] <dbh2> So there needs to be a mapping between host and a security prinsipal.
[14:53:06] <dbh2> try again .. a mapping between SSH hostname (or whatever, since SSH does not have a term for this), and the SNMP principal that snmp uses.
[14:55:38] <Dave Nelson> Attemting to address the notification questions...
[14:57:19] <Dave Nelson> JH use of public key of the user or a public key belong to the host an a username significant on that host.
[14:57:55] <Dave Nelson> Wiki question AQ1.
[14:58:05] <Dave Nelson> Also AQ2.
[14:58:36] <Dave Nelson> JH probably never both for any given authentication, but it could be either.
[14:58:46] <Dave Nelson> JH AQ1 ans, probably yes.
[14:58:59] <Dave Nelson> JH AQ2, only if you wan to.
[14:59:00] <dbh2> IN some circumstances, the NO will need to set up a session.
[14:59:41] <dbh2> AQ2: if session established by notify-receiver,
[14:59:48] <Dave Nelson> JH AQ1 mandatory to mimpelemt.
[14:59:58] <Dave Nelson> implement
[15:00:02] <dbh2> AQ1 will be mandatory; AQ2 if you are reusing a channel.
[15:01:35] <dbh2> (the last comment fron JH)
[15:03:21] <dbh2> AQ4: JH - no. this cannot be done in ssh.
[15:05:20] <dbh2> JH: AQ4: once an ssh session has been established, higher layere things like channel-establishment are symmetrical
[15:07:43] <dbh2> JQ: if manager to-agent has been established client-to-server (AQ1), then it might be reasonable to send notifications back via AQ2.
[15:08:19] <dbh2> JH: AQ3 ties these together. the answre is yes, AQ1 should be mandatory and AQ2 should be recommended, and must be runtime configurable.
[15:08:44] <dbh2> JO: what does runtime configurable mean?
[15:09:27] <dbh2> JH: the real gist of AQ3 is do we need to discuss howe to do this in the protocol? I think the answer is yes.
[15:09:37] <dbh2> JQ: can this be done with a config file?
[15:10:08] <dbh2> JH: possibly, but operators want this to be configurable via MIBs.
[15:10:32] <dbh2> DP: none of the conig is done vi asnmp; it is done through cli.
[15:11:00] <j.schoenwaelder@jabber.eecs.iu-bremen.de> not really, snmp folks typically figure out how to do things via mibs, implementors wrap that in cli commands and this is what operators use
[15:11:38] <dbh2> JH: then the credentials can be specified by cli.
[15:12:58] <j.schoenwaelder@jabber.eecs.iu-bremen.de> in practical terms yes, but what we provide are mib tables
[15:13:02] <dbh2> JQ: it must e confugrable, but we don't have to specify how in isms
[15:14:04] <dbh2> JQ: we can complete our charter without specifying the mis for config.
[15:14:22] <dbh2> JS, do you concur?
[15:14:47] <j.schoenwaelder@jabber.eecs.iu-bremen.de> i have to read the charter again - traditionally, snmp folks tried to be complete in what they do
[15:17:18] <j.schoenwaelder@jabber.eecs.iu-bremen.de> it seems that the charter is silent about this
[15:18:25] <j.schoenwaelder@jabber.eecs.iu-bremen.de> as an implementor of isms, I would like to know what needs to be configured (a management considerations section ;-)
[15:20:48] <dbh2> consensus: we can define WHAT, but we don't need to say how.
[15:23:23] <dbh2> The implication of the "no" answer to AQ4 is an open question whether the SSH "SHOULD NOT" in subsystems document; we may need to say "for ISMS, the SHOULD NOT is overridable" Further discussion is needed.
[15:23:35] <dbh2> Further discussion needed by SSH experts.
[15:26:12] <dbh2> JH: SQ1 - yes; soemtimes you are forced to establish a session, and if so, under what conditions is it needed at all?
[15:26:28] <dbh2> JH: the when is as already stated in the EOP.
[15:26:49] <dbh2> JH: the conditions are when you don't have a session established yet.
[15:27:18] <dbh2> JH: SQ1 - some of this is not specific to nitifications.
[15:27:50] <dbh2> JH: SQ3 - no, it isn't required, which is why SQ1 is yes.
[15:28:44] <dbh2> JH: Can NO use already established sessions? This question should be can NO reuse a RR session?
[15:31:07] <dbh2> JH: For NO, it doesn't know about any session ifno, so it would need to select based on transport, securityname/model/level.
[15:33:10] <dbh2> given the info from a notify-mib that includes transport, securityNML, we should be able to determine if an approrpriate session exists
[15:34:03] <dbh2> DH: do we need to know the directionality of a session?
[15:34:27] <dbh2> JH: if we allow the RR reuse, then we don't care about directionality.
[15:34:41] <dbh2> If we don't allow it, then we need to know directionality.
[15:37:15] <dbh2> JH: AQ1 and SQ1 imply a question that is not directly asked.
[15:37:56] <dbh2> Do we require people sending notify to always buiold the session; if so, we cannot reuse sessions without knowing dorectionality.
[15:39:31] <dbh2> JS - do you have a Skype ID?
[15:40:48] <dbh2> If we will require NO to originate sessions for security purposes, then they cannot reuse RR sessiosn.
[15:43:13] <j.schoenwaelder@jabber.eecs.iu-bremen.de> yes - my skype id is j.schoenwaelder (how boring)
[15:44:19] <Dave Nelson> OK, so Elliot is attempting to connect....
[15:47:13] <dbh2> dbh: does "mapping" mean we need to statically preconfigure the agent?
[15:47:42] <dbh2> JH: no, it is as dynamic as the table to send notifications, or it can be a function based on your authen tication infrastructure, such as who is your root CA?
[15:49:02] <dbh2> JH: the ssh mechanisms make it no more inconvenient than ISMS is now, and can make it easier if that is how they do it elsewhere.
[15:49:23] <dbh2> i.e. If they choose as simple mechanisms for other SSH usages, it will be simple for SNMP.
[15:49:39] <Dave Nelson> EL: Would it be helpful to have examples?
[15:49:40] <j.schoenwaelder@jabber.eecs.iu-bremen.de> FYI: I turned off my microphone and now I can actually understand you well (since skype has less echo supression to do)
[15:50:47] <Dave Nelson> Examples to be createdandsent ofline.
[15:50:50] <dbh2> somebody will send dbh samples to be sure it is clearly enough understaood for editing purposes.
[15:52:22] <Dave Nelson> JH SQ4 is no.
[15:52:49] <Dave Nelson> JH SQ% when you get into such a situation, you tear down the session.
[15:53:03] <dbh2> JQ: AQ and SQ issues are fairly complete. SQ4 is no; SQ5 is "tear down a session - which is implementation-dependent."
[15:53:04] <Dave Nelson> Implementation matter which to tear down.
[15:53:34] <Dave Nelson> SQ^ mostely an implementation matter.
[15:53:45] <dbh2> SQ6 - implementation-dependent? which snmp tables need to e cleaned up?
[15:54:56] <dbh2> If we have a session table in TMSM or SSHSM, then it will need to be addressed.
[15:57:00] <dbh2> If we use dynamically created notify tables, would we need to clean those up when a session closed?
[15:57:59] <dbh2> Dynamic tables would be used if a CG cause dthe config of notify tables when the CG creates its session.
[15:58:23] <dbh2> Or do we require that notify tables are always statically configured?
[15:58:43] <dbh2> time is up.
[15:59:30] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Is the plan to go through the Qs tomorrow and to explain and get WG input/feedback?
[15:59:53] <dbh2> summary: we answerd aq1-4, sq1-5. sq6-7 depends on the mib designer.
[16:00:08] <dbh2> JQ: R* have not yet been answered.
[16:00:31] <dbh2> JQ: yes
[16:05:24] --- Dave Nelson has left
[16:05:47] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left
[16:08:13] --- dbh2 has left
[17:48:56] --- dbh2 has joined
[18:45:37] --- dbh2 has left: Replaced by new connection
[18:45:39] --- dbh2 has joined
[19:24:28] --- dbh2 has left