Re: [Isms] (D)TLS question (#1): selecting a client certificate to use

["Donati Andrew-MGIA0477" <adonati at motorola.com>]

Wes,

Option A sounds like a good solution.  Here are a few observations on
option A.  

-- Since RowStatus and StorageType are already present the
snmpTargetParams table, it may be conflicting to have these columns
duplicated in the augmenting tlstmParams table.  

-- If tlstmParamsRowStatus is not used, the modification rules based on
the setting of snmpTargetParamsRowStatus for tlstmParams objects may
need to be clarified in their respective description clauses.  Note that
the tlstmParamsRowStatus description states that "The value of this
object has no effect on whether other objects in this conceptual row can
be modified" and the values for objects in the snmpTargetParams table
cannot be set if the RowStatus is active.

-- The tlstmParamsHashValue object may need to have a default value
defined.    

Andy Donati
Motorola HN&M

-----Original Message-----
From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On Behalf Of
Wes Hardaker
Sent: Tuesday, June 30, 2009 7:21 PM
To: isms at ietf.org
Subject: [Isms] (D)TLS question (#1): selecting a client certificate to
use


Background:

I have a few questions about supporting (D)TLS that I'd like to solicit
feedback for on the list.  I was going to describe them at the IETF too,
but I figure starting on the list is probably better as it'll help the
discussion process move along more rapidly.



So question #1 deals with selecting a client-side certificate for
outgoing connections (eg, for notifications originated by a notification
generator).

Right now client side configuration exists in the SNMP-TARGET-MIB for
configuring which remote server to connect to:

   snmpTargetAddrTable:   details about the address to connect to
                          (address, port, timeout, retry, ...)
                          (this table also points to the
snmpTargetParamsTable)

   snmpTargetParamsTable: details about SNMP protocol usage
                          (security model, security name, security
level, ...)

To open a (D)TLS connection, however, we need to know which X.509
certificate to present to the server in order to authenticate us and
(help) secure the connection.  For SSH we assumed infrastructure was in
place to do client identification certificate selection.  For (D)TLS
there isn't really a deployed base that has a pre-assigned and
pseudo-standardized user-name to certificate mapping database on each
system (IE, there is no ~/.ssh/identity.pub file).


To solve this problem, the current (D)TLS draft has the following
SNMP-TARGET-MIB augmentation table in it (this is obviously abbreviated;
please look at the draft for the full MIB definition):

  tlstmParamsEntry OBJECT-TYPE
    SYNTAX      TlstmParamsEntry
    AUGMENTS    { snmpTargetParamsEntry }

  TlstmParamsEntry ::= SEQUENCE {
      tlstmParamsHashType        X509IdentifierHashType,
      tlstmParamsHashValue       X509IdentifierHash,
      tlstmParamsStorageType     StorageType,
      tlstmParamsRowStatus       RowStatus
  }

Where X509IdentifierHashType is just a enum of common (current) hashing
algorithms (which will probably discussion of which to include and
eventually require IANA maintenance).  X509IdentifierHash is just a hash
of a given certificate to use.  IE, the hash is really just a look-up
key into an implementation dependent certificate store.  [FYI, I asked a
number of PKIX folks about the best way to remotely refer to
certificates, and they all agreed that a hash lookup is the best way to
do it].

I don't think defining a certificate store (and associated upload
mechanism!) is within scope of the WG and even if we wanted to do it.
(It would fall into the scope of the PKIX WG not ISMS).  But we do need
a method to perform a lookup given an outgoing connection, which is all
this table is trying to do.

What do people think of this solution as defined above?

The other potential solution I think is possible is a securityName to
certificate mapping table rather than augmenting the
snmpTargetParamsTable.  The USM MIB's user table is an example of how
credentials are looked up based on snmpTargetParamsTable data.  But, one
aspect of using a securityName to certificate mapping table that needs
to be dealt with is how to handle the situation where two different
connections require two different certificates but the same
securityName.  This is handled within USM by the securityEngineID being
part of the index to the USM User table, but we don't have a
securityEngineID available in the ISMS transport solutions.


If you like multiple choice style questions, the options are:

  A) Use the AUGMENTS mechanism as summarized above and defined in the
     current draft
  B) Create a securityName to certificate mapping table and solve the
     single securityName to multiple certificate issue discussed above
  C) Don't provide any sort of mapping and assume it's
implementation-dependent 

Obviously, because I wrote the draft that way, I think A) is more
straight forward.  My second choice is B), but I don't like the problem
with multiple securityName/certificate combinations.
I don't like the idea of C) at all.

--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms