RE: RADIUS/DTLS and RADIUS crypto-agility requirements

[Bernard Aboba <bernard_aboba@hotmail.com>]

Comments below. 

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

[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?  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:
21       Resource-Free-Request        [RFC3575]
22       Resource-Free-Response       [RFC3575]
23       Resource-Query-Request       [RFC3575]
24       Resource-Query-Response      [RFC3575]
25       Alternate-Resource-
         Reclaim-Request              [RFC3575]
> > 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] 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. 

> > [BA] Does RADIUS/DTLS require a separate port for both conventional and
> > RFC 3576 RADIUS exchanges?
> 
>   It could use the same port for both.

[BA] OK. 

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