Subject: RE: [Isms] Evaluation status

From: Juergen Quittek <[email-masked]>
Date: Tue, 11 Jan 2005 09:13:18 +0100

David,

--On 10.01.2005 12:16 Uhr -0500 David B Harrington wrote:

> I agree. I don't feel this is a significant change.
> The question posed was essentially, is the evaluation team making real
> progress?
> The answer "we have permission to push back an interim deadline"
> doesn't answer the question asked.
>
> I think the more important points are that:
> 1) The evaluation team has met and discussed all proposals.
>
> It is good to know that the team has been active, although this
> doesn't give us much info on how active. They met at IETF61. It would
> be nice if they and the chairs chose to share info, like how many
> times have they met and had useful discussions. We are looking for
> assurance that the team is seriously working on comparing and
> discussing the proposals, and that the recommendations they provide
> will be well-researched.
>
> They apparently have not conferred with the authors of the proposals
> for any clarifications yet, and that seriously concerns me. I do not
> feel comfortable that we will have meaningful comparisons completed
> before the March IETF meeting. Please comfort me.
>
> 2) The team will produce an Internet draft reflecting the
> discussion and giving a recommendation to the WG.
>
> OK. But do we get to know what they are using for evaluation
> guidelines, or do we have to wait until feb14 to find out how the
> evaluation is being done? If we don't even get to know what guidelines
> are being used before the final publication deadline for the March
> meeting, we certainly will not have time to do much if the WG
> disagrees with the guidelines. Eric proposed some guidelines to meet
> his security needs; Dave Perkins proposed some application guidelines;
> Wes published a table of attributes for various potential solutions.
> Are any or all of these proposed guidelines being taken into account
> in defining the team's guidelines? Are all team members using the same
> guidelines, or each using their own guidelines?
>
> I just want to know what the team's guidelines are so we are not
> blind-sided if the evaluation team doesn't consider the issues that
> the WG agrees need to be considered. The secrecy combined with the
> tight deadline is stressful; I'd like to know if there is something
> the rest of the WG or the authors of the proposals could be doing to
> make the evaluation process more effective/efficient.
>
> 3) There is already a version of this draft, but the essential
> section, the recommendation, is still to be done.
>
> Understood. Having an empty template for an internet-draft isn't very
> reassuring, however.

Thank you for the kind comment.  You are very right!

However, a missing essential section does not necessarily imply
an empty document.  I wouldn't have called it an initial version
in such a case.

The evaluation team spent effort on discussing and comparing
the proposals and this is reflected by the initial version.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

> Does the initial version indicate what factors
> are being considered in the analysis - e.g. an abstraction of the
> guidelines being used?
>
> 4) One of the problems the team is facing is that the different
> proposals cover different aspects of the overall problem.
>
> So is there anything we can do to help make it easier to complete the
> evaluation?
> Can I clarify anything in the TLS proposal, or provide additional
> specifications to address specfic aspects that are not currently
> covered in the proposal, or provide research services such as
> providing references to sections of other documents to help the team
> quickly compare the proposals?
>
> dbh
>
>> -----Original Message-----
>> From: Wes Hardaker [mailto:[email-masked]]
>> Sent: Monday, January 10, 2005 11:21 AM
>> To: Juergen Quittek
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [Isms] Evaluation status
>>
>> >>>>> On Mon, 10 Jan 2005 14:05:57 +0100, Juergen Quittek
>> <[email-masked]> said:
>>
>> Juergen> The most important news is that our shepherding AD granted
> a
>> Juergen> deadline extension until March for the WG decision on the
>> Juergen> solution to focus on.  You will find this reflected on our
>> Juergen> charter web page.
>>
>> I actually don't find this a big change.  The original November date
>> was really just an early deadline that tried to emphasize the
> urgency
>> of the one in march which was the real cut-off: decide something or
>> shut down.  By simply aligning the should-be-decided deadline with
> the
>> must-be-decided deadline you haven't really changed anything.  The
> end
>> result is still the same: if you wait until Feb 14th to let the
>> members of the group know what 4-6 people have decided, I have
> strong
>> doubts that there is enough time between that point and the
>> MUST-have-consensus deadline to handle the resulting discussions.
>>
>> --
>> Wes Hardaker
>> Sparta
>>
>
>

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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 11 Jan 2005 10:02:42 -0800

Martin Soukup [mailto:[email-masked]]  wrote: 
> > 4) There is an inherent problem with SNMPv3's Symmetric Key 
> > distribution such that it is difficult to deploy multi-vendor SNMPv3

> > systems in a manner that is not operationally insecure. (Yes, I do
know 
> > about RFC 2786 but I note that it is an informational RFC that is
not 
> > universally implemented.)  
 
> What will make the product of this WG more successful?  
 
Martin is asking a very important question here, which comes right back
to my "evaluation rationale" concern. The issue is that the IETF has a
diverse membership with diverse agendas. When I first started attending
back in 1992, I was one of two individuals in the community who were
"end users" (the other was Brian Carpenter, back when he worked for
CERN). The community then, as now, was dominated by researchers and
product makers. As the Internet grew in importance, the IETF community
has become more diverse, with healthy participation from ISPs,
governmental entities, and others. Each of these entities have their own
agenda and issues. 
 
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.
 
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 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). 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). 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. 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. I want the specification to compel default
behaviors that are secure, rather than the current situation. The larger
picture is that I want better tools and protections against crackers and
I want this WG to help the larger picture by correcting the current
SNMPv3 USM vulnerabilities.
 
--Eric