[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
[Joe] The proposal requires the use of new RADIUS attributes. All
other aspects of the RADIUS protocol can remain the same, so backward
compatibility is possible. However it is important to note that if
stronger that current security algorithms are required then backwards
compatibility is not possible.
[BA] Can you expand on this? Couldn't a RADIUS packet sent by a NAS include
both existing and new security attributes for backward compatibility?
6. 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.
[Joe] Depending upon the selection of the key the new protection can be
completely separate from the existing protection. The selection of the
key is currently a deployment choice.
[BA] If the existing RADIUS security mechanism is compromised, how does this
affect the security of the negotiation? For example, if both existing and
new attributes are sent, couldn't an attacker strip off the new attributes
and recalculate the Message-Authenticator attribute?
INTEROPERABILITY AND CHANGE CONTROL
7. Proposals MUST indicate a willingness to cede change control to the
IETF.
[Joe] Change control can be cede. An informational RFC may be published
to document existing implementations.
[BA] Do existing implementations use VSAs?
10. Proposals MUST include a Diameter compatibility section, although it
is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is exchanged
with Diameter.
[Joe] A Diameter compatibility section will need to be added.
[BA] In terms of processing wouldn't a RADIUS/Diameter gateway just strip
off the new attributes?
Or are changes to RFC 4072 implementations required?
--
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/>