Subject: RE: [Isms] RE: Network management authorization

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 18 Jan 2005 09:56:37 -0500

Nice analogy!  :-)
 
It doesn't match the reality though. In reality when pre-shared keys are
used, the "fox" is authenticated to the "henhouse" by its knowledge of
the shared key. Now it shares something (another key, long-term - for
even with AAA in the end you just share a key) from which a subsequent
session key is generated. 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.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Tuesday, January 18, 2005 9:42 AM
To: 'Martin Soukup'; 'Joseph Salowey'; 'Bernard Aboba'
Cc: [email-masked]
Subject: RE: [Isms] RE: Network management authorization

So, you're suggesting having the entity to-be-authenticated serve as the
AAA-server when the regular AAA server is not accessible?
Isn't that like asking the fox to authenticate/authorize itself to the
henhouse when the farmer's not available?
 
dbh

________________________________

	From: Martin Soukup [mailto:[email-masked]] 
	Sent: Tuesday, January 18, 2005 9:25 AM
	To: 'Joseph Salowey'; 'Bernard Aboba'; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Isms] RE: Network management authorization

	> -----Original Message----- 
	> From: [email-masked]
[mailto:[email-masked]] On 
	> Behalf Of Joseph Salowey 
	> 
	> With EUSM we selected using EAP because of the integration
possibilities 
	> with back end AAA authentication mechanisms. 
	> 
	> We had envisioned two modes of operation: 
	> 
	> 1. When the SNMP Manager/Client is aware of the location of
the AAA server 
	> then it can establish keys with AAA server using RADIUS which
then can 
	> cache 
	> them and localize them for each agent as needed.  Here EAP is
encapsulated 
	> in RADIUS. 
	> 
	> 2. When the SNMP Manager/Client is not aware of the AAA or
there is no AAA 
	> server then the key negotiation would initiate between the
SNMP 
	> Manage/Client and SNMP Agent and would be proxied to AAA over
RADIUS if 
	> applicable.  We did not encapsulate EAP in SNMP since this
would be a big 
	> change to the SNMP protocol but instead choose to encapsulate
it in an out 
	> of band protocol to leverage existing work.  The protocols we
had in mind 
	> were existing protocols that carry EAP such as PANA/NACP(EAP
over UDP) or 
	> IKEv2, but other arrangements are possible. 
	> 
	> The second mode allows for operation without AAA. 

	So then the Manager (separately from "SNMP") acts as the AAA
server when an external/remote AAA server is unavailable or not
configured? I think this is a nice solution. I like the idea of
supporting USM as-is and providing something in addition to support AAA.

	Martin. 

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Jan 2005 11:39:57 -0800 (PST)

> If the manager knows the AAA key, there's

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.