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

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: abhijan.bhattacharyya@tcs.com
> Website: http://www.tcs.com <http://www.tcs.com/>
> ____________________________________________
> Experience certainty.        IT Services
>        Business Solutions
>        Consulting
> ____________________________________________
>
>
> "Ace" <ace-bounces@ietf.org> wrote on 10/13/2015 12:11:46 AM:
>
> > From: Rafa Marin Lopez <rafa@um.es>
> > To: Alexander Pelov <a@ackl.io>
> > Cc: 6tisch@ietf.org, Dan Garcia <dan.garcia@um.es>, Rafa Marin Lopez
> > <rafa@um.es>, ace@ietf.org
> > Date: 10/13/2015 12:16 AM
> > Subject: Re: [Ace] Optimizing EAP-over-CoAP payload
> > Sent by: "Ace" <ace-bounces@ietf.org>
> >
> > Dear Alexander:
> >
> > Thanks for your comments
> >
> > > El 8 oct 2015, a las 10:53, Alexander Pelov <a@ackl.io> 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
> > > Ace@ietf.org
> > > 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: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
> > -------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________
> > Ace mailing list
> > Ace@ietf.org
> > 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
>