Subject: RE: Fwd: Re: [Isms] EUSM key localization details

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 9 Nov 2004 10:33:41 -0800

Balazs,

The key management problem is indeed an issue (i.e., SNMPv3 deployments
are often operationally insecure). However, the following is my list of
what I believe to be the problems with SNMP security (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

I want to encourage your thoughts about using Radius. However, I also
want to encourage Kerberos and PKI-based solutions since each of these
are viable enterprise-wide solutions. The fact that in my analysis PKI
solutions are the best alternative for our company's networks does not
mean that other companies wouldn't be better served by a Kerberos or
Radius solution. However, it does mean that I would like the ultimate
solution to be also able to support PKI.

--Eric

-----Original Message-----
From: Balazs Lengyel [mailto:[email-masked]] 
Sent: Monday, November 08, 2004 12:02 AM
To: [email-masked]
Subject: Re: Fwd: Re: [Isms] EUSM key localization details

Hello Kaushik,
An even more basic question: If the problem with SNMPv3 was only that it
is difficult to 
manage keys why don't we just let radius to assign the keys that the
real USM can use for a 
long time ? Then we could let it be the administrators job to decide if
he wants to change 
keys every 2 minutes or every two months.

Is it really  a design goal to push the administrators into using short
lived keys (60-180 
sec) ? Or in other words, do you see problems with setting the cache
period to 2 months ?

If Radius is unavailable why can't we just keep on using the last valid
EUSM keys in USM 
this way we might avoid the need to configure USM as a backup.

regards Balazs

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

---

From: "Tom Petch" <[email-masked]>
Date: Sun, 28 Nov 2004 22:33:54 +0100

David

Thanks for puting me right - I was mixing up several ideas in my
enthusiasm to get away from the terminology of agent and manager (which
I always see as a bit rigid).

Tom Petch
NW Networks

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>; "'Joseph Salowey'"
<[email-masked]>; <[email-masked]>
Sent: Friday, November 26, 2004 10:24 PM
Subject: RE: Fwd: [Isms] EUSM key localization details

> Hi Tom,
>
> Let mne respond to two threads within the current thread.
>
> 1) Distinguishing Entities
>
> I suggest the better choice of wording to distinguish the roles of two
> SNMPv3 entities is to discuss the application being used, per RFC3413.
> Is each role one of command generator, command responder, notification
> originator, notification receiver, proxy forwarder, or other
> yet-to-be-defined application role?
>
> We deliberately stopped using agent and manager after the SNMPv2 and
> its variations because too many entities do not fit the classic
> definition of agent or manager, and the need to keep security vitual
> databases on both the agent and receiver made it very complex to
> determine whether an emtity was operating in an agent or manager role.
>
> 2) Authoritative and the SNMPv3 Architecture
>
> The concept of an authoritative engine is part of the architecture
> described in RFC3411 and RFC3412; it is part of the
> generateRequestMsg(), processIncomingMsg(), generateResponseMsg() ASIs
> between the message-processing subsystem and the security subsystem.
> It is important to identify which virtual database should be used for
> the security credentials when processing an SNMP message.
>
> USM is the first concrete specification of how and when to utilize
> authoritative credentials, and the SNMPv3 message format is the first
> concrete specification of a message format which includes a
> securityEngineID. RFC3412 section 7 is devoted to SNMPv3-message
> processing (v3MP), and describes how the v3MP and potentially-multiple
> security models share the knowledge of which engine is authoritative.
> Another message processing model would be expected to pass the
> authoritative engine between subsystems.
>
> Different add-on message processing models and different add-on
> security models may impact which engine is authoritative, and no
> assumptions should be made that future usage will necessarily be
> consistent with the v3MP/USM usage. The use of authoritative is rather
> complex, and I recommend that it NOT be used to distinguish the
> functional roles of the entities. I recommend it only be used when
> discussing a specific security model's approach to authoritative.
>
> General note on ASIs:
>
> Note that RFC3411 and RFC3412 describe conceptual application service
> interfaces (ASIs), which are present only to make it easier to develop
> add-on modules, such as new security models. The ASIs of RFC3411 and
> RFC3412 identify the conceptual information that theoretically is
> necessary to share between architectural subsystems (and models of
> those subsystems). When a security model uses an authoritative engine,
> it shares the identity of the authoritative engine with the messaging
> processing subsystem in the architecture via the securityEngineID
> parameter of the relevant ASI.
>
> The SNMPv3 design team recommended that the conceptual information
> used within a subsystem's model SHOULD NOT be shared with other
> subsystems, unless necessary, in order to prevent creating
> dependencies between models of different subsystems, i.e. for "data
> hiding" reasons. The avoidance of inter-subsystem dependencies was
> very deliberately done to allow different models to advance in the
> standards track independently of each other.
>
> David Harrington
> [email-masked]
>
>
>
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tom Petch
> > Sent: Thursday, November 25, 2004 8:15 AM
> > To: Joseph Salowey; [email-masked]
> > Subject: Re: Fwd: [Isms] EUSM key localization details
> >
> > I wish you did not use the terms SNMP agent and SNMP manager;
> > I am never quite sure if that is what you mean, perhaps
> > because manager-manager communication has been an integral
> > part of network management for me for ages.
> >
> > I think SNMPv3 got it right in principle with authoritative
> > and non-authoratitive engines, but might have found better
> > words, easier to say, spell and type:-(
> >
> > I prefer client and server or in my own private jottings use
> > autheng and nautheng.
> >
> > Tom Petch
> > NW Networks
> > ----- Original Message -----
> > From: "Joseph Salowey" <[email-masked]>
> > To: "'Blumenthal, Uri'" <[email-masked]>; <[email-masked]>
> > Sent: Monday, November 15, 2004 7:20 PM
> > Subject: RE: Fwd: [Isms] EUSM key localization details
> >
> >
> > > Hi Uri,
> > >
> > > We should use existing EAP methods that generate keys, we
> > don't really
> > want
> > > to create special methods for SNMP.
> > >
> > > There are basically three parts to the proposal.
> > >
> > > 1. Authenticated Key setup between SNMP manager and key server
> > >
> > > This protocol should authenticate the user and the key server,
> > establish a
> > > strong key, and be flexible in mechanism.  We suggest using EAP in
> > RADIUS.
> > > The EAP framwework is useful because it integrates with AAA
> servers
> > for
> > > authentication. The EAP methods used should not be SNMP specific.
> > >
> > > 2. Communication of keys from key server to SNMP agent
> > >
> > > This requires secure transmission of the correct localized
> > SNMPv3 keys
> > from
> > > key server to agent.  If the key server is co-located with the
> agent
> > then
> > > this is a local API matter.  If the key server is remote from the
> > agent then
> > > you can gain the benefit that one key setup procedure can be used
> to
> > set up
> > > a key that can be the basis for security for many agents.
> > We suggest
> > using
> > > some extensions to RADIUS for this key transport.  It would also
> be
> > useful
> > > to communicate other parameters such as VACM information to
> > the agent
> > in
> > > this protocol as well.  RADIUS is useful since many entities
> > containing
> > > agents are RADIUS clients as well.
> > >
> > > 3. EUSM enhancement to SNMPv3 between agent and manager
> > >
> > > This is enhancements to SNMPv3 to support key material that is
> > established
> > > external to SNMP processing.  The main goal here was to keep
> changes
> > to
> > > SNMPv3 as minimal as possible.
> > >
> > > Joe
> > >
> > > [email-masked] wrote:
> > > >  Yes, AAA must receive the snmpEngineID in order to compute
> > > > localized key, and AAA should verify authorization. Re.
> > > > newtributes - a new EAP method is being defined anyway, right?
> > > >
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Joseph Salowey
> > > > Sent: Monday, November 15, 2004 11:50 AM
> > > > To: 'Randy Presuhn'; [email-masked]
> > > > Subject: RE: Fwd: [Isms] EUSM key localization details
> > > >
> > > >
> > > >
> > > > [email-masked] wrote:
> > > >> Hi -
> > > >>
> > > >>> From: "Kaushik Narayan" <[email-masked]>
> > > >>> To: "Wes Hardaker" <[email-masked]>
> > > >>> Cc: <[email-masked]>
> > > >>> Sent: Saturday, November 06, 2004 10:33 AM
> > > >>> Subject: Re: Fwd: [Isms] EUSM key localization details ...
> > > >>> This would mean that agents do-not need to acquire keys to
> serve
> > an
> > > >>> SNMPv3 engine ID discovery request and SNMP Managers
> > can discovery
> > > >>> engine IDs and bootstrap the AAA server.
> > > >> ...
> > > >>
> > > >> Which brings us back to my question at the start of this
> thread:
> > > >> how does the AAA server know *which* of the SNMP engine
> > IDs to use?
> > > >> The information described in the proposal as flowing in
> > > >> the RADIUS Key_Request   (Key (App ID),  Calling-Station-ID,
> > > >> User-Name) is not sufficient to map to a single engine ID,
> since
> > > >> there may be multiple SNMP engines in a single system.
> > > >>
> > > >
> > > > [Joe] Yes I think we need an attribute to contain the
> > SNMP Engine ID
> > > > making the request.  I'm not sure if we can use existing
> > attributes
> > > > to convey this information, we may need to create a new one.
> The
> > > > AAA server still should verify that the engine ID is
> > authorized to
> > > > the RADIUS client making the request.
> > > >
> > > >> Randy
> > > >>
> > > >>
> > > >>