Re: RADIUS/DTLS and RADIUS crypto-agility requirements
Alan DeKok <aland@nitros9.org> Tue, 17 July 2007 14:31 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 17 Jul 2007 14:32:42 +0000
Message-ID: <469CD2D5.6030301@nitros9.org>
Date: Tue, 17 Jul 2007 16:31:49 +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>, 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: >> This method is already recommended in >> draft-fischl-sipping-media-dtls-03.txt. > > [BA] This would allow a RADIUS server to automatically determine > whether a given NAS > supports RADIUS or RADIUS/DTLS, which would ease the configuration > effort considerably. > How do things work on the RADIUS client side? Does it attempt > RADIUS/DTLS first, and if > it gets no response after suitable timeout, drop back to RADIUS? Yes. > As you note, a > RADIUS/DTLS packet can be differentiated from RADIUS unless the client > or server > implements RADIUS resource management, so that a RADIUS server not > supporting > RADIUS/DTLS would silently discard the DTLS initiation packet. From > http://www.iana.org/assignments/radius-types: Yes. The low byte of the DTLS version and the high byte of the epoch overlap with the "length" field in RADIUS. From RFC 4347, the DTLS version number is 0xfeff, (though OpenSSL has DTLS1_VERSION = 0x0100 http://crypto.stanford.edu/~nagendra/projects/dtls/dtls-0.9.7g.patch) Also, the epoch and sequence_number fields in the initial DTLS packet are always zero. The only time there can be a confusion is when the server supports DTLS and resource management, and the client sends a RADIUS packet with ID that matches the current DTLS major version, length that matches the current DTLS minor version * 256, with the first 9 bytes of the authentication vector being (00 LL 00 00 00 00 00 00 00), where "LL" is the same as the high byte of the RADIUS length field. Since the DTLS minor version number is either 255 (or 0, depending on who you believe), a RADIUS server will see the RADIUS length field as either 0xff00, or 0x0000, neither of which are valid for RADIUS. For NASes that implement a proper CSPRNG, having that many zeros in the authentication vector will happen once per 2^128 packets. Add to that the coincidence factor that the second byte of the vector matches the length, and it's even less probable. I don't think we need to worry about confusing the packets. > [BA] Diameter doesn't require DNSSEC because either IPsec or TLS security is > required for Diameter; the only question is which one is used. That is > not the > case here - it is possible that no DTLS would be used (e.g. drop back to > normal > RADIUS). That enables a forged DNS RR to cause the negotiation to select > RADIUS when RADIUS/DTLS (or another more secure alternative) is available. Yes. SRV records are not part of this proposal, so I've ignored them here. If they are standardized, we should mandate that RADIUS clients MUST implement DTLS with certain cryptographic checks for any server found via SRV lookups. 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