[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06â
#101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06â
Changes (by bernard_aboba@â):
* status: new => closed
* resolution: => fixed
Comment:
Proposed resolution is as follows:
In Section 2 change "MUST NOT introduce new capabilities negotiation
features" to "MUST NOT introduce generic new capabilities negotiation
features".
Change Section 4.3 to the following:
4.3. Backwards Compatibility
Solutions MUST demonstrate backward compatibility with existing
RADIUS implementations. That is, an implementation that supports
both crypto-agility and legacy mechanisms MUST be able to talk with
legacy RADIUS clients and servers (using the legacy mechanisms).
While backward compatibility is needed to ease the transition between
legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
only appropriate prior to the compromise of those mechanisms. After
legacy mechanisms have been compromised, secure algorithms MUST be
used, so that backward compatibility is no longer possible.
Since RADIUS is a request/response protocol, the ability to negotiate
cryptographic algorithms within a single RADIUS exchange is
inherently limited. Prior to receipt of a response, a requester will
not know what algorithms are supported by the responder. Therefore,
while a RADIUS request can provide a list of supported cryptographic
algorithms which can be selected for use within a response, prior to
the receipt of a response, the cryptographic algorithms utilized to
provide security services within an initial request will need to be
pre-determined.
In order to enable a request to be handled both by legacy as well as
crypto-agile implementations, a request can be secured with legacy
algorithms was well as with attributes providing security services
using more secure algorithms. This approach allows a RADIUS packet
to be processed by legacy implementations as well as by crypto-agile
implementations, and does not result in additional response delays.
If this technique is used, credentials used with legacy algorithms
MUST be cryptographically independent of the credentials used with
the more secure algorithms, so that compromise of the legacy
credentials does not result in compromise of the credentials used
with more secure algorithms.
In this approach to backward compatibility, legacy mechanisms are
initially used in requests sent between crypto-agile implementations.
However, if the responder indicates support for crypto-agility,
future requests can use more secure mechanisms. Note that if a
responder is upgraded and then subsequently needs to be downgraded
(e.g. due to bugs), this could result in requesters being unable to
communicate with the downgraded responder unless a mechanism is
provided to configure the requester to re-enable use of legacy
algorithms.
Probing techniques can be used to avoid the use of legacy algorithms
in requests sent between crypto-agile implementations. For example,
an initial request can omit use of legacy mechanisms. If a response
is received, then the recipient can be assumed to be crypto-agile and
future requests to that recipient can utilize secure mechanisms.
Similarly, the responder can assume that the requester supports
crypto-agility and can prohibit use of legacy mechanisms in future
requests. Note that if a requester is upgraded and then subsequently
needs to be downgraded (e.g. due to bugs), this could result in the
requester being unable to interpret responses, unless a mechanism is
provided to configure the responder to re-enable use of legacy
algorithms.
If a response is not received, in the absence of information
indicating responder support for crypto-agility (such as pre-
configuration or previous receipt of a crypto-agile response), a new
request can be composed utilizing legacy mechanisms.
Since legacy implementations not supporting crypto-agility will
silently discard requests not protected by legacy algorithms rather
than returning an error, repeated requests can be required to
distinguish lack of support for crypto-agility from packet loss or
other failure conditions. Therefore probing techniques can delay
initial communication between crypto-agile requesters and legacy
responders. This can be addressed by upgrading the responders (e.g.
RADIUS servers) first.
--
------------------------------------+---------------------------------------
Reporter: charliek@â | Owner:
Type: defect | Status: closed
Priority: minor | Milestone: milestone1
Component: Crypto-Agility | Version: 1.0
Severity: Submitted WG Document | Resolution: fixed
Keywords: |
------------------------------------+---------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/101#comment:1>
radext <http://tools.ietf.org/radext/>
--
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/>