Re: RADIUS/DTLS and RADIUS crypto-agility requirements
Alan DeKok <aland@nitros9.org> Tue, 17 July 2007 06:17 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 17 Jul 2007 06:19:04 +0000
Message-ID: <469C5EE1.4060407@nitros9.org>
Date: Tue, 17 Jul 2007 08:17:05 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
CC: radiusext@ops.ietf.org
Subject: Re: RADIUS/DTLS and RADIUS crypto-agility requirements
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Bernard Aboba wrote: > 4. Crypto-agility solutions MUST specify mandatory-to-implement > algorithms for each mechanism. > --> not specified in the -00 draft, but can be specified > easily, as is done with other protocols leveraging TLS. > > [BA] What TLS ciphersuites would be mandatory to implement? AES-CBC/SHA-1? That would be acceptable. > At IETF 68 we discussed potential attacks on "up-negotiation", > where an initial (non-DTLS) RADIUS packet is sent, then RADIUS/DTLS > is negotiated. If the RADIUS shared secret on the initial RADIUS > Request is cracked, then the attacker can create a bogus response that > would impersonate the RADIUS server, implying to the client that DTLS > is not supported. Thus, an unprotected session proceeds even though > a RADIUS/DTLS session would be possible. Both RADIUS and DTLS require at least 16 octets in a packet, and both include a "type" as the first octet, and a "length" field within the first 16 octets. For RADIUS implementations that don't use codes 20..23, there is no overlap between the two protocols. So the first octet could be used as a key to distinguish RADIUS / DTLS. A little extra sanity checking could check that the length field matched the length of the UDP data, to further help distinguish the protocols. This would have to be done only for the first packet from a NAS. After that, the existence of the DTLS session mandates that the packets must be DTLS. This method is already recommended in draft-fischl-sipping-media-dtls-03.txt. > As I recall, the solution to this was to use a separate port number > for RADIUS/DTLS, rather than up-negotiating. Is the idea to use > DNS SRV to determine if a given server supports DTLS or not, and if so, > does this imply a requirement for DNSSEC? A DNS SRV record would work, too. I'm not sure it requires DNSSEC. RFC 3588 (Diameter) permits TLS and SRV lookups, but doesn't mandate DNSSEC. If the NASes are configured with a root CA, then DNSSEC doesn't matter as much, because the NAS can validate the server certificate against its CA. > [BA] Does RADIUS/DTLS require a separate port for both conventional and > RFC 3576 RADIUS exchanges? It could use the same port for both. > "issues & fixes" already mandates state on the RADIUS server. When > RADIUS servers include EAP, they already maintain state for TLS sessions. > > [BA] What kind of state is required, and at what granularity? A flag that this particular NAS session is TLS, and TLS session state, per NAS. At the most: (src/dst ip + src/dst port + TLS session data) * Num_sessions 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/>
- Re: RADIUS/DTLS and RADIUS crypto-agility require… Alan DeKok
- RE: RADIUS/DTLS and RADIUS crypto-agility require… Bernard Aboba
- Re: RADIUS/DTLS and RADIUS crypto-agility require… Alan DeKok
- RADIUS/DTLS and RADIUS crypto-agility requirements Bernard Aboba