Re: [Isms] ISMS/SSH and notifications

["tom.petch" <cfinss at dial.pipex.com>]

<inline>
Tom Petch

----- Original Message -----
From: "Wes Hardaker" <wjhns1 at hardakers.net>
To: "tom.petch" <cfinss at dial.pipex.com>
Cc: <Pasi.Eronen at nokia.com>; <wjhns1 at hardakers.net>; <isms at ietf.org>
Sent: Tuesday, May 13, 2008 11:11 PM
Subject: Re: [Isms] ISMS/SSH and notifications


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

Yes, I agree. I am left wondering, more with the second point than the first,
if this is good enough security and thinking that perhaps it is not.  I see this
as the crux of the issue.

In passing, SSH (unlike TLS) does have a ready made session identifier that is
cryptographically bound to the session so if we do take data from the session
setup for use in the ways you describe, then that is what I think we should use
(see draft-williams-sshv2-channel-bindings-00.txt)

Tom Petch

>                                                            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