From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: Crypto-agility requirements: Backward Compatibility (from Issue 303)
Date: Sun, 28 Jun 2009 14:04:56 -0700
In Issue 303, Pasi Eronen said:
"
Backward compatibility/negotiation:"
Section 4.3 says "Solutions to the problem MUST demonstrate backward
compatibility with existing RADIUS implementations. That is, a
crypto-agility solution needs to be able to send packets that a legacy
RADIUS client or server will receive and process successfully.
Similarly, a crypto-agility solution needs to be capable of receiving
and processing packets from a legacy RADIUS client or server."
The intent of this paragraph is probably right, but currently, it's
somewhat open to multiple interpretations. Would something like this
capture the intent?
"Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations. That is, an implementation that
supports both the crypto-agility solution and legacy mechanisms MUST
be able to talk with legacy RADIUS clients and servers (using the
legacy mechanisms). Acceptable solutions to determining which set of
mechanisms is used (with a particular peer) include some kind of
negotiation, and manual configuration."
Note that *not* meeting this requirement would actually be quite
difficult... if the intent of this paragraph was to require some kind
of negotiation (interpreted loosely -- anything more automatic than
manual configuration), the text should say so.
Join me |