Re: [core] OSCORE: Status Update on the C Implementation of an OSCORE Server

Göran Selander <goran.selander@ericsson.com> Fri, 14 December 2018 10:33 UTC

From: Göran Selander <goran.selander@ericsson.com>
To: Jaro Fietz <jaro.fietz@aisec.fraunhofer.de>, "core@ietf.org" <core@ietf.org>
CC: "'Christian M. Amsüss'" <christian@amsuess.com>, Francesca Palombini <francesca.palombini@ericsson.com>, "martin.striegel@aisec.fraunhofer.de" <martin.striegel@aisec.fraunhofer.de>, Stefan Hristozov <stefan.hristozov@aisec.fraunhofer.de>, "jaro.fietz@gmx.de" <jaro.fietz@gmx.de>
Thread-Topic: OSCORE: Status Update on the C Implementation of an OSCORE Server
Thread-Index: AQHUkvIR/OT3z7quJk6jkgnrIEBquKV+G9CA
Date: Fri, 14 Dec 2018 10:33:39 +0000
Message-ID: <6A66D31F-EC70-438E-8243-94FC5171863D@ericsson.com>
References: <bd95ea38-7425-13d6-a955-1e60a5bd0945@aisec.fraunhofer.de> <20181011110943.GE31858@hephaistos.amsuess.com> <bdb05cc8-7418-a65c-b4a1-6111e1467c13@aisec.fraunhofer.de> <3E80C9C0-E03A-4EAE-8CAD-8063DC93C1A5@ericsson.com> <2608c3f9-907f-6f22-2c9e-bef30f9c0ef3@aisec.fraunhofer.de> <53AFBD47-6D9D-47FA-82E5-F1C8F5DC6F1F@ericsson.com> <3f288e89-ea41-5da5-ddb1-f5eada5a39cc@aisec.fraunhofer.de>
In-Reply-To: <3f288e89-ea41-5da5-ddb1-f5eada5a39cc@aisec.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.13.0.181109
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6BA871C05BC5D740A53725D8DB0ABC72@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 412a9c0a-913e-4448-c949-08d661af9ca3
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 10:33:39.3883 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5352
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUiTcRjH+e09fJVWP6fmoyLUwD8SPMkaYWUYNTok+6OkxFz6ost5sJnl EUzNjqmlppRzXmRmas55pKYpWiSK4lFKWanpwIO0ovKmcnsX9N/neb7f54KHIQS1lD0jjYpl 5VESmZC2IPMDmq64UDetAt1Lyh1E7c13SFH7gpYQzU4k06KUah0SNS/1kKJ366VmPrS4Qv2R Fqs61yjxt+9B4rKyVd4p8pyFdygrk8axcrcDwRbhtS+rqJhR0dWq0mVaiTR7VcicAbwbhnRp hApZMAL8CoFmrMAULCG4PdZmZnAJcBkPtIuxBoHEWQQMD28gzpXHA934Q1MwhaByJZdnKKHx YZhUThnZGp+GhuwRymAicBMPFt+MGPtaYT/omF8mOZM/tG80II49IW9o2sgkdgJdim7TzzB8 fBCeFcq4YQUENGcVGfuY46Mwk6mnDYzwdljurTYOJrAtjOmLedylGMraBgiObWBu+jdlYBvs Bmm9d824/A7orligOXaE4eJ042WAR2nQD42aTB7Q/aSD4IQJGopTxylOOAl9ddkUJwwiaO3P MVU4w+LsCI9bLwhSapSmERGgmcxEWchT/d+26s1LCbwLtM/duLQYapQDZhzvhNz0z0bmY0vo ydeTJYiqRDYKVnExMszT05WVS0MUiugo1yg2tg5t/lFnw7p7M5qbOdSFMIOEW/hVyVaBAkoS p4iP7ELAEEJr/pm0zRQ/VBKfwMqjL8gvy1hFF3JgSKEtf0NgGSjAYZJYNoJlY1j5P5XHmNsr ke9Z/77HdvWdg97ahsTFBM38+dBtfrBn9FriUsGjCZf+xv0tf177fpA+/VS4ctz1fpKXX731 JVXQvox7asuVAN9VVVu19r1z5/Ufc7Llxhde5aJ44sTs263HmlBGy5dxp1/R3qkz0Q8kdWrp kVC71hDHJGERzffRl+asfU39eSv4hpBUhEs8nAm5QvIX6mRZrkMDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/QI0us6zUdYwMbLjbaOfcZVgFS5c>
Subject: Re: [core] OSCORE: Status Update on the C Implementation of an OSCORE Server
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2018 10:33:47 -0000

Hello Jaro,

Great news, thanks for sharing this! Please keep us updated on the progress.

Best regards,
Göran

On 2018-12-13, 15:42, "Jaro Fietz" <jaro.fietz@aisec.fraunhofer.de> wrote:

    Hey everyone,
    
    after I've received several follow-up mails about my minimal C 
    implementation of an OSCORE server on top of the embedded OS Zephyr, 
    I've decided to give everyone an update on my progress. I've implemented 
    a subset of the OSCORE Draft Version 14 in C, leaving out most optional 
    features. My implementation provides a minimal working OSCORE server for 
    an embedded board (in my case the 96 Boards BLE Nitrogen). It is based 
    on Zephyr as the underlying embedded operating system but should be 
    easily adaptable to other needs.
    
    The implementation is now finished feature wise. Key derivation was 
    tested against the Appendix C.1.2 testcase from the specification [1]. 
    Additionally, the server successfully responds to the OSCORE Test_1a [1] 
    (executed with aiocoap's plugtest script). I haven't performed other 
    tests, but this should be good enough to exchange simple encrypted messages.
    
    I'm currently in the works of open sourcing the project. I expect the 
    source code to be published on github mid to late January. I hope that 
    this will be quick enough for RIOT. I'll write to the ML once the source 
    code is available (or only to individual people in case this information 
    isn't relevant to the ML).
    
    BR,
    Jaro
    
    [1]: 
    https://tools.ietf.org/html/draft-ietf-core-object-security-14#appendix-C.1.2
    [2]: https://ericssonresearch.github.io/OSCOAP/test-spec5.html#test-1a
    
    On 11/26/18 3:18 PM, Göran Selander wrote:
    > Hi Jaro,
    >
    > Thanks for the update!
    >
    > I understand you can't promise anything here. The question I got was for a C-implementation which was not tailored for a particular constrained platform OS, like what exists for Contiki NG and Open WSN. For your information, the people I talked to at RIOT wants to start after the new year holidays, so anything available around that time would be very welcome.
    >
    > Thanks,
    > Göran
    >
    >
    > On 2018-11-26, 14:39, "Jaro Fietz" <jaro.fietz@aisec.fraunhofer.de> wrote:
    >
    >      Hello Göran,
    >      
    >      we are planning on open-sourcing the C implementation, I'm in the works
    >      of filling in the paperwork. Currently I'm in the bugfixing stage, so
    >      the code isn't functional quite yet. Once I have a minimal working
    >      example and we have the go-ahead for open-sourcing it, I'll let you
    >      know. I hope that it'll happen within the next month, but can't
    >      guarantee anything.
    >      
    >      BR,
    >      Jaro
    >      
    >      On 11/23/18 4:04 PM, Göran Selander wrote:
    >      > Hello Jaro,
    >      >
    >      > I'm curious about the continued story of one of the questions from Christian, below.
    >      >
    >      > On 2018-10-11, 14:42, "core on behalf of Jaro Fietz" <core-bounces@ietf.org on behalf of jaro.fietz@aisec.fraunhofer.de> wrote:
    >      >
    >      >      Hello Christian,
    >      >
    >      >      thanks for your quick answer, it clarified the second of my questions.
    >      >
    >      >      On 10/11/18 1:09 PM, Christian Amsüss wrote:
    >      >      > The expectation is that the shortest (zero-length) ID would be used in
    >      >      > cases wherever that's beneficial, eg. when a constrained device
    >      >      > primarily utilizes one context in which it is addressed as a server.
    >      >      This is an interesting optimization. I'm not too sure about the actual
    >      >      benefits though. To me this would only result in the constrained nodes
    >      >      being able to shave off a few bytes of allocation when constructing the
    >      >      response and saving their sender_id to persistent storage.
    >      >      > You briefly had me worried I got it wrong myself -- but the
    >      >      > left-trimming that's happenign is on the sequence numbers, not on the
    >      >      > sender IDs.
    >      >      Sorry, I must have skipped incorrectly over the tuple construction.
    >      >      Reading through it again, your code is, of course, correct :)
    >      >      > Slightly off topic: Would that happen to be a freely licensed
    >      >      > implementation? If so, I know of an embedded operating system project
    >      >      > that would love to hear about this.
    >      >      I'm implementing OSCORE on top of zephyr (not integrated into it) for an
    >      >      embedded board. Currently it isn't open source, but I asked my advisor,
    >      >      who'll forward the request to the supervisor.
    >      >      Judging from your github history I expect you ask for RIOT-OS? :)
    >      >
    >      > Have you decided about open source? I also got question from people working RIOT-OS __
    >      >
    >      > BR
    >      > Göran
    >      >
    >      >
    >      >
    >      >
    >      
    >      
    >

[core] OSCORE: Questions about Section 5.2 Jaro Fietz
Re: [core] OSCORE: Questions about Section 5.2 Christian Amsüss
Re: [core] OSCORE: Questions about Section 5.2 Jaro Fietz
Re: [core] OSCORE: Questions about Section 5.2 Christian Amsüss
Re: [core] OSCORE: Questions about Section 5.2 Francesca Palombini
[core] OSCORE: Status Update on the C Implementat… Jaro Fietz
Re: [core] OSCORE: Status Update on the C Impleme… Göran Selander