[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #22: Review
#22: Review
Comment(by bernard_aboba@â):
It isn't clear to me how "Hint and Reject" techniques apply, since legacy
implementations will silently discard crypto-agile requests that don't
utilize legacy mechanisms, without sending an error-message. So the
reality is more like "Choose and Silent Discard". This can make it hard
for a requester to distinguish lack of support for crypto-agility from
packet loss or some other failure.
Unless a request utilizing "Hint and Accept" is protected by legacy
methods, a legacy implementation will silently discard it, this approach
is only possible if the responder is crypto-agile, and even then, it only
applies to the response, not the request, which needs to be protected by
mechanisms that are chosen apriori. Yet the document talks about the need
to protect all RADIUS messages, not just responses.
The reality is that in the absence of information about the capabilities
of the responder, the requester will need to make a decision on what
algorithms to use to protect the request. If legacy mechanisms are
included, then there will be potential consequences, regardless of what
other algorithms are used. So it is desirable to avoid use of legacy
algorithms between crypto-agile implementations. Also, information from
previous responses could be used to determine what mechanisms to use to
protect subsequent requests.
Since Section 4.3 is about backward compatibility, it needs to talk about
some of these issues, and put forward some potential approaches to solving
the problem that can address security issues in both requests and
responses.
The suggested resolution is to 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: jsalowey@â | 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/22#comment:2>
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/>