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

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Jan 2005 14:58:55 -0800 (PST)

There a number of ways that EAP could be used to secure SNMP, and they
have somewhat different implications:

a. EAP packets could be encapsulated within SNMP itself.
b. Keys derived from EAP could be used to secure SNMP.

Approach a) would appear to run afoul of the RFC 3748 Section
1.3 applicability statement:

"  EAP was designed for use in network access authentication, where IP
   layer connectivity may not be available.  Use of EAP for other
   purposes, such as bulk data transport, is NOT RECOMMENDED."

However, the applicability statement only applies to authentication
methods encapsulated within EAP; the same algorithms, if encapsulated
within SNMP itself, would not run afoul of the applicability statement.

It is also worth noting that the applicability statement does not apply to
RADIUS, so that RADIUS/EAP could be used between a RADIUS client and
server even if the protocol used to authenticate SNMP did not involve EAP.
As an example, there are IETF protocols that support CHAP authentication
(iSCSI is an example) and RADIUS is commonly used to centrally manage CHAP
authentication.

Approach b) is not in conflict with RFC 3748.  However, it would
introduce a link layer dependency into SNMP, since not all link layers
support EAP.  Typically link layer dependencies are to be discouraged,
since one of the goals of the TCP/IP protocol suite is to shield
applications from the link layer dependencies.

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Jan 2005 15:09:00 -0800 (PST)

I should add that there are other variations, such as:

c. An authentication algorithm could be encapsulated with SNMP,
   deriving keys to secure SNMP, with the key derivation mechanisms
   being borrowed from the EAP Key Management Framework.

This particular variation does not involve EAP authentication on the wire
at all, and so does not run afoul of RFC 3748.  It also does not imply a
link layer dependency, since the link layer is  not required to support
EAP.  All that happens in this variation is reuse of EAP key derivation
formulas, which presumably will be thoroughly reviewed.

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 12 Jan 2005 12:00:44 -0800

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. 

Joe

[email-masked] wrote:
> This particular variation does not involve EAP authentication
> on the wire at all, and so does not run afoul of RFC 3748.
> It also does not imply a link layer dependency, since the
> link layer is  not required to support EAP.  All that happens
> in this variation is reuse of EAP key derivation formulas,
> which presumably will be thoroughly reviewed.
> 
> 
>> There a number of ways that EAP could be used to secure SNMP, and
>> they have somewhat different implications:
>> 
>> "  EAP was designed for use in network access authentication, where
>>    IP layer connectivity may not be available.  Use of EAP for other
>> It is also worth noting that the applicability statement does not
>> apply to RADIUS, so that RADIUS/EAP could be used between a RADIUS
>> client and server even if the protocol used to authenticate SNMP did
>> not involve EAP. As an example, there are IETF protocols that
>> support CHAP authentication (iSCSI is an example) and RADIUS is
>> commonly used to centrally manage CHAP authentication.
>> 
>> introduce a link layer dependency into SNMP, since not all link
>> layers support EAP.  Typically link layer dependencies are to be
>> discouraged, since one of the goals of the TCP/IP protocol suite is
>> to shield applications from the link layer dependencies.
>> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Jan 2005 18:50:12 -0800 (PST)

> with back end AAA authentication mechanisms.

Integration with the AAA server is achievable regardless of whether the
protocol on the wire between the Manager and Agent is EAP.  For example,
an authentication method could be embedded within SNMP without EAP
encapsulation, and then the agent could encapsulate the authentication
method within AAA/EAP in talking to the AAA server.  Alternatively,
rather than speaking EAP/AAA, the AAA client could use new
AAA attributes could be defined to handle a particular authentication
method (as is being done for SIP Digest).  However, this approach is less
general.

> them and localize them for each agent as needed.  Here EAP is encapsulated

I guess you have decide whether the Manager/Client or Agent plays the role
of the AAA client.  Since there are typically only a few Managers and lots
of Agents, it might make sense for the Manager to act in the role of the
NAS, and the Agents to act as users requesting authentication.  That way
there are a lot fewer RADIUS shared secrets to distribute.

I guess that in this particular case, the NAS/Manager/Client might be
initiating a particular authentication method, rather than starting off
with an Identity exchange, but that can be handled within RFC 3579.

> Manager/Client and SNMP Agent and would be proxied to AAA over RADIUS if

As you say, you could use IKEv2 w/EAP to derive keys to protect SNMP via IPsec.
This would be somewhat unusual with Transport Mode (I think the EAP functionality
in IKEv2 was created for largely for use with tunnel mode), but it would
more or less work as you describe, with or without a AAA server.

Since EAP functionality is officially part of the IKEv2 spec, this
is like any other use of IKEv2/IPsec and doesn't run afoul of RFC 3748,
3579 or anything else, as far as I can tell.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Jan 2005 20:13:39 -0800

Hi -

> From: "Bernard Aboba" <[email-masked]>
> To: "Joseph Salowey" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 12, 2005 6:50 PM
> Subject: RE: [Isms] RE: Network management authorization
...
> there are a lot fewer RADIUS shared secrets to distribute.
...

"Managers" and "agents" are just particular combinations of applications
making use of an SNMP protocol engine.  Furthermore, "managers" and
"agents" frequently exist in many-to-very-many relationships, and "dual
role" systems abound.  Consequently, I suspect SNMP engines in
general would need to play the role of AAA client.  We went to a lot
of effort to get rid of the manager/agent dichotomy in SNMPv3.  Let's
not bring back that not-too-helpful distinction.

Randy

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 13 Jan 2005 10:30:10 -0800

Hi Bernard,

Please find my reply inline.

>method (as is being done for SIP Digest).  However, this approach is less

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.

>with an Identity exchange, but that can be handled within RFC 3579.

Actually the shared secret management for SNMPv3 agents should not
be a problem that most of SNMPv3 agents would have shared secrets
already setup for AAA for the CLI interface, since the proposal will
primarily allow customers to use existing infrastructure that is used
for CLI and other management protocols for SNMPv3 authentication.

regards,
   kaushik!

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Jan 2005 13:06:28 -0800 (PST)

> 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.

> for CLI and other management protocols for SNMPv3 authentication.

If you're not worried about this, then the agent could serve
as a AAA client, and the Manager would act as a user.  Of course then the
agents would need to receive and interpret AAA attributes.

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 13 Jan 2005 17:38:10 -0800

Hi Bernard,

>the provisioning problem we were trying to avoid here.

AAA attributes are never directly passed between the SNMP agent and manager.
The SNMP agent is a AAA client will need a shared secret, it would already have
a shared secret for CLI AAA.

The SNMP manager will negotiate the key with the AAA server either directly in
which case it would need a shared secret. In the other model, the key 
negotiation
would use EAP between the SNMP manager and agent, the agent will proxy the
request to AAA over RADIUS if applicable.  In most cases we are not 
requiring any
new credential provisioning since for thousands of agents, they already have a
shared secret.

The credential provisioning  problem that ISMS is trying to solve is 
actually with
provisioning of users and user credentials. The problem is that the current 
SNMPv3
USM specification requires that every agent has it's own user repository 
and there
is no way to integrate it with existing user/AAA infrastructure. This is 
clearly not
scale able and also does not integrate well in customer environments and 
has been
a significant barrier to deployment for SNMPv3.

>agents would need to receive and interpret AAA attributes.

That's pretty close to our proposal and agents are already AAA
clients since they process AAA attributes for CLIs.

regards,
   kaushik!

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 14 Jan 2005 09:37:10 -0800 (PST)

HI,

On Thu, 13 Jan 2005, Kaushik Narayan wrote:
...

> In the other model, the key negotiation
> request to AAA over RADIUS if applicable.  

In the -00 draft, I didn't see the details for this approach.
Did I miss them, or are they available in an update?

Regards,
/david t. perkins

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 14 Jan 2005 14:18:11 -0800

Hi David,

This is described in the -00 draft. Section 2 provides the description
and Figure 2 in the draft  illustrates  the flow.

regards,
   kaushik!

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 14 Jan 2005 15:50:46 -0800 (PST)

HI,

Yes, I know the -00 draft contained a diagram. But did
it include the DETAILS, that is, describe the contents of
the SNMP messages between a "manager" and "agent".
What info is in the messages, and what is the syntax
of the messages. I didn't see that in section 2,
or elsewhere in the document.

Regards,
/david t. perkins

---

From: Kaushik Narayan <[email-masked]>
Date: Sun, 16 Jan 2005 22:29:07 -0800

Hi David,

As stated previously the EUSM proposal attempts to minimize the changes to
SNMPv3.  The only change to the SNMPv3 packet is the introduction of a new
security mode.

The key negotiation uses Key_Setup protocol that runs out-of-band to the
SNMPv3 communication and keys derived from Key_Setup protocol are then
used to secure SNMPv3 communication.

regards,
   kaushik!

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 17 Jan 2005 08:34:53 -0800 (PST)

HI,

I'm confused by your answer. 
In section 2, there a is  paragraph that starts with...
"The second scheme described in the figure below is
similar to EAP exchanges used in 802.1x environments."
There is not enough detail present for me to understand
how this second scheme works.

Do you have plans for expanding this? Do you have any
other info, such as packet traces?

Also, how do you see the configuration setup in the manager
so that it would know that it shoudl use the second form?
How much additional code do you see in the manager and
agent to support the second form?

And to I correctly understand your description that a new,
yet to be defined, protocol is used?

Regards,
/david t. perkins

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 17 Jan 2005 12:42:39 -0800

Hi David,

>other info, such as packet traces?

The reason this has not been expanded since EAP exchanges
used by the Key_Setup_Protocol are captured in the RADIUS/EAP
specification  (RFC 3579) and we did not want to put redundant
information.

>agent to support the second form?

It would pretty straight-forward to drive the Key_Setup mode
via a configuration variable. Part of the code required for the
agent is already available (i.e. RADIUS/EAP code to talk
a RADIUS server), we need plug the code in to terminate
EAP transport protocol and there needs to code on the
manager to initiate EAP messages over the EAP transport
protocol.

We pretty much leverage existing implementation of EAP
message handling and the EAP methods.

>yet to be defined, protocol is used?

We are not trying to define a new protocol but rather re-use
an existing EAP transport protocol and there are several
options such PANA, IKEv2 etc.

Future work on the protocol in the Working Group will help
us identify the optimal EAP transport protocol choice.

regards,
   kaushik!