Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload

[Abhijan Bhattacharyya <[e-mail]>]

Hi Alexander,

> Thanks for pointing your draft - very interesting work.
Thanks a lot.

> However, it seems to me that it solves only a subset of the problems
> at which EAP-over-CoAP is aimed.
You are right.
To be precise, the work I pointed out actually starts after the EAP. We 
tried a propose a very lightweight version of session-key establishment 
using CoAP assuming that the master keys have been previously configured 
(may be through EAP!). The idea is as follows:

The DTLS protocol can be separated into two parts in terms of 
functionality. First is secure session establishment and the next one is 
providing channel security with inherent reliability and replay 
protection. However, we think that the required exchanges in DTLS session 
establishment (I am only talking about symmetric system) may be bit heavy 
for really constrained networks with intermittent connectivity and 
bandwidth constraint. So, we propose to push the session establishment 
part to application layer (CoAP) and leverage the inherent "lightweight 
yet reliable" nature of CoAP (considering the CON mode). We believe, it is 
better to put more control to the application layer when you are dealing 
with constrained environment. The application layer session establishment 
mechanism over CoAP establishes a secure session which finally produces 
the same tuple as in DTLS session establishment ,i.e, <Server_write_key, 
Client_write_key, Server_IV, Client_IV>.

Then the responsibility is transferred to the transport layer and the 
channel security is provided using conventional DTLS-PSK record 
encryption. Thus it takes all the advantage of DTLS record encryption. The 
idea is to use the best of the worlds. CoAP's lightweight-ness coupled 
with record protection from DTLS. This was just an experimental work to 
solve some immediate problems at hand. However, if this kind of 
cross-layer approach makes sense then it may  spawn extended ideas.

 > ..... Maybe there could be some kind of cooperation .....
Its a good proposition. But we need to know if there is enough traction in 
the community for extending the work. May be we can discuss if we happen 
to meet in Yokohama.

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


"Ace" <[e-mail]> wrote on 10/14/2015 02:47:19 PM:

> From: Alexander Pelov <[e-mail]>
> To: Abhijan Bhattacharyya <[e-mail]>, Rafa 
> Marin Lopez <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail]
> Date: 10/14/2015 02:51 PM
> Subject: Re: [Ace] Optimizing EAP-over-CoAP payload
> Sent by: "Ace" <[e-mail]>
> 
> Hi Abhijan,
> 
> Thanks for pointing your draft - very interesting work.
> 
> However, it seems to me that it solves only a subset of the problems
> at which EAP-over-CoAP is aimed. Most notably, it is limited to a 
> specific authentication method (DTLS-PSK), whereas EAP is an 
> extensible framework. Maybe there could be some kind of cooperation 
> between the two, e.g. you could specify an EAP method like 
EAP-DTLS-PSK-short?
> 
> Best,
> Alexander
> 

> Le 13/10/2015 14:48, Abhijan Bhattacharyya a écrit :
> Hi Rafa, 
> The application layer driven approach is really interesting in the 
> constrained environment context. We had a similar approach for 
> secure session establishment (assuming that boot-strapping is 
> already done) which performs the session establishment in CoAP but 
> uses the DTLS encryption and header-structure for secure exchange of
> the application-layer message. Coincidentally we have also defined 
> an option called "Auth" . 
> 
> Here is the link to the draft: https://tools.ietf.org/html/draft-
> bhattacharyya-dice-less-on-coap-00 (Had an older work in progress: 
> https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00
> . But this one did not provide channel security). 
> I submitted this draft to dice, however, dice was not really the 
> place to discuss this. Our draft is due to expire in about 4 days. 
> 
> 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: [e-mail]
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
> 
> 
> "Ace" <[e-mail]> wrote on 10/13/2015 12:11:46 AM:
> 
> > From: Rafa Marin Lopez <[e-mail]> 
> > To: Alexander Pelov <[e-mail]> 
> > Cc: [e-mail], Dan Garcia <[e-mail]>, Rafa Marin Lopez
> > <[e-mail]>, [e-mail] 
> > Date: 10/13/2015 12:16 AM 
> > Subject: Re: [Ace] Optimizing EAP-over-CoAP payload 
> > Sent by: "Ace" <[e-mail]> 
> > 
> > Dear Alexander:
> > 
> > Thanks for your comments 
> > 
> > > El 8 oct 2015, a las 10:53, Alexander Pelov <[e-mail]> escribió:
> > > 
> > > Dear Rafa,
> > > 
> > > I've been reading the latest version of your draft ( draft-marin-
> > ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding
> > some of the payload options, which could be optimized even further:
> > > 
> > > 1) Use shorter name for the /auth resource
> > > 2) Mandate the use of zero-length CoAP token
> > > 
> > > The first, and the more simple one, is - would it be possible to 
> > change the name of the authentication resource from /auth to a 
> > shorter one (like /a)? Maybe it could be an option to change the 
> > name of this resource, based on the underlaying architecture, e.g. 
> > an RFC could mandate that in a specific network the resource could 
> > be named /a, whereas the default value could remain /auth?
> > 
> > [Rafa] I do not see any problem to shorten the resource name.
> > 
> > > 
> > > The second, which is a little bit more subtle. Tokens are used to 
> > match responses to requests, but during the authentication/
> > authorization phase a single peer (endpoint) would communicate with 
> > a single authenticator. Moreover, the communication happens in a 
> > serial fashion, and responses are piggybacked. This falls in the 
> > case when zero-length token is also advised by RFC7252. Do you think
> > that it would be appropriate to make the use of zero-length token 
> > mandatory for EAP-over-CoAP?
> > 
> > [Rafa] I guess you are referring to this text:  
> > 
> > "An empty token value is appropriate e.g., when
> >    no other tokens are in use to a destination, "or when requests are
> >    made serially per destination and receive piggybacked responses.”
> > 
> > I would say that using zero-length token is possible. What I am not 
> > sure is whether make it mandatory or not. I mean we could say that 
> > if the client sends a zero-length token the server can consider it 
> > OK as per the text above. If there is a non-zero length token value 
> > should be also fine.
> > 
> > What do you think?
> > 
> > Best Regards.
> > 
> > > 
> > > Best,
> > > Alexander
> > > 
> > > _______________________________________________
> > > Ace mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ace
> > 
> > -------------------------------------------------------
> > Rafael Marin Lopez, PhD
> > Dept. Information and Communications Engineering (DIIC)
> > Faculty of Computer Science-University of Murcia
> > 30100 Murcia - Spain
> > Telf: [phone] Fax: [phone] e-mail: [e-mail]
> > -------------------------------------------------------
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Ace mailing list
> > [e-mail]
> > 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
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace