Subject: RE: [Isms] Evaluation status [and more]

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 11 Jan 2005 14:47:24 -0500

I tremendously value Wes Hardaker and his impressive skills, but our
frequent disagreements on this list is a reflection of our difference in
orientation. It's not necessarily that Wes is right and I am wrong, it
is rather that the issues are complicated. We can ignore a community or
a perspective (including their issues and agendas) but our result is
stronger if we do not.
 
Uri> Perhaps we should concentrate on the common part of all the
proposals - which is the most foreign to SNMP protocol - the idea of
"sessions". Once this is added cleanly - the rest ought to be easy
(after all, there's lots of knowledge in science and experience in the
field regarding protecting session traffic, once the entities are
authenticated and session "master key"  is created). Lack of "session"
concept makes integration with any session-based infrastructure a hack
at best.
 
Many years ago, Jeff Case and others were proposing Session-based
approach. It was shot down at the time, because (a) it wasn't clear how
to deal with local resource consumption; (b) it wasn't clear that it is
necessary; (c) it was deemed too expensive. There was no talk of
integrating with RADIUS back then (I think RADIUS protocol wasn't even
defined yet).
 
What we need to add to the architecture (probably not the protocol
itself - it doesn't have to show on the wire). I'll speak of sessions in
terms of USM and integration with USM - though it's not an absolute
necessity. But since requirements that session management lays on VACM
are the same as for USM, it's reasonable to keep it in here. Especially
since I see a way to avoid modifying the message or packet format.
 
Session: owns resources, requires dynamics in VACM and USM tables. In
that case - not "users" but "sessions" will "own" the actual traffic
keys, not "users" but "sessions" will be mapped onto VACM groups... And
a "session" will be created upon successful completion of "user"
authentication and high-level authorization, accomplished via non-SNMP
protocol (RADIUS, Kerberos, whatever). One has to define sessions,
because all the parameters (how many sessions are currently handled by
this engine, what's the life-time of this session, how much traffic has
it consumed, what user owns it, what protocol authorized its generation,
etc) ............ Nah, probably not the right place to start this
discussion.......

I want to poll the group: do you agree that in order to cleanly
integrate with any of the eisting infrastructures, SNMP needs to define
and emprace the concept of a session. If there's agreement - I'll finish
my write-up and submit it. [If not - I've other interesting things to do
:-]

So what will make this WG more successful? I believe that clearly
articulating the goals, concerns and issues of the various communities
that comprise us is a "path forward" to completing our task well since
it would provide a clearly stated evaluation rationale for us all. 
 
Uri> We're in agreement here.
 
My issues are the following: I have concluded that the SNMPv3 USM is
currently operationally insecure 
 
Uri> I resent this comment and find it unfounded and unjustified. 
 
.... and far too many SNMPv3 products are prohibitively difficult to
deploy securely today (i.e., a "hack me here" technology and far too
often the weakest point in a deployment). 
 
Uri> And why is that?
 
We buy products and I am constrained by what vendors create. It is an
expensive and time consuming game to do what Wes is suggesting on the
list for us do (i.e., for us to demand that vendors change their
products or else we won't buy them). 
 
Uri> You have your needs, other have theirs - that don't match yours. So
convince vendors that it's your needs that should be addressed. There is
no other acceptable way - to create a special standard just so that your
needs (rather than theirs) are addressed, seems too gross.
 
We've done that in the past and it is very costly to behave in that way
-- and there are many more issues to consider in buying products than
security. 
 
Uri> If only very few customers require what you need - obviously the
"customized" solution will cost money. What else is news?
 
Therefore, to me,  this WG will be successful if it results in
interoperable SNMP products that leverage one or more of our current
Authentication infrastructures in a manner that is operationally secure.

Uri> 1. This WG can result only in proposals later-to-become-standards,
not products. 2. All of the submitted proposals leverage one or more of
the current Authentication infrastructures. So this WG will be
successful even if we just toss a coin to choose one.
 
I want the specification to compel default behaviors that are secure,
rather than the current situation. 
 
Uri> "Secure" for you is "overboard" for most of other users. Why should
the default favor you and not them?
 
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 11 Jan 2005 16:17:03 -0500

>> I want to poll the group: do you agree that in order 
>> to cleanly integrate with any of the existing infrastructures,
>> SNMP needs to define and embrace the concept of a session.
>> If there's agreement - I'll finish my write-up and submit it.
>
> I agree.

Thank you.

> The notion of session might be accomplished via use of an existing secure
> session context (e.g. TLS session, IPSec SA, etc.)

I don't think so. Because in order to map it onto VACM - which none of the proposals (except for EUSM) did - the SNMP packet itself has to carry relevant information. Otherwise it wouldn't be any different than just tunneling SNMP traffic through an underlying protocol (such as TLS or IPsec). But no way to *cleanly* map the exchange to VACM.

> or it could simply be defined using the current SNMPv3 privacy mechanism,
> based on the lifetime of the "session keys".  We would need to adopt an
> appropriate authenticated key management system (e.g. Kerberos, etc.)
> to meet this requirement.

If by "privacy" you mean USM - I agree. If you mean just the "confidentiality" feature of USM - then I don't understand.

And yes - I envision creating dynamic USM entries for sessions, with appropriate keys computed locally from "session keys" received from Kerberos or RADIUS (or such).

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 11 Jan 2005 16:42:42 -0500

Uri Blumenthal writes...

> If by "privacy" you mean USM - I agree. If you mean just the
> "confidentiality" feature of USM - then I don't understand.
> 
> And yes - I envision creating dynamic USM entries for sessions, with
> appropriate keys computed locally from "session keys" received from
> Kerberos or RADIUS (or such).

Sorry.  I wasn't very clear.  What I intended to convey is that one
could obtain both confidentiality and authenticity on a
message-by-message basis (e.g. using UDP datagrams) without incurring
the overhead of per-message authentication (USM, RADIUS, Kerberos,
etc.), if the protocol payload contains some form of clear-text session
ID bound to the session keys, was encrypted for confidentiality using
one session key, and protected by a cryptographic MAC using another
session key.  The validity of the MAC under the selected (by session ID)
session key provides the authenticity.  The session lasts for the
lifetime of the session keys.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 11 Jan 2005 15:09:41 -0800

David's comments below reflect my own beliefs concerning the importance of supporting SNMP session security.

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, January 11, 2005 1:00 PM
To: 'Nelson, David'; [email-masked]
Subject: RE: [Isms] Evaluation status [and more]

Hi,

I would phrase the requirement slightly differently.
I do not believe that "in order to cleanly integrate with any of the existing infrastructures, SNMP needs to define and embrace the concept of a session.", but rather if SNMP embraced the concept of a session, it would have a much much larger selection of existing infrastructures with which to integrate.

If we adopt a third-party-authenticated session, we still need to have a fallback to a UDP-based trasnport and limited local authentication for troubleshooting a broken network.

I think the benefits of a session approach are numerous:
If we adopt a secured-transport session, we may not have to provide message authentication, integrity, and timeliness in the SNMP engine. If we adopt a secured-transport session, we might send multiple SNMP messages within the same session, to minimize the overhead. If we adopt a secured-transport session, we might make this host-to-host, which is similar to the way many operators "authenticate" SNMPv1 messages. 
If we adopt a secured-transport session with host-level authentication, we might make user-authentication part of the authorization stage, so we don't have to pass the security principal from the transport layer to the application layer. If we adopt a secured-transport session, we might be able to transport the simpler SNMPv1 or SNMPv2c message formats securely.

If we adopt a stream-based transport session, we might send much larger messages, improving SNMP's efficiency for table retrieval. If we adopt a stream-based transport session, that would make SNMP much more consistent with other management interfaces, like CLI/SSH and NETCONF. If we adopt a stream-based transport session, we could more easily utilize an XML-based data description approach, and move away from ASN.1.

I, for one, would like to see us adopt a session-based approach to supplement the UDP-based approach needed for troubleshooting broken networks. My preference would be to utilize sessions already provided by lower-layer protocols, so we can simplify SNMPv3.

David Harrington
[email-masked]

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 12 Jan 2005 02:37:02 +0200

I would agree if you change 'any' by 'many' 
 
Regards,

Dan

I want to poll the group: do you agree that in order to cleanly integrate with any of the eisting infrastructures, SNMP needs to define and emprace the concept of a session. If there's agreement - I'll finish my write-up and submit it. [If not - I've other interesting things to do :-]

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 11 Jan 2005 17:17:49 -0800

Well, Uri, you certainly popped my balloon. Here I was thinking that
perhaps this is among my best postings, and your email was certainly not
the response I was expecting.
 
I will try to answer your questions (or objections) by embedding my own
text below. Should my explanations not resonate with you, then perhaps
we can discuss these issues at the next IETF, assuming that I will be
funded to attend it?

	-----Original Message-----
	From: Blumenthal, Uri [mailto:[email-masked]] 
	Sent: Tuesday, January 11, 2005 11:47 AM
	To: Fleischman, Eric
	Cc: [email-masked]
	Subject: RE: [Isms] Evaluation status [and more]

	 <snip> 
	So what will make this WG more successful? I believe that
clearly articulating the goals, concerns and issues of the various
communities that comprise us is a "path forward" to completing our task
well since it would provide a clearly stated evaluation rationale for us
all. 

	My issues are the following: I have concluded that the SNMPv3
USM is currently operationally insecure 
	 
	Uri> I resent this comment and find it unfounded and
unjustified.  

Eric> I am very sorry to cause you resentment. That certainly wasn't my
intention. Large operations, which due to their size and large number of
different device types, need to orchestrate the products of multiple
SNMP vendors. SNMP does not make this easy if one is trying to do this
securely. Rather, such environments are confronted by a lack of a
coherent SNMP infrastructure to enable a viable multi-vendor deployment
without having to do onerous investments (or onerous human management
tasks) on their own in order to perform fundamentally tasks things like
symmetric key distribution. This is an awfully lot of needless expense
when we have already deployed authentication systems deployment wide
such as PKI, Kerberos, or RADIUS. Such problems probably don't occur for
single vendor implementations though such environments are outside of my
experience. Unless one has total control of the SNMP system end-to-end
today it is simply not possible to deploy a viably secure SNMP
deployment (e.g., if one is controlling SNMP clients but not SNMP
management systems). The current approach is therefore not modular nor
scalable nor demonstrably secure. Rather, there is lots of evidence to
question whether it is securable at all.

	.... and far too many SNMPv3 products are prohibitively
difficult to deploy securely today (i.e., a "hack me here" technology
and far too often the weakest point in a deployment). 
	 
	Uri> And why is that? 

Eric> The default privacy key durations are dangerously long. The
establishment mechanism for distributing authentication keys is
operationally difficult in some single vendor and most multi-vendor
environments. SNMP MIBs by default often provide invaluable aids for
hacking and cracking devices. These default MIBs need to be really
tightened down if they are not actively undercut the security of that
platform or environment. One must rely on non-SNMP mechanisms (e.g.,
IPTables, IPSec, SSH) to supplement the USM provisions in order to
protect the devices' SNMP agents from a wide variety of cracking
attempts. This is more troubling when one has fundamental doubts about
the very viability of privacy and authentication keys due to the lack of
PFS or the presence of password-derived keys. In shared business
environments, how can we ensure that our business partner has kept their
keys secure such that Joe cracker isn't spoofing them to us? I could go
on and on but the point I am trying to make isn't that the USM security
is technically flawed theoretically because such a point would probably
be false. It is rather that the environment in which USM is deployed is
such that it is really, really tough to deploy devices supporting USM in
an operationally secure manner and, even if one has, one has no way to
verify that one has. Also, the USM is very poorly designed for
supporting many emerging modern business requirements, particularly
those that are affiliated with increasingly porous corporate perimeter
boundaries.

	We buy products and I am constrained by what vendors create. It
is an expensive and time consuming game to do what Wes is suggesting on
the list for us do (i.e., for us to demand that vendors change their
products or else we won't buy them). 
	 
	Uri> You have your needs, other have theirs - that don't match
yours. So convince vendors that it's your needs that should be
addressed. There is no other acceptable way - to create a special
standard just so that your needs (rather than theirs) are addressed,
seems too gross. 

Eric>  Because I don't expect non-end users to sympathize or value the
problems of end users (especially in the IETF where end users have such
a tiny voice), I am uncertain how to respond to you on this point. I
don't think it would be helpful to refer to the many other end users or
certification authorities who have made similar conclusions as I about
SNMPv3. You probably wouldn't agree with me that these issues are
indirectly reflected by a diminishing SNMP mind-share worldwide. That
is, if you concur at all that the SNMP mind share is diminishing, you
probably believe that it is being caused by other factors (e.g., the
desirability of using XML structures instead of MIBs/PIBs). I guess I
can only say that a growing number of us end users are feeling like me,
which is why I argued so often for the creation of the ISMS working
group. That is, I wanted the IETF to create ISMS because I believe that
the best way to make SNMP's security become operationally viable is to
create a common multi-vendor security solution for SNMP that is
operationally viable. Because a fundamental problem with SNMP security
is in multi-vendor deployments, pounding on vendors individually is not
a promising mechanism to fix problems which aren't caused by the vendors
themselves. Rather, I believe that the solution is to create a viable
alternative to -- or a supplement for -- the current USM within the
IETF. I believe that vendors will be encouraged to deploy a more secure
version of SNMP once such an alternative exists for their customers to
request.

	 We've done that in the past and it is very costly to behave in
that way -- and there are many more issues to consider in buying
products than security. 
	 
	Uri> If only very few customers require what you need -
obviously the "customized" solution will cost money. What else is news?

	Uri> 1. This WG can result only in proposals
later-to-become-standards, not products. 2. All of the submitted
proposals leverage one or more of the current Authentication
infrastructures. So this WG will be successful even if we just toss a
coin to choose one. 

Eric> Proposals that become standards is what I am after. Once a viable
standard exists, then viable interoperable products may be devised. My
goal is products but the path to that is first a proposal and then a
standard.
 
I don't know if your second point is true or not. It may be. Certainly I
concur with you that most -- perhaps even all of them, as you state,
though I haven't concluded this yet myself -- of the alternatives
materially improve SNMP security and thus are very positive steps
forward. However, some alternatives seem to me to be more flexible than
others. Flexibility is good. Also, some seem to have many provisions,
and others have only a few. If "many" doesn't translate into "needless
complexity", then "many" is good. If it does, then it isn't.

	  I want the specification to compel default behaviors that are
secure, rather than the current situation. 
	 
	Uri> "Secure" for you is "overboard" for most of other users.
Why should the default favor you and not them?

Eric> My use of the word "default" was concerning the defaults within
the protocol itself. I am arguing for approaches that are inherently
secure, rather than approaches which require convolutions on the part of
the end user to make them become secure. 
 
--Eric

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 28 Jan 2005 13:29:48 -0800

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Friday, January 28, 2005 1:09 PM
...
(lots of agreement deleted)
...
> In SNMPv1, the immutable assignments were made to communities, but I'm
> not sure whether contexts, views or groups are the right answer in
> SNMPv3. Contexts are the immutable entities, so I think contexts might
> be the right answer. I think we could help the vendors provide default
> assignment of mib modules to public/private/root contexts by providing
> a list of IETF mib modules, and recommend which context they should be
> associated with.
...

I think using contexts to accomplish this would take us back to the
semantic tangle we had with communities.

I think groups are a better match, since the VACM defines a group as a
set of users with identical permissions.

Randy

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 31 Jan 2005 18:35:15 -0500

Wes Hardaker writes...

> I don't think the charter for ISMS should ever be expanded to 
> say that both problems (or others) must be bound together in 
> a single solution.  They should, obviously, be usable together 
> however.

Hmm...  I'm confused by this.  I believe that authorization *needs* to
be strongly bound to authentication, to be robust and trustworthy.
While there may be ways to accomplish that binding using disparate
solutions, it seems that it would be much easier (straightforward) to
achieve the binding using a single solution.  That's not to say that we
don't have the potential for using multiple AAA protocols, but rather to
say we ought not to mix authentication from protocol "A" with
authorization from protocol "B".

> I would not mind, personally, if the charter were updated to 
> include such future work as well but right now we haven't 
> actually accomplished the immediate goals of determining an 
> architectural direction to solve the current problem.

Agreed.  We need to keep the pressure on to complete current goals. That
doesn't mean that authorization is unimportant, however.

---

From: "Martin Soukup" <[email-masked]>
Date: Mon, 31 Jan 2005 21:41:29 -0500

> From: Wes Hardaker [mailto:[email-masked]]
> Sent: January 31, 2005 4:45 PM
> To: Soukup, Martin [CAR:5K50:EXCH]
> Cc: [email-masked]'; 'David T. Perkins'; [email-masked]
> Subject: Re: [Isms] Evaluation status [and more]
> 
> >>>>> On Sun, 30 Jan 2005 20:32:09 -0500, "Martin Soukup"
> <[email-masked]> said:
> 
> Martin> I think that's what I said. I think that the migration of SNMP
> Martin> users to secure communication and complex access control is
> Martin> once direction things are moving. The other is the movement of
> Martin> users with experience with secure communication and complex
> Martin> access control to SNMP. It just important, to me, to find a
> Martin> solution that solves both migrations if possible.
> 
> In order to achieve maximum deployment and usability, I agree that we
> need to solve all the deployment problems that people face.  This
> includes both secure communication via authentication mechanisms
> operators already use (ISMS work) as well as work to help distribute
> authorization configuration to VACM or anything else (future work).  I
> don't, however, see a technical to tie the results together.  IE, I
> don't think the charter for ISMS should ever be expanded to say that
> both problems (or others) must be bound together in a single
> solution.  They should, obviously, be usable together however.  I
> would not mind, personally, if the charter were updated to include
> such future work as well but right now we haven't actually
> accomplished the immediate goals of determining an architectural
> direction to solve the current problem.  We're now at the end of
> January and still have yet to hear from the evaluation team but yet
> the clock is still ticking away.

I agree that this is out of scope and that it is best to focus on
accomplishing something here. I agree that authN should be defined
separately from authR, but not the reverse - something to be debated after
ISMS creates something we all use I hope.

Martin.