|
> > I'm not sure what to provide for text for negotiation, because > > RADIUS does not support capability negotiation. > > Right. It comes down to the RADIUS client advertising what it can support, > by means of hint attributes included in the Access-Request packet, and the > RADIUS server picking at most one of the options. The term "offer/answer" model might make sense here. That is, the RADIUS client offers potential ciphersuites, and the RADIUS server answers by picking one. However, there is an issue of how to prevent bidding down attacks on the "offers". For example, what happens if the MD5 hash is cracked? In such a circumstance, MD5 couldn't be the only mechanism used to protect the "offer". Otherwise, an attacker recovering the MD5 key could then spoof an alternative offer, perhaps removing all offers other than MD5. It seems to me that the document needs to discuss this issue, as well as some of the transition assumptions/requirements. For example, one might assume that the RADIUS server is initially upgraded so as to support both MD5 as well as an improved ciphersuite. The RADIUS clients can then be upgraded to support the improved ciphersuite over time. In such an environment, the RADIUS server can be configured to REQUIRE the upgraded ciphersuite on those clients that support it (thereby avoiding the bidding down attack entirely). However, in very large deployments, it might be very difficult to maintain a list of which clients have been upgraded, and which haven't been. So the server might be configured to support both MD5 and an alternative for a transition period, before the new ciphersuite can be mandated. Alternatively, there might be some legacy RADIUS servers, so that upgraded clients cannot only support the new ciphersuite, but also need to continue to support MD5. In this scenario, do the clients include both the legacy MD5 support and the new ciphersuite attributes? Can legacy RADIUS servers be depended on to ignore the new attributes? |