Re: Thoughts on Requirements for RADIUS crypto-agility

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
>>   I am sure we will get clarification on the issues. :)
> 
> Can you suggest improved text?

  It's hard to come up with something that's clear, and at the same time
descriptive.  The issue isn't maintenance of state, as servers already
maintain caches of sent packets, SSL information for ongoing EAP
sessions, and "live/dead" status of home servers when proxying.

  Those kinds of state are acceptable, and I would guess that minor
additions to those kinds of state is acceptable, also.  e.g. additional
information per home server such as the RFC 3539 watchdog timer intervals.

...
  11. Crypto-agility solutions should not require fundamental changes to
the RADIUS operational model, such as the introduction of new commands,
and should require maintenance of minimal additional state on the RADIUS
server.
...

  e.g. TCP has send/recv windows for bytes.  We could add packet
send/recv windows to RADIUS, which would also serve to limit the number
of outstanding packets to a server, and help manage load.  That may be
acceptable amounts of state, even if it doesn't solve the replay problem.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>