Subject: Re: [Isms] Working Group Last Call tmsm-09

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Sep 2007 08:56:48 +0200

On Fri, Aug 10, 2007 at 09:36:34AM +0200, tom.petch wrote:
> Eeee, reading this does not get any easier
> 
> a) I would like to see more words on susbsystem/model/mapping since it has been
> a
> source of confusion on this list and is likely to be so to a wider audience.  I
> know that RFC3411 explains this point but I read that document several times
> without getting it.  I am looking at para. 2 towards the end.  Where it says
> "This document defines a Transport Subsystem extension"
> that is ambiguous; an extension to the Transport Subsystem or an
> extension to the architecture? and later it says
> 
> "through an SNMP Transport Model [RFC3417].  Such a Transport Model "
> well no; in the absence of a susbsystem, as now, there can be no model.
> 
> I suggest the following instead
> "The current RFC3411 architecture does not encompass transport (although RFC3417
> does define transport mappings).  This document adds a transport subsystem,
> based on the third approach, to the architecture,  and this enables the use of
> existing security mechanisms such as TLS [RFC4346] or SSH [RFC4251] within the
> enhanced RFC3411 architecture.
> 
> A companion document [I-D.draft-ietf-isms-secshell-08] defines a transport model
> which is based on SSH while [I-D.ietf-isms-transport-security-model] defines a
> security model which uses this approach"
> 
> (I am a believer in stating the obvious when that may not be obvious to someone
> who has not been following isms for four years:-).

good suggestion - editorial

> b) 3.2.1.1 /is/in/

editorial

> c) 3.2.1.2 I think that the transport model MUST be aware of the mapping between
> securityName and transportspecificName else how can it select the right
> transport?

I think an SNMP application passed the transportDomain and
transportAddress to the dispatcher in the sendPdu() ASI and hence the
dispatcher knows the transport to be used. Or was your point that you
want the text

   If a message is secured using a secure transport layer, then the
   Transport Model should provide the translation from the authenticated
   identity (e.g., an SSH user name) to the securityName in step 3.

to be changed such that it reads

   If a message is secured using a secure transport layer, then the
   Transport Model provides the translation from the authenticated
   identity (e.g., an SSH user name) to the securityName in step 2.

> d) ... and that is in step 2 not step 3.

editorial
 
> e) 3.3.1 is the use of 'agent' here wilful?  I notice that the term is banned in
> 'transport-security-model'

editorial

> f) 3.3.2 would seem to preclude the renegotiation of keys, a recommended
> practice during a long running session.  Suggest a rewording of the two
> sentences starting 'Cryptographic keys ...' to
> 
> "Fresh session keys should be established at the beginning of each session in
> order to provide authentication, integrity and confidentiality, whichever of
> these services are required."

As technical contributor, I am actually uneasy with both the existing
text and the suggested improvement since there are cases where you
really like to use session resumption due to the very short lifetime
of the underlying connections and the computational costs associated
with creating session keys. Perhaps we should just state that the
transport model should have a feature to establish and renegotiate
session keys instead of requiring this to happen at the beginning of
each session.

> g) 4 /pdutype/pduType/

editorial

> h) 5.2 'The tmStateReference captured
>    during processing of an incoming message SHOULD include a transport-
>    specific session identifier.'
> 
> I think that the nature of this identifier MUST be specified, either in the
> security or transport model.  Getting it wrong invalidates the security and it
> is not obvious what it should; the right answers for TLS and SSH are quite
> different.

I do not see why this needs to be specified - this identifier never
leaves the agent and is thus purely internal to the implementation and
the precise format of this identifier actually to some extend also
depends on the libraries that you use. Sure, the TSM and the *TMs need
to agree on the format of these identifiers so that they do not mix up
identifiers but I as a technical contributor consider this
implementation detail. (We use magic numbers at the beginning of a
struct to deal with this but I believe this is implementation detail.)

> i) <dbh e-mail 25apr07>
> 'The Transport Subsystem architecture document will reflect the SNMPv3
> WG's decision that **architecturally** this is a SHOULD.
> The decision is security-model-dependent, and the Transport Security
> Model will make it a MUST.'
> 
> I am still seeing a 'MUST' in this section.

Dave Harrington, can you please check?

> j) 6.2 I am still puzzled by the absence of prepareResponseMessage and cannot
> see how it works without it

Dave Harrington, can you please look at this? I think Tom makes a point that
prepareResponseMessage should also have an OUT tmStateReference.

/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://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Thu, 13 Sep 2007 08:18:29 -0400

Hi,

I'm getting a little short-tempered about what i consider to be some
pretty ridiciulous editorial changes, and I'm going to let it show.

Ask yourself a question - does the requested change make it easier for
an implementer to implement the specification or an operator to manage
their network? if not, why are we wasting time? I think we may have
already lost all the "customers" that wanted this solution while we
waste time dotting i's and crossing t's. They want to be abel to use
this technology to manage their networks! 

> I am looking at para. 2 towards the 
> end.  Where it says
> > extension to the architecture? 

Let's look at the phrase you were looking at - with the "to" included:
"This document defines a Transport Subsystem extension to the RFC3411
architecture based on the third approach."

Doesn't that answer the question already?

Does changing this to "This document adds a transport subsystem,
based on the third approach, to the architecture, ..." make it easier
to manage a network securely?

David Harrington
[email-masked]
[email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 13 Sep 2007 08:50:58 -0400

David Harrington writes...
 
> I'm getting a little short-tempered about what i consider to 
> be some pretty ridiculous editorial changes, and I'm going 
> to let it show.

> ...why are we wasting time? I think we may have already lost 
> all the "customers" that wanted this solution while we
> waste time dotting i's and crossing t's.

Apparently trivial editorial changes can be annoying.  OTOH, the document
editor has editorial discretion with respect to the draft.  WG consensus is
[only] required for technical changes.  The editor is expected to process
all _reasonable_ comments.

As to the timeliness of our work product, I don't think we can lay that
issue at the feet of a few [trivial] editorial comments, coming in late
during WGLC. That has more to do with the WG participants' rate of coming to
closure on some major issues.  That ship has sailed.  I don't think we need
to reject _meaningful_ editorial comments, at this point in time, solely on
that basis.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 13 Sep 2007 10:12:06 -0400

Hi,

> > enhanced RFC3411 architecture.

First, I disagree with "The current RFC3411 architecture" - as
compared to what? the future RFC3411 architecture? The RFC3411
architecture is cast in stone. It will never change. We are updating
the architecure, and when this is published (if we ever get past all
the i's and t's and get it submitted to the IESG), it will be the
RFCXXXX architecture.

"The current RFC3411 architecture does not encompass transport"
Then what is the box labeled "Transport Mappings" in the diagram in
RFc3411 section 2?
Why does RFC3411 have a subsection entitiled "Transport Mappings"?
What is the "Transport Mappings" in the diagram in section 3.1.3.1 and
3.1.3.2?
Why is transport mentioned in every ASI?
Of course it encompasses transport. It just doesn't use a formal
subsystem to do so.

The abstract of TMSM explains that we are adding a transport
subsystem: "This document defines a Transport Subsystem, extending the
Simple Network Management Protocol (SNMP) architecture defined in RFC
3411. This document defines a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work is
being done to expand the transport to include secure transport such as
SSH and TLS, using a subsystem will enable consistent design and
modularity of such Transport Models. This document identifies and
describes some key aspects that need to be considered for any
Transport Model for SNMP."

I do not quite agree that "this 
> enables the use of existing security mechanisms such as TLS
[RFC4346] or SSH 
> [RFC4251]...."

We could have simply used transport mappings for SSH and TLS. We did
not need a subsystem to enable this. We chose to add a subsystem (and
models) to make the transport terminology consistent with other
portions of the architecure, and to enable consistent design and
modularity of transport models.

Transport mappings and transport models are effectively the same
thing; newer "models" might pass transport-specific security
parameters to other subsystems in the architecture. See the text in
section 2.1: 
"The transport mappings defined in RFC3417 do not provide lower-layer
security functionality, and thus do not provide transport-specific
security parameters. This document updates RFC3411 and RFC3417 by
defining an architectural extension and ASIs that transport mappings
(models) can use to pass transport-specific security parameters to
other subsystems, including transport-specific security parameters
translated into the transport-independent securityName and
securityLevel."

I think thatis pretty clear and unambiguous, myself.

David Harrington
[email-masked]
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Thu, 13 Sep 2007 15:26:29 -0400

Hi,

Here are my responses, inline. 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, September 12, 2007 2:57 AM
> To: tom.petch
> Cc: ISMS WG
> Subject: Re: [Isms] Working Group Last Call tmsm-09
> 
> > a) I would like to see more words on 
> susbsystem/model/mapping since it has been
> > a
> > which is based on SSH while 
> [I-D.ietf-isms-transport-security-model] defines a

commented in a separate email.

> editorial

done
> > d) ... and that is in step 2 not step 3.

should is more accurate because it is possible that a future transport
model might not provide this translation for a valid technical reason.
Removing the should makes this an implicit MUST, which I believe is an
unnecessary CLR.

s/step 3/step 2/ done.

> > 'transport-security-model'

It was, but I modified it for consistency.

> session keys instead of requiring this to happen at the beginning of

I changed the text slightly:
"Cryptographic keys associated with the transport session SHOULD be
used to provide authentication, integrity checking, and encryption
services, as needed, for data that is communicated during the session.
The cryptographic protocols used to establish keys for a Transport
Model session SHOULD ensure that fresh new session keys are generated
for each session."

I changed the first sentence to reflect that the keys were associated
with the session, without saying when they were generated, and added
the "as needed" clause to reflect that not all servcies are
necessarily required for all transport models. I did not change the
second sentence; the SHOULD permits the valid technical exception of
support for session resumption, while still including the
recommendation for the start of each session. (and session resumtpion
presumably is resuming the same session.)

> editorial

done.

> struct to deal with this but I believe this is implementation
detail.)

We could define a MIB, which is a virutal interface to an
implementation-specific detail, and the implementation can totally
choose to ignore our standardized interface, and it would make no
difference on-the-wire. So I agree that we do not need to specify
this. 

If you have an example of how this could be a security problem, I have
no problem with you creating an implementer's note advising
implementers to be sure the implementation in the security models and
the implementation in the transport models agree on the format, but I
would certainly like to have that note explain why this is necessary
for security reasons. By the way, note the plurals, in case there are
multiple SMs that can work with the same TM, or multiple TMs that can
work with the same SM. And, of course, we would need consensus on the
content of the note.

> Dave Harrington, can you please check?

I rewrote the tmStateReference section of each document, and the
elements of procedure for each document, to clarify this.

> prepareResponseMessage should also have an OUT tmStateReference.

done.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 13 Sep 2007 18:58:15 -0400

Hi,

I have wordsmithed multiple places to help clarify this.

As I recall, the WG decided initailly to define the contents of
tmStateReference (around the time of the interim meeting), but later
decided not to define the specifics of the tmStateReference because
this is transport-specific.

One way I can clarify the multiple securityname ambiguity is to define
tmStateReference fields called tmSecurityName and tmSecurityLevel and
then the Security Model can work with those fields. Does the WG want
to go this way?

dbh

> From: David Harrington [mailto:[email-masked]] 
> Sent: Friday, August 24, 2007 9:32 AM
> To: 'tom.petch'; 'Jeffrey Hutzelman'; 'ISMS WG'
> Subject: RE: [Isms] Working Group Last Call - securityName
> 
> inline 
> 
> > >
> > > > tmsm 3.2.1.2.  Transport Subsystem and the RFC3411
Architecture
> > > >
> > > > seems clear enough
> > > >
> > > >    1) authenticate the principal, check integrity and 
> > timeliness of the
> > > >       message, and decrypt the message.  [Transport Model]
> > > >    2) translate parameters to model-independent 
> > parameters (Transport
> > > >       Model)
> > > >
> [...]
> > You are quite right; the words are clear and exact; it was my 
> > understanding that
> > got vaguer at this point because those words seem to 
> > contradict what is said in
> > 3.2.1.2.  I read, and read, 3.2.1.2 as saying that the Transport
> Model
> > translates between a transport level identifier and the (one and
> only)
> > securityName.   I now understand that the securityModel can 
> > use a different
> > value for securityName, based on the information it has.  For 
> > me, 3.2.1.2 does
> > not say that so I think the wording in 3.2.1.2 should be 
> > changed to be clearer.
> 
> 3.2.1.1 says:
>    (Note that these lists are simplified for illustrative purposes,
> and
>    do not represent all details of processing.  Transport Models
must
>    provide the detailed elements of procedure.)
> 
> But, I will wordsmsith this to try to make it less ambiguous.  
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2007 14:15:08 +0200

On Wed, Aug 22, 2007 at 07:16:33PM -0400, Jeffrey Hutzelman wrote:

> I think the simple thing to do here is for the TM to include a real session 
> identifier in the tmStateRef, and use that instead of matching to find the 
> correct session for a reply.
>
> However, even if you search for a session by matching transport address and 
> security parameters, having the "wrong" thing happen requires the 
> following:
>
> (1) I establish an SSH connection, authenticated as Alice.
> (2) I send an authentic SNMP request using USM, with USM username Bob.
> (3) While my request is being processed, I disconnect the SSH session,
>    then establish a new SSH session to the SNMP server _from the same
>    transport endpoint_, and this time authenticate as Bob.
> (4) The server's response goes to my connection, because it belongs to Bob
>    and has the right transport address.
>
> In this situation, something "wrong" has happened, but it has not 
> compromised security, because I proved I was "Bob" when I sent the message, 
> and again when I established the new SSH connecton, and I even still have 
> to know the USM key in order to process the response.

I think this can compromise security to some extend if you have USM in
authNoPriv mode since the response comes back in cleartext and may
contain data the attacker (who of course has to be able to
authenticate him as Bob) is not allowed to see. It won't be easy in
practice to mount this attack and requires a certain interesting
configuration of the SNMP agent to work.

But this seems a general USM "security property" if you want.  With
USM over UDP, after an authNoPriv request has been sent, an attacker
can get the response by replacing the UDP endpoint used by the command
generator's SNMP engine with its own endpoint.

Sure, if you use authNoPriv, you kind of agree that anybody able to
listen on the network can read the data anyway. Hence, this "attack"
will only be useful if you can't sniff the network but you are able to
control/replace the transport endpoints of a management system.

I believe it is important to realize that with USM over SSH you get
the security of USM and nothing more - and USM does not protect
responses unless you use authPriv mode.

Can we get away with documenting this properly in the security
considerations section(s)?

/js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 Sep 2007 11:59:37 -0400 (EDT)

On Fri, 14 Sep 2007, Juergen Schoenwaelder wrote:

> authenticate him as Bob) is not allowed to see.

No.  If the attacker can authenticate as Bob, the attacker _is_ Bob, for
all intents and purposes.  He is allowed to see anything that Bob is
allowed to see, and so security is not compromised by giving him
information that Bob is allowed to have.

Put another way, what the scenario I described means is that if a single
entity possesses SSH credentials for Alice and Bob, and USM credentials
for Bob, then he can (with some effort) arrange to send a request over an
SSH connection authenticated as Alice and get the response over a
different SSH connection authenticated as Bob.  This is a little odd, and
I can't think of any useful reason to do it, but it doesn't mean there is
a security problem.

> generator's SNMP engine with its own endpoint.

Yes.  Of course, with SSH involved, a real attacker need not even replace
the UDP endpoint in this case -- all he has to do is watch all the traffic
sent by the CP or received by the CG.

> responses unless you use authPriv mode.

That's not entirely true -- if you verify the SSH server's identity, you
get to run USM over an encrypted tunnel.  You can even do so securely.
The only problem is that if we try to match outgoing messages to SSH
sessions by transport address and security name instead of by "use the
connection the request came in on", then you won't get the responses _at
all_ unless your SSH and USM credentials agree.

> considerations section(s)?

I don't see a security consideration here.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Fri, 14 Sep 2007 18:40:36 +0200

<inline, omitting the agreed editorials; I still think that h) is a security
exposure, and probably a worse one than I can envisage ie a more
security-oriented person than I might like to look at it>

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>
Cc: "'ISMS WG'" <[email-masked]>
Sent: Thursday, September 13, 2007 9:26 PM
Subject: RE: [Isms] Working Group Last Call tmsm-09

> > >
> > > a)  (in a separate e-mail)
> >

See separate e-mail
> presumably is resuming the same session.)

OK

> work with the same SM. And, of course, we would need consensus on the

My issue here was/is that an identifier may or may not identify the session in a
secure manner and I want it to be in a secure manner.  For example, the SSH
session ID is a cryptographic binding of all relevant SSHv2 connection
parameters so you can trust, cryptographically, that it identifies the right
session.  By contrast, for TLS,  the session ID is not sufficient as it is
server-assigned and so could be assigned by an MITM to match a server's.  And I
wanted this identifier to be secure so that when passed securely to an upper
layer, then that could be used for channel binding, something which I believe
can solve a number of security problems and so would not want precluded at a
subsystem level (eg the initial SSH or TLS transport uses weak authentication
which could allow a MITM but then a further authentication by security model or
application, perhaps accesssing a third party, verifies that there is no MITM).

If the session identifier does not identify the session in a secure manner, then
(apart from removing the option of channel binding) I think that an application
may be fooled into sending data over the wrong session.

SSHTM says that if a session is closed, then session state information should be
discarded - I am not sure if this is enough to guard against this.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 14 Sep 2007 18:38:55 +0200

Separate reply for issue c)

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>

> > > Eeee, reading this does not get any easier
<snip>
> Removing the should makes this an implicit MUST, which I believe is an

I was hoping for an implicit (or even explicit) MUST.

This is for me the one unresolved issue, and one which has been discussed
further, by others, since my initial e-mail.  Taking a step back from the
details of cache, elements of procedure and ASI, what I would like (future)
models to be able to do is

a) map the name used in setting up the session into a different one, in the TM;
mapping can be an identity mapping

b) map the original name or the different one into the securityName used for
access control and in the sendPdu/processPdu, in the SM; mapping can be an
identity mapping

c) responses can be forced to go back over the same session as requests came in
on

d) application can select the session, pre-existing or new (using
transportDomain, transportAddress, securityModel, securityName, securityLevel)
(eg so a NO can use a pre-exisiting CG/CR session)

e) a secure transport may offer a greater level of security than an application
requested but the application need not be aware of this

all of which I think has been agreed over the life of this group.

So I work through the subsystems as amended by tmsm to see if this is possible,
if the right parameters are passed in the right places, by cache and ASI; and I
look for MUSTs to ensure it is, that a TM will do what it needs to to enable a
SM to play its part to achieve this.  Mostly, my suggestions have been accepted,
albeit with an improvement in the wording, but it is around security name and
security level that I still see difficulties.

And, as the recent discussion of USM over SSH showed (USM uses name from
securityParameters and has no knowledge of what the TM is using), I think it not
obvious from tmsm what is and is not possible.

Tom Petch

 /js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 14 Sep 2007 18:40:36 +0200

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>

See separate e-mail

OK

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 14 Sep 2007 18:38:55 +0200

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>

<snip>

Tom Petch

 /js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 14 Sep 2007 13:57:44 -0400

How does this look?

7.1.  Coexistence, Security Parameters, and Access Control

   In the RFC3411 architecture, the Message Processing Model makes the
   decision about which Security Model to use.  The architectural
change
   described by this document does not alter that.

   The architecture change described by this document does howvwer,
   allow SNMP to support two different approaches to security -
message-
   driven security and transport-driven security.  With message-driven
   security, SNMP provides its own security, and passes security
   parameters within the SNMP message; with transport-driven security,
   SNMP depends on an external entity to provide security during
   transport by "wrapping" the SNMP message.

   Security models defined before the Transport Security Model (i.e.,
   SNMPv1, SNMPv2c, and USM) do not support transport-based security,
   and only have access to the security parameters contained within
the
   SNMP message.  They do not know about the security parameters
   associated with a secure transport.  As a result, the Access
Control
   Subsystem bases its decisions on the security parameters extracted
   from the SNMP message, not on transport-based security parameters.

   Implications of coexistence of older security models with secure
   transport models are known:
      An SNMPv1 message will always be paired with an SNMPv1 Security
      Model (per RFC3584), regardless of the transport mappng or
      transport model used, and access controls will be based on the
      community name.
      An SNMPv2c message will always be paired with an SNMPv2c
Security
      Model (per RFC3584), regardless of the transport mappng or
      transport model used, and access controls will be based on the
      community name..
      An SNMPv3 message will always be paired with the securityModel
      specified in the msgSecurityParameters field of the message (per
      RFC3412), regardless of the transport mappng or transport model
      used.  If the SNMPv3 message specifies the User-based Security
      Model (USM), access controls will be based on the USM user.If
the
      SNMPv3 message specifies the Transport Security Model (TSM),
      access controls will be based on the prinipal authenticated by
the
      transport.

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 12:00 PM
> To: Juergen Schoenwaelder
> Cc: David Harrington; 'tom.petch'; 'ISMS WG'
> Subject: Re: [Isms] Working Group Last Call - securityName
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 Sep 2007 17:56:06 -0400

On Friday, September 14, 2007 06:40:36 PM +0200 "tom.petch" 
<[email-masked]> wrote:

> My issue here was/is that an identifier may or may not identify the
> session in a secure manner and I want it to be in a secure manner.  For
> example, the SSH session ID is a cryptographic binding of all relevant
> SSHv2 connection parameters so you can trust, cryptographically, that it
> identifies the right session.  By contrast, for TLS,  the session ID is
> not sufficient as it is server-assigned and so could be assigned by an
> MITM to match a server's.  And I wanted this identifier to be secure so
> that when passed securely to an upper layer, then that could be used for
> channel binding, something which I believe can solve a number of security
> problems and so would not want precluded at a subsystem level (eg the
> initial SSH or TLS transport uses weak authentication which could allow a
> MITM but then a further authentication by security model or application,
> perhaps accesssing a third party, verifies that there is no MITM).
>
> If the session identifier does not identify the session in a secure
> manner, then (apart from removing the option of channel binding) I think
> that an application may be fooled into sending data over the wrong
> session.

We're really not talking about an externally-provided identifier that is 
used to find a session from among a random selection of potentially 
existing sessions.  We're talking about a mechanism for making sure a 
response goes out over the same session the request came in on.  This isn't 
some complex standardized data structure with cryptographic binding; it's a 
pointer.  You don't need to say "the session with this exchange hash" 
(which you don't know anyway, because that's below the abstraction 
boundary).  It's sufficient to say "the session attached to file descriptor 
12".

If you _really_ think you want to be able to have SNMP applications do 
channel binding to a secure transport, then you need to figure out a way to 
pass channel bindings up through the SNMP architecture from the secure 
transport to the application.  Specifying what the channel bindings are 
isn't up to the SNMP framework; in most cases, it isn't even really up to 
the particular transport mapping, but instead will be specified for the 
underlying transport.

Personally, I don't see SNMP as a layer above which channel bindings need 
to be specified.  We are binding SNMP authentication into the secure 
transport below (in a transport-specific fashion) precisely so that SNMP 
applications don't need to worry about any such thing.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 Sep 2007 18:00:49 -0400

> 7.1.  Coexistence, Security Parameters, and Access Control

This looks good.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Sep 2007 08:50:48 +0200

> security level that I still see difficulties.

Please be concrete and point to the specific text which you think is
problematic and supply and explanation with suggested replacement
text. The idea of "I see difficulties around something" do not help us
to get issues worked out and resolved.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Sep 2007 08:58:55 +0200

> information that Bob is allowed to have.

I am talking about the response. The response in USM goes where the
"agent" believes Bob to be and that endpoint might not be Bob anymore.
 
> all_ unless your SSH and USM credentials agree.

An existing USM implementation following the architecture does not
know about the tmStateReference and hence the SSHTM lacks information.
Im real code, I believe all this is a non-issue since the binding of
the various pieces is typically much stronger compared to the
architectural model.

> I don't see a security consideration here.

So you are suggesting to do nothing?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Sep 2007 09:01:04 +0200

>       access controls will be based on the prinipal authenticated by

Fine with me.

/js

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Sat, 15 Sep 2007 11:07:34 +0200

Fine by me. Too bad we can't do SNMPv1/v2c over SSH unless we do more
work.
But good we describe it. a few typos are pointed out below

Bert Wijnen  

> Sent: Friday, September 14, 2007 7:58 PM
> To: 'Jeffrey Hutzelman'; 'Juergen Schoenwaelder'
> Cc: 'ISMS WG'
>    decision about which Security Model to use.  The 
> architectural change
>    and only have access to the security parameters contained 
> within the
>    associated with a secure transport.  As a result, the 
> Access Control

s/mappng/mapping/

>       An SNMPv2c message will always be paired with an 
> SNMPv2c Security

s/mappng/mapping/

>       Model (USM), access controls will be based on the USM 
> user.If the
>       access controls will be based on the prinipal 

s/prinipal/principal/

> authenticated by the

Bert

---

From: "David Harrington" <[email-masked]>
Date: Sat, 15 Sep 2007 08:55:29 -0400

Does the new text I added to the security considerations address this
adeqautely?

dbh 

> Sent: Saturday, September 15, 2007 2:51 AM
> To: tom.petch
> Cc: David Harrington; 'ISMS WG'
> Subject: Re: [Isms] Working Group Last Call tmsm-09c
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Sep 2007 15:31:35 +0200

On Sat, Sep 15, 2007 at 11:07:34AM +0200, Wijnen, Bert (Bert) wrote:

> work. But good we describe it.

Bert,

the transition path for many people depends on (a) how difficult is it
to setup and deploy a new version (including the installation of users
and keys) and (b) how much effort it takes to adapt existing scripts
or programs (where scripts probably cover a pretty significant
fraction of the installed space).

In terms of CLI / scripting API changes, TSM has the potential to do
really fine, e.g. you go from current NET-SNMP syntax:

  snmpwalk -v 2c -c public some.router.org ifInOctets

to 

  snmpwalk ssh:some.router.org ifInOctets

where your local identity is used as the SSH name (and thus
snmpSecurityName). If you want some other identity, you write

  snmpwalk ssh:[email-masked] ifInOctets

All this I think looks reasonably simple and familiar for CLI folks
and it does not at all matter whether under the hood you carry SNMPv2c
or SNMPv3 message headers. In terms of agent configuration (again
NET-SNMP), you get a few more directives where to find the host keys
and that is it.

/js

PS: For SNMPv2c over SSH, you would probably get something like the
    following (note I am thinking loud here):

    snmpwalk -v 2c -c public ssh:some.router.org ifInOctets

    This might be made to work but is essentially not different from
    running SNMP over TCP through an SSH tunnel, which you can in
    principle already do now. My point here, however, is that running
    SNMPv3/TSM over SSH can actually be made to look simpler than
    SNMPv2c over SSH (and this might also apply to internal APIs but
    that surely needs some more work to get sorted out and depends on
    the particularities of the SNMP stack you use).

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Sun, 16 Sep 2007 13:04:55 +0200

Thanks Juergen. I understood it that way too.

The issue is that in the SNMPv2c and SNMPv1 community-based security 
models (in RFC3584) we have define that the securityLevel MUST always
be set/assumed to be noAuthNoPriv. And so in the VACM tables, one would
probably NEVER allow write access to any MIB object instances.

So this SNMPv1/v2c over SSH does not help then, does it?
I understand, that in order to fix it, we need to update RFC3584
I guess. Such is life. It would have been nice if this would have
come sort of automatic.

peace,

Bert Wijnen  

> Sent: Saturday, September 15, 2007 3:32 PM
> To: Wijnen, Bert (Bert)
> Cc: David Harrington; Jeffrey Hutzelman; ISMS WG
> the transition path for many people depends on (a) how 
> difficult is it to setup and deploy a new version (including 
> the installation of users and keys) and (b) how much effort 
> it takes to adapt existing scripts or programs (where scripts 
> probably cover a pretty significant fraction of the installed space).
> 
> In terms of CLI / scripting API changes, TSM has the 
> potential to do really fine, e.g. you go from current NET-SNMP syntax:
> 
> All this I think looks reasonably simple and familiar for CLI 
> folks and it does not at all matter whether under the hood 
> you carry SNMPv2c or SNMPv3 message headers. In terms of 
> agent configuration (again NET-SNMP), you get a few more 
> directives where to find the host keys and that is it.
> 
> /js
>

---

From: "tom.petch" <[email-masked]>
Date: Sun, 16 Sep 2007 17:54:23 +0200

<At the bottom>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Saturday, September 15, 2007 8:50 AM
Subject: Re: [Isms] Working Group Last Call tmsm-09c

> to get issues worked out and resolved.

Juergen

The text in question is -09 3.2.1.2, where, in point c) of my original last call
comments, I said that  I thought that the transport model MUST be aware of the
mapping between securityName and transportspecificName. Everything else in this
e-mail is the explanation of why I think that not having a MUST could come back
to bite us at a future date.  I still think MUST would be the best choice.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Sun, 16 Sep 2007 18:04:25 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "tom.petch" <[email-masked]>; "David Harrington"
<[email-masked]>; <[email-masked]>
Cc: "'ISMS WG'" <[email-masked]>; "Jeffrey Hutzelman" <[email-masked]>
Sent: Friday, September 14, 2007 11:56 PM
Subject: Re: [Isms] Working Group Last Call tmsm-09

> applications don't need to worry about any such thing.
Jeff

I wasn't thinking primarily of SNMP applications doing channel binding but a
future Security Model, that is that TLS/SSH/etc establish a session with weak
authentication and then the Security Model, with more time and resouces, can
perform a stronger authentication - provided it has a something - eg in the
tmStateReferenced cache - which is cryptographically bound to the session.

As you say, the channel bindings are up to the transport but I wanted the
Transport Model - which is transport specific - to be required to identify what
would, or would not, be suitable.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Sep 2007 15:22:44 +0200

On Sun, Sep 16, 2007 at 05:54:23PM +0200, tom.petch wrote:

> Juergen
> 
> The text in question is -09 3.2.1.2, where, in point c) of my
> original last call comments, I said that I thought that the
> transport model MUST be aware of the mapping between securityName
> and transportspecificName. Everything else in this e-mail is the
> explanation of why I think that not having a MUST could come back to
> bite us at a future date.  I still think MUST would be the best
> choice.

So your request is to make the following change:

OLD:

NEW:

   If a message is secured using a secure transport layer, then the
   Transport Model MUST provide the translation from the authenticated
   identity (e.g., an SSH user name) to the securityName in step 3.

Actually, the translation is not directional (as some might read into
this piece of text) and we perhaps should talk about principals rather
than identities for consistency with the SNMPv3 terminology.

That said, any arguments out there to not make this change?

/js

---

From: "tom.petch" <[email-masked]>
Date: Mon, 17 Sep 2007 12:15:23 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>
Cc: "'ISMS WG'" <[email-masked]>
Sent: Thursday, September 13, 2007 4:12 PM
Subject: RE: [Isms] Working Group Last Call tmsm-09

> I think thatis pretty clear and unambiguous, myself.
David,

My wording could be improved but I still believe that the
existing text in s.2 of tmsm should be clearer, thinking of those who have not
lived through isms.  Preamble over, this is the point in the I-D when you say
why the document exists, and for someone who knows that SNMP over SSH has been
specified, looks for an RFC, finds three (none of which do so), I think it
important that these paragraphs be really simple and clear lest the reader gets
lost.  I think too that you are being over simplistic to say model and mapping
are the same - given RFC3411's great stress on the nature of a model - and that
some reference to that change is needed.

The text I am looking at is

"  This document defines a Transport Subsystem extension to the RFC3411
   architecture based on the third approach.  This extension specifies
   how other lower layer protocols with common security infrastructures
   can be used underneath the SNMP protocol and the desired goal of
   unified administrative security can be met.

   This extension allows security to be provided by an external protocol
   connected to the SNMP engine through an SNMP Transport Model
   [RFC3417].  Such a Transport Model would then enable the use of
   existing security mechanisms such as (TLS) [RFC4346] or SSH [RFC4251]
   within the RFC3411 architecture."

which I suggest replacing by

"The RFC3411 architecture includes transport mappings [RFC 3417] but not a
Transport Subsystem or Transport Models.  This document, using the third
approach, extends the architecture to include a Transport Subsystem which can
then contain Transport Models and, by doing so, enables the consistent design
and modularity of such Transport Models.  A Transport Model in turn enables the
use of existing security mechanisms such as TLS [RFC4346] or SSH [RFC4251]
within the architecture.

I note you do not comment on my second paragraph - I trust that that indicates
assent.

As you may gather, I see these paragraphs as key to the understanding of what
isms has done, ie much more than dotting t's and crossing i's.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 17 Sep 2007 12:17:37 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'David Harrington'" <[email-masked]>; "'tom.petch'"
<[email-masked]>; "'Jeffrey Hutzelman'" <[email-masked]>; "'ISMS WG'"
<[email-masked]>
Sent: Friday, September 14, 2007 12:58 AM
Subject: RE: [Isms] Working Group Last Call - securityName

> then the Security Model can work with those fields. Does the WG want
Works for me, especially as I see this in isms-secshell

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 17 Sep 2007 14:42:24 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>
Cc: "'ISMS WG'" <[email-masked]>
Sent: Saturday, September 15, 2007 2:55 PM
Subject: RE: [Isms] Working Group Last Call tmsm-09c

> Does the new text I added to the security considerations address this

I am not clear that it does.  The text is good and certainly should be included
but I think that 3.2.1 - which is where my concerns are - will need revising to
match.  I was and am concerned about the last sentence of 3.2.1.2 wanting the
'should' to be a 'MUST' although as Jeff pointed out, there are two cases here,
of STM with TSM (when I think MUST is needed) and STM with USM (where I would
still like a MUST even if, as has been now discussed, the actions of TSM will be
ignored because USM ignores tmStateReference)

Re-read 3.2.1 considering each of STM with TSM, STM with USM, UDP (as an
instance of insecure TM) with TSM, UDP with USM; I think that at least the
titles of 3.2.1.1.1 and 3.2.1.2 need amending

Tom Petch

<snip>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Sep 2007 10:18:06 -0400

Hi,

The wording in rev10 reads,
   If a message is secured using a secure transport layer, then the
   Transport Model should provide the translation from the
authenticated
   identity (e.g., an SSH user name) to a model-independent
securityName
   in step 2.

We are having difficulties designing an ISMS solution because, based
on the needs of the security model then under design (USM), a bunch of
MUSTs were specified by the SNMPv3 WG. It turns out that, when trying
to leverage other technologies, those MUSTs are inappropriate.

I think it is better to say should, to permit those protocol designers
who wish to add to this architecture in the future to make the
appropriate decisions, based on their better understanding of future
needs, rather than tying their hands with MUSTs based on our imperfect
knowledge of the future or based on the solution currently under
design. 

I prefer the wording of rev10. 

dbh

> Sent: Monday, September 17, 2007 9:23 AM
> To: tom.petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Sep 2007 16:36:21 +0200

On Fri, Aug 10, 2007 at 12:49:10PM +0200, tom.petch wrote:
> a) 2.2 says
> 'the Transport Security Model will make no assumptions
>    about there being a session of any kind'
> yet later it is required to passs a tmSameSession parameter.  Lest this seem
> contradictory, I would add a comment to 2.2 such as
> "but the Model will pass a tmSameSession parameter when appropriate for the use
> by session-based transports"
> 
> b) 2.3 suggest adding a note to the RFC-Editor to replace YY; not strictly
> necessary but keeps it simple; it is the only reference in the body of the
> document to YY
> 
> c) 4.3 Where it says
> 'and tmStateReference from the cache'
> I suggest "from the cachedSecurity Data"  I misread this as the
> tmStateReferenced cache which makes it a nonsense.

All three look editorial to me.

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 19 Sep 2007 09:28:20 +0200

Juergen

I looked at tmsm-10 for the issues that I had raised; three seem unresolved.

In 3.2.1.2, it says
"  If a message is secured using a secure transport layer, then the
   Transport Model should provide the translation from the authenticated
   identity"
where I would like a must (probably better than MUST).  The arguments are well
rehearsed.  No matter how clever those are who come after, I cannot see a STM
working with a TSM unless this translation is made available by the TM; any
other approach - eg putting it in the ASI or having the TSM extract it for
itself - would require a further change to the architecture.  As I mentioned, I
have dry-run the architecture ASI, EoP etc for a range of scenarios that might
occur, got stuck on this 'should' and spent ages wondering what subtlety I was
missing, finally concluding that I wasn't; but if I got stuck, others will too.
Jeff pointed out that it was not needed for STM+USM - true, but the STM does not
know architecturally what SM this message will go to, that is up to the MPP.
And the context of 3.2.1.2 for me is STM+TSM (should the title be changed from
'Transport Subsystem and the RFC3411 Architecture'? - after all, 3.2.1.1.1 is
'USM and the RFC3411 Architecture'; probably too minor to be concerned with).
And David does not like unnecessary MUSTs because they come back to inhibit
future development.

Anyhow, you know all this, so enough (too much:-) said.

But this raises a delectable irony with my second point.  In 5.2 it says
"  Each Security Model that supports the tmStateReference cache SHOULD
   pass a tmSameSession parameter in the tmStateReference cache for
   outgoing messages to indicate whether the same session MUST be used
   for the outgoing message as was used for the corresponding incoming
   message."

A dbh e-mail 25apr07 said
"The Transport Subsystem architecture document will reflect the SNMPv3
WG's decision that **architecturally** this is a SHOULD.
The decision is security-model-dependent, and the Transport Security
Model will make it a MUST."

I am still seeing that MUST; and when I look at tsm, I think I see a SHOULD
(although I am looking at the previous tsm I-D, not the revised tsm).  And these
MUSTs do have a habit of constricting those who come after us, who may come up
with a cleverer idea than us:-)

Finally, I was expecting to see a change around the two paragraphs in s2
starting
" This document defines a Transport Subsystem extension to the RFC3411.." which,
as I have said before, I see as key paragraphs to the understanding of the roles
of the three I-Ds.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 19 Sep 2007 14:25:23 -0400

Hi,

comments inline.

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 3:28 AM
> To: [email-masked]
> Cc: ISMS WG
> Subject: [Isms] must and should in tmsm-10
> 
> Juergen
> 
> And the context of 3.2.1.2 for me is STM+TSM 
> (should the 
> title be changed from

The text in the first two paragraphs of  3.2.1.1 provide the
simplified overview that is really important.

There have been multiple complaints about these lists and the
comparisons.
To make this simple, I will remove 3.2.1.1.1 and 3.2.1.2 and the last
paragraph of 3.2.1.1, then we don't need to worry about whether the
lists line up properly, or what we should title the lists. 

> with a cleverer idea than us:-)

s5.2 has a number of SHOULDs and a number of MUSTs. I am not sure
which MUST you object to.

p2 says if the response doesn't match the request, it SHOULD be
discarded, BUT
the decision is security-model-dependent, not architectural.
A security model can REQUIRE this. (or not, depending on the security
model)

p4 says each transport model SHOULD include a session ID so the TM can
determine whether the session is the same. (but an alternative
approach for identifying a session is acceptable as well)

p5 says the tmSameSession field should be supported in the cache, so a
security model can indicate whether it is REQUIRED or not. (I changed
the name of this in TSM, so there is currently a consistency issue
with the name; I'll fix that in the next rev. In addition, I think the
presence of this parameter needs to be transport/security
model-independent, so if there is consensus, I will make this a MUST
in the next rev.)

p6 says **if** the security model said it is REQUIRED, and the session
is not the same, then the transport model MUST discard the message.

I don't see the inconsistency in MUST usage that you apparently see.

> understanding of the roles

Section 1 is about the overall management framework, the SNMP
architecure, and where this subsystem fits within the overall
framework/architecture and where the ISMS documents "fit" within the
whole set of SNMPv3-related documents. The description of the roles of
the three isms IDs you proposed is in s1.2 "Where This Extension
Fits", which is the section that discusses the roles of other
documents that are needed to work with the subsystem. 

Section 2 is about motivation. The two paragraphs you refer to in
section 2 discuss how the subsystem addresses the motivations - common
security infrastructures, unified administrative security, use of
existing security mechanisms. Section 2 is not about the roles of
different documents and where they fit.

If the WG really wants the discussion of how the docuemnnt fit
together to be in the motivations section rather than in the section
that talks about how the documents all fit together, I'll move it.
Personally, I think the current organization makes more sense.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Sep 2007 13:18:11 +0200

> lists line up properly, or what we should title the lists. 

Speaking as technical contributor, I think that the processing steps
are actually useful to get an idea how things work. I am wondering,
however, whether this text perhaps be moved into the TSM document and
then the headlines would be "USM processing of incoming messages" and
"TSM processing of incoming messages". Right now, the problem seems to
be that the architectural extension is much more general and thus it
is kind of difficult to be concrete. The TSM document, however, can
easily be concret. So what about making this comparison an appendix of
the TSM document instead of deleting it completely?
 
> I don't see the inconsistency in MUST usage that you apparently see.

My reading of the the text matches David's explanation and I am not
really sure where the problem is or how to improve things. Tom, can
you re-read the text and tell us precisely what you want to get
changed?

> Personally, I think the current organization makes more sense.

Personally, I also think that section 1.2 is rather clear where the
pieces fit. If I would anything to explain this better, I would do so
directly before 1.3 by adding a sentence or extending that last
sentence before 1.3.

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 28 Sep 2007 09:36:45 +0200

Apologies for the much delayed inline response

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: "'tom.petch'" <[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Thursday, September 20, 2007 1:18 PM
Subject: Re: [Isms] must and should in tmsm-10

> the TSM document instead of deleting it completely?

Yes, I think that that would work very well; the information is worth having, in
the right context.

> you re-read the text and tell us precisely what you want to get
Ok, leave it as it is.  The paragraph I was referring to is
" Each Security Model that supports the tmStateReference cache SHOULD
   pass a tmSameSession parameter in the tmStateReference cache for
   outgoing messages to indicate whether the same session MUST be used
   for the outgoing message as was used for the corresponding incoming
   message."
where as I said before, I understood an earlier e-mail of David to be saying
that that MUST would become a SHOULD, but if you, Juergen, are happy, then leave
it as is.

> directly before 1.3 by adding a sentence or extending that last
Yes, adding a sentence to the end of s1.2 would be a good idea.  I agree that it
is clear for those of us who have followed isms but I do not think the
explanation of why there are three I-Ds will be clear to others (and I seem to
recall this having to be explained several times on this list). So I would add
(stating the obvious)
 - the Transport Security Model provides a concrete implementation of the
Security Subsystem, as an alternative to USM
 -  the Transport Model enables the use of existing security mechanisms such as
(TLS) [RFC4346] or SSH [RFC4251]
 - the Secure Shell Transport Model [I-D.ietf-isms-secshell] defines the such a
use for SSH

Tom Petch

/js