Re: RADIUS/DTLS and RADIUS crypto-agility requirements

[Alan DeKok <aland@nitros9.org>]

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