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

From: Kaushik Narayan <[email-masked]>
Date: Fri, 05 Nov 2004 09:52:18 -0800

>
>Hi Balazs,
>
>Please find my reply inline.
>
>
>At 09:25 AM 11/5/2004, Balazs Lengyel wrote:
>>Hello Kausik,
>>Tanks for the answers.
>>- If Radius is unavailable we ought to use USM. But how is this USM 
>>configured ? Does it take the last valid EUSM key or are we back to 
>>normal USM configuration problems ?
>
>
>The expectation is that USM users are configured for backup. The SNMPv3
>agent will continue to use the cached keys until they expire, after expiration
>if the agent is unable to acquire keys from the AAA server (server is 
>down), the
>agent will fallback to USM. This is no different from configuration of 
>local users
>  for fallback for CLI access.
>
>>- Why is it advisable to have a new key for each transaction (90-180 
>>sec)? Is that not "too" secure a bit ? In my area we have quite a bit of 
>>SNMP traffic e.g. we can get performance measurements every 15 seconds. 
>>Asking for a fresh password every 180 sec in this case seems a bit overkill.
>
>
>That's the reason we have a configurable cache-key-time, typically
>configuration jobs, periodic inventory collection would have a time
>window of about 90-180 seconds. Periodic performance collection
>has a completely different characteristic and the key-cache-time
>might be configured to provide for larger window.
>
>regards,
>   kaushik!
>
>
>>Regards Balazs
>>
>>Kaushik Narayan wrote:
>>>Hi Balazs,
>>>Please find my reply inline.
>>>
>>>At 03:00 AM 11/5/2004, Balazs Lengyel wrote:
>>>
>>>>Hello All,
>>>>As a new outsider to this discussion I have some questions:
>>>>1) EUSM allows the SNMP agent/manager to cash the localized key for 
>>>>some time. How long ? When will it loose it's validity ?
>>>
>>>That has been described in the EUSM proposal. The key-cache-time will
>>>be signalled by the AAA server to the SNMP agents as part of the key
>>>distribution response.
>>>
>>>>2) If the localized key has to be requested again after every n-th SNMP 
>>>>transaction this means that every n-th UDP package will need
>>>>additional RADIUS traffic. How many additional packets/transactions 
>>>>does this mean ?
>>>
>>>The key-cache-time is a configurable parameter on the AAA server and
>>>administrators can configure the time window based on the typical
>>>patterns. It is advisable that this window be in the order of 90-180
>>>seconds since that this is the typical duration of job/operation.
>>>There aren't any fixed SNMP transactions in a session, it depends on
>>>the operation and the key-cache-time.
>>>
>>>
>>>>3) If the Radius server is unreachable is the SNMPv3 traffic according 
>>>>to EUASM dead ? Or ?
>>>
>>>That has been specified in the proposal as well, agents will use USM in
>>>case the AAA server is down.
>>>regards,
>>>   kaushik!
>>>
>>>
>>>>Balazs
>>>>
>>>>Randy Presuhn wrote:
>>>>
>>>>>Hi -
>>>>>Page16 of draft-kaushik-snmp-external-usm-00.txt describes
>>>>>how a RADIUS server will generate a localized key.  It says that the
>>>>>server will have to have been configured with the set of SNMP Engine
>>>>>IDs in use by the AAA server.  What isn't clear to me from the text is
>>>>>how the RADIUS server can know *which* of those SNMP Engine IDs
>>>>>to use in key localization.
>>>>>The RADIUS key request from the SNMPv3 agent carries the SNMP
>>>>>manager's IP address, (as the "Calling-Station-ID") and the user
>>>>>name (as the "User-Name"), but there's nothing for the agent's SNMP
>>>>>Engine ID.
>>>>>Randy
>>>>>
>>>>>_______________________________________________
>>>>>Isms mailing list
>>>>>[email-masked]
>>>>>https://www1.ietf.org/mailman/listinfo/isms
>>>>
>>>>
>>>>--
>>>>Balazs Lengyel                       Ericsson Hungary Ltd.
>>>>AXD Operational Suite (AOS)          OPM & System Manager
>>>>ECN: 831 7320                        Fax: +36 1 4377792
>>>>Tel: +36-1-437-7320     email: [email-masked]
>>>>
>>>>_______________________________________________
>>>>Isms mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/isms
>>
>>--
>>Balazs Lengyel                       Ericsson Hungary Ltd.
>>AXD Operational Suite (AOS)          OPM & System Manager
>>ECN: 831 7320                        Fax: +36 1 4377792
>>Tel: +36-1-437-7320     email: [email-masked]

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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 08 Nov 2004 09:01:34 +0100

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

Kaushik Narayan wrote:
>>> sec)? Is that not "too" secure a bit ? In my area we have quite a bit 
>>> of SNMP traffic e.g. we can get performance measurements every 15 
>>> seconds. Asking for a fresh password every 180 sec in this case seems 
>>> a bit overkill.
>>
>>
>>
>>>>> 2) If the localized key has to be requested again after every n-th 
>>>>> SNMP transaction this means that every n-th UDP package will need
>>>>> 3) If the Radius server is unreachable is the SNMPv3 traffic 
>>>>> according to EUASM dead ? Or ?
>>>>
>>>>

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 09 Nov 2004 11:41:58 -0800

Hi Balazs,

At 12:01 AM 11/8/2004, Balazs Lengyel wrote:
>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 ?

The problem with long lasting keys is that there isn't a scheme for revocation
described in Radius. The proposal does not try to limit the use of the key
lifetime to 60-180 seconds but definitely does not believe that the time should
be any where around 2 months given the inability for revocation.

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

The configuration of backup is required since other means of management
such as CLI require local accounts. I also believe that the way to handle the
fallback case is to make AAA services more available rather trying to define
schemes that involve caching keys for long durations.

regards,
   kaushik!

>>>>seconds. Asking for a fresh password every 180 sec in this case seems a 
>>>>bit overkill.
>>>
>>>
>>>