Subject: RE: [Isms] Evaluation process?

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 2 Dec 2004 14:08:12 -0800

Uri, 

Thank you for your response. My answers are embedded within <Eric>
delimiters below.

--Eric

From: Blumenthal, Uri [mailto:[email-masked]] to Eric
Fleischman:

> If the ISMS results won't produce an (SNMPv3) USM-like variant (or
adjunct) that
> cleanly works with PKI, then my efforts in arguing for the formation
of
> this WG would have been wasted.

Can you explain how exactly you envision PKI utilisation in SNMPv3? 

<Eric> I would like to see PKI identity certs be used for network
manager authentication to SNMPv3 agents. I'd also like to see the
identity certs and server certs be used in a (code, document) signing
manner to provide authentication and integrity protection of SNMP
communications -- including the introduction of an authentication
chaining concept. The latter would permit the SNMP agent, for example,
to securely forward the signed communication to some other remote
location (which may or may not be under its auspices) for the network
manager's request to be processed without having the processing agent
have to trust the security representations of the SNMP agent. In this
way, there would be no requirement for the processing agent to trust the
SNMP agent.<Eric>

> I know that not every entity is deploying corporate-wide PKI 
> infrastructures, but I strongly believe that a prime requirement for 
> ISMS is that the selected protocol MUST be able to integrate with the 
> major existing corporate key management systems. These infrastructures

> include PKI, Kerberos, RADIUS, and possibly a few others.

PKI is probably in the future for the corporate world, question's
when...

<Eric> Yeah, I've heard this skepticism many times before. However, our
corporation spent many years to gradually make PKI become universally
real within our environment. It's been effectively "rock and rolling"
here for some time now. I am aware that not everybody is in a similar
shape, but I do know of many similar efforts occurring within other
American and European corporations, universities, and governments. PKI
is in much better shape than your skepticism justifies.<Eric>

> I also believe that the protocol MUST resolve the existing security 
> problems with SNMPv3 USM which are:
> 1) no provisions for two-factored authentication

Not sure it's needed - probably the *other* direction is where
two-factored auth may be required.

<Eric> Feel free to conclude this if you want. However, please privately
contact me if you aren't already aware of use cases where such a feature
would be very valuable. <Eric> 

> 2) SNMP symmetric keys may be assembled from passwords

You don't want keys be assembled from passwords - so don't do that. It's
not mandatory to derive keys that way. But for those who insist on
having the convenience of that weaker method, it's there. And by the
way, if you noticed - most of the world is still using plain password
auth (thankfully, now within a TLS pipe).

<Eric> Several/many existing SNMPv3 products today solely support
password assembly options. <Eric>

> 3) Key updates do not provide for Perfect Forward Security

DH-based key updates do.

<Eric> If your deployed SNMP implementations come from a single source,
you may be OK. If it comes from many sources, then you probably are not.
<Eric>

> 4) Inherent Symmetric Key distribution problems

You either need a trusted third party to tell the entities what their
session key is going to be, or a trusted thir party to confirm their
identities (i.e. DH key agreement signed by certified public keys), or
pre-provision the keys.

<Eric> Your "Trusted third parties" reference presumes an existing key
management infrastructure or approach that you share together. Since
SNMP's use of symmetric keys is unique within our environment, it is not
cost-effective to develop such an infrastructure solely for SNMP.
Rather, SNMP should conform to already existing key distribution systems
that we have already created for more important applications. By using
the word "important", I am not speaking against SNMP. Rather, I am
attempting to reflect the fact that SNMP has a very poor business case
because it doesn't help to bring in any revenue (i.e., it is a cost
sink, not a business solution).<Eric>

> 5) Lack of viable session keys

Perhaps it comes from the lack of the session concept in SNMP protocol?

<Eric> Yes, you are of course correct about SNMP's UDP orientation.
However, several of the proposals on the ISMS table have suggested
solutions to this problem without requiring TCP transports. <Eric>

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 2 Dec 2004 17:21:59 -0500

:-)
--Eric

Communications....

[Uri] Obviously for auth - that's not exactly what I'm asking. 
[Uri] Do you want per-message signatures to be PK-based? And
[Uri] how do you see agent-to-manager auth in that environment?

-- including the introduction of an authentication

[Uri] I sort of understand what you mean... I'm not sure it belongs
[Uri] to SNMP, but perhaps I just didn't get enough of this idea.
[Uri] We can discuss it later privately.

is in much better shape than your skepticism justifies.

[Uri] It's not skepticism - just an observation. Now, if you're in
[Uri] position to send me an unclassified presentation on PKI
[Uri] deployment in your organization (off-line of course),
[Uri] it would make my life easier. (At the last IETF, there
[Uri] were several such ones: MIT, J&J and US DoD.)

<Eric> Feel free to conclude this if you want. However, please privately
contact me if you aren't already aware of use cases where such a feature
would be very valuable. <Eric> 
[Uri] Please consider this a request (re. two-factor auth both ways),and
[Uri] feel free to respond privately.

<Eric> Several/many existing SNMPv3 products today solely support
password assembly options. <Eric>
[Uri] Hmm... Nowhere does the standard say that one should do so.
[Uri] And banging on the vendors should solve this, no? After all,
[Uri] it's a lot easier for the code to just intake a key, than to
[Uri] intake something, crank it several times and then store as a 
[Uri] key...

[Uri] Not quite. And it's not a TCP issue - it's the issue of having
[Uri] to keep track of a "session" somewhere at both ends, rather 
[Uri] than just "get a message, respond and forget". I'm not arguing
[Uri] against it - just bringing to attention that it's an extra
[Uri] effort that somebody or something will have to spend.