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

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

"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
2) SNMP symmetric keys may be assembled from passwords
3) Key updates do not provide for Perfect Forward Security
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

-----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: Eric Rescorla <[email-masked]>
Date: Mon, 28 Feb 2005 09:25:18 -0800

> 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.

> 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).

-Ekr

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Feb 2005 14:40:17 -0500

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)
>