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

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Feb 2011 08:39:05 -0000

#67: RADIUS vs RDTLS disambiguation (TLS Alert)

 ''3.1 "As a result, protocol disambiguation is straightforward.  If the
 first byte of the packet has value 22, it is a DTLS packet, and is a DTLS
 connection initiation request.  Otherwise, it is a RADIUS"''

 {{{
 5.
 "
          P = receive_packet_from_network()
          D = lookup_dtls_session(T, P)

          if (D || client_supports_rdtls(P)) {
             R = process_dtls_packet(D, P)
             if (R) {
                process_radius_packet(R)
             }

          } else if (first_octet_of_packet_is_22(P)) {
             process_dtls_clienthello(P)

          } else {
             process_radius_packet(P)
          }"
 }}}

 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.

 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.

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  minor                    |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/67>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Feb 2011 10:43:50 +0100

>  someone can spoof a request with the intent to prematurely lock in the use

  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.

>  it may be sent by the client as part of its peer validation before the

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

  Alan DeKok.

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 21 Feb 2011 22:11:28 -0000

Changes (by bernard_aboba@…):

  * owner:  => aland@…

 Reporter:  peterd@…                 |       Owner:  aland@…                  

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/67#comment:1>
radext <http://tools.ietf.org/radext/>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 Feb 2011 15:23:15 +0100

>  someone can spoof a request with the intent to prematurely lock in the use

  Hmm... that's true.

>  it may be sent by the client as part of its peer validation before the

  I'll look into ways to avoid doing that.

  Alan DeKok.