There is no notion of "key refresh", in either DTLS or even TLS, which would be independent of the handshake. If you want to refresh your keys for some reason, then you do so by requiring a new handshake. Both client and server can trigger a new handshake at any time (the client does so by sending a
ClientHello, while the server sends an
There are two types of keys in TLS (and DTLS):
- The master secret is established through asymmetric cryptography (RSA, Diffie-Hellman) as part of a "full handshake".
- The actual encryption and MAC keys are produced from the master secret and the "random values" sent by client and server. When a client and server do an "abbreviated handshake", a previously shared "master secret" is reused, but new encryption/MAC keys are produced.
There is no intrinsic reason in TLS or DTLS which would force a new handshake, except possibly running out of distinct sequence numbers; but since that number is a 64-bit counter, running out does not actually happen in practice (by a very long shot). Any specific application may wish to do a "refresh" at any time, and can do so by triggering a new handshake (abbreviated or full: an abbreviated handshake occurs only if both client and server agree to it).
It must be noted that there are very few rational reasons for "refreshing" the keys. People who do the refresh actually do so for the sake of formal compliance to regulatory requirements whose basis has been lost in the mists of Time (usually remnants of procedures which were needed for security with cryptosystems from before the invention of the computer). The unspoken myth at work in those cases is an assumption that keys somehow degrade upon usage, like bearings for a wheel, and must be replaced on a regular basis. This myth is, well, a myth, but a strong one, which still powers many standards and "best practice" documents.
(The one rational reason I have seen for a "refresh" was not about refreshing at all; it was a TLS server used in a context where the client also has a certificate, whose private key was in a smart card. The server regularly forced a new full handshake to make sure that the smart card was still there.)