Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm

[Wes Hardaker <[e-mail]>]

>>>>> On Wed, 5 May 2010 19:47:54 -0400, "David Harrington" <[e-mail]> said:

>> I'd love to see a case that points out where something isn't
>> deterministic given the existing specifications.  Please provide!

DH> My concerns are not about deterministic; they are about
DH> interoperability.

Ah; then I'd love to have the concerns explained!  More specifically, I
haven't heard a description of an actual problem (and I love to fix
problems, but I can't do so without the described complaint ;-).

The only issue I have in my head is that an operator MAY create a
situation where multiple certificates all map to a given
tmSecurityName.  This is possible a feature in their eyes, but it could
be done by mistake.  But certificates already contain this problem as
if you have two CAs as trust anchors there is nothing that says the
CommonName or any other value in a certificate can't conflict between
the two CAs.  IE, the problem isn't unique to SNMP.  What operators
should do is avoid those situations and ensure they understand and trust
their CA's publication policies.

DH> PKIX would not be the right place to define how to ***map them to
DH> SNMPv3*** security levels.

I think I misread a sentence early on and I apologize for that because I
missed the original point.

Defining a mapping table to security levels is technically possible and
would probably look something close to:

  |------------------------------+-------------------------------|
  | TLS Suite (index(es))        | securityLevel (output column) |
  |------------------------------+-------------------------------|
  | TLS_RSA_WITH_AES_128_CBC_SHA | authPriv                      |
  | TLS_NULL_WITH_NULL_NULL      | noAuthNoPriv                  |
  | TLS_RSA_WITH_NULL_SHA256     | authNoPriv                    |
  | ...                          | ...                           |
  |------------------------------+-------------------------------|

I don't think it would be a complex table.  But we decided not to go
there and simply declare than "NULL" must not be used to fulfill an
"auth" or "priv" flag (which the document already says).

-- 
Wes Hardaker
Cobham Analytic Solutions