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