Subject: [Isms] Question on TlstmAddrEntry and TlstmCertToTSNEntry

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 8 Jan 2010 15:46:03 -0800

The text in these MIB modules seems to indicate that the
tlstmAddrServerFingerprint object can only be used to match a specific
certificate. 

On the other hand it seems the tlstmCertToTSNFingerprint object can be
used to match either a specific end-entity certificate or a CA
certificate. 

Why are these two cases treated differently?  Why not allow the
tlstmAddrServerFingerprint to reference a CA and use the
tlstmAddrServerIdentity for identity?  If the tlstmAddrServerFingerprint
is present is tlstmAddrServerIdentity ignored? 

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jan 2010 17:15:08 -0800

>>>>> On Fri, 8 Jan 2010 15:46:03 -0800, "Joseph Salowey (jsalowey)" <[email-masked]> said:

JS> The text in these MIB modules seems to indicate that the
JS> tlstmAddrServerFingerprint object can only be used to match a specific
JS> certificate. 

JS> On the other hand it seems the tlstmCertToTSNFingerprint object can be
JS> used to match either a specific end-entity certificate or a CA
JS> certificate.

JS> Why are these two cases treated differently?

They're different cases, admittedly similar.  The real result is that
for the mapping to a securityName it really needed to be done to make
the resulting SNMPv3/TLS protocol even usable (IE, if we don't have a
securityName in the end of the mapping we're sunk).

The WG in Stockholm (I'm pretty sure; I'd have to go back and look at
the minutes and/or audio tape to be 100% confident) decided that we
shouldn't do a full set of trust-anchor configuration objects because
that was beyond scope of the WG.  But we should support referencing a
single fingerprint to support self-signed certificates (one primary
reason is that the syslog WG decided they should do it, so we should
too).  So that's exactly what the object does: fingerprints of the
presented certificate, and only the presented certificate.  Note that
the elements of procedure allows for other trust verification paths to
succeed if no row exists in the table though (IE, other 5280 or similar
processes can be used instead).

I find it interesting that there are a number of WGs that have produced
psuedo-requirements for having a trust anchor management solution.  I
suspect that "soon" would be a good time to start such a management
endeavor within the TLS WG.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sat, 9 Jan 2010 17:47:46 -0800

> JS> tlstmAddrServerFingerprint object can only be used to match a 
> JS> specific certificate.
> 
> JS> On the other hand it seems the tlstmCertToTSNFingerprint 
> object can 
> JS> be used to match either a specific end-entity certificate or a CA 
> JS> certificate.
> 
> They're different cases, admittedly similar.  The real result 
> is that for the mapping to a securityName it really needed to 
> be done to make the resulting SNMPv3/TLS protocol even usable 
> (IE, if we don't have a securityName in the end of the 
> mapping we're sunk).
> 
[Joe] Correct operation of the protocol requires the server certificate
to be authenticated and authorized, its not any less important than
SecurityName mapping.  

> The WG in Stockholm (I'm pretty sure; I'd have to go back and 
> look at the minutes and/or audio tape to be 100% confident) 
> decided that we shouldn't do a full set of trust-anchor 
> configuration objects because that was beyond scope of the 
> WG.  But we should support referencing a single fingerprint 
> to support self-signed certificates (one primary reason is 
> that the syslog WG decided they should do it, so we should 
> too).  So that's exactly what the object does: fingerprints 
> of the presented certificate, and only the presented 
> certificate.  Note that the elements of procedure allows for 
> other trust verification paths to succeed if no row exists in 
> the table though (IE, other 5280 or similar processes can be 
> used instead).
> 
[Joe] I definitely agree with having fingerprint support.  Another
common deployment would be to have a common trust root that issues
certificates for devices.  The document already covers this case for
security name, it seems a little odd not to cover this case for the
server certificate as well.  

> I find it interesting that there are a number of WGs that 
> have produced psuedo-requirements for having a trust anchor 
> management solution.  I suspect that "soon" would be a good 
> time to start such a management endeavor within the TLS WG.
> 
[Joe] Perhaps. There is some trust anchor management work going on in
PKIX and the apps area is working on basic common validations procedures
for certificates.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 11 Jan 2010 09:00:27 -0800

>>>>> On Sat, 9 Jan 2010 17:47:46 -0800, "Joseph Salowey (jsalowey)" <[email-masked]> said:

JS> [Joe] Correct operation of the protocol requires the server certificate
JS> to be authenticated and authorized, its not any less important than
JS> SecurityName mapping.  

True; didn't mean to imply that's not the case.

JS> [Joe] I definitely agree with having fingerprint support.  Another
JS> common deployment would be to have a common trust root that issues
JS> certificates for devices.  The document already covers this case for
JS> security name, it seems a little odd not to cover this case for the
JS> server certificate as well.  

The split/difference was because in one side we have to derive
information (the securityName) from the presented certificate and just
"accepting the connection" isn't enough.  On the client side, though, we
don't need to do that.  It would certainly be nice to support
configuration for a list of trust anchors that are acceptable to use for
connection establishment but it's was considered beyond scope of the WG
because that would be getting involved with CA trust anchor certificate
management.  I'd actually like to see that work done (somewhere).  It'd
require a few mib configuration tables, though, and tables that aren't
necessarily specific to SNMP even.

On the other hand, adding a CA column to the existing tlstmAddrTable
isn't a good solution because it requires a row-per-connection and if
you have a device set up to make connections to 100 other places then
when the CA certificate changed you have to update 100 different rows.
It would need to be in another table that listed it singularly as a
valid CA to use for any outgoing connection.  And since that is not
necessarily protocol dependent, it should really go into a TLS-CA-MIB or
TLS-TA-MIB or something.

>> time to start such a management endeavor within the TLS WG.
JS> [Joe] Perhaps. There is some trust anchor management work going on in
JS> PKIX and the apps area is working on basic common validations procedures
JS> for certificates. 

Yep; I'm aware of the TAMP work in PKIX as well.  They're not quite
a complete solution for us, though.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 11 Jan 2010 09:33:34 -0800

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Monday, January 11, 2010 9:00 AM
> To: Joseph Salowey (jsalowey)
> Cc: Wes Hardaker; [email-masked]
> Subject: Re: IsmsQuestion on TlstmAddrEntry and TlstmCertToTSNEntry
> 
> JS> [Joe] Correct operation of the protocol requires the server 
> JS> certificate to be authenticated and authorized, its not any less 
> JS> important than SecurityName mapping.
> 
> The split/difference was because in one side we have to 
> derive information (the securityName) from the presented 
> certificate and just "accepting the connection" isn't enough. 
>  On the client side, though, we don't need to do that.  It 
> would certainly be nice to support configuration for a list 
> of trust anchors that are acceptable to use for connection 
> establishment but it's was considered beyond scope of the WG 
> because that would be getting involved with CA trust anchor 
> certificate management.  I'd actually like to see that work 
> done (somewhere).  It'd require a few mib configuration 
> tables, though, and tables that aren't necessarily specific 
> to SNMP even.
> 
[Joe] It seems you are doing trust anchor management for the other side.
I think even if you do a generic trust anchor management interface you
would still need to make specific entries for applications.  I can see
your argument that even given this a generic solution might be better.
I think we can take this off line and see what it might look like.  

One question/nit: in section 5.3, 3b - says that path validation like
5280 MUST be followed, isn't this only the case if a fingerprint match
was not available? 

> On the other hand, adding a CA column to the existing 
> tlstmAddrTable isn't a good solution because it requires a 
> row-per-connection and if you have a device set up to make 
> connections to 100 other places then when the CA certificate 
> changed you have to update 100 different rows.
> It would need to be in another table that listed it 
> singularly as a valid CA to use for any outgoing connection.  
> And since that is not necessarily protocol dependent, it 
> should really go into a TLS-CA-MIB or TLS-TA-MIB or something.
> >> I find it interesting that there are a number of WGs that have 
> >> produced psuedo-requirements for having a trust anchor management 
> >> solution.  I suspect that "soon" would be a good time to 
> start such a 
> >> management endeavor within the TLS WG.
> >> 
> JS> [Joe] Perhaps. There is some trust anchor management work 
> going on 
> JS> in PKIX and the apps area is working on basic common validations 
> JS> procedures for certificates.
> 
> Yep; I'm aware of the TAMP work in PKIX as well.  They're not 
> quite a complete solution for us, though.
> 
[Joe] Yup.

---

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

>>>>> On Mon, 11 Jan 2010 09:33:34 -0800, "Joseph Salowey (jsalowey)" <[email-masked]> said:

JS> One question/nit: in section 5.3, 3b - says that path validation like
JS> 5280 MUST be followed, isn't this only the case if a fingerprint match
JS> was not available? 

I changed the text to the following to resolve this issue:

  Validation procedures (like the path validation procedures defined in
  <xref target="RFC5280" /> or through the use of fingerprints as
  defined by the tlstmAddrServerIdentity column) MUST be followed.