Subject: (radius) Shared secret questions

From: Brian Czako <[email-masked]>
Date: Tue, 22 Feb 2000 16:17:40 -0500

I have a few questions regarding shared secrets.
Hopefully, they haven't been discussed to death here.

1) Are shared secrets allowed to be updated dynamically, or
is it required to restart both client and server for the change to take
effect?

2) How have people resolved sync'ing up the client with the server in this
case?

3) Must a shared secret be consistent within a call or can it change
between, say, an
Accounting-Start and Accounting-Stop packet?

Non-shared secret questions
4) If a connection is lost to the RADIUS server and then later
re-established,
is there an Accounting-On packet required?

5) Should the "vendor length" value in vendor-specific attributes be
clarified to 
say that it includes the 2 bytes corresponding to the "vendor type" and
"vendor length" fields?

Thanks in advance,
Brian Czako

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "David Mitton" <[email-masked]>
Date: Wed, 23 Feb 2000 10:52:24 -0500

>is it required to restart both client and server for the change to take 

Most people/implementations assume that shared secrets are "long lived" and 
NOT changed in real-time.   Scanning RFC 2138, I do find [page 10] that the 
Request-Authenticator is supposed to be unique "over the lifetime of the 
secret".  But that's the only mention of time.

In any case the RFC says nothing about requirements to "restart" an 
implementation given a change.  In practice, some do, some don't.  Depends 
on their information update model.
If changes are made, it's usually done to debug and converge on the correct 
configuration, which is then typically left static.

>2) How have people resolved sync'ing up the client with the server in this 

I'd be interested to hear from anyone that has attempted intentional 
dynamic changes.

>between, say, an Accounting-Start and Accounting-Stop packet?

The RFC makes no requirements.

>re-established, is there an Accounting-On packet required?
Not specified. We (Bay/Xylo/Annex/5399) used to do that, and it ran into 
problems with multi-pathed proxies to the same central server.
We changed to only send Accounting-Ons at boot-up.

>clarified to say that it includes the 2 bytes corresponding to the "vendor 
>type" and "vendor length" fields?

I guess you could.  But all other attribute lengths work this way, so it's 
assumed.

>'unsubscribe ietf-radius' in the body of the message.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Carrier Packet Solutions, Preside             978-288-3030 FAX
Billerica, MA 01821                    [email-masked]

-