Subject: [Isms] securityName mapping was Re: draft updates

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Jun 2008 14:31:21 +0200

David

This is related to but I think distinct from issues 2 and 3.

When we discussed securityName last year, I understood that
- the Security Model always determines the securityName and not the Transport
Model.
- there are (consequently) two mappings involved, between identifier used by the
secure transport and proposed securityName from the Transport Model, and between
the proposed securityName from the Transport Model and the securityName selected
by Security Model.  Of course both mappings can be the identity mapping.

Is this intended to be what SSHTM describes?

Where does tmSecurityName fit into the three identifiers?

I ask because the usage seems not quite consistent.  If we agree on what should
be happening, then I will trawl the I-D again for wording which I think
inconsistent, but want to establish the principle first.

The simplest case is is a CR receiving a request, so let's focus on that first.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 27, 2008 3:16 AM
Subject: [Isms] draft updates

> Hi,
>
> I intend to publish an updated draft before the document cut-off for
> Dublin. If I can, I will publish it earlier than that.
>
> I just changed divisions in my company. I am heading off to China for
> a month starting June 10. The next two weeks I will be pretty busy
> preparing for China. I expect to have some, possibly limited, time in
> China to work on the ISMS drafts and other drafts I am editing, plus
> any chair work I need to do.
>
> I started looking at the drafts to see what should be updated relative
> to the ongoing discussion. Unfortunately, I am not finding a lot to
> update. The drafts represent what I believe has been, and remains WG
> consensus - that the format of the LCD is implementation-dependent,
> and processing related to the LCD and SSH remains
> implementation-dependent. Most of what we are talking about is some
> abstractions and possible details of implementation-dependent stuff. I
> think it has been valuable for understanding how the problem can be
> addressed by people developing implementation-dependent designs.
>
> I do think it would be really unfortunate to not have some of the
> current discussion summarized in the document, possible in an
> "implementor recommendations" section. But the discussion has
> meandered quite a bit, and has had a lot of RFC3411-incorrect
> explanations, so I'm not quite sure what to write at this time.
> Cleaned-up proposed text is welcome.
>
> It might be helpful to include an SSHTM-MIB as a sample LCD, but we've
> started this and removed it and started this again and removed it. We
> have not reached consensus what needs to be in the LCD. Even in the
> current discussion, we have not reached any consensus on what the
> "pointer into SSH config" must be able to represent.
>
> While the current discussion seems to be reaching consensus that
> storing client credentials is acceptable for establishing a connection
> for notifications, what those credentials look like are strictly
> implementation-dependent. The standardized part of notification config
> (target and params-mib config) is already described in the TSM
> document, and the secshell document says that the SSH and LCD details
> are implementation-dependent.
>
> As far as the documents are concerned, I don't understand the edits.
> We need to drive the discussion to be more specific about how the text
> in the documents should be changed.
>
> I am not sure whether reusing an existing connection makes sense any
> more. It has been WG consensus, but supporting both client credentials
> and reuse adds unnecessary complexity. especially given some of
> Pasis's comments. I am also not sure how all this works for informs
> between two manager applications or between two agents, or if that
> makes any difference.
>
> I think the WG needs to go through the documents closely, with RFC3411
> modularity in mind, to determine what new text is needed, what text
> needs to be changed, and whether the proposed approaches work in all
> instances.
>
> dbh
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:[email-masked]]
> > Sent: Monday, May 26, 2008 5:00 AM
> > To: David Harrington
> > Subject: Re: FYI: my priorities
>

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

---

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Jun 2008 14:35:40 +0200

David,

My third source of confusion, which I do not think falls within the existing
issues.

Is the securityName always derived, by one or two mappings, from the SSH client
user name, and never from a name used by the SSH Server?

I ask, because the current I-D clearly conveys to me the former, and the
discussions we have been having - well, you, Wes and Juergen have been having
while I have been digesting - seem to open the possibility that some server
identifier could be the basis.

Again, clarify the principle and I will go through the text again.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Jun 2008 14:37:01 +0200

David,

Re-reading SSHTM, I am uncertain about tmStateReference.  Is it in any way
dependent on a specific message, or is it solely about the session?  And does it
identify an instantion of a specific session?

What drives the question is session reuse, when a Response must use the same
session and, between Request and Response in a CR, the session has been taken
down and a fresh one has been set up with identical target index, as defined in
eg SSHTM s5.2.

It would seem to me that the tmStateReference MUST contain a unique session
identifier otherwise it is impossible to tell if it is the same session, but
that is not what SSHTM says.

And, less clearly, SSHTM seems to use tmStateReference as if it referred to any
session with a given target index rather than a single instantiation.

Can you clarify how you see session reuse working when eg

1) CG sends reqA, reqB, CR receives both, sends respA
2) session fails, is re-established, CG sends reqC
3) CR generates respB, respC; former must not be sent, latter can be.

It would seem that tmStateReference for respB must be distinct from
tmStateReference for respC.

Of course, we could rely on the pseudo-random generation of TCP source ports for
the tmTransportAddress to distinguish them but that would seem to me to be
insecure.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 5 Jun 2008 10:33:49 -0400

Hi Tom,

comments inline. 

> From: tom.petch [mailto:[email-masked]] 
> Sent: Thursday, June 05, 2008 8:31 AM
> To: David Harrington; [email-masked]
> Cc: [email-masked]
> Subject: securityName mapping was Re: [Isms] draft updates
> 
> David
> 

That is correct.

> - there are (consequently) two mappings involved, 

Yes.

> between 
> identifier used by the
> secure transport and proposed securityName from the Transport 
> Model, 

the "proposed securityName from the Transport Model" is the
tmSecurityname in the tmStateReference

> and between
> by Security Model.  

Yes. (and for different securitymodels, there may be mappings from
other things to securityName; for USM, the proposed securityName comes
from the securityParameters from the SNMPv3 message (IIRC); for
"community" security models, the proposed security name comes from the
community string.)

> Of course both mappings can be the 
> identity mapping.
> 

SSH TM should describe the SSH-to-tmSecurityName mapping.
TSM should describe the tmSecurityName-to-securityName mapping.

There is some ambiguity because we have not defined an LCD standard,
and have not provided a non-standard example LCD; the value of
tmSecurityName is also likely to be stored in the LCD, as part of the
index into the LCD, so the mappings to/from tmSecurityName might also
be done using the LCD.

> inconsistent, but want to establish the principle first.

I think the amount of confusion we have had in our discussions stems a
great deal from not having a sample LCD, and I think we should define
a sample LCD format (as a MIB module) so people can really see the
data and how it passed between models.

---

From: "tom.petch" <[email-masked]>
Date: Mon, 9 Jun 2008 12:02:53 +0200

Towards the end; some suggested amendments and a further issue.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 05, 2008 4:33 PM
Subject: RE: securityName mapping was Re: [Isms] draft updates

> TSM should describe the tmSecurityName-to-securityName mapping.

Good, we are on the same wavelength.  Consequently,

4.2  I would like an explicit statement here, about the roles of TM and SM, for
those whose memory of the tmsm I-D may be slipping:-).  Perhaps,

"When a connection is received, the SSH Transport Model places a proposed
'securityName' in the tmSecurityName field.  The final decision on what
securityName to use for a message is taken by the Security Model, based on all
the information it has available to it"

3.1.1 3)

      " SSH provides for both verification of the identity
       of the SSH server and verification of the identity of the SSH
       client - the principal on whose behalf a received SNMP
       message claims to have been generated."

I have puzzled over this but think that it is ok.  The identifier may change,
from transport to SSHTM to Security Model via mappings, but the underlying
identity remains the same so I think it correct to equate SSH identifier with
principal, as you do.  This crops up elsewhere, eg 3.1.2.

3.2.  Security Parameter Passing

  "For incoming messages, SSH-specific security parameters are
   translated by the transport model into security parameters
   independent of the transport and security models."

This doesn't seem right. SSHTM starts the process, but it is the Security Model
that has the last say on the securityName.  I think that it is only SSH
independent, not security model independent.

And The Big(?) Issue.

3.1.6

 "SSH sessions are uniquely identified within the SSH Transport
   Model  by the combination of transportAddressType,
   transportAddress,  securityName, and securityLevel
   associated with each session."

I am going round on circles on this.

At the application level, in a target MIB, sessions must be identifed by
securityName since tmSecurityName is unknown.  But here in the SSHTM, I think
that this is
tmSecurityName and not securityName.  If I assume it is securityName and not
tmSecurityName, then when a connection is received, SSHTM knows the
tmSecurityName but cannot know the securityName until the SecurityModel has
performed its processing. The cache would also need to contain the securityName
in order to perform the match for an outbound message, perhaps inserted by the
Security Model when it determines it.

And this gets more worrying since different messages over the same SSH
connection could be different SNMP versions and the Security Model then
determines a different securityName for different messages over the same
connection (which the SNMP v2c SM cannot insert into the cache since it does not
know about the cache).

And, since the mapping from tmSecurityName to SSH identifier is under the remit
of the SSH TM, I think that the SSH TM needs to hang on to the tmSecurityName in
unaltered form for it to be able to communicate with SSH for outbound messages,
ie the Transport Security Model cannot simply overwrite tmSecurityName with the
securityName it determines.

In 5.1, the references are to tmSecuirtyName, which I agree with, but in 5.2,
this issue arises again; I think that it needs to be tmSecurityName and not
securityName.

It is complicated, allowing these mappings between SSH identifier, proposed
securityName and securityName.  My thinking is that the SSHTM cannot reliably
know the securityName for an incoming session (nb not message) so
references to securityName in this I-D should only arise to help readers
understand that
the Security Model performs a second mapping to it.

Tom Petch