Re: Reminder: automated key management is often required for new protocols

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
>>> If you have not already taken a look at RFC 4107 in the context of
>>> your working group, please do so.
> 
> So, all of the RADEXT WG members participating in the discussion of our
> Crypto-Agility work item now have some homework to do: read RFC 4107 and
> report back on how it applies to the proposed solutions we are considering.

  DTLS requires manual key management to distribute long-term session
keys.  These can be shared secrets for TLS-PSK methods, or certificates
for other TLS methods.

  Section 2.1:   As noted at the bottom of page 2 of RFC 4107, TLS
provides automated key management.  Therefore the requirements of
Section 2.1 are satisfied by DTLS.

  Section 2.2: The manual key management for long-term session keys
meets the last criteria in this section:

     The scale of each deployment is very limited.

  Ideally, each long-term key in DTLS is shared only between one server
and one client.  Each client-server pair shares a unique key, and those
keys are (ideally) not re-used across multiple client-server pairs.
There aren't many deployments that are smaller scale than two parties.

  Section 2.3: If certificates are used, the certificate generation
scheme will have to satisfy these criteria.  If shared secrets are used
for TLS-PSK, it gets a little harder to meet these criteria.  We could
avoid the problem by pushing the requirements back onto the admistrator
(i.e. You MUST use hard-to-guess shared secrets).  But that's not
particularly secure.

  Perhaps something like Paul Funk's proposal would help:

http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt

  We could say that for PSK methods, the PSK that is used in TLS MUST be
the output of the shared secret amplification, and not the original text
as entered by the administrator.  This method would be a step to
addressing the requirements of [RFC4107] Section 2.3.  At the minimum,
it would increase the attack cost by a fixed factor of (say) 1,000,000.

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