Subject: Re: [Isms] Network management authorization

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 Jan 2005 12:50:44 -0800

>>>>> On Wed, 12 Jan 2005 15:41:41 -0500, "David B Harrington" <[email-masked]> said:

David> In my view (and not neceesarily in Juergen's), I think it might
David> be worthwhile to separate the message authentication from the
David> user identity autentication.

This is frequently done in situations like this.  The only thing you
have to make sure you do is cryptographically bind the message
authentication key with the identity authentication mechanism.
Without doing that, you end up with the MiM attacks that have been
discussed so widely in the last 2 years or so.

-- 
Wes Hardaker
Sparta

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 Jan 2005 12:53:18 -0800

>>>>> On Wed, 12 Jan 2005 15:50:53 -0500, "David B Harrington" <[email-masked]> said:

David> I think everybody is in agreement on that point.

I agree with your agreement on our agreement.

-- 
Wes Hardaker
Sparta

---

From: "Martin Soukup" <[email-masked]>
Date: Sun, 16 Jan 2005 09:26:30 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bernard Aboba
> > The primary motivation to use the existing model with EAP is since one
> of the
> > goals of the proposal was to retain most of the existing SNMPv3 packet
> > processing and not require additional attributes to be passed between
> the
> > SNMPv3 engines part of the new SNMPv3 security model to reduce the
> > churn to the thousands of agents.
> 
> AAA attributes are only passed from the AAA server to the AAA client, no?
> Since only the SNMP agent or manager would act as a AAA client, I'm not
> sure how AAA attributes end up on the wire between the agent and
> manager.  Since RADIUS requires a shared secret to be established between
> the RADIUS client and server, if the agent and manager could speak
> RADIUS, then that implies they have a shared secret.  I thought that was
> the provisioning problem we were trying to avoid here.

I believe we are trying to solve the problem of provisioning attributes "per
user". Solving the problem of provisioning connectivity of the client and
server is a separate issue IMO (which needs to be solved, but not here).

You raise a good point about the carrying of AAA attributes. Really, what
makes sense to me is that both parts of the SNMP communication are AAA
clients, and that the AAA exchanges provide information to each party that
allow their authenticated communication through the existing USM mechanism.
I think this is quite possible, but requires the definition of (possibly
various) mechanisms of AAA servers providing key information to these
parties. I also think it critical that the USM key authenticator not have
access to any of the user AAA information (e.g. credentials) but only the
SNMPv3 keys for a specific session.

Martin.

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 31 Jan 2005 10:50:13 -0500

Martin Soukup writes...

> Doesn't this just make sense? The big questions to me are: 
> 1. Can we agree on RADIUS EAP and can the extensions needed 
> be standardized 
> 2. How can generation, caching and timeout of keys best be 
> designed to provide PFS and minimize communication with a central 
> AAA
> (Host-specific access control is also interesting but out of 
> scope)

I understand that authorization considerations are currently out of
scope.  My opinion is that constraint was agreed upon because of the
desire to have a narrow focus and short schedule, to see if consensus
could really be achieved around authentication and key management.

There have been suggestions that we could have a BOF on authorization
issues.  I suspect that the better thing to do is to make rapid progress
on the existing charter issues, and then revise the charter to add
authorization.  IMHO, it would be a major mistake to standardize
AAA-based authentication and key management and not standardize
AAA-based authorization (access control).  The level of recent list
discussion indicates to me that there is a substantial community of
interest.

---

From: "Martin Soukup" <[email-masked]>
Date: Mon, 31 Jan 2005 11:02:41 -0500

I second that.

> Behalf Of Nelson, David
> Sent: January 31, 2005 10:50 AM
> To: [email-masked]
> Subject: RE: [Isms] RE: Network management authorization
> 
> Martin Soukup writes...
>

---

From: "Martin Soukup" <[email-masked]>
Date: Sun, 30 Jan 2005 16:41:29 -0500

Also note that EAP is used in 802.1x. The way that RADIUS is designed
suggesting extensions to its methods doesn't break it - it's made to be
customizable and extensible. The introduction of EAP and thus numerous
originally unintended authentication mechanisms are already supported, why
not another? Personally, I would argue that existing EAP mechanisms provide
for the exchange of key information and thus no significant extensions are
required. The only thing that doesn't fit within the existing protocols
AFAICT is the ability of a trusted 3rd party to request key information on
behalf of a client - this sounds more like the Liberty Federation standards,
but it is definitely useful in RADIUS itself.

Is it possible to define the EUSM concepts of layering key exchange within
existing protocols out-of-band and then supporting USM as-is? Is it possible
to agree on the approach and then debate which protocols can be reused for
it? And then the details?

It seems to me, to make sense to talk about the main architectural goals:
1. Use SNMPv3 and USM as-is (meaning provide key exchange through a
different mechanism, without modifying SNMPv3 - this should also work for
VACM but is outside of scope for this discussion)
2. The authenticator should provide key generation capabilities for the
authenticatee in the case that a central AAA is not available (system should
work a) without a central AAA b) with the central AAA unavailable) -
otherwise the authenticator must request key information for a user upon
session initiation
3. The generation of keys should be timed to provide for session time-outs
and things like this

Doesn't this just make sense? The big questions to me are:
1. Can we agree on RADIUS EAP and can the extensions needed be standardized
2. How can generation, caching and timeout of keys best be designed to
provide PFS and minimize communication with a central AAA

(Host-specific access control is also interesting but out of scope)

Martin.

> Sent: January 11, 2005 3:38 PM
> To: [email-masked]
> > (Of course, the fact
> > that Bernard Aboba claimms EUSM does things with RADIUS that are
> > forbidden by the RADIUS protocol doesn't help its case a lot.)
> 
> I'm not sure I remember that posting.  It may well have to do with the
> fact that RADIUS is not an authenticated key management service.  There
> are IDs proposing to add that kind of service to RADIUS.  They are
> currently considered out-of-scope of the RADEXT WG, because that WG's
> charter explicitly excludes new security methods for RADIUS.
> 
> Having said that, RADIUS, using EAP methods, has been used as the AAA
> system behind the authenticated key management system in IEEE 802.11i
> wireless LANs.
> 
> There has also been some discussion of changes to RADIUS to make it FIPS
> compliant (whatever that turns out to mean), and the RADEXT charter
> might be revised at some point when NIST has given definitive guidance
> on this subject, and sufficient progress has been made on WG
> deliverables and milestones, to warrant a charter revision.  Too soon to
> predict...
> 
> 
>

---

From: "Martin Soukup" <[email-masked]>
Date: Sun, 30 Jan 2005 20:13:06 -0500

I think it important to note that the same keys should not be used for
communication, authentication, or key exchange. What I mean by this is that
there should be three independent keys (assuming authPriv), meaning that if
a centralized AAA is used there are separate shared keys for each client of
the AAA.

Martin.

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: January 18, 2005 2:40 PM
> To: Blumenthal, Uri
> Cc: [email-masked]; Soukup, Martin [CAR:5K50:EXCH]; Joseph Salowey;
> [email-masked]
> > If the manager knows the AAA key, there's
> > nothing wrong in its overtaking the AAA role and generating session keys
> > + authorization.
> >
> > To summarize: details need to be worked out, but in general the approach
> > is OK.
> 
> In general, RADIUS clients are specifically authorized to act in that
> role.  A client cannot be configured to act as a RADIUS server merely
> because it has knowledge of a RADIUS shared secret.  For example, the
> shared secret is supposed to be different for each client-server pair.