Hi Rafa, > But I see you would require an additional exchange. I guess you are > thinking the communication among smart objects after the bootstrapping. Yes. Generating a temporary session key for each session between the objects.
Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: [email protected] Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ "Ace" <[email protected]> wrote on 10/14/2015 11:23:45 PM: > From: Rafa Marin Lopez <[email protected]> > To: Abhijan Bhattacharyya <[email protected]> > Cc: [email protected], [email protected], [email protected], Rafa Marin Lopez > <[email protected]>, [email protected] > Date: 10/14/2015 11:24 PM > Subject: Re: [Ace] Optimizing EAP-over-CoAP payload > Sent by: "Ace" <[email protected]> > > Hi Abhijan: > > > El 13 oct 2015, a las 14:48, Abhijan Bhattacharyya > <[email protected]> escribió: > > > > 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" . > > As you mention the bootstrapping can provide a symmetric key (we > call it COAP_AUTH_PSK) to protect CoAP messages with AUTH option. > But I see you would require an additional exchange. I guess you are > thinking the communication among smart objects after the bootstrapping. > > Best Regards. > > > > > 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: [email protected] > > Website: http://www.tcs.com > > ____________________________________________ > > Experience certainty. IT Services > > Business Solutions > > Consulting > > ____________________________________________ > > > > > > "Ace" <[email protected]> wrote on 10/13/2015 12:11:46 AM: > > > > > From: Rafa Marin Lopez <[email protected]> > > > To: Alexander Pelov <[email protected]> > > > Cc: [email protected], Dan Garcia <[email protected]>, Rafa Marin Lopez > > > <[email protected]>, [email protected] > > > Date: 10/13/2015 12:16 AM > > > Subject: Re: [Ace] Optimizing EAP-over-CoAP payload > > > Sent by: "Ace" <[email protected]> > > > > > > Dear Alexander: > > > > > > Thanks for your comments > > > > > > > El 8 oct 2015, a las 10:53, Alexander Pelov <[email protected]> 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 > > > > [email protected] > > > > 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: [email protected] > > > ------------------------------------------------------- > > > > > > > > > > > > > > > _______________________________________________ > > > Ace mailing list > > > [email protected] > > > 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 > > [email protected] > > 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: [email protected] > ------------------------------------------------------- > > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
