Subject: Re: [Isms] security name relevant text from the current SSH draft and needed changes

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 17:35:52 -0500

--On Monday, March 02, 2009 12:14:41 PM -0800 Wes Hardaker 
<[email-masked]> wrote:

> I think this logic should meet what everyone is expecting, based on
> previously agreed upon consensus.  If the above looks good logic wise,
> I'll even offer to check what text needs to be modified and submit a
> fast proposal for fixing it.  Note that the ID cut-off for a -15 is
> imminent.

Yes, I believe that correctly captures the way I have understood the 
protocol to work all along, and how I believe we have agreed it should work.

The one bit that confused me was that I thought the SNMPv3 message carried 
a security name, in which case it would be necessary to verify that that 
name matched the one provided by the transport layer.  But David assures me 
this is not the case, which means the problem goes away.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 02 Mar 2009 16:17:29 -0800

>>>>> On Mon, 02 Mar 2009 17:35:52 -0500, Jeffrey Hutzelman <[email-masked]> said:

JH> The one bit that confused me was that I thought the SNMPv3 message
JH> carried a security name, in which case it would be necessary to verify
JH> that that name matched the one provided by the transport layer.  But
JH> David assures me this is not the case, which means the problem goes
JH> away.

It does not carry a securityName.  The packet basically is broken down
as (I created a cheat-sheet years ago when SNMPv3 was first being
developed in order to understand it all):

  SNMPv3Message ::= SEQUENCE {
    msgVersion INTEGER { snmpv3 (3) },
    msgGlobalData HeaderData,
      msgID      INTEGER (0..2147483647),
      msgMaxSize INTEGER (484..2147483647),
      msgFlags   OCTET STRING (SIZE(1)),
      msgSecurityModel INTEGER (0..2147483647)
    msgSecurityParameters OCTET STRING,
      msgData  ScopedPduData
        ...

The msgSecurityModel valrue in the global headers is a field that all v3
messages contain.  The msgSecurityParameters is functionally an opaque
field that the SM gets to put whatever it wants into it.  For USM, the
user name and other parameters are put into it.  For TSM, we're putting
nothing (it becomes an empty octet string).  So no, there is user
information in snmpv3 packet itself unless the SM puts it in there.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 14:34:03 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 03, 2009 1:17 AM
Subject: Re: [Isms] security name relevant text from the current SSH draftand
needed changes

> information in snmpv3 packet itself unless the SM puts it in there.

And it really fascinates me, that after all this time, some think that the name
is there.  That sort of tells me it should be, life would be straightforward if
it was, and the way I see [email-masked]:port (and Windows has just told me
that this is an e-mail address which is why I keep saying e-mail format address
:-) is that is exactly what we are doing.  'user' is the name that we do not
have in the PDU so we are using a backdoor to get it from local to remote
engine.  It's a philosophical point but that is how I see it.

Ah well, we chose the difficult way of doing it and at this stage I want to make
that work, not go back and put 'user' into isms securityParameters.  No jokes,
this is me being serious.

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 11:49:41 -0500

--On Tuesday, March 03, 2009 02:34:03 PM +0100 "tom.petch" 
<[email-masked]> wrote:

> And it really fascinates me, that after all this time, some think that
> the name is there.

Well, of course the name isn't there if the SM gets to decide.  I'm not an 
SNMP expert, though, and for some reason I was under the impression this 
was present in part of the SNMPv3 message that is not under the SM's 
control.

> That sort of tells me it should be

No, the fact that I was under the impression that part of the SNMPv3 
message format was designed badly does not mean that it _should_ be 
designed badly.

> 'user' is the name that we do not have in the PDU so we are using
> a backdoor to get it from local to remote engine.

No.  In that example, 'user' is a name that is completely meaningless to 
SNMP, but is required by ssh, so we're using a backdoor to get it from the 
local engine to the local SSH client.

-- Jeff