Subject: [Isms] TLSTM -05 More bits of MIB module

From: "tom.petch" <[email-masked]>
Date: Wed, 13 Jan 2010 12:41:16 +0100

I find the processing of server certificates by clients unclear when a
connection is being established as a result of the SNMP-TARGET-MIB module.

5.3 3 b talks of server identity being configured or not configured, the
DESCRIPTION clause talks of matching but does not say what is being matched.

If a row has fingerprint and no server identity, can this produce a match? The
DESCRIPTION clause says
"This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable
        with an expected (D)TLS server-side certificate identifier to .."
no mention of the server identity there implying that a match can take place on
the certificate identifier ie the fingerprint.

If not, then I think the text needs clarifying as to just what is being checked.

And, what if the table produces multiple matches?  *.server.example.com and
*.example.com or perhaps multiple SANs of different types.

As Joe has pointed out, there are differences for which the reasons are unclear
between the server's processing of a client certificate and the client's
processing of a server's certificate.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Jan 2010 06:58:08 -0800

>>>>> On Wed, 13 Jan 2010 12:41:16 +0100, "tom.petch" <[email-masked]> said:

tp> I find the processing of server certificates by clients unclear when a
tp> connection is being established as a result of the SNMP-TARGET-MIB
tp> module.

Given that these new comments are months beyond the last call, I'll wait
for the WG chairs to decide whether I should address them now or wait
until IETF last call to look at them.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Thu, 14 Jan 2010 17:52:13 +0100

Juergen

Thanks for the clarification on the process; my apologies for not being around
at the time of the Last Call - I was away from when it started until long after
it had finished - hence my lateness in reviewing and commenting.

My comments on -05 are mostly editorial suggestions, but in two places, I find
the I-D unclear and will be happy to suggest text once I am clear what the I-D
is intending.  Both relate to the checking performed by a client on a server
certificate when the TARGET-MIB module is used.

I am confused as to what the checking is.
"This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable
        with an expected (D)TLS server-side certificate identifier .."
Elsewhere certificates are located by a fingerprint so 'certificate
identifier' - not host, or entity or engine identifier - sounds a lot like a
fingerprint.  So does the client fingerprint the incoming certificate and look
for a match in the table (as well as looking for other matches such as in the
subjectAltName field)?  I see that as one reading of the text.  If it is a wrong
reading, then I think that the text needs clarifying; tell me and I will suggest
text.

Further on, I find no clarity about what is taken from
draft-saintandre-tls-server-id-check
and what is taken from the text here; which takes precedence, especially as
draft-saintandre-tls-server-id-check
forbids the use of * in the reference identity whereas
the DESCRIPTION of
tlstmAddrServerIdentity
explicitly allows it?

Finally, I am now reasonably confident that the tlstmAddrTable and the
tlstmParamsTable are only used when a session is being established as a result
of an entry in the TARGET-MIB module; this question confused me for a long time.
I think that that needs explicitly stating in the DESCRIPTION clauses of the two
tables and will also propose text for that.  One reading of the current text is
that you create entries in three tables (TARGET, tlstmAddr, tlstmParams) so that
certificates get checked even if the session setup does not itself use the
TARGET-MIB module.

These comments are not intended to be technical changes, just clarity on what it
meant.

Tom Petch

----- Original Message -----
From: "tom.petch" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "isms" <[email-masked]>
Sent: Wednesday, January 13, 2010 12:41 PM
Subject: [Isms] TLSTM -05 More bits of MIB module

> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 Jan 2010 09:39:56 -0800

>>>>> On Thu, 14 Jan 2010 17:52:13 +0100, "tom.petch" <[email-masked]> said:

tp> My comments on -05 are mostly editorial suggestions

Thanks for those changes; I'll make sure to get to them after the end of
the last-last-call today.

tp> I am confused as to what the checking is.  "This table extends the
tp> SNMP-TARGET-MIB's snmpTargetAddrTable with an expected (D)TLS
tp> server-side certificate identifier .."  Elsewhere certificates are
tp> located by a fingerprint so 'certificate identifier' - not host, or
tp> entity or engine identifier - sounds a lot like a fingerprint.

Good catch.  The "certificate identifier" wording actually came from an
earlier version of the certificate fingerprint TC where we weren't
necessarily assuming a cryptgraphic hash as a fingerprint.  Originally I
was trying to be generic so that any unique identifier could be used.
I'll be sure to change that text to say "fingerprint" again.

tp> So does the client fingerprint the incoming certificate and look for
tp> a match in the table

Yes.

tp> Further on, I find no clarity about what is taken from
tp> draft-saintandre-tls-server-id-check and what is taken from the text
tp> here; which takes precedence, especially as
tp> draft-saintandre-tls-server-id-check forbids the use of * in the
tp> reference identity whereas the DESCRIPTION of
tp> tlstmAddrServerIdentity explicitly allows it?

I think that is definitely a clash and I need to look into it.  In fact,
another person already pointed out that potential issue.  So you're not
alone in finding that the particular issue needs addressing.

tp> Finally, I am now reasonably confident that the tlstmAddrTable and
tp> the tlstmParamsTable are only used when a session is being
tp> established as a result of an entry in the TARGET-MIB module

Correct.  They're extensions to the TARGET-MIB so I don't know why
they'd be used otherwise.

tp> this question confused me for a long time.  I think that that needs
tp> explicitly stating in the DESCRIPTION clauses of the two tables and
tp> will also propose text for that.

Ok; as they're extensions I think can be derived but I'm all for stating
things clearly and explicitly.  Please do propose text ASAP.

Thanks for the questions and comments.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Wed, 20 Jan 2010 12:31:57 +0100

Wes

My suggested DESCRIPTION clauses based on my current understanding (which may
still be imperfect).

tlstmParamsTable

"This table is used by a (D)TLS client when a (D)TLS session is being set up
using an entry in the SNMP-TARGET-MIB.  It extends the SNMP-TARGET-MIB's
snmpTargetParamsTable with a fingerprint of a certificate to
use when establishing such a (D)TLS connection."

tlstmAddrTable

This table is used by a (D)TLS client when a (D)TLS session is being set up
using an entry in the SNMP-TARGET-MIB.  It extends the SNMP-TARGET-MIB's
snmpTargetAddrTable so that the client can validate the certificate
that the server presents.

If there is a row in this table corresponding to the entry in the
SNMP-TARGET-MIB that was used to
establish the session (and that row is active), then
the fingerprint of the server's certificate is compared with
the value of the tlstmAddrServerFingerprint column. If
fingerprint does not match, then the connection
MUST NOT be established.

If the row exists with a zero-length
tlstmAddrServerFingerprint value and the certificate can
be validated through another certificate validation path
(such as the path validation procedures defined in [RFC5280])
 then the server's presented identity should be
checked against the value of the tlstmAddrServerIdentity
column following the procedures specified in
draft-saintandre-tls-server-id-check.  If the server's identity does not match
the reference
identity found in the tlstmAddrServerIdentity column then the
connection MUST NOT be established.

A tlstmAddrServerIdentity
may contain a '*' to match any server's identity or may
contain a '*.' prefix to match any server identity from a
given domain (e.g. '*.example.com').  Note that this overrides
the provision specified in draft-saintandre-tls-server-id-check.

If there is no row in this table corresponding to an entry in the
SNMP-TARGET-MIB and another certificate validation path
algorithm (such as the path validation procedures defined in [RFC5280])
can be followed to a configured trust anchor, then the connection
SHOULD still proceed."

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>; "isms"
<[email-masked]>
Sent: Tuesday, January 19, 2010 6:39 PM
Subject: Re: TLSTM -05 More bits of MIB module

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Jan 2010 13:57:28 -0800

Tom,

Regarding your suggested text replacements for some of the tables I have
the following action summary for what I've done with your suggestions.

Markings reminders:

My responses are prefixed below with "WH:" if you want to search for
them.  The status of each item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you
  ANSWERED: A question was answered but had no action resulting from it

1 DONE tlstmParamsTable 
~~~~~~~~~~~~~~~~~~~~~~~~

             "This table is used by a (D)TLS client when a (D)TLS
             session is being set up using an entry in the
             SNMP-TARGET-MIB.  It extends the SNMP-TARGET-MIB's
             snmpTargetParamsTable with a fingerprint of a certificate
             to use when establishing such a (D)TLS connection."

2 DONE tlstmAddrTable 
~~~~~~~~~~~~~~~~~~~~~~

             This table is used by a (D)TLS client when a (D)TLS session
             is being set up using an entry in the SNMP-TARGET-MIB.  It
             extends the SNMP-TARGET-MIB's snmpTargetAddrTable so that
             the client can validate the certificate that the server
             presents.

             If the row exists with a zero-length
             tlstmAddrServerFingerprint value and the certificate can
             be validated through another certificate validation path
             (such as the path validation procedures defined in [RFC5280])
              then the server's presented identity should be
             checked against the value of the tlstmAddrServerIdentity
             column following the procedures specified in
             draft-saintandre-tls-server-id-check.  If the server's
             identity does not match the reference identity found in the
             tlstmAddrServerIdentity column then the connection MUST NOT
             be established.

             If there is no row in this table corresponding to an entry
             in the SNMP-TARGET-MIB and another certificate validation
             path algorithm (such as the path validation procedures
             defined in [RFC5280]) can be followed to a configured trust
             anchor, then the connection SHOULD still proceed."

             + WH: I used a slightly modified version of your text.
               Most specifically:
               + I didn't include a reference to the
                 draft-saintandre-tls-server-id-check document since
                 we're unsure of it's future progress and it's not the
                 only way that an identity could be checked.
               + I removed support completely for wildcards; I vaguely
                 recall this request coming from a discussion in
                 Stockholm but it is clearly not acceptable practice
                 and I'd rather remove it.  That paragraph now says:

                      A tlstmAddrServerIdentity may contain a single
                      ASCII '*' character (ASCII code 0x2a) to match
                      any server's identity if the
                      tlstmAddrServerFingerprint column is not blank.
                      A row MUST NOT contain both a blank
                      tlstmAddrServerFingerprint column and a '*' in
                      the tlstmAddrServerIdentity column since this
                      would insecurely accept any presented
                      certificate.

                 And the RowStatus column now also says:

                      Rows MUST NOT be active if the
                      tlstmAddrServerFingerprint column is blank and
                      the tlstmAddrServerIdentity is set to '*' since
                      this would insecurely accept any presented
                      certificate.