Re: [Isms] ISMS/SSH and notifications

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Tue, 13 May 2008 16:32:18 +0200, "tom.petch" <cfinss at dial.pipex.com> said:

tp> The problem I see, which has been mulled over for some three years
tp> and Juergen articulated last month, is that access control in the NO
tp> checks that the NR is permitted to see the data in the notification
tp> based on the securityName.

Correct.  The VACM uses a securityName to make an access control
decision.  The security model is responsible for determining that the
other side isn't "faking it".  The security model (SM) is responsible
for mapping "something security-model specific" (paraphrasing the
architecture here) to a securityName that could be used "beyond that
point" (again, paraphrasing), like the application (NG, NO, CR, CG) for
example.  The "beyond that point" apps trust the SM to have given it an
appropriate securityName.

The question is, where does that name come from?  There are three
potential places:

  1) configuration
  2) somewhere in the packet
  3) somewhere in the security credentials

Where it comes from only is tied together cryptographically if it's in
the keying material (#3) is chosen (keep reading to get comments on #2)

tp> For that check to be of any value, then the name needs
tp> authenticating, which means that the NR should supply credentials
tp> for it.

Not necessarily true.  In a security model that didn't have a 1:1
mapping from something in the packet to the securityName then the
security model has to *derive* the securityName to use.  It does this
through a security model specific transformation (the SNMPv3
architecture very wisely allowed for this possibly and discusses it in
various places).

What, does a protocol which has no in-packet direct "note" saying "I'm
Bob" do?

The choices (marker: ***) are:

  1) throw up your hands and say "this protocol is useless".  I don't buy
     this option but apparently some are willing to just ditch SSH because
     there is no magical 1:1 mapping transformation.

  2) Use some other in-protocol field to "transform" into a security
     name.  This could be, for example, the SSH server name offered up
     by the SSH server side of the protocol.  This is one potential
     solution out of this space.  The securityName would be set to
     "wjh.hardakers.net", for example, if a client was trying to connect
     to my laptop.  The issue will come, however, that the legal length
     of a host name is longer than that of the legal securityName value
     that is used to look up a VACM entry.

  3) A configured mapping table.  Something in the packet or in the
     configuration that created the session could be used to look up, in
     a configured lookup table, what the securityName should be based on
     cryptographically proven (assuming at least authNoPriv) portions of
     the packet.  Like the server's SSH public key.

Only public key *certificates* (note the added word) actually containing
identifying information in the certificate itself that says "I'm Bob,
and not only that if I alter this certificate saying I'm now Eve it
won't work".  SSH doesn't operate this way; the application says "I'm
Bob and I'm using this key" but the key doesn't prove it.  The keys only
prove that the application has the private key.  It could still say
"Eve" and you can still only verify that eve has a private key you
recognize and potentially trust.  The USM doesn't provide any assurance
that the keying material it uses is attached to a particular name as
well.  Every user in the USM table could all be configured with the same
localized key so that Bob, Mary, Eve and Joe all could swap account
names and the far other side would do VACM checks on whatever name was
given to it in the packet regardless of the fact that they could have
picked from a few.  That wouldn't be allowed with an X.509 cert, for
example, but would be with both SSH and USM.

tp> So Wes is right to say that VACM is not responsible for checking it
tp> but I think wrong to say that it is ok to take whatever the
tp> application gives it.  The security model should stand between the
tp> two and check that the secure transport ends at something with that
tp> name and with verified security credentials (as USM does).

No, actually the USM doesn't do this.  A couple of problems exist in
this logic:

1) The security model hands the securityName back to the application and
   says "I got this message from this dude named 'Bob'".  The
   application already takes the value 'Bob' and can change it to
   whatever it wants before handing it to the VACM.  There is no
   security check in the architecture today that the application isn't
   discarding what it got from the SM and winging it.  The security
   model doesn't "stand between the two" like you suggest.

   (a historic aside: there was actually an alternate SNMPv3 architecture
   ID that attempted to allow the SM and the ACM blocks to communicate
   so that the ACM could verify wit the SM that the application wasn't
   lying to it, but it never got published.  I was even part of a team
   that did a reference implementation of it that really showed you have
   to have the SM and the ACM blocks be memory protected from the
   application for it to actually be an effective security mitigation
   and no SNMP stack these days really supports that separation).

2) The initiating application (NG or CG) is the one that actually tells
   the remote side who it is when USM is used.  More importantly, it
   really says "we're both Bob; I can prove I'm Bob and please prove you
   are too when you send a response".  The CR and NR merely use this
   fact to look up the proper keying material to use to ensure that they
   can be Bob.

tp> And as has been pointed out several times, when the NO originates
tp> the session, and the NO is the ssh client, then that credential is a
tp> public key.

The *client* credential is a public key.  As is the servers.

tp> So that is what the NO should be checking and what VACM should have
tp> in its tables:-)

Right, that's actually what I said.  You could use the server's key to
do a lookup in a table to ensure you're talking to Bob.  If they say I
have key 0xABCD and you have "Bob" next to 0xABCD in your keying table,
then you can be completely sure it's "Bob" at the other end.

The only two forward paths that exist are #2 and #3 from *** above.  I'm
honestly happy with either, though #2 (using the SSH server host name as
the securityName) would limit the hostnames I can use but, and this is
my important point, it doesn't provide me with any extra security over
#3 (using a mapping table so the key would be used to lookup the value
of the securityName to use).  A lookup would be done in the process of
sending a trap.  The configuration would specify the remote securityName
and the public key of the remote server to verify it's the right
securityName on the other side.

Cryptographically speaking, you still don't have any assurance that the
application hasn't messed with the data before the VACM uses it nor do
you have any assurance that the public key in use wasn't intended to be
used by a completely different name.  You still can be completely
assured that whoever is listening on the other side, be it Bob or Eve,
could convenience you that they're both Bob and Eve or whatever name you
want them to be.  They have the private key to prove it and that's all
you can care about.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms