[radext] #15: DTLS Comments

["radext issue tracker" <trac@tools.ietf.org>]

#15: DTLS Comments
-------------------------------------+--------------------------------------
 Reporter:  peterd@â                 |       Owner:  aland@â                  
     Type:  defect                   |      Status:  new                      
 Priority:  major                    |   Milestone:  milestone1               
Component:  RDTLS                    |     Version:  1.0                      
 Severity:  Candidate WG Document    |    Keywords:                           
-------------------------------------+--------------------------------------
 Date first submitted:  March 22, 2010
 Reference: http://ops.ietf.org/lists/radiusext/2010/msg00260.html

 Sec 8.1 -

 "The previous RADIUS practice of using shared secrets that are minor
    variations of words is NOT RECOMMENDED, as it would negate nearly all
    of the security of DTLS."


 I think any statements WRT secret key strength should to be generalized
 and take into account the properties of the underlying PSK suite as some
 systems may or may not be subject to offline attack.
 "Any shared
    secret used for RADIUS MUST NOT be used for DTLS.  Reusing a shared
    secret between RADIUS and DTLS would negate all of the benefits found
    by using DTLS."


 I wonder if a more general warning about the possibility of down-
 negotiation would be a better fit. I can see the same concept applying to
 administrative selection of cipher-suites.
 Sec 4.1.1 -

 "Where the RADIUS specifications require that a
    RADIUS packet received via the DTLS session is to be "silently
    discarded", the entry in the tracking table corresponding to that
    DTLS session MUST also be deleted, the DTLS session MUST be closed,
    and any TLS session resumption parameters for that session MUST be
    discarded."


 Why is this still done when DTLS is used for a transport? IIRC in the TCP
 mapped drafts this was done to mitigate possibility of loss of protocol
 synchronization - not possible WRT DTLS.

 My concern as with the TCP map is silently discarded messages can take
 down other unrelated exchanges. The inner RADIUS should speak up while the
 transport is being established if there is no intention on honoring the
 established channel.

 There is an additional concern in that DTLS closure messages have no
 retransmission timers and are not guaranteed to be delivered. When this
 occurs future messages will be discarded by the peers DTLS stack until the
 clients "lifetime" timer expires and the DTLS session is reestablished.
 Sec 4.2 -

 "RDTLS clients SHOULD NOT send both normal RADIUS and RDTLS packets
    from the same source socket."

 " and increases the potential for
    security breaches due to implementation issues."


 WRT security only it seems to me servers must know better if not
 explicitly forbidden whether this is done or not. Encouraging (change
 SHOULD NOT to MAY) can only shine light on the issue and force
 implementors to address appropriately.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/15>
radext <http://tools.ietf.org/radext/>


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