Subject: [Ace] FW: New Version Notification for draft-selander-ace-object-security-00.txt

From: Göran Selander <[email-masked]>
Date: Mon, 27 Oct 2014 17:07:54 +0000

Hi all,

Although we are still collecting use cases, we would like in parallel to
start discussing object security for CoAP. We have submitted a new draft
on the topic.

The draft presents one method to integrity protect individual CoAP
requests and responses by including a JWS detached signature as a new CoAP
option (called the "JWS option"). This provides end-to-end security of
payload, request method and other data, e.g. in store-and-forward use
cases where DTLS is not sufficient.

As is noted in the JWS draft, a unique message identifier is required for
replay protection, and for this purpose we introduce sequence numbers in
the JOSE header of the JWS option. We elaborate on how this can work
together with proxy caching and CoAP Observe. This first version of our
draft is focusing on integrity protection, we plan to cover encryption in
later version. The JWS option can be used in conjunction with hop-by-hop
DTLS/TLS.

The draft may be interesting also in the of context of secure multicast,
securing CoAP over SMS, and  CoAP endpoint identification (cf. key
identifiers).

We would like to present this in the ACE slot in Hawaii.

Thanks,
Göran

On 27/10/14 17:34, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-selander-ace-object-security-00.txt
>has been successfully submitted by Ludwig Seitz and posted to the
>IETF repository.
>
>Name:		draft-selander-ace-object-security
>Revision:	00
>Title:		October 27, 2014
>Document date:	2014-10-27
>Group:		Individual Submission
>Pages:		26
>URL:            
>http://www.ietf.org/internet-drafts/draft-selander-ace-object-security-00.
>txt
>Status:         
>https://datatracker.ietf.org/doc/draft-selander-ace-object-security/
>Htmlized:       
>http://tools.ietf.org/html/draft-selander-ace-object-security-00
>
>
>Abstract:
>   We present a format for data object security in Constrained
>   Application Protocol CoAP, i.e. protection of individual request and
>   response messages between client and server.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 29 Oct 2014 21:10:52 +0530

Hi All,
Would just like to take this opportunity to share some progress we have 
made regarding object security based on CoAP.
During London meeting (IETF 89) we submitted a draft describing a work in 
progress on providing inherent capability in CoAP to mutually authenticate 
the endpoints and agreeing on a session key. At present the scheme is 
conceived for systems where provisioning pre-shared secret is possible. 
The session-key generated in the process can be used for object security 
for CoAP payloads.
The draft is available at: 
https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00. 
The work has also been published : 
http://dl.acm.org/citation.cfm?id=2523504
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6815204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6815204 

Recently we have extended the work and created a scheme which we name 
"LESS (Lightweight Establishment of Secure Session) on CoAP". The proposed 
scheme models the full exchange as just two pairs of CoAP request/response 
and generates the key-pair (server-write-key, client-write-key) similar to 
DTLS. The scheme uses AES-CCM-8 encryption algorithm as proposed in sepc. 
The generated key-pair can be used to exchange CoAP payloads in a secure 
manner.

Further, we take a cross-layer approach to provide optional channl seurity 
to the full application layer message (CoAP header + payload). The 
resultant of the session establishment process over CoAP is used to create 
the session tuple {server-write-key, client-write-key, server-IV, 
client-IV}. (Ofcourse, IV generation is not same as proposed in DTLS).The 
session tuple is used to populate a structure same as the DTLS-PSK session 
structure without any modification. Once that is done, the control 
switches to transport layer and uses same DTLS-record-encryption technique 
to provide channel security to the full CoAP message.

Unfortunately, we could not publish the work as a draft as the work is 
under review in an international conference though I am attending IETF91. 
We may submit the full work as a draft before the next meeting.
However, we are sharing some comparative results that we achieved over a 
controlled emulated WAN. The results show that LESS is quite lightweight.

It will be really great to hear whether our approach makes sense and, most 
importantly, whether the problem we are trying to address does have some 
relevance.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

From:   Göran Selander <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Cc:     Ludwig Seitz <[email-masked]>, John Mattsson 
<[email-masked]>
Date:   10/27/2014 10:38 PM
Subject:        [Ace] FW: New Version Notification for 
draft-selander-ace-object-security-00.txt
Sent by:        "Ace" <[email-masked]>

Hi all,

Thanks,
Göran

>until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you