[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements
Bernard_Aboba@hotmail.com wrote:
> This is a call for RADEXT WG mailing list consensus on this issue.
> Does the mailing list agree
> that Automated Key Management is not a requirement for a RADIUS
> Crypto-agility solution?
I agree Pointing to my response:
http://psg.com/lists/radiusext/2007/msg00911.html
> Some of the arguments made include:
>
> 1. While automated key management may prove convenient in some
> circumstances (e.g. EDUROAM),
> the demand is by no means universal, nor is the pain of the current
> manual keying environment considered
> acute by most customers.
Most commercial deployments of RADIUS interconnects are either
( N x N ) - where N is small, < 5
(N x 1 + 1 x M) - where N and M may each be > 30
i.e. full interconnects are usually small. Otherwise, intermediary
proxies are used to simplify the problem.
I think Eduroam is the only (N x N) deployment I've seen where N > 10.
Since Eduroam is using RadSec, I suspect that the N^2 issue could be
solved by leveraging a central Eduroam Certificate Authority. It would
issue, and sign, certificates for each participating institution or
country. Each particpant would then be responsible for using those
certs, and for validating the certs of Eduroam partners.
> 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
> a. RADIUS client-server communication is not an N^2 problem (except
> perhaps in the roaming
> situation where end-to-end protection is being provided).
Yes.
> b. One of the goals of RADIUS crypto-agility is to remove the use of
> stream ciphers.
> c. RADIUS traffic is generally light enough that a credible
> ciphersuite would not require rekey for a long time.
Yes.
Alan DeKok.
--
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/>