[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #23: Comments
#23: Comments
Comment(by bernard_aboba@â):
It is proposed that we change the following text in Section 4.3:
Proposals MUST NOT introduce new capabilities negotation features
into the RADIUS protocol, but rather MUST use the existing
mechanisms. Included in such negotiation techniques are "hint and
accept" and "hint and reject" mechanisms, where the NAS (RADIUS
client) provides a list of supported algorithms and the RADIUS server
selects one.
To:
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 RADIUS 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
pre-configured.
Since legacy implementations not supporting crypto-agility will
silently discard requests not protected by legacy algorithms,
in the absence of knowledge about the capabilities of the
recipient, requests will need to be protected by legacy algorithms.
--
----------------------------------+-----------------------------------------
Reporter: glenzorn@â | Owner: bernard_aboba@â
Type: defect | Status: new
Priority: major | Milestone: milestone1
Component: Crypto-Agility | Version: 1.0
Severity: Active WG Document | Keywords:
----------------------------------+-----------------------------------------
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#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/>