Subject: RE: [Isms] achieving market saturation with ISMS (fwd)

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 28 Feb 2005 09:29:15 -0800

I feel very sad, Randy, that you read David's posting as a put-down. I
did not read it that way. Would you mind re-reading his posting after
considering my next paragraphs?

I fully concur with what David wrote. However, I simultaneously have
respect and appreciation for what you and the other authors accomplished
by your draft. I honor you, despite my belief that your work was flawed
because it did not consider all of the consensus requirements of the
working group. Rather, it only considered a small subset. 

All this comes back to my frequent earlier emails months ago that the
noble undertaking which you so graciously volunteered to do was unlikely
to be successful unless it was pegged to specific documented
requirements and a documented evaluation criteria. When we learned that
this was not the case, I was fairly certain that your work could not be
adequate, which was how it proved to be. This is a process issue and not
a personnel issue: I am confident that all four of you are outstanding
technical people and that had you addressed documented requirements in
terms of documented evaluation criteria that you would have produced an
outstanding draft. 

--Eric

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, February 25, 2005 5:01 PM
To: [email-masked]
Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

Hi -

> From: "David T. Perkins" <[email-masked]>
> To: "Juergen Quittek" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, February 25, 2005 8:51 AM
> Subject: Re: [Isms] achieving market saturation with ISMS (fwd)
>

> HI,
>
> The WG is the guide, not the EVAL I-D.
>
> The EVAL I-D is fatally flawed because,
>  1) It used eval aspects not included in the WG charter
>     or that had rough concensus on the WG charter.

Please forgive us for attempting to include points raised in discussion
on the working group mailing list, like those from Eric Fleischman's
wish list, that appeared to not be contentious, as well as any other
criteria that we may have used in trying to identify a clear "winner"
from among the proposals.

>  2) It specified eval criteria in section 2.3 (operational
>     scenarios), but did not include the result of
>     these operational scenarios in the EVAL I-D.

Please forgive us for submitting a -00- draft that is not perfect. I
guess we erred by trying to produce something helpful in time for the
i-d cutoff, rather than waiting for something that was complete in all
respects.

>  3) It mischaracterized the features of the proposals.

Please forgive us for not getting everything right.  Please send text,
and we'll happily correct errors where we've misunderstood the
proposals.

>  4) It based it's recomendations on facts the authors
>     didn't know and ignored facts authors should know
>     (or that could be determined).

Please forgive our lack of omniscience.  We'll happily incorporate text
that will improve the document, particularly if it would enable a more
clear-cut decision by the WG. However, the WG should, I think, be
focusing on moving ahead.  As much as we would have like to be able to
pick one of the proposals and say "this is perfect and we should procede
from here", things, at least as we saw them, were not so clear-cut.

> Does this help with your questions below?
> On USM support, why don't you ask the EVAL authors
> instead of trying to interpret their double talk.

I'm not sure what you're calling "double talk."   The requirement
"Must not preclude the use of USM [RFC3414], particularly if network
instability could cause problems for the proposed solution" has not
previously been disputed, as far as I know.

> That is, EVAL authors,
> 1) Can a new security model replace USM so that there
>    would be no need for its deployment. That is,
>    after the new security model is available for
>    deployment, will there be any need for USM
>    except where it is already deployed?

I think any model that potentially relies on external AAA needs some
kind of self-sufficient fallback.  USM fuflfills that requirement. It's
probably possible to define a new security model with comparable
fallback capabilities, like the local accounts in SBSM, but that begs
the question of how these are managed.  So yes, to the extent that a new
model re-impliments some key USM features,and doesn't break other key
needs, like device discovery, it could replace USM. Whether doing so
would actually be desirable is not clear.

> On Fri, 25 Feb 2005, Juergen Quittek wrote:
>
> > Hi David,
> >
> > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote:
> >
> > > HI,
> > >
> > > This is a resend. Sorry if you get it twice, but
> > > it's VERY IMPORTANT.
> > >
> > > Regards,
> > > /david t. perkins
> > >
> > > ---------- Forwarded message ----------
> > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST)
> > > From: David T. Perkins <[email-masked]>
> > > To: Juergen Schoenwaelder <[email-masked]>
> > > Cc: Randy Presuhn <[email-masked]>, [email-masked]
> > > Subject: Re: [Isms] achieving market saturation with ISMS
> > >
> > > HI,
> > >
> > > Juergen is so right. We covered this topic in the BOFs that lead 
> > > up to the formation of ISMS.
> > >
> > > That is, when a box is set up, work is done to use
> > > other management interfaces. Unfortunately, to deploy SNMPv3/USM 
> > > on the box, extra work has to be done. And for on-going 
> > > operations, extra work needs to be done to support SNMPv3/USM. The

> > > ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this "extra" work.
> >
> > Sorry, to which part of the I-D are you referring?
> >
> > >                              I believe the EVAL team didn't GET 
> > > THIS, and thus, they came out with a fatally flawed I-D. Again, 
> > > THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For 
> > > example,

The "extra" work, setting the keys for the "initial" user, isn't
addressed by any of the proposals.  In some respects they compound the
problem by requiring provisioning of AAA keys.  This has been discussed
on this mailing list at some length.  What other parts of the problem
don't we get?

> > Do you have more examples or even the full list?

These would be appreciated; we're trying to be useful.

> > >                                    they believed that boxes must 
> > > continue to support USM, so if an authentication service was not 
> > > available, there would be a fallback method to authentication. 
> > > WRONG!!

So if there is no authentication service available, things should simply
not work?  If the fallback is to local accounts, we're back to the
problem of specifying how they're managed, unless you accept the
argument that it's simply someone else's problem.

> > What the I-D states is
> >
> >       *  Must not preclude the use of USM [RFC3414], particularly if
> >          network instability could cause problems for the proposed
> >          solution
> >       *  ...
> >       *  Must not break basic device discovery.  (Retaining USM
support
> >          would satisfy this goal.)
> >
> > I don't see a statement saying "boxes must continue to support USM".
...

Indeed, we did not say boxes must continue to support USM.
The requirement is that this solution must not preclude supporting USM.

> > >                                   There is NO NEED for USM, except

> > > for backwards compatibility with the VERY small number of 
> > > SNMPv3/USM managers.
> >
> > Is there support for this statement by other WG members?
> >
> > > The WG will continue to go around in circles and come
> > > up with clever engineering solutions (because the
> > > EVAL authors and members of the WG are really smart
> > > engineers) until some basic understanding is reached
> > > on the operational problem to be solved.
...

Which operational problem(s) do you believe are the ones to
be solved, if not the ones in our charter?

Randy

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

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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 28 Feb 2005 09:48:05 -0800

From: Eric Rescorla [mailto:[email-masked]] 
>> 2) SNMP symmetric keys may be assembled from passwords

>I'm not sure that this is a showstopper. Obviously, it's 
>better to have an authentication system that's not susceptible 
>to dictionary attack, but a system which is susceptible to 
>dictionary attack is far better than no system at all (cf. 
>CRAM-MD5, etc.) Do you want to ban passwords or simply provide 
>an alternative.

I agree with you, Eric: this is not a show-stopper. Undesirable, yes.
That is why it is at the beginning of the list (i.e., not a highest
priority item). What makes it bad, in my mind, is when it is combined
with other issues, such as Issue 3 (no PFS), and issue 5 (i.e., the
default lifetimes of the privacy key). As Uri has pointed out, support
for AES has dampened the affect of these combined blemishes but they
nevertheless are weaknesses that can be leveraged by "bad guys".

No, I certainly don't want to ban passwords, since they are part of the
current USM. My view is that USM is good for many deployments and so
those deployments shouldn't be forced to undergo the disruptions that
change causes. However, some deployments have need for more security
than what USM provides, and that is what we in the ISMS WG are trying to
address -- or, at least, this is what I think we are trying to address.

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

>Why do you think this is a requirement? Many security 
>systems (e.g. SSL) do perfectly well without using PFS. 
>(SSL has a PFS mode, but the dominant modes, at least for HTTPS, 
>do not provide PFS).

Good point, Eric. I fear that my point is motivated by the local USM
situation and that, had we more adequate keys (i.e., keys that were
stronger than passwords) and had we more adequate privacy (i.e., if we
had a "session concept" such as TLS) and had we a better operationally
secure system (e.g., fool-proof symmetric key exchange)
SNMP-deployment-wide, then this wouldn't be an issue. However, given
password-assembled keys and bad privacy default configurations, the lack
of PFS is A Very Big Deal -- something it wouldn't have been if the keys
were stronger to begin with.

Uri will probably argue that given AES, this is no longer a big deal.
Half of my mind agrees with him, but then the other half remembers how
creatively I've been cracked in the past, and I really don't want to be
giving the crackers any needless ammunition. Rather, I want SNMP to have
similar strong defense in depth as the rest of my systems, which a
near-total reliance on AES does not provide.

--Eric

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 28 Feb 2005 12:38:16 -0800

David,

Your charter quote concerns me because I believe that it endorses what I
have been suggesting and you apparently interpret it differently.
Concerning the phrase in the charter "creating a security model", do you
interpret that as being an optional replacement for USM or a
modification to USM? I assume by your last paragraph that you believe
the former. If so, then we are somewhat on the same page together.

Concerning your 90% number, what is to be lost in addressing the needs
of the remaining 10% who do not believe SNMP USM to be adequately secure
-- or, more accurately, who believe that the current USM implementations
cannot be readily deployed in a secure manner in large, multi-vendor
environments? Would you have SNMP continue to fragment in terms of
various security gradations when one alteration could satisfy everyone?
After all, what I am seeking are three possible deployment
configurations (1) no security, (2) traditional USM security, and (3)
adequate security for the environments in which I work. Why do you
apparently urge needless and destructive fragmentation, fragmentation
that does not address the security needs of the large deployment, which
is what ISMS is explicitly trying to do (i.e., READ THE CHARTER!!!)? 

It has been my contention all along that the reason why it is difficult
to securely deploy the SNMPv3 USM in large distributions is due to
inherent and significant weaknesses within the USM's security design
that are difficult to overcome when creating secure multi-vendor
deployment. This is the basis for my requirements list.

I disagree with your claims that RFC 3411 lists our security
requirements. It is very obvious to me that the SNMP security community
has NEVER historically considered the larger deployment environment --
otherwise it NEVER would have defined a security proposal that cannot
interwork with ANY other IETF protocol nor with any installed
authentication/authorization system. This is a big reason for why the
charter is written as it is. Therefore, I STATE that RFC 3411 reflects
the historic bias of the SNMP security community rather than the needs
of the SNMP user community.

Therefore, the view from my knothole as an SNMP user, is that you have
not yet accepted the ISMS charter nor understood why ISMS is needed. You
are therefore not appropriately responding to the ISMS goals.

In your favor, I do believe that there are numerous user communities
with fairly homogeneous device deployments (e.g., ISPs) and/or with very
small (tiny) numbers of devices (e.g., less than 100,000) that probably
can securely deploy SNMPv3 USM exactly as it currently is defined.
However, since I do not work in such an environment, I very much would
like SNMP's security to become adequate for the environment in which I
do work. This is why I oppose what you are suggesting because you are
basically saying that my type of user is not worthy of being supported,
since we are only 10% of the deployments. However, consider how many
billions of devices are included in our 10%!!!! In any case, the bottom
line is that the ISMS WG is primarily created to support users like me
since the needs of your 90% are already covered.

--Eric

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Monday, February 28, 2005 11:40 AM
To: Fleischman, Eric; 'Randy Presuhn'; [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS (fwd)

Hi Eric,

>From where I sit as a proposal writer, I am not of the impression that
your list is ISMS consensus of the requirements, and have not been
working to address each of your requirements with the TLSM proposal. I
consider your list to be a wish list from one contributor - an important
contributor, but still just one contributor.

>From the charter:
"Although the enhanced protocol is secure, operators and administrators
find that deploying it can be problematic in large distributions. ...
The ISMS working group will focus on finding and identifying a solution
for the first of the two above mentioned problems: creating a security
model for SNMPv3 that will meet the security and operational needs of
network administrators. ... It should also be compliant with the
security model architectural block of SNMPv3, as outlined in RFC 3411." 

RFC3411 lists Security Requirements of the Architecture; I consider that
list to be the security requirements. In a BOF held a few years ago,
"Security Requirements for Network Management Protocols", sponsored by
the Security Area and attended by many operators, it was concluded that
SNMPv3 (using USM and VACM) was secure, although AES support was
desired. I have seen extremely few complaints that USM is inadequately
secure (given AES support); I recall complaints from you and from Wes,
but not from others. I don't consider the WG consensus to be that we
were striving to provide stronger security, but rather that we are
trying to improve the deployability of SNMPv3 by leveraging existing
security infrastructure to meet the SNMPv3 requirements for security
defined in RFC3411. 

I have seen many complaints that SNMPv3 is hard to deploy; I have been
trying to address the deployment issue, and I think the bulk of the WG
are focusing on the deployment issue. In an IAB workshop for network
management, with numerous operators present, there were complaints about
the SNMP ease-of-use, but none about SNMPv3 not being secure enough. I
think 90% of operators are satisifed that USM is secure, and the WG is
trying to make it possible for that 90% to deploy SNMPv3 (with security
comparable to USM) more easily.

David Harrington
[email-masked] 

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Fleischman, Eric
> Sent: Monday, February 28, 2005 12:16 PM
> To: Randy Presuhn; [email-masked]
> Subject: RE: [Isms] achieving market saturation with ISMS (fwd)
> 
> "Wish List"??? It is my belief that I have been articulating
security
> requirements for the new protocol. I have frequently invited
> discussions
> as to why the following SNMPv3 USM blemishes need to be 
> improved. Other
> than discussions in the SNMP mail list over two years ago, I 
> haven't had
> any takers in this WG. Thus, from where I sit, the following ARE
> consensus ISMS requirements, listed in order of increasing
importance:
> 1) no provisions for two-factored authentication
> 4) Inherent Symmetric Key distribution problems
> 5) Lack of viable session keys
> 6) SNMPv3 USM keys are unrelated to any existing authentication
system
> within a deployment (e.g., Kerberos, PKI, Radius, etc.)
> 
> --Eric
> 
> kind of self-sufficient fallback.  USM fuflfills that requirement. 
> It's probably possible to define a new security model with comparable
> > > > That is, when a box is set up, work is done to use other 
> > > > management interfaces. Unfortunately, to deploy
> SNMPv3/USM

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 28 Feb 2005 15:42:37 -0500

> 1) no provisions for two-factored authentication

Seems that nobody cares (except for you).

> 2) SNMP symmetric keys may be assembled from passwords

Any keys may be assembled from passswords - just run a crypto-hash over
them. SNMP just offers a "standard" way of doing that.

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

Seems that nobody cares.

> 4) Inherent Symmetric Key distribution problems

Use symmatric key algorithms - have key distribution. We're addressing
this.

> 5) Lack of viable session keys

"No session" = "no session keys". We're addressing this.

> 6) SNMPv3 USM keys are unrelated to any existing authentication system

With no session concept - it's the only feasible way. As we're
introducing session - we're addressing this.

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, February 25, 2005 5:01 PM
To: [email-masked]
Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

Hi -

support
...

...

Randy

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 28 Feb 2005 15:51:41 -0500

>were stronger to begin with.

Again, what is lacking is "session" (with which comes separation between

long-term and short-term or session keys). It is being addressed.

> Uri will probably argue that given AES, this is no longer a big deal.

Encryption algorithm has little to do with this issue. Creating session
machanism 
Has everything to do with it.

I myself am perfectly happy if USM users are dynamic (and their key
lifetime
is session-long), created with the session by xUSM protocol.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 28 Feb 2005 13:04:04 -0800

Uri,

It seems that you and I are starting to think similarly. This is good
news.

>long-term and short-term or session keys). It is being addressed.

I certainly agree with you about the need for "session" but I do not
believe that "session" alone will meet all of our needs. Specifically, I
remain very concerned about weaknesses in the authentication system
being exploited by crackers. It may be that you can hit both birds with
one stone. If so, I'm very interested in how you propose doing so.
Certainly, our world would be much easier if the SNMP authentication
system were based on at least one of our deployed authentication
infrastructures.

>I myself am perfectly happy if USM users are dynamic (and their 
>key lifetime is session-long), created with the session by 
>xUSM protocol.

I too would be very happy with such a world **if** both the session and
authentication security requirements were met and the system leverage
widely deployed authentication infrastructures. Replacing USM has never
been my goal -- being able to security deploy SNMP in large, multivendor
environments has always been my goal.

--Eric

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 28 Feb 2005 21:03:45 -0500

> being exploited by crackers. 

What specific weaknesses in what part of authentication system?
Rememeber that the traffic is protected by session-wide keys that are
created when the session is established and are gone once the session is
terminated.