[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #100: Gen-ART Review
#100: Gen-ART Review
Changes (by bernard_aboba@â):
* status: new => closed
* resolution: => fixed
Comment:
Proposed resolution is as follows:
- Change:
OLD: This memo,
when approved, reflects the consensus of the RADIUS Extensions
(RADEXT) Working Group of the IETF as to the features, properties and
limitations of the crypto-agility work item for RADIUS.
NEW: This memo describes the features, properties and
limitations of the crypto-agility solution for RADIUS.
- Introduction,second paragraph. In this situation, there has apparently
been some confusion about the history, so articulating the background is
important.
- Section 1.3 has been deleted.
- Section 2. First sentence has been deleted.
- Section 2, 4th paragraph. SHOULD NOT upgraded to MUST NOT.
- Section 4.2, 5th paragraph, 1st sentence. Change to: " Support for
encryption of individual RADIUS attributes is OPTIONAL
for solutions that provide encryption of entire RADIUS packets."
- Section 4.2, "Limit key scope" paragraph. Change to: Support
for end-to-end confidentiality of RADIUS attributes is OPTIONAL.
Change Section 4.3 to:
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.
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.
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.
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.
- Section 4.6. Change
OLD:
At the
IETF-70 meeting, and leading up to that meeting, the RADEXT WG
debated whether or not RFC 4107 would require a RADIUS Crypto-Agility
solution to feature Automated Key Management (AKM). The working
group determined that AKM was not inherently required for RADIUS
based on the following points:
NEW:
Consideration was given as to
whether or not RFC 4107 would require a RADIUS Crypto-Agility
solution to feature Automated Key Management (AKM). It was
determined that AKM was not inherently required for RADIUS based
on the following points:
Nits:
- Section 4.6, 1st paragraph after the bulleted list: Change .., the same
time, â -> â, at the same time,...
--
----------------------------------------+-----------------------------------
Reporter: mary.ietf.barnes@â | 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/100#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/>