[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #23: Comments
#23: Comments
Comment(by bernard_aboba@â):
It is not clear to me what is meant by "MUST use the existing mechanisms".
RADIUS does not include a version field, nor is any negotiation mechanism
defined in any of the existing RADIUS RFCs. Recommend that this phrase be
deleted.
Also, there is a simple workaround to the issue of probing delays:
upgrade the responder (e.g. RADIUS server) first, so that a crypto-agile
request will always receive a response.
The proposed revision to Section 2 is as follows:
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.
Proposals MUST NOT introduce new capabilities negotiation features
into the RADIUS protocol and 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.
Acceptable solutions for determining the mechanisms to be used within
a request include manual configuration as well as backward compatible
negotiation techniques such as those described in Section 4.3.
Solutions for determining the mechanisms to be used in a response
include manual configuration and "advertise and select" mechanisms
(e.g. selection within the response from mechanisms advertised in a
request).
The proposed revision to Section 4.3 is as follows:
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).
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.
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, instead
utilizing mechanisms indicated in the response.
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.
Probing techniques can avoid the use of legacy algorithms between
crypto-agile implementations. An initial request can omit use of
legacy mechanisms, 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 mechanisms. Similarly, the responder
can assume that the requester supports crypto-agility and can
prohibit use of legacy mechanisms 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 mechanisms.
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. This can be addressed by upgrading the responders (e.g.
RADIUS servers) first.
--
----------------------------------+-----------------------------------------
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:4>
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/>