RE: RADIUS/DTLS and RADIUS crypto-agility requirements

[Bernard Aboba <[e-mail]>]

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 NASsupports 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 ifit gets no response after suitable timeout, drop back to RADIUS?  As you note, aRADIUS/DTLS packet can be differentiated from RADIUS unless the client or serverimplements RADIUS resource management, so that a RADIUS server not supportingRADIUS/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 isrequired for Diameter; the only question is which one is used.  That is not thecase here - it is possible that no DTLS would be used (e.g. drop back to normalRADIUS).  That enables a forged DNS RR to cause the negotiation to selectRADIUS 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