Subject: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements

From: <[email-masked]>
Date: Thu, 6 Dec 2007 10:33:17 -0800

At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements. 

The consensus within the room was that Automated Key Management should not be added to the list
of Crypto-agility requirements. 

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? 

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. 

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).  
  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. 

So, does the WG agree with these arguments?  Please respond to the list even if you have no new arguments
to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Dec 2007 01:10:08 +0100

> that Automated Key Management is not a requirement for a RADIUS

  I agree  Pointing to my response:

http://psg.com/lists/radiusext/2007/msg00911.html

> manual keying environment considered

  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.

> situation where end-to-end protection is being provided). 

  Yes.

>   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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Fri, 7 Dec 2007 08:23:15 +0100

Hello,

>   I think Eduroam is the only (N x N) deployment I've seen where N > 10.

And even we are avoiding N^2 complexity at the moment with a tree structure: 
star topology with central proxy from institutions within a country, star 
topology of country proxies to root.

If you care enough: even with RadSec and peer resolution, we might still have 
proxies in between, for entirely non-technical reasons. Some countries want 
to reserve the right to filter attributes at a national level, so any 
resolution technique would be configured on their side to end up at the 
national TLD proxy, and be distributed onwards from there.

> certs, and for validating the certs of Eduroam partners.

That is exactly the plan. We are not quite there yet with full deployment, but 
on our way.

> > situation where end-to-end protection is being provided).

We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end 
security, which is where my wish to have auto key mgmt came from. The 
concrete use case we have is that some countries need the age of a user to 
determine if he's legally allowed to get unfiltered internet access.

This means we would need to transfer either birthday or at least age via 
RADIUS. This kind of user attribute can be easily tied to a concrete 
User-Name in most cases and is thus subject to law regulations regarding 
transmission and storage of personal data.

For the moment our only solution is to keep eduroam to higher ed and research 
only, where all eligible users can be expected to be over eighteen. We are 
currently working on a quite sophisticated out-of-band handshaking for such 
data (there are more examples than just age), but would be a lot happier if 
there was an easy in-band solution.

I agree though that our woes in that regard are pretty much unique.

Greetings,

Stefan

-- 
Stefan WINTER

RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu               Fax:      +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Dec 2007 09:02:11 +0100

Stefan Winter wrote:
>> [ certs ]

  That addresses some of my concerns about scalability.

> security, which is where my wish to have auto key mgmt came from.

  I think end-to-end security is outside of the scope of RADIUS.

  If hop-by-hop security is sufficient, then the requirements and
assertions can go into a vendor-specific dictionary.

  Alan DeKok.