Subject: RE: (radius) Shared secret questions

From: Brian Czako <[email-masked]>
Date: Thu, 24 Feb 2000 10:55:02 -0500

> > 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?
> 
> I believe this is implementation dependent and the RADIUS protocol doesn't
> speak to it.
> 
	Well, if this is implementation dependent, is it reasonable to do
the following:
	Provide a mechanism where both the old and new secrets are kept
around for a configurable period of time.
	If a password decryption or packet authentication fails within this
interval, the old secret is tried.

	The goal we're trying to reach is that no components need to ever be
brought down and no calls are lost.

	Also, just how often are shared secrets being changed?

	Thanks,
	Brian

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

---

From: Ran Atkinson <[email-masked]>
Date: Thu, 24 Feb 2000 11:16:29 -0500

% 
% > > 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?
% > 
% > I believe this is implementation dependent and the RADIUS protocol doesn't
% > speak to it.
% > 
% 	Well, if this is implementation dependent, is it reasonable to do
% the following:
% 	Provide a mechanism where both the old and new secrets are kept
% around for a configurable period of time.
% 	If a password decryption or packet authentication fails within this
% interval, the old secret is tried.

	You are trying to come up with a kind of simple key management
scheme.  While this is a fine goal, it is outside the scope of this
(soon to disappear) WG because the WG charter is limited to documenting
the existing deployed practice.

% 	The goal we're trying to reach is that no components need to ever be
% brought down and no calls are lost.
% 
% 	Also, just how often are shared secrets being changed?

	In practice, I've never heard of anyone ever changing
the "shared secret" anyplace once it was initially deployed.

	The RADIUS specifications are silent on how shared secrets
would ever be updated.  They don't prohibit it, but they also do
not specify how it is done.

Regards,

Ran
[email-masked]

NB: @Home doesn't actually use RADIUS for anything, so comments about
	observed use necessarily are based on data outside @Home.

-

---

From: Barry L James <[email-masked]>
Date: Thu, 24 Feb 2000 11:06:35 -0700 (MST)

Hey Brian,

> interval, the old secret is tried.

It seems to make sense to have some configurable value that would allow
you to keep your old password for a short period of time (like an ACE
server that still lets you login even if your token # changes while you're
waiting for authentication).  Or, maybe the client may send some semantic
value in an attribute that will allow the server to know which secret (or
permutation) was used with the packet.  Kind of like the serial number in
DNS; each change of secret increments this serial and the serial may be
passed in some attribute (maybe State) to the server.

Again, the RFC wouldn't necessarily specify how this would be
accomplished, but leaves the option open to the implementor.

> brought down and no calls are lost.

You're also getting into the realm of redundancy and high-availability
here.

> 	Also, just how often are shared secrets being changed?

Often enough that the change increases the expense of hijacking a session,
yet seldom enough that the computational complexity and expense of
managing numerous valid secrets doesn't adversely affect the operation of
your AAA infrastructure, I'd think.

Regards,
Barry

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

Barry L James            | Never doubt that a small group of
IP SWAT                  | thoughtful, committed citizens can
Level 3 Communications   | change the world.  Indeed, it's 
http://www.level3.com    | the only thing that ever has.
Member IEEE, AAAI        | #include <std_disclaimer>

-