[Isms] (D)TLS question #2: expecting a server side certificate

[Wes Hardaker <wjhns1 at hardakers.net>]

As just discussed, when a client (typically using the SNMP-TARGET-MIB)
is opening an outgoing connection it needs to select a client-side
certificate to use when making the connection.

But, it also has to have an expectation of which remote machine it's
connecting to as well.  It shouldn't just connect to any old system that
answers it's call.  It needs to know that the remote system is, in fact,
the responder it was hoping to reach.

This can be done a number of ways:

1) Add additional rows to the snmpTargetAddrTable that specifies a
   hash-type/hash-value column pair to refer to a locally held copy of
   the remote certificate that should be presented.  IE, this requires an
   additional row in an additional table per target.

2) Use one of the more standardized mapping techniques for assuring
   target certificates are ok based on a trust-anchor CA certificate and
   accepted mappings of either the CommonName field (which is commonly
   what web-browsers use, for example) or the subjectAltName field,
   which is what is currently being recommended within the IETF and the
   CN field is actually being deprecated.  See the following draft for
   the current thoughts and details on TLS server side identity checks:

      draft-saintandre-tls-server-id-check-00.txt

   We'd then need to specify the allowable bindings.  In particular,
   we already have the remote entity specified by the
   snmpTargetAddrTAddress variable which pretty much dictates the type
   of lookup that needs to happen in the subjectAltName list.

   The nice advantage of this approach is that it's the one used in
   industry today for other TLS connection types and requires no
   configuration (assuming we're going to stay out of CA-trust-anchor
   configuration because it's out of scope of the charter).

3) A combination of #1 and #2 allowing for both 1:1 X.509 hash
   references to an expected certificate and allowing for 1:1 mapping
   for those folks that don't have control over the certificate
   generation process or have such small installations that they don't
   want to set up anything other than self-signed certificates.


Personally, I'm leaning toward just #2.

Note that the current draft doesn't discuss this much and only hints at
it.  I intend to write up text for #2 unless the WG participants feel
I'm taking the wrong direction in this approach.

-- 
Wes Hardaker
Cobham Analytic Solutions