|
To clarify -- RADIUS has previously used MD5 as a stream cipher to protect attributes including passwords (User-Password, Tunnel-Password) and keys (keying attributes within RFC 2548). While the use of MD5 for integrity protection has a set of issues (e.g. collisions), the use of MD5 as a stream cipher brings up another set of issues, such as known plaintext attacks. Given this, the ability to negotiate alternative "hiding" mechanisms is considered an important part of RADIUS crypto-agility. However, this is logically separate from the need to provide end-to-end protection for key transport. So far, the need to solve the end-to-end key transport problem has not been part of RADIUS crypto-agility requirements. Should it be? Note that it is possible for a crypto-agility solution to solve the "hiding" problem without solving the end-to-end transport problem. With Diameter, it was clear that the IESG expected a solution to both problems -- ciphersuite negotiation (via TLS/IKE) as well as a mechanism for avoiding key disclosure to proxies (e.g. redirect). The current RADIUS crypto-agility requirements only appear to require solution to the former problem (ciphersuite negotiation), but not the latter (key disclosure). That said, there has been some discussion of how the current proposals (RADIUS crypto-agility and RADIUS/DTLS) could address the key disclosure problem. > From: hartmans-ietf@mit.edu > To: radext-chairs@tools.ietf.org; radiusext@ops.ietf.org > Date: Thu, 20 Dec 2007 22:44:10 -0500 > Subject: [ Comments on automated key management and crypto agility > > > > > It's my understanding that you are in the middle or have just finished > a consensus call regarding automated key management and radius crypto > agility. > > I gave the chairs some advice on this topic a while ago. It turns out > I completely failed to understand the question I was asked. > > > I assumed that the crypto agility work was intended to strengthen > radius's integrity protection and dependence on md5. > > However as I understand now, the scope of the work also includes a > real solution to the key transport problem. > > So I don't think the advice I gave the WG applies. > > I don't know if this changes any of your deliberations, but I just thought I'd write and let you know that I was confused. > > Here's my current understanding of the situation in this space. > > * RFC 3962 says that we should have a way so that people do not need > to expose keys to third parties (proxies). This is not mandatory to > use, but we need to have a solution for that problem. > > * Diameter has the redirect mechanism which handles this need in some > deployments. > > * Our protocols don't force you to use proxies, but there are a lot of > good reasons why you might want to do so. > > > * Hokey may need to have a solution to do key management that meets > the RFC 3962 requirements. > > * It may be the easiest place for hokey to solve its problem if it has > one is at the radius key transport level. > > * That doesn't inherently make it radext's problem to solve. We also > still haven't even figured out how much of this is hokey's problem. > > I'm trying to understand this all better and to try and figure out > what sort of consensus we want to build. |