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

From: "tom.petch" <[email-masked]>
Date: Fri, 10 Aug 2007 09:36:34 +0200

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:-).

b) 3.2.1.1 /is/in/

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?

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

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

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."

g) 4 /pdutype/pduType/

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) <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.

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

Tom Petch

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "ISMS WG" <[email-masked]>
Sent: Wednesday, July 18, 2007 3:15 PM
Subject: [Isms] Working Group Last Call on three documents

> Dear all,
>
> This is the working group last call on all of our three current working
> group documents
>
> - Transport Subsystem for the Simple Network Management Protocol (SNMP)
>   <draft-ietf-isms-tmsm-09.txt>
>
> - Transport Security Model for SNMP
>   draft-ietf-isms-transport-security-model-05.txt
>
> - Secure Shell Transport Model for SNMP
>   draft-ietf-isms-secshell-08.txt
>
> The authors and the chairs think that these document are mature
> enough for WGLC.
>
> The first two already passed a first WGLC, but there were many
> comments and changes since then. They should be reviewed once more.
>
> Because we have the IETF meeting ahead and people are already busy with
> reviewing many other drafts, the WGLC will last more than the usual two
> weeks.
>
> Please do review these document and post your comments on this list until
> August 10, 2007.
>
> Please also post to the list if you have read one of the documents and
> are fine with it as it is.  It is very useful to know how many people
> have read the document.
>
> Thanks,
>
>     Juergen Q.
> --
> Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
> NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
> Registered in England 2832014
>
>
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms

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

---

From: "tom.petch" <[email-masked]>
Date: Fri, 10 Aug 2007 12:34:11 +0200

I remain confused about the translation between a transport dependent principal
name(TDPM) and the architectural securityName.

tmsm requires the Ttransport Model to find a matching session and securityName
is part of the key for the match, so the Transport Model must know the
securityName; self-evidently, it must also know the corresponding TDPM

Why then does transport-security-model say

'When the Transport Security Model is
   used with a secure Transport Model, the information in the cache is
   used by the Transport Security Model to translate between the
  security model-independent securityName and any identity used by the
   secure transport; '

Why does it need to know? Can it know for the first CR message of a session?  I
think that the Transport Model must know and that the Security Model need not;
if the Security Model were ever to change the mapping, then the Transport Model
should probably tear down the session and start again.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Aug 2007 08:55:33 -0400

Hi,

                      messaging          acm
                          ^               ^
                          |               |
                      msgSecParams      securityName
                          |               |
                          v               v
transport             security            application
  |<--------------------->|<--------------->|
   <--tmStateRef--------->|<--securityName->|

On incoming messages, 
I1) transport MAY provide a mapping between the transport-specific
identity and a **proposed** securityName, which it puts into the
tmStateReference cache.
I2) messaging extracts the security information from the message and
passes it to the selected security model
I3) the security model may extract an identity from the security
parameters passed from the messaging model as a *proposed*
securityName.
I4) the security model decides which proposed securityName becomes the
official securityName to be passed on to the application for use in
access control
I5) if this is an incoming request, then the security model saves the
security state information so the response can be sent using the same
security paramaters (which would include inforamtion about the secure
transport session used).

For outgoing messages,
O1) the application subsystem specifies the securityName
O2) the security determines if this is a response message, and if so,
extracts the security/transport info from the security state cache.
O3) the security model determines what identity should be put into the
message, if any, and what identity should be passed to the transport
model, if any. It uses information from the securityState cache when
making this decision for responses.

The decisions made at each step in the process are model-dependent. 
It is the responsibility of the security model to determine the value
of the securityname that will be used by the application and access
control subsystems.
The messaging subsystem makes the decision about which security model
will be used.
The transport and messaging subsystem MAY provide information to the
security model to aid in making the decision.

What each model knows at each step depends a lot on whether you are
talking about an incoming message or an outgping message, and whether
the outgoing message is a response. Can you ask your questions again,
making it clear whether you are in the flow of an outgoing message or
the flow of an incoming message?

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

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, August 10, 2007 6:34 AM
> To: Juergen Quittek; ISMS WG
> Subject: Re: [Isms] Working Group Last Call - securityName
>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Aug 2007 09:34:00 -0400

Hi Tom,

The comparison in 6) compares the securityLevel specified **in the
message** (extracted by the messaging model and passed to the security
model using the processIncomingMsg service primitive), with that
specified by the transport model and passed in the tmStateReference.

The value in the message is set based on the request of the
application.
 
dbh

> Sent: Friday, August 10, 2007 6:41 AM
> Subject: Re: [Isms] Working Group Last Call - securityLevel
> 
> I remain confused about the securityLevel in the 
> tmStateReferenced cache
> 
> transport-security-model says
> 
> '2) If there is no securityStateReference,
> [**ie Request, Notification]
>            then find or create an
>    entry in a Local Configuration Datastore containing the provided
> [**destination]
>    transportDomain, transportAddress, securityName, securityLevel,
and
>    securityModel, create a tmStateReference to reference the entry.'
> ie securityLevel is derived from the CR application
> 
> it also says, for an incoming message,
> 
> '6) Compare the value of securityLevel in the cache referenced by
>    tmStateReference to the value of the securityLevel parameter
passed
>    in the processIncomingMsg service primitive.  If the parameter
>    specifies privacy (Priv), and the cache specifies no 
> privacy (noPriv)
>    was provided by the Transport Model, or the parameter specifies
>    authentication (auth) and the cache specifies no authentication
>    (noAuth) was provided by the Transport Model, then the
>    tsmInadequateSecurity counter is incremented, and an error 
> indication
>    (unsupportedSecurityLevel) together with the OID and value of the
>    incremented counter is returned to the calling module.'
> 
> so here securityLevel in the cache is that derived from the 
> transport not that
> derived from the application
> 
> I cannot see how this checks that the transport level 
> security is not less than
> that requested by the application.
> 
> Tom Petch
> 
>

---

From: "tom.petch" <[email-masked]>
Date: Sat, 11 Aug 2007 11:52:48 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Juergen Quittek'"
<[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Friday, August 10, 2007 3:34 PM
Subject: RE: [Isms] Working Group Last Call - securityLevel

> The value in the message is set based on the request of the

Yeees; I see that s5.2 6) uses the value of securityLevel from the cache which
has been put there by the transport model but I also see that s4.3 2) has the
Transport Security Model place securityLevel in the cache and at that stage, the
transport model has not been invoked and so the
securityLevel referred to can only be that specifed by the application, it
cannot be that from the message.

So sometimes the securityLevel in the cache comes up from the transport,
sometimes it comes down from the application; yes?

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 13 Aug 2007 10:25:09 +0200

Thanks for the info.  The issue for me is the selection of the session for
outbound messages.  This is based on the model-independent securityName (tmsm
s.3.3) so the transport model must know that and so must also know the mapping
to any transport dependent principal name.

If the first message on a session is inbound, you say that the security model
has the final say in the mapping.  That is fine but the transport model then
needs to be told this prior to an outbound message (or even prior to the next
inbound message) and I would not gather this from the text in tmsm eg in
s3.2.1.1.  So if it is an architectural principle that the security model is
responsible for the mapping, then I think that the wording in tmsm needs
tightening.

If the first message on a session is outbound, then I am less clear how it
works.  I see a transport dependent principal name as being the province of the
transport, not something that the security model can dictate to transport, in
which case it is the transport model that is authoritative for the mapping.  Or
can the security model be authoritative?  Either way, I do not see definitive
text saying either and I am assuming that it is an architectural principle that
one or the other is authoritative for the mapping.  (Can the mapping be changed
as a result of an inbound response to the outbound message - I hope not)

I would like the text about the mapping (in both tmsm and trasnport security
model) either to be more vague, saying that this is not something that is
specified by the architecture, or else to be more specific, nailing down which
subsystem takes responsbility.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Juergen Quittek'"
<[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Friday, August 10, 2007 2:55 PM
Subject: RE: [Isms] Working Group Last Call - securityName

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Aug 2007 13:36:25 -0400

Hi,

I need to answer this in two ways.
First, you need to understand the limitations of what we can specify,
and then second, I will try make sure you understand how "mappings"
are handled.

First, you need to understand that we are not modifying the SSH
standard. We are providing an SNMP-specific interface to secure
transport protocols, and we are not dictating how the implementation
must handle sessions in the transport security protocol (or even
whether the secure transport uses sessions). We specify that when SNMP
says "give me secure transport for <securityName>, <securityLevel> at
this transport address", the implementation needs to determine how to
actually deliver that mapping given the chosen secure transport. There
are multiple SSH implementations, and the SSH WG did not define an API
for us to call to get a particular session. So there is some
background processing that needs to be done, preesumably via some type
of local configuration datastore, that the implementation can use to
get a mapping between the secure transport sessions and credentials
and the SNMP request parameters. The SSH WG decided not to write a MIB
to show conceptually how this transport-specific information is
maintained, and the ISMS WG decided not to write a MIB to show this
SSH-specific information either.

For the second point, see comments inline 

> Sent: Monday, August 13, 2007 4:25 AM
> To: David Harrington; 'Juergen Quittek'; 'ISMS WG'
> has the final say in the mapping. 

You may be onto something, but I cannot tell for sure because you use
language loosely. At what step in the Elements of Procedure is
information missing that is needed? Where should that information be
coming from? It would help immensely if you differentiated the
"mapping" you refer to. There are different mappings happening.

A secure transport model provides a mapping between the identity
authenticated by the transport and the proposed securityName in the
tmStateReference. That mapping is always the responsibility of the
transport model. This mapping happens with every message, even though
the authentication might be done on a transport-session-basis, and
therefore should be the same for every message received within a
transport session.

A messaging model may provide a field in the message to allow the
sending application to name a proposed securityName for the remote
message-named securityModel. USM does this. It is up to USM to
maintain such a mapping, e.g., via the USM-USER-MIB. This happens with
every message.

It is the responsibility of the securityModel to decide what inputs it
will consider in making the determination of securityName to be passed
to applications for an incoming message. And this happens for every
message.

It is the responsibility of the securitymodel to determine which
information needs to be passed to the remote securitymodel for
processing, for outgoing messages. For USM, the USM security model
puts the something in the securityParameters in the SNMPv3 message.
For TSM, it identifies which LCD entry should be used, based on
securityName, securityLevel, and transport address; the LCD should
contain the necessary transport-specific securityName->transport
identity mapping.

> That is fine but the 
> transport model then
> works.  

If the first message is outbound, then the implementation needs to
provide a mechanism for specifying how the initial transport
information is determined. We provide some exmaples using the
TARGET-MIB et al, but that is one approach to defining an LCD, but the
LCD is implementation-dependent.

> I see a transport dependent principal name as being 
> the province of the
> > > is part of the key for the match, so the Transport Model must
know
> > the
> > > securityName; self-evidently, it must also know the
corresponding
> > TDPM
> > >    used with a secure Transport Model, the information in 
> the cache
> > is
> > >   security model-independent securityName and any identity used
by
> > the

---

From: "tom.petch" <[email-masked]>
Date: Tue, 14 Aug 2007 16:18:36 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Monday, August 13, 2007 7:36 PM
Subject: RE: [Isms] Working Group Last Call - securityName

> contain the necessary transport-specific securityName->transport
David

The mapping that I am concerned with is the one used by the secure transport
model to select the transport session over which to send the message.  My
understanding is that, long ago, we achieved consensus that what the secure
transport used, a transport identity eg an SSH user name (although this model is
not limited to SSH), need not be identical to the securityName as used in eg
access control.  So there is a mapping and that is what I am unclear about from
the I-Ds.  And I am concerned at the architectural level, at the division of
labour between the security subsystem and the transport subsystem, as defined in
the ASIs, so that we have something that can accommodate fresh models.

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)

and below it says

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.

I assume that that is step 2 and I do understand that you have chosen only a
'should' and not a 'SHOULD' or a 'MUST'

But 3.2.2 gets a whole lot vaguer

'A Security Model may have multiple
   sources for determining the principal and desired security services,
   and a particular Security Model may or may not utilize the
   securityName mapping and securityLevel made available by the
   Transport Model when deciding the value of the securityName and
   securityLevel to be passed to the Message Processing Model.'

So I used to understand that the transport model generates the securityName that
will be used in access control.  But your previous e-mail said that the security
model had the last word on the mapping and this e-mail talks of proposed
securityName so it seems you have two mappings in mind, between securityName
used in access control and securityName proposed by transport and between
securityName proposed by transport and transport identity.

I think that the mapping matters because when a session-oriented secure
transport model is passed an outbound message, it has no transport selector and
uses securityName, securityLevel, and transport address to select a session; get
the wrong session and you have undermined security.  I see a need for the
mapping(s) to be in place and current for the  secure transport model to select
the right session for an outbound message lest security be undermined.

But look at 3.3.3
'A Transport Model session will have a single transportDomain,
   transportAddress, securityName and securityLevel associated with it.'
' For Transport Models, securityName should be specified during session
   setup, and associated with the session identifier.'
Note that this says 'session setup' not 'when the first inbound message is
processed by the security model'; although again, it is only a 'should'.

Or 6.3.
'If one does not exist, the Transport Model might create a cache
   referenced by tmStateReference.  If present, this information might
   include transportDomain, transportAddress, securityLevel, and
   securityName, plus model or mechanism-specific details.'

This all seems inconsistent with the transport model proposing a securityName
and the security model deciding on a different one as you now describe.  I have
no problem with that being the architecture, it is just that tmsm (and other
I-Ds) seem inconsistent about this point.

Overall, I cannot assign one meaning to 'securityName' and make sense of the
document.

Tom Petch

<snip>

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 14 Aug 2007 14:05:25 -0400

Tom Petch writes...
 
> This all seems inconsistent with the transport model proposing a
> securityName and the security model deciding on a different one 
> as you now describe.

Perhaps my understanding of what function securityName serves in the SNMP
architecture is fuzzy, so please correct me as required.  It would seem to
be a model-independent name that various models can use to identify the
principal, and perform functions such as finding the right encryption and
decryption keys or assigning the right access control rights.  Was it
originally envisioned in the SNMP architecture that different models (i.e.
different subsystem instantiations) would hold a different view of this
object for the same SNMP "transaction"? 

If the intent was to have a consistent, but model-independent name, that
would make a lot of sense.  I, too, have some unease about the notion of an
inconsistent name.  If names are used inconsistently, it seems that all
sorts of security problems are possible.

> Overall, I cannot assign one meaning to 'securityName' and make sense
> of the document.

Do we in fact have one meaning?

---

From: "tom.petch" <[email-masked]>
Date: Wed, 15 Aug 2007 10:58:16 +0200

There is another related issue on security level, best raised sooner rather than
later, namely that a secure transport can renegotiate the Cipher Spec so a
secure transport can go from authentication and privacy to authentication only
and vice versa, without changing its session identifier.

If the secure transport updates the information in the cache referenced by
tmStateReference when this happens, as the I-D suggests, and at this time, there
is still a message being processed by the security model, then the security
model could extract the wrong information from the cache so a message received
with authentication and privacy could be discarded because the secure transport
is now authentication only, or an invalid message could be let through because
the message arrived with authentication only and only later was the secure
transport upgraded to authentication and privacy..

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 15 Aug 2007 08:52:27 -0400

We don't have control over how the SSH is configured. IIRC, We specify
that operators are expected to ensure it is configured for auth and
priv. If they don't, there isn't much we can do about it. We also tell
them not to configure noAuth, but they can and we cannot do anything
about it. The SSH standard does not give us any way to check.

I'll make note to double-check our wording.

dbh
> Sent: Wednesday, August 15, 2007 4:58 AM
> Subject: Re: [Isms] Working Group Last Call - securityLevel changes
>

---

From: "tom.petch" <[email-masked]>
Date: Fri, 17 Aug 2007 15:57:28 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Wednesday, August 15, 2007 2:52 PM
Subject: RE: [Isms] Working Group Last Call - securityLevel changes

> I'll make note to double-check our wording.

The wording in 'draft-ietf-isms-secshell-08' is fine, namely,

"While SSH does support turning off confidentiality and integrity, they SHOULD
NOT be turned off when used with the SSH Transport Model."

(although MUST NOT might be better)

What I am saying is that this capability is widely present in secure transports;
with the way in which the cache is used,
it creates a security loophole in the architecture and so should be flagged as
such in tmsm.

<snip>

---

From: "tom.petch" <[email-masked]>
Date: Mon, 20 Aug 2007 09:05:28 +0200

----- Original Message -----
From: "tom.petch" <[email-masked]>
To: "David Harrington" <[email-masked]>; "'ISMS WG'" <[email-masked]>
Sent: Friday, August 17, 2007 3:57 PM
Subject: Re: [Isms] Working Group Last Call - securityLevel changes

> it creates a security loophole in the architecture and so should be flagged as
Just to be more specific, I am suggesting adding wording to tmsm, either what we
have in secshell, that security level of the transport SHOULD NOT be changed,
or, if that is too restrictive in the architecture, as opposed to a model, then
a warning that a change in security level could lead to a security exposure
since the security subsystem may not have access to information relevant to the
message it is processing.

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 17:50:01 -0400

>    securityLevel to be passed to the Message Processing Model.'

That's not vague at all; it means exactly what it says.  The secure 
transport model proposes a securityName and securityLevel based on the 
properties of the secure transport.  The security model, which sits at a 
conceptually higher layer in the stack, is free to use that information or 
ignore it.

If you use the SSH transport model, then it is going to derive a 
securityName from the authenticated SSH username (we've mostly agreed that 
this derivation is in fact the identity mapping, though it doesn't have to 
be).

If you also use the transport security model, then it is going to go ahead 
and use the securityName provided by SSH, and that becomes the name used 
for access control.

If you use SSH but use USM as your security model, then USM is going to 
ignore the securityName provided by SSH, and instead use the one contained 
in the SNMPv3 message.  It's also going to get the securityLevel from the 
SNMPv3 message, and verify the message using the appropriate USM keys and 
so on.  In other words, USM-over-SSH gives you exactly the same security 
parameters as USM-over-UDP.

> So I used to understand that the transport model generates the
> securityName that will be used in access control.

If you use TSM, that is effectively true, because TSM is defined to use the 
securityName proposed by the transport model.  If you use some other 
security model, it generally not be true, because the other security models 
will use different ways of deciding what name to use.

> transport model is passed an outbound message, it has no transport
> selector and uses securityName, securityLevel, and transport address to
> select a session; get the wrong session and you have undermined security.

Ah, I see what you're getting at, but I don't think there's a problem.

For an incoming message, there are multiple potential sources of security 
information.  One is the transport model, another is the security 
parameters in the SNMPv3 message, and still another is any private source 
of information available to the security model (for example, if you had a 
security model that used public key signatures with certificates, then the 
sender's certificate might have security name information).

Someone has to decide which of these sources of information is used to 
determine the parameters seen by access control and the application, and 
architecturally, that someone is the security model.  The securityName 
proposed by the secure transport model is intended to be in the same 
namespace as the one eventually selected by the securityModel, so if the 
security model chooses to use that information, it will generally do so by 
copying.

For an outbound message, there is no decision to be made -- the 
securityName came from the application, and while there might be multiple 
consumers of that information (the security model, the SNMPv3 message 
security parameters, and the secure transport model), they all consume the 
same value, which is the one provided by the application.

The issue I think you're driving at is selection of the proper session for 
an outbound message.  The correct handling of this depends on whether the 
message is a response or not.  If the message is a response, then the 
correct session (assuming the transport is session-oriented) is the session 
on which arrived the incoming message to which the present message is a 
response.  The way this works is that on an incoming message, the transport 
model places into the tmStateRef enough information to find the session 
used, and this information is passed back to it along with the outgoing 
reply.  The session to be used for the reply is located based on this 
cached data, not the securityName/securityLevel/transport address.

For an outgoing message which is not a response, the correct session is one 
for the specified securityName, securityLevel, and transport address. 
There is no ambiguity or chance of choosing the "wrong" session, because 
there is only one securityName inolved, that being the one specified by the 
application.

> I see a need for the mapping(s) to be in place and current for the
> secure transport model to select the right session for an outbound
> message lest security be undermined.

On an incoming message, there certainly is a mapping from the name proposed 
by the transport model to the one eventually given to the application. 
However, that mapping is not necessarily reversible -- the security model 
may choose to ignore the name proposed by the transport model and instead 
use one from another source; in this case all names proposed by the 
transport model would map to the same value, namely, the value given by the 
other source.  However, this is not a problem because for a message that is 
a response, the securityName need not be used to identify the session to be 
used.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 18:02:17 -0400

> about it. The SSH standard does not give us any way to check.

The SSH standard does not give you any way to check because any interface 
between SSH and applications built on top of it is application-specific and 
out of the scope of the SSH standard.  You could certainly impoose 
requirements on the algorithms in use, and require that implemtnations 
check that those requirements are met.  A compliant SSH-TM implementation 
would then have to use an SSH implementation that provides a suitable 
interface.

However, I would not recommend doing so, for several reasons.  First, the 
reality is that most SSH implementations do not provide a rich enough 
interface for this, and so SNMP implementors would be forced to choose 
between ignoring this requirement or modifying their SSH implementation to 
allow them to meet it.

Second, SSH algorithms don't have properites you can check for this, 
because SSH doesn't need them.  SSH always provides an encrypted, 
integrity-protected channel; the question is how good the encryption and 
integrity protection are.  Obviously, "null" algorithms exist which go 
through the motions but don't actually provide any protection.  There are 
also algorithms which attempt to provide protection but are no longer 
strong enough.  And there is no sharp line between these.

So, since SSH always provides encryption and integrity protection unless 
you do something stupid, the securityLevel associated with an SSH session 
always indicates both properties.  If you've configured SSH to use the null 
encryption algorithm, you still have encryption; it's just really bad.

-- Jeff

---

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

Thank you Jeff. Your analysis is very thorough, and I believe it is
fully accurate.

A couple minor comments. 

> From: Jeffrey Hutzelman [mailto:[email-masked]] 

> > select a session; get the wrong session and you have 

We do have a transport selector; it is the transportDomain parameter
that accompanies the transportAddress in the ASIs. For the SSH-TM, it
is snmpSSHDomain and the address is of type SnmpSSHAddress. 

We even have a session-selector because we specify that "SSH sessions
are uniquely identified within the SSH Transport Model by the
combination of transportAddressType, transportAddress, securityName,
and securityLevel associated with each session."  

[note to self: should this transportAddressType wording be
transportDomain?]

> same value, which is the one provided by the application.

The application is required to provide not only the securityName, but
also the securityModel. The securityModel knows how to "reverse the
mapping" to send the right parmaters to the other pieces that will
process the outgoing message (the message processing model and the
transport model).

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 19:16:33 -0400

>> > select a session; get the wrong session and you have

Note that the above was written by Tom and not me.

> is snmpSSHDomain and the address is of type SnmpSSHAddress.

Sure, but I think he means "transport session selector".

> and securityLevel associated with each session."

Yes, but Tom's point is that that alone doesn't always help you.
For a message that is a response, the securityName associated with the 
message will have been provided by the application, and should be the same 
as the securityName of the original request.  However, in the USM-over-SSH 
case, this may not be the same as the securityName that the transport model 
proposed, and if not, there is no way to recover that name.  So if you use 
the transport address and security parameters to find a session, you may 
end up with the "wrong" session; that is, one whose ssh username agrees 
with the name provided by USM but which is not the same session the request 
came in on.

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.

What is more likely is that I do (1) and (2), and then the server is 
confused about where to send the response because there is no ssh session 
from Bob.

> process the outgoing message (the message processing model and the

Well, no, not entirely.  USM does not know how to regenerate the SSH 
username that it discarded.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Wed, 22 Aug 2007 19:34:09 -0400

Ah! I agree. The security model saves the security state for use with
responses, and in the USM over SSH combination, the USM does not know
about or save the SSH security state or the mapping from the
application/securityCache securityName to the transport mapping
securityName. I don't know how to make the "legacy" security models
understand about transport security parmeters without rewriting them.

The only solution I can see is to force the choice of security model,
which means the USM over SSH combination cannot be chosen, which
violates the architecture.

dbh

> Sent: Wednesday, August 22, 2007 7:17 PM
> To: David Harrington; 'tom.petch'; 'ISMS WG'
> Cc: Jeffrey Hutzelman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 20:32:04 -0400 (EDT)

> violates the architecture.

Hrm.  Why does it have to be the security model that saves state between
request and response?

I actually think it would be acceptable to say you can't use the USM over
SSH combination if the security parameters don't match.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Aug 2007 02:17:13 -0400

Hi, 

> Sent: Wednesday, August 22, 2007 8:32 PM
> To: David Harrington
> Cc: 'tom.petch'; 'ISMS WG'

That's what the architecture demands. 

The transport model doesn't know what the operation in the incoming
message is; it doesn't know if the message contains a request or a
response. This is because the message has not yet been parsed by the
MPM.

The MPM doesn't know what the security parameters are; the
securityParmeters in the message are opaque to the MPM; those are only
unpacked by the security model. So the security model has to be the
one to ave security state.

> SSH combination if the security parameters don't match.

What security parameters do you want to "match"? These are different
protocol parameters at different layers. Can you say that SSH cannot
be used over IPsec if the parameters don't match? They are at
different layers and use different parameters.

The MPM selects which security model to use, but the MPM doesn't know
what the security parameters are. And once the MPM has selected the
USM, the USM has no way to determine the security parameters related
to a secure transport. We've done a good job of hiding information ...
;-)

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:45 +0200

Inline

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 8:17 AM
> To: 'Jeffrey Hutzelman'
> Cc: 'ISMS WG'
> > Hrm.  Why does it have to be the security model that saves state 
> > between request and response?
> 

Mmm... isn't it such that the security model save securityState that it 
needs later when it needs to process a response.?

The trabport model saves tmState that it needs when later
processing a response.

I do not see the wto conflict or cause trouble.
So I do not see why USM over SSH would be a [problem in this respect.

> The transport model doesn't know what the operation in the 
> incoming message is; it doesn't know if the message contains 
> a request or a response. This is because the message has not 
> yet been parsed by the MPM.
> 
Does it need to know?

> TFrom [email-masked] Thu Aug 23 05:27:53 2007
Content-class: urn:content-classes:message
Subject: RE: [Isms] Working Group Last Call - securityName
Date: Thu, 23 Aug 2007 11:25:45 +0200
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: "David Harrington" <[email-masked]>,
	"Jeffrey Hutzelman" <[email-masked]>
Cc: ISMS WG <[email-masked]>

Inline

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 8:17 AM
> To: 'Jeffrey Hutzelman'
> Cc: 'ISMS WG'
> > Hrm.  Why does it have to be the security model that saves state 
> > between request and response?
> 

Mmm... isn't it such that the security model save securityState that it 
needs later when it needs to process a response.?

The trabport model saves tmState that it needs when later
processing a response.

I do not see the wto conflict or cause trouble.
So I do not see why USM over SSH would be a [problem in this respect.

> The transport model doesn't know what the operation in the 
> incoming message is; it doesn't know if the message contains 
> a request or a response. This is because the message has not 
> yet been parsed by the MPM.
> 
Does it need to know?

> securityParmeters in the message are opaque to the MPM; those 
> are only unpacked by the security model. So the security 
> model has to be the one to ave security state.
> 

Right, and so for USM over SSH, the only thing it needs to know is
that the underlying security was indeed at least as high as the 
securityLevel (actually, it may not even need that, does it?).

> > 
> > I actually think it would be acceptable to say you can't 
> use the USM 
> > over SSH combination if the security parameters don't match.
> 
> What security parameters do you want to "match"? These are 
> different protocol parameters at different layers. Can you 
> say that SSH cannot be used over IPsec if the parameters 
> don't match? They are at different layers and use different 
> parameters.
> 
> The MPM selects which security model to use, but the MPM 
> doesn't know what the security parameters are. And once the 
> MPM has selected the USM, the USM has no way to determine the 
> security parameters related to a secure transport. We've done 
> a good job of hiding information ...
> ;-)
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
> 
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 23 Aug 2007 10:40:23 -0400 (EDT)

> one to ave security state.

Sure, but information about what session was used isn't security state;
it's transport state.

> What security parameters do you want to "match"?

I mean, the securityName and securityLevel derived from ssh must be the
same as those used by USM.  If that is true, then the procedure as
currently written will find the correct session for the response, if there
is one.  If not, it won't, because at least for ssh, you can't _have_ more
than one incoming session with the same transport address.

And by "can't use", I don't mean an explicit prohibition, just that it
won't work.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 24 Aug 2007 12:48:19 +0200

Catching up, inline

Tom Petch

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "tom.petch" <[email-masked]>; "David Harrington"
<[email-masked]>; "'ISMS WG'" <[email-masked]>
Cc: "Jeffrey Hutzelman" <[email-masked]>
Sent: Wednesday, August 22, 2007 11:50 PM
Subject: Re: [Isms] Working Group Last Call - securityName

> That's not vague at all; it means exactly what it says.

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.

So step 2 (referred to as step 3) translates an identity (and it will not
necessarity be authenticated, depends on the transport model) to a
<br>proposed</br> securityName.  Then step 5 must in addition translate the
proposed securityName into the securityName.

(The wording in 3.2.2 changed in -09, introducing this proposed wording,
something which I did not take it on board; it spelt out the provisional
nature of the work of the transport model and I think that that change needs
refelecting in other paragraphs).

And, as I have said on previous occasions, I would like distinct, defined terms
for these different object (classes).  I note that SSHTM defines tmsSecurityName
(which I think should be tmSecurityName) and I think this topic would be clearer
if tmsm used that term too.

Tom Petch

<snip>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 24 Aug 2007 09:32:27 -0400

inline 

> > >    2) translate parameters to model-independent 
[...]
> not say that so I think the wording in 3.2.1.2 should be 

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: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 24 Aug 2007 12:41:47 -0400 (EDT)

> proposed securityName into the securityName.

I think the intent is that a secure transport model will propose a
security name based on some authenticated identity, and any other
transport model will not propose one at all.  After all, the security
model has to decide whether to use that name without knowing the details
of the transport model, and it can only do that if it can assume that any
proposed name will come from some authenticated identity.

I also believe the intent is not so much that the security model will
"translate" the name as that it will either use it as-is or not at all. I
don't think it's intended that the SM would apply an arbitrary mapping.

-- Jeff