Subject: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Dec 2009 17:19:14 -0800

I've been plugging away at resolving the outstanding comments received
during the last call round and most of them don't require a heavy amount
of discussion and review.  But a few I wanted to run by the WG in
advance before publication to see if they meet the expectations based on
those who participated in the WG discussions.

The first issue presented at the WG meeting was surrounding the need to
map otherName data in a securityName.  The solution agreed to during the
WG meeting was to use OBJECT-IDENTITY clauses for defining matching so
that the system is extensible in the future when someone wishes to
define an otherName mapping, for example.  (But we wouldn't define an
otherName mapping at all at this point).

The results of implementing this are as follows:

1) The new table looks like this:

    TlstmCertToSNEntry ::= SEQUENCE {
        tlstmCertToSNID           Unsigned32,
        tlstmCertToSNFingerprint  Fingerprint,
        tlstmCertToSNType         INTEGER (specific(1), mapped(2)),
        tlstmCertToSNSecurityName SnmpAdminString,
        tlstmCertToSNMapType      AutonomousType,
        tlstmCertToSNStorageType  StorageType,
        tlstmCertToSNRowStatus    RowStatus
    }

  And the tlstmCertToSNMapType is used to refer to external identities, of
  which the draft defines these five:

    tlstmCertSANRFC822Name
    tlstmCertSANDNSName
    tlstmCertSANIpAddress
    tlstmCertSANAny
    tlstmCertCommonName

The full patch is attached below as is the full MIB so you can read
all the nitty-gritty details.

However, there is another potential solution that I wanted to see if
anyone had opinions on:

Specifically, the "specific" mapping (which directly says "use the
securityName found in the tlstmCertToSNSecurityName column) could also be
turned into an identity, though an extension field is still needed.

2) Thus the second alternative is to do this instead:

    TlstmCertToSNEntry ::= SEQUENCE {
        tlstmCertToSNID           Unsigned32,
        tlstmCertToSNFingerprint  Fingerprint,
*       tlstmCertToSNMapType      AutonomousType,
*       tlstmCertToSNMapData      OCTET STRING,
        tlstmCertToSNStorageType  StorageType,
        tlstmCertToSNRowStatus    RowStatus
    }

The *'d fields would then be used to do *any* type of mapping, and the
'specified' enum would then be converted to a OBJECT-IDENTITY which
would say to directly use the data found in the now generic
tlstmCertToSNMapData column.  The advantage of this would be that any
other future extensions could have a spare column of data to help
configure the OBJECT-IDENTITY's behavior.  The downside is that making
it generic makes it "less straightforward".

So, my question to the WG is: should I:

1) use the approach defined in #1 above and the patch/mib below?
2) use the approach described in #2 to make it "really generic"?

-- 
Wes Hardaker
Cobham Analytic Solutions
diff --git a/draft/draft-ietf-isms-dtls-tm.xml b/draft/draft-ietf-isms-dtls-tm.xml
index 520040d..6f30ebc 100644
--- a/draft/draft-ietf-isms-dtls-tm.xml
+++ b/draft/draft-ietf-isms-dtls-tm.xml
@@ -1539,7 +1539,8 @@ IMPORTS
     OBJECT-IDENTITY, snmpModules, snmpDomains,
     Counter32, Unsigned32, NOTIFICATION-TYPE
       FROM SNMPv2-SMI
-    TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType
+    TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType,
+    AutonomousType
       FROM SNMPv2-TC
     MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
       FROM SNMPv2-CONF
@@ -1637,8 +1638,9 @@ tlstmMIB MODULE-IDENTITY
 -- ************************************************
 
 tlstmNotifications OBJECT IDENTIFIER ::= { tlstmMIB 0 }
-tlstmObjects       OBJECT IDENTIFIER ::= { tlstmMIB 1 }
-tlstmConformance   OBJECT IDENTIFIER ::= { tlstmMIB 2 }
+tlstmIdentities    OBJECT IDENTIFIER ::= { tlstmMIB 1 }
+tlstmObjects       OBJECT IDENTIFIER ::= { tlstmMIB 2 }
+tlstmConformance   OBJECT IDENTIFIER ::= { tlstmMIB 3 }
 
 -- ************************************************
 -- tlstmObjects - Objects
@@ -1907,6 +1909,78 @@ Fingerprint ::= TEXTUAL-CONVENTION
       "
     SYNTAX       OCTET STRING (SIZE (1..255))
 
+-- Identities
+
+tlstmCertToSNMIdentities    OBJECT IDENTIFIER ::= { tlstmIdentities 1 }
+
+tlstmCertSANRFC822Name OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "Maps a subjectAltName's rfc822Name to a SNMPv3
+                  securityName.  The local part of the rfc822Name is
+                  passed unaltered but the host-part of the name must
+                  be passed in lower case.
+
+                  Example rfc822Name Field:  [email-masked]
+                  is mapped to securityName: [email-masked]"
+    ::= { tlstmCertToSNMIdentities 1 }
+
+tlstmCertSANDNSName OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "Maps a subjectAltName's dNSName to a SNMPv3
+                  securityName by directly passing the value without
+                  any transformations."
+    ::= { tlstmCertToSNMIdentities 2 }
+
+tlstmCertSANIpAddress OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "Maps a subjectAltName's ipAddress to a SNMPv3
+                  securityName by transforming the binary encoded
+                  address as follows:
+
+
+                  1) for IPv4 the value is converted into a decimal
+                     dotted quad address (e.g. '192.0.2.1')
+
+                  2) for IPv6 addresses the value is converted into a
+                     32-character hexadecimal string without any colon
+                     separators.
+
+                     Note that the resulting length is the maximum
+                     length supported by the View-Based Access Control
+                     Model (VACM).  Note that using both the Transport
+                     Security Model's support for transport prefixes
+                     (see the SNMP-TSM-MIB's
+                     snmpTsmConfigurationUsePrefix object for details)
+                     will result in securityName lengths that exceed
+                     what VACM can handle."
+    ::= { tlstmCertToSNMIdentities 3 }
+
+tlstmCertSANAny OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "Maps any of the following fields using the
+                  corresponding mapping algorithms:
+
+                  |------------+------------------------|
+                  | Type       | Algorithm              |
+                  |------------+------------------------|
+                  | rfc822Name | tlstmCertSANRFC822Name |
+                  | dNSName    | tlstmCertSANDNSName    |
+                  | ipAddress  | tlstmCertSANIpAddress  |
+                  |------------+------------------------|
+
+                  The first matching subjectAltName value found in the
+                  certificate any of the above types MUST be used when
+                  deriving the securityName."
+    ::= { tlstmCertToSNMIdentities 4 }
+
+tlstmCertCommonName OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "Maps a certificate's CommonName to a SNMPv3
+                  securityName by directly passing the value without
+                  any transformations."
+    ::= { tlstmCertToSNMIdentities 5 }
+
+
 -- The tlstmSession Group
 
 tlstmSession           OBJECT IDENTIFIER ::= { tlstmObjects 1 }
@@ -2098,9 +2172,9 @@ tlstmCertToSNEntry OBJECT-TYPE
 TlstmCertToSNEntry ::= SEQUENCE {
     tlstmCertToSNID           Unsigned32,
     tlstmCertToSNFingerprint  Fingerprint,
-    tlstmCertToSNMapType      INTEGER,
+    tlstmCertToSNType         INTEGER,
     tlstmCertToSNSecurityName SnmpAdminString,
-    tlstmCertToSNSANType      INTEGER,
+    tlstmCertToSNMapType      AutonomousType,
     tlstmCertToSNStorageType  StorageType,
     tlstmCertToSNRowStatus    RowStatus
 }
@@ -2124,8 +2198,8 @@ tlstmCertToSNFingerprint OBJECT-TYPE
         is dictated by the tlstmCertToSNMapType column."
     ::= { tlstmCertToSNEntry 2 }
 
-tlstmCertToSNMapType OBJECT-TYPE
-    SYNTAX      INTEGER { specified(1), bySubjectAltName(2), byCN(3) }
+tlstmCertToSNType OBJECT-TYPE
+    SYNTAX      INTEGER { specified(1), mapped(2) }
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
@@ -2140,41 +2214,27 @@ tlstmCertToSNMapType OBJECT-TYPE
                       column's value is ignored for all other
                       tlstmCertToSNMapType values.
 
-        bySubjectAltName(2):
-                      The securityName that should be used to
+        mapped(2):    The securityName that should be used to
                       associate with the session should be taken from
-                      the subjectAltName(s) portion of the client's
-                      X.509 certificate.  The subjectAltName used MUST
-                      be the first encountered subjectAltName type
-                      indicated by the tlstmCertToSNSANType column.
-
-                      If the resulting mapped value from the
-                      subjectAltName component is not compatible with
-                      the needed requirements of a securityName (e.g.,
+                      client's X.509 certificate.  The exact mechanism
+                      used to derive the securityName from the
+                      certificate is indicated by the
+                      tlstmCertToSNMapType column.
+
+                      If the resulting mapped value from the necessary
+                      certificate component is not compatible with the
+                      needed requirements of a securityName (e.g.,
                       VACM imposes a 32-octet-maximum length and the
                       certificate derived securityName could be
-                      longer) then the next appropriate subjectAltName
-                      of the correct type should be used if available.
+                      longer) then the next appropriate value should
+                      be used if one is available (e.g. it is possible
+                      for a certificate to include multiple
+                      subjectAltName values of the same type).
 
-                      If no appropriate subjectAltName of the given
-                      type is found within the certificate then
-                      additional rows in the tlstmCertToSNTable must
-                      be searched for additional
-                      tlstmCertToSNFingerprint matches.
-
-        byCN(3):      The securityName that should be used to
-                      associate with the session should be taken from
-                      the CommonName portion of the Subject field from
-                      the client's presented X.509 certificate.
-
-                      If the value of the CommonName component is not
-                      compatible with the needed requirements of a
-                      securityName (e.g., VACM imposes a
-                      32-octet-maximum length and the certificate
-                      derived securityName could be longer) then
-                      additional rows in the tlstmCertToSNTable must
-                      be searched for additional
-                      tlstmCertToSNFingerprint matches."
+                      If no appropriate value for the given type is
+                      found within the certificate then additional
+                      rows in the tlstmCertToSNTable must be searched
+                      for additional tlstmCertToSNFingerprint matches."
 
     DEFVAL { specified }
     ::= { tlstmCertToSNEntry 3 }
@@ -2195,48 +2255,16 @@ tlstmCertToSNSecurityName OBJECT-TYPE
     DEFVAL { "" }
     ::= { tlstmCertToSNEntry 4 }
 
-tlstmCertToSNSANType OBJECT-TYPE
-    SYNTAX      INTEGER { any(1), rfc822Name(2), dNSName(3),
-                          ipAddress(4), otherName(5) }
+tlstmCertToSNMapType OBJECT-TYPE
+    SYNTAX      AutonomousType
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "Specifies the subjectAltName type that may be used to extract
-        the securityName from.
-
-        The any(1) value indicates the (D)TLS server should use the
-        first value found for any of the following subjectAltName
-        value types for the securityName: rfc822Name, dNSName, and
-        ipAddress.
-
-        When multiple types for a given subjectAltName type are
-        encountered within a certificate the first legally usable
-        value is the one selected.
-
-        Values for type ipAddress(4) are converted to a valid
-        securityName by:
-
-            1) for IPv4 the value is converted into a decimal dotted
-               quad address (e.g. '192.0.2.1')
-
-            2) for IPv6 addresses the value is converted into a
-               32-character hexadecimal string without any colon
-               separators.
-
-               Note that the resulting length is the maximum length
-               supported by the View-Based Access Control Model
-               (VACM).  Note that using both the Transport Security
-               Model's support for transport prefixes (see the
-               SNMP-TSM-MIB::snmpTsmConfigurationUsePrefix object for
-               details) will result in securityName lengths that
-               exceed what VACM can handle.
-
-        Values for type otherName(5) are converted to a valid
-        securityName by using only the decoded value portion of the
-        OtherName sequence.  I.E. the OBJECT IDENTIFIER portion of the
-        OtherName sequence is not included as part of the resulting
-        securityName."
-    DEFVAL      { any }
+        the securityName from.  Details for mapping of a particular
+        type SHALL be specified in the DESCRIPTION clause of the
+        OBJECT-IDENTITY that describes the mapping."
+    DEFVAL      { tlstmCertSANAny }
     ::= { tlstmCertToSNEntry 5 }
 
 tlstmCertToSNStorageType OBJECT-TYPE
@@ -2267,16 +2295,16 @@ tlstmCertToSNRowStatus OBJECT-TYPE
         tlstmParamsRowStatus column is 'notReady'.
 
         In particular, a newly created row cannot be made active until
-        the corresponding tlstmCertToSNFingerprint,
-        tlstmCertToSNMapType, tlstmCertToSNSecurityName, and
-        tlstmCertToSNSANType columns have been set.
+        the corresponding tlstmCertToSNFingerprint, tlstmCertToSNType,
+        tlstmCertToSNSecurityName, and tlstmCertToSNMapType columns
+        have been set.
 
         The following objects may not be modified while the
         value of this object is active(1):
             - tlstmCertToSNFingerprint
-            - tlstmCertToSNMapType
+            - tlstmCertToSNType
             - tlstmCertToSNSecurityName
-            - tlstmCertToSNSANType
+            - tlstmCertToSNMapType
         An attempt to set these objects while the value of
         tlstmParamsRowStatus is active(1) will result in
         an inconsistentValue error."
@@ -2525,10 +2553,14 @@ tlstmAddrRowStatus OBJECT-TYPE
 -- ************************************************
 
 tlstmServerCertNotFound NOTIFICATION-TYPE
+    OBJECTS { tlstmSessionInvalidServerCertificates }
     STATUS  current
     DESCRIPTION
         "Notification that the server certificate presented by a SNMP
-         over (D)TLS server could not be found in the tlstmAddrTable."
+         over (D)TLS server was invalid.  Reasons for
+         invalidation includes, but is not limited to, cryptographic
+         validation failures and an unexpected presented certificate
+         identity."
     ::= { tlstmNotifications 1 }
 
 tlstmServerAuthFailure NOTIFICATION-TYPE
@@ -2591,9 +2623,9 @@ tlstmIncomingGroup OBJECT-GROUP
         tlstmCertToSNCount,
         tlstmCertToSNTableLastChanged,
         tlstmCertToSNFingerprint,
-        tlstmCertToSNMapType,
+        tlstmCertToSNType,
         tlstmCertToSNSecurityName,
-        tlstmCertToSNSANType,
+        tlstmCertToSNMapType,
         tlstmCertToSNStorageType,
         tlstmCertToSNRowStatus
     }

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Dec 2009 08:11:53 +0100

> it generic makes it "less straightforward".

Is this not sufficient?

Do we have a concrete example where an OCTET STRING value is needed as
input to the mapping for a cert field? We usually do not provide OCTET
STRING blobs in MIB modules just because they might be useful at some
time in the future. So I like the idea to do away with tlstmCertToSNType
but I am not convinced yet an opaque tlstmCertToSNMapData is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Thu, 3 Dec 2009 11:54:06 -0500

Wes,

WH> So, my question to the WG is: should I:

WH> 1) use the approach defined in #1 above and the patch/mib below?
WH> 2) use the approach described in #2 to make it "really generic"?

I am leaning toward approach #2 for the reason that depending on what
value is specified in tlstmCertToSNType, one other column in that table
is always invalidated.  To address this, we can have the table be
indexed by <tlstmCertToSNID.tlstmCertToSNType>, but having a double
index can complicate the prioritized search.  Using approach #2
eliminates these small complexities caused by tlstmCertToSNType.

- Andy Donati 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wes Hardaker
Sent: Wednesday, December 02, 2009 8:19 PM
To: [email-masked]
Subject: [Isms] TLSTM Issue #1: proposed text for otherName
mappingresolution

  And the tlstmCertToSNMapType is used to refer to external identities,
of
  which the draft defines these five:

    tlstmCertSANRFC822Name
    tlstmCertSANDNSName
    tlstmCertSANIpAddress
    tlstmCertSANAny
    tlstmCertCommonName

The full patch is attached below as is the full MIB so you can read all
the nitty-gritty details.

Specifically, the "specific" mapping (which directly says "use the
securityName found in the tlstmCertToSNSecurityName column) could also
be turned into an identity, though an extension field is still needed.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Dec 2009 09:00:28 -0800

>>>>> On Thu, 3 Dec 2009 08:11:53 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Is this not sufficient?

JS> TlstmCertToSNEntry ::= SEQUENCE {
JS> tlstmCertToSNID           Unsigned32,
JS> tlstmCertToSNFingerprint  Fingerprint,
JS> tlstmCertToSNMapType      AutonomousType,
JS> tlstmCertToSNSecurityName SnmpAdminString,
JS> tlstmCertToSNStorageType  StorageType,
JS> tlstmCertToSNRowStatus    RowStatus
JS> }

That is sufficient for handling the directly specified securityName,
yes, as all that is needed is a SnmpAdminString.  The above, though,
limits the extra field for use only using the directly specified
securityName.  My real question was: can we envision other cases where
other MapTypes may want a configuration field.  EG, you could imagine (I
suppose) a kerberos otherName field that would want a configuration
option saying "but only those kerberos principals in the realm
[email-masked]'".

JS> Do we have a concrete example where an OCTET STRING value is needed as
JS> input to the mapping for a cert field?

Only hypothetical ones like the above.

JS> So I like the idea to do away with tlstmCertToSNType but I am not
JS> convinced yet an opaque tlstmCertToSNMapData is needed.

Thanks for the input.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Dec 2009 18:57:45 +0100

> option saying "but only those kerberos principals in the realm

Let me see whether I understand things correctly. As long as I ignore
fingerprints matching trusted CA certificates, I have one row per
client certificate. If this is correct, it does not reall matter
whether I provision information to a magic mapping function or simply
write down the securityName. If I am correct, that the only
interesting situation is when the fingerprint refers to trusted CA
certificates since then I might accept a number of N certificates.
What you are saying that for this case we should provision an opaque
OCTET STRING that can be used for filtering purposes in case we ever
define cert type specific mappings. The alternative would be to simply
augment that table with cert type specific filters once we define
mappings that need filters.

For me, this all still sounds a bit hypothetic - but then I am not
working in an environment where certificates are heavily used. It
would help if those who are intensively work in such environments can
comment on this.

/js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 03 Dec 2009 15:21:47 -0500

--On Thursday, December 03, 2009 06:57:45 PM +0100 Juergen Schoenwaelder 
<[email-masked]> wrote:

> client certificate.

That's my understanding as well.

> mappings that need filters.

It's not the same.  "We" aren't necessarily defining new mappings; anyone 
can do so.  After all, they're named by OID's.  Wes provided a hypothetical 
but realistic example; I might want to turn a KRB5PrincipalName SAN into an 
ASN.1 security name; that would require at least specifying what realm I'm 
interested in, and possibly other things.

Actually, that same argument can be made for RFC822 names, where one might 
want to handle only names with a particular domain-part.

Unfortunately, algorithmic mapping of data in client certificates to useful 
application-specific identifiers does not seem to be an area that has been 
explored very widely.  Of course, it's easy for every site to say "we're 
doing it this way", but that doesn't really help with standardization.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Dec 2009 12:41:31 -0800

>>>>> On Thu, 3 Dec 2009 18:57:45 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> }
>> option saying "but only those kerberos principals in the realm

JS> Let me see whether I understand things correctly. As long as I ignore
JS> fingerprints matching trusted CA certificates, I have one row per
JS> client certificate. If this is correct, it does not reall matter
JS> whether I provision information to a magic mapping function or simply
JS> write down the securityName. If I am correct, that the only
JS> interesting situation is when the fingerprint refers to trusted CA
JS> certificates since then I might accept a number of N certificates.
JS> What you are saying that for this case we should provision an opaque
JS> OCTET STRING that can be used for filtering purposes in case we ever
JS> define cert type specific mappings. The alternative would be to simply
JS> augment that table with cert type specific filters once we define
JS> mappings that need filters.

You're correct.  I think.

The interesting cases are (I'm using DATA here as the column for the
yet-to-be-decided column; IE, it'll either be a generic OCTET STRING or
will be the securityName SnmpAdminString like you're wishing for):

1) fingerprint directly matches a presented server certificate and we
   want to directly map it to a securityName:
   tlstmCertToSNFingerprint = the server's fingerprint
   tlstmCertToSNMapType     = OID for 'specified'
   tlstmCertToDATA          = 'wes'

2) fingerprint matches a CA certificate used to verify the presented
   server certificate and we want to pull data from the subjectAltName:
   tlstmCertToSNFingerprint = the CA fingerprint
   tlstmCertToSNMapType     = OID for 'specified'
   tlstmCertToDATA          = ''  (empty and not used and any value ignored)

3) fingerprint matches a CA certificate used to verify the presented
   server certificate and we want to pull data from an
   as-yet-undocumented identifier like a kerberos otherName principal.
   It may be defined such that "if tlstmCertToDATA contains a non-zero
   length string then it should be used as a must-match against the
   kerberos realm name"

   tlstmCertToSNFingerprint = the CA fingerprint
   tlstmCertToSNMapType     = OID for 'specified'
   tlstmCertToDATA          = 'example.com'

   So only kerberos principals ending in @example.com would be accepted
   as valid securityNames to use.

I don't know if we want to support #3 or not, which was most of my
questioning.  Jeff indicated he'd like this extensibility.  Donati
seemed to indicate he favored it as well.
-- 
Wes Hardaker
Cobham Analytic Solutions