Subject: RE: [Isms] Evaluation status

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 10 Jan 2005 09:56:24 -0800

From: David B Harrington [mailto:[email-masked]] wrote:
>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?

I value David's and Wes' (and doubtlessly the other authors as well)
desire to assist the evaluators, if possible. Thank you! However, my
concern remains that I am uncertain what evaluation criteria and
requirements the evaluators are using.

There are indeed multiple aspects to the overall problem. However, my
satisfaction with the evaluation conclusions will be a function of how
they addressed the prioritized list requirements that I have repeatedly
enumerated to the IETF over the past 18 months or so. I can't imagine
being a happy camper if the requirements that I believe to be the
highest priority are disregarded altogether at the expense of issues
that I either don't value or else believe to be of low importance.

I am very willing to justify my prioritized list. However, such
discussions should have occurred before the evaluation, rather than not
occurring at all.

Here is my prioritized list (listed in order of increasing importance):

1)	No provisions supporting two-factored authentication.
2)	SNMPv3's symmetric keys may be assembled from passwords (several
SNMP implementations require that they must be so assembled due to
symmetric key distribution problems). Such keys are no more secure than
the passwords they are derived from.
3)	Key updates do not provide for Perfect Forward Security (PFS).
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.)
5)	SNMPv3's session (i.e., privacy) keys are often default-deployed
in (security) non-viable ways.
6)	SNMPv3's symmetric keys are unique within a deployment (i.e.,
SNMP keys are unique to SNMP and are not integrated with any other IETF
protocol). Similarly, SNMPv3 cannot use any existing
authentication/authorization infrastructures already present in that
deployment (e.g., Kerberos, PKI, RADIUS, etc.).

--Eric

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Jan 2005 13:57:34 -0800

Hi -

Would the authors of the proposals on the table care to address
Eric's list in terms of (a) how their proposal does(n't) meet each of
his requirements, and (b) how much importance they'd attribute
each of his requirements?

Randy

> From: "Fleischman, Eric" <[email-masked]>
...
> Cc: <[email-masked]>
> Sent: Monday, January 10, 2005 9:56 AM
> Subject: RE: [Isms] Evaluation status
...
> deployment (e.g., Kerberos, PKI, RADIUS, etc.).
...

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Jan 2005 23:40:04 +0100

> each of his requirements?

I can try (although I am not even sure we decided or lets say attempted
to decide that Eric's requirements are the WGs requirements).
 
> > 1) No provisions supporting two-factored authentication.

The idea behind the transport layer security model was to provide 
a generic mechanism to bind a security service operating at the 
transport layer (as seen from an SNMP architecture perspective) 
into the SNMP architecture with the goal to make existing security 
protocols which provide two-factored authentication usable within 
SNMP. (I hope there is one. ;-)

> > the passwords they are derived from.

This is USM specific and perhaps even implementation specific. Should
not be an issue with a transport layer security model.

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

Boils down to the concrete security protocol one would use with the
transport layer security model.

> > universally implemented.)

Key distribution is always difficult. While Kerberos works in some
environments, there are others where Kerberos does not exist. Different
environments use different things - the nice thing about the transport
layer security model proposal is that once defined it should allow to
interface to different things providing security below SNMP in a common
way.

> > in (security) non-viable ways.

Not sure what this is - probably a request for vendors and implementors 
not to ship default keys? If yes, no standard can't fix stupidity.

> > deployment (e.g., Kerberos, PKI, RADIUS, etc.).

This is what the transport layer security model was trying to address.

Now, does this help? I guess not. The proposals on the table indeed
focus on different aspects of the overall problem space.  The best 
thing that could come out of the evaluation in my mind would be a 
description in which SNMP application areas or environments the 
different proposals help to solve the SNMPv3 deployment problems
and how.  

There seem to be big differences how different organizations with 
different backgrounds and cultures address their security needs and 
the one solution fits all approach is probably not realistic. So the 
decision will likely be on which environment(s) to focus this work, 
taking very well into account that the solution might not be 
interesting for all of us since other solutions (not selected)
might work better in other segments of the overall market space.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Jan 2005 16:24:04 -0800

Hi -

Thanks!  I'd love to hear from the other authors as well.
One minor comment follows below.

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, January 10, 2005 2:40 PM
> Subject: Re: [Isms] Evaluation status
>

...

That's why I was careful to phrase it as "Eric's list" and "his requirements".
That's also why anything that looks like "requirements" in the design team's
recommendations must not be given undue weight.  There has been
no proclamation of consensus on what the WG requirements might be,
beyond what's dictated by the WG charter.

At least Eric has been willing to state what he wants, though as I understand
what he's asking for, none of the proposals before us will make him happy,
and some of his requirements seem to me to be contradictory.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 10 Jan 2005 19:47:55 -0800

>>>>> On Mon, 10 Jan 2005 13:57:34 -0800, "Randy Presuhn" <[email-masked]> said:

Randy> Would the authors of the proposals on the table care to address
Randy> Eric's list in terms of (a) how their proposal does(n't) meet
Randy> each of his requirements, and (b) how much importance they'd
Randy> attribute each of his requirements?

I think the matrix I've posted a number of times here covers most of
the aspects in the list plus more.  However, I'd be more than happy to
respond to it directly.

>> 1) No provisions supporting two-factored authentication.

SBSM as is doesn't support this, but only because the draft hadn't
documented a complete solution for that type of security mechanism.
It actually was within my plans to make that support possible.

>> the passwords they are derived from.

I don't find this a realistic complaint.  You need to purchase
software from the people that support the modes you need to operate
in.  If your software doesn't offer support for direct input of
randomly generated keys then don't buy it until they do.  And, most
importantly, tell them that.  There seems to be an ever growing gap in
communication between the people that sell software of any kind and
the people that use it.

That being said, all of the items in this list do not adequately
describe one of the fundamental differences between USM and, actually,
all of the proposals: the separation between identity authentication
and message integrity authentication.  All of the solutions use a
independent key for message integrity authentication (SBSM included,
since I should talk mostly about that), which makes them all better in
this respect.  As far as authenticating a user, SBSM can use multiple
mechanisms for identifying a user in order to tie those message
integrity keys to a user.  Passwords are still possible if need be, as
are better forms of user authentication.  The SBSM draft is fairly
silent on which forms of authentication should be put into the
resulting WG draft since it was expected that the WG would likely be
making the decision as to which authentication mechanisms should be
used and which was the mandatory one (if one).

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

Again, which keys?  SBSM provides PFS for session keys.  It does not
provide a mechanism in the current draft to change the authentication
keys since that is dependent on the authentication mechanism used, and
it is not clear if the WG will or even should work on how to manage
existing security infrastructures (we're just trying to make use of
them first).

>> universally implemented.)

Again, if you require software that implements a known feature tell
that to your vendor...

However, SBSM allows for mechanisms other than symmetric keys to be
used for authentication which solves Eric's problem.  I'm assuming
here he means for user authentication and not message integrity, since
again he was unclear and they are not equal.  (though SBSM generates
session keys securely, so the answer will still be "supported").

>> in (security) non-viable ways.

I have no idea what this is trying to get at.  Well, thats not true, I
have about 100 ideas but I'm just not sure which one he means as the
question is too vague.

>> SNMP keys are unique to SNMP and are not integrated with any other
>> IETF protocol). Similarly, SNMPv3 cannot use any existing
>> authentication/authorization infrastructures already present in
>> that deployment (e.g., Kerberos, PKI, RADIUS, etc.).

Well, since that's the fundamental root of the WG, I'm sure they're
all going to claim this is solved ;-) SBSM certainly solves it.

It's interesting that this is last on Eric's list when it's first on
many other people's (it wouldn't be first or last on mine, but I
haven't ranked them).

I do find it interesting that the most common authentication
mechanism, according to the poll I took near the start of the WG,
showed that local accounts (read: passwords) were the most common form
of authentication in use out there.  Hence requirements #2 and #6 are
somewhat in conflict.

Note that if you only picked one form of authentication to support,
even the most popular (being local accounts), you'd only make a
fraction of the world happy.  I'm convinced that the results of this
WG will the most usable by the community at large if multiple
potential authentication systems are considered.  The question is what
is the right number so that you don't end up with everyone
implementing something different, and which should be mandatory to
ensure at least minimal interoperability.  That is a topic I'm hoping
the WG will hit at some point post initial direction decision.

-- 
Wes Hardaker
Sparta