Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload
Rafa Marin Lopez <rafa@um.es> Wed, 14 October 2015 17:53 UTC
Return-Path: <rafa@um.es>
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 464741AD0B3; Wed, 14 Oct 2015 10:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Mjven3RLxWkH; Wed, 14 Oct 2015 10:53:55 -0700 (PDT)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79C1AD0AF; Wed, 14 Oct 2015 10:53:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id DF5244446; Wed, 14 Oct 2015 19:53:48 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FYf7klN4PVm7; Wed, 14 Oct 2015 19:53:48 +0200 (CEST)
Received: from inf-205-175.inf.um.es (inf-205-175.inf.um.es [155.54.205.175]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id D6848440E; Wed, 14 Oct 2015 19:53:46 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <OF8676C547.C1DA2D9E-ON65257EDD.00415177-65257EDD.00465A76@tcs.com>
Date: Wed, 14 Oct 2015 19:53:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9862DED4-7265-4D41-86D1-CF55F38BAA97@um.es>
References: <56162F1A.5020503@ackl.io> <DEC84E1F-F40D-48C2-8CBD-8262FADD45B2@um.es> <OF8676C547.C1DA2D9E-ON65257EDD.00415177-65257EDD.00465A76@tcs.com>
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/rb0bjbHTrMx6cTDoQGUFg_6hFHk>
Cc: 6tisch@ietf.org, ace@ietf.org, a@ackl.io, Rafa Marin Lopez <rafa@um.es>, dan.garcia@um.es
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: Wed, 14 Oct 2015 17:53:58 -0000
Hi Abhijan: > El 13 oct 2015, a las 14:48, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> 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: 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 > > > _______________________________________________ > 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 -------------------------------------------------------
- [6tisch] Optimizing EAP-over-CoAP payload Alexander Pelov
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Rafa Marin Lopez
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Carsten Bormann
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Abhijan Bhattacharyya
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Alexander Pelov
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Alexander Pelov
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Abhijan Bhattacharyya
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Rafa Marin Lopez
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Rafa Marin Lopez
- Re: [6tisch] [Ace] Optimizing EAP-over-CoAP paylo… Abhijan Bhattacharyya