[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #23: Comments
#23: Comments
Comment(by bernard_aboba@â):
This still isn't quite right. While negotiation within a single RADIUS
request/response is limited, there are potential techniques that could be
utilized over multiple exchanges. Currently, the text doesn't describe
the limitations or lay out some of the possibilities, nor does it discuss
the implications for backwards compatibility for security or performance.
Suggested resolution is as follows:
Change Section 2 to the following:
2. A Working Definition of Crypto-Agility
A generalized definition of crypto-agility was offered up at the
RADEXT WG session during IETF-68. Crypto-Agility is the ability of a
protocol to adapt to evolving cryptography and security requirements.
This may include the provision of a modular mechanism to allow
cryptographic algorithms to be updated without substantial disruption
to fielded implementations. It may provide for the dynamic
negotiation and installation of cryptographic algorithms within
protocol implementations (think of Dynamic-Link Libraries (DLL)).
In the specific context of the RADIUS protocol and RADIUS
implementations, crypto-agility may be better defined as the ability
of RADIUS implementations to automatically negotiate cryptographic
algorithms for use in RADIUS exchanges, including the algorithms used
to integrity protect and authenticate RADIUS packets and to hide
RADIUS Attributes. This capability covers all RADIUS message types:
Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-
Request/Response, and Status-Server. Negotiation of cryptographic
algorithms MAY occur within the RADIUS protocol, or within a lower
layer such as the transport layer.
Since RADIUS is a request/response protocol, the ability to negotiate
cryptographic algorithms within a single RADIUS exchange is
inherently limited. While a RADIUS request can provide a list of
supported cryptographic algorithms which can selected for use within
a response, prior to the receipt of a response, the cryptographic
algorithms utilized to provide security services within the request
will need to be determined a-priori. Techniques that can be used for
negotiation over multiple request/response exchanges are described in
Section 4.3.
Change the third paragraph of Section 4.2 to the following:
Crypto-agility solutions MUST avoid security compromise, even in
situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little
or no security (e.g. in event of compromise of the legacy RADIUS
shared secret). Included in this would be protection against bidding
down attacks. In analyzing the resilience of a crypto-agility
solution, it can be assumed that RADIUS requesters and responders can
be configured to require the use of new secure algorithms in the
event of a compromise of existing cryptographic algorithms or the
legacy RADIUS shared secret.
Change Section 4.3 to the following:
4.3. Backwards Compatibility
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). Proposals MUST NOT introduce new capabilities
negotation features into the RADIUS protocol, but rather MUST use the
existing 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 algorithms have been compromised, secure algorithms MUST be
used, so that backward compatibility is no longer possible.
Acceptable solutions to determining which set of mechanisms is used
(with a particular peer) include some kind of negotiation, and manual
configuration. 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 as well as more secure algorithms.
While this approach permits the initial use of legacy algorithms
between crypto-agile implementations, if the responder indicates
support for crypto-agility, future requests can omit use of legacy
algorithms.
This approach minimizes the response delay from both legacy and
crypto-agile implementations. However, it is viable only where
legacy hidden attributes (e.g. User-Password) are not included within
requests, and where compromise of the legacy algorithm and RADIUS
shared secret does not compromise secure algorithms.
Probing techniques can be used to avoid the use of legacy algorithms
between crypto-agile implementations. An initial request can omit
use of legacy algorithms, and if a response is received, then the
recipient can be assumed to be crypto-agile and future requests to
that recipient can utilize secure algorithms. Similarly, the
responder can assume that the requester supports crypto-agility and
can prohibit use of legacy algorithms in future requests.
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 algorithms.
Since legacy implementations not supporting crypto-agility will
silently discard requests not protected by legacy algorithms rather
than returning an error, repeated requests may be required to
distinguish lack of support for crypto-agility from packet loss or
other failure conditions. As a result, probing techniques can delay
initial communication between crypto-agile requesters and legacy
responders.
Crypto-agility solutions SHOULD NOT require changes to the RADIUS
operational model as defined in "RADIUS Design Guidelines" [RFC6158]
Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on
the crypto-agility problem and nothing else. For example, proposals
SHOULD NOT require new attribute formats and SHOULD be compatible
with the guidance provided in [RFC6158] Section 2.3.
--
----------------------------------+-----------------------------------------
Reporter: glenzorn@â | Owner: bernard_aboba@â
Type: defect | Status: closed
Priority: major | Milestone: milestone1
Component: Crypto-Agility | Version: 1.0
Severity: Active WG Document | Resolution: fixed
Keywords: |
----------------------------------+-----------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/23#comment:3>
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/>