Hi Jim, the random value in the DTLS/TLS handshake needs to be random.
In the OAuth-ACE framework we assume some initial keying material provided to the device (for example using some commissioning tool or during manufacturing). That key is the long-term key. Generating further keys that are bound to access tokens is then something provided by the OAuth-ACE protocol and also there randomness is needed when deriving the keys (except for the PSK case at the moment where that key is generated on the server-side). Note that some ciphers in TLS also utilize ECDHE and therefore also need to generate those keys. Ciao Hannes PS: Assuming wall-time support is yet another challenge. It is easier to find micro-controllers with a hardware-based random number generator than it is to integrate time into the solution. On 06/09/2016 02:09 AM, Jim Schaad wrote: > The client random value does not need the same quality of randomness > that would be desired for a private key generation process – especially > a long term key. I would need to sit down and think about it, but it is > quite possible that a counter would work for the client random value. > The main thing you want with this is non-repeating so that the final > secret is always uniquely generated. There have been cases where time > has been part of this random value and I don’t believe that it makes the > final key any less secure. > > > > Jim > > > > > > *From:*Ace [mailto:[email protected]] *On Behalf Of *Samuel Erdtman > *Sent:* Monday, June 06, 2016 9:58 PM > *To:* Julien Vermillard <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [Ace] Constrained Environment PKI enrollment > > > > Okay so there needs to be some sort of random number generation for the > TLS-PSK handshake, I was not aware of that. (is the requirements on it > as rigor as for the key generation) > > The other reason I could think of that is kind of mentioned previously, > it is the "quality" of the generated key, in some deployments, FIPS > certified key generation is required and that could be easier to > guarantee server-side. > > But it might be that there are no absolute situations where server-side > key-generation but rather a design option. > > //Samuel > > > > > > On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard <[email protected] > <mailto:[email protected]>> wrote: > > Yes, but since you need some random numbers for doing a TLS-PSK > handshake (ClientHello random) why a TLS-PSK client should no be > able to generate ECDSA keys? > > > -- > Julien Vermillard > > > > On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman <[email protected] > <mailto:[email protected]>> wrote: > > Hi Julien, > > The first one that comes to mind would be where Pre-Shared-keys > are used i.e. symmetric keys. These keys could be factory keys > used only to setup the PKI-keys. > > If you look at EST the server generated keys is also recommended > to be wrapped in an extra layer of encryption in addition to the > transport layer security (DTLS/TLS). So if the transport layer > security is not absolute no keys should be leaked. > > > > //Samuel > > > > > > > On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard > <[email protected] <mailto:[email protected]>> wrote: > > Hi Samuel, > > I wonder in which scenario a RNG is safe enough for running > a DTLS stack but not good enough for generating a ECDSA key > couple? > > > -- > Julien Vermillard > > > > On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman > <[email protected] <mailto:[email protected]>> wrote: > > The company I previously worked for where looking into > adopting EST for this purpose, the benefit of EST > compared to cmp or scep was that it defined the process > for server side generated keys, which could be > beneficial if key generation would be to cumbersome for > the device or if you don't trust the device to generate > a "good" key. > > > > Maybe Shahid could give sold more updates since he was > helping us with this project > > > > On Thursday, 2 June 2016, Julien Vermillard > <[email protected] <mailto:[email protected]>> > wrote: > > Hi, > > In industrial or enterprise M2M/IoT application we > often use PSK for authentication, but more and more > user want to enroll the device on their public key > infrastructure like they does with some routers > using SCEP/CMP. > > I wonder if it was explored to enroll devices, and > renew certificates on PKI only using CoAP and not HTTP? > > > -- > Julien Vermillard > > > > > > > > > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
