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

Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> Tue, 13 October 2015 12:50 UTC

Return-Path: <prvs=72126694a=abhijan.bhattacharyya@tcs.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ED41B3025; Tue, 13 Oct 2015 05:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkP06pV7s9QL; Tue, 13 Oct 2015 05:50:10 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6115E1B3023; Tue, 13 Oct 2015 05:50:05 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ABAgC9+xxW/wQXEqxeg3puvhIBDYFaFwEJgnKCCn8CHIFgFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgQBAgECKAMCAgIlHwMGCAYLCBuICxWsMQEBAW+TXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSmqFP4RCMAoNBAcGgig7FB2BFAWHPYVRdYgThRmJWZZBg28fAQGCUQIdgVxphnEBAQE
X-IPAS-Result: A2ABAgC9+xxW/wQXEqxeg3puvhIBDYFaFwEJgnKCCn8CHIFgFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgQBAgECKAMCAgIlHwMGCAYLCBuICxWsMQEBAW+TXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSmqFP4RCMAoNBAcGgig7FB2BFAWHPYVRdYgThRmJWZZBg28fAQGCUQIdgVxphnEBAQE
X-IronPort-AV: E=Sophos;i="5.17,677,1437417000"; d="scan'208";a="12666699"
In-Reply-To: <DEC84E1F-F40D-48C2-8CBD-8262FADD45B2@um.es>
References: <56162F1A.5020503@ackl.io> <DEC84E1F-F40D-48C2-8CBD-8262FADD45B2@um.es>
To: Rafa Marin Lopez <rafa@um.es>
MIME-Version: 1.0
X-KeepSent: 8676C547:C1DA2D9E-65257EDD:00415177; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: <OF8676C547.C1DA2D9E-ON65257EDD.00415177-65257EDD.00465A76@tcs.com>
From: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
Date: Tue, 13 Oct 2015 18:18:26 +0530
X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June 07, 2015) at 10/13/2015 18:19:03, Serialize complete at 10/13/2015 18:19:03
Content-Type: multipart/alternative; boundary="=_alternative 00465A7265257EDD_="
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/bDsGB0NprrB2GHGw1SQ2tkKD2w8>
Cc: 6tisch@ietf.org, a@ackl.io, dan.garcia@um.es, ace@ietf.org
Subject: Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 12:50:13 -0000

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