Hi all,
I've recently started working in the IoT space and wish to standardize
our transport security by introducing the use of DTLS. It seems that the
usual practice is to use PSK for mutual authentication, but I'm not
happy with this solution. A breach of server security allows not only
server impersonation, but also, due to the PSK symmetry, client
impersonation.
We are already using static ECDH keys for authentication (at the
application layer), so I looked for a way to make use of these in DTLS
and came up with the following solution using (D)TLS 1.2:
Assume the client is provisioned with an Id, a corresponding private key
'c_id' and a corresponding server public key 'S_id' (the server key may
be different for each Id or it may be common across all clients); the
server has a list of client public keys 'C_id' and corresponding server
private key(s) 's_id'. This OOB pre-provisioning corresponds to that of
a symmetric PSK.
The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK
handshake as in RFC4279. This solution applies to both DH/DHE keys and
to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so
the following explanation focuses on the EC variant. The messages are:
Client Server
------ ------
ClientHello ----->
ServerHello
ServerKeyExchange
<----- ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished ----->
ChangeCipherSpec
<----- Finished
Application Data <----> Application Data
The way this differs from TLS_ECDHE_PSK is only in the generation of
the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A'
(public) from the server; and 'b' (private) and 'B' (public) from the
client. Then the client and server form the premaster secret in a struct
with the following information (where [x]Y represents multiplication of
the point 'Y' by the scalar 'x'):
Client Premaster: [b]A || [c_id]A || [b]S_id
Server Premaster: [a]B || [a]C_id || [s_id]B
The first term provides PFS even if both client and server static
private keys become known; the second term provides client
authentication even if server keys are compromised; and the third term
provides server authentication even if client keys are compromised.
My questions to the list are:
=============================
1. Has anything similar to this been proposed before (I found nothing)?
2. Can anyone see a problem with this formulation?
3. Is there any interest in this (I would be happy to write an ID)?
The reason that I advocate this for IoT devices over signature schemes
is that the code for ECDH will already have to be present if modern
key agreement methods with PFS are to be used. So this solution uses
fewer resources than ECDHE together with a signature scheme in terms of
code space and RAM, and improves execution speed (I believe ECDH is about
twice as fast as equivalent signature generation/checking). Also, fewer
messages are needed and the messages are smaller (even if using raw keys).
A constraint not made explicit above is that the (EC)DHE keys must use
the same group/curve parameters as define the preshared keypairs. Since
the ClientHello does not contain any client information, this means the
server endpoint (e.g. as defined by SNI) can only support a single form
of preshared keypair. This could be improved on in TLS 1.3.
I don't believe that this constraint is serious, because this method is
designed to be used in the same scenarios as PSK; that is, where client
and server have an OOB method of receiving authentication credentials
from a common source. In this situation, the server is unlikely to be
serving clients which use multiple types of preshared keypairs, though
it does mean that if the keypair format is changed (e.g. strengthened)
during the life of an IoT product then a new server endpoint will have
to be defined for the upgraded products.
Additionally, this method is proposed to prevent the leaking of client
credentials if the server is compromised. This means that the client
private key must be high-entropy: this method is not suitable for keys
derived from passwords or other low-entropy sources.
Lastly, I have had a look at extending this to TLS 1.3 and it seems
pretty straightforward; however, there is no urgency and I feel we can
defer that to after the TLS 1.3 draft has been approved.
Regards,
Tony
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
