Subject: [Isms] wg last call on isms document set

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Nov 2008 09:13:20 +0100

This message starts the working group last call on the ISMS documents:

[1] Transport Subsystem for the Simple Network Management Protocol (SNMP)
    <draft-ietf-isms-tmsm-15.txt>

[2] Transport Security Model for SNMP
    <draft-ietf-isms-transport-security-model-10.txt>

[3] Secure Shell Transport Model for SNMP
    <draft-ietf-isms-secshell-13.txt>
  
[4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple
    Network Management Protocol (SNMP) Transport Models
    <draft-ietf-isms-radius-usage-04.txt>
                                                                                                                  
The authors and the chair think that these documents are mature enough
for last call.  Since the next IETF meeting is coming up, the last
call period is not two weeks as usual, but extends until the the end
of the IETF week. However, I like to encourage people to review these
documents before the ISMS meeting in Minneapolis (currently scheduled
for Monday November 17) so that the WG meeting time can be used to
resolve any issues that might come up during document review.

Please do review the documents and post your comments on this list
until November 23, 2008.  Please also post to the list if you have
read the documents and you are fine with them.  It is very useful to
know how many people have read the documents.

/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: "Dave Shield" <[email-masked]>
Date: Tue, 4 Nov 2008 17:53:22 +0000

2008/11/4 Juergen Schoenwaelder <[email-masked]>:
> This message starts the working group last call on the ISMS documents...
> until November 23, 2008.

How did you guess this was coming?  :-)

Please find attached my comments on these last set of documents.
I've tried to take them as they stand, "reading afresh" without referring
back to my previous comments and suggestions.

By Shield standards, these comments are not much more than
low-level mutterings, though there are a handful of open questions
that don't feel to have been resolved as yet.

Dave

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Nov 2008 23:07:06 +0100

>     <draft-ietf-isms-radius-usage-04.txt>

I like to remind everyone that we have our documents in WG last
call. It will be very useful to receive reviews before the WG meeting
next week. Also short reports that you have read the documents and are
fine with them are useful.

/js

---

From: "tom.petch" <[email-masked]>
Date: Tue, 18 Nov 2008 15:43:47 +0100

I think that there is still a functional hole in tmsm s.6, the same one that has
been bugging me since August 2005.

On a Response, to a common or garden Get, nothing fancy, the application will
pass transportDomain, transportAddress, securityModel, securityName,
securityLevel to the dispatcher, which passes them unaltered to the Message
Processing Model, which passes them to the (Transport) Security Model.

transportDomain, transportAddress no problem, they pass unchanged through the
stack

Previous versions of tmsm specified that securityModel should be part of the
check for an existing session in s.6.2; this has gone, I am unclear why.  This
suggests that different securityModel will have distinct caches.  Quoting dbh
slightly out of context from 12Sep2008, "We should probably add a check to
ensure that, on the response, we are using the same security model as was used
with the request."

The text then says 'requested securityLevel' which I think should be either
securityLevel, which is what the Security Model is being passed, or, perhaps,
tmRequestedSecurityLevel, assuming that, although the I-D does not say, this is
now set to securityLevel as passed as an IN parameter.

But the real difficulty for me is the specification here of tmSecurityName

5.2.2 is explicit 'the tmSecurityName may or may not be the same as the
securityName as seen by the Application and Access Control subsystems' so my
question is, when they are not the same, who is doing the mapping and where so
that the securityName as an IN parameter to the Security Model can be translated
into tmSecurityName for comparison with existing cache entries.  Whoever does
it, I think that there is a problem that other parts of the stack need to know
the mapping and do not.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 19 Nov 2008 10:03:06 +0100

Apart from the technical problem I have flagged separately, my impression of
tmsm is that it has become much vaguer, harder to follow unless you know of the
background.  Perhaps we will need another I-D, a 'SNMP Security Companion'.

Som editorial suggestions.

s.2
/wide spread/widespread/

s.3.2.1

" This Transport Subsystem uses a modular design that permits Transport
   Models to be "plugged into" the RFC3411 architecture, supported by
   corresponding Transport Models"

** reads oddly, I suspect that the second Transport Model is referring to the
underlying transport.

3.2.1.3.  Passing Information between SNMP Engines

   A secure Transport Model will establish an authenticated and/or

** this 'and/or' bugs me - it allows for unauthenticated/encrypted transport
which I think is a no no

" Transport Models MAY support sending multiple SNMP messages through  the same
tunnel."

** I have never really understood this.  It seems to be saying that after
sending a message, you are not REQUIRED to tear the tunnel down:-)

   will be prepended to all passed tmSecurityNames.

**  suggest 'tmSecurityName' since that is the name of the object

3.2.2.1.  securityName and securityLevel Mapping

   include from one to four ASCII characters, not including a ":" (ASCII

** this would allow the use of vertical tab and BEL:-)  I think that the ASCII
character set should be more restricted, to one of the well known sets, both in
this section and in s.8

3.2.4

  " either based on the message version, e.g., SNMPv1 and SNMPv2c, and "

** suggest 'either ...or' else 'both...and'

3.3.1
** para 3 uses tmSecurityName and tmRequestedSecurityLevel
   para 4 uses securityName and securityLevel

suggest consistency, with an explicit statement of where in the architecture you
are referring to, since this determines the appropriate term, the application
interface or the transport interface

6.2.2 generateResponseMessage

** this has lots of references to steps, first appeared in tmsm-13, which are
not in the I-D

8
Prefix snmpDomain Reference

**should be snmpDomains

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 19 Nov 2008 12:32:12 +0100

I cannot make sense of secshell-13 which in turn means I cannot make sense of
tsm-10.

Back in -11, tmStateReference contained tmTransport and tmAddress which became
tmTransportDomain and tmTransportAddress in -12 and stay so in -13.  No such
fields are mentioned in tmsm-15 or tsm-10 or in the description of the cache in
secshell-13.

These fields appear from nowhere in secshell-13 s.5.1 and I have no idea why.

We established years ago that there would be two values of 'securityLevel' and
have kept that idea, giving them different names.

We established years ago that there would be multiples values of 'securityName'
and have yet to decide how and where it is mapped but no matter, we still have
the idea of multiple values with distinct names.

I recall no discussion asserting a need for multiple values of transport Domain
and Address and cannot see one.

s5.2 says
'(SSHTM ignores the provided tmTransportDomain tmTransportAddress '

Since it has not been provided by tsm, then it is fortunate that it is being
ignored, but really, I have no idea what is going on here.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 19 Nov 2008 09:38:51 -0600

Hi Tom, 

Thanks for catching these.
comments inline

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, November 19, 2008 5:32 AM
> To: Juergen Schoenwaelder; [email-masked]
> Cc: David Harrington; Wes Hardaker; [email-masked]
> Subject: Re: [Isms] wg last call on isms document set -secshell
> 

I will look at this and try to determine why the change was made.

> the idea of multiple values with distinct names.

It is the responsibility of the security model to accept "proposed"
security names from possibly multiple sources on input, and craete a
securityName for use with applications. On output, the reverse mapping
(from securityNsme to whatever) is done. 

> ignored, but really, I have no idea what is going on here.

I will look into this. It might be that I changed this, but
incompletely, to address sameSecurity.

It would seem to be wrong to allow an application to specify an
address that is different than the one used to receive the request,
especially since we have now added the [email-masked] feature. If we
want to use the same address, we need to store it in
securityStateReference, which means the transport model needs to pass
it in tmStateReference. The "mappings" to and from
securityStateReference must happen in TSM.

I think the EOP would fail to find a valid "same session" if the
address was changed, so this may not be needed.

dbh

---

From: "tom.petch" <[email-masked]>
Date: Wed, 19 Nov 2008 15:55:25 +0100

My review of tsm is somewhat hampered by being unable to make sense of secshell
but ...

I think that the changes discussed in September and October have not been fully
followed through.

3.2.4

The WG decided long since that for TSM, responses MUST use the same session as
the request.  This is clear in 3.3.1 but when you have waded through 3.2.4 you
might not be so clear

'response message SHOULD be discarded'
'security-model-specific decision whether to REQUIRE this.'
'this flag is used ' - yes but when is it set?

I suggest adding
' The Transport Security Model REQUIRES that the security parameters
   used for a response are the same as those used for the corresponding
   request'
to the end of 3.2.4 - make it clear!

4.2
I think our caches are getting tangled.  For an outgoing response,
we get tmStateReference from the securityStateReference cache.
But why get anything else?

DBH said 12Sep08 that the securityModel should be checked and I think that
absolutely right but I see no text for that.

Wes 21Oct08 made me think that securityName and securityLevel would come from
the tmStateReference and not from the securityStateReference cache.  Surely the
former is closer to the truth.  We REQUIRE the same session and security for the
response so why use the securityStateReference cache, which is one stage removed
from the truth, at all, except to obtain the tmStateReference?

Likewise, transportDomain transportAddress would come from the tmStateReference
and the IN parameters would be ignored by TSM - in which case, we should spell
that out lest these unused (for outgoing response) parameters confuse.

I want to see 4.2 1) clearly spell out the usage of

transportDomain
 transportAddress
 securityModel
 securityName
securityLevel

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 19 Nov 2008 14:38:38 -0600

Hi,

comments inline. 

> Sent: Wednesday, November 19, 2008 8:55 AM
> To: [email-masked]; [email-masked]
> Cc: David Harrington; Wes Hardaker
> Subject: Re: [Isms] wg last call on isms document set- tsm
> 

The section "Cached Information and References" is identical in each
document, except an add-on section that document-specific differences.
In the old format each document said mostly the same thing, but each
document was slightly different. This inconsistency across documents
was confusing. So we changed it,and put document-specific cache
information into a separate section. 

"section 3.3 Transport Security Model Cached Information

The Transport Security Model has specific responsibilities regarding
   the cached information.
"

Personally, I find the new cross-document-consistency suggested by
Dave Shield much easier. For all future readers who have not
particpated in the discussions, I think the new format provides a more
abstract and architectural description in the document, before adding
the document-specific details in later sections.

My impression is this will make it easier for new readers of the
document. It might not make it easier for those who are trying to
correlate the document text with old email messages.

> to the end of 3.2.4 - make it clear!

It is clearly stated in section 3.3.1

   The Transport Security Model REQUIRES that the security parameters
   used for a response are the same as those used for the
corresponding
   request.  This security model sets the tmSameSecurity flag to true
in
   the tmStateReference before passing it to the transport model.

> absolutely right but I see no text for that.

and as I recall, the WG consensus was that this was not neceeasry. If
a flow was directed into TSM and the securityModel is not TSM, that is
an implementation bug, not a TSM specification bug.

> from the truth, at all, except to obtain the tmStateReference?

tmStateReference records session-related information (except one
field,  that requires updating the transaction-specific sessionID
value from the associated incoming request)
securityStateReference records transaction-specific information.
In most instances, it makes no difference whether we use the values
from securityStateReference or tmStateReference because the values
will be the same.

why have both?
securityStateReference is defined, at least somewhat, in the RFC341x
series. Unfortunately, it is not very clear.
The definition of tmStateReference duplicates some fields because the
TM needs to tell TSM what the values are, and the TM has no access to
securityStateReference.

> that out lest these unused (for outgoing response) parameters
confuse.

I think the following text does this:
"If there is a securityStateReference (Response or Report message),
   then this security model uses the cached information rather than
the
   information provided by the ASI."
and
"If there is no securityStateReference then create a
   tmStateReference cache with tmRequestedSecurityLevel set to the
value
   of securityLevel, the tmSecurityName set to securityName, and
   tmSameSecurity set to false."

> I want to see 4.2 1) clearly spell out the usage of

I will review the text.
Additional comments from others welcome.

---

From: "Dave Shield" <[email-masked]>
Date: Thu, 20 Nov 2008 09:15:07 +0000

2008/11/19 David Harrington <[email-masked]>:
>> Since it has not been provided by tsm, then it is fortunate
>> that it is being ignored, but really, I have no idea what is going on here.
>

I believe that the transport Domain/Address information,
held within the tmStateReference cache are originally supplied
by the SSHTM itself, from when the request first arrived.

Following the path of an incoming request, the processing appears
to be as follows:

The Transport Model calls the Dispatcher    (receiveMessage)
   providing transportDomain/Address as parameters
   plus tmStateReference (which also contains transportDomain/Address)
The Dispatcher calls the MPM   (prepareDataElements)
   providing transportDomain/Address as parameters
   plus tmStateReference (which also contains transportDomain/Address)
The MPM calls the Security Model   (processIncomingMsg)
   providing tmStateReference (which contains transportDomain/Address)

  Control then passes back to the Dispatcher, which calls the
application (processPdu).
  The values returned by the Security Model to the MPM, and by the MPM
  to the Dispatcher include do not include any transport information.
  Neither does the application receive any tranport information.
  (At least not directly, although the stateReference contains the
  securityStateReference which contains the tmStateReference)

Following the path of the corresponding response, the processing appears
to be as follows:

The application calls the Dispatcher    (returnResponsePdu)
   providing no transport information (but including stateReference)
The Dispatcher calls the MPM   (prepareResponseMessage)
   providing no transport information (but including stateReference)
The MPM calls the Security Model   (generateResponseMsg)
   providing transportDomain/Address parameters    <=== ***
   (plus securityStateReference, which includes tmStateReference)

The MPM then passes control back to the Dispatcher,
   providing values for destTransportDomain/Address  <=== ***
   plus tmStateReference (which also contains transportDomain/Address)
The Dispatcher calls the Transport Model
   providing destTransportDomain/Address as parameters
   plus tmStateReference (which also contains transportDomain/Address)

> address that is different than the one used to receive the request,

The application doesn't have the opportunity to specify *any* address
infomation for a response message.   That is provided by the MPM
Message Processing Model (at the points marked <=== *** above).
Presumably cached from the processing of the incoming message.

  As such, this will inherently be the same value as originally supplied
by the initial Transport Model (both as transportDomain/Address parameters
and within the tmStateReference).

I believe that I've already raised the issue of transportDomain/Address
parameter values vs the contents of the tmStateReference (for TSM
processing of a response message).   In all the RFC3411 modules,
there are distinct ASIs for dealing with outgoing requests vs responses:

   sendPdu  vs  returnResponsePdu
   prepareOutgoingMessage vs  prepareResponseMessage
   generateRequestMsg   vs   generateResponseMsg

With the existing RFC 3411 architecture, these ASIs will either take
domain/address parameters (sendPdu, prepareOutgoingMessage) or
a reference parameter (returnResponsePdu, prepareResponseMessage)
but not both.

The only ASI that takes *both* address information *and* a state
reference as IN parameters, is the revised generateResponseMessage [sic]
defined in the current -tmsm and -tsm drafts

It would seem more sensible (IMO) *not* to add transportDomain/Address
parameters to the generateResponseMsg ASI, and to use the information
from the tmStateReference cache instead.
   Of course, generateRequestMsg *would* need these new transport
parameters, since it needs to set up the transport cache itself.

Dave

---

From: "Dave Shield" <[email-masked]>
Date: Thu, 20 Nov 2008 09:30:22 +0000

2008/11/18 tom.petch <[email-masked]>:
> question is, when they are not the same, who is doing the mapping and where

The (transport-aware) security model.

>  Whoever does it, I think that there is a problem that other parts of the stack
> need to know the mapping and do not.

The tmSecurityName is the concern of Security Model and the Transport Model,
and these modules only.  No other module need consider this value.

Most modules (application, Dispatcher, MPM, ACM) would only work with
the securityName.
The Transport Model would only wotk with the tmSecurityName  (plus any
internal means
of identifying the transport principal).

The only module that is concerned with *both* securityName and tmSecurityName
(and hence needs to know about the mapping between the two) is the
Security Model.

That's my understanding, anyway.

Dave

---

From: "tom.petch" <[email-masked]>
Date: Thu, 20 Nov 2008 18:19:46 +0100

tsm s. 4.2 2) leaves me puzzled.

"2) If there is no securityStateReference then create a
   tmStateReference cache with tmRequestedSecurityLevel set to the value
   of securityLevel, the tmSecurityName set to securityName, and
   tmSameSecurity set to false"

So if an application generates 99 GET in quick succession, then there will be 99
cache entries containg tmRequestedSecurityLevel and tmSecurityName but no
transport domain or address (nor security model) - perhaps in addition to an
entry created by a previous GET.

This seems to be a cache with an entry per message, like securityStateReference,
but at odds with the description in eg tmsm s 5.2 which says
"   The tmStateReference cache will typically remain valid for the
   duration of the transport session, and hence may be used for several
   messages."
or tsm s.3
"This document defines the requirements for a cache to handle the
   longer-term transport state information,..."

which, with other references has always left me with the impression that this
was a cache with an entry for each transport session.

Which is it, an entry per message, or an entry per transport session?  I see
problems with either alternative.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Nov 2008 19:35:12 +0100

> entry created by a previous GET.

The text says:

  1) If there is a securityStateReference then ...

  2) If there is no securityStateReference then ...

My reading is that the first message creates the
securityStateReference and then it is being reused. How do you read it
differently?

> problems with either alternative.

So what is the problem you see?

/js

---

From: "Dave Shield" <[email-masked]>
Date: Fri, 21 Nov 2008 08:49:30 +0000

2008/11/20 Juergen Schoenwaelder <[email-masked]>:
> securityStateReference and then it is being reused.

No - I believe Tom is correct here.

The securityStateReference is a parameter to the
generateResponseMessage ASI.   It isn't relevant
to the processing of (outgoing) Request messages.
It will be created as part of the processing of *incoming*
Requests, and only exists during the processing of
that single request (being discarded at the end of 4.2 step 1))
   It doesn't get reused.

The tmStateReference is a longer-term concept, and
*should* be reused from one request to the next.
The text of 4.2 step 2) should probably say something like

   If there is no securityStateReference (Request message)
then look for an existing transport cache entry matching the
requested parameters, and set tmStateReference to point to it.
If such an entry does not exist, then create one, with blah blah blah

That seems to be the thrust of the general summary description
in the last paragraph of TMSM 6.2.2

Dave

---

From: "tom.petch" <[email-masked]>
Date: Fri, 21 Nov 2008 14:36:27 +0100

<inline>
Tom Petch

----- Original Message -----
From: "Dave Shield" <[email-masked]>
To: <[email-masked]>; "tom.petch" <[email-masked]>
Cc: <[email-masked]>; "David Harrington" <[email-masked]>; "Wes Hardaker"
<[email-masked]>
Sent: Friday, November 21, 2008 9:49 AM
Subject: Re: [Isms] wg last call on isms document set - tsm b

> in the last paragraph of TMSM 6.2.2

Thanks Dave, that is how I see it
but ....

Can the tsm accurately find a transport cache entry? Does it have the
appropriate values of transportAddress, transportDomain, securityModel,
securityLevel, securityName or translations thereof to key into the cache?  I
think not.

I had no problem with the transport details until the recent change to secshell
which introduced tmTransportAddress whose meaning I remain uncertain of.  But
perhaps tmTransport... is  synonym for transport... and this is not a problem.

securityModel should be ok although there are parts of these I-Ds that seem to
suggest distinct caches per securityModel which is not what I had thought.

The other two I have problems with.  I saw consensus years ago that the
securityLevel as passed by the application was part of the key to the cache.
This was challenged earlier this year, saying that it was
tmTransportSecurityLevel that was used, Requested was ignored.  I have seen no
resolution to this but believe that mixing requested levels on a single secure
transport session will create security loopholes.

And security name, if it gets mapped from one value to another anywhere - and
most people seem to think it will need mapping somewhere sometimes - I think
will definitely cause problems since tsm and secshell can get out of synch.

So yes, it would be nice if tsm could locate a cache entry, in practice I think
it cannot.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 21 Nov 2008 19:02:51 +0100

Murky waters - see inline

Tom Petch

----- Original Message -----
From: "Dave Shield" <[email-masked]>
To: "tom. petch" <[email-masked]>; "David Harrington"
<[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, November 20, 2008 10:15 AM
Subject: Re: [Isms] wg last call on isms document set -secshell

>    (plus securityStateReference, which includes tmStateReference)

But...
the thinking was that it was up to the Security Subsystem to identify whether or
not a session existed and if so, to provide a reference to it in the form of the
OUT parameter tmStateReference for the Transport Subsystem to use.

So the Security Subsystem <had> to be told the transportDomain and -Address
since they were/are part of the 5-tuple (along with
security -Model, -Name, -Level) which are the identifier of any session.  If
those five are the same, then this is the session - if one differs, different
session.

At that time, tmStateReference was NOT part of securityStateReference so
transportAddress Domain could not be obtained in that way.

Perhaps this is no longer the consensus but that is why transportDomain/Address
is IN and tmStateReference is OUT for
generateResponseMsg

Tom Petch

> from the tmStateReference cache instead.

See above; there was a good reason for including them.  I also have concerns
here about the tmStateReference cache, entry per message or entry per session; I
see problems with either approach.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 21 Nov 2008 19:11:50 +0100

<inline>
Tom Petch

----- Original Message -----
From: "Dave Shield" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 20, 2008 10:30 AM
Subject: Re: [Isms] wg last call on isms document set -tmsm

> (and hence needs to know about the mapping between the two) is the

The problem now is that cache entries cannot be identified.

A cache entry is identified by a 5-tuple which includes a 'security' name.  If
this is securityName, which you say above is unknown to the Transport Subsystem,
then the Transport Subsystem can never identify a cache entry.  if it is the
tmSecurityName, then a session cannot be identified until the Security Subsystem
has performed its mapping ie the Application cannot know what will happen.

I convinced myself last year that it has to be the securityName, and the mapping
to tmSecurityName can only happen in the Transport Subsystem

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 21 Nov 2008 19:16:14 +0100

<inline>

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Cc: "'Wes Hardaker'" <[email-masked]>
Sent: Wednesday, November 19, 2008 9:38 PM
Subject: RE: [Isms] wg last call on isms document set- tsm

<snip>

> value from the associated incoming request)

Gosh, that has rocked me back on my heels. I had always imagined that
tmSessionID identified a session and stayed the same for the life of the session
which could encompass millions of transactions.

Doubtless I have missed the text that explains it is unique to a transaction;
can you point me to it please?

Tom Petch

> from securityStateReference or tmStateReference because the values
<snip>

---

From: "Dave Shield" <[email-masked]>
Date: Sat, 22 Nov 2008 13:14:39 +0000

2008/11/21 tom.petch <[email-masked]>:
> A cache entry is identified by a 5-tuple which includes a 'security' name.

What level of the RFC3411 architecture are you talking about?
Security, or Transport?

In the case of the security subsystem, what you say is probably true.

But in the case of the transport subsystem, the tmStateReference
cache holds the information relevant to a particular transport session.
So I'd expect the mapping to be more direct - perhaps via the
tmSessionID value.

>  If this is securityName, which you say above is unknown to the
> Transport Subsystem, then the Transport Subsystem can never
> identify a cache entry.

If the transport subsystem is processing an outgoing message,
then the cache entry is provided as one of the parameters to the
sendMessage() ASI.

If the transport subsystem is processing an incoming message,
then it knows which session the message was received on, and
can select the cache entry corresponding to that session.
Perhaps using the sessionID as the lookup key, or possibly the
transport cache will be part of the data structure for the transport
session.
   In any case, this is an implementation detail - it's not part of the
specs.   All that is required is that the transport subsystem can
map between a tmStateReference cache entry and the corresponding
transport session.

Dave

---

From: "Dave Shield" <[email-masked]>
Date: Sat, 22 Nov 2008 13:16:09 +0000

2008/11/21 tom.petch <[email-masked]>:
> securityLevel, securityName or translations thereof to key into the cache?

All five of these values are parameters to the generateRequestMsg() ASI.
So yes, it should be able to do a lookup into the transport cache, to check
whether there is a suitable existing transport connection for an outgoing
request.
    Why do you think there will be a problem with this?

> which introduced tmTransportAddress whose meaning I remain uncertain of.

I suspect that this may be a typographical error (possibly introduced by me).
By 'tmTransportAddress/Domain', I presume the intention is to refer to the
transport information held within the tmStateReference cache (rather than
the ASI parameter values).
  But the common description of the tmStateReference cache actually talks
about fields 'transortAddress' and 'transportDomain'.  So there's certainly a
naming inconsistency which needs to be sorted out.

Personally, I'd suggest that it would be useful to have distinct names for the
ASI parameters and the tmStateReference cache fields, so that it's clear
exactly what is being referred to.
   (Although the values will typically be the same anyway, as I indicated
yesterday).

> tmTransportSecurityLevel that was used, Requested was ignored.

If we're talking about establishing a connection for outgoing requests
(and then re-using this for subsequent requests), then the securityLevel
ASI parameter is the only possible candidate, since this is the *only*
security level value that is available to the security model.
   The tmRequestedSecurityLevel field is simply used to pass this value
down to the transport level.   It wouldn't make sense to use this field as
part of the cache lookup.

  If we're talking about what connection to use for an outgoing response
to an incoming request, then the appropriate tmStateReference cache
is already available in the securityStateReference cache.
   No lookup is needed.

  The only potentially problematical case is where a transport session is
established for an incoming request, and then the local system needs to
send an outgoing request (not a response) to the same remote destination.
If the transport level creates a tmStateReference cache entry, then it
would have to use tmTransportSecurityLevel (typically authPriv) as part of
the index, since this is the only security level information it knows.

   If the outgoing request was requesting authPriv protection, then the cache
lookup would succeed and re-use this established session for the outgoing
request.   But if the outgoing request needed weaker protection, then the
lookup would fail, and the engine would end up (unnecessarily) creating a
new connection for this traffic.
   But that's actually the same scenario as outgoing authPriv and authNoPriv
requests to the same destination, with no existing session present.   Once
again, the transport session lookup for one wouldn't match the session
established for the other, so you'd end up with two parallel transport sessions
for the two levels of security protection.
   It could even be argued that this is a feature, not a bug!

>                                                                           I have seen no

I'm not sure that this would happen.  (See above).

> will definitely cause problems since tsm and secshell can get out of synch.

The transport model doesn't need to know about the securityName.   It doesn't
even ever see it. The *only* name that the transport model is concerned with is
tmSecurityName (plus whatever it uses to identify principals internally).

Dave

---

From: "tom.petch" <[email-masked]>
Date: Mon, 24 Nov 2008 09:19:32 +0100

<Inline thrice>

----- Original Message -----
From: "Dave Shield" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "David Harrington"
<[email-masked]>; "Wes Hardaker" <[email-masked]>
Sent: Saturday, November 22, 2008 2:16 PM
Subject: Re: [Isms] wg last call on isms document set - tsm b

>     Why do you think there will be a problem with this?

a) Consider an incoming session request, successfully processed by the Transport
Subsystem, followed by a message.  The secshell transport model cannot know the
securityLevel and if, as you have suggested, the security subsystem is
responsible for translating between securityName and other name(s), then nor can
it be confident that it will know the securityName.  So the secshell tm creates
a cache entry, passes on a message but does not know the n-tuple to identify the
cache.

In general, I look at the quartet of outgoing request, incoming request,
outgoing response, incoming response and try to find a single set of
assumptions, a single set of interpretations of the text, that will cause these
four to be successfully processed.  It is easy to make assumptions that will
cause one or two of these to succeed, but for all four, I do not think that it
is possible.

> naming inconsistency which needs to be sorted out.

b) Yes, hopefully soon.  My recollection was that the original description of
the cache did not have any tm... names in it, just the names from the existing
ASI but in fact it was the other way round. tmTransportDomain and
tmTransportAddress were in I-Ds in 2005 (along with tmKitchenSink and everything
else:-).  I have pressed over the years for clarity in this area, for a
specification or indication of how the tm.. values are or may be derived from
the values in the RFC3411 ASIs.  My pressing has in some cases identified
aspects that would not work so I am still pressing:-)

>    (Although the values will typically be the same anyway, as I indicated

c) Well, I think the same for transport Address/Domain, potentially different
for securityLevel and securityName.

Tom Petch.

> >                                                                           I
have seen no

---

From: "tom.petch" <[email-masked]>
Date: Mon, 24 Nov 2008 09:24:04 +0100

<inline>
Tom Petch

----- Original Message -----
From: "Dave Shield" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>;
<[email-masked]>
Sent: Saturday, November 22, 2008 2:14 PM
Subject: Re: [Isms] wg last call on isms document set -tmsm

> So I'd expect the mapping to be more direct - perhaps via the

To quote tmsm, the update to RFC3411,

 " In summary, a unique combination of transportDomain,
   transportAddress, securityName, and securityLevel could serve to
   identify a given transport session.  Different values for any of
   these parameters would imply the use of a different session."

so while sessions are not supported and there is no session selector in the
Abstract Service Interfaces, I do expect that there is an n-tuple doing that
job, or an explanation of why that is not the case for a particular Transport
Model and the interactions of a Security Model with it.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 24 Nov 2008 10:11:50 +0100

Juergen

The end date of the last call is past so where have I got to?

I suspect that some of the procedures described in the I-Ds do not work but have
difficulty in being sure on account of underlying issues.  Hopefully, these, at
least in part, can be resolved fairly quickly.

1) the (re-)appearance of tmTranportAddress/Domain in secshell with no
explanation of how they relate to transportAddress/Domain.  Hopefully just an
editorial glitch.

2) does a single secshell transport session, assumed of course to have
authentication and privacy, multiplex messages of different securityLevel?  I
had always assumed not, based on discussions on this list and on tmsm s.3.3.1.
But earlier this year, I was told that no, of course multiplexing would happen.
I see this as an open issue.

3) why is securityModel not part of the 'session selector'?  It was present up
until tmsm-07 where it was removed "since this is not known for incoming
messages until the message processing model".  True, but also true for
securityLevel.  The implication is that if a USM 'session' is set up to a given
transportAddress/Domain with a given securityName/Level, then it is impossible
to set up a secshell session with the same 4-tuple since these have the same
identifier; aliter, an application cannot influence the choice between USM and
TSM.  I am not sure that this is what I want.

4) is the tmStateReference updated with each message, as the recent text
implies?  or is it long term information about the session that remains
invariant until the session is taken down?  I had always assumed the latter and
was surprised to see the former.

Tom Petch

---

From: "Dave Shield" <[email-masked]>
Date: Mon, 24 Nov 2008 12:49:33 +0000

> Model and the interactions of a Security Model with it.

I view that text as descriptive, rather then prescriptive.

A given transport session will be associated with fixed values for
the security information.   The n-tuple "could" be used to identify
a particular session (which is typically what would be done at the
higher-level modules - application and security).

   That's different from saying that this n-tuple "must" be used to
identify the session.   As I understand it, the Transport Model *will*
end up using the transport session appropriate for that n-tuple of values.
It's just that it doesn't use the n-tuple as a lookup mechanism
(so it doesn't matter that some of these values are not available).

Dave

---

From: "Dave Shield" <[email-masked]>
Date: Mon, 24 Nov 2008 13:02:39 +0000

> a cache entry, passes on a message but does not know the n-tuple to identify the

Indeed.
But I don't think that it needs to.
As long as it can map from a given transport session to the
appropriate cache entry,
and from a transport cache entry to the corresponding session, then it
will always
be using the appropriate transport for that particular n-tuple.
(Even though it
doesn't know what that n-tuple actually is).

It's the security model that would be using the n-tuple of security
values as a lookup
index.   So in the scenario you outline, it might well need to add
this mapping for the
incoming request to its local lookup table.    It could then use these
lookup values to
identify the same transport cache for the outgoing request

> four to be successfully processed.

I'll need to sit down and think about all the (valid) combinations of
these requests
to make sure that my reading of the current specs works correctly in all cases.
But I'm reasonably confident that everything should be OK.

Dave

---

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Nov 2008 22:27:49 -0500

Hi,

Let me respond with my view of the universe. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Monday, November 24, 2008 4:12 AM
> Subject: Re: [Isms] wg last call on isms document set
> 
> Juergen
> 

I need to check this one.

> I see this as an open issue.

I do not see it as an open issue.

Architecturally (i.e., in tmsm), an application can request different
levels of security. 
Practically, a security model that relies on lower layers to provide
security (i.e., TSM) cannot tell whether security level has been
applied as requested. It must take the transport model's assertion of
securityLevel.
Secure Shell Transport Model states:
   SSH provides the "none" userauth method.  The SSH Transport Model
   MUST NOT be used with an SSH connection with the "none" userauth
   method.  While SSH does support turning off confidentiality and
   integrity, they MUST NOT be turned off when used with the SSH
   Transport Model.

As a result, SSHTM does not support noAuthNoPriv or NoAuthPriv. The
only securityLevel it supports is authPriv.

An application cannot request noAuthNoPriv or NoAuthPriv and get such
a securityLevel from SSHTM. All requests are treated as (promoted to)
authPriv.

Since authPriv is the only level supported by SSHTM, it does not make
sense to have multiple sessions for the same securityModel and
securityname and securityLevel (authPriv) at the same remote address.
You only need one authPriv connection.

(And having three different authPriv connections called authPriv,
AuthNoPriv, and NoAuthNoPriv is simply misleading. I strongly
recommend against adding support for this "feature".)

For RFC3411 modularity purposes, an application has never been allowed
to specify a particular transport session (not that any existing
transport mapping HAD transport sessions). We do not pass any type of
transport session ID to the application subsystem, and the application
subsystem never passes a transport session selector in an ASI. An
application should know nothing about transport-specific sessions.
Even the (transport) security model should know nothing about
transport-specific sessions. That violates RFC3411 modularity.

We added sessionID to tmStateReference so a security model could store
an opaque reference to some type of transport session identification
so the security model can pass it back, so the transport model could
match requests and corresponding responses. 

> 
> 3) why is securityModel not part of the 'session selector'?  

**** We should not have a 'session selector' ****
The only place we should be dealing with transport-specific sessions
is in the transport model. Period!!!

I would be absolutely thrilled to remove all notion of session
selection from these documents, except the opaque sessionID required
for sameSecurity. I think the idea of allowing an application to try
to select a particular transport session is absolutely wrong from the
RFC3411 perspective.

The application can choose what transportDomain, transportAddress,
securtityModel, securityName, and securityLevel it would like used.

   However, because the handling of transport sessions is specific to
   each transport model, some transport models MAY restrict the
   applicability of these parameters for selecting an associated
   transport session.

And I should add ...
However, because the handling of securityName and securityLevel are
specific to each security model, some security models MAY restrict the
applicability of these parameters for selecting security properties.

(Keep in mind that the SNMPv1 Security Model and the SNMPv2 Security
Model [RFC3584] always tell an application that the securityLevel is
noAuthNoPriv, regardless of any additional authentication or
encryption provided by the transport used.)

> It was present up

I am certain that I do not WANT applications to try to select
particular transport sessions. And SNMP has no sessions to select. I
would be happy to remove the text that suggests "selecting a session"
makes any sense here.

But let's talk about 4-tuples. An application most certainly can
influence the choice between USM and TSM; every ASI on the path
between the application subsystem and the security subsystem includes
securityModel. That's how it gets delivered to the appropriate
security model.

The RFC3411 architecture is built on the principal that information
necessary to each model, and especially information that is modifiable
by each model, should be in a conceptually separate data store (e.g.,
a MIB module) for that model. This is important to make sure one model
does not cause side-effects by changing another model's datastore. 

Each security model uses its own MIB (or its own
implementation-dependent datastore). USM and TSM do not share
standardized datastores. Whether they do at the implementation-level
is implementation-dependent.

So any type of 'session selector' might mean totally different things
in USM and TSM and SNMPv1-SM and SNMPv2-SM, and might mean totally
different things in different transport models (or mappings), such as
UDP, TCP, CMOT, SSHTM, DTLSTM. 

That's why we should not have any mention of session selectors except
within a model that has model-specific sessions.

> was surprised to see the former.

Well, securityStateReference and tmStateReference are references.
securityStateReference references a specific securityState, and
tmStateReference references a particular tmState. It is
implementation-dependent how tmState and securityState and the
references to them are implemented (duh).

The sessionID field that is contained in the tmState is used for one
and only one purpose - to match corresponding request and response
sessions to ensure sameSecurity. It is never used for any other
purpose. And it is opaque to the security model.

The securityState includes a reference to a tmState. That
tmStateReference must reference the tmState that identifies the
session on which a request was received, so TSM can require the same
session be used when sending the associated response. It is
model-dependent (and possibly implementation-dependent) how the
transport model compares the sessionID value from a tmStateReference
and its notion of a current sessionID.

In my view of the universe, this means, every time we receive a
request, the associated tmStateReference must point to a tmState that
accurately records the sessionID the incoming message was received on.
As long as there is a request/response transaction in-process, we
cannot change the securityState (or its Reference) or the tmState (or
its Reference) or the sessionID field contained in that tmState. That
is true even if we receive another request before the first response
is sent.

If a session closes and another is opened while a request/response
transaction is in-process, we need to be able to look at the tmState
for the request and compare that to the current tmState to be used for
the response. If the security model REQUIRES sameSEcurity, and the
tmState for the request and the tmState for the response do not match,
then we MUST discard the message.

Let's assume I keep my tmStates in an array, and each entry identifies
a specific long-lived session. (The sessionID might simply be the
array index.)

Every time I receive a request, I pass a reference (or pointer) to the
appropriate array entry. But wait, there's more! Since the transport
model has no access to the PDU type, it doesn't know which messages
contain requests. Therefore it must pass a tmStateReference for each
received message, regardless of PDU, and the tmStateReference points
to the tmState for that incoming message.

If two incoming messages use different sessions, the tmStateReference
associated with each message is set to point to the associated tmState
used for each message. (So in my implementation, the first
tmStateReference might be a pointer to tmState[1], and the second
tmStateReference might be a pointer to tmState[2].)

If two incoming messages use the same session, the tmStateReference
associated with each message is set to point to the associated tmState
used for each message. (So in my implementation, the first
tmStateReference might be a pointer to tmState[1], and the second
tmStateReference might be a pointer to tmState[1] as well.)

If the transport model gets on outgoing message with a
sameSecurity=true, then the transport model checks that the sessionID
for the transport session used to send the message matches the
sessionID in the tmState that is referenced by the tmStateReference.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 25 Nov 2008 14:26:11 +0100

David

Thanks for the comprehensive reply; I am splitting out 4)

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Juergen Schoenwaelder'"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, November 25, 2008 4:27 AM
Subject: RE: [Isms] wg last call on isms document set

<snip>

> sessionID in the tmState that is referenced by the tmStateReference.

Yes, all this I agree with (but it's good to know we are on the same page).

My problem is then with
tsm-10 s 4.2  Elements of Procedure for Outgoing Messages 2)
which says
"If there is no securityStateReference then create a
   tmStateReference cache ..."
so 99 outgoing Request with the same securityName will create 99 cache entries,
many - perhaps all - of which will have the same securityLevel, none of which,
on the current text, will have a transportDomain/Address. This seems like a
cache entry per message.

The text used to be
" 3) If there is no securityStateReference, then find or create an
      entry in a Local Configuration Datastore containing the provided
      transportDomain, transportAddress, securityName, securityLevel,
      and securityModel, and create a tmStateReference to reference the
      entry."
which I always thought was ok (especially the reference to securityModel:-).

I do not know why we changed it between tsm-5 and tsm-6.  The only reference in
the change log that might be apt is
"      Replaced tmSameSession with tmSameSecurity to eliminate session-
      matching from the security model."

'Eliminate session-matching' would appear to mean create a separate cache entry
for each and every outbound message which does not have a
securityStateReference, cache entries which the stm then has to map to its own
'these are not sessions' cache entries.

So tmStateReference will point to a session entry for incoming messages and
outgoing responses, but to a very incomplete message entry for outgoing
messages.

Is this what we want?  If so, then I think that more words of explanation would
be desirable, in all three I-Ds.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Nov 2008 20:58:23 +0100

> The end date of the last call is past so where have I got to?

We received some substantial reviews, which is good.
 
> I suspect that some of the procedures described in the I-Ds do not
> work but have difficulty in being sure on account of underlying
> issues.  Hopefully, these, at least in part, can be resolved fairly
> quickly.

This is what I hope as well. And it will surely help our editors if
people can make concrete editing proposals such as replace "this text"
with "some new text" plus a rationale for the suggested change.

/js