Subject: [Isms] Tmsm#1: MUST Responses go back on the same channel?

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Feb 2007 08:47:12 -0500

>From Wes Hardaker (1/9/07):

> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
> *** *** *** 
>    					      Responses are expected
to
>    be returned using the same session that carried the corresponding
>    request message.  Reuse of sessions is not required for 
> conformance.
> 
> Um...  IMHO, this should be a MUST.  There are security implications
> if you send a response over a different session than the request
came
> in over.  Different sessions may use different cryptographic 
> properties
> (algorithms, etc).  Plus, once you start doing that you can actually
> play with the timing of messages as they arrive at the other end by
> slowing one session down and not the other, etc.
> 
> This, IMHO, is critical that responses go back on the same session.
> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
> *** *** *** 

There have been comments, prior to WGLC, saying this should not be
architecturally-mandatory, but should depend on the transport model
and/or security model.  

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

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Mon, 19 Feb 2007 16:13:33 +0100

I am not a security expert. But I tend to agree with Wes.
Remember that in USM we also have the rule that a response
needs to come back with the SAME securityLevel. This to
me is somwhwat analogous as to why Wes wants a stronger
statement that a response must come back on same connection.

my 2 cents
Bert 

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: vrijdag 16 februari 2007 14:47
> To: [email-masked]
> Subject: [Isms] Tmsm#1: MUST Responses go back on the same channel?
> 
> > properties (algorithms, etc).  Plus, once you start doing 
> that you can 
> > actually play with the timing of messages as they arrive at 
> the other 
> > end by slowing one session down and not the other, etc.
> > 
> There have been comments, prior to WGLC, saying this should 
> not be architecturally-mandatory, but should depend on the 
> transport model and/or security model.  
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> 
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 19 Feb 2007 10:57:50 -0500

Hi,

I understand that USM (and the SNMPv3 Message Processing Model)
requires this.
But I believe the RFC3411 'descriptive' architecture deliberately did
not mandate this.
There was discussion during SNMPv2/v3 development that there might be
circumstances where the request could be sent unencrypted, and the
response could be sent encrypted. 

TMSM is an architecture extension. Do we want to modify the
architecuture to require that all transport models and any security
models and message processing models that work with them MUST always
use the same session (or session-like mechanism) for the request and
the response? 

The RFC3411 architecture makes this decision model-dependent. If we
make this a MUST, we change the RFC3411 architecture.

I certainly agree that we could say SHOULD, and suggest that any model
that does not use the same session should explain the security threats
introduced by such a design. I hesitate to add such a contraint to an
architectural subsystem, since I cannot tell how such a constraint
might impact future models. It sounds like one more CLR.

Dbh

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Monday, February 19, 2007 10:14 AM
> To: David Harrington; [email-masked]
> Subject: RE: [Isms] Tmsm#1: MUST Responses go back on the 
> same channel?
> 
> > >    					      Responses 
> are expected

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 26 Feb 2007 14:11:08 -0800

[sorry for the delay]

>>>>> "DH" == David Harrington <[email-masked]> writes:

DH> I understand that USM (and the SNMPv3 Message Processing Model)
DH> requires this.

...

DH> TMSM is an architecture extension.

Extensions that have security ramifications on the original
architecture may need to impose additional constraints.

I think the issue is that you're trying to avoid it for the case where
it doesn't matter (EG, USM over UDP) which makes perfect sense.  But,
in the case where the security is entirely implemented by the
transport itself (as will be the case with ssh) then suddenly it
becomes necessary that the transport itself refuses to send responses
to queries that didn't come through it in the first place.

What worries me is this: lets say manager M wants to send a request to
agent A.  It believes the response will contain highly-sensitive data
that it wants to ensure is protected by at least AES security.

Under USM/UDP you can be assured that when the manager sends the
request, that agent A will double check (in the USM module) to make
sure that the response is at the same security level as the original
request.

Under TMSM, though, suddenly you're in a situation where as agent A is
processing the request and the original session between M and A gets
dropped and a new one is created using DES gets established
(regardless of which side establishes it; both are potentially
possible but it doesn't matter).  Now, since the transport is the one
that is picking where to send it if you don't require it to go back
over the same transport then suddenly you're sending the response back
with a potentially completely different set of security properties
than the request came through under (in this case, the response would
be sent back over DES instead of AES).

The agent has no ability to make an intelligent decision.  It doesn't
know what the security requirements of the response should be
protected by.  Only the person or application that sent the request
would know this.

Further, it's unlikely that the management stack would even warn the
user that the transport used was potentially the incorrect one.  If it
simply receives a message from the lower transport and wasn't handed
the security parameters under which the message was protected, it
likely wouldn't even know that the policy it sent the request with
wasn't followed by the responder.

With USM, this example wouldn't pose an issue.  The user's key,
protocols, and user name are all cached in the security state, so the
response will always be protected in the same way.  The encryption
algorithm couldn't have changed from AES to DES because it's
disallowed.  Even if the user's algorithm was reduced to NULL the
security cache still contains the proper information to send the
response back using the same mechanisms it was sent over.

In the end, maybe what you really want is to qualify the statement
such that it MUST NOT be sent over a different transport if the
transport itself is responsible for handling any of the message
security details.  (word smithing needed).  But fundamentally, you
could allow a USM/UDP request's response to go back over USM/TCP and
not care but it would be illegal to allow a TMSM/ISMS response to go
back over anything that wasn't the original transport.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Feb 2007 17:29:04 -0500

> dropped and a new one is created using DES gets established

The manager avoids this by not accepting such a connection.  Of course, he 
doesn't necessarily know what response is going to come over that 
connection, so he probably needs a uniform policy about what he is going to 
accept.

In an ideal world, the way to solve this is to provide a much richer 
concept of "security level" than SNMP currently has.  However, previous 
attempts have shown that both in design and operationally, this is very 
hard to get right.  IMHO, if someone thinks they can get this right, they 
should go off and do it, but not in ISMS.

In practice, the solution is to do exactly what Wes described - open a 
connection with the desired security properties, and assume the application 
will require the response to be sent back via the same transport.  For most 
applications, this assumption pretty much has to be true, because there's 
no other way to associate requests and responses.  For others, it has to be 
explicit.

I don't see a problem with requiring that responses be sent using the same 
security model (already true, AFAIK), and for TMSM, that the same transport 
session be used.  The main issue here is that I'd rather not see the 
session concept appear above the transport model, especially when it comes 
to deciding how to manage cached sessions and when to destroy them.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 26 Feb 2007 15:28:14 -0800

>>>>> "JH" == Jeffrey Hutzelman <[email-masked]> writes:

JH> The manager avoids this by not accepting such a connection.  Of
JH> course, he doesn't necessarily know what response is going to come
JH> over that connection, so he probably needs a uniform policy about what
JH> he is going to accept.

It's frequently been presumed in the past that managers may use
multiple protection mechanisms based on the requests they're
sending...  IE, authNoPriv for no-need-for-encryption data like
interface counters but authPriv for, say, policy data or something
worth protecting with encryption.  Now, having said that, I don't know
how many managers actually exist that make use of that concept but it
was in the usability design of SNMPv3 originally.

On the other hand in the ISMS world then if a manager opens two
connections with different security properties and the agent is
allowed to choose which it responds over then this is moot.

JH> In an ideal world, the way to solve this is to provide a much richer
JH> concept of "security level" than SNMP currently has.  However,
JH> previous attempts have shown that both in design and operationally,
JH> this is very hard to get right.  IMHO, if someone thinks they can get
JH> this right, they should go off and do it, but not in ISMS.

It's sort of there now, that's my point.  The combination of
USM/VACM/etc actually does provide some things that aren't really well
discussed in the RFCs themselves but I've heard being talked about by
vendors.  One of which is the ability to trust that the response will
be protected similarly as it was sent.  The "security level" isn't the
only mechanism that is assured today...  the level, the keys, the
integrity mechanism and the encryption mechanism are all assured by
the USM spec to be the same in the response.

JH> I don't see a problem with requiring that responses be sent using the
JH> same security model (already true, AFAIK), and for TMSM, that the same
JH> transport session be used.  The main issue here is that I'd rather not
JH> see the session concept appear above the transport model, especially
JH> when it comes to deciding how to manage cached sessions and when to
JH> destroy them.

I should have mentioned, that if the decision not to send it happens
at the SM level rather than the transport level, that doesn't bother
me.  IE, if the SM says "use transport X with ID #2 or nothing" that's
fine.  What I don't think is wise is the SSH SM saying "let it go
forward" and then the transport model later arbitrarily picking
which session to send it over.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 10:41:45 +0100

> make this a MUST, we change the RFC3411 architecture.

The text in question is:

   A Transport Model implementation MAY reuse an already established
   session with the appropriate transportDomain, transportAddress,
   securityName, securityModel, and securityLevel characteristics for
   delivery of a message containing a different pduType than originally
   caused the session to be created.  For example, an implementation
   that has an existing session originally established to receive a
   request MAY use that session to send an outgoing notification, and
   MAY use a session that was originally established to send a
   notification to send a request.  Responses SHOULD be returned using
   the same session that carried the corresponding request message.
   Reuse of sessions is not required for conformance.

Speaking as a technical contributor, I am fine with making the SHOULD
a MUST since there might indeed security holes that we are opening,
although I do understand Dave's argument that we should not
architecturally require this.

Speaking as a co-chair, it seems that so far most people supported a
MUST. If someone (except Dave) thinks we should be using a SHOULD,
please speak up now. Otherwise, I assume that the concensus is to go
with a MUST.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 10:56:42 -0500

Hi,

Sorry, this is a long one.

I have not been a strong proponent of one way or the other; I raised
this as an issue because somebody else raised the issue that security
properties were not required to be the same between request and
response; this was a deliberate decision of the snmpv3 WG to not make
this mandatory. The SNMPv3 WG made the decisioon model-specific. Then
they made it mandatory for the snmpv3-MPM and USM models. Obviously,
they had mixed feelings on the issue, but felt it best to allow for
the possibility of future models to support this rather than outlaw it
architecturally.

As I study this problem, however, I think there are real problems
associated with trying to require the Transport Subsystem to enforce a
decision that the same session must be used for request and
corresponding response.

1) Who knows what?

Before deciding on an answer for this issue, the WG should seriously
consider issue#3 - does a transport model know what operation is
contained within a message? i.e. does it know a message is a Response?

The ASIs have been designed such that the transport model does NOT
have that information. The transport model/subsystem does not know
whether a message contains a response or a request or a notification.
The transport model only sees an opaque outgoingMessage that needs to
be sent, or an opaque incomingMessage that needs to be passed to the
dispatcher.

The determination of what operation is/should be in a message is made,
for incoming and outgoing messages, by the message processing model.
The mapping of an incoming response to an outstanding request is
handled within the Message Processing Subsystem.

Part of the reason for this is to permit the extensibility of message
formats, including the operations contained in a message, without
impacting the security subsystem or the transport subsystem or the
disptacher (an application would need to know how to process the
operation). This allows co-existence of an SNMPv1 message processing
model and an SNMPv3 messafe processing model, since there are
operations specific to each protocol version (Trap, Trap-v2, GetBulk,
Inform, etc.).

Having the transport subsystem know about specific operations violates
the modularity of the architecture, and makes it harder to support new
operations in the system.

2) in a related question, who knows about transport session?

Remember that the "sessions" being discussed in TMSM and TSM are
purely **transport** sessions. They are NOT security sessions; they
are not messaging sessions. Since transport sessions are
transport-specific, the only portion of the system that knows about
transport sessions should be the transport-specific models. An SSH
session is not the same as a TLS session is not the same as a BEEP
session and so on. The notion of session is specific to the transport
being used.

The message processing model has no knowledge of transport sessions.
Nor does the Transport Security Model. 

The Message Processing Subsystem, which knows when an outgoing message
is a response, does have the securityStateReference cached
information, and can request the use of the same securityName,
securitylevel, transportDomain, and transportAddress as the request. 

3) who knows about the encryption algorithms used?

Wes argues that a request could be sent over an AES-encrypted session,
and the response could be sent over a less-secure DES encrypted
session if we do not require the same session be used.

Jeff responded with "In an ideal world, the way to solve this is to
provide a much richer concept of "security level" than SNMP currently
has.  However, previous attempts have shown that both in design and
operationally, this is very hard to get right.  IMHO, if someone
thinks they can get this right, they should go off and do it, but not
in ISMS."

The SNMPv3 WG struggled with this issue, especially given that both
the Community-based security and USM provide "authentication" but at
widely different levels of effectiveness. After studying the problem,
including much input from security experts, it was decided that this
was a slippery slope. It was decided that SNMP could only specify
whether authentication was provided, and whether encryption was
provided, without trying to standardize different security levels of
the mechanisms used, and without  standardizing an ASI to request
specific mechanisms or security options. 

It was decided by the SNMPv3 WG that SNMP should have no inherent
knowledge of the security mechanisms used. That was up to an operator
to configure. USM provided a vendor-neutral, mechanism-neutral, and
extensible MIB module that an operator could use to configure which
mechanisms could be used by each USM user. 

This WG has already decided similarly. It was decided that
implementations should support any mechanism allowed for the secure
transport protocol, and then it is the responsibility of operators to
ensure that reasonable options were configured. As editor, I fought
long battles that the WG should standardize which transport-specific
parameters should be saved in the cache and the LCD (issue#2) and I
lost, because doing this would hamper algorithm agility.

Therefore, the idea that the SNMP engine knows which transports are
encrypted with AES and which with DES seems out of scope for this WG.
That determination should be made by the operator who configures the
options for the underlying secure transports (and possibly by a AAA
"policy" support of the secure transport).

4) who should provide the mapping from model-independent parameters to
transport-specific security parameters?

It would be inappropriate for the MPM to know anything about
transport-specific sessions, and it would be especially inappropriate
to force the Message Porcessing Subsystem to know which encryption
algorithms were used for which transport-specific sessions, so the MPM
cannot choose which transport-specific session should be used for a
Response.

The Security Model has limited insight into both sets of information.
When the Message Processing Subsystem calls the Security Subsystem, it
passes the securityName/Level and transportDomain/Address information.
For SNMPv3, if it is a Response, then this will be the values
extracted from the securityStateReference cache to match the Request.

The Security Model can then look up any associated LCD info and pass
that to the transport model. The tmStateReference cache contains
transport-specific information, possibly including the mechanisms used
and other security options. But those are outside the scope of the
Security Model so we can avoid having to have an SSH-specific security
model to use with the SSH-specific transport model, and a TLS-security
model to use with the TLS transport model, and so on. We do not define
the cache or LCD format because this would force us to **standardize**
an SSH-specific LCD, and possibly an SSH-over-AES specific cache and
LCD, and an SSH-over-DES specific cache and LCD, and so on.

In the Transport-Security-Model, for an incoming message, an
implementation MAY save the transport-specific information in a Local
Configuration Datastore; for an outgoing message, if the
transport-specific properties have been saved in an LCD, then they
should be forwarded to the transport model for (possible) use. 

Should we REQUIRE saving the transport-specific info in an LCD? Should
we specify what information must be saved? Should we write a MIB
module to hold transport-model-security-specific info? 

Thus far, the WG consensus seems to be "no, we should not. We want to
keep knowledge of mechanism-specific information and options out of
view of SNMP, and keep it in the secure transport layer."

Given that, we need to be careful about trying to impose need-to-know
intelligence onto SNMP subsystems that thus far have no need-to-know.

dbh

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 4:42 AM
> To: [email-masked]
> Subject: Re: [Isms] Tmsm#1: MUST Responses go back on the 
> same channel?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 19:38:35 +0100

> decision that the same session must be used for request and

[...]

I am not sure I see the problem. Perhaps I am missing the conclusions
from your essay. ;-) The dispatcher knows the transport domain and 
transport address of a receiver. In addition, if we have a response,
we have a saved security state reference. Is this not enough information
to locate the correct session for a session based transport? Perhaps we
need to put the tmStateReference into the security state reference.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Feb 2007 11:06:15 -0800

DH> Sorry, this is a long one.

No problem.  I'm going to shorten it to specific points.

I do believe that you're thinking I'm saying something much different
than what I was trying to say.

EG: I never at all tried to say what's associated with:

DH> Therefore, the idea that the SNMP engine knows which transports
DH> are encrypted with AES and which with DES seems out of scope for
DH> this WG.

Specifically, I agree completely.  The SNMP stack shouldn't have to
know, understand, etc the nitty gritty details of an already opened
transport (it may have to in order to open one, but that's a different
case).  But that wasn't my point.

As worded, the document allows responses (specifically) to go back
over any session it so chooses.  This is all I take issue with.  *If*
you simply change that to a MUST this all goes away and there is no
need for snmp stack to understand the nitty gritty.  All it needs to
do is ensure that the response goes back over the same session, which
is significantly easier than trying to ensure that transport Y is
sufficient when it came in over transport X.  If you unsure that if
incoming is X then outgoing is X, then no magic knowledge has to go
anywhere *except* to ensure that the right transport session is used.
Because doing anything else, as you say, is way out of scope!  Doing
anything less, though, is insecure.

You already need to have a binding between the future transport
specific security models and the underlying transport.  Information is
already being bound between them that has never existed before because
the transport will be taking care of the security issues and
information will have to pass between them for the security model to
make heads or tails of the decisions it has to make about the message.

DH> Before deciding on an answer for this issue, the WG should seriously
DH> consider issue#3 - does a transport model know what operation is
DH> contained within a message? i.e. does it know a message is a
DH> Response?

IMHO, it doesn't need to and I wasn't trying to imply that.  What I
think MUST be able to happen is that the security model must be able
to say "use session X and nothing else".  I'm not trying to state that
the transport itself needs to know the internals of the packet.  I'm
trying to state that if the system as a whole can't promise that, the
system is broken.  I honestly don't care whether the decision happens
at the transport level or in the security model level.  But the
wording today implies the transport layer gets to make a security
decision (which secure transport to use) without guidance from
anywhere else.  It shouldn't be in charge of securing data.  It should
be a minion that is being directed by the security model because doing
anything else means the transport can trump the security model.  I
fail to see how that's ever a good thing.

Now stepping off the high soap box that seemed to grow while I was
standing on it...

The solution, in my mind, is that for security transports they must be
directed by the security model.  If the security model is willing to
say "I don't care and please use any available session" then that's a
different story, but I at least have the trust that it is making an
informed decision.  I don't think the transport model itself can.

I think I had more to say, but I think you're probably happy that I
forgot it.
-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 14:02:55 -0500

Hi,

OK. Maybe I'm seeing problems that don't exist.

Please tell me which text in which document needs to be changed to
meet the MUST requirement. Please be sure the ASIs and cache
definitions deliver the necessary information to where it is needed.

dbh

> Sent: Tuesday, February 27, 2007 1:39 PM
> To: David Harrington
> Cc: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Feb 2007 18:03:04 +0100

On Tue, Feb 27, 2007 at 02:02:55PM -0500, David Harrington wrote:
 
> meet the MUST requirement.

I think we are talking about the following text:

I think Wes' proposal was to change the SHOULD into a MUST. I can live
with this (as long as we consider a resumed TLS session the same
session - so we might end up discussing what a session is ;-). I am
also fine with a SHOULD in the RFC 2119 sense:

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course.

Since we are on an architectural level, using SHOULD and thereby
putting the burdon on security model designers to provide an
explanation if they choose to not do the SHOULD is just fine.

> Please be sure the ASIs and cache definitions deliver the necessary
> information to where it is needed.

If the ASIs support a SHOULD, they should also support a MUST. (The
SHOULD is pointless if the ASIs do not provide the information to make
it happen.)

So to summarize, I finally concluded for myself that the SHOULD
wording is just fine as it implies that transport models that do not
return responses over the same session need to explain why.

/js