Re: draft-dekok-radext-dtls-02 comments

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> 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.

  Do you have suggested text?

> "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.

  Do you have suggested text?

  Also, an *explicit* note that secrets should not be re-used is
required, in my opinion.  This forbids one "obvious" class of
implementations, where there's only one secret for RADIUS && RDTLS.

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

  In DTLS, the crypto layer ensures that packets have not been modified.
 Therefore, the only time that packets are malformed is when the sender
has sent bad data.  When that happens, they should no longer be trusted
to do *anything*.

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

  A counter point is that systems not implementing RADIUS should not
talk to RADIUS servers.  It's not really appropriate to add negotiation
to RADIUS where implementations indicate whether or not they support RADIUS.

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

  Yes.  Too bad.  If someone can't be bothered to implement RADIUS
properly, their software won't work that well.

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

  Hmm... allowing potentially bad behavior to highlight the fact that
bad behavior needs fixing.  I'm not sure I agree with that.

  Another argument is that allowing this increases the server processing
requirements for *every* packet.  Instead of doing RADIUS / DTLS
detection on the first packet from a new socket, it has to be done for
*every* packet.  This increases the number of cases that have to be
examined for potential RADIUS / DTLS overlap.

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