[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Wednesday, October 15, 2008 7:04 PM
> To: David B. Nelson; radiusext@ops.ietf.org
> Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility
> Requirements for RADIUS"
>
> > > 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.
>
[Joe] Does this require a new "offer/answer" exchange? The client may
need to encrypt data in the request and it needs to authenticate the
request so it will have choose. The server can either reject or accept
this message. Its not clear that the client would know why the request
was rejected without new messaging.
> 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.
>
[Joe] It sounds like we are heading towards a full feature negotiation
mechanism.
> 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.
>
[Joe] Without a policy for which clients support only the legacy scheme,
I'm not sure how you can avoid the problem.
> 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?
>
[Joe] This might bad, for example do you really want to send your
password with weak encryption? This would eliminate the benefit of the
stronger encryption.
>
--
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/>