[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [radext] RDTLS #67 (new): RADIUS vs RDTLS disambiguation (TLS Alert)



radext issue tracker wrote:
>  Until the TLS session is fully established you must be able to accept
>  normal RADIUS packets in the case where client_supports_rdtls is false or
>  someone can spoof a request with the intent to prematurely lock in the use
>  of DTLS.

  Yes.  My thoughts are that RADIUS packets received *during* DTLS
session initiation should cause the DTLS session to be discarded, but
*only* when:

 - src/dst ip/port are all the same as the DTLS session
 - RADIUS packet is signed correctly

  The idea is that sane clients will not send DTLS + RADIUS from the
same source IP/port.

>  In terms of the text this draft should also burn the alert ctype (21) as
>  it may be sent by the client as part of its peer validation before the
>  session is established.

  Only if the client is sending RADIUS and DTLS from the same source
IP/port.

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