draft-dekok-radext-dtls-02 comments

[Peter Deacon <peterd@iea-software.com>]

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.

regards,
Peter

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