Subject: [Isms] tmsm issue #1: meaning of authoritative in the context of TMSM (p28)

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 May 2006 20:56:58 +0200

tmsm issue #1: meaning of authoritative in the context of TMSM (p28)

  We need to discuss what the meaning of authoritative would be in a
  TMSM environment.

  -> strawman: the meaning of authoritative in the sense of clock
     synchronization does not apply to TMSM instances and is
     irrelevant

/js

-- 
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: Wed, 17 May 2006 20:57:15 +0200

tmsm issue #2: purpose of msgSecurityParameters in TMSM (p28)

  We need to discuss whether the specific services provided in USM
  security from msgSecurityParameters still are needed, and how the
  Message Processing model provides this information to the security
  model via generateRequestMsg() and processIncomingMsg() primitives.
  RFC3412 specifies that "The data in the msgSecurityParameters field
  is used exclusively by the Security Model, and the contents and
  format of the data is defined by the Security Model.  This OCTET
  STRING is not interpreted by the v3MP, but is passed to the local
  implementation of the Security Model indicated by the
  msgSecurityModel field in the message."

  -> strawman: we leave the contents of the msgSecurityParameters to
     the definition of a concrete TMSM instance

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 May 2006 20:57:29 +0200

tmsm issue #3: handling of msgFlags and securityLevel (p29)

  The text says that messages must be discarded if the underlying
  transport can't provide the requested security. How is yet to be
  determined, and may be model-specific or implementation-specific.

  -> strawman: yes, the implementation is implementation specific
     and the [discuss] should simply be dropped

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 May 2006 20:57:44 +0200

tmsm issue #4: notification state of NO initiated sessions (p31)

  We need to determine what state needs to be saved here.

  -> unclear what is needed here or what this issue is all about

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 May 2006 20:58:02 +0200

tmsm issue #5: session table (p39)

  Should it be possible for a manager to create or modify rows in the
  session table?  If so, then we may need the rowstatus object.  If
  the session table is read-only then we can probably eliminate the
  rowstatus.  If the tabel is not read-only, then we need to list the
  tables and objects and state why they are sensitive.

  -> strawman: the session table is read-only

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 May 2006 20:58:38 +0200

tmsm issue #7: transport type (p40)

  How do we add a new TransportType?

  I am not sure, but the underlying question might be whether we use
  generic TransportAddress and TransportAddressType TCs or stick with
  the traditional TDomain and TAddress TCs.

  -> strawman: We use TDomain/TAddress and every TMSM instance provides
     appropriate TCs and OID constants for the specific SNMP
     transport.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 May 2006 20:58:21 +0200

tmsm issue #6: security considerations (p40)

  How do we modify this section for an SNMP/SSH or other transport
  mapping security model?  If the security model provides for
  securityName/Level/Model then some of the normal boilerplate is not
  true.

  -> strawman: TMSM instance specific text goes into the document which
     defines the TMSM instance - drop the discuss.

/js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 May 2006 16:11:43 -0400

>From my limited understanding of what's going on here, this concept of 
"authoritative" is specific to the way USM works, and should be irrelevant 
to TMSM, at least at the abstract layer.

>      the definition of a concrete TMSM instance

Agree.

>      and the [discuss] should simply be dropped

Yup.  There may be cases where the model needs to define exactly what it 
means for the underlying transport to provide the needed security; for 
example, SSHSM could decide that the level of security provided by an SSH 
connection depends on whether the null cipher is used, or not.  Or, it 
could leave that up to the implementation or to configuration.  In any 
event, actually determining what cipher is in use would certainly be 
implementation specific.

> tmsm issue #4: notification state of NO initiated sessions (p31)

I have to go reread documents before I can comment on this.

>   -> strawman: the session table is read-only

The session table appears to be a means for exposing information about 
cached transport sessions.  Since the actual sessions represented by these 
rows typically include things like actual transport connections and 
security state associated with those connections, it seems nonsensical for 
this table to be anything other than read-only.  In fact, I'm not entirely 
convinced this essentially internal state should be exposed at all.

>      appropriate TCs and OID constants for the specific SNMP

I'm not sure I understand what you're proposing; maybe I need to go back 
and look at SNMPv3 again.  My recollection from the interim was that we 
came to the conclusion that a new transport address type would be necessary 
to describe SSH endpoints by name.

>      defines the TMSM instance - drop the discuss.

Agree.  Each TMSM is going to have to have security considerations which 
depend on the underlying transport and on how it is being used.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 May 2006 16:59:39 -0400

Agreed.
dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 2:57 PM
> To: [email-masked]
> Subject: [Isms] tmsm issue #2: purpose of 
> msgSecurityParameters in TMSM (p28)
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 May 2006 16:59:39 -0400

Hi,

The RFC3411 ASIs contain securityEngineID and a comment about it being
authoritative.
For SSHSM, I believe we do not use the concept, and I have modified
SSHSM to use the local snmpEngineID wherever the securityEngineID is
called for. I think that will work in the elements of procedure (EOP)
for SSHSM and the RFC3412 MP model EOP.

I think authoritative is not relevant to SSHSM, but there may be other
TMSM models for whom authoritative may be meaningful. This is highly
model-dependent, and may not mean the same type of authoritative as
USM's authoritative. So until RFC3412 and RFC3411 are rewritten to
remove securityEngineID from the ASIs, I think it would be wise to
leave it, but we can point out that it is model-specific and may not
be used by all models, and the local snmpEngineID will stauisyf the
ASIs when it is not needed by a security model.

dbh

> Subject: [Isms] tmsm issue #1: meaning of authoritative in 
> the context ofTMSM (p28)
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 May 2006 22:25:11 -0400

The text preceding this discuss is incorrect, in that an outgoing
notification does not cause the generation of a securityCache. 

This section basically says that a norification must cause the
creation of a session if one does not exist. I do not think this
requires any special processing other than getting the information
from the target-mib (or whatever), which is likely to be
model-specific. When I do the EOP for SSHSM, I will have a better idea
of whteher there are any special issues for creating sessions for
notifications.

dbh

> Sent: Wednesday, May 17, 2006 2:58 PM
> To: [email-masked]
> Subject: [Isms] tmsm issue #4: notification state of NO 
> initiated sessions(p31)
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 May 2006 22:40:29 -0400

So an engine creates session entries for one of two circumstances
1) an outgoing message causes creation of a session.
2) an outgoing message from another engine causes creation of a
session with this engine.

Are those the only two things we need to care about?

Either way, a sessionEntry should be created to record the session's
existence. Although this makes me realize that we have not provided
any text that discusses the opening of a session by a remote engine,
and how the sessionTable gets populated.

If those are the only two ways to create a session, then read-only
should be fine. But these do not cover any callhome mechanism.

dbh

> Subject: [Isms] tmsm issue #5: session table (p39)
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 May 2006 22:51:18 -0400

Juergen,

I think the page numbers you are showing are for -01-, not -02-

dbh

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 19 May 2006 20:23:57 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, May 17, 2006 11:58 AM
...

The only reasons I can think for having a session table visible to
management are:
    - to monitor who is accessing a system at the moment
    - to provide a way for an administrator to terminate other sessions
    - for debugging

None of these seems very persuasive to me.  I suggest eliminating
the table.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Mon, 22 May 2006 13:37:16 -0400

Hi Randy,

There is another use case you didn't mention. 

An authenticated CG could cause the creation of a session from the
remote system to the local system for callback purposes. Such a
callback approach has not been well-specified, and I am not sure such
an approach is even viable, but it would require either read-write
access to the session table, or another object that would cause a
session to be created. Either way, the manager would probably want to
see if a suitable session already existed before creating a new
session.

Callback has been debated, and the WG has waffled between "this really
is needed for notifications when no session yet exists" to "we don't
care about this because there is no customer demand for this feature."

If all engines support mixing R/R and notification messages in the
same session, then a manager could open a two-way session to each
agent in case there are any notifications to be sent to it. I think
this compares to the subscription model being discussed in netconf.
There are issues with mixing that we have not yet discussed and which
have been discussed in netconf, such as whether a long response (say
to a getbulk) would block the delivery of notifications. There are
issues with subscriptions that we have not discussed, such as the
scalability of requiring managers to configure sessions to agents,
especially when a network is recovering from, say, a power outage -
with a subscription model, should the linkUp notifications be buffered
by the agent until a manager sets up a session?

In the meantime, I find the session table useful to try to understand
what session info needs to be kept in an LCD for use by the elements
of procedure, whether the LCD is in MIB format or a proprietary
format. Using an implementation-neutral session MIB makes this clearer
for me for now.

We will need to keep session info available, and specify how one does
a lookup based on the info available in the ASIs, in order to support
the reuse of sessions (mixed or not). SNMP applications and the
dispatcher and the message processing models do not know about
sessions, and SSH does not know about securityN/M/L, so SSHSM needs to
translate from the ASI parameters (transport + securityN/M/L) to SSH
username/subsystem/transport somehow. A session tabel seems an
appropriate place.

dbh

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 11:24 PM
> To: [email-masked]
> Subject: Re: [Isms] tmsm issue #5: session table (p39)
> 
> 
> Hi -
>