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: [email protected]
Website: http://www.tcs.com <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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
