Re: RADIUS/DTLS and RADIUS crypto-agility requirements

[Alan DeKok <aland@nitros9.org>]

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/>