Hi Panos,

I wonder what kind of devices you have in mind? On one hand, the devices are constrained enough not to have resources for generating cryptographic quality randomness. But they somehow have support for tamper-resistance identity protection? Is it cheaper to have tamper-resistance? And is it somehow more energy-efficient?

I understand that generating strong identities and storing them securely are different issues. But I would be interested to learn about IoT devices that have tamper-resistance storage but no possibility of generating cryptographic quality randomness. Also, what protocols do you think the devices would use for authenticating these identities?

--Mohit

On 05/15/2018 05:00 PM, Panos Kampanakis (pkampana) wrote:

Hi Mohit,

These priv/public keypairs+cert are provisioned and used on the endpoint as identity for authentication. If tamper-resistance is not supported on the endpoint, the keypairs could be reprovisioned more often than the traditional cert lifetime as the server-side key gen transaction does not incur significant workload to the endpoint itself.

Rgs,

Panos

*From:*Mohit Sethi [mailto:mohit.m.se...@ericsson.com]
*Sent:* Tuesday, May 15, 2018 1:37 AM
*To:* Panos Kampanakis (pkampana) <pkamp...@cisco.com>; Hannes Tschofenig <hannes.tschofe...@arm.com>; ace@ietf.org
*Subject:* Re: [Ace] EST over CoAP

Hi Panos,

How do you intend to use these server generated keys once they are provisioned onto the device?

--Mohit

On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:

    Hi Hannes,

    To address your question about server-side key gen, below is the
    explanation we have put in the draft already and will be in the
    next iteration
    /~~~~~~~~~~~~~/

    /   Constrained devices sometimes do not have the necessary
    hardware to/

    /   generate statistically random numbers for private keys and DTLS/

    /   ephemeral keys.  Past experience has shown that cheap endpoints/

    /   sometimes generate numbers which could allow someone to
    decrypt the/

    /   communication or guess the private key and impersonate as the
    device./

    /   Studies have shown that the same keys are generated by the
    same model/

    /   devices deployed on-line./

    //

    /   Additionally, random number key generation is costly, thus energy/

    /   draining. Even though the random numbers that constitute the/

    /   identity/cert do not get generated often, an endpoint may not
    want to/

    /   spend time and energy generating keypairs, and just ask for
    one from/

    /   the server./

    //

    /   In these scenarios, server-side key generation can be used.  The/

    /   client asks for the server or proxy to generate the private
    key and/

    /   the certificate which is transferred back to the client in the/

    /   server-side key generation response./
    /~~~~~~~~~~~~~/

    This is a need that we have heard from customers at Cisco.

    About the proxy-Registrar question, we already have made the
    change in the working copy of the draft as well. We no longer call
    this functionality proxying, but instead use the concept of the
    registrar that terminates the connection and establishes the next
    one.

    We didn’t add any new features in the doc after removing the BRSKI
    stuff.

    If you want an early preview to comment on, we can share the
    repository with you.

    Panos

    *From:* Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Hannes
    Tschofenig
    *Sent:* Monday, May 14, 2018 5:05 AM
    *To:* ace@ietf.org <mailto:ace@ietf.org>
    *Subject:* [Ace] EST over CoAP

    Hi all,

    At IETF#101 Peter presented a list of open issues with the EST
    over CoAP draft, see

    
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00

    -Operational parameter values

    -Server side key generation using simple multipart encoding

    -Explain trust relations for http/coap proxying

    I have challenged the usefulness of the server-side key generation
    during the meeting but in general I am curious where we are with
    the document. It would be great to get it finalized. It appears
    that we are adding new features and therefore will not be able to
    complete the work in any reasonable timeframe.

    So, do we have a plan for how to complete the document?

    Ciao

    Hannes

    IMPORTANT NOTICE: The contents of this email and any attachments
    are confidential and may also be privileged.. If you are not the
    intended recipient, please notify the sender immediately and do
    not disclose the contents to any other person, use it for any
    purpose, or store or copy the information in any medium. Thank you.




    _______________________________________________

    Ace mailing list

    Ace@ietf.org <mailto:Ace@ietf.org>

    https://www.ietf.org/mailman/listinfo/ace


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to