Subject: [Isms] Clarifications about EUSM

From: Kaushik Narayan <[email-masked]>
Date: Tue, 22 Feb 2005 07:40:29 -0800

Hi All,

There have been some questions about the capability of EUSM
to support multiple authentication systems such as X.509
certificates, Kerberos, Local accounts etc. in addition to RADIUS.
We do not think that this is in conflict with the EUSM proposal
and EUSM -02 draft addresses this requirement and elaborates
on how these various authentication systems can be supported.
EUSM recommends using EAP and does not depend upon
RADIUS for its operation any more that EAP does.  The
authentication conversation could terminate on the SNMP engine
such as when EAP-TLS  is used with PKI, Kerberos or Local
credentials.

There was also a question about changes required to AAA protocols.
The current EUSM proposal specifies an optimization wherein a
single master session key can be used to derive session keys
for multiple authoritative SNMP engines which requires new functionality
in RADIUS,  but this is not out of line with proposals that have been
discussed in the IEEE for similar key distribution problems.  Actually,
if this optimization is not used then integration with RADIUS servers that
already support 802.11 should work with little or no modification.

regards,
   kaushik!

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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 23 Feb 2005 11:14:57 -0800

Kaushik,

Thank you for this good news. I hoped that EUSM wouldn't have problems
also supporting Kerberos and PKI-based authentication, but I needed you
to verify that. Thank you for having done so. This support makes your
proposal much more attractive to me. The final remaining point is to
better understand how you enhance SNMP session security. For example,
would it be possible for EUSM to leverage TLS (e.g., see
http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt)?

--Eric

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2005 7:40 AM
To: [email-masked]
Subject: [Isms] Clarifications about EUSM

Hi All,

There have been some questions about the capability of EUSM
to support multiple authentication systems such as X.509 certificates,
Kerberos, Local accounts etc. in addition to RADIUS. We do not think
that this is in conflict with the EUSM proposal and EUSM -02 draft
addresses this requirement and elaborates on how these various
authentication systems can be supported. EUSM recommends using EAP and
does not depend upon RADIUS for its operation any more that EAP does.
The authentication conversation could terminate on the SNMP engine such
as when EAP-TLS  is used with PKI, Kerberos or Local credentials.

There was also a question about changes required to AAA protocols. The
current EUSM proposal specifies an optimization wherein a single master
session key can be used to derive session keys for multiple
authoritative SNMP engines which requires new functionality in RADIUS,
but this is not out of line with proposals that have been discussed in
the IEEE for similar key distribution problems.  Actually, if this
optimization is not used then integration with RADIUS servers that
already support 802.11 should work with little or no modification.

regards,
   kaushik!

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 24 Feb 2005 15:11:13 -0500

Right now there's exactly one security model. If another model is
proposed - it will be two. "Few enough", IMHO.

If the current model (USM) doesn't satisfy the needs of a subset of the
users - why don't they design one that does? Define it, define its
relation to VACM [or if VACM doesn't fit their needs too - OACM (Other
Access Control Model)] and be done with it. SNMPv3 architecture has no
problem with such an approach. And if it turns out that this new model
is more popular than USM - the market will vote with money, and one
model will supersede the other.

A lot of protocols have negotiable choice of options, sub-protocols,
cipher suites, etc. It doesn't seem to hurt interoperability.

P.S. I noticed that I react strangely to terms like "more security",
"better security", "more better products"... 

-----Original Message-----
From: Robert Story [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 2:43 PM
To: Blumenthal, Uri
Cc: [email-masked]
Subject: Re: [Isms] Clarifications about EUSM

On Thu, 24 Feb 2005 09:20:18 -0500 Blumenthal, wrote:
BU> Others say that USM itself isn't secure enough for them, and other
BU> per-message protection mechanisms are necessary. These folks should
BU> design their own security model, utilizing whatever mechanisms they
BU> fancy (DTLS, for example) - and submit their drafts as additional
BU> security models for SNMPv3 (as v3 architecture allows multiple
security
BU> models). Within that model they're free to use any key management
BU> approach they like. But this work is out of scope for this WG, IMHO.

I think that this attitude is a bit extreme. For interoperability, the
fewer
security models the better.

The WG must produce something that is no less secure than USM, but that
doesn't
mean it can't produce something more secure. I agree that additional
per-message security shouldn't be the primary goal of the WG, but if a
proposal offers better security, I think it is perfectly reasonable to
take
that into consideration while comparing the proposals.

-- 
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>

You are lost in a twisty maze of little standards, all different.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 24 Feb 2005 17:14:33 -0800

Come on now, Uri. There is no reason why we can't satisfy both needs in
this one activity. Your final paragraph is completely disingenuous. I
believe that the whole purpose of this WG is to finally make SNMPv3
security "secure enough" for everybody. If we aren't doing this, then we
are wasting our time.

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 6:20 AM
To: [email-masked]
Subject: RE: [Isms] Clarifications about EUSM

There are two issues: (a) user and key management, and (b) providing
per-message security.

Some say that USM provides adequate per-message security (especially
with AES draft), and what's missing is convenient key management that's
tied to other existing infrastructure such as RADIUS or Kerberos.
Interests and requirements of those will be addressed by this WG,
hopefully to everybody's satisfaction.

Others say that USM itself isn't secure enough for them, and other
per-message protection mechanisms are necessary. These folks should
design their own security model, utilizing whatever mechanisms they
fancy (DTLS, for example) - and submit their drafts as additional
security models for SNMPv3 (as v3 architecture allows multiple security
models). Within that model they're free to use any key management
approach they like. But this work is out of scope for this WG, IMHO.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Fleischman, Eric
Sent: Wednesday, February 23, 2005 2:15 PM
To: Kaushik Narayan
Cc: [email-masked]
Subject: RE: [Isms] Clarifications about EUSM

Kaushik,

--Eric

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2005 7:40 AM
To: [email-masked]
Subject: [Isms] Clarifications about EUSM

Hi All,

regards,
   kaushik!

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 25 Feb 2005 08:46:17 -0500

Eric, we had this discussion before.

Security costs, both in performance degradation and administration.
"Secure enough" means different levels with different costs for
different people. For example, I don't want to be as secure as you want
to - and pay the cost that you'll pay for that.

This is why SNMPv3 from the beginning aimed at being modular and capable
of using several security models, possibly at the same time within the
same SNMP engine. The idea is - there's no "one sie fits all" solution.
There will always be Erics for who the existing model isn't "secure
enough", and then some other guys (name withheld to protect the guilty)
for who SHA-1 is too slow - so it must be MD5, otherwise he cannot use
message integrity; and then everything in between...

Other security models are encouraged, especially if there is market
demand for them. What's so difficult about this?! IMHO the one thing one
has to take care designing a new security model is clean integration
with SNMPv3 Access Control (VACM or other model if you care to create
one) - make sure all the necessary information is collected and passed
to it from your security model. And of course preserving the outer
message wrapper so that the protocol engine can pass it to the right
security model, would help. That's it! 

What I want out of this WG is an easy clean method to integrate with
other infrastructures, such that access to authorizing capabilities of
SNMPv3 is available and clean. A method that can be used by any security
model. 

-----Original Message-----

Kaushik,

--Eric

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2005 7:40 AM
To: [email-masked]
Subject: [Isms] Clarifications about EUSM

Hi All,

regards,
   kaushik!

---

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

Uri,

>From where I sit, there are two fundamental issues for this WG to agree
upon:

1) Are we trying to improve USM security in a manner that is as
transparent as possible to USM (e.g., create a USMv2) or are we creating
a configuration alternative to potentially replace USM, both of which
are possibilities anticipated by SNMPv3? 

2) If we are creating a security alternative to USM, then what are the
security requirements we are hoping to address? I have provided such a
list, as have others. We as a community need to articulate the official
ISMS list if we are to make progress.

I thought that the answer to the first question was that we were
creating an enhanced security model that needs not be compatible with
USM (i.e., it is a possible configuration replacement for USM). Is this
also how you see things?

Given my answer to the first question, it seems obvious to me that our
efforts need to address all of the perceived blemishes with USM such
that deployments will have three basic SNMP configuration alternatives
to choose between: (1) no SNMP security, (2) USM security, and (3) ISMS
security. If ISMS security doesn't address all of the perceived
blemishes with USM, then who-knows-how-many additional alternatives will
be proposed to USM, which would create churn/confusion, which would be
very bad for SNMP in general and an untenable situation for product
developers and end users in particular.

--Eric

---

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

> are possibilities anticipated by SNMPv3? 

IMHO, neither. We are trying to introduce a concept of "session" in SNMP
(something that was proposed approximately a decade ago and rejected
then as too expensive to manage by a dumb SNMP agent). Now we're back to
it, and we want it - for the benefits it offers, especially in ssecurity
area. Then utilizing session - create a relation between SNMP security
mechanisms and existing security infrastructure(s) such as RADIUS (or
Kerberos, or PKI).

This "session" concept automatically takes care of keying, both
long-term and session-wide (these now are dynamic, the mapping between
dynamic user name and VACM entry is created when session is established
and destroyed when the session is deleted, PFS becomes possible, etc),
and happens to improve security by giving clean separation between
long-term and traffic (session) keys.

We are not modifying USM - we're providing a "wrapper" for a security
model.

Like David H. said - we don't hear complaints that USM isn't secure
enough (except from you, and maybe Wes). USM was reviewed several times,
and found OK. What people do complain loudly about - is difficulty of
deployment, and lack of integration with their existing security
infrastructures. We're taking care of this (hopefully), by offering a
mechanism to integrate.

> USM (i.e., it is a possible configuration replacement for USM). Is
this

No this is not. We're addressing deployability issue, trying to change
as little as possible/practical.

IMHO, if somebody wants a different security model (with greater or
lesser security than USM) - all he has to do is design it. The two
requirements this new model should satisfy are:
 - integration with ACM (providing enough information for xACM to make
decisions);
 - using the SNMPv3 message wrapper (so the message can be handled to
the right security model).
It would be nice if the purpose/reasons for this new model were given,
but it is not required nor necessary.

And overall, there are gazillion ways to protect SNMP traffic. For
example, tunnel it through Ipsec pipe with user keying. It won't satisfy
the conditions I listed above - but it surely can work.

> If ISMS security doesn't address all of the perceived blemishes with
USM,

Perceived by who? Market doesn't seem to complain.

> then who-knows-how-many additional alternatives will

I'd like to see at least one alternative, that people would say "yea
this is what we want!"  So far, there isn't a crowd storming the gates
with cartloads of new security models.