Subject: [Isms] pre-08 for TSM document

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Jun 2008 18:41:15 +0800

Hi,

I have added the MIB tables we discussed. 
I have not yet adjusted any of the non-MIB documentation.
Please see whether these MIB tables look appropriate.

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Jun 2008 19:43:22 +0800

Hi,

I should probably provide a little guidance on this MIB.
Due to modularity rules, only the TSM will actually manipulate this
MIB.
It might also be the only module to read the MIB.
(Implementations of course can optimize as they wish).

TSM will convert from ASI parameters to LCD, and from LCD to ASI
parameters. In C++ terms, this is a "private" datastore, accessible
through "public" interfaces. I started calling this the
snmpTsmUserTable, but that could be misleading, so I changed it the
snmpTsmLCDTable. Let me know which you prefer, or if you have another
name you prefer.

For outgoing messages, the application ASIs will provide securityName,
Level, domain, and address. These may, of course, come from the
RFC3413 MIB modules.

The TSM MIB may be preconfigured with desired mappings, so the TSM
will look to see if there is an entry for the provided securityName,
Level, domain, and address. If not, the TSM will create an entry, and
by default, the provided securityName will be used as both the
LCDSecurityName and the LCDName. (I debated whether to name the label
default or identity.

Then, the TSM will make a request of the transport model, converting
the LCD info into the ASI parameters (passing a tmStateReference,
containing info in the fields). The transport model will work with the
info from the tmStateReference, not the LCDTable. The SSHTM will also
have a local config datastore, but we are not defining that since it
is SSH configuration. How SSHTM uses the tmStateReference equivalent
of LCDName is implementation-dependent.

For incoming messages, SSHTM will fill out the fields in the
tmStateReference that is passed to TSM. TSM will check for an existing
entry in the snmpTsmLCDTable. If none exists, it will create one using
the provided info, by default using the SSHTM-recommended
securityName.

For both incoming and outgoing, the TSM will check the policy before
creating an entry. Presumably, an error will be returned to the
calling module and the processing will be aborted, if the policy says
do not create the entry. The error-handling will become clear when I
do the EOP.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Harrington
> Sent: Thursday, June 19, 2008 6:41 PM
> To: [email-masked]
> Subject: [Isms] pre-08 for TSM document
> 
> Hi,
>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 19 Jun 2008 14:07:55 -0400

"These MIB objects SHOULD NOT be modified via other documents."

DBN: You mean "by subsystems or models described in other documents"?

snmpTsmInadequateSecurityLevels OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of incoming messages dropped because
                 the actual securityLevel provided was less than
                 the requested securityLevel."

DBN: Does this assume that individual messages are dropped?  It seems to me
that the securityLevel inadequacy is going to be on a per transport
connection basis, not on a per message basis.  All messages coming through
the same transport connection will have the same securityLevel, no?

---

From: "Purvis, Ray" <[email-masked]>
Date: Thu, 19 Jun 2008 14:19:09 -0400

If a TM is developed under TSM that uses DTLS, or any other connectionless
protocol based method, then it would be a per message basis, wouldn't it?  

v/r

Ray Purvis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David B. Nelson
Sent: Thursday, June 19, 2008 1:08 PM
To: [email-masked]
Subject: Re: [Isms] pre-08 for TSM document

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 19 Jun 2008 14:34:36 -0400

> protocol based method, then it would be a per message basis, wouldn't it?

No, not really.  Whenever there is encryption or a cryptographic checksum
involved, even a datagram based transport needs to keep track of which
message belongs to which connection, otherwise the wrong keys are applied.
The transport knows which packet belongs to which connection.  I suppose the
question is whether the TSM knows that?

---

From: "David Harrington" <[email-masked]>
Date: Fri, 20 Jun 2008 08:45:22 +0800

The TSM does not know about transport-specific sessions.

It knows only about the "thing" that can be identified using
transportdomain, address, security name and level. It also knows about
some opaque identifier (snmpTsmLCDName) that is presumabkly meaningful
to the transport layer.

dbh 

> Behalf Of David B. Nelson
> Sent: Friday, June 20, 2008 2:35 AM
> To: [email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 20 Jun 2008 09:31:50 -0400

So then, this object is incremented by the TSM when the securityLevel passed
via the ASI isn't what is expected?  If the securityLevel is part of the
"index" of the "thing" how can that work?  That is to say, how can it have
an unexpected value and at the same time be used to distinguish (index) one
connection vs. another?  Maybe I'm just dense...

---

From: "David Harrington" <[email-masked]>
Date: Fri, 20 Jun 2008 23:43:34 +0800

comments inline 

> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Friday, June 20, 2008 9:32 PM
> To: [email-masked]
> Cc: 'David Harrington'
> Subject: RE: [Isms] pre-08 for TSM document
> 
> via the ASI isn't what is expected?  

No. 
This error can only occur for an incoming message.
securityLevel in the ASI comes from the message header of an incoming
message.
tmTransportSecurityLevel is the level asserted by the transport model,
based on whatever information it has about the services provided by
the lower layer.

Compare the value of tmTransportSecurityLevel in the
   tmStateReference cache to the value of the securityLevel parameter
   passed in the processIncomingMsg ASI.  If securityLevel specifies
   privacy (Priv), and tmTransportSecurityLevel specifies no privacy
   (noPriv), or securityLevel specifies authentication (auth) and
   tmTransportSecurityLevel specifies no authentication (noAuth) was
   provided by the Transport Model, then the
   snmpTsmInadequateSecurityLevels counter is incremented, and an
error
   indication (unsupportedSecurityLevel) together with the OID and
value
   of the incremented counter is returned to the calling module.
   Transport Security Model processing stops for this message.

> If the securityLevel is 
> part of the
The existing revision never says when the LCD is created for an
incoming message; the revision-in-progress will. It happens after it
checks for a valid level. If the level is invalid, it won't be used to
index into the LCD for that message.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 20 Jun 2008 14:26:47 -0400

>    tmStateReference cache to the value of the securityLevel
>    parameter passed in the processIncomingMsg ASI.

Under what circumstances could these be different?  Does it require a
nonconforming implementation to trigger this, or simply a misconfiguration?

---

From: "David Harrington" <[email-masked]>
Date: Sat, 21 Jun 2008 09:59:54 +0800

Hi,

With SSH, they are unlikely to differ in a manner that matters. SSH
provides no standardized feedback for applications that use it.
Because SSHTM has no visibility to the underlying transport security,
we tell operators they MUST configure for authpriv; if they do not,
that is a configuration error. SSHTM always asserts authpriv was used.
As long as what is asserted is greater than or equal to what is
requested (and you cannot request higher than authpriv), the
InadequateLevel error is not triggered. 

With a transport that actually tells the transport model what
properties were applied, we could distinguish between
"dbh@address:authpriv" from "dbh@address:noauthnopriv". Applications
can request different levels, and TSM could check whether the level
provided is at least as strong as requested.

If an SSHTM implementation uses an SSH toolkit (or builds their own)
whose API provides feedback about what auth and priv protocols were
actually used, SSHTM could detect when auth or priv were not provided,
and that implementation could do better than the hardcoded authpriv
assertion of the standard at determining whether the actual level is
at least as strong as that requested.

dbh

> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Saturday, June 21, 2008 2:27 AM
> To: [email-masked]
> Cc: 'David Harrington'

---

From: "tom.petch" <[email-masked]>
Date: Tue, 24 Jun 2008 09:58:24 +0200

Looks good.  I think that my concerns with SSHTM remain unaltered by this.

Focussing on this I-D, you say that the TM will not alter the LCD table, but I
think that it will struggle to read it, at least on inbound  messages, as it
cannot be sure what the securityName is and so cannot index into the table.  It
could walk the table looking for a matching snmpTsmLCDName ... well perhaps not.

I assume that snmpTsmLCDName is tmSecurityName; could the names be more similar
or is there a subtle point that I am missing in them being so different?

I am concerned at the length of snmpTsmLCDName, at 32 maximum.  I am aware of no
such constraint for an SSH user name.

And as you probably realise, the Security Considerations will need an update viz

"8.1.  MIB module security

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create."

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 26 Jun 2008 13:53:09 +0800

> Sent: Friday, June 20, 2008 2:08 AM
> To: [email-masked]
> Cc: 'David Harrington'

fixed.

> the same transport connection will have the same securityLevel, no?

As explained in another message, securityLevel is defined in two
places. The transport model
reports what the transport provided (to the best of the TM's
knowledge), and the messahe
contains a requested securityLevel. These two values are compared.

The transport securityLevel is likely the same over the lifetime of
the transport session. (I only say likely to accommodate
currently-unspecified transport models)

The requested securityLevel is specified on a per-message basis, the
comparison is done on a per-message basis, and the drop is done on a
per-message basis.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 26 Jun 2008 13:54:20 +0800

yes. it is always on a per-SNMP-message basis regardless of transport
protocol. 

dbh

> Behalf Of Purvis, Ray
> Sent: Friday, June 20, 2008 2:19 AM
> To: David B. Nelson
> Cc: [email-masked]
> Behalf Of

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 26 Jun 2008 10:55:19 -0400

> comparison is done on a per-message basis, and the drop is done on a

OK, I get it now.  Maybe you should modify the DESCRIPTION clause to say:

  DESCRIPTION "The number of incoming messages dropped because
               the securityLevel reported by the transport to 
               the SNMP Transport Model was less than the 
               securityLevel requested in the SNMP PDU."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2008 09:12:20 +0200

On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote:

> Focussing on this I-D, you say that the TM will not alter the LCD
> table, but I think that it will struggle to read it, at least on
> inbound messages, as it cannot be sure what the securityName is and
> so cannot index into the table.  It could walk the table looking for
> a matching snmpTsmLCDName ... well perhaps not.

I fail to see why a TM needs to read the table. The TM just passes the
name provided by the transport via the tmStateReferences and TSM then
does any mappings as needed.
 
> I assume that snmpTsmLCDName is tmSecurityName; could the names be
> more similar or is there a subtle point that I am missing in them
> being so different?

I agree that finding good labels is important. I am not having a good
constructive idea yet... Checking RFC 3411 again, I see there it makes
a distinction between a securityName and a security ID, where the
security ID seems to be pretty close to our tmSecurityName. Dave, do
you agree with this reading of RFC3411?

> I am concerned at the length of snmpTsmLCDName, at 32 maximum.  I am
> aware of no such constraint for an SSH user name.

Since snmpTsmLCDName is not used in an INDEX, I think we can easily
drop the length restriction.

/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/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2008 09:25:19 +0200

On Thu, Jun 19, 2008 at 07:43:22PM +0800, David Harrington wrote:
 
> I started calling this the snmpTsmUserTable, but that could be
> misleading, so I changed it the snmpTsmLCDTable. Let me know which
> you prefer, or if you have another name you prefer.

I find snmpTsmLCDTable too broad; the snmpTsmLCDTransformTable is also
stored in the LCD. The table really is a snmpTsmSecurityNameMappingTable
or a snmpTsmTmMappingTable or a snmpTsmNameMappingTable. Or what about
snmpTsmTmNameTable?

Nits:

- s/2007/2008/

- The import of TEXTUAL-CONVENTION is not used.

- Missing dot at the end of the first sentence in section 6.3.2.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 27 Jun 2008 12:49:25 +0200

Juergen

Just continuing with the first point, my concern is a SSHTM one in that I cannot
see how it works.

On an incoming call, the SSHTM will know transport addresses, ports and type,
SSH user name, SSH host name and will have an SSH session identifier; I assume
that this will be stored in an internal SSHTM table(or cache).  When a message
subsequently arrives over that session, SSHTM cannot know the securityLevel or
securityName (as generated by the message originator), the former is buried in
the ASN.1, the latter is the province of the SM not the TM.

So on an outgoing message at some later time, it cannot match the 4-tuple of
transportDomain and transportAddress, securityName and securityLevel that is
used elsewhere in the stack to identify the session to be used for a message.  I
thought that snmpTsmLCDTable would provide an answer but I don't see it.

(The SSHTM I-D says
"     1) Determine the target index by extracting the transportDomain,
      transportAddress, securityName, and securityLevel from the
      tmStateReference.
      2) Lookup the session in the Local Configuration Datastore using
      the target index " )

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Friday, June 27, 2008 9:12 AM
Subject: Re: [Isms] pre-08 for TSM document

> does any mappings as needed.

<snip>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2008 14:01:57 +0200

On Fri, Jun 27, 2008 at 12:49:25PM +0200, tom.petch wrote:
 
> On an incoming call, the SSHTM will know transport addresses, ports
> and type, SSH user name, SSH host name and will have an SSH session
> identifier; I assume that this will be stored in an internal SSHTM
> table(or cache).  When a message subsequently arrives over that
> session, SSHTM cannot know the securityLevel or securityName (as
> generated by the message originator), the former is buried in the
> ASN.1, the latter is the province of the SM not the TM.

The TM caches the authenticated identity and passes this on via the
tmStateReference. The SM picks up the value, it knows which TM has
passed the tmStateReference, and it knows the actual security level
and can check them.
 
> So on an outgoing message at some later time, it cannot match the
> 4-tuple of transportDomain and transportAddress, securityName and
> securityLevel that is used elsewhere in the stack to identify the
> session to be used for a message.  I thought that snmpTsmLCDTable
> would provide an answer but I don't see it.

Why not? What do you think is missing?

>       2) Lookup the session in the Local Configuration Datastore using

I do not yet see why it won't work. Please explain.

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Jun 2008 20:51:28 +0800

Hi, 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, June 27, 2008 3:12 PM
> To: tom.petch
> Cc: David Harrington; [email-masked]

A TM should not use this TSM table. This table is really all about
getting the securityName, which is an SM thing. 

As I began to update the secshell document, I decided the "security
ID" (snmpTsmLCDName) really should be in the TM, not the SM. The TM
should provide a mapping from secuity ID to tmSecurityName, ans TSM
should simply take tmSecurityName as securityName. Therefore, TSM
doesn't need a mapping table, TM does. So I have started moving the
mapping table to SSHTM.

The Transform table really belongs in TM as well. I think the
TM-disable belongs in TSM though, so I am splitting the TransformTable
into a TSM-disable-domain-table, and an
SSHTM-which-mapping-transform-table.

You are absolutely right that on an incoming message, the TM will have
a hard time reading the table because it is indexed by securityName,
so the transform will need to be done before the table can be read to
see if an entry already exists. I considered searching the table for 
address/LCDName, but since that is not an index, it is not guaranteed
to be unique, and it is reasonable that a given address might have
multiple SSH users.

> > more similar or is there a subtle point that I am missing in them

I think they really would be the same, but with the chnages I am
proposing, that will not be an issue.

> you agree with this reading of RFC3411?

When I move this to SSHTM, we could simply name this SSHTMPrincipal or
something similar. We have so many variations of securityName, this is
sure to be confusing to people.
> drop the length restriction.

Is there a limit to SSH user name? We should make sure they are
consistent.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Jun 2008 21:06:04 +0800

> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, June 27, 2008 6:49 PM
> To: [email-masked]
> Subject: tm table was Re: [Isms] pre-08 for TSM document
> 
> Juergen
> 

Correct, the TM knows nothing about what is requested in the ASN.1
message.

The tmSecurityLevel in the TM for an incoming message is supplied by
interpreting the SSH security proprties. In SSH, this is not
necessarily available so we assert that it is always authPriv. The SM
will compare tmSecurityLevel with msgSecurityLevel to see if
thSecurityLevel is greater than or equal to msgSecurityLevel (and for
SSHTM, it always will be because authpriv is the highest level).

> thought that snmpTsmLCDTable would provide an answer but I 

The tmStateReference actually contains the requested level for an
outgoing message (tmRequestedSecurityLevel). SSHTM then tells SSH to
apply authpriv regardless of the (possibly lower level) request.

Are you trying to identify a particular SSH session, where there might
be multiple sessions associated with the 4-tuple? We have explicitly
said the 4-tuple is unique; there cannot be two sessions for the same
4-tuple in SSHTM.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jun 2008 15:52:01 +0200

> Is there a limit to SSH user name? We should make sure they are

usmUserName is SnmpAdminString (SIZE(1..32)) so there is a limit.  On
the other hand, there is no limit for snmpCommunityName. I am not sure
we need to have identical limits for security IDs.

The fun part is that in several places there is no limit for a
securityName but VACM says vacmSecurityName is SnmpAdminString
(SIZE(1..32)). So you can configure USM to map a user name to an
snmpSecurityName for which it is impossible to specify access control
rules in VACM. It looks we should have defined an SnmpSecurityName TC
to make things really consistent...

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 27 Jun 2008 19:10:08 +0200

<inline>
Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 27, 2008 3:06 PM
Subject: RE: tm table was Re: [Isms] pre-08 for TSM document
> SSHTM, it always will be because authpriv is the highest level).

Understand and am happy with that.

> apply authpriv regardless of the (possibly lower level) request.

Understand again.

> said the 4-tuple is unique; there cannot be two sessions for the same

Again, understand, but ...

> >       2) Lookup the session in the Local Configuration Datastore

... from the information that the SSHTM has from receiving a session and
subsequent inbound messages, it has no knowledge of securityName and
securityLevel.  So when an outbound message is passed down to it, and the SSHTM,
as per EOP, is expected to use the 4-tuple to look for a session, then this may
be the first that the SSHTM has ever heard of the particular values of
securityName and securityLevel; it may have a match on tranportAddress and
transportDomain in the table of sessions it has (initiated or) received (along
with other SSH data), it could have several but how can it tell if the two
security parameters match?

(eg it cannot use tmTransportSecurityLevel as that is always authPriv for SSH
and the application creating the outbound message may have had other ideas)

I was envisaging that some unique index could pass from TM to SM so that SM
could hand back index+securityName+securityLevel; or that there is a common
table into which SM inserts securityName+securityLevel so that TM now can
associate them with a session (but which the structure of the snmpTsmLCDTable
now seems to rule out as a candiate) or ..

Puzzled,

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Sat, 28 Jun 2008 10:46:20 +0800

> securityLevel.  

OK. sometimes we talk about the concept instead the exact variable
name that must be used. We are not implementing this, we are
describing how it works conceptually. I will make sure to change this
to say tmSecurityName and tmSecurityLevel. (or more accurately,
tmRequestedSecurityLevel and tmTransportSecurityLevel). 

> So when an outbound message is passed down to 
> it, and the SSHTM,
> > > > > Focussing on this I-D, you say that the TM will not alter
the
> > LCD

---

From: "tom.petch" <[email-masked]>
Date: Mon, 30 Jun 2008 18:23:31 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, June 28, 2008 4:46 AM
Subject: RE: tm table was Re: [Isms] pre-08 for TSM document

> tmRequestedSecurityLevel and tmTransportSecurityLevel).

I still think that it cannot work, conceptually or otherwise:-)

A session is received, the TM gets information about the session which it can
use to identify it but which cannot include the securityName and securityLevel
as used by the application which has or is about to transport a message over the
session.

A message is received over this session which has this security information
embedded within it but which is inaccessible to the TM, only to SM and MPM
respectively, neither of which tell the TM about it; the TSM will put such
information into a cache, which, as Juergen said, he saw no point in the TM even
reading.

An outbound message is now passed to the TM and the session to use is identified
by the 4-tuple which includes securityName and securityLevel, which the TM has
never heard of and which there is nowhere to use as an index to translate to
information which the TM does understand (eg SSH session ID, SSH host name, SSH
user name ...).  Nor do I see how any model in the stack can create such a
translation table so I do not see how can a message ever be sent over a session
that already exists, and that includes a response to a request.

The part that does work is when an outbound message creates a session; then and
only then does the TM know the securityLevel and securityName associated with
the session (and to create a new session if the transport details match but the
security details differ).

When I use securityName and securityLevel here I mean literally that, the values
used by the application and most of the models in the stack to identify the
session to be used (in conjunction with the two transport parameters) and not
the proposed or such level parameters that may be translated into or from the
application level parameters by the Security Model..

Tom Petch