Subject: [6tisch] Optimizing EAP-over-CoAP payload

From: Alexander Pelov <[email-masked]>
Date: Thu, 8 Oct 2015 10:53:46 +0200

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?

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?

Best,
Alexander

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 12 Oct 2015 20:41:46 +0200

Dear Alexander:

Thanks for your comments 

> El 8 oct 2015, a las 10:53, Alexander Pelov <[email-masked]> 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:
> 
> 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-masked]
> 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-masked]
-------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Oct 2015 21:01:32 +0200

> 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 conside…

There is never a reason to discuss token values -- these are chosen by
the requester based on its needs, and there is never a reason for a
responder to question that choice.

Grüße, Carsten

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 13 Oct 2015 18:18:26 +0530

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-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

"Ace" <[email-masked]> wrote on 10/13/2015 12:11:46 AM:

> From: Rafa Marin Lopez <[email-masked]>
> To: Alexander Pelov <[email-masked]>
> Cc: [email-masked], Dan Garcia <[email-masked]>, Rafa Marin Lopez
> <[email-masked]>, [email-masked]
> Date: 10/13/2015 12:16 AM
> Subject: Re: [Ace] Optimizing EAP-over-CoAP payload
> Sent by: "Ace" <[email-masked]>
> 
> Dear Alexander:
> 
> Thanks for your comments 
> 
> > 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:
> > 
> > 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?
> 
> > 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?
> 
> 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
> > 

=====-----=====-----=====
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

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 14 Oct 2015 11:17:19 +0200

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 :
> 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" .
>
> https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00(Had 
> 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
> Website: http://www.tcs.com <http://www.tcs.com/>

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 14 Oct 2015 11:24:40 +0200

Hi Carsten,

yes, you are right about this! Thanks for pointing it out.

Indeed, the wording should be carefully selected, and I think in some 
(most?) cases the token can be zero-length. However, as you correctly 
state, this should not be a MUST. If the requester includes a token, 
then the responder must conform to the CoAP specification.

Best,
Alexander

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 14 Oct 2015 16:40:07 +0530

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

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

> From: Alexander Pelov <[email-masked]>
> To: Abhijan Bhattacharyya <[email-masked]>, Rafa 
> Marin Lopez <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Date: 10/14/2015 02:51 PM
> 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?

> 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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 14 Oct 2015 19:00:18 +0200

Hi Carsten:

Fully agree.

Thanks.

> El 12 oct 2015, a las 21:01, Carsten Bormann <[email-masked]> escribió:
> 
> Rafa Marin Lopez wrote:
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 14 Oct 2015 19:53:45 +0200

Hi Abhijan:

> El 13 oct 2015, a las 14:48, Abhijan Bhattacharyya <[email-masked]> 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

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 15 Oct 2015 08:26:09 +0530

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

"Ace" <[email-masked]> wrote on 10/14/2015 11:23:45 PM:

> To: Abhijan Bhattacharyya <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], Rafa Marin Lopez 
> <[email-masked]>, [email-masked]
> Date: 10/14/2015 11:24 PM
> > El 13 oct 2015, a las 14:48, Abhijan Bhattacharyya 
> <[email-masked]> escribió:
> > 
> > Hi Rafa, 
> 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.
> 
> >