From nobody Wed Nov 1 00:55:58 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0113F700 for ; Wed, 1 Nov 2017 00:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TC3jyx8Hu2hI for ; Wed, 1 Nov 2017 00:55:55 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530FE13F569 for ; Wed, 1 Nov 2017 00:55:55 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id EB4FE223DF6 for ; Wed, 1 Nov 2017 07:55:51 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 1 Nov 2017 08:55:52 +0100 To: References: <01a201d35259$c782ee50$5688caf0$@augustcellars.com> From: Ludwig Seitz Message-ID: <04909b5c-6e64-2543-c1ca-2b1f8da16650@ri.se> Date: Wed, 1 Nov 2017 08:55:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <01a201d35259$c782ee50$5688caf0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=NEAV23lmAAAA:8 a=QLPfpYkryAO4RqcpiSkA:9 a=QEXdDO2ut3YA:10 a=V2CapFxqm0gA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] CWT - Scope Claim X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 07:55:58 -0000 On 2017-10-31 16:06, Jim Schaad wrote: > I have an outstanding comment to the effect that I want a binary scope > value – specifically to allow for a CBOR encoded object – on the > framework document. Fixed in the editor's draft. Will submit an update soon. (See: https://github.com/ace-wg/ace-oauth/issues/122) /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Nov 1 01:02:32 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768F113F627 for ; Wed, 1 Nov 2017 01:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9FOKkCGKtfVO for ; Wed, 1 Nov 2017 01:02:29 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646DB13F580 for ; Wed, 1 Nov 2017 01:02:28 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id C8B52224041 for ; Wed, 1 Nov 2017 08:02:25 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 1 Nov 2017 09:02:26 +0100 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: <7f57f209-864d-7f94-04e6-5222c278f524@ri.se> Date: Wed, 1 Nov 2017 09:02:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=NEAV23lmAAAA:8 a=D9erhLJ4zLHjVISB0-AA:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] ACE github repos X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 08:02:31 -0000 Hello ACE, just a heads-up to tell you that thanks to Francesca we now have an ACE github organization here: https://github.com/ace-wg This contains the following drafts: draft-ietf-ace-dtls-authorize draft-ietf-ace-oauth-authz draft-ietf-ace-actors You can follow the editors' progress on these drafts (between submissions) through the "Editor's copy" links on the sub-pages, and also submit issues and pull requests. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Nov 1 05:05:58 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813C213F683 for ; Wed, 1 Nov 2017 05:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 qMajliozZK5H for ; Wed, 1 Nov 2017 05:05:54 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1EF13F63A for ; Wed, 1 Nov 2017 05:05:53 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id g6so1946714pgn.6 for ; Wed, 01 Nov 2017 05:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l7Im/MmRf+GDh4pwJPeeLkiAkSy3mFzBziYDeERM4qw=; b=F+Lt1BdDhJ1VxZXeLe+tHXBI1VUBSSI9W0vw6JJp6/h6Tu8hgp2GO5UmInFYLIIaKd InuHyrjUAwFo0mW83NXrGZdO61AxQmXYDUGoOfAavuG4DzdgaAgFAEIoksWyr7ioc1jR xPSAMLk7X3D7E+z7yBrNxX0jVDiicjhCs8DkzWu3lEbHxQYUD5UL6ND5/+4myQMqBfMV AlcHhfR4TGDaNL/ZwjAxxCAtX0geKPirPuxkQ2UpW4EumL294MpYjCPaIOB8vnX66yPi 7ZYn8Vepc/FVQ2alyNaLIFawSKAVT/XOru9oyRxCL8sYOOje/xTWGvWO1P522+U/9A8j 99Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l7Im/MmRf+GDh4pwJPeeLkiAkSy3mFzBziYDeERM4qw=; b=beZW2gxrUPRjflKlL6Nhg1XmifpMAATGKOsQy0LNiKFEquuXrtjpL0G0mqBj2y1Fck C5j1MuAsu0t1oyOewPpBXwy2I+uQtC14iAkq/jJmwHNSODUZVlEi9ugph0KZDocniVnz roUEQ32dlwg+hADR2iEuSqIIQnfjUxVdKrb/x+SOW2uOHZaFrakTP8BqBEyDlmXlDkok Fv5deBjaBNcngdPOWFshXoTn3/TF9DG5l8o5+sY5Cekau3RlHPTIOcyZZ4OwlVgHNOEA qwe9wXGKRRQ61yutXJtoLAo9l2/B6yKl2fa/mAajmuAT+aPOwCNM9tTM7k9bvFVuGULM ckMg== X-Gm-Message-State: AMCzsaXCZK/xc3RfREr8yz7AfONvAfH09mwe5I+GDvdU3Xdut02cMYVe TYaQcSgrzkuOBfrUDsohJMpsiYoEVKzj23UHTrEWIw== X-Google-Smtp-Source: ABhQp+S+O4FSinVeDYMzcGVbqNpDMWzig6KVRrHcgxjG+z2BM1JffBte4ZNsqjgR5SJ/ZJvmUskiEQyXxs69EBbClv4= X-Received: by 10.101.77.144 with SMTP id p16mr5958582pgq.226.1509537953419; Wed, 01 Nov 2017 05:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Wed, 1 Nov 2017 05:05:52 -0700 (PDT) In-Reply-To: References: <01a201d35259$c782ee50$5688caf0$@augustcellars.com> From: Samuel Erdtman Date: Wed, 1 Nov 2017 13:05:52 +0100 Message-ID: To: Mike Jones Cc: Hannes Tschofenig , Jim Schaad , "ace@ietf.org" Content-Type: multipart/alternative; boundary="089e082551ac7d27bc055ceab165" Archived-At: Subject: Re: [Ace] CWT - Scope Claim X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 12:05:56 -0000 --089e082551ac7d27bc055ceab165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 CWT should not add claims. I also created an issue to register the claim with JWT. On Tue, Oct 31, 2017 at 9:08 PM, Mike Jones wrote: > I agree that CWT shouldn't define claims beyond those that correspond to > the JWT claims. Other specs can do that via the registry established for > that purpose. > > -- Mike > ------------------------------ > *From:* Ace on behalf of Jim Schaad < > ietf@augustcellars.com> > *Sent:* Tuesday, October 31, 2017 8:06:04 AM > *To:* Hannes Tschofenig; 'Samuel Erdtman' > > *Cc:* ace@ietf.org > *Subject:* Re: [Ace] CWT - Scope Claim > > > I have an outstanding comment to the effect that I want a binary scope > value =E2=80=93 specifically to allow for a CBOR encoded object =E2=80=93= on the framework > document. > > > > In terms of defining it in this document rather than in the framework, my > first response would be =E2=80=98no=E2=80=99 only because this was design= ed to be a direct > copy of the JWT document and it was not defined there. Other than that I > would not care one way or the other. > > > > Jim > > > > > > *From:* Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hannes Tschofeni= g > *Sent:* Tuesday, October 31, 2017 2:58 AM > *To:* Samuel Erdtman > *Cc:* ace@ietf.org > *Subject:* Re: [Ace] CWT - Scope Claim > > > > Hi Samuel, > > > > You are correct that we should register it also with the JWT. > > > > Additionally, I wonder whether the string representation of the claim for > the CWT is the most efficient way to represent the scope. Shouldn=E2=80= =99t we > rather use CBOR capabilities here since we are trying to optimize 2 bytes > in other areas? > > > > Ciao > > Hannes > > > > *From:* Samuel Erdtman [mailto:samuel@erdtman.se ] > *Sent:* 31 October 2017 10:46 > *To:* Hannes Tschofenig > *Cc:* ace@ietf.org > *Subject:* Re: [Ace] CWT - Scope Claim > > > > The framework does register a CWT 'scoop' claim, but I think it has to > register it with JWT too to be correct. > > > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-8.5 > > > > //Samuel > > > > On Tue, Oct 31, 2017 at 10:28 AM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > I was wondering whether we should define a claim, scope, that captures th= e > scope that was granted by the authorization server. > > > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --089e082551ac7d27bc055ceab165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

CWT should not add claims.
I also created an issue to register the claim with JWT.

On Tue, Oct 31, 201= 7 at 9:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I agree that CWT shouldn't define claims beyond those that correspond t= o the JWT claims.=C2=A0 Other specs can do that via the registry establishe= d for that purpose.

-- Mike
From: = Ace <ace-bounc= es@ietf.org> on behalf of Jim Schaad <ietf@augustcellars.com>
Sent: Tuesday, October 31, 2017 8:06:04 AM
To: Hannes Tschofenig; 'Samuel Erdtman'
=C2=A0

I have an outstanding comment to the effect that I = want a binary scope value =E2=80=93 specifically to allow for a CBOR encode= d object =E2=80=93 on the framework document.

=C2=A0

In terms of defining it in this document rather tha= n in the framework, my first response would be =E2=80=98no=E2=80=99 only be= cause this was designed to be a direct copy of the JWT document and it was not defined there.=C2=A0 Other than that I would not care one w= ay or the other.

=C2=A0

Jim

=C2=A0

=C2=A0

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, October 31, 2017 2:58 AM
To: Samuel Erdtman <samuel@erdtman.se>
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

=C2=A0

Hi Samuel,

=C2=A0

You are correct that w= e should register it also with the JWT.

=C2=A0

Additionally, I wonder= whether the string representation of the claim for the CWT is the most eff= icient way to represent the scope. Shouldn=E2=80=99t we rather use CBOR capabilities here since we are trying to optimize 2 bytes = in other areas?

=C2=A0

Ciao

Hannes

=C2=A0

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: 31 October 2017 10:46
To: Hannes Tschofenig
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Scope Claim

=C2=A0

=C2=A0

On Tue, Oct 31, 2017 at 10:28 A= M, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

I was wondering whether we shou= ld define a claim, scope, that captures the scope that was granted by the a= uthorization server.

=C2=A0

Ciao

Hannes

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

=
_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace

=C2=A0

IMPORTANT NOTICE: The contents of th= is email and any attachments are confidential and may also be privileged. I= f you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other perso= n, use it for any purpose, or store or copy the information in any medium. = Thank you.


--089e082551ac7d27bc055ceab165-- From nobody Wed Nov 1 08:01:04 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7306F13F4FD for ; Wed, 1 Nov 2017 08:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 y_md6Surhc7s for ; Wed, 1 Nov 2017 08:01:01 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7338139680 for ; Wed, 1 Nov 2017 08:01:01 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id l24so2312748pgu.11 for ; Wed, 01 Nov 2017 08:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bT6gCCPiXOIyYTiSCFgUTIHSEATagAhTlqI3EKI32go=; b=aBW7AJd+6W+0ulKY3dd4nhqj89n8kTSkMAthnb/pUO1nkHGly1zamqjEb44MAjLBfi nCsQLNO25IaoKYAApIlsLByubjBTSeo5/lLsmRBp2PZZRAJaLREeGuJ85eMQ8VywlsPY OmEJqeJi657qkrGskoeCd10E+XGXfQu7jJkuxohE4/wHd1kpcaWLLohGqsz5WwfD/8UI HDhqcm4sRkMvzUr0nHOtoeX/gMeAm7EwTAhkGtPPkcUIw+XPSotkubM/2xBL/Qb+CLBW 0ltnAnRn2ZmhiV9dsi5doJ6K15R490TOO+0KVuRzE77QkUZPlpSGe4a20tVPAX6+t0YY GEjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bT6gCCPiXOIyYTiSCFgUTIHSEATagAhTlqI3EKI32go=; b=DfOeyFLF7skSMxY8RUmafDUDlrVp12NZt4eQdfkBViS1v4j9d4A4OI+np6gXWlLi21 S6hDWNMOWWP85bx6iDwNMLfsqVjkicthcSgYAym3EBnwJrtL0SLsOrZvBo5yAvSDKRcR 45LTNbAxNV2XwLkOAzGGqDRKzJdHY+0U1tysCntu/CkKNK4OdsEItUAyWAdv5y8s1Vya m4pkJHuSmsiEZ0VNTaXVmQQ8AbOIMxUSYzWn2k30YNObfBpA6nzxDM+YKZwLjmelydIy gqVHOpYbeaD7ROHIrXHWrczQI/gpYFezui6AFvDUtVBv5efumt2tH7yHppZXHiRmHGX4 8cxw== X-Gm-Message-State: AMCzsaUBgb6VV+aWOI1pYcdpTAsOv2r7EZ1ByDeEP1SHEdWk57niB/4h TzOXUHX95c08061Tky1NgNYey8MpV67Ijou5H9w= X-Google-Smtp-Source: ABhQp+Rx8jY0acNhlvBmP0QHgebz8Tnmz9XXTofQ0tRpvqgrEq996NMHkv6nNG4mYfUluelhixBfI9lHKkdrm9g1zRw= X-Received: by 10.98.33.15 with SMTP id h15mr125315pfh.319.1509548461060; Wed, 01 Nov 2017 08:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Wed, 1 Nov 2017 08:00:20 -0700 (PDT) In-Reply-To: <7f57f209-864d-7f94-04e6-5222c278f524@ri.se> References: <7f57f209-864d-7f94-04e6-5222c278f524@ri.se> From: Kathleen Moriarty Date: Wed, 1 Nov 2017 11:00:20 -0400 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ace] ACE github repos X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 15:01:03 -0000 Thank you, Francesca! On Wed, Nov 1, 2017 at 4:02 AM, Ludwig Seitz wrote: > Hello ACE, > > just a heads-up to tell you that thanks to Francesca we now have an ACE > github organization here: https://github.com/ace-wg > > This contains the following drafts: > > draft-ietf-ace-dtls-authorize > draft-ietf-ace-oauth-authz > draft-ietf-ace-actors > > > You can follow the editors' progress on these drafts (between submissions) > through the "Editor's copy" links on the sub-pages, and also submit issues > and pull requests. > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Best regards, Kathleen From nobody Wed Nov 1 10:25:05 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B5113F9BE for ; Wed, 1 Nov 2017 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zhxd67j6KSty for ; Wed, 1 Nov 2017 10:25:03 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E2113F8E2 for ; Wed, 1 Nov 2017 10:25:02 -0700 (PDT) X-AuditID: 12074423-6bfff70000004185-7c-59fa036c899e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C1.8B.16773.C630AF95; Wed, 1 Nov 2017 13:25:01 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id vA1HOxFB030758 for ; Wed, 1 Nov 2017 13:24:59 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA1HOuTg012544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Nov 2017 13:24:58 -0400 Date: Wed, 1 Nov 2017 12:24:56 -0500 From: Benjamin Kaduk To: ace@ietf.org Message-ID: <20171101172455.GT26855@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixCmqrZvL/CvS4P1rTovv33qYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0ffmOmPBCaaK7z+3sTYwTmLqYuTkkBAwkVi3vZu9i5GLQ0hg MZPEzZO72EASQgKHGSX2fmKFSDxnkjjT0QNUxcHBIqAi8ag3B6SGDchs6L7MDGKLCAhIzP34 mRmkRFhAT+LhSn4Qkxdo/sT9CiAVvAKCEidnPmEBsZkFtCRu/HvJBFLCLCAtsfwfB0hYVEBZ Ym/fIfYJjLyzkHTMQtIxC6FjASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJN jKAQYndR3sH4ss/7EKMAB6MSD++Lyz8ihVgTy4orcw8xSnIwKYnyat7/GSnEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhPfcGaAcb0piZVVqUT5MSpqDRUmcd1vQrkghgfTEktTs1NSC1CKYrAwH h5IE7x6mX5FCgkWp6akVaZk5JQhpJg5OkOE8QMOVQGp4iwsSc4sz0yHypxiNOW48vP6HiePZ zNcNzEIsefl5qVLivHsZgUoFQEozSvPgpoHSgET2/ppXjOJAzwnzHgUZyANMIXDzXgGtYgJa 5SXxA2RVSSJCSqqB0eb+giO/lp2RP+P23rh2vpkaj+InRj+9t1yrjC5v5nsg0SuaaHX2E89D mfAnJccaTFWnPm2aqeRxJUJp4aIeoyituZ2O8txZ1qFZnArpoZe2BKYZFlp+THGaYbQqYYbq 2vNCy35dZhQKX7J2tvHZtHB1r6WNSfaTr09XuMV8YpXWuQh1HcNaJZbijERDLeai4kQAi40m mt4CAAA= Archived-At: Subject: [Ace] WGLC on draft-ietf-ace-cbor-web-token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:25:04 -0000 This message begins a working group last call for draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, ending at 23:59 PST on Wednesday 29 November, 2017. The current (-09) version of the document is available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . Thanks, Ben and Jim From nobody Wed Nov 1 10:26:24 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CFB13F99C for ; Wed, 1 Nov 2017 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 f1KCBhLQAKSz for ; Wed, 1 Nov 2017 10:26:21 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEF913F9EE for ; Wed, 1 Nov 2017 10:26:20 -0700 (PDT) X-AuditID: 1209190f-8d7ff70000005074-4d-59fa03bbb74a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 66.6C.20596.BB30AF95; Wed, 1 Nov 2017 13:26:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id vA1HQGhj007881 for ; Wed, 1 Nov 2017 13:26:17 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA1HQDxm013080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Nov 2017 13:26:15 -0400 Date: Wed, 1 Nov 2017 12:26:13 -0500 From: Benjamin Kaduk To: ace@ietf.org Message-ID: <20171101172612.GU26855@kduck.kaduk.org> References: <20171101172455.GT26855@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101172455.GT26855@kduck.kaduk.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUixG6nrruH+Vekwad3rBbfv/UwOzB6LFny kymAMYrLJiU1J7MstUjfLoEro+PSWeaCmywV245YNDC+Zu5i5OSQEDCR+LD8DWsXIxeHkMBi JolfR5eyQDiHGSW2nF/ODuE8Z5JoW/6bFaSFRUBFYuvuY4wgNhuQ3dB9GWyUiICAxNyPn8Fs YQEjiZvTnoLZvEArJv2+zQJiCwHZczq62SHighInZz4BizMLaEnc+PeSqYuRA8iWllj+jwMk zClgKjG1/wzYKlEBZYm9fYfYJzDyz0LSPQtJ9yyE7gWMzKsYZVNyq3RzEzNzilOTdYuTE/Py Uot0TfRyM0v0UlNKNzGCAo9Tkn8H45wG70OMAhyMSjy8Dtd+RAqxJpYVV+YeYpTkYFIS5dW8 /zNSiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvuTNAOd6UxMqq1KJ8mJQ0B4uSOO+2oF2RQgLp iSWp2ampBalFMFkZDg4lCV4TYIQJCRalpqdWpGXmlCCkmTg4QYbzAA0XBKnhLS5IzC3OTIfI n2I05rjx8PofJo5nM183MAux5OXnpUqJ835iAioVACnNKM2DmwZKHhLZ+2teMYoDPSfMawsy kAeYeODmvQJaxQS0ykviB8iqkkSElFQDI1OwqKCn0+57eg943zcVdBxOXFD/WGd5QkCRkWG5 6Y0XE0Nfni63zS26P6FtN9fu86m+6/XXHTx8aE+A44aVapfOJnvWmneoh7Gu7Ju4wM38k6fJ Qt8NlQvPBh9zzJ8nyLJl+UZX4UyHD20epmsu2U5yLV62nT1sXX3Sx/hPc8qem8/bwci8VIml OCPRUIu5qDgRAPNYdt75AgAA Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:26:22 -0000 On Wed, Nov 01, 2017 at 12:24:55PM -0500, Benjamin Kaduk wrote: > This message begins a working group last call for > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > ending at 23:59 PST on Wednesday 29 November, 2017. > > The current (-09) version of the document is available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . We will be treating Hannes' comment about the (lack of) multi-valued audience as a WGLC comment. I hope Mike did not need the extra motivation of the WGLC to go through and make the comparison against JWT :) -Ben From nobody Wed Nov 1 10:34:08 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798CE13FB00 for ; Wed, 1 Nov 2017 10:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xYplTsTC32Bb for ; Wed, 1 Nov 2017 10:34:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010ED13F558 for ; Wed, 1 Nov 2017 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vA1HY0Ib023376; Wed, 1 Nov 2017 18:34:00 +0100 (CET) Received: from client-0182.vpn.uni-bremen.de (client-0182.vpn.uni-bremen.de [134.102.107.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yRwLc2SfpzDWxs; Wed, 1 Nov 2017 18:34:00 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20171101172455.GT26855@kduck.kaduk.org> Date: Wed, 1 Nov 2017 18:33:59 +0100 Cc: ace@ietf.org X-Mao-Original-Outgoing-Id: 531250439.275834-80787967afcee414f581cb8ac6733c1f Content-Transfer-Encoding: quoted-printable Message-Id: <83E3AB3D-BEEB-4749-BFFA-3D5F986436A2@tzi.org> References: <20171101172455.GT26855@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:34:06 -0000 Just wondering: Are you aware that this is a second WGLC? You didn=E2=80=99t mention = that. (And do we really need four weeks for a second WGLC? Even factoring in = the IETF week?) Gr=C3=BC=C3=9Fe, Carsten > On Nov 1, 2017, at 18:24, Benjamin Kaduk wrote: >=20 > This message begins a working group last call for > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > ending at 23:59 PST on Wednesday 29 November, 2017. >=20 > The current (-09) version of the document is available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . >=20 > Thanks, >=20 > Ben and Jim >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 From nobody Wed Nov 1 10:41:20 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF9813FDB3 for ; Wed, 1 Nov 2017 10:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yVuwBYJDzgms for ; Wed, 1 Nov 2017 10:41:16 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30ABC13FE08 for ; Wed, 1 Nov 2017 10:41:16 -0700 (PDT) X-AuditID: 12074423-6bfff70000004185-35-59fa07384a74 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 71.8D.16773.9370AF95; Wed, 1 Nov 2017 13:41:14 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vA1Hf9YP015964; Wed, 1 Nov 2017 13:41:10 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA1Hf5Q1019561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Nov 2017 13:41:08 -0400 Date: Wed, 1 Nov 2017 12:41:06 -0500 From: Benjamin Kaduk To: Carsten Bormann Cc: ace@ietf.org Message-ID: <20171101174105.GW26855@kduck.kaduk.org> References: <20171101172455.GT26855@kduck.kaduk.org> <83E3AB3D-BEEB-4749-BFFA-3D5F986436A2@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83E3AB3D-BEEB-4749-BFFA-3D5F986436A2@tzi.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nomvF/ivS4Oc9NYvv33qYLY5Mucvq wOSxZMlPJo9pizIDmKK4bFJSczLLUov07RK4Mn4/fMFecJu5YlvrCtYGxg9MXYwcHBICJhKn Fqh2MXJxCAksZpL4u+0BexcjJ5CzgVHi6KE0iMQVJolTi/+zgSRYBFQkmpsfsYLYbEB2Q/dl ZhBbREBJ4sLFNWwgQ5kFBCQ+XE8CCQsLWEjcnd/FAmLzAu1qubebGWJ+qsSfvYdZIeKCEidn PgGrYRZQl/gz7xIzxBhpieX/OCDC8hLNW2eDtXIKWEv8O94JdqaogLLE3r5D7BMYBWchmTQL yaRZCJNmIZm0gJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRnA4uyjvYHzZ 532IUYCDUYmH98XlH5FCrIllxZW5hxglOZiURHk17/+MFOJLyk+pzEgszogvKs1JLT7EKMHB rCTCe+4MUI43JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFqEUxWhoNDSYLXhe1XpJBg UWp6akVaZk4JQpqJgxNkOA/QcAWQGt7igsTc4sx0iPwpRmOOGw+v/2HieDbzdQOzEEtefl6q lDjvNVagUgGQ0ozSPLhpoJQkkb2/5hWjONBzwrzdIAN5gOkMbt4roFVMQKu8JH6ArCpJREhJ NTA2X6hcH2eX2f5n0jrpHA7NPfVT2Fw//LE5t1ZfZbXjpgNbY7Q+BG+ex7/li/L57M9zNd+J 5G1r70iq39ZZMG+F5jXb0swlde8PfbomaKYmli81ifugbU2i2+9mSy15z4CbczX+d3d7nr2d wnx14/QIlontVRxSdZKe06POLxDuUDSpK/CtylZiKc5INNRiLipOBAB9V1ZIJAMAAA== Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:41:17 -0000 On Wed, Nov 01, 2017 at 06:33:59PM +0100, Carsten Bormann wrote: > Just wondering: > > Are you aware that this is a second WGLC? You didn’t mention that. I was aware, sorry for not mentioning it. (The first WGLC was on the -04.) > (And do we really need four weeks for a second WGLC? Even factoring in the IETF week?) It spans a US holiday and an IETF meeting, so the extra time seemed warranted given how many other distractions people may have. -Ben From nobody Thu Nov 2 05:04:47 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700DA13F5FB; Thu, 2 Nov 2017 05:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FrQQ-Ar3tkrK; Thu, 2 Nov 2017 05:04:44 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC98F13F5E1; Thu, 2 Nov 2017 05:04:39 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 19D08204FDB; Thu, 2 Nov 2017 12:04:35 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 2 Nov 2017 13:04:36 +0100 To: "ace-chairs@ietf.org" CC: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Thu, 2 Nov 2017 13:04:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=TC_NPqnNGDR0LWaAP2AA:9 a=QEXdDO2ut3YA:10 a=V2CapFxqm0gA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] IETF 100 presentation slot request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 12:04:46 -0000 Hello ACE chairs, I'd like to request a ~15 minute slot to present the updates to draft-ietf-ace-oauth-authz at IETF 100. Currently the plan is to present remote, but I have backup on site in case there is network trouble. I'm not sure how much discussion to expect. The presentation will be much shorter than 15 mins, the ensuing discussion might not. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Thu Nov 2 19:47:42 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D013FB27; Thu, 2 Nov 2017 19:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 LkMpE62UPVK8; Thu, 2 Nov 2017 19:47:39 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F03413FB19; Thu, 2 Nov 2017 19:47:39 -0700 (PDT) X-AuditID: 1209190d-da5ff70000000899-30-59fbd8c84bc0 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E7.FC.02201.9C8DBF95; Thu, 2 Nov 2017 22:47:37 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id vA32lWjH028508; Thu, 2 Nov 2017 22:47:34 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA32lTIt008507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Nov 2017 22:47:31 -0400 Date: Thu, 2 Nov 2017 21:47:29 -0500 From: Benjamin Kaduk To: Ludwig Seitz Cc: "ace-chairs@ietf.org" , "ace@ietf.org" Message-ID: <20171103024728.GD26855@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYrdT1z1543ekQeNpFYtpd3+zWnz/1sNs 8erzdFYHZo8lS34yeSxt2swUwBTFZZOSmpNZllqkb5fAlfGzrbZgDWvFo43XmRsY57F0MXJy SAiYSMx+2czWxcjFISSwmEli18YDLBDOBkaJ1u7vUJkrTBJbpixiA2lhEVCR+NV5CKydDchu 6L7MDGKLCKhKnHz6BcxmFvCTmL3gL1i9sIC+xOMXV8BsXqB1pw4+ZQSxhQQsJNpXLIOKC0qc nPmEBaJXS+LGv5dMXYwcQLa0xPJ/HCBhTgFLiRcXpoCNFxVQltjbd4h9AqPALCTds5B0z0Lo XsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXSC83s0QvNaV0EyMoXDkleXcw/rvrdYhRgINR iYeXY/LvSCHWxLLiytxDjJIcTEqivHc3/ooU4kvKT6nMSCzOiC8qzUktPsQowcGsJML7OAao nDclsbIqtSgfJiXNwaIkzrstaFekkEB6YklqdmpqQWoRTFaGg0NJgpcTGJdCgkWp6akVaZk5 JQhpJg5OkOE8QMPfXgMZXlyQmFucmQ6RP8VoyXHj4fU/TByPbtwFks9mvm5gFmLJy89LlRLn lQQZKgDSkFGaBzcTlH4ksvfXvGIUB3pRmPfwdaAqHmDqgpv6CmghE9BCL4kfIAtLEhFSUg2M O69zZQVKyC092pIjpRMRdWLd1jqX5LOnggW/3xdf7XPwrqblus+Gq3WXX3t5+ryLYOrL75Ob iwQVneK15vAbWf6vVKzL+TA3SX3fjl9sdxLf6+uq6TxU+N5pdErlqjmbRvMu954LYpmntxUu m1nFJzbxTuk8OUd1oQsVRtsYZq1Z+XryjKXLlFiKMxINtZiLihMBJbzc1hoDAAA= Archived-At: Subject: Re: [Ace] IETF 100 presentation slot request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:47:41 -0000 Hi Ludwig, On Thu, Nov 02, 2017 at 01:04:36PM +0100, Ludwig Seitz wrote: > Hello ACE chairs, > > I'd like to request a ~15 minute slot to present the updates to > draft-ietf-ace-oauth-authz at IETF 100. Currently the plan is to present > remote, but I have backup on site in case there is network trouble. > > I'm not sure how much discussion to expect. The presentation will be > much shorter than 15 mins, the ensuing discussion might not. Thanks for letting us know about the plan for remote presentation, which of course requires additional prepartaion. As things currently stand, it seems likely that we can accomodate the request for agenda time. -Ben From nobody Sun Nov 5 09:37:20 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBD313FB82 for ; Sun, 5 Nov 2017 09:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Sy4BRn8XQ8QE for ; Sun, 5 Nov 2017 09:37:11 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7CC13FB3A for ; Sun, 5 Nov 2017 09:37:10 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n5so8434153qke.11 for ; Sun, 05 Nov 2017 09:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XhPCrko1fE0ieYybivK1R87Uu67jZRd9sKllSxAid4E=; b=MjIdbsICCyKMgxZMDijPR6TBZD9VLEyHLccnFWyzMNlm6Vl4LRht/ESwUcWsP29ath DQQfoQ9SLzPVRwPFCib6x+xFfQaOpgwZnsPIyNRdUqsYn/rBc5JFfBABHZMc+qkDzwet T7oRNb1htq9n+86pywKND4yfpwLhsVSNq69EfyGmgkDMIketeOBCGP4dvto9QQLe1XAW NvXgvaz9rvZkQRGeDYOKYk771yQ871WJnqN7To8kvUhvgqcwSPVsromHD5yR+XTDQBB5 wS3i9P1rfIizVROhwJ9IJPWVujEbrM9++EmIiiiS8cPb8eSEnH/YyR/LmGNsrAdKv7g5 TmBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XhPCrko1fE0ieYybivK1R87Uu67jZRd9sKllSxAid4E=; b=hcyIe5ne2gSN+1/4bAoPgC4g+4sOMogqU9KOcLdUKlbN2rrGmXVOnPI8AIbGXGzXa+ wCkuilmp+gP5KC2EfTaq5a1frlcEmotE/+o9Dc2zb9bYxh/vR4ErML1BJypV0ppBSJk+ O7YN2L8SY0YiQuTFOjzD3tYT2A7WEBTlHxr3K6mbLQOAjLYw4+UNc1krDNyyZBJEahJv AoXErj8IRT+CxjzrT2TKcvXQHuCMB2Ptok81ZiUuIVSA6lj4Gchr/nCq/NS9p9yc2ayQ bE6o1j28L05nqs3SdISEs7EbQPnO9RsIy/2QQEDQpy729wqI2lWIvVIM3gez8lz1bMMd Swvw== X-Gm-Message-State: AJaThX7vGe2p/50VvLY323ajtpJsWuoGAOQ9TJXSkuB5WwOfCILiVST5 0Dz/BVGCQHX2lSqt7vUC0Yp+e7qC0f9a+H1tqsE= X-Google-Smtp-Source: ABhQp+T1SFBsABtDriY8wk2f6pM9Bx/d7Zz2HUWE8hVWY+jyWZh+6aOd6XhgR2jbi32TuvMGtXTMgdp0bx0hoW39uiM= X-Received: by 10.55.20.153 with SMTP id 25mr2255342qku.315.1509903429959; Sun, 05 Nov 2017 09:37:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.74.142 with HTTP; Sun, 5 Nov 2017 09:37:09 -0800 (PST) In-Reply-To: <01a801d34dde$72e5af10$58b10d30$@augustcellars.com> References: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> <01a801d34dde$72e5af10$58b10d30$@augustcellars.com> From: Cigdem Sengul Date: Sun, 5 Nov 2017 17:37:09 +0000 Message-ID: To: Jim Schaad Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="001a1147357096851e055d3fc93c" Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 17:37:13 -0000 --001a1147357096851e055d3fc93c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the case of rogue requestor being the client, it does not have visibility into what is included in the permission ticket ( ticket is a reference returned by rs to be presented at as). It may dos Rs with requests, which rs may implement a solution like rate limiting (not described in uma). The as api for rs is protected via an oauth2 token (PAT) which rs must present for permission registration (as well as for other functions). This Pat allows as to map es=E2=80=99s request to a particular Ro. Rs can only a= sk for permissions for the resources and scopes it already registered with the As. Hope I was able to clarify. Thanks, =E2=80=94Cigdem On Wednesday, October 25, 2017, Jim Schaad wrote: > So you would be doing based on something like the address of the requesto= r > or the content of the request. I would complete understand the first > half. Is there any way to prevent a rouge requestor from asking for > information =E2=80=93 or are you just relying on a closed system? > > > > *From:* Cigdem Sengul [mailto:cigdem.sengul@gmail.com > ] > *Sent:* Wednesday, October 25, 2017 2:19 PM > *To:* Jim Schaad > > *Cc:* Ludwig Seitz >; ace@ietf.org > > *Subject:* Re: [Ace] Question about the response to an unauthorized > request > > > > UMA assumes that resource server knows =E2=80=9Cwhich authorization serv= er to > approach for the permission ticket and on which resource owner's behalf= =E2=80=9D > deriving =E2=80=9Cthe necessary information using cues provided by the st= ructure of > the API where the resource request was made, rather than by an access > token. =E2=80=9C > > On Wednesday, October 25, 2017, Jim Schaad > wrote: > > How does the RS make an informed decision about who the client is given > that it is a tokenless access request? > > > > > > > > *From:* Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Cigdem Sengul > *Sent:* Wednesday, October 25, 2017 7:28 AM > *To:* Ludwig Seitz > *Cc:* ace@ietf.org > *Subject:* Re: [Ace] Question about the response to an unauthorized > request > > > > Hello, > > > > To bring a different view, I wanted to mention Kantara UMA (User Managed > Access) approach to this problem. (I participated in the UMA v2.0 > development this year, so had the chance to be more familiar with the new > drafts.) > > > > In UMA, the resource server must respond to a client's tokenless > (unauthorized) access attempt by obtaining a permission ticket from the > authorization server. > > If RS is able to obtain a permission ticket from the AS, RS returns this > ticket to the client also with the AS uri to aid AS discovery. > > > > UMA handles resources (resource sets, permissions etc.) differently but > the permission requests (from RS to AS) can be considered as signaling t= o > the AS what audience/scope RS expects. > > > > In ACE, there are limitations of course - i.e., RS may not always reach A= S > etc. Nevertheless, it may be useful to think how other groups approach > similar problems. > > > > Best, > > --Cigdem > > > > > > On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz wrote: > > Hello ACE, > > Jim Schaad has brought up an interesting question [1] on > draft-ietf-ace-oauth-authz [2]: > > Currently when a client makes an unauthorized request to a resource > server, it gets back the address of the authorization server and optional= ly > a nonce (to prevent replay attacks). > > Jim is suggesting to add hints to the audience and scope the resource > server expects for accessing this resource. > > I'm not sure whether that would not reveal too much information to a > potential attacker. > > What does the group think of this issue? > > /Ludwig > > > [1] https://github.com/ace-wg/ace-oauth/issues/124 > [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08# > section-5.1.2 > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > > --001a1147357096851e055d3fc93c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the case of rogue requestor being the client, it does not have visibilit= y into what is included in the permission ticket ( ticket is a reference re= turned by rs to be presented at as). It may dos Rs with requests, which rs = may implement a solution like rate limiting (not described in uma).
The as api for rs is protected via an oauth2 token (PAT) which = rs must present for permission registration (as well as for other functions= ). This Pat allows as to map es=E2=80=99s request to a particular Ro. Rs ca= n only ask for permissions for the resources and scopes it already register= ed with the As.

Hope I was able to clarify.
<= div>
Thanks,
=E2=80=94Cigdem=C2=A0

On Wednes= day, October 25, 2017, Jim Schaad <ietf@augustcellars.com> wrote:

So you would be doing based on something like the address of the requ= estor or the content of the request.=C2=A0 I would complete understand the = first half.=C2=A0 Is there any way to prevent a rouge requestor from asking= for information =E2=80=93 or are you just relying on a closed system?

=C2=A0

From: Cigdem Sengul [mailto:cigdem.sengul@gmail.com]
Sent: Wednesda= y, October 25, 2017 2:19 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org
Subject: Re: [Ace] Question about the response to an unauthori= zed request

=C2= =A0

UMA assumes that=C2=A0=C2=A0resource serve= r=C2=A0knows=C2=A0=E2=80=9Cwhich authorization server to approach for the p= ermission ticket and on which resource owner's behalf=E2=80=9D deriving= =E2=80=9Cthe necessary information using cues provided by the structure of= the API where the resource request was made, rather than by an access toke= n. =E2=80=9C

On Wednesday, October 25, 2017, Jim Schaad <<= a href=3D"javascript:_e(%7B%7D,'cvml','ietf@augustcellars.com&#= 39;);" target=3D"_blank">ietf@augustcellars.com> wrote:

How does the RS make an informed decision about who the clie= nt is given that it is a tokenless access request?

=C2=A0

=C2=A0

=C2=A0

From: Ace [mailto:ace-bounces@ietf.or= g] On Behalf Of Cigdem Sengul
Sent: Wednesday, October= 25, 2017 7:28 AM
To: Ludwig Seitz <ludwig.seitz@ri.se&= gt;
Cc: ace@ietf.org
Subject: Re: [Ace] Question= about the response to an unauthorized request

=C2=A0

Hello,

=C2=A0<= /u>

To bring a different view, I wante= d to mention Kantara UMA (User Managed Access) approach to this problem. (I= participated in the UMA v2.0 development this year, so had the chance to b= e more familiar with the new drafts.)

=C2=A0

In= UMA,=C2=A0 the resource server must respond to a client's tokenless (u= nauthorized) access attempt by obtaining a permission ticket from the autho= rization server.

If RS i= s able to obtain a permission ticket from the AS, RS returns this ticket to= the client also with=C2=A0 the AS uri to aid AS discovery.=C2=A0=

=C2=A0

UMA handles resources (resource sets, permissions = etc.) differently but the permission requests (from RS to AS)=C2=A0 can be = considered as signaling to the AS what audience/scope RS expects.=

=C2=A0

In ACE, there are limitations of course - i.e., RS= may not always reach AS etc.=C2=A0 Nevertheless, it may be useful to think= how other groups approach similar problems.=C2=A0

<= div>

=C2=A0

Best,=C2=A0

--= Cigdem=C2=A0

=C2= =A0

=C2=A0<= u>

On Mon, Oct 23, 2017 at 2:38 PM, Ludw= ig Seitz <ludwig.seitz@ri.se> wrote:

Hello ACE,

Jim Schaad has brought up an= interesting question [1] on draft-ietf-ace-oauth-authz [2]:

Current= ly when a client makes an unauthorized request to a resource server, it get= s back the address of the authorization server and optionally a nonce (to p= revent replay attacks).

Jim is suggesting to add hints to the audien= ce and scope the resource server expects for accessing this resource.
I'm not sure whether that would not reveal too much information to a = potential attacker.

What does the group think of this issue?

= /Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/12= 4
[2] https://tools.ietf.org/html/dr= aft-ietf-ace-oauth-authz-08#section-5.1.2
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 5= 1

_______________________________________________
Ace ma= iling list
Ace@ietf.org
https://www.ietf.org/mailman/listinf= o/ace

=C2=A0

<= /div> --001a1147357096851e055d3fc93c-- From nobody Sun Nov 5 23:56:51 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96CE13FB3D for ; Sun, 5 Nov 2017 23:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gQRD5i3nR6SZ for ; Sun, 5 Nov 2017 23:56:48 -0800 (PST) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B1313FB34 for ; Sun, 5 Nov 2017 23:56:47 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 30525204D44 for ; Mon, 6 Nov 2017 07:56:43 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 6 Nov 2017 08:56:44 +0100 To: References: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> <01a801d34dde$72e5af10$58b10d30$@augustcellars.com> From: Ludwig Seitz Message-ID: <513dc544-6cda-7637-a685-93994aa80cd2@ri.se> Date: Mon, 6 Nov 2017 08:56:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=Bep8bgcclLamCvfF2mcA:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Question about the response to an unauthorized request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 07:56:50 -0000 On 2017-11-05 18:37, Cigdem Sengul wrote: > In the case of rogue requestor being the client, it does not have > visibility into what is included in the permission ticket ( ticket is a > reference returned by rs to be presented at as). It may dos Rs with > requests, which rs may implement a solution like rate limiting (not > described in uma). > > The as api for rs is protected via an oauth2 token (PAT) which rs must > present for permission registration (as well as for other functions). > This Pat allows as to map es’s request to a particular Ro. Rs can only > ask for permissions for the resources and scopes it already registered > with the As. > > Hope I was able to clarify. > > Thanks, > —Cigdem > Just for even more clarity: What you (or is it UMA?) call ticket is equivalent to the OAuth access tokens? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Nov 6 00:14:31 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5E13FB34 for ; Mon, 6 Nov 2017 00:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nXNpDc1Axm-N for ; Mon, 6 Nov 2017 00:14:23 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D5E13FB42 for ; Mon, 6 Nov 2017 00:14:23 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id x195so4290389qkb.12 for ; Mon, 06 Nov 2017 00:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DPk1FNfIF7ORfKsjkTQJah4ByobtcDKl5G6IXrU32GM=; b=HZb8FM3MV1TVvDvwgZbCU5pw9kC2cP/zK7VIVmcnLRgJ4qtFJL6jj7bA3xf1n8vgeY 7KVG4wr/q4rAhehiQl0wlR64hGiZJ8mrOxtB6zP7hKspaztt4tgCBFvISPGqvEtTVFtn WYEajgMHhZHbQuEB42V1X7s3z5KcpCZnLXAyCjC78PzxH2u3HDEhkXOTdQlxgQHVqCAK 1ZEdhZ8hM5UnaSsCfo7NIwGsgzPBaDPsLn59t0nP1J/WTVvIRSwkzzxeiwX3ZWS2LtsS q9pUAMJIpJrsPsAvkajUosfmeEGJBYPcEHmyB9Ux4XwajLm5Mqnb5REqNU4THffHGwAV 1VZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DPk1FNfIF7ORfKsjkTQJah4ByobtcDKl5G6IXrU32GM=; b=IavnVLrZaRFANrIm1Wsh5ZjcmLFIq84t7O+7aLq/Uc1TIAgB4iR7CAp6soaJufzxwJ +FYWqSDTZBRtyubGMwvsTOLKGayJt5fTp/yU656CmZBuByJeqkZLJTG9BY7XxElSUKEd HbhoMnw4TOTIN2hu0XTdL+C/puslYpmPrN72Lduxsep3/YfmyBq+EOBugp3nr1pzCr/7 I9aRw8MNfUdWhbftb6rREtv9YTJMsVi9bu3c4k/2DRuCQfzZmBtMTTiNHTz4O0BGn2ty tl/kdY/6UbVjW8yjWv9btju5rMEVj3+yRUujChpYOdCQ0yxoiwY6hmAxXEib+DWR9ggK ikHg== X-Gm-Message-State: AJaThX76OVIpGCXsdBKGUXyzc4fzrCdgNUHDbt5NPR0QsMZhbT8fr4h3 k4Hcy/JnGazr3LilvZFv42otAZYVhJVONQGeFVM= X-Google-Smtp-Source: ABhQp+S3s45XTddqlMbHQjpWH3x47hG8lmFQxksS7rzwXGYeoBH2AlAG91LJpAhKTlwECMamOIKjt6XJ/hxFRapQA6I= X-Received: by 10.55.158.78 with SMTP id h75mr5688403qke.355.1509956062860; Mon, 06 Nov 2017 00:14:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.74.142 with HTTP; Mon, 6 Nov 2017 00:14:22 -0800 (PST) In-Reply-To: <513dc544-6cda-7637-a685-93994aa80cd2@ri.se> References: <017f01d34dcb$c5d2e930$5178bb90$@augustcellars.com> <01a801d34dde$72e5af10$58b10d30$@augustcellars.com> <513dc544-6cda-7637-a685-93994aa80cd2@ri.se> From: Cigdem Sengul Date: Mon, 6 Nov 2017 08:14:22 +0000 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0600cec0dae2055d4c0a71" Archived-At: Subject: [Ace] Question about the response to an unauthorized request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 08:14:25 -0000 --94eb2c0600cec0dae2055d4c0a71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Ludwig, This is UMA. The ticket is a way for RS to register client=E2=80=99s reques= t with AS, giving it the ability to communicate other scopes etc related to request. Client presents the ticket to AS to obtain an access token. (So ticket is not an access token). I brought UMA ticket up to respond Jim=E2=80=99s original question of: =E2=80=9CJim is suggesting to add hints to the audience and scope the resou= rce server expects for accessing this resource.=E2=80=9D The ticket is a reference to audience/scopes the rs communicated to as with respect to the request. I already touched upon the feasibility of this in ACE given that rs and as may not be always connected. More info: https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.= html#permission-endpoin t Thanks, On Monday, November 6, 2017, Ludwig Seitz > wrote: > On 2017-11-05 18:37, Cigdem Sengul wrote: > >> In the case of rogue requestor being the client, it does not have >> visibility into what is included in the permission ticket ( ticket is a >> reference returned by rs to be presented at as). It may dos Rs with >> requests, which rs may implement a solution like rate limiting (not >> described in uma). >> >> The as api for rs is protected via an oauth2 token (PAT) which rs must >> present for permission registration (as well as for other functions). Th= is >> Pat allows as to map es=E2=80=99s request to a particular Ro. Rs can onl= y ask for >> permissions for the resources and scopes it already registered with the = As. >> >> Hope I was able to clarify. >> >> Thanks, >> =E2=80=94Cigdem >> >> > Just for even more clarity: What you (or is it UMA?) call ticket is > equivalent to the OAuth access tokens? > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --94eb2c0600cec0dae2055d4c0a71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Ludwig,

This is UMA. The ticket is a way for RS to= register client=E2=80=99s request with AS, giving it the ability to commun= icate other scopes etc related to request.

Client = presents the ticket to AS to obtain an access token. (So ticket is not an a= ccess token).

I brought UMA ticket up to respond J= im=E2=80=99s original question of:=C2=A0
=E2=80=9CJim is suggesting to add hints to the a= udience and scope the resource server expects for accessing this resource.= =E2=80=9D

The ticket is=C2=A0a reference to audience/scopes the rs communicated = to as with respect to the request.=C2=A0

I already touched upon the feasibility of t= his in ACE given that rs and as may not be always connected.=C2=A0

=C2=A0Thanks,


On Monday, November= 6, 2017, Ludwig Seitz <ludwig.seitz@ri.se>= wrote:
On 2017-11-05 18:37, Cigdem Sengu= l wrote:
In the case of rogue requestor being the client, it does not have visibilit= y into what is included in the permission ticket ( ticket is a reference re= turned by rs to be presented at as). It may dos Rs with requests, which rs = may implement a solution like rate limiting (not described in uma).

The as api for rs is protected via an oauth2 token (PAT) which rs must pres= ent for permission registration (as well as for other functions). This Pat = allows as to map es=E2=80=99s request to a particular Ro. Rs can only ask f= or permissions for the resources and scopes it already registered with the = As.

Hope I was able to clarify.

Thanks,
=E2=80=94Cigdem


Just for even more clarity: What you (or is it UMA?) call ticket is equival= ent to the OAuth access tokens?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace
--94eb2c0600cec0dae2055d4c0a71-- From nobody Mon Nov 6 00:20:03 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5844213FB48; Mon, 6 Nov 2017 00:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Hg5dofutCJSA; Mon, 6 Nov 2017 00:19:59 -0800 (PST) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3E013FA6E; Mon, 6 Nov 2017 00:19:59 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id ED176204DFB; Mon, 6 Nov 2017 08:19:55 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 6 Nov 2017 09:19:56 +0100 To: "ace-chairs@ietf.org" CC: "ace@ietf.org" , 'Samuel Erdtman' From: Ludwig Seitz Message-ID: <4b3f951b-4ccd-f670-abd6-8aef94daa33f@ri.se> Date: Mon, 6 Nov 2017 09:19:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=QLPfpYkryAO4RqcpiSkA:9 a=QEXdDO2ut3YA:10 a=V2CapFxqm0gA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] Timeslot request for draft-erdtman-ace-rpcc X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 08:20:01 -0000 Hello ACE chairs, I'd like to request a 5 min. timeslot for a remote presentation of draft-erdtman-ace-rpcc. I will have a in-person backup in case there is network trouble. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Nov 6 08:11:50 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030D13FB26; Mon, 6 Nov 2017 08:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 mu48FX2PQIsc; Mon, 6 Nov 2017 08:11:48 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6F513FAF5; Mon, 6 Nov 2017 08:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vA6GBiNc017090; Mon, 6 Nov 2017 17:11:44 +0100 (CET) Received: from wangari.tzi.org (p508A45B4.dip0.t-ipconnect.de [80.138.69.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yVyHN1Bp0zDWlH; Mon, 6 Nov 2017 17:11:44 +0100 (CET) From: Olaf Bergmann To: ace-chairs@ietf.org Cc: ace@ietf.org Date: Mon, 06 Nov 2017 17:11:43 +0100 Message-ID: <87mv3z2xq8.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ace] timeslot for draft-ietf-ace-dtls-authorize @IETF 100 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 16:11:49 -0000 Dear chairs, we would like to request a 10 min timeslot for the ACE session at IETF 100 to present the current status of draft-ietf-ace-dtls-authorize. We have not yet decided on a presenter but at least one of the authors, G=C3=B6ran, will be on-site. Thanks Olaf From nobody Mon Nov 6 14:34:03 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B354413FBD3; Mon, 6 Nov 2017 14:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 o__Vyhrt8dhk; Mon, 6 Nov 2017 14:34:00 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5811613FBDE; Mon, 6 Nov 2017 14:34:00 -0800 (PST) X-AuditID: 12074422-a93ff70000003b9e-a6-5a00e354b69f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id D6.8F.15262.553E00A5; Mon, 6 Nov 2017 17:33:58 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vA6MXrhR027292; Mon, 6 Nov 2017 17:33:54 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA6MXmQH011062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2017 17:33:52 -0500 Date: Mon, 6 Nov 2017 16:33:48 -0600 From: Benjamin Kaduk To: Olaf Bergmann Cc: ace-chairs@ietf.org, ace@ietf.org Message-ID: <20171106223348.GM26855@kduck.kaduk.org> References: <87mv3z2xq8.fsf@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mv3z2xq8.fsf@tzi.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6nohv2mCHK4E+jvMW0u79ZLb5/62G2 aFrcyOTA7LFkyU8mj2mLMgOYorhsUlJzMstSi/TtErgybv44wVxwmKXi66r77A2Mh5m7GDk4 JARMJG68jOti5OIQEljMJHH9wgIWCGcDo8TamR8ZIZwrTBI33/YCOZwcLAIqEn0fv7KD2GxA dkP3ZWYQWwTI3tD9jAnEZhZQlXi55TcbiC0s4Chxqe01WJwXaNupFYfAbCGg+uZ7y5kh4oIS J2c+YYHo1ZHYufUOG8h1zALSEsv/cUCE5SWat84GK+cEGv+54TMriC0qoCyxt+8Q+wRGwVlI Js1CMmkWwqRZSCYtYGRZxSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZopeaUrqJERzcLko7 GCf+8zrEKMDBqMTD++EwQ5QQa2JZcWXuIUZJDiYlUd4NIUAhvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIrzb1YFyvCmJlVWpRfkwKWkOFiVx3m1BuyKFBNITS1KzU1MLUotgsjIcHEoSvIKPgBoF i1LTUyvSMnNKENJMHJwgw3mAhv97CDK8uCAxtzgzHSJ/itGS48bD63+YOB7duAskn8183cAs xJKXn5cqJc7bCdIgANKQUZoHNxOUrCSy99e8YhQHelGY1xdkNQ8w0cFNfQW0kAlo4f4QsIUl iQgpqQZGQ9UKxoD7peLlP36p2z1d+E3t2v+EgoVGVey9RjfbZizfsfJG0hX5nXKcGl/z5f9s +u7hWdvGmxzTfuwpb5PvsfodRvpvuPqi6xnlXG49Fbxz5ZfkDJF+ZTaJd1Nddq67sXVunl+m jhSrx56mK6dF9bNOPPcJmcSpHuqbMU33z9s0d8MVJtZKLMUZiYZazEXFiQCid/VGMQMAAA== Archived-At: Subject: Re: [Ace] timeslot for draft-ietf-ace-dtls-authorize @IETF 100 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 22:34:02 -0000 Hi Olaf, On Mon, Nov 06, 2017 at 05:11:43PM +0100, Olaf Bergmann wrote: > Dear chairs, > > we would like to request a 10 min timeslot for the ACE session at IETF > 100 to present the current status of draft-ietf-ace-dtls-authorize. We > have not yet decided on a presenter but at least one of the authors, > Gran, will be on-site. It looks like we will have time for a 10-minute slot. Since we need to coordinate with Meetecho for remote presenters, please let us know by this Wednesday (8 November) if the presenter is likely to be remote. Thanks, Ben From nobody Tue Nov 7 02:20:21 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD7413FD54 for ; Tue, 7 Nov 2017 02:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rbDn7ZeXDIiB for ; Tue, 7 Nov 2017 02:20:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A7613FD51 for ; Tue, 7 Nov 2017 02:20:05 -0800 (PST) Received: from [192.168.91.204] ([80.92.118.86]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MOfQw-1eI5WX0AnG-0069Qn for ; Tue, 07 Nov 2017 11:20:03 +0100 References: <150955072760.16701.2547212715008710582@ietfa.amsl.com> To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Forwarded-Message-Id: <150955072760.16701.2547212715008710582@ietfa.amsl.com> Message-ID: Date: Tue, 7 Nov 2017 11:20:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150955072760.16701.2547212715008710582@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:U2+omvVDnYubhbr2PiTFAZqYzX/F57f0sxVJYujvlxwtlOmdAjY IPhAng5mLy8D7r+rBxMnbzlcQ9b+ryVlU/CsLTpjqBYN8yZBjnTN5HgmbHsBTbBHwPNJzau +tDIws9xJrG7bZ0M+A2WCZbn7QodkaIMG3GZiHXMY6fTT7LfAIG6//13PoXW3Zb/ujSu6QV Rsw2kvo1HcNHgq7uq2s2g== X-UI-Out-Filterresults: notjunk:1;V01:K0:PpooCnJwa+g=:T/LAU4oq738CWF7iGwJPqb tAlhE+ob1v5rAC8Zs9JfZ7DUB3ePOJODGMjtJzkk9xxKz1v4ow+m5s8fvNTYcrufmLT07RjwA XvZl2hUvxdRPnutDWfid8dSqSbtuvRVV9zthNrAwa1s3x6rtyiV0/VnmJ2LWHdohQVEhO3KuF 9l0R/24mohub1NUr7Jlllo9LUWWeVjPa3qjSTXY54/o6COYYArZkdXEGi3f+uwJRN9T++dRpF 6phvY/Iixjfig4kK7xyCnIErh+GxTcpRj8/OwDHC3DjoGdCMvtjOAhwBbnNUR6ud2qK1brEPj n+rsKVpLi6MrOpQhLZVyAJ+PGo1mMDuNFKGdYyjQ2gFSQOUrgRUwqzFZobR1tYTQfA8wWPF0x Vn3/c1rQFS9nsNODnUmm36IdbIyED0fWvb3ERaTKiOPMYKfBJil4OhOtqqIUVLuEOiAojmnrU Ngn5BkFrb0u/axnvuCQhUJYfGciHpnNGC1jyyefFrY2C7JhVgrbUIO+PoJMcXbx4Bl3UANuPU r0Af//T2XtRThzqBGaYGFqidRIW462ilWytnLQuIU33LzlZ46hjFPX49UKpl4k/ejds+ks48S 9hENXWy69AJ/sCG5S26W8y+fN/Yh5Btz9q2Qy260ql4KVTIsGyAGbk4jaC5+P5RFoyzx2TsvZ M5Gx+fcNRxH7hp/WMbBr+d1w78Hr5L1H7qy2OPScVaY1Alk5nBpRPaEESUL4qgl7hb5THfsFF MCrX8kJkF8irIypZhi2DqKESHQXACUCQGYLhrf5Hbo/xKNoL3fPCmX+/ovEk8tx4YZo1++ngt xTy1PE/g2/NyEbtZNPfon14Zfr7xdKO6L7dWFNSAkLEkQ2wtss= Archived-At: Subject: [Ace] Fwd: IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-tschofenig-ace-group-communication-security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 10:20:18 -0000 We wanted to make the ACE working group aware of an IPR disclosure on the group communication security from Ericsson. -------- Forwarded Message -------- Subject: IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-tschofenig-ace-group-communication-security Resent-Date: Wed, 1 Nov 2017 08:38:47 -0700 (PDT) Resent-From: alias-bounces@ietf.org Resent-To: Hannes.Tschofenig@gmx.net, werner@werner-ms.at Date: Wed, 01 Nov 2017 08:38:47 -0700 From: IETF Secretariat To: draft-tschofenig-ace-group-communication-security@ietf.org CC: alissa@cooperw.in, ipr-announce@ietf.org Dear Hannes Tschofenig, Walter Werner: An IPR disclosure that pertains to your Internet-Draft entitled "Security for Low-Latency Group Communication" (draft-tschofenig-ace-group-communication-security) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3099/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-tschofenig-ace-group-communication-security" Thank you IETF Secretariat From nobody Tue Nov 7 02:52:10 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913A913FDA8 for ; Tue, 7 Nov 2017 02:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 iV9IdQnLxnet for ; Tue, 7 Nov 2017 02:52:01 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0075.outbound.protection.outlook.com [104.47.0.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35A513FD9F for ; Tue, 7 Nov 2017 02:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I2UnGcXhWVlYAEBTa9HDfug4XhbwDRKjrnCZX+jlgto=; b=Qpi9/8nAR7dgxRx4tF718PpEUs7lvEB3jw7pxfTL8d/CSKekSTpZO7RN3UM884TRtvCYASTSpMndYiYPFX5bxAeCjhjUtH+Zj2hgDonFSuIVHYIBDzH5yJbPbclAonuqAMHYVIZe5ePwlbwsHY5WBbMo8iR2/P38Jj+ZlQPHKVY= Received: from VI1PR0801MB2717.eurprd08.prod.outlook.com (10.166.198.22) by VI1PR0801MB2719.eurprd08.prod.outlook.com (10.166.198.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Tue, 7 Nov 2017 10:51:57 +0000 Received: from VI1PR0801MB2717.eurprd08.prod.outlook.com ([fe80::65d5:69ef:ba63:1cf9]) by VI1PR0801MB2717.eurprd08.prod.outlook.com ([fe80::65d5:69ef:ba63:1cf9%14]) with mapi id 15.20.0197.020; Tue, 7 Nov 2017 10:51:57 +0000 From: Hannes Tschofenig To: "Ace@ietf.org" Thread-Topic: Group Communication Security Thread-Index: AdNXtY6IyHwhSkQ4SpeoDTsT5TLCVA== Date: Tue, 7 Nov 2017 10:51:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2719; 6:ZA8KE1ov0cv0+oTHxsVbZ73HEcHsBzJlLiiwKWVSZcAZ+j6/EAeYgovGdHoA+/kkQ0xsyTw6phHLAtCiC6ZXxeQMUrcjk4VGNtNAhWmI2dDuCH3qW7jaJYgMrtba8mjOJYZ4aVcj28Ya5CR1evtJH5zSYbv8u44GRQE/UFJSgxKUwJtxxUV9K7WrYGHlruQDsnMf9/bXzxzveDJ9AQPTN6M7IfR3SByJmWTEIKzRqndZwnIAXAVYk164KINqI6DZR7E68uzZEdZJEo4U1FV3p6NixTHFfP9MyKGVQRlY6pvLpGzAb+KCCSN/dSDCqFYBr4/nnXXVteFpYFqIOCLSECOJdURh3Tn5pbGy++BVOsY=; 5:+g555l3L9jvJtxbfGs8bp7IVNKsdz/0ZDueC0tXBnDDv44RbPEhV8cvlxHQ5S/qS9nprEV7T9f88FQ/G8zN5QEFmMdCmgf9rLEZCHztyCnEgSLzVjIlXfEnPktWvKqQNOkYcCn63Zl5P66o+f8k7C9jdnX+4aoaEvEY3dILOvMM=; 24:i1J+PL+DjeP1A8oicLWqWGQ49McDPoxkUiaPvfMkM5oT6m6LZ9gCl33l3S7e/KlYa+NMqTSpaC8FsxhfEd2CW8PxjLwmqHJ8j26yL21/N5A=; 7:sD4EqT9KomGmzQk8kgHBY9M4qAAKGLedVdyaFEJKfvm6sntpyKQ+a1k5YvtFoaWYWi91YRs5q6SRLhXDYHJtEEV5pUCVLXcBHqqLiffW0K/Lr5C96EeLLxOLKxYNxlKcrtDtqBegxY9CNXtwsZVl1euljC9hg7GM1ZGHcioZLraoETEJK4p5FbPcmbstiWdUpjdM4iuaRoguV8XV83FsqojwOr38TNYqeDYHSDMEbBOT0BL7vCAqFPrKRbR5+1NH x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7f775e19-3522-4fae-75c7-08d525cd9103 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR0801MB2719; x-ms-traffictypediagnostic: VI1PR0801MB2719: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231021)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0801MB2719; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0801MB2719; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(199003)(189002)(40434004)(53754006)(7736002)(316002)(2351001)(8676002)(5640700003)(14454004)(105586002)(99286004)(106356001)(25786009)(54356999)(50986999)(81156014)(81166006)(8936002)(3480700004)(6436002)(3280700002)(2420400007)(10710500007)(6306002)(54896002)(66066001)(3846002)(9686003)(15650500001)(33656002)(7110500001)(189998001)(86362001)(5630700001)(2900100001)(72206003)(53936002)(7116003)(101416001)(97736004)(74316002)(5660300001)(6506006)(55016002)(68736007)(6116002)(790700001)(102836003)(3660700001)(5890100001)(2906002)(478600001)(6916009)(5250100002)(2501003)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2719; H:VI1PR0801MB2717.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2717EAF4BC6486E751B618ABFA510VI1PR0801MB2717_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f775e19-3522-4fae-75c7-08d525cd9103 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 10:51:57.3145 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2719 Archived-At: Subject: [Ace] Group Communication Security X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 10:52:09 -0000 --_000_VI1PR0801MB2717EAF4BC6486E751B618ABFA510VI1PR0801MB2717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I wonder whether there is time to talk about the group communication securi= ty work at the upcoming IETF meeting. Walter and I have re-submitted the draft-tschofenig-ace-group-communication= -security-00 draft (which is just a new version of the earlier published d= raft-somaraju-ace-multicast work) and despite the Ericsson IPR we still thi= nk it is worthwhile to chat about what we actually want to accomplish. At the virtual interim meeting there was some confusion about what was real= ly needed. It is our believe that a symmetric group communication security solution is= needed for the low latency requirement in the commercial indoor lighting d= omain. We want to finally come to a conclusion whether we want to do this in the g= roup. I don't think we would need a lot of time since we don't need to talk about= how the detailed solution looks like since we need to get an agreement abo= ut the requirements first. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2717EAF4BC6486E751B618ABFA510VI1PR0801MB2717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I wonder whether there is time to talk about the gro= up communication security work at the upcoming IETF meeting.

Walter and I have re-submitted the draft-tschofenig-= ace-group-communication-security-00  draft (which is just a new versio= n of the earlier published draft-somaraju-ace-multicast work) and despite t= he Ericsson IPR we still think it is worthwhile to chat about what we actually want to accomplish.

 

At the virtual interim meeting there was some confus= ion about what was really needed.

 

It is our believe that a symmetric group communicati= on security solution is needed for the low latency requirement in the comme= rcial indoor lighting domain.

We want to finally come to a conclusion whether we w= ant to do this in the group.

 

I don’t think we would need a lot of time sinc= e we don’t need to talk about how the detailed solution looks like si= nce we need to get an agreement about the requirements first.

 

Ciao
Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2717EAF4BC6486E751B618ABFA510VI1PR0801MB2717_-- From nobody Tue Nov 7 07:55:55 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0361C133D5B for ; Tue, 7 Nov 2017 07:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gVlUyqSDJMf6 for ; Tue, 7 Nov 2017 07:55:52 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2064133D41 for ; Tue, 7 Nov 2017 07:48:43 -0800 (PST) X-AuditID: 1209190e-137ff70000003365-f0-5a01d5dad473 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 11.6D.13157.AD5D10A5; Tue, 7 Nov 2017 10:48:42 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vA7Fmfie009646 for ; Tue, 7 Nov 2017 10:48:42 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA7Fmc1Z026423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Nov 2017 10:48:41 -0500 Date: Tue, 7 Nov 2017 09:48:38 -0600 From: Benjamin Kaduk To: ace@ietf.org Message-ID: <20171107154837.GE26425@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUixCmqrHvrKmOUwa/jehbfv/UwOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40qTZsE67orjvc8YGxhncXYxcnBICJhILN8Y28XIxSEksJhJ YveC82wQzmFGiVUn5jNBOM+ZJG7vPsbYxcjJwSKgIvHr0gtmEJsNyG7ovgxmiwgISMz9+JkZ ZKqwgKpExy9ekDAv0IKNu1cwQtiCEidnPmEBsZkFdCR2br3DBlLOLCAtsfwfB0RYXqJ562yw iaICyhJ7+w6xT2Dkm4WkexaS7lkI3bOQdC9gZFnFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yX m1mil5pSuokRHHSSfDsYJzV4H2IU4GBU4uGdcZAhSog1say4MvcQoyQHk5Io74YQoBBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3u3qQDnelMTKqtSifJiUNAeLkjjvtqBdkUIC6YklqdmpqQWp RTBZGQ4OJQne3iuMUUKCRanpqRVpmTklCGkmDk6Q4TxAw6eD1PAWFyTmFmemQ+RPMepyPJv5 uoFZiCUvPy9VSpy3DqRIAKQoozQPbg4oWUhk7695xSgO9JYw7ySQKh5gooGb9ApoCRPQkv0g 3/EWlyQipKQaGNlTUkS+7AztY3QSW748Y82/N/cfKZzq+27hdcT96VO/Sfubuqwddvs2BIdI /peoDLsgOPlc2p5o43BHueL9HDlF3uV75PU7xc+Hf1n2zkjHtH9Gf0b81Hf6P2ImLHJbue/F xBbbX9wT3h80j5l9db7mF62DYWd2KeyvPDKjaVvFf2PxuZ5fpiqxFGckGmoxFxUnAgC6e9aJ 8QIAAA== Archived-At: Subject: [Ace] IETF 100 draft agenda posted X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:55:54 -0000 Hi all, I just posted a draft agenda to the datatracker for our sesion in Singapore, included below for your convenience. Note that it is still draft, i.e., might change some more. Presenters, please send your slides to the chairs by Sunday the 12th so that we can get them uploaded and confirm that we can display them, etc. We also would like to ask the presenters to focus their presentations on open issues that require WG input -- all of the documents on the agenda have been presented previously, and there is not much need for a tutorial/content section as an introduction. -Ben for the chairs ================================================================== ACE WG Meeting IETF 100 - Singapore Agenda Bashing and Administrivia (Chairs, 5 mins) Status Update (Chairs, 5 mins) Current Working Group Documents: * draft-ietf-ace-cbor-web-token (5 mins) - Mike Jones * draft-ietf-ace-cwt-proof-of-possession (10 mins) - Mike Jones * draft-seitz-ace-oscoap-profile (10 mins) - Francesca Palombini * draft-ietf-ace-oauth-authz (15 mins) - Ludwig Seitz * draft-ietf-ace-dtls-authorize (10 mins) - Olaf Bergmann/Gran Non-Working Group Documents: * draft-tiloca-ace-oscoap-joining (15 mins) - Marco Tiloa * draft-aragon-ace-ipsec-profile (5 mins) - Marco Tiloa * draft-vanderstok-ace-coap-est (15 mins) - Peter van der Stok Wrap up - (Chairs, 15 mins) * Steps before next meeting From nobody Tue Nov 7 09:05:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FAB13306A for ; Tue, 7 Nov 2017 09:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 KvHI6cFvP5pT for ; Tue, 7 Nov 2017 09:05:21 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40068.outbound.protection.outlook.com [40.107.4.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72281331FB for ; Tue, 7 Nov 2017 09:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vFXzBHY0Sksa2usaL+WbbkAJKBlJpmLqnJ173ewr/Io=; b=RjVTGZznNOCBgINRioGbh0OPFKrlkzwqphTAMvwiS4YRu5HhnURmwkKTvi7fpDgsEvEhsLm41UJg46yZzjWLugucRwhWdDnyci7q6X3HJjEdH0zl+90dAF8SuScPEAlONBCUS+MUPJgVqi4ONt0oMo3aSQ2sr+pCBzN0WrlcqmI= Received: from VI1PR0801MB2717.eurprd08.prod.outlook.com (10.166.198.22) by VI1PR0801MB2720.eurprd08.prod.outlook.com (10.166.198.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Tue, 7 Nov 2017 17:05:10 +0000 Received: from VI1PR0801MB2717.eurprd08.prod.outlook.com ([fe80::65d5:69ef:ba63:1cf9]) by VI1PR0801MB2717.eurprd08.prod.outlook.com ([fe80::65d5:69ef:ba63:1cf9%14]) with mapi id 15.20.0197.020; Tue, 7 Nov 2017 17:05:09 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] IETF 100 draft agenda posted Thread-Index: AQHTV+Dn2P+wQiGfkkejNrsiCYpWx6MJJPMQ Date: Tue, 7 Nov 2017 17:05:09 +0000 Message-ID: References: <20171107154837.GE26425@kduck.kaduk.org> In-Reply-To: <20171107154837.GE26425@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2720; 6:t2V4vafy1yaADkc7pgr3a3mPkAEmt7/e+5eAc8Vez7bsEHtLyuu0qYHY0dGSp1VychDHGb4uk84QX6F5xUBgf2wm+e6mQSEyuqrGPzLC+o0owj8Viv5HbgeLSHy1mgmKow/mtpy3RVLN0vaK8opjuiu6lFxpR4o6wNX3j/rzGutYDG9IX1PitKJCcsiVsVI0smteV21UEhmdQ13mkVw64Rx4mJfrWFn+8af0cZdes4y696wBgQ2BEkoa9n14YI6tyXbOj8gdACRO65hFsi//+Us8xzOval9ma9NINKx8r0Afda6Tcb3hKLQItHSxQn0teKsUn02eULERuhaYJ/ML7rfgJBcdz94NM1YcOXOdlF4=; 5:uNnl5apghdFR8z1YzJzSvS/a0gdrK8ZGAlbQHKabxjjYaHz9e5VB/1kWV8J0CswyyuqrSnTs08SjZvKE5QudHfA0kt5psITInptzdkIymZWarQw9NKh5B6sVQWCWiUAOiqhO9I7V+S0BHHOOpWfx8w+ktZfmlZ9tDKb8MxX9ynA=; 24:0+4wniFEJoct54MGJq+1+FVA7jjy3S4WYk1HOtPLAQicL5YYd94ODmlQG+TJxnhTSWd8HdKZ6maFY5GuQ5yzpUPZZQYm+1elhCSYpqLLpdU=; 7:9Z9TzjWAxSvBdz6/IsO+nuCG0rAccZ63w6xVutV7gPqeCYk42bIioQhddc6+whMSlGMGsNirPkGOEXkyqgGhKsGD2d29CsuTmX04KioxXaJYlwIiEsVjNgyrnqe5ZdcZ0ezoQf5EvTcJFf2j6LCY6aad8JNftJS39obnatRbL4+T6dpVXC0yXqPKMqGutcGm9jeXHn+AOKg6bwxiKtYZ1cGb69EuvLyYDHRG7AFesfQXNzi3TWF7do0CzpjHI8PM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1abef723-a981-4e66-a4e8-08d52601b3fc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:VI1PR0801MB2720; x-ms-traffictypediagnostic: VI1PR0801MB2720: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231021)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0801MB2720; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0801MB2720; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(199003)(13464003)(40434004)(189002)(53754006)(2900100001)(3846002)(2171002)(6246003)(97736004)(478600001)(229853002)(102836003)(99286004)(6116002)(68736007)(105586002)(53936002)(6306002)(55016002)(9686003)(106356001)(2501003)(5250100002)(8936002)(81166006)(81156014)(8676002)(189998001)(7696004)(5660300001)(50986999)(76176999)(966005)(101416001)(2950100002)(14454004)(33656002)(86362001)(74316002)(2906002)(7736002)(53546010)(110136005)(305945005)(5890100001)(25786009)(72206003)(6506006)(6436002)(3660700001)(316002)(54356999)(66066001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2720; H:VI1PR0801MB2717.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1abef723-a981-4e66-a4e8-08d52601b3fc X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 17:05:09.8044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2720 Archived-At: Subject: Re: [Ace] IETF 100 draft agenda posted X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:05:24 -0000 Hi Ben, I suspect my question about agenda time for the group communication securit= y topic was thereby (indirectly) answered with "no". Ciao Hannes -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: 07 November 2017 16:49 To: ace@ietf.org Subject: [Ace] IETF 100 draft agenda posted Hi all, I just posted a draft agenda to the datatracker for our sesion in Singapore= , included below for your convenience. Note that it is still draft, i.e., = might change some more. Presenters, please send your slides to the chairs by Sunday the 12th so tha= t we can get them uploaded and confirm that we can display them, etc. We a= lso would like to ask the presenters to focus their presentations on open i= ssues that require WG input -- all of the documents on the agenda have been= presented previously, and there is not much need for a tutorial/content se= ction as an introduction. -Ben for the chairs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ACE WG Meeting IETF 100 - Singapore Agenda Bashing and Administrivia (Chairs, 5 mins) Status Update (Chairs, 5 mins) Current Working Group Documents: * draft-ietf-ace-cbor-web-token (5 mins) - Mike Jones * draft-ietf-ace-cwt-proof-of-possession (10 mins) - Mike Jones * draft-seitz-ace-oscoap-profile (10 mins) - Francesca Palombini * draft-ietf-ace-oauth-authz (15 mins) - Ludwig Seitz * draft-ietf-ace-dtls-authorize (10 mins) - Olaf Bergmann/G=F6ran Non-Working Group Documents: * draft-tiloca-ace-oscoap-joining (15 mins) - Marco Tiloa * draft-aragon-ace-ipsec-profile (5 mins) - Marco Tiloa * draft-vanderstok-ace-coap-est (15 mins) - Peter van der Stok Wrap up - (Chairs, 15 mins) * Steps before next meeting _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Nov 7 09:11:29 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D196133248 for ; Tue, 7 Nov 2017 09:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T86MUVVJvXWy for ; Tue, 7 Nov 2017 09:11:26 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D7E133090 for ; Tue, 7 Nov 2017 09:11:25 -0800 (PST) X-AuditID: 1209190c-525ff7000000399b-cf-5a01e93cae8a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 94.C1.14747.C39E10A5; Tue, 7 Nov 2017 12:11:24 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vA7HBKXt027542; Tue, 7 Nov 2017 12:11:22 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA7HBHnZ002755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Nov 2017 12:11:19 -0500 Date: Tue, 7 Nov 2017 11:11:17 -0600 From: Benjamin Kaduk To: Hannes Tschofenig Cc: "ace@ietf.org" Message-ID: <20171107171116.GG26425@kduck.kaduk.org> References: <20171107154837.GE26425@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0bV5yRhlsLPF1uL7tx5mi5szTjE5 MHmsmbeG0WPJkp9MAUxRXDYpqTmZZalF+nYJXBm9b9axFZwTq9i54RFzA+NCoS5GTg4JAROJ L//OMHYxcnEICSxmkvg9+wArhLOBUWLJ4QY2COcKk8Tjt4vZQVpYBFQk5kxrBrPZgOyG7svM ILaIgKHE3uZDQN0cHMwCihJ/L6mChIUF9CW2rD/MAhLmBdp262Y9xMhuRomWD7/BWnkFBCVO znzCAmIzC+hI7Nx6hw1ijLTE8n8cEGF5ieats8HKOQUSJfbM/8oGYosKKEvs7TvEPoFRcBaS SbOQTJqFMGkWkkkLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBAU1pyTP DsYzb7wOMQpwMCrx8M44yBAlxJpYVlyZe4hRkoNJSZR3QwhQiC8pP6UyI7E4I76oNCe1+BCj BAezkgjvdnWgHG9KYmVValE+TEqag0VJnHdb0K5IIYH0xJLU7NTUgtQimKwMB4eSBG/DC8Yo IcGi1PTUirTMnBKENBMHJ8hwHqDhi54D1fAWFyTmFmemQ+RPMepyPJv5uoFZiCUvPy9VSpxX EmSQAEhRRmke3BxQMpLI3l/zilEc6C1h3jkgVTzARAY36RXQEiagJftBvuMtLklESEk1MLbz LAgQ8V4VxvCPtftiksn5TrNLmxdc8N7twH9JV9a4zKntT4WArKJd4OUjs8KOs/0xuh+knfk4 Y+KZbdIr7Oy2nr94cduKpWqWqdoOFTdm7dxwZJXC/G7h8jWtnYyfON4+177p5MJXXNmTnuu9 KaGu4/NDJR0vzfCQd4GvNV+2/zL4VB7xUYmlOCPRUIu5qDgRABosNVQhAwAA Archived-At: Subject: Re: [Ace] IETF 100 draft agenda posted X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:11:28 -0000 Hi Hannes, I wouldn't say that; it's more of a race condition as I prepared the agenda last night and did not see your request this morning before I submitted the draft agenda. So, you should expect a separate response to that request (and could note that the current agenda does not fill the allocated timeslot), -Ben On Tue, Nov 07, 2017 at 05:05:09PM +0000, Hannes Tschofenig wrote: > Hi Ben, > > I suspect my question about agenda time for the group communication security topic was thereby (indirectly) answered with "no". > > Ciao > Hannes > > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Benjamin Kaduk > Sent: 07 November 2017 16:49 > To: ace@ietf.org > Subject: [Ace] IETF 100 draft agenda posted > > Hi all, > > I just posted a draft agenda to the datatracker for our sesion in Singapore, included below for your convenience. Note that it is still draft, i.e., might change some more. > > Presenters, please send your slides to the chairs by Sunday the 12th so that we can get them uploaded and confirm that we can display them, etc. We also would like to ask the presenters to focus their presentations on open issues that require WG input -- all of the documents on the agenda have been presented previously, and there is not much need for a tutorial/content section as an introduction. > > -Ben > for the chairs > > > ================================================================== > > ACE WG Meeting > IETF 100 - Singapore > > Agenda Bashing and Administrivia (Chairs, 5 mins) > > Status Update (Chairs, 5 mins) > > Current Working Group Documents: > * draft-ietf-ace-cbor-web-token (5 mins) - Mike Jones > * draft-ietf-ace-cwt-proof-of-possession (10 mins) - Mike Jones > * draft-seitz-ace-oscoap-profile (10 mins) - Francesca Palombini > * draft-ietf-ace-oauth-authz (15 mins) - Ludwig Seitz > * draft-ietf-ace-dtls-authorize (10 mins) - Olaf Bergmann/Gran > > Non-Working Group Documents: > * draft-tiloca-ace-oscoap-joining (15 mins) - Marco Tiloa > * draft-aragon-ace-ipsec-profile (5 mins) - Marco Tiloa > > * draft-vanderstok-ace-coap-est (15 mins) - Peter van der Stok > > Wrap up - (Chairs, 15 mins) > * Steps before next meeting > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From dominik.obermaier@gmail.com Tue Nov 7 13:29:07 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514A71270FC for ; Tue, 7 Nov 2017 13:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8x13dkMAsB4H for ; Tue, 7 Nov 2017 13:29:05 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2882B126C19 for ; Tue, 7 Nov 2017 13:29:05 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id k61so559604wrc.4 for ; Tue, 07 Nov 2017 13:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Dru23qL9fxvYiedLArqOGYR3fbOXIEjNP+ra6UHcFis=; b=MRV5+O9sfKZiDDjXTD0pT6pelo7Od0ugwN1w5Tz6a19x0zGWEEd4/QRE3xsOkKb0wV +FBxDrAqjXRWrePHlUJF+mGCL2DngRpS84NkrRIqeKZYxo790Jut0UwtUDr6w7TxfUDW 08Bzrh+cv6hO4pb+7PLsT+a5z2ZbyOJzT/nb+qGWKIvWMcIsH+WAaPUSveagDKdegame hyPP1GEuoBrAGnGNnNB9PSysaDwDtEjoM4NEMpuabwkRo52zvdBrsuQiUoebiha0m6/o yyQtmGI8w0+dN/RDa3iVitO2cb4ZdxAlk/KJpb5QqUC/XVpDDc3s18Ojwi8vfvISi3ul hMIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Dru23qL9fxvYiedLArqOGYR3fbOXIEjNP+ra6UHcFis=; b=mbXy1kPt9Gq30n0I3wopjYpCFDM9BjODg0rDjkfJnzMvdmNKsYnVJMQj3kp9ej+Thg SAenteIs+2q1ZblN9ztQTPu1BdZcab3xQnXxh5TRUoxRMCylpQGKW3xmI7f/bHuKRxwl OlamZrxxr5yUR6cFLiV0r5DOKUDWUpboa5rllIQxNxT/gZ2X36t6CQh2MVC9l4oD57qh n94bTOE8xp/k+wQVZsR2BmHqa8wceRY42Lw3I+Hi6xoNVgFMrLTzrwwiU//MZigSLmy7 3PmO1ZscrRzMjXrZUBOp4bR3GXiHojZgV6lNrYyM+bkxt+D19jDIxIM5XLao0GBMUMVs ltfg== X-Gm-Message-State: AJaThX6JEpAc0NrOe9g6sjXeM+0vuzde5AZR9udtMc2Zd2/mwPaKQJ2Z rNWItZ81FPBDo1cWPMK51FC7ll7a X-Google-Smtp-Source: ABhQp+STCwRsLK5i8En0vKvpIK1TNjmFKIgd+W8f6F8vwU563Ctz2mxkkNaA0X3dIzaRJTxoEsQ9Yg== X-Received: by 10.223.139.149 with SMTP id o21mr83818wra.87.1510090143287; Tue, 07 Nov 2017 13:29:03 -0800 (PST) Received: from [192.168.178.29] (p549F7ED0.dip0.t-ipconnect.de. [84.159.126.208]) by smtp.gmail.com with ESMTPSA id v8sm1148433wrg.80.2017.11.07.13.29.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 13:29:02 -0800 (PST) From: "Dominik Obermaier" To: ace@ietf.org Date: Tue, 07 Nov 2017 22:29:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: [Ace] MQTT-TLS profile of ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 21:30:01 -0000 All, I had the opportunity to review the MQTT-TLS profile for ACE [1] and I’d like to share my thoughts with this list. The document at hand proposed that token expiry checks take place on PUBLISH, SUBSCRIBE or CONNECT actions. I’d like to note that it might be worthwhile to have the token expiry checks for PINGREQ packets in order to make sure that “sleeping” MQTT clients which do not send PUBLISH or SUBSCRIBE packets can get disconnected at the next possible client interaction with the broker. On a sidenote: In a recent MQTT project with millions of constrained and untrusted devices (connected via unreliable communication channels), an almost identical approach as proposed in the draft was implemented. The authentication and authorization was implemented exactly as described in this document with the use of the Introspection API and “offline validation” of JWTs. So I can confirm that the approach proposed is actually usable at scale and works very well with some existing MQTT brokers. All the best, Dominik [1] https://www.ietf.org/id/draft-sengul-ace-mqtt-tls-profile-01.txt From nobody Wed Nov 8 05:34:35 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B2C1201F2 for ; Wed, 8 Nov 2017 05:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=nominet.uk header.b=Ms02KFfI; dkim=pass (1024-bit key) header.d=nominetuk.onmicrosoft.com header.b=IHtsUIb2 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 VnjLLhChn8M7 for ; Wed, 8 Nov 2017 05:34:30 -0800 (PST) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD1126CC7 for ; Wed, 8 Nov 2017 05:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.uk; i=@nominet.uk; q=dns/txt; s=nominetuk.dkim.nominet.selector; t=1510148069; x=1541684069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QDxAYdxQLJhZ0Slu4BlJ5pWRqXcaho+7Zpday4fjebI=; b=Ms02KFfIYZTCYhmEy6ETFyCW/id7TnnWU+InOnfK49iJIaQd144TZm5N Rh0t3C3aGIRZ+8WXuT5yhI205XSCBKKLTAzd5Xq5dtB3Ve/i5d5lv1FFj BWktTNCqulGUAnEGVBUhyDjHLlRoog6mwqZ50hwKpzVp+l3HfrLbuYCu5 910/6UL+5hQFGrGnb1yXh4iCwvAX5GRya+JmfsxFjECwfoMMpPbM4JRL4 pKmjHqISOExlOmc8DFaUBTL9xR2Wg; X-SenderBase-Reputation: 3.5 X-IPAS-Result: =?us-ascii?q?A2CrAQAyBwNahzaax9VdGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?mS1cQXwQLJwePCY1qgkN+h1eOB4EiA1MJChgLhRgChT4VAQEBAQEBAQEBEwEBA?= =?us-ascii?q?QgNCQgoJAuFHgEBAQEDAQE+AQERGwsBDwIBCBEEAQENIiEGCx0IAgQOBQiKAwM?= =?us-ascii?q?WAwydTAKLCQEBgxGDCQEBBYQ4DQuDPQEBAQEBBQEBAQEBAQEBGAMFgzCDW4Fpg?= =?us-ascii?q?nU1gmuBbjwCg0SCEiChYj2LT4Q2mDGNIohSAgICAgkCEQEBB4E5NYITNCE2TYJ?= =?us-ascii?q?kgk0fgXN3AYlaLIEFAYEQAQEB?= Received: from mail-ve1eur02lp0054.outbound.protection.outlook.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) ([213.199.154.54]) by mx2.nominet.org.uk with ESMTP/TLS/AES256-SHA256; 08 Nov 2017 13:34:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NominetUK.onmicrosoft.com; s=selector1-nominet-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y4ZQOwQrcEgt/JOQjkXJE+sHUDXAmwdRiD7srH1vPro=; b=IHtsUIb289wywm56g7cZHpycHFXct3ZpS6ta+C7tfrvhC8TVYQdwCWw4R8+sYmYfHJPlQixyMkOgQGr80gYVhTR0roNVSXFceVu0RKaSMG3OWu5kJRREPHj2cZ9Wkfl9NrfYJIex2nQbeMBDyEweyTj8hYconGrqkLcOzISmqLQ= Received: from AM4PR05MB3507.eurprd05.prod.outlook.com (10.171.188.12) by AM4PR05MB3508.eurprd05.prod.outlook.com (10.171.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 8 Nov 2017 13:34:26 +0000 Received: from AM4PR05MB3507.eurprd05.prod.outlook.com ([fe80::d52b:5272:d63f:45d4]) by AM4PR05MB3507.eurprd05.prod.outlook.com ([fe80::d52b:5272:d63f:45d4%13]) with mapi id 15.20.0197.020; Wed, 8 Nov 2017 13:34:26 +0000 From: Anthony Kirby To: "ace@ietf.org" CC: Dominik Obermaier Thread-Topic: [Ace] MQTT-TLS profile of ACE Thread-Index: AQHTWA+XyhqrOkDWyE6EcyUW5sQ/j6MKXdZx Date: Wed, 8 Nov 2017 13:34:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Anthony.Kirby@nominet.uk; x-originating-ip: [213.248.204.106] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR05MB3508; 20:ID8Q8G8xsszUWybRRi9t3j7PgA0ehihtC3UBlGmGg4Y5km/78IMc0AA8lCtNgX6je/Hn1zsegieq3gR8pKfeFiURfx8A5BgCZNCvWtCbhEDZb3nISxRK1oPvUysfN/CqIwUKPTq0dAlTLEMc0YiPbgBIShZHp1LNOGs9nAY5Yzo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d5d3a5a5-2b2b-4285-0fa2-08d526ad6e20 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:AM4PR05MB3508; x-ms-traffictypediagnostic: AM4PR05MB3508: x-exchange-antispam-report-test: UriScan:(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231021)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR05MB3508; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR05MB3508; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(189002)(51914003)(199003)(3660700001)(3280700002)(2950100002)(99286004)(6916009)(7696004)(74482002)(229853002)(966005)(345774005)(5660300001)(72206003)(8936002)(8676002)(2501003)(81166006)(1730700003)(5250100002)(316002)(305945005)(2900100001)(74316002)(2906002)(25786009)(81156014)(54356999)(189998001)(97736004)(9686003)(55016002)(6306002)(6246003)(50986999)(66066001)(7736002)(39060400002)(53546010)(86362001)(14454004)(106356001)(105586002)(2351001)(76176999)(478600001)(5640700003)(6436002)(6506006)(68736007)(101416001)(4326008)(102836003)(53936002)(6116002)(33656002)(3846002)(266184004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR05MB3508; H:AM4PR05MB3507.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nominet.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nominet.uk X-MS-Exchange-CrossTenant-Network-Message-Id: d5d3a5a5-2b2b-4285-0fa2-08d526ad6e20 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 13:34:26.0335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 797b4183-8c85-46bd-ba6d-6371cfdf5059 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3508 Archived-At: Subject: Re: [Ace] MQTT-TLS profile of ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:34:33 -0000 Hi Dominik, many thanks for the review! It's appreciated. We didn't initially consider the keepalive / PINGREQ, because we'd seen it = as (effectively) a lower layer issue. But I understand value of using it a= s an opportunity to check for token expiry: Even if it happens frequently,= each check will be a low cost for the broker. Thank you for the suggestio= n, I'll add it to the draft. Thinking aloud, it might not be straightforward to implement this when exte= nding an existing broker (for example the mosquitto auth plugin) so I expec= t it would be a SHOULD rather than a MUST. Anthony ________________________________________ From: Ace on behalf of Dominik Obermaier Sent: 07 November 2017 21:29 To: ace@ietf.org Subject: [Ace] MQTT-TLS profile of ACE All, I had the opportunity to review the MQTT-TLS profile for ACE [1] and I=92d like to share my thoughts with this list. The document at hand proposed that token expiry checks take place on PUBLISH, SUBSCRIBE or CONNECT actions. I=92d like to note that it might be worthwhile to have the token expiry checks for PINGREQ packets in order to make sure that =93sleeping=94 MQTT clients which do not send PUBLISH or SUBSCRIBE packets can get disconnected at the next possible client interaction with the broker. On a sidenote: In a recent MQTT project with millions of constrained and untrusted devices (connected via unreliable communication channels), an almost identical approach as proposed in the draft was implemented. The authentication and authorization was implemented exactly as described in this document with the use of the Introspection API and =93offline validation=94 of JWTs. So I can confirm that the approach proposed is actually usable at scale and works very well with some existing MQTT brokers. All the best, Dominik [1] https://www.ietf.org/id/draft-sengul-ace-mqtt-tls-profile-01.txt _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Nov 10 06:09:01 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81AF126BFD for ; Fri, 10 Nov 2017 06:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x_XX96Z_GO4K for ; Fri, 10 Nov 2017 06:08:57 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D38120454 for ; Fri, 10 Nov 2017 06:08:57 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id o6so12017841qkh.3 for ; Fri, 10 Nov 2017 06:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FRH7HsOWVza2DqC6whc1ZkIIYQcjGf1oIHa171dV+Qg=; b=AuQrvzZ6gjMlFt7rHld7DIQ+YzE88FWj6YTJ6YrCnrdZ5bIBYm8jIsHKNHzjabxd1n TTBepnPzrkhEAnXclpRO+n2w3vjq3xgDhpvdOfaE5eko7KpisggTdchxJoL8AlPs4BOu DvFJ/egmL8fg09jrva21rteL4KlDYGQ/CFoskXr5kh6nVbsO63qk40v542qums1VTy2E p8NMaAhZxND/2KW/uZFaKo57HPpniIAyzYlKo4uNoXJZBTtOau2v3e9aRUvFllx6m9Q4 zy0JCmgzJP10sdFiiJYBO6JZJ9e7zZ0o+SjgLZWlbhv/iI268zfcOpNdj0/OVCW6aaMZ qEGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FRH7HsOWVza2DqC6whc1ZkIIYQcjGf1oIHa171dV+Qg=; b=IxGnhtf4N8UCyS3cY5q8frK/KzT1KireDxDIKl2NmTekKJrcdwf8ocoAMG7GRuaBm/ UM1aMMzjLbAPtmaQg96XEOptVd8WVJiWyme9r5T5jzRW1TzNDkRCQfLHbY95cKHwr8GQ kpXPzCSJpawfcWWeuNPB88+sWz9JtcS+xlqyO8AVYafDQ383LhS48jUEy6wGB74FLv0t HQEwLd6NQgO979RLW3dDA0DY/XwfpH//tAINsg2SJWYvLPm5GwmQfyb1J6LT4nYGDs84 sml3N0Mh1IfeZiwrlNXAFpnwXLntamraXtPOhghg5q7s23SgSJZei9HpkaN6Vn/74i5q 7mxw== X-Gm-Message-State: AJaThX6rLab/vQ81UTjfY4tSFzu275+5+5x8TBVGhueTj329kgCFP1eZ vUbrlAETmN5/j98vBNRqc9gAAZ5MQgH2fWdZ+D4= X-Google-Smtp-Source: AGs4zMbFVPZQiBmfFtj/fZ/Q7utcyQlufoJ0/Kzt+Kq0oqEHVULfLZsq/UdFSnvBD+DGLb8EojAsQTJbK12ijpfO8XU= X-Received: by 10.55.75.75 with SMTP id y72mr705104qka.118.1510322936612; Fri, 10 Nov 2017 06:08:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.74.142 with HTTP; Fri, 10 Nov 2017 06:08:56 -0800 (PST) In-Reply-To: References: From: Cigdem Sengul Date: Fri, 10 Nov 2017 14:08:56 +0000 Message-ID: To: Anthony Kirby Cc: "ace@ietf.org" , Dominik Obermaier Content-Type: multipart/alternative; boundary="001a114a6abe221190055da176a9" Archived-At: Subject: Re: [Ace] MQTT-TLS profile of ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 14:09:00 -0000 --001a114a6abe221190055da176a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Dominik for your review of the draft. We mentioned in the virtual interim that we approached to OASIS MQTT TC for reviewers; Dominik kindly agreed to review our draft. Indeed, the PINGREQs were not included for checking token expiry as they do not signal a token (like CONNECT) or topic permissions (like PUBLISH/SUBSCRIBE). But, your suggestion would be a very useful optimization for early detection of token expiry. As Anthony said, we will add it to the draft (possibly as a SHOULD). Very glad to hear that your ongoing project is in agreement with the draft. It would be very useful to get input from your deployment experience. Sincerely, --Cigdem On Wed, Nov 8, 2017 at 1:34 PM, Anthony Kirby wrote: > Hi Dominik, > many thanks for the review! It's appreciated. > > We didn't initially consider the keepalive / PINGREQ, because we'd seen i= t > as (effectively) a lower layer issue. But I understand value of using it > as an opportunity to check for token expiry: Even if it happens > frequently, each check will be a low cost for the broker. Thank you for > the suggestion, I'll add it to the draft. > > Thinking aloud, it might not be straightforward to implement this when > extending an existing broker (for example the mosquitto auth plugin) so I > expect it would be a SHOULD rather than a MUST. > > Anthony > > > ________________________________________ > From: Ace on behalf of Dominik Obermaier < > dominik.obermaier@gmail.com> > Sent: 07 November 2017 21:29 > To: ace@ietf.org > Subject: [Ace] MQTT-TLS profile of ACE > > All, > > I had the opportunity to review the MQTT-TLS profile for ACE [1] and > I=E2=80=99d like to share my thoughts with this list. > > > The document at hand proposed that token expiry checks take place on > PUBLISH, SUBSCRIBE or CONNECT actions. I=E2=80=99d like to note that it m= ight > be worthwhile to have the token expiry checks for PINGREQ packets in > order to make sure that =E2=80=9Csleeping=E2=80=9D MQTT clients which do = not send > PUBLISH or SUBSCRIBE packets can get disconnected at the next possible > client interaction with the broker. > > On a sidenote: In a recent MQTT project with millions of constrained and > untrusted devices (connected via unreliable communication channels), an > almost identical approach as proposed in the draft was implemented. The > authentication and authorization was implemented exactly as described in > this document with the use of the Introspection API and =E2=80=9Coffline > validation=E2=80=9D of JWTs. So I can confirm that the approach proposed = is > actually usable at scale and works very well with some existing MQTT > brokers. > > All the best, > Dominik > > [1] https://www.ietf.org/id/draft-sengul-ace-mqtt-tls-profile-01.txt > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a114a6abe221190055da176a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Dominik for your review of the draft. We mention= ed in the virtual interim that we approached to OASIS MQTT TC for reviewers= ; Dominik =C2=A0kindly agreed to review our draft.=C2=A0

Indeed, the PINGREQs were not included for checking token expiry as they d= o not signal a token (like CONNECT) or topic permissions (like PUBLISH/SUBS= CRIBE). But, your suggestion would be a very useful optimization for early = detection of token expiry. As Anthony said, we will add it to the draft (po= ssibly as a SHOULD).=C2=A0

Very glad to hear that = your ongoing project is in agreement with the draft. It would be very usefu= l to get input from your deployment experience.=C2=A0

<= div>Sincerely,
--Cigdem =C2=A0

On Wed, Nov 8, 2017 at 1:34 PM, Anthony = Kirby <Anthony.Kirby@nominet.uk> wrote:
Hi Dominik,
many thanks for the review! It's appreciated.

We didn't initially consider the keepalive / PINGREQ, because we'd = seen it as (effectively) a lower layer issue.=C2=A0 But I understand value = of using it as an opportunity to check for token expiry:=C2=A0 Even if it h= appens frequently, each check will be a low cost for the broker.=C2=A0 Than= k you for the suggestion, I'll add it to the draft.

Thinking aloud, it might not be straightforward to implement this when exte= nding an existing broker (for example the mosquitto auth plugin) so I expec= t it would be a SHOULD rather than a MUST.

Anthony


________________________________________
From: Ace <ace-bounces@ietf.org<= /a>> on behalf of Dominik Obermaier <dominik.obermaier@gmail.com>
Sent: 07 November 2017 21:29
To: ace@ietf.org
Subject: [Ace] MQTT-TLS profile of ACE

All,

I had the opportunity to review the MQTT-TLS profile for ACE [1] and
I=E2=80=99d like to share my thoughts with this list.


The document at hand proposed that token expiry checks take place on
PUBLISH, SUBSCRIBE or CONNECT actions. I=E2=80=99d like to note that it mig= ht
be worthwhile to have the token expiry checks for PINGREQ packets in
order to make sure that =E2=80=9Csleeping=E2=80=9D MQTT clients which do no= t send
PUBLISH or SUBSCRIBE packets can get disconnected at the next possible
client interaction with the broker.

On a sidenote: In a recent MQTT project with millions of constrained and untrusted devices (connected via unreliable communication channels), an
almost identical approach as proposed in the draft was implemented. The
authentication and authorization was implemented exactly as described in this document with the use of the Introspection API and =E2=80=9Coffline validation=E2=80=9D of JWTs. So I can confirm that the approach proposed is=
actually usable at scale and works very well with some existing MQTT
brokers.

All the best,
Dominik

[1] https://www.ietf.org/id/draft-sengul-ace-mqtt-tls-profile-01.txt

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--001a114a6abe221190055da176a9-- From nobody Fri Nov 10 10:41:06 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391B312878D for ; Fri, 10 Nov 2017 10:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 d6GHn607qorN for ; Fri, 10 Nov 2017 10:41:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA32A1289B0 for ; Fri, 10 Nov 2017 10:41:03 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B0B5520008 for ; Fri, 10 Nov 2017 13:42:27 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A397F80661 for ; Fri, 10 Nov 2017 13:41:02 -0500 (EST) From: Michael Richardson To: ace@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 18:41:05 -0000 --=-=-= Content-Type: text/plain {In some ways this should be a discussion among the authors of which I am now one, but I feel that the discussion belongs in public} 1) discovery. Section 4.1 provides for the process to start with a discovery operation. The presence and location of (path to) the management data are discovered by sending a GET request to "/.well-known/core" including a resource type (RT) parameter with the value "ace.est" [RFC6690]. Upon success, the return payload will contain the root resource of the EST resources. It is up to the implementation to choose its root resource; throughout this document the example root resource /est is used. The example below shows the discovery of the presence and location of management data. REQ: GET /.well-known/core?rt=ace.est I can see the architectural reasons for why we do that, but I really have to ask why if we really really need this extra round trip. The alternative is that we either have to use /.well-known/est, or that we wind up standardizing something (maybe /e) that isn't inside /.well-known. Can DTLS compression do better things for us instead? 2) DTLS and HelloVerifyRequest. SHOULD CoAP-EST servers always perform the HelloVerifyRequest state? Again, it's an extra round trip. Always doing it would simplify the code paths on both ends. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloF8r4ACgkQgItw+93Q 3WXeYwgAuRqDoZP2zJwVUlLFGgGkfAVMLam8HSzBblTS1K+oNxSyALUfzWkU4DZ4 6CLoCTqaHonCofamaGanPk2x3tRzCwZYbvnhNUo/gLPAomPoNUhiAljltwCC/HrV dyEpHpjWMgNSFb6bIFV8prffgj4ygvfXemq0kJZ0wvZyA4fYi2XvqZJqWzE76kXU 6LdzCrpvdI40rQudOzdSVcbhugRVXgrfYP2kCdYkn4rnuQC18gpib4icxySc5DqL 2fHy0zRaikwdHKpYNqAd4PUiYTgUb5tHNfsMeSA9bPJf7DN+Zq7uzW1tLvJGmGZu b7Sl19nHwpNCi1zOYPIHMRpNbo7pLA== =5Ukr -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 11 04:46:54 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAB0128959 for ; Sat, 11 Nov 2017 04:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eHEhgQqx2zkX for ; Sat, 11 Nov 2017 04:46:50 -0800 (PST) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE671270A7 for ; Sat, 11 Nov 2017 04:46:49 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud9.xs4all.net with ESMTPA id DVBOelVeznIXbDVBOeqUFQ; Sat, 11 Nov 2017 13:46:48 +0100 Received: from 2001:67c:1232:144:9016:6f55:5e12:75b8 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 11 Nov 2017 13:46:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 11 Nov 2017 13:46:46 +0100 From: peter van der Stok To: Michael Richardson Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <14857.1510339262@obiwan.sandelman.ca> References: <14857.1510339262@obiwan.sandelman.ca> Message-ID: <03924b83147ae84930537290b363e3f2@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfNgvz83brplGzlyqwEKWV4Ms18GKzOAaRd6gvz8pUPXmJiLBC0Lhxtst197XTlMOJBcdp3up55/PQdPZia8BAGStvsb8SAMg7umtOVYm+xPUTA9urlGO u+7BX1paB80UIlVxbC+H9G3kyGGxytIhlaDb6JZjRYMO7n2V9ccfyCeC3o0hRdaz3yh46TxmN1HkIV807q3RMBdCVik97qMjuroXB3UQK2zDEqC3uTQKPjv3 Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 12:46:52 -0000 Hi Michael, See below. Michael Richardson schreef op 2017-11-10 19:41: > {In some ways this should be a discussion among the authors of which I > am now > one, but I feel that the discussion belongs in public} > > 1) discovery. > > Section 4.1 provides for the process to start with a discovery > operation. > > The presence and location of (path to) the management data are > discovered by sending a GET request to "/.well-known/core" including > a resource type (RT) parameter with the value "ace.est" [RFC6690]. > Upon success, the return payload will contain the root resource of > the EST resources. It is up to the implementation to choose its > root > resource; throughout this document the example root resource /est is > used. The example below shows the discovery of the presence and > location of management data. > > REQ: GET /.well-known/core?rt=ace.est > > I can see the architectural reasons for why we do that, but I really > have to > ask why if we really really need this extra round trip. This is the standard way of discovering coap endpoints. It's done once at start-up. It's extra to what? > > The alternative is that we either have to use /.well-known/est, or that > we wind up standardizing something (maybe /e) that isn't inside > /.well-known. > I don't understand this last phrase, Peter From nobody Sat Nov 11 10:32:32 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17A4126C0F for ; Sat, 11 Nov 2017 10:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 N_E2oaZhWnsr for ; Sat, 11 Nov 2017 10:32:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EC21201F2 for ; Sat, 11 Nov 2017 10:32:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6964E20008; Sat, 11 Nov 2017 13:33:58 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E295182639; Sat, 11 Nov 2017 13:32:29 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org cc: ace@ietf.org In-Reply-To: <03924b83147ae84930537290b363e3f2@xs4all.nl> References: <14857.1510339262@obiwan.sandelman.ca> <03924b83147ae84930537290b363e3f2@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 18:32:31 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > Michael Richardson schreef op 2017-11-10 19:41: >> {In some ways this should be a discussion among the authors of which I am >> now >> one, but I feel that the discussion belongs in public} >> >> 1) discovery. >> >> Section 4.1 provides for the process to start with a discovery operation. >> >> The presence and location of (path to) the management data are >> discovered by sending a GET request to "/.well-known/core" including >> a resource type (RT) parameter with the value "ace.est" [RFC6690]. >> Upon success, the return payload will contain the root resource of >> the EST resources. It is up to the implementation to choose its root >> resource; throughout this document the example root resource /est is >> used. The example below shows the discovery of the presence and >> location of management data. >> >> REQ: GET /.well-known/core?rt=ace.est >> >> I can see the architectural reasons for why we do that, but I really have >> to >> ask why if we really really need this extra round trip. > This is the standard way of discovering coap endpoints. > It's done once at start-up. It's extra to what? Yes, once after a whole bunch of DTLS setup packets back and forth. So perhaps it fades into noise compared to the DTLS setup... >> The alternative is that we either have to use /.well-known/est, or that >> we wind up standardizing something (maybe /e) that isn't inside >> /.well-known. >> > I don't understand this last phrase, We could go against some architecture decisions and standardize /e or something like that rather than /.well-known/est or the lookup. Given the size of the vouchers, the certificates being passed around by DTLS, and the DTLS record format... does shortening the URLs from /.well-known/est buy much? I shall look at the example packets in the document to see. Can the response from core?rt=ace.est be "/" or ""? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloHQj0ACgkQgItw+93Q 3WXE1ggAuJKW/e6lw39sygl8SX+a5mInpGNxCscJyXBGPNcsxC4o6w8kbFGOF9C2 D2q81VJXQ5vUqocaP+Dajjt2f+6lhvwRswK+Is7St7MGlEnuqWk847kEX3dMlOTJ Iq1OTLstuycyI5O9E41dCGXTU1Hj5wU2cunOnn/17bp2oRFPzwHOeoKVgsur1A6o 6S/1xp1TyAfC118wX26IRXyK02g6r3NaCCa5vR7FpvyI1S4hruiVj86Wmx/BL73t q5YMEESu3Ro8tBBD+pDfOVlOM8M+IjXSTcilmsSfrBMx0TmJAgAsJ/aU7W+P0nUH oyq2YszxGXfUIWgKUUOeXcF+q+jDig== =/o6z -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 12 18:32:09 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CF8127077 for ; Sun, 12 Nov 2017 18:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KH0zEgmOz4vl for ; Sun, 12 Nov 2017 18:32:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AFD2126D85 for ; Sun, 12 Nov 2017 18:32:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 186D720008 for ; Sun, 12 Nov 2017 21:33:38 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3928C81F0B for ; Sun, 12 Nov 2017 21:32:04 -0500 (EST) From: Michael Richardson to: ace@ietf.org In-Reply-To: <14857.1510339262@obiwan.sandelman.ca> References: <14857.1510339262@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sun, 12 Nov 2017 21:32:04 -0500 Message-ID: <10211.1510540324@obiwan.sandelman.ca> Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:32:08 -0000 Michael Richardson wrote: > Section 4.1 provides for the process to start with a discovery > operation. ... > REQ: GET /.well-known/core?rt=ace.est > I can see the architectural reasons for why we do that, but I really > have to ask why if we really really need this extra round trip. Having read rfc6690 over again in order to implement this, I am now further convinced that using this mechanism as a way to shorten the /.well-known/est to something else is not entirely right. I can see how a CoAP multicast to /.well-known/core?rt=ace.est ought to return a list of hosts that support EST, and that EST ought to be returned in a list of supported interfaces. I'm less convinced that we ought to be using this mechanism to shorten /.well-known/est to /est (why stop there? can't we go to /?) It seems like maybe a 301-like (Moved Permantly) reply from /.well-known/est/*, but CoAP doesn't have 301 codes.... (weird to me that rfc6690 got published with an informative reference to CoAP, as WIP... I guess the WG wanted to get it out. I wish our process would let us update that reference to the RFC, because it confuses the rfc dependancy process) > The alternative is that we either have to use /.well-known/est, or that > we wind up standardizing something (maybe /e) that isn't inside > /.well-known. > Can DTLS compression do better things for us instead? > 2) DTLS and HelloVerifyRequest. > SHOULD CoAP-EST servers always perform the HelloVerifyRequest state? > Again, it's an extra round trip. Always doing it would simplify the > code paths on both ends. > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sun Nov 12 18:55:47 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39395128ACA for ; Sun, 12 Nov 2017 18:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 6C8RPl-T5m-g for ; Sun, 12 Nov 2017 18:55:24 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00059.outbound.protection.outlook.com [40.107.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446C2127B52 for ; Sun, 12 Nov 2017 18:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jga+7ux6wpz3DYjSE82L6hu4t2uhCXlLzmSgPz9kf3I=; b=gKDnwcq367meqczVZNA+BrkEjtip3jL8PVZCXCft8/Gl5zJK7eRNAJCtSUOMsbAfEFzXPcmID7gFlW8jR2w9PLdf9nHwdZwSQFKjy89cPe1PCM9Jf1TRt3ws817VWrVAc1znDjAyhUicunkEaADyyWwlZryZ/OrX14UPZevreL4= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 02:55:21 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0218.011; Mon, 13 Nov 2017 02:55:21 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Early warning: Rewrite of vanderstok-ace-coap-est Thread-Index: AdNcKf9COzJtOICCSM+68aI+fwgxvw== Date: Mon, 13 Nov 2017 02:55:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [2001:67c:1232:144:1d23:c4d:39b2:26ea] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:WeCFbkZ+g++MsxrLXBETNzoIaGdCEtmVYS/8e0rwroiYrEX1epdx6rFqvsX/0UxbfnCL6ZMhJnKfjjZ2TS/+/Js25meUjpgdXEzNdJ6GJFm0FvlmsTFIbss224HpaRRrewZ84R8nru+imcO+uidr5rVdCOLte1b3rSunX/leoQ9ECoaCZOq1se0XKwLHaOARsmyY+efQdQ64Etm1eei1OW3VjPItG4wMYr5c+3fMWpyOIAUIO0RMjMC33Z6aEDZoxpEncK0nK2UfOGhke5eni0QvBlXDrYejgHYgLdOlo5Em/eLXJtP2HvPDbaZ0bKpzm/l5tDtEdy4X6DvOYOVcYFMMX5OIXksk5tuBdeEEhDA=; 5:/0zDh8jnFk28NNz0cJLI11WpigwLs1XIZOiQT93pyzvpex2KNAs+jF8NWh0ZiF30vkhnz9fArrv66pFarxSJktsFYcNoEYfSVchEPuv3A1HcY9VIu1bkeKEKC7Nh0ciidaWxbOFvCZ+Ii2x/0i64/oHl1D78eP+88fOW8/C43fk=; 24:Lt9itO9baZf62UI9Na6cLVj9k+EjE2ntrjpFys5YGGMsMUj/Bz0uVB2JiIQuEGhbSnOQCDjOuiwJi1In/yoS9mxF0zAsT+NF7xefnn4XxqM=; 7:vpGwjaG6JE0wMCtUTg4o1k//sdiQoxRrdGxw/IaLXimi88r2ItG3Ry0vhxRsSKpvNtO/EZm4pM8KHk4buy7GV9Cfp/DpALBkP4XKLmUEUQrqAD+BZaXhMJWDcxhT9Wbe6NgcLCGtwmKJZEgpv0846OhZV/hL+efU8aY22quh3+z/ybnEoJkeQe5lweyYtWe6E1zYft9JcVTmHQnxRlHTV8VV6vXPut9dRlWIjtUO1oeTXNeBxYp+ksw/3VwJZ2ss x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 233f183b-de9e-4754-72a8-08d52a41facd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(6055026)(6041248)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(189002)(40434004)(199003)(53754006)(97736004)(230783001)(106356001)(33656002)(53936002)(790700001)(25786009)(86362001)(102836003)(8676002)(6116002)(50986999)(54356999)(99286004)(101416001)(5890100001)(5250100002)(2501003)(5660300001)(105586002)(316002)(2351001)(5640700003)(74316002)(72206003)(68736007)(8936002)(478600001)(2906002)(81166006)(5630700001)(6506006)(2900100001)(6916009)(189998001)(3280700002)(54896002)(7736002)(9686003)(1730700003)(81156014)(7696004)(55016002)(6306002)(3660700001)(14454004)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706D0E86B77EFB6BF038A01FA2B0AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 233f183b-de9e-4754-72a8-08d52a41facd X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 02:55:21.0552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:55:31 -0000 --_000_AM4PR0801MB2706D0E86B77EFB6BF038A01FA2B0AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I had provided comments on the EST over CoAP document in the past. Unfortun= ately, my recommendations have been ignored and instead the document went i= nto the other direction getting more complex with every draft version. I need something that just allows me to run EST over CoAP - nothing more. A= s a result, I don't want profiling, don't want normative dependency to the = ANIMA work, and don't want any relationship to IEEE 802.15.4. EST over CoAP= should be able to run in a variety of context and over a number of network= s. For this purpose I am planning to write a new draft during this week that c= overs only one thing, namely carrying EST over CoAP without any profiling a= nd without any new functionality. If someone is interested in collaborating with me please drop me a note. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB2706D0E86B77EFB6BF038A01FA2B0AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I had provided comments on the EST over CoAP documen= t in the past. Unfortunately, my recommendations have been ignored and inst= ead the document went into the other direction getting more complex with ev= ery draft version.

 

I need something that just allows me to run EST over= CoAP – nothing more. As a result, I don’t want profiling, don&= #8217;t want normative dependency to the ANIMA work, and don’t want a= ny relationship to IEEE 802.15.4. EST over CoAP should be able to run in a variety of context and over a number of networks.

 

For this purpose I am planning to write a new draft = during this week that covers only one thing, namely carrying EST over CoAP = without any profiling and without any new functionality.

If someone is interested in collaborating with me pl= ease drop me a note.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB2706D0E86B77EFB6BF038A01FA2B0AM4PR0801MB2706_-- From nobody Sun Nov 12 19:18:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C791274D0 for ; Sun, 12 Nov 2017 19:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TZhwLC48K3pU for ; Sun, 12 Nov 2017 19:18:21 -0800 (PST) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7E8127077 for ; Sun, 12 Nov 2017 19:18:20 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud7.xs4all.net with ESMTPA id E5GMeOmR3VNbYE5GMer041; Mon, 13 Nov 2017 04:18:19 +0100 Received: from 2001:67c:1232:144:9016:6f55:5e12:75b8 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 13 Nov 2017 04:18:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 13 Nov 2017 04:18:18 +0100 From: peter van der Stok To: Hannes Tschofenig Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <5291501da1447deb69d317e6e10e9ed9@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJVcjr3aCHfvnQuFaUPj3vfX4TGpzaamTZ1uJrMyb6thh+0GXsx1um1wvKD9IMb0eZgKVc9W/fjGUxcTZvfOXpndBOfB5ch11IRYfHb1xfs8I8kpamOE rjMR2u9o45zmqIAS7uVFmTb3UplI80+Vcuu6H2PX4T5jcOBjsF5ppwgFcJcQ3X+z5pxgLzjXpyR3r33sgozdUJcRIge+L/q+jWC54a0NpnSPefAOxTyiPue3 Archived-At: Subject: Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:18:24 -0000 Hi Hannes, thanks for the early warning. Looking forward to reading your version. Let's see afterwards how we continue ( one document or two complementary documents) cheerio, peter Hannes Tschofenig schreef op 2017-11-13 03:55: > Hi all, > > I had provided comments on the EST over CoAP document in the past. > Unfortunately, my recommendations have been ignored and instead the > document went into the other direction getting more complex with every > draft version. > > I need something that just allows me to run EST over CoAP - nothing > more. As a result, I don't want profiling, don't want normative > dependency to the ANIMA work, and don't want any relationship to IEEE > 802.15.4. EST over CoAP should be able to run in a variety of context > and over a number of networks. > > For this purpose I am planning to write a new draft during this week > that covers only one thing, namely carrying EST over CoAP without any > profiling and without any new functionality. > > If someone is interested in collaborating with me please drop me a > note. > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sun Nov 12 20:13:41 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBEF129407 for ; Sun, 12 Nov 2017 20:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 m3IBXFRnw0B8 for ; Sun, 12 Nov 2017 20:13:37 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0BE126D46 for ; Sun, 12 Nov 2017 20:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7636; q=dns/txt; s=iport; t=1510546416; x=1511756016; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6w8lZSyiIfuqnrQ2uWIny1IMsqVOtHj2xOPQIgdBuYQ=; b=XxRTABt39kUdAwAvgD1IVbh8mESULAvhlui5wmwoSJ/xIGU4JsbzvACY zwnkjQ+tg7jtLRdH+HffMCCJeoKe2A6LKzKJvq2HvTbyuWqusmaNsx71E TjX/31YTiH2vBDfACYNqQvkOep76lov6WRVXPiVZUuZuB9Jj7xvJk5P6g w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAQBcGwla/4cNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcWRuJwedP4F9kQiFWIIBCoU7AoRGQxQBAQEBAQEBAQFrKIU?= =?us-ascii?q?eAQEBAQMtQwIXAgEIEQQBASgHMhQJCAEBBAESCIk2ZK1RiwYBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgzSBNVKBVW2EJoRkARIBVYVCBaIqAo85hUCCHh2Fa4sllXc?= =?us-ascii?q?CERkBgTgBNiGBA296FUmCZIRfd4YigSSBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,387,1505779200"; d="scan'208,217";a="319829937" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 04:13:35 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAD4DZGI004507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 04:13:35 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 12 Nov 2017 22:13:34 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Sun, 12 Nov 2017 22:13:34 -0600 From: "Panos Kampanakis (pkampana)" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: Early warning: Rewrite of vanderstok-ace-coap-est Thread-Index: AdNcKf9COzJtOICCSM+68aI+fwgxvwACu/RA Date: Mon, 13 Nov 2017 04:13:34 +0000 Message-ID: <84a16e55cc914dfd8e75a04647c7e6ac@XCH-ALN-010.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.226.194] Content-Type: multipart/alternative; boundary="_000_84a16e55cc914dfd8e75a04647c7e6acXCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 04:13:38 -0000 --_000_84a16e55cc914dfd8e75a04647c7e6acXCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, I think the current draft offers that. The BRSKI EST APIs are not mandatory= to implement by any means. The bindings of just the EST (RFC7030) APIs exp= lained in the doc would suffice. If you are saying that the current doc is = too complicated, may that is something that can be addressed. If you are sa= ying that there need to be two docs, one for pure EST and one for the BRSKI= EST messages, maybe it makes sense. The list can chime in on that. Looking forward to your draft. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, November 12, 2017 9:55 PM To: ace@ietf.org Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est Hi all, I had provided comments on the EST over CoAP document in the past. Unfortun= ately, my recommendations have been ignored and instead the document went i= nto the other direction getting more complex with every draft version. I need something that just allows me to run EST over CoAP - nothing more. A= s a result, I don't want profiling, don't want normative dependency to the = ANIMA work, and don't want any relationship to IEEE 802.15.4. EST over CoAP= should be able to run in a variety of context and over a number of network= s. For this purpose I am planning to write a new draft during this week that c= overs only one thing, namely carrying EST over CoAP without any profiling a= nd without any new functionality. If someone is interested in collaborating with me please drop me a note. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_84a16e55cc914dfd8e75a04647c7e6acXCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes,<= /span>

I think the current dr= aft offers that. The BRSKI EST APIs are not mandatory to implement by any m= eans. The bindings of just the EST (RFC7030) APIs explained in the doc woul= d suffice. If you are saying that the current doc is too complicated, may that is something that can be addresse= d. If you are saying that there need to be two docs, one for pure EST and o= ne for the BRSKI EST messages, maybe it makes sense. The list can chime in = on that.

Looking forward to you= r draft.

Panos

 

 

From: Ace [mailto:ace-bounces@ietf.org] On= Behalf Of Hannes Tschofenig
Sent: Sunday, November 12, 2017 9:55 PM
To: ace@ietf.org
Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

 

Hi all,

 

I had provided comments on the = EST over CoAP document in the past. Unfortunately, my recommendations have = been ignored and instead the document went into the other direction getting= more complex with every draft version.

 

I need something that just allo= ws me to run EST over CoAP – nothing more. As a result, I don’t= want profiling, don’t want normative dependency to the ANIMA work, a= nd don’t want any relationship to IEEE 802.15.4. EST over CoAP should be able to run in a variety of context and over a number of ne= tworks.

 

For this purpose I am planning = to write a new draft during this week that covers only one thing, namely ca= rrying EST over CoAP without any profiling and without any new functionalit= y.

If someone is interested in col= laborating with me please drop me a note.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of= this email and any attachments are confidential and may also be privileged= . If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any othe= r person, use it for any purpose, or store or copy the information in any m= edium. Thank you.

--_000_84a16e55cc914dfd8e75a04647c7e6acXCHALN010ciscocom_-- From nobody Sun Nov 12 21:40:15 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D0127337 for ; Sun, 12 Nov 2017 21:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 UESwN7iJ3itp for ; Sun, 12 Nov 2017 21:40:12 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20066.outbound.protection.outlook.com [40.107.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C05124D6C for ; Sun, 12 Nov 2017 21:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GUqcQle5k0dZpzkbGpQDY5k58IsJo2tB8sOFOXYjj4c=; b=SQ8oFMVFfzS4kcOlCzpsdx5zjMa9UYmKXi5ko+Jp541Sdzc+5IW8MBQ8aqCBp8zT/yOOYNAn48W2DnkwQoLs+KxFxbYCuzDM5H0D8uBKm0ZYYaDg/Afl11mMisFuqOtG5pox4DNyTmgt4+gJv4Zg2RXmZm+RpINDo+Rtkzm6QV4= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 05:40:08 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::403b:850e:c32c:fad6%13]) with mapi id 15.20.0218.011; Mon, 13 Nov 2017 05:40:08 +0000 From: Hannes Tschofenig To: "Panos Kampanakis (pkampana)" , "ace@ietf.org" Thread-Topic: Early warning: Rewrite of vanderstok-ace-coap-est Thread-Index: AdNcKf9COzJtOICCSM+68aI+fwgxvwACu/RAAAMWQsA= Date: Mon, 13 Nov 2017 05:40:08 +0000 Message-ID: References: <84a16e55cc914dfd8e75a04647c7e6ac@XCH-ALN-010.cisco.com> In-Reply-To: <84a16e55cc914dfd8e75a04647c7e6ac@XCH-ALN-010.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [2001:67c:370:128:8d21:dc8c:4ac0:5c40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:AV1vQgZXBPGE8fuJbM0rrgGSpAE70DidWqBEEtT44oJfDKFL0So9YWMBVButgj9hOoWe35QZtP3MYr4TFQU3dBrPJSMDyyTvFoBZTAyxtBXP7JTk65FIHQvoJmcC51D2+7w7ChDhR6OkOYbphBlBJty2Ea4dM/NIU6EQpqUQuHl3Bn9v2kcEf0nsxxgbyd+VXClnmSfh/Phej2Vf49hsexcOvWy2H+RZmYiFw5Dfpqr6xc24fRTCLsKNqazUs6V0INooy6Eq/YAbo1o9m2QrVLbnhOF83qEI0C2RmkAxHLFNHAWDZK4sWsPitvP95SsAXjXEVV7fxWuzKi1V+r/ypD6ZiJ+w1iwTC5Hfs1RnKZg=; 5:hF7xJGob1ksNwIPEjXptkZ0NhvA3TZOgohPr1OwZtcjyyrRrRxX0195dkNRJP2VWGEQsAnI5AkJjH9kM5k4JIO/MI/YbBqbQETNt3oUIG/Qz+CD+sEsikU88RSkX06p44bibzkejJQKv3pqG40EEoHCFg9Z6UvprHnG1NV1DA3s=; 24:ZjcH4h2ImmmVIhlxUV9z22arV3rt+TywzHMaUuTQDQ7aUxJ1Au5ZsDHH1UStKNozWMapFeB44yZitqvf1p/SoU6c+tXixp4Wj/FcyEOfpjk=; 7:iaon6cAgTFosMPudJRXHcl3BJYameGbswHvJHeHfGdGQ2YBq2pyPnC7k/hn7iu4lp+rUOLUpmlm31RTRcmzDEmjkMaOHsVO1LRqhmbd7dBJuyNGzbILKb1UTis5QsRmGVqrwB0NeyzzuP3p6DLKQwfu5mJ2jJ4TRicB1NMm2h48+suHboT6gopsEeFsCMVBjysaNo9R5a5RvKAx/BC9XGZXWlsF7wa/o2FmIfhvuoAZHAN1Xv3ibQfhPT6abojr9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ab760bfb-ae3a-4628-275d-08d52a590005 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(199003)(53754006)(189002)(40434004)(81166006)(81156014)(2900100001)(6506006)(229853002)(2950100002)(74316002)(72206003)(478600001)(2906002)(68736007)(8936002)(14454004)(305945005)(6436002)(3660700001)(9686003)(189998001)(3280700002)(7736002)(55016002)(7696004)(6246003)(25786009)(102836003)(8676002)(6116002)(86362001)(97736004)(33656002)(53936002)(110136005)(230783001)(106356001)(105586002)(316002)(5660300001)(54356999)(99286004)(76176999)(53546010)(2501003)(101416001)(5890100001)(50986999)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab760bfb-ae3a-4628-275d-08d52a590005 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 05:40:08.2493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:40:14 -0000 I disagree with you, Panos. The normative reference, include among other things, [I-D.ietf-anima-bootst= rapping-keyinfra]. As you will see with my write-up there is a way to offer EST over CoAP supp= ort without creating any such dependency. This will allow for generic uses = of EST over CoAP, very much in spirit of the original spec EST spec Ciao Hannes From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 13 November 2017 12:14 To: Hannes Tschofenig; ace@ietf.org Subject: RE: Early warning: Rewrite of vanderstok-ace-coap-est Hi Hannes, I think the current draft offers that. The BRSKI EST APIs are not mandatory= to implement by any means. The bindings of just the EST (RFC7030) APIs exp= lained in the doc would suffice. If you are saying that the current doc is = too complicated, may that is something that can be addressed. If you are sa= ying that there need to be two docs, one for pure EST and one for the BRSKI= EST messages, maybe it makes sense. The list can chime in on that. Looking forward to your draft. Panos From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, November 12, 2017 9:55 PM To: ace@ietf.org Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est Hi all, I had provided comments on the EST over CoAP document in the past. Unfortun= ately, my recommendations have been ignored and instead the document went i= nto the other direction getting more complex with every draft version. I need something that just allows me to run EST over CoAP - nothing more. A= s a result, I don't want profiling, don't want normative dependency to the = ANIMA work, and don't want any relationship to IEEE 802.15.4. EST over CoAP= should be able to run in a variety of context and over a number of network= s. For this purpose I am planning to write a new draft during this week that c= overs only one thing, namely carrying EST over CoAP without any profiling a= nd without any new functionality. If someone is interested in collaborating with me please drop me a note. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Nov 13 05:16:06 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80D5128B91 for ; Mon, 13 Nov 2017 05:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 k7XPkp4ZG7TD for ; Mon, 13 Nov 2017 05:16:03 -0800 (PST) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EFC129422 for ; Mon, 13 Nov 2017 05:16:02 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud7.xs4all.net with ESMTPA id EEameTggxVNbYEEametwgK; Mon, 13 Nov 2017 14:16:00 +0100 Received: from 2001:67c:1232:144:9016:6f55:5e12:75b8 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 13 Nov 2017 14:16:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 13 Nov 2017 14:16:00 +0100 From: peter van der Stok To: Michael Richardson Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <10211.1510540324@obiwan.sandelman.ca> References: <14857.1510339262@obiwan.sandelman.ca> <10211.1510540324@obiwan.sandelman.ca> Message-ID: <2f2df7844afb1c07cd369393042afbd5@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKaK/khrPX7iMkbLuuDA6d5d7G5pfYUMoVbdRDKNcVnEoOswqQZ1U440LFzVY84HYKCoOXZEB4G3Gk3rjbcmlwzeGUY2Qi5ecB2dlht3Ke1417cz0thy GW2NivqNQsnzA1i6SgLKQIy5JsvSfmYncrU3zA/AovMHlKRtmNeTZFTCPM0ssvr++nv16kMMv0hLYAt7LdrGsUo8vCGORC2w7+Ys3wgIwsDe5M77TvCuCaPC Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:16:05 -0000 Michael Richardson schreef op 2017-11-13 03:32: > Michael Richardson wrote: > > Section 4.1 provides for the process to start with a discovery > > operation. > > ... > > > REQ: GET /.well-known/core?rt=ace.est > > > I can see the architectural reasons for why we do that, but I > really > > have to ask why if we really really need this extra round trip. > > Having read rfc6690 over again in order to implement this, I am now > further > convinced that using this mechanism as a way to shorten the > /.well-known/est > to something else is not entirely right. > > I can see how a CoAP multicast to /.well-known/core?rt=ace.est ought to > return a list of hosts that support EST, and that EST ought to be > returned in > a list of supported interfaces. > > I'm less convinced that we ought to be using this mechanism to shorten > /.well-known/est to /est (why stop there? can't we go to /?) > It seems like maybe a 301-like (Moved Permantly) reply from > /.well-known/est/*, but CoAP doesn't have 301 codes.... /.well-known/core is supposed to contain links. The links point to resources which can be at the host themselves or at other hosts. The example link for the resource with rt=ace.est is /est in the draft. Anything else than /est can be used; the chosen path name is SDO- or installation dependent. Indeed table 1 proposes to shorten the path names to the resources; these have received the same resource type (rt) in the discovery request half a page later. One could make them discoverable with different rt's. In the latter case, these rt's need to be registered and the path names become discoverable. Hope this clarifies. Peter From nobody Mon Nov 13 07:38:42 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF31286B2 for ; Mon, 13 Nov 2017 07:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SUvhsYBwN84x for ; Mon, 13 Nov 2017 07:38:40 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBFC127843 for ; Mon, 13 Nov 2017 07:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vADFca4Q001120; Mon, 13 Nov 2017 16:38:36 +0100 (CET) Received: from dhcp-9924.meeting.ietf.org (dhcp-9924.meeting.ietf.org [31.133.153.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ybFCv5YbMzDX8w; Mon, 13 Nov 2017 16:38:35 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <10211.1510540324@obiwan.sandelman.ca> Date: Mon, 13 Nov 2017 23:38:32 +0800 Cc: ace@ietf.org X-Mao-Original-Outgoing-Id: 532280312.419932-9a67ee635a0b27f0aca7cd2bd9b79f7d Content-Transfer-Encoding: quoted-printable Message-Id: References: <14857.1510339262@obiwan.sandelman.ca> <10211.1510540324@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:38:41 -0000 On Nov 13, 2017, at 10:32, Michael Richardson wrote: >=20 > I'm less convinced that we ought to be using this mechanism to shorten > /.well-known/est to /est (why stop there? can't we go to /?) Why do you think that a node can only have one EST endpoint? It should be possible to have many, and the client should be able to = choose the one that is actually doing the right thing for them. > It seems like maybe a 301-like (Moved Permantly) reply from > /.well-known/est/*, but CoAP doesn't have 301 codes=E2=80=A6. (The link-format self-description is exactly the replacement for the = HTTP 301 here. Same number of roundtrips...) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 13 16:05:34 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 968FE1200CF; Mon, 13 Nov 2017 16:05:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151061792856.6045.7576294710525857774@ietfa.amsl.com> Date: Mon, 13 Nov 2017 16:05:28 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-actors-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:05:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : An architecture for authorization in constrained environments Authors : Stefanie Gerdes Ludwig Seitz Goeran Selander Carsten Bormann Filename : draft-ietf-ace-actors-06.txt Pages : 33 Date : 2017-11-13 Abstract: Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-actors-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-actors-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 13 16:12:41 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4619D1200CF for ; Mon, 13 Nov 2017 16:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HD3ub-BYUeJF for ; Mon, 13 Nov 2017 16:12:37 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9802112421A for ; Mon, 13 Nov 2017 16:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vAE0CXTb016193 for ; Tue, 14 Nov 2017 01:12:33 +0100 (CET) Received: from dhcp-9924.meeting.ietf.org (dhcp-9924.meeting.ietf.org [31.133.153.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ybScv67NMzDXFS; Tue, 14 Nov 2017 01:12:31 +0100 (CET) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_8DD79E1E-3B50-4D55-B093-3B715751BC17" X-Mao-Original-Outgoing-Id: 532311148.54357-0af0da3d1b16e8629a4b2e4f6593b295 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 08:12:28 +0800 Message-Id: References: <151061792877.6045.899077932098408506.idtracker@ietfa.amsl.com> To: ace X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-actors-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:12:39 -0000 --Apple-Mail=_8DD79E1E-3B50-4D55-B093-3B715751BC17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have submitted an update to the actors draft, now addressing all = outstanding (in both senses of the word!) comments from Robin Wilton. I have not been able to coordinate this with all the authors, so I = expect one more editing round before WGLC. One thing we could do in that next round is to remove material that = really is about security considerations of IoT in general (and not about = security considerations of the actors model); we now have = draft-irtf-t2trg-core-security to point to. Ceterum censeo: I renew my plea to return to sane terminology. See (many of) you in 80 minutes... Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-ace-actors-06.txt > Date: November 14, 2017 at 08:05:28 GMT+8 > To: "Ludwig Seitz" >, = "Carsten Bormann" >, "Goeran = Selander" >, "Stefanie Gerdes" > >=20 >=20 > A new version of I-D, draft-ietf-ace-actors-06.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-ietf-ace-actors > Revision: 06 > Title: An architecture for authorization in constrained = environments > Document date: 2017-11-14 > Group: ace > Pages: 33 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-ace-actors-06.txt = > Status: = https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ = > Htmlized: https://tools.ietf.org/html/draft-ietf-ace-actors-06 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-ace-actors-06 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-actors-06 = >=20 > Abstract: > Constrained-node networks are networks where some nodes have severe > constraints on code size, state memory, processing capabilities, = user > interface, power and communication bandwidth (RFC 7228). >=20 > This document provides terminology, and identifies the elements that > an architecture needs to address, providing a problem statement, for > authentication and authorization in these networks. --Apple-Mail=_8DD79E1E-3B50-4D55-B093-3B715751BC17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have submitted an update to the actors draft, now = addressing all outstanding (in both senses of the word!) comments from = Robin Wilton.

I have = not been able to coordinate this with all the authors, so I expect one = more editing round before WGLC.
One thing we could = do in that next round is to remove material that really is about = security considerations of IoT in general (and not about security = considerations of the actors model); we now have = draft-irtf-t2trg-core-security to point to.

Ceterum censeo: I renew my plea to = return to sane terminology.

See (many of) you in 80 minutes...

Gr=C3=BC=C3=9Fe, = Carsten


Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-ace-actors-06.txt
Date: = November 14, 2017 at 08:05:28 = GMT+8
To: = "Ludwig Seitz" <ludwig.seitz@ri.se>, = "Carsten Bormann" <cabo@tzi.org>, "Goeran Selander" <goran.selander@ericsson.com>, "Stefanie Gerdes" <gerdes@tzi.org>

A new version of I-D, draft-ietf-ace-actors-06.txt
has been successfully submitted by Carsten Bormann and posted = to the
IETF repository.

Name: = = draft-ietf-ace-actors
Revision: 06
Title:= = An architecture for authorization in constrained environments
Document date: 2017-11-14
Group:= = ace
Pages: 33
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-ace-actors-06.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-ace-actors/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ace-actors-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ace-actors-06<= /a>
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-actors-06

Abstract:
=   Constrained-node networks are networks where some nodes have = severe
  constraints on code size, state = memory, processing capabilities, user
=   interface, power and communication bandwidth (RFC 7228).

  This document provides = terminology, and identifies the elements that
=   an architecture needs to address, providing a problem = statement, for
  authentication and = authorization in these networks.

= --Apple-Mail=_8DD79E1E-3B50-4D55-B093-3B715751BC17-- From nobody Mon Nov 13 18:57:20 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1979C127076 for ; Mon, 13 Nov 2017 18:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QbnbNElCjDfL for ; Mon, 13 Nov 2017 18:57:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02864127342 for ; Mon, 13 Nov 2017 18:57:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CB4E020008; Mon, 13 Nov 2017 21:58:53 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 380CE80CFA; Mon, 13 Nov 2017 21:57:17 -0500 (EST) From: Michael Richardson To: Carsten Bormann cc: ace@ietf.org In-Reply-To: References: <14857.1510339262@obiwan.sandelman.ca> <10211.1510540324@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:57:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> I'm less convinced that we ought to be using this mechanism to short= en >> /.well-known/est to /est (why stop there? can't we go to /?) > Why do you think that a node can only have one EST endpoint? It could have hundreds, I agree. Could also have hundreds of different IPs in the /64 answer. If it had more than one, then shortening would have to be done differently for each, I think. We already have /.well-known/est as well. > It should be possible to have many, and the client should be able to > choose the one that is actually doing the right thing for them. I'm pretty sure that I have no way to describe the logic to a client. >> It seems like maybe a 301-like (Moved Permantly) reply from >> /.well-known/est/*, but CoAP doesn't have 301 codes=E2=80=A6. > (The link-format self-description is exactly the replacement for the > HTTP 301 here. Same number of roundtrips...) yes, that's a good point, except that for the end-point that has the single end point at /.well-known/est, then there is no 301. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloKW4wACgkQgItw+93Q 3WVCmQgAkmC9Pyjefz1HM6wy8T0Kf2PD5MzMhF2O9j65tolf8w7LwkYoUgmj68Xr kKpKYegDaYhGwTVzaDzBR5phGbdCICvCytEc7VPLT6x/pxnC87MmnB+M46s/AUHC DgfUyLcjG9KaoHfb3dqPx6wFMo82KWIAewX1R9Doii8+NOvBnm9u7bcKbzaWs9jz R0au5BkAQm/vbzK7KTZ999WOE5MImmoT+lbY62dx/BVGIBSigLhR4AKMU5/s3GHi 636f/1DMEkkyY8wQHqJQ7btUSvoHUIRQUkJMcM+YLeWLj5H7BhQ7Oj4NCOJ8pHvJ m5zUC5PKE0Fz6UITzgCPtzns6bm47Q== =iAqh -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 14 01:59:25 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92E5124B09 for ; Tue, 14 Nov 2017 01:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 uzwUiftyPdER for ; Tue, 14 Nov 2017 01:59:21 -0800 (PST) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AEAA126DED for ; Tue, 14 Nov 2017 01:59:20 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 2A4D2201BB3 for ; Tue, 14 Nov 2017 09:59:17 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 14 Nov 2017 10:59:18 +0100 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> Date: Tue, 14 Nov 2017 10:59:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=YObImbj46ZUGhGQCD-gA:9 a=Q-6g0to3y7KFzokC:21 a=ODsFeaU0z7EW0oB7:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] Questions about draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:59:24 -0000 Hello ACE, during the IETF 100 session there were a number of questions on draft-ietf-ace-oauth-authz that I would like to bring to the list for feedback: 1.) Currently the framework requires the use of CBOR as data object format and of parameter name abbreviations. Some comments voiced the opinion that these requirements should be relaxed and the choice left to the profiles. I see the following options: a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED) b.) Remove all requirements (i.e. data format totally up to the profiles) c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing profiles to specify something else) What does the group think we should do? 2.) Should the work on Client Token (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) be in the draft or moved out to a separate document? Background: We designed Client Token to address the use cases where the client has intermittent connectivity and needs to receive information from the AS. 3.) What is the relationship to the Token Binding Work at OAuth (https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ? 3-bis.) To me it seems like this could go into a profile of the ACE framework. Would someone be willing to write such a draft? 4.) What parameters to put into the response to an unauthorized request (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)? Jim Schaad suggested to add information about the audience and scope the RS expects to grant access to the given resource (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) We have had some discussion on this topic already, but I have not seen a conclusive "decision" by the group (if such a thing can exist) as to what to do. 5.) Francesca suggested to allow the AS to return a list of possible profiles to the client in response to an access token request. Currently only one profile is selected and optionally returned by the AS (it could even be implicit and not be returned at all). Background: The way I was thinking this should work was that both the client and the RS need to be registered at the AS in order for the exchanges to work. I made the assumption (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) that the AS would already know which profiles both C and RS support, and thus just select the ideal one. What does the group think, should we instead allow for a list of profiles and let the client select which one to use? Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Nov 14 07:15:43 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07D12700F for ; Tue, 14 Nov 2017 07:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 lYpD9Tw0VIGg for ; Tue, 14 Nov 2017 07:15:40 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9E5124D6C for ; Tue, 14 Nov 2017 07:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vAEFFa5M024848; Tue, 14 Nov 2017 16:15:36 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:951d:873c:afdc:3ad4] (unknown [IPv6:2001:67c:1232:144:951d:873c:afdc:3ad4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ybrfw0wC9zDXSk; Tue, 14 Nov 2017 16:15:35 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> Date: Tue, 14 Nov 2017 23:15:32 +0800 Cc: "ace@ietf.org" X-Mao-Original-Outgoing-Id: 532365332.693141-8f3fa155c81c703db688bf295dfcc45b Content-Transfer-Encoding: quoted-printable Message-Id: References: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] Questions about draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:15:42 -0000 > On Nov 14, 2017, at 17:59, Ludwig Seitz wrote: >=20 > Hello ACE, >=20 > during the IETF 100 session there were a number of questions on = draft-ietf-ace-oauth-authz that I would like to bring to the list for = feedback: >=20 > 1.) Currently the framework requires the use of CBOR as data object = format and of parameter name abbreviations. Some comments voiced the = opinion that these requirements should be relaxed and the choice left to = the profiles. > I see the following options: >=20 > a.) Keep it as it is (i.e. CBOR and parameter name abbreviations = REQUIRED) >=20 > b.) Remove all requirements (i.e. data format totally up to the = profiles) >=20 > c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing = profiles to specify something else) >=20 > What does the group think we should do? Clearly (c) (RECOMMEND). If is good to have a common way of doing this, but if a profile has a = good reason to deviate, state that reason and deviate. > 2.) Should the work on Client Token = (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) = be in the draft or moved out to a separate document? >=20 > Background: We designed Client Token to address the use cases where = the client has intermittent connectivity and needs to receive = information from the AS. No opinion on document splitting. > 4.) What parameters to put into the response to an unauthorized = request = (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)?= >=20 > Jim Schaad suggested to add information about the audience and scope = the RS expects to grant access to the given resource > = (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) >=20 > We have had some discussion on this topic already, but I have not seen = a conclusive "decision" by the group (if such a thing can exist) as to = what to do. It should be up to the deployment what it wants to reveal here. So do provide a way to include this information, but do not require it. > 5.) Francesca suggested to allow the AS to return a list of possible = profiles to the client in response to an access token request. Currently = only one profile is selected and optionally returned by the AS (it could = even be implicit and not be returned at all). >=20 > Background: The way I was thinking this should work was that both the = client and the RS need to be registered at the AS in order for the = exchanges to work. I made the assumption = (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) = that the AS would already know which profiles both C and RS support, and = thus just select the ideal one. >=20 > What does the group think, should we instead allow for a list of = profiles and let the client select which one to use? I=E2=80=99m not quite convinced about the use case, but I also don=E2=80=99= t see much harm (this is a less-constrained, horizontal protocol). SAM = (AS) won=E2=80=99t necessarily be =E2=80=9Cclosely familiar=E2=80=9D = with C, so C (or the CAM component of it) may be able to make a better = choice. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 14 18:16:53 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AB1126D73 for ; Tue, 14 Nov 2017 18:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2xK9H_TBg398 for ; Tue, 14 Nov 2017 18:16:49 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F15127077 for ; Tue, 14 Nov 2017 18:16:48 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud9.xs4all.net with ESMTPA id EnFseFKIznIXbEnFse36TW; Wed, 15 Nov 2017 03:16:47 +0100 Received: from dhcp-9f62.meeting.ietf.org ([31.133.159.98]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 15 Nov 2017 03:16:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 15 Nov 2017 03:16:44 +0100 From: peter van der Stok To: Michael Richardson Cc: Carsten Bormann , ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <26702.1510628237@obiwan.sandelman.ca> References: <14857.1510339262@obiwan.sandelman.ca> <10211.1510540324@obiwan.sandelman.ca> <26702.1510628237@obiwan.sandelman.ca> Message-ID: <98d52582ea2f1c2c779c66daf7912140@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfC6EClCkl27qHXI98mAoHJzs/SpiHWWVKIY0O7y2qJJstpKdC15z+KvCNZor5Av0wuhOXDaaSXETmtMsVvRZXEaqnVrY18mG881/mOv4lk+C4CsiSjgW uom3+Ya9jMkO0MLx2iszUW+nWEiGXX26QHD1TCgUyD5d/Vg2MkW5jxj8jV3mX4fii8CCdBsYSV0HfYNko7RFXE/2xYHvFooOw+S6Cn9FThNjtSm9JjZOyip8 0too4jjIQfiwNGQinG8ItA== Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:16:52 -0000 Hi, Jim suggests to keep both the /.well-known/est/* entry-points and the optional short ones. Seems the right approach to me and gives the application the opportunity to shorten the request URIs. Michael Richardson schreef op 2017-11-14 03:57: > Carsten Bormann wrote: > >> I'm less convinced that we ought to be using this mechanism to > shorten > >> /.well-known/est to /est (why stop there? can't we go to /?) > > > Why do you think that a node can only have one EST endpoint? > > It could have hundreds, I agree. > Could also have hundreds of different IPs in the /64 answer. > > If it had more than one, then shortening would have to be done > differently > for each, I think. > > We already have /.well-known/est as well. > > > It should be possible to have many, and the client should be able > to > > choose the one that is actually doing the right thing for them. > > I'm pretty sure that I have no way to describe the logic to a client. > > > >> It seems like maybe a 301-like (Moved Permantly) reply from > >> /.well-known/est/*, but CoAP doesn't have 301 codes…. > > > (The link-format self-description is exactly the replacement for > the > > HTTP 301 here. Same number of roundtrips...) > > yes, that's a good point, except that for the end-point that has the > single > end point at /.well-known/est, then there is no 301. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Nov 15 12:36:27 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C8D127342 for ; Wed, 15 Nov 2017 12:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pS84HHnH4azv for ; Wed, 15 Nov 2017 12:36:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1760B124B18 for ; Wed, 15 Nov 2017 12:36:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D03EC20008; Wed, 15 Nov 2017 15:38:03 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 36CB381DB3; Wed, 15 Nov 2017 15:36:21 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org cc: Carsten Bormann , ace@ietf.org In-Reply-To: <98d52582ea2f1c2c779c66daf7912140@xs4all.nl> References: <14857.1510339262@obiwan.sandelman.ca> <10211.1510540324@obiwan.sandelman.ca> <26702.1510628237@obiwan.sandelman.ca> <98d52582ea2f1c2c779c66daf7912140@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Wed, 15 Nov 2017 15:36:21 -0500 Message-ID: <29222.1510778181@obiwan.sandelman.ca> Archived-At: Subject: Re: [Ace] some thoughts about vanderstok-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 20:36:25 -0000 peter van der Stok wrote: > Jim suggests to keep both the /.well-known/est/* entry-points and the > optional short ones. Seems the right approach to me and gives the > application the opportunity to shorten the request URIs. I agree. Do you think that est/requestvoucher should also be shortened to ../est/rv? I'm using the CoAP server rails plugin, "david"; I'm trying to add the ?rt=XXX mechanism to it. As is, it actually returns a value for every single defined target: I.e. it returns ,,<...> I attempting to fix this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Thu Nov 16 06:32:39 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB08120454; Thu, 16 Nov 2017 06:32:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151084275193.28337.11320329088585223771@ietfa.amsl.com> Date: Thu, 16 Nov 2017 06:32:31 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 14:32:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-09.txt Pages : 66 Date : 2017-11-16 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-09 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 16 06:34:59 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4861D1294DB for ; Thu, 16 Nov 2017 06:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NnVYeS27R8z1 for ; Thu, 16 Nov 2017 06:34:54 -0800 (PST) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEBD127137 for ; Thu, 16 Nov 2017 06:34:54 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id BDEFC204D94 for ; Thu, 16 Nov 2017 14:34:50 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 16 Nov 2017 15:34:51 +0100 References: <151084275234.28337.487498679030625717.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <151084275234.28337.487498679030625717.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 16 Nov 2017 15:34:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <151084275234.28337.487498679030625717.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=WgwJIo3SAAAA:8 a=7CQSdrXTAAAA:8 a=0FD05c-RAAAA:8 a=6dJUei-FWW49CdKgRUUA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=l1rpMCqCXRGZwUSuRcM3:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 14:34:57 -0000 Hello ACE, as promised during the ACE session, here is an update that addresses the IANA issues that were raised by Mike Jones (and some more). This update also rearranges the IANA section in a logical way and fixes a number of inconsistencies throughout the draft (mostly related to IANA definitions). /Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-09.txt Date: Thu, 16 Nov 2017 06:32:32 -0800 From: internet-drafts@ietf.org To: Ludwig Seitz , Samuel Erdtman , Hannes Tschofenig , Goeran Selander , Erik Wahlstroem A new version of I-D, draft-ietf-ace-oauth-authz-09.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 09 Title: Authentication and Authorization for Constrained Environments (ACE) Document date: 2017-11-16 Group: ace Pages: 66 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-09 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Nov 16 17:16:40 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A78126D0C for ; Thu, 16 Nov 2017 17:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OevkLqyBAlsD for ; Thu, 16 Nov 2017 17:16:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A09126CD8 for ; Thu, 16 Nov 2017 17:16:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4720820072 for ; Thu, 16 Nov 2017 20:18:22 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7E92182639 for ; Thu, 16 Nov 2017 20:16:35 -0500 (EST) From: Michael Richardson to: ace@ietf.org In-Reply-To: <8736.1510870569@obiwan.sandelman.ca> References: <0ad947db-efdc-ebcc-1b6f-6dd8b1074259@cisco.com> <8736.1510870569@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Ace] DTLS proxy in EST-coaps X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 01:16:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I'm slowly absorbing the contents of draft-vanderstok-ace-coap-est-02. I'm building draft-ietf-6tisch-zerotouch-join with the assumption that it might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP mechanism. I looked through section 6, and I don't understand why COAPS would be used From=20the Registrar through an ESTcoaps-to-HTTPS Proxy to the MASA. The Registrar as not in the constrained networks, and can speak HTTPS just fine. That's why we proxy the COAPS traffic to the Registrar, so that the Registrar does not have to live (entirely) in the constrained network. So, in the ANIMA BRSKI context, we have the Join Proxy to connect the insec= ure (unencrypted) network with the JRC as we can not assume the registar (JRC) = is within radio distance of all pledges. For EDHOC and DTLS-over-COAP, we can use the option as described in draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy stateless. For DTLS, I thought we had a few IDs on how to relay DTLS in a stateless ma= nner. I can't seem to find any (Yes, I did look through expired drafts too). Are there some options for DTLS? Is there a way to statelessly (on the join proxy) relay traffic? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloOOHMACgkQgItw+93Q 3WW96ggApRdwxyb86kS0Kw1f3gtX27j/feKuM78OR40DrYZ47sDpfWSY2nmOzTrK /DBOmDmv+hMixNoek6JtcHYJBxN09HzFQ8SSCjtXJS13KfKQ+M0b2T8LbjoiT7ZN spf9gpdEAxpIVnMyBcUij14wO81uKbNgyV6kq068r3mfU4f46WF1pVGfVcROdMfS TAl4ZGttXlEVCxRMQ4slzzx8I94HD59kgihS63GILaLO7SqbU/o97ae+kzCaEojk iIbpiPn/9/1mebiAWYgvc058f8JC/haDz1Ix0XnHgV5op0xHttvFa2SFO/yRSRRG MryCxh5KBPM3l1Ait5AbUVcWV/2aZQ== =IUGb -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 16 18:09:39 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58DE1274D2 for ; Thu, 16 Nov 2017 18:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FSwhz4nhFmVT for ; Thu, 16 Nov 2017 18:09:36 -0800 (PST) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A12F1274A5 for ; Thu, 16 Nov 2017 18:09:36 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud9.xs4all.net with ESMTPA id FW63eYZm2nIXbFW63eClc6; Fri, 17 Nov 2017 03:09:35 +0100 Received: from 2001:67c:1232:144:b48f:66d4:33ec:d810 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 17 Nov 2017 03:09:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 17 Nov 2017 03:09:35 +0100 From: peter van der Stok To: Michael Richardson Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <17202.1510881395@obiwan.sandelman.ca> References: <0ad947db-efdc-ebcc-1b6f-6dd8b1074259@cisco.com> <8736.1510870569@obiwan.sandelman.ca> <17202.1510881395@obiwan.sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfGo6NSQh9Y7xtupcPcEEN0DQgYkLfjxAwyLfvCzDXbP3PY+GBAaQoig8CaZMAl2EWS8HPEmZ3DTk+aJuJtQ2IvlUbcYo2ZfHiU7V6QOzqs2tf8QqiRyj CGy7Ghgb6Vg5sJWPIlhvH2hnjcLlmnEGPexRKMv8JY1DvOp5FroqL3bJE6vEQFZujgSMa+/VM9kNr+Xx5pOmYh9qWmM85DcG+gU2EDWp6jSI8JynoMsakPkX Archived-At: Subject: Re: [Ace] DTLS proxy in EST-coaps X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:09:39 -0000 > I'm slowly absorbing the contents of draft-vanderstok-ace-coap-est-02. > I'm building draft-ietf-6tisch-zerotouch-join with the assumption that > it > might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP > mechanism. Good > > I looked through section 6, and I don't understand why COAPS would be > used > From the Registrar through an ESTcoaps-to-HTTPS Proxy to the MASA. The > Registrar as not in the constrained networks, and can speak HTTPS just > fine. > That's why we proxy the COAPS traffic to the Registrar, so that the > Registrar does not have to live (entirely) in the constrained network. If this is a unrealistic use case, it should go from the document. > > So, in the ANIMA BRSKI context, we have the Join Proxy to connect the > insecure > (unencrypted) network with the JRC as we can not assume the registar > (JRC) is > within radio distance of all pledges. > > For EDHOC and DTLS-over-COAP, we can use the option as described > in draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy > stateless. > > For DTLS, I thought we had a few IDs on how to relay DTLS in a > stateless manner. > I can't seem to find any (Yes, I did look through expired drafts too). You mean expired est-coaps drafts? Indeed, the draft never considered these, assuming they were off topic and were adequately treated elsewhere. The next version of est-coaps draft will be less BRSKI oriented and I think the subject of stateless join proxy is off topic. (BTW they are systematically called "circuit proxy" in keyinfra draft). > > Are there some options for DTLS? > Is there a way to statelessly (on the join proxy) relay traffic? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Nov 16 23:49:26 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7068C128C84 for ; Thu, 16 Nov 2017 23:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 F2nbJLW_AAxt for ; Thu, 16 Nov 2017 23:49:21 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0048.outbound.protection.outlook.com [104.47.1.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB6112741D for ; Thu, 16 Nov 2017 23:49:20 -0800 (PST) Received: from VI1P121CA0003.EURP121.PROD.OUTLOOK.COM (129.75.24.209) by AM5P121MB0051.EURP121.PROD.OUTLOOK.COM (129.75.189.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Fri, 17 Nov 2017 07:49:18 +0000 Received: from HE1EUR02FT045.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::202) by VI1P121CA0003.outlook.office365.com (2a01:111:e400:e2b2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.15 via Frontend Transport; Fri, 17 Nov 2017 07:49:18 +0000 Received-SPF: Neutral (protection.outlook.com: 13.81.48.91 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-2.lighting.com (13.81.48.91) by HE1EUR02FT045.mail.protection.outlook.com (10.152.11.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12 via Frontend Transport; Fri, 17 Nov 2017 07:49:17 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (213.199.154.113) by autodiscover.lighting.com (10.0.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Fri, 17 Nov 2017 08:48:54 +0100 Received: from HE1P121MB0012.EURP121.PROD.OUTLOOK.COM (129.75.24.151) by HE1P121MB0011.EURP121.PROD.OUTLOOK.COM (129.75.24.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Fri, 17 Nov 2017 07:48:52 +0000 Received: from HE1P121MB0012.EURP121.PROD.OUTLOOK.COM ([fe80::1501:196e:f3e9:1dfc]) by HE1P121MB0012.EURP121.PROD.OUTLOOK.COM ([fe80::1501:196e:f3e9:1dfc%13]) with mapi id 15.20.0197.025; Fri, 17 Nov 2017 07:48:52 +0000 From: Sandeep Kumar To: Michael Richardson , "consultancy@vanderstok.org" CC: "ace@ietf.org" Thread-Topic: [Ace] DTLS proxy in EST-coaps Thread-Index: AQHTX0G77SE49NcaUUOJ4dQ6vAUqV6MX07aAgABcfCs= Date: Fri, 17 Nov 2017 07:48:52 +0000 Message-ID: References: <0ad947db-efdc-ebcc-1b6f-6dd8b1074259@cisco.com> <8736.1510870569@obiwan.sandelman.ca> <17202.1510881395@obiwan.sandelman.ca>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=sandeep.kumar@lighting.com; x-originating-ip: [82.173.121.77] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; HE1P121MB0011; 6:4EhGsWNW28O5+6v68VtINoFNjFcu52w7fboOj/w2dWQmz/kPtip29yBnlOGmuAhGsPeq5mhOqlC/6F1ob/j39brb8S1TkWz1OtFElopPgYwp76thN4bC0YyuEGnxagcpEPDJqbvcSLm0yCtMizgyLi2ldQboCwYOzFcSKUBgiYG/6/1TNGLYlj7AJJi7mL6cHR041tmi4OdiFOMlnyWrPnJYT51GEGrimQ3DcArrw0jFP6xKUct57j628TxVNMCLzR+2Td1KbQf2zKbyFeFVAfEvtx9JY/WkTwz6X8zOxV2Cqvpg/mqHBnEIWaEjs6UR0v7togl/Uc2khr/BiK7JO6wud69FHyMyrWw9vHVYPKo=; 5:CjIpDjCpCVFB/PkmxMcqZNrAlI94xCl0YKBXXIUtYCKQMPiaoGTFCZn/DLCO99iXpSYx96DwQKMps1MW9s9lVYJgm8bo5nh+wEKYxaxxBqQ62xVKh9r1T4VvixE/DUml971aEJTq2oWEOiECu3DwbNTn29r9nprz/Uvc+b7asec=; 24:la8zqf7drgm5bq6cG14SAy5yR08U80qzmPoWU1jbUTo2gGyrf4FPBSK6qnAmG94iMGcnCBYsewuTstjBTe3D1JT6CLlUXUr981ZsokP5HIo=; 7:0Aj/Inyj9jpVEFJJEYrMQwQ+iD6XraiBSLSbK5nFTe2cj0TgtnSmIhU7mM8cBUkvDTLdwTTmWvGR7xeGh8TgCUIcYFJnIYM436rE2IYo8kUIpqLDnpf7T6q8mivvUypaW58pDvl2TaWFo60pNQVQPh0j8jxMFehU5QgWUB9MvnHuuCwolBEhxlIxd0mXi6N2a5WRNduukEx/CC1pXOram2WU5eN+I/24Y1BZmJoldHKOlMT5P5L64I5PQ84FqxXY x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: ff4bad5b-1345-496d-244d-08d52d8fb4b9 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:HE1P121MB0011; X-MS-TrafficTypeDiagnostic: HE1P121MB0011:|AM5P121MB0051: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(21532816269658); UriScan:(21532816269658); x-exchange-antispam-report-cfa-test: =?us-ascii?Q?BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101?= =?us-ascii?Q?)(100105300095)(100000702101)(100105100095)(6040450)(2401047?= =?us-ascii?Q?)(5005006)(8121501046)(100000703101)(100105400095)(93006095)?= =?us-ascii?Q?(93001095)(10201501046)(3231022)(3002001)(6041248)(201703131?= =?us-ascii?Q?423075)(201702281528075)(201703061421075)(201703061406153)(2?= =?us-ascii?Q?0161123558100)(20161123564025)(20161123562025)(2016112355502?= =?us-ascii?Q?5)(20161123560025)(6072148)(201708071742011)(100000704101)(1?= =?us-ascii?Q?00105200095)(100000705101)(100105500095);SRVR:HE1P121MB0011;?= =?us-ascii?Q?BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101?= =?us-ascii?Q?)(100110300095)(100000802101)(100110100095)(100000803101)(10?= =?us-ascii?Q?0110400095)(100000804101)(100110200095)(100000805101)(100110?= =?us-ascii?Q?500095);SRVR:HE1P121MB0011;BCL:0;PCL:0;RULEID:(100000700101)?= =?us-ascii?Q?(100105000095)(100000701101)(100105300095)(100000702101)(100?= =?us-ascii?Q?105100095)(6095135)(2401047)(8121501046)(5005006)(1000007031?= =?us-ascii?Q?01)(100105400095)(3231022)(10201501046)(93006095)(93003095)(?= =?us-ascii?Q?3002001)(6055026)(6096035)(20161123561025)(20161123556025)(2?= =?us-ascii?Q?0161123563025)(201703131430075)(201703131448075)(20170313143?= =?us-ascii?Q?3075)(201703161259150)(201703151042153)(20161123565025)(2016?= =?us-ascii?Q?1123559100)(201708071742011)(100000704101)(100105200095)(100?= =?us-ascii?Q?000705101)(100105500095);SRVR:AM5P121MB0051;BCL:0;PCL:0;RULE?= =?us-ascii?Q?ID:(100000800101)(100110000095)(100000801101)(100110300095)(?= =?us-ascii?Q?100000802101)(100110100095)(100000803101)(100110400095)(4000?= =?us-ascii?Q?06)(100000804101)(100110200095)(100000805101)(100110500095);?= =?us-ascii?Q?SRVR:AM5P121MB0051;?= x-forefront-prvs: 049486C505 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(199003)(189002)(85714005)(7736002)(8676002)(105586002)(14454004)(189998001)(3660700001)(93886005)(8936002)(86362001)(4326008)(54896002)(9686003)(6306002)(3280700002)(68736007)(2900100001)(966005)(478600001)(53546010)(25786009)(6246003)(106356001)(236005)(81156014)(81166006)(7696004)(606006)(53936002)(50986999)(54356999)(74316002)(110136005)(76176999)(101416001)(2906002)(6506006)(66066001)(6436002)(316002)(55016002)(33656002)(97736004)(2501003)(2950100002)(102836003)(99286004)(5250100002)(6116002)(3846002)(229853002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P121MB0011; H:HE1P121MB0012.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1P121MB001239049944E7C08C39B5118D2F0HE1P121MB0012EURP_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0011 X-CrossPremisesHeadersFilteredBySendConnector: LIGHT-EDGE-2.lighting.com X-OrganizationHeadersPreserved: LIGHT-EDGE-2.lighting.com X-EOPAttributedMessage: 0 X-Matching-Connectors: 131553785578398797; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: HE1EUR02FT045.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.81.48.91; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(376002)(346002)(39860400002)(39380400002)(2980300002)(199003)(85714005)(189002)(97736004)(5660300001)(966005)(498600001)(356003)(68736007)(7736002)(606006)(2950100002)(106466001)(2900100001)(189998001)(7696004)(81156014)(53546010)(93886005)(16586007)(316002)(5250100002)(105586002)(110136005)(81166006)(74316002)(84326002)(25786009)(14454004)(99286004)(69596002)(8676002)(3846002)(6116002)(53936002)(236005)(55016002)(260700001)(102836003)(61614004)(2906002)(2501003)(4326008)(9686003)(6306002)(54896002)(6246003)(8936002)(50986999)(86362001)(66066001)(76176999)(229853002)(33656002)(54356999)(512954002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P121MB0051; H:LIGHT-EDGE-2.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT045; 1:aAuCX5jJufCqky+TLto5a1kYh1t+ur/JU7Fir92sLY4m5xK60RbcycVEl9RFZnO2o28e1jz7ISyt7ui9+mst6anGlBJVD5Fcd1ajl6muaZjFkPhghXGHsY8Ia36p2T2e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4628075)(201703131517081)(2017052603258); SRVR:AM5P121MB0051; X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0051; 3:Ea/Q2zftdWDN2vAxgYANXkwjE2d4yUyB3CUdI/dlxDVJcWlRTedg3ugel+pgV6Q9r2xhgDVaI5TY62P/M/olAWMriUHChVNVu4bTCleCogc2rBQx+UcqDm21TP4hexdHFwnJrtfoBD1uBDnqu5CWlGxamr/vljurSH4EposbsvtBF6Woz80kqpuYZSLe/WpQ9FsVEE6ivnNwgO7WPqEtnncO7n0xNccO8RVRuRwd8eIHcBU+by5aT/3vs1xB+9JNCM2csKjK+QWHDKUUT/ZmT2dGyUYDjF4svU8A3WpFy6e6VdCU85uNfwWaN4z65e6PrYUdr3V/RSSmsGMhg6nO1g==; 25:7TW5nAw2MX9Vw2+EEoVwv0EMSElDsVKOWfogdRqVJPNu1OH6AyvUDws7ggZTYEaDywEB4nDcY5fYJNmmv08ndplkcUwIpysH8OlmrvlKv+Se8UI2HfAeB3DNm6xMTpiSA2jVoqDlJYwvsrpl+kKf5/hOTiwOAAve85YGaFrZEl8IUpSsivF4TguJaPeQbChA4gx/Q/OHpRCmohG5bDwxwtu5Z0v7oEceD305VjrjVlq93AG00M7jsyAueiqglFR6OHQ+Gd0yLP1BmMwXNmdkhHAP40qnRd9+cEQqATg8zWqNv7Qp7PII7fMs5MlLfKnrKue5VwiCfN928sx4KwWnBw==; 31:P9I6tZL6I33Hmvd0f6ExfCDPnXpzqqs0eCmaLp3SEoFw9Nm4Xp7487lyiFpjRzlTtoIWDvWYHj+gsaUyiq2W+nWjfmsefN3RuCjtFOsDA//20sRT1Terfn8LRJMM+V9HmJNkTDLua7+kHyZHPfd/xdaN7ZP/G0kBkUSjWMq9MIJT57ZZJ+LkrvxBTMCEUTKHUBi6mVm+h8mXz71pI6gbRbPcCiikVxVttdF3YR5KkFY= X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0051; 4:vvJj5+n22HXjp6FBV3IKgHUc8spTEr8q4/cYsMTXWvKzSbXR8UwxQ/GfRlC0/6rekctl0yuIIvLIzY/ZeI4d2ZFuRgTmJV2/6iu0h+HFv24ajWW7sFhykX32tOsx4IJiYbmfSecF9HD2ctAbOkaS9ytlmwyvTpV2ojUa1DbY8abOO5l12Ne3hPnxJ5yg0t/NUJVfuTuNOHMFQtPeHUimLMDX4KL/565KT8nK28qLpRB6hOmHB/FZmUEQX4sOiz7wAj3Qq4MNPXtrAZkoq6YRwrXvhzlizeu2TEoUMx2452Mu8BXCcKPpfEMss5MI/Zup X-Forefront-PRVS: 049486C505 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5P121MB0051; 23:5W9uNGpOc/dlZ+aCSTxLEXYiUthk81aE8c+ios7V0?= =?us-ascii?Q?e8Q6RLiNodjdBz83ibxJr0MQiEStIdprErxgVx9Snhqi3vYAWGKXDzl8eVNt?= =?us-ascii?Q?LR11cIYR+K3P87+XvFjgpy9ClnuvUWtH7UdyJ1oy+sfSgpxauyd6NcdasMyX?= =?us-ascii?Q?vDa9YRH4LPG+qqwAQmkGnSzT1Lhce1q8Y9MoMQ2A6O6d4tU6+o8aCj/ob8ae?= =?us-ascii?Q?AGzfPY8hLA8nA4h9oxWqlj6IIMHRkOfRUxH9lHF5QiNm9ggFCkwwKRqtmGAb?= =?us-ascii?Q?JLoKlr0dLAZ6yywDDipgpdrBkiNss6+xNsrpsKUFwhzDcXwBm4XH2wk3Irbd?= =?us-ascii?Q?XjlBS/Ltyn2HV2C0+rpkEncjUSSP6NYcOT9aFh8NANEJ2PvqfGHNyjjXdzOM?= =?us-ascii?Q?XXTUCCmES1r8C5zVFky8h7EsIMQExyLtU+WIPoAvhDz+vWUep5yLWBO5828E?= =?us-ascii?Q?xIhu4DV4SPgM4y+ZRA16b9OKj8ApyknLHYRdHUHH1akNFWf14dBabBAgLhFd?= =?us-ascii?Q?XmNXSp5SN7a19+P3eiBlB9icVq5wxNIBTI1XPoZ+U4f9AaD3KpHGxEDtCVma?= =?us-ascii?Q?ka+ZxA5QWjym5otpffDfS/5Ze3rL4uSUrdYA/Km7zep+9q38WsFcyGe3t6Zh?= =?us-ascii?Q?MBsd9I1RxI3fszezyvvr5BTQYy8p4QHGwiRZM3G80Hi0fxvECv7kl6Yd9aF3?= =?us-ascii?Q?O6DxwCkpaqjUy7GuJxQeHEKH46GNOuvR/wVZE934LXiJNPARCRxrkbi3eVep?= =?us-ascii?Q?U9TEMxC8IH5ney9p1kN7GA9xGfM42cW5Gxt+DQs/r+ImeUI5vs3DdNo0PRL+?= =?us-ascii?Q?gQdoka69K7D4ZTJQZat6FnS3bSvWoJ42B5JuuN2eLEpqQslDeSL9cnZ4f0JT?= =?us-ascii?Q?WNqIW6e7yhNhFvuSPCHosbhfGtAA3zeurZbxpbmSeMi+hTg9RGZyt24mcNyu?= =?us-ascii?Q?KM/hIHw3AIEvZw/vcqL7ITMqu+XzvjJvkW8QY2oH8FZoF/ZGcwH+VQ1Z+o4q?= =?us-ascii?Q?VtGzt54RV5ePX8gPfCLjPHzcfcwSEz67nngowse/2AJL4e//SS6bQpsF3wwy?= =?us-ascii?Q?84nq30Pgz+IwiQWnZjSXMHjuj0Jz5lOq45qRs0FFBfOk9VoA62vHGZWHEjPw?= =?us-ascii?Q?MZQjy8Y52fnT7OoDws/Er/nbHpF0n2hIDzGa36fGoFxY7nrwK8MR5B7MuaxZ?= =?us-ascii?Q?U78Gw7mrIbem+VBpFx5i3pyTUbjODNy61ZJrcWFIGPqN1n75hp0wSAJrm0XF?= =?us-ascii?Q?8ffEK6PlsxtvKUe+ut/b19HsiHVCte1yVLEGRBzcis9cacyJATYPl1nsmuZG?= =?us-ascii?Q?axg+33Ct9iMdnxqWcxu1y3bCXTt8zLBjF4Su5HurGupACIVeGYrLOUfLb3VQ?= =?us-ascii?Q?4cho7LnztpPjesaQtkGTC52d3GVQDkyhVT+MvmOGdd3GVx2fb0TDeWZU/0Kz?= =?us-ascii?Q?XfqG/vfSXuntv6/t4fCi64FRx6McvI=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5P121MB0051; 6:DFTC7txDYFlOxzypJ3lhI+zzFLKhjdCd0YpIKHs2dWtaByHvcHx6YcMopsta6UNoDZOWFuM9wOoa0O8VF2ojyp1jam1kXTLrdxRSRIYGqvrfHmGO26dyMsQjoyvr48zASNp5vc9xjbSs8+UXf4RYHoDNXIYeklAxwq3OfB+Ft+E/Bz26HL6K0Mu3v2NbxcAH/XRO1l4OqTuSpxUaRlJgD/8wajko7H2370xCDdbSqOs1j+NinuqEtc6dFMTewdMvKdd3GuXAMqBJdYmEJ2Aw0jVlkFwrZ3pAQmQ+0B/pj1LKFQU8E99XQ2UDHSiMr6ANHKKVyCb4EKSYx1pY93ezy/Icz9VS2LLzdzOBgmCPDAU=; 5:lpElAxRaJkchNe82o01EpjkoZ6nYJhOkMPaos1nHQvyx0EQLMwM2zwhKGdD7/MnuoAoNl+xxtvFxIWrTkuWsVckk0SQ0TZ8O5OHRea+k9iinQGuKzN/9sHhiBoAiomZGZNfDw5ihgaFQwLuX9NNUfOBapVxo7P4wbN7Y46H/Izc=; 24:Kmr4UhiDHnvK97XDSyUnO9Pp1svL3rcZ0Ip+cKFu3K7e8nwFzmxADLg80dYMWmy6BGBd03q6N1MJBJONgtIK20DFv2tB016HvHLXSh5Oaw8=; 7:36LqVdTe2hzHo0j7MsucWUlf+AjGIJ49yjruG44aFVKaDo7dyCqhiLoNIe6U8UJFJZA/uEq95qgIC7b5NF3kRMeU79Zj2MGJGH6rAWUnlHMOLkzakWfoASJPl5WM6cxm0moHFXj22HHmw1ZztQW27K+j1j6QbFUkNK6YgeMWOWo55sViAAEMM/ogQNnvxhH7ovzjWH2nRSidbK/H/QLBA0IpdI8nb74I0G/g2odt3tHpHN3LPc+qlppC48cNHF5l X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2017 07:49:17.6367 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff4bad5b-1345-496d-244d-08d52d8fb4b9 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.81.48.91]; Helo=[LIGHT-EDGE-2.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P121MB0051 Archived-At: Subject: Re: [Ace] DTLS proxy in EST-coaps X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 07:49:25 -0000 --_000_HE1P121MB001239049944E7C08C39B5118D2F0HE1P121MB0012EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DTLS relaying draft was in DICE wg. The WG was not chartered for the activi= ty. Other SDOs picked it up and filed the gaps. Sandeep ________________________________ From: Ace on behalf of peter van der Stok Sent: Friday, November 17, 2017 3:09:35 AM To: Michael Richardson Cc: ace@ietf.org Subject: Re: [Ace] DTLS proxy in EST-coaps > I'm slowly absorbing the contents of draft-vanderstok-ace-coap-est-02. > I'm building draft-ietf-6tisch-zerotouch-join with the assumption that > it > might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP > mechanism. Good > > I looked through section 6, and I don't understand why COAPS would be > used > From the Registrar through an ESTcoaps-to-HTTPS Proxy to the MASA. The > Registrar as not in the constrained networks, and can speak HTTPS just > fine. > That's why we proxy the COAPS traffic to the Registrar, so that the > Registrar does not have to live (entirely) in the constrained network. If this is a unrealistic use case, it should go from the document. > > So, in the ANIMA BRSKI context, we have the Join Proxy to connect the > insecure > (unencrypted) network with the JRC as we can not assume the registar > (JRC) is > within radio distance of all pledges. > > For EDHOC and DTLS-over-COAP, we can use the option as described > in draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy > stateless. > > For DTLS, I thought we had a few IDs on how to relay DTLS in a > stateless manner. > I can't seem to find any (Yes, I did look through expired drafts too). You mean expired est-coaps drafts? Indeed, the draft never considered these, assuming they were off topic and were adequately treated elsewhere. The next version of est-coaps draft will be less BRSKI oriented and I think the subject of stateless join proxy is off topic. (BTW they are systematically called "circuit proxy" in keyinfra draft). > > Are there some options for DTLS? > Is there a way to statelessly (on the join proxy) relay traffic? > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email. --_000_HE1P121MB001239049944E7C08C39B5118D2F0HE1P121MB0012EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DTLS relaying draft was in DICE wg. The WG was not chartered for the activi= ty. Other SDOs picked it up and filed the gaps.

Sandeep
From: Ace <ace-bounces@i= etf.org> on behalf of peter van der Stok <stokcons@xs4all.nl>
Sent: Friday, November 17, 2017 3:09:35 AM
To: Michael Richardson
Cc: ace@ietf.org
Subject: Re: [Ace] DTLS proxy in EST-coaps
 

> I'm slowly absorbing the contents of draft-vanderstok-ace-coap-est-02.=
> I'm building draft-ietf-6tisch-zerotouch-join with the assumption that=
> it
> might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP
> mechanism.

Good
>
> I looked through section 6, and I don't understand why COAPS would be =
> used
> From the Registrar through an ESTcoaps-to-HTTPS Proxy to the MASA. The=
> Registrar as not in the constrained networks, and can speak HTTPS just=
> fine.
> That's why we proxy the COAPS traffic to the Registrar, so that the > Registrar does not have to live (entirely) in the constrained network.=

If this is a unrealistic use case, it should go from the document.
>
> So, in the ANIMA BRSKI context, we have the Join Proxy to connect the =
> insecure
> (unencrypted) network with the JRC as we can not assume the registar <= br> > (JRC) is
> within radio distance of all pledges.
>
> For EDHOC and DTLS-over-COAP, we can use the option as described
> in draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy > stateless.
>
> For DTLS, I thought we had a few IDs on how to relay DTLS in a
> stateless manner.
> I can't seem to find any (Yes, I did look through expired drafts too).=

You mean expired est-coaps drafts?
Indeed, the draft never considered these, assuming they were off topic
and were adequately treated elsewhere.
The next version of est-coaps draft will be less BRSKI oriented and I
think the subject of stateless join proxy is off topic. (BTW they are
systematically called "circuit proxy" in keyinfra draft).
>
> Are there some options for DTLS?
> Is there a way to statelessly (on the join proxy) relay traffic?
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Softwa= re Works
>  -=3D IPv6 IoT consulting =3D-
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf= .org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/= mailman/listinfo/ace

The information contained in= this email may be confidential and/or legally protected under applicable l= aw. The message is intended solely for the addressee(s). If you are not the= intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original email.
 --_000_HE1P121MB001239049944E7C08C39B5118D2F0HE1P121MB0012EURP_-- From nobody Fri Nov 17 01:02:51 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A5D129404 for ; Fri, 17 Nov 2017 01:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 r4XsjnfPPXcV for ; Fri, 17 Nov 2017 01:02:43 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0707312871F for ; Fri, 17 Nov 2017 01:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vAH92c1u025191; Fri, 17 Nov 2017 10:02:38 +0100 (CET) Received: from wangari.tzi.org (unknown [IPv6:2001:638:708:304:fa59:71ff:fe87:cb48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ydXFB2HHMzDWmD; Fri, 17 Nov 2017 10:02:38 +0100 (CET) From: Olaf Bergmann To: Ludwig Seitz Cc: "ace\@ietf.org" References: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> Date: Fri, 17 Nov 2017 10:02:38 +0100 In-Reply-To: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> (Ludwig Seitz's message of "Tue, 14 Nov 2017 10:59:17 +0100") Message-ID: <87zi7lnuq9.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Questions about draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:02:46 -0000 Ludwig Seitz writes: > 1.) Currently the framework requires the use of CBOR as data object > format and of parameter name abbreviations. Some comments voiced the > opinion that these requirements should be relaxed and the choice left > to the profiles. > I see the following options: > > a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED) > > b.) Remove all requirements (i.e. data format totally up to the profiles) > > c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing > profiles to specify something else) > > What does the group think we should do? I am in favor for (a) but (c) would be the more flexible choice for a future-proof framework. > 2.) Should the work on Client Token > (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) > be in the draft or moved out to a separate document? > > Background: We designed Client Token to address the use cases where > the client has intermittent connectivity and needs to receive > information from the AS. No opinion here. > 3.) What is the relationship to the Token Binding Work at OAuth > (https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ? > > 3-bis.) To me it seems like this could go into a profile of the ACE > framework. Would someone be willing to write such a draft? > > > 4.) What parameters to put into the response to an unauthorized > request > (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)? > > Jim Schaad suggested to add information about the audience and scope > the RS expects to grant access to the given resource > (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) > > We have had some discussion on this topic already, but I have not seen > a conclusive "decision" by the group (if such a thing can exist) as to > what to do. I suggest to add this information (as optional fields) to the response so the client knows what to request from AS. > 5.) Francesca suggested to allow the AS to return a list of possible > profiles to the client in response to an access token > request. Currently only one profile is selected and optionally > returned by the AS (it could even be implicit and not be returned at > all). > > Background: The way I was thinking this should work was that both the > client and the RS need to be registered at the AS in order for the > exchanges to work. I made the assumption > (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) > that the AS would already know which profiles both C and RS support, > and thus just select the ideal one. > > What does the group think, should we instead allow for a list of > profiles and let the client select which one to use? I think that negotiating the profile between C and AS is inevitable but returning a list of profiles with the AS-to-Client response might be difficult because there might be profile-specific claims that need to be included as well. I prefer a client-driven negotiation mechanism where the client may send the list of profiles it supports, and the server picks one of this list or returns an error if the resource server does not support any of these. If the client does not send this list, AS just picks one as described by Ludwig. Gr=C3=BC=C3=9Fe Olaf From nobody Fri Nov 17 01:38:59 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B2B127868 for ; Fri, 17 Nov 2017 01:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tW7BxcZipzn5 for ; Fri, 17 Nov 2017 01:38:55 -0800 (PST) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7221124D6C for ; Fri, 17 Nov 2017 01:38:55 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 39CCA2241EB; Fri, 17 Nov 2017 09:38:50 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 17 Nov 2017 10:38:51 +0100 To: Olaf Bergmann CC: "ace@ietf.org" References: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> <87zi7lnuq9.fsf@tzi.org> From: Ludwig Seitz Message-ID: <9fc73ae7-8741-5ba8-ff52-14ace08521e6@ri.se> Date: Fri, 17 Nov 2017 10:38:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87zi7lnuq9.fsf@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=nFsDmeAZn58wqwa1scMA:9 a=tBegGb05RrU_dMJY:21 a=ejzDzB23oFd76VqD:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Questions about draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 09:38:58 -0000 On 2017-11-17 10:02, Olaf Bergmann wrote: > Ludwig Seitz writes: > >> 5.) Francesca suggested to allow the AS to return a list of possible >> profiles to the client in response to an access token >> request. Currently only one profile is selected and optionally >> returned by the AS (it could even be implicit and not be returned at >> all). >> >> Background: The way I was thinking this should work was that both the >> client and the RS need to be registered at the AS in order for the >> exchanges to work. I made the assumption >> (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) >> that the AS would already know which profiles both C and RS support, >> and thus just select the ideal one. >> >> What does the group think, should we instead allow for a list of >> profiles and let the client select which one to use? > > I think that negotiating the profile between C and AS is inevitable but > returning a list of profiles with the AS-to-Client response might be > difficult because there might be profile-specific claims that need to be > included as well. > > I prefer a client-driven negotiation mechanism where the client may send > the list of profiles it supports, and the server picks one of this list > or returns an error if the resource server does not support any of > these. If the client does not send this list, AS just picks one as > described by Ludwig. > > Grüße > Olaf > Interesting point. We had a negotiation mechanism for profiles in an earlier version of the draft, and decided to pull it out again because it felt over-engineered, given the fact that the AS would know what profiles both C and RS support. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Fri Nov 17 05:49:39 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA27126FB3 for ; Fri, 17 Nov 2017 05:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 60xqdtsw5U_5 for ; Fri, 17 Nov 2017 05:49:37 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E159F126C19 for ; Fri, 17 Nov 2017 05:49:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A944720072; Fri, 17 Nov 2017 08:51:24 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25C1382B25; Fri, 17 Nov 2017 08:49:36 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org cc: ace@ietf.org In-Reply-To: References: <0ad947db-efdc-ebcc-1b6f-6dd8b1074259@cisco.com> <8736.1510870569@obiwan.sandelman.ca> <17202.1510881395@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] DTLS proxy in EST-coaps X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 13:49:38 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> So, in the ANIMA BRSKI context, we have the Join Proxy to connect the >> insecure (unencrypted) network with the JRC as we can not assume the >> registar (JRC) is within radio distance of all pledges. >> >> For EDHOC and DTLS-over-COAP, we can use the option as described in >> draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy >> stateless. >> >> For DTLS, I thought we had a few IDs on how to relay DTLS in a >> stateless manner. I can't seem to find any (Yes, I did look through >> expired drafts too). > You mean expired est-coaps drafts? Indeed, the draft never considered > these, assuming they were off topic and were adequately treated > elsewhere. I don't think that it was est-coaps. I think it was maybe 2 years ago, there were some proposals to proxy DTLS in a stateless way. I was sure at the time that a solution on top of CoAP would be better, so I didn't pay a lot of attention. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloO6O8ACgkQgItw+93Q 3WVvWwgAhPQmR/uvCLWvtavSN+tdx3nX6iLzCzoYg0YJlkE8Jg12alqifvs0eUTs aKTb36z49jG8IZ4A+4vvn5Dh/XrDtKk4CRymrFIYtrHHjLrLdd0DdLr1v3ofBV8k ACaf0fKp2LKxrwDuMkrIrhzfbXdf4ZjF/15NwAVn1W7n+0A5CNAyF31SC/EeFKx0 YrKB2FrPJChwe6ddPlPCbUbbdnfC7qEpROSOAC7tGUCDBFt7Vrdc5h8dfRuv/dpR yeaEOInoLkvQWnv50TD8c3OcAzDHbzbNyxiB7HJKSZMlqTTPOBMSKP4elNWo0uVS 8qO0p9mZkjoqs0+zApgAptZe7AWP+g== =Vuwp -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 17 06:11:55 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34411270B4 for ; Fri, 17 Nov 2017 06:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2mrI3Z8GRABh for ; Fri, 17 Nov 2017 06:11:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AAA126CB6 for ; Fri, 17 Nov 2017 06:11:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 043EC20072; Fri, 17 Nov 2017 09:13:41 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63AFC82B25; Fri, 17 Nov 2017 09:11:52 -0500 (EST) From: Michael Richardson To: Sandeep Kumar , "ace\@ietf.org" cc: "consultancy\@vanderstok.org" In-Reply-To: References: <0ad947db-efdc-ebcc-1b6f-6dd8b1074259@cisco.com> <8736.1510870569@obiwan.sandelman.ca> <17202.1510881395@obiwan.sandelman.ca>, X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] DTLS proxy in EST-coaps X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 14:11:55 -0000 --=-=-= Content-Type: text/plain Sandeep Kumar wrote: > DTLS relaying draft was in DICE wg. The WG was not chartered for the > activity. Other SDOs picked it up and filed the gaps. mcr> For DTLS, I thought we had a few IDs on how to relay DTLS in a mcr> stateless manner. I can't seem to find any (Yes, I did look through mcr> expired drafts mcr> too). I was reminded in a private email that the document I wanted was yours: https://tools.ietf.org/html/draft-kumar-dice-dtls-relay-02 but it does not detail what the DRY header would look like. I assume it has to fit into DTLS clothing so that it can be demux'ed. I was hoping that your document had already figured that part out. Perhaps you have some thinking you can share? Which SDOs picked up the gap, and where are the documents? Were there IANA allocations required? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloO7icACgkQgItw+93Q 3WWvbAf/dg+sVP0iRvbDrTqIsDfAzaofGd5kkOf8awxTKHzSjwNACbRuW08sP/oc eUEctoiTRLzby01MSNKSQ1BzxQuFvoaYyBE7XNl6rR/OOvnIoICPnO1dGEEXe0iY dRJjxKA71RReAcYp+fygh3QDwKpP8KBzB7G2JLqpZmc4s9h3MFHyV081CIDbder1 RtpjX+eU868qWKmJ610mHYmFYogZVwFS7QCfSAySjG7AoZaKSNMYuQlwzFyTplfK OJZV+PCI7EFE2lSWGfYnbHvXm8ugQGH+vEI9isNihgZCEQIaQ7fGiK5+6Vu9uNJA JIX9H7tYiQJD90vCcGjoiQvBEVo2+Q== =lq4T -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 17 06:47:41 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B9B126CB6 for ; Fri, 17 Nov 2017 06:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 ab9QZhsdoV3M for ; Fri, 17 Nov 2017 06:47:37 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D53E124B18 for ; Fri, 17 Nov 2017 06:47:37 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id j16so2106995pgn.9 for ; Fri, 17 Nov 2017 06:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GuOs5MkSszudsyIbQO5W32o6+HsURdoedoz55pScDfE=; b=apxZAR0uJ4OxvffCNlVS56ExvZkUl2++yX49pUAWDi+yEhzhqPBU4Ltr4ztzwDt9sm fkJrlv/fqk3Wm61x69sCTZ/IMkDLSFPvw33b9jsziPD2/v8sP0DmN9rVJYqSDg1/pQdj mVKmeaVC4nZog/jxIE1DrfppI+Qec6ct12Da12vejfNS1CjN1rwQXv+a02cWqk9hxt5q XQKDJYuUpPs3O6o/f+6FvsxvJjC3zxyPZUHxQ6f/fBxG54NvStMiW9by4uvpOKTt3Z0g rMzsKq0dx4WAfs2imTVhqvUoX1xtZz0WCktOmlWZwWR6jNUwuZQJek2BGe1XE7CKogF3 569g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GuOs5MkSszudsyIbQO5W32o6+HsURdoedoz55pScDfE=; b=IjnEj7f/wl1nt9BsG4Bp9tqsFZbds56U4aZv47ve/IK3+PMc19Fqn54dvhctNm0KB5 X6xC+8AM7Kuosd+++bb6+ausA9Ua24suN8mZh4ldx+u2xEdFggrnFnNRT/YS5v45q496 T+sT+A3e0PlBRLIHXprtUrZyppkPO+d+PSQSbLrSiBqHspjD/wpRy5cLgCzOWciywLgs Ohk5Pwqfvz5TQvOiEfC4qgh4xC1VR70cWAjEtL7cmG9gkZqwAqQkP0vNP6GZgO7QDpWu 9vpSllN3wGjsFtJsKydeSYYq8Mil8V8G1CsG2G7aK3JWEKM42vZwHyMc7ukppYrKEz1m 59ZQ== X-Gm-Message-State: AJaThX6qqFQoezW827frnZd/1UiM2LTvUlnYBr1NMbkfTHl8X+Q6SnJw j0HY6TW3ElAeH2TBqZ/Scd8iwhrC0GducofzFoUplxYyhag= X-Google-Smtp-Source: AGs4zMZmHXKuvxgkw8mcUl3EcOxwyz5A84yKh/SuAoE6TH9/GIxV6cdf2Avawk+24xmMsK65gFy1pd0HO7K5mewr9bQ= X-Received: by 10.101.77.201 with SMTP id q9mr5312496pgt.226.1510930056811; Fri, 17 Nov 2017 06:47:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.230 with HTTP; Fri, 17 Nov 2017 06:47:36 -0800 (PST) In-Reply-To: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> References: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> From: Samuel Erdtman Date: Fri, 17 Nov 2017 15:47:36 +0100 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="089e0825458c512c8b055e2ed1b1" Archived-At: Subject: Re: [Ace] Questions about draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 14:47:40 -0000 --089e0825458c512c8b055e2ed1b1 Content-Type: text/plain; charset="UTF-8" see inline On Tue, Nov 14, 2017 at 10:59 AM, Ludwig Seitz wrote: > Hello ACE, > > during the IETF 100 session there were a number of questions on > draft-ietf-ace-oauth-authz that I would like to bring to the list for > feedback: > > 1.) Currently the framework requires the use of CBOR as data object format > and of parameter name abbreviations. Some comments voiced the opinion that > these requirements should be relaxed and the choice left to the profiles. > I see the following options: > > a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED) > > b.) Remove all requirements (i.e. data format totally up to the profiles) > > c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing > profiles to specify something else) > > What does the group think we should do? > I vote for *c* > > > 2.) Should the work on Client Token (https://tools.ietf.org/html/d > raft-ietf-ace-oauth-authz-08#section-5.7.4) be in the draft or moved out > to a separate document? > > Background: We designed Client Token to address the use cases where the > client has intermittent connectivity and needs to receive information from > the AS. > I vote for separate document for Client Token, I like the idea but I think it comes as a natural extension to the framework. > > 3.) What is the relationship to the Token Binding Work at OAuth ( > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ? > > 3-bis.) To me it seems like this could go into a profile of the ACE > framework. Would someone be willing to write such a draft? > Agree > > 4.) What parameters to put into the response to an unauthorized request ( > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)? > > Jim Schaad suggested to add information about the audience and scope the > RS expects to grant access to the given resource > (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) > I liked Carstens comment "It should be up to the deployment what it wants to reveal here. So do provide a way to include this information, but do not require it." So +1 on that. > We have had some discussion on this topic already, but I have not seen a > conclusive "decision" by the group (if such a thing can exist) as to what > to do. > > 5.) Francesca suggested to allow the AS to return a list of possible > profiles to the client in response to an access token request. Currently > only one profile is selected and optionally returned by the AS (it could > even be implicit and not be returned at all). > > Background: The way I was thinking this should work was that both the > client and the RS need to be registered at the AS in order for the > exchanges to work. I made the assumption (https://tools.ietf.org/html/d > raft-ietf-ace-oauth-authz-08#appendix-D) that the AS would already know > which profiles both C and RS support, and thus just select the ideal one. > > What does the group think, should we instead allow for a list of profiles > and let the client select which one to use? > I think AS should return one profile, I would like to avoid negotiation, for now at least. > > > Regards, > > Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --089e0825458c512c8b055e2ed1b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
see inline

On Tue, Nov 14, 2017 at 10:59 AM, Ludwig Seitz <ludwig.seit= z@ri.se> wrote:
Hello ACE,

during the IETF 100 session there were a number of questions on draft-ietf-= ace-oauth-authz that I would like to bring to the list for feedback:

1.) Currently the framework requires the use of CBOR as data object format = and of parameter name abbreviations. Some comments voiced the opinion that = these requirements should be relaxed and the choice left to the profiles. I see the following options:

a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED)<= br>
b.) Remove all requirements (i.e. data format totally up to the profiles)
c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing profile= s to specify something else)

What does the group think we should do?

I vote for c
=C2=A0


2.) Should the work on Client Token (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) be in the draft or moved out to a separate document?
Background: We designed Client Token to address the use cases where the cli= ent has intermittent connectivity and needs to receive information from the= AS.

I vote for separate document for C= lient Token, I like the idea but I think it comes as a natural extension to= the framework.
=C2=A0

3.) What is the relationship to the Token Binding Work at OAuth (https://datatracker.ietf.org/doc/draft-ie= tf-oauth-token-binding/) ?

3-bis.) To me it seems like this could go into a profile of the ACE framewo= rk. Would someone be willing to write such a draft?
Agree



4.) What parameters to put into the response to an unauthorized request (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)?

Jim Schaad suggested to add information about the audience and scope the RS= expects to grant access to the given resource
(https://mailarchive.ietf.org/<= wbr>arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw)


I liked Carstens comment=C2=A0 "It shou= ld be up to the deployment what it wants to reveal here. So do provide a wa= y to include this information, but do not require it."
= So +1 on that.


We have had some discussion on this topic already, but I have not seen a co= nclusive "decision" by the group (if such a thing can exist) as t= o what to do.

5.) Francesca suggested to allow the AS to return a list of possible profil= es to the client in response to an access token request. Currently only one= profile is selected and optionally returned by the AS (it could even be im= plicit and not be returned at all).

Background: The way I was thinking this should work was that both the clien= t and the RS need to be registered at the AS in order for the exchanges to = work. I made the assumption (htt= ps://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D= ) that the AS would already know which profiles both C and RS support, = and thus just select the ideal one.

What does the group think, should we instead allow for a list of profiles a= nd let the client select which one to use?

<= div>I think AS should return one profile, I would like to avoid negotiation= , for now at least.
=C2=A0


Regards,

Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--089e0825458c512c8b055e2ed1b1-- From nobody Sun Nov 19 23:49:24 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7603129474 for ; Sun, 19 Nov 2017 23:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xV53PvODjy8p for ; Sun, 19 Nov 2017 23:49:20 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0069.outbound.protection.outlook.com [104.47.0.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B52412947B for ; Sun, 19 Nov 2017 23:49:20 -0800 (PST) Received: from VI1P121CA0006.EURP121.PROD.OUTLOOK.COM (129.75.190.16) by VI1P121MB0062.EURP121.PROD.OUTLOOK.COM (129.75.190.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Mon, 20 Nov 2017 07:49:17 +0000 Received: from VE1EUR02FT048.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::202) by VI1P121CA0006.outlook.office365.com (2603:10a6:821:2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.15 via Frontend Transport; Mon, 20 Nov 2017 07:49:17 +0000 Authentication-Results: spf=neutral (sender IP is 13.81.48.91) smtp.mailfrom=philips.com; sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.81.48.91 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-2.lighting.com (13.81.48.91) by VE1EUR02FT048.mail.protection.outlook.com (10.152.13.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12 via Frontend Transport; Mon, 20 Nov 2017 07:49:16 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.216) by autodiscover.lighting.com (10.0.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Mon, 20 Nov 2017 08:49:00 +0100 Received: from HE1P121MB0012.EURP121.PROD.OUTLOOK.COM (129.75.24.151) by HE1P121MB0012.EURP121.PROD.OUTLOOK.COM (129.75.24.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.15; Mon, 20 Nov 2017 07:48:57 +0000 Received: from HE1P121MB0012.EURP121.PROD.OUTLOOK.COM ([fe80::a0c8:e3a2:207d:b385]) by HE1P121MB0012.EURP121.PROD.OUTLOOK.COM ([fe80::a0c8:e3a2:207d:b385%13]) with mapi id 15.20.0218.017; Mon, 20 Nov 2017 07:48:57 +0000 From: Sandeep Kumar To: Michael Richardson , Sandeep Kumar , "ace@ietf.org" CC: "consultancy@vanderstok.org" Thread-Topic: [Ace] DTLS proxy in EST-coaps Thread-Index: AQHTX0G77SE49NcaUUOJ4dQ6vAUqV6MX07aAgABcfCuAAG1SAIAESy1Q Date: Mon, 20 Nov 2017 07:48:57 +0000 Message-ID: References: <0ad947db-efdc-ebcc-1b6f-6dd8b1074259@cisco.com> <8736.1510870569@obiwan.sandelman.ca> <17202.1510881395@obiwan.sandelman.ca>, <31595.1510927912@obiwan.sandelman.ca> In-Reply-To: <31595.1510927912@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL25mciBrZXkiLCJpZCI6IjQwODI5N2IzLTM4MzctNDY5NC05YWQzLWE4NjQxNmQ2N2RmNyIsInByb3BzIjpbeyJuIjoiQ2xhc3NpZmljYXRpb24iLCJ2YWxzIjpbeyJ2YWx1ZSI6Ik5vbi1DbGFzc2lmaWVkICg2NjYyNTI3NzQzNDMzKSJ9XX0seyJuIjoiSW50ZXJuYWxJbmZvcm1hdGlvblR5cGUiLCJ2YWxzIjpbXX0seyJuIjoiQ29uZmlkZW50aWFsSW5mb3JtYXRpb25UeXBlIiwidmFscyI6W119LHsibiI6IlNlY3JldEluZm9ybWF0aW9uVHlwZSIsInZhbHMiOltdfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuMTEuNCIsIlRydXN0ZWRMYWJlbEhhc2giOiJXdlFZd05pSVk5T1BwTjdDTUMzT2VXKzZpandpVjNWVHJaM3lNYmlTSk1FPSJ9 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=sandeep.kumar@lighting.com; x-originating-ip: [80.246.199.210] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; HE1P121MB0012; 6:7bFhICEi7dTirYNB1mwhbzCJd8T+Ian9uJCPufYVwsJXP6N6EcVaBT8DJzKlX+QBB3U2K3bSvYFtKNrvDWjEWQT/cJHtga27KjOA/FgWyt0r/EC8DFTtNU0Zui2s0WA2qz3tpWdP4P0m5jnYp7dlgw3+5DzLEFGGmllw8F2vElOnP5eNFg+01STKfqJ8ADA3WNYeOLZx7zTRE9JKw1ZgeCILz3FVpSRwfjn6PuMGfmzNy/LWn8hd98C9Lt0uOXbk0IOsP387S9StcjCyXAJCug0Sb+iuI+axauySL3/xibZNV4NnlYQ+Viglc2UOXW7YsGMHPHepqRYKYa7a+H0TTh7SsuOuHq7CpmXobwO5tyE=; 5:xlYzMzYPu04g91mi7hEzhnTzsk8u5DZ4S7xvx9UJpP2wKzhs3myk+nI4vCdHqLa3qP/MHe0DUqcZmf2jjX2XSnD+HGrXb4KsuRTNP7dnBXCbJBACTfDIrVdjqNeO2hWkWL8slUSY9O85c4n3Qnw7YmsAG5VaBXW1/ORy96vFrTw=; 24:Y3dESWZ+7oQUKieA7Cd+TAO43A7G+T+Ps5893P43dsi6kW3MouJUxRDXBf3SwsNxQZwwh4ikJBQCBBOLVfY2mzg/NHVJhWF2GEKDOtWO8IU=; 7:zLzgqRAgBIOnCrXtZHMN43ajr3ujSbJThfW5q51AowpynkxMdoMfzN83zRLlMz11KGFQxocTt+2r3Ystb/p0u1TqTjXPmUH9ALN91gArjNA8MiP5CJEJipgcC6ziGC/tteS7VAAOZsRS4dTR1lMfyi/DlqGFXlPImxp2zx9v/TePsJhiu/8m+E/OwvEaNO2NOQcqqIHl5hC9wCPxLJVqd//fekJh1mcXer0mSFga76CDlzz7qS5FfmTZPhmc5q9h x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 7cab3fbf-4d8f-4ce1-6e4c-08d52feb336e X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:HE1P121MB0012; X-MS-TrafficTypeDiagnostic: HE1P121MB0012:|VI1P121MB0062: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(260087099026482); UriScan:(260087099026482); x-exchange-antispam-report-cfa-test: =?us-ascii?Q?BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101?= =?us-ascii?Q?)(100105300095)(100000702101)(100105100095)(6040450)(2401047?= =?us-ascii?Q?)(8121501046)(5005006)(3002001)(10201501046)(3231022)(100000?= =?us-ascii?Q?703101)(100105400095)(93006095)(93001095)(6041248)(201611235?= =?us-ascii?Q?55025)(20161123562025)(20161123560025)(201703131423075)(2017?= =?us-ascii?Q?02281528075)(201703061421075)(201703061406153)(2016112356402?= =?us-ascii?Q?5)(20161123558100)(6072148)(201708071742011)(100000704101)(1?= =?us-ascii?Q?00105200095)(100000705101)(100105500095);SRVR:HE1P121MB0012;?= =?us-ascii?Q?BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101?= =?us-ascii?Q?)(100110300095)(100000802101)(100110100095)(100000803101)(10?= =?us-ascii?Q?0110400095)(100000804101)(100110200095)(100000805101)(100110?= =?us-ascii?Q?500095);SRVR:HE1P121MB0012;BCL:0;PCL:0;RULEID:(100000700101)?= =?us-ascii?Q?(100105000095)(100000701101)(100105300095)(100000702101)(100?= =?us-ascii?Q?105100095)(6095135)(2401047)(8121501046)(5005006)(1000007031?= =?us-ascii?Q?01)(100105400095)(3002001)(10201501046)(3231022)(93006095)(9?= =?us-ascii?Q?3003095)(6055026)(6096035)(20161123563025)(201703131430075)(?= =?us-ascii?Q?201703131448075)(201703131433075)(201703161259150)(201703151?= =?us-ascii?Q?042153)(20161123559100)(20161123556025)(20161123561025)(2016?= =?us-ascii?Q?1123565025)(201708071742011)(100000704101)(100105200095)(100?= =?us-ascii?Q?000705101)(100105500095);SRVR:VI1P121MB0062;BCL:0;PCL:0;RULE?= =?us-ascii?Q?ID:(100000800101)(100110000095)(100000801101)(100110300095)(?= =?us-ascii?Q?100000802101)(100110100095)(100000803101)(100110400095)(4000?= =?us-ascii?Q?06)(100000804101)(100110200095)(100000805101)(100110500095);?= =?us-ascii?Q?SRVR:VI1P121MB0062;?= x-forefront-prvs: 04976078F0 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(24454002)(189002)(13464003)(199003)(85714005)(2950100002)(3280700002)(97736004)(14454004)(7696004)(53936002)(6246003)(2906002)(3660700001)(93886005)(53546010)(68736007)(3846002)(81166006)(81156014)(8676002)(102836003)(6116002)(316002)(5660300001)(110136005)(86362001)(105586002)(55016002)(106356001)(6506006)(33656002)(6436002)(966005)(7736002)(229853002)(101416001)(8936002)(2501003)(305945005)(2900100001)(4326008)(74316002)(478600001)(50986999)(66066001)(25786009)(9686003)(76176999)(99286004)(6306002)(189998001)(54356999)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P121MB0012; H:HE1P121MB0012.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0012 X-CrossPremisesHeadersFilteredBySendConnector: LIGHT-EDGE-2.lighting.com X-OrganizationHeadersPreserved: LIGHT-EDGE-2.lighting.com X-EOPAttributedMessage: 0 X-Matching-Connectors: 131556377569488460; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR02FT048.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.81.48.91; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39380400002)(376002)(39860400002)(346002)(2980300002)(189002)(24454002)(13464003)(85714005)(199003)(110136005)(2501003)(99286004)(189998001)(6246003)(47776003)(97736004)(93886005)(6306002)(9686003)(2950100002)(46406003)(7696004)(3846002)(5660300001)(102836003)(23726003)(66066001)(316002)(53936002)(4326008)(6116002)(2900100001)(50986999)(966005)(8676002)(81166006)(81156014)(50466002)(74316002)(2906002)(55016002)(7736002)(305945005)(54356999)(76176999)(33656002)(68736007)(5250100002)(6506006)(86362001)(8936002)(53546010)(498600001)(69596002)(105586002)(106466001)(229853002)(14454004)(25786009)(8746002)(356003)(97756001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P121MB0062; H:LIGHT-EDGE-2.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR02FT048; 1:swzMl9jV2Qfs1ctwodIRVeZsLKP1/sJI5P75X+9e1DwPtb6mCgUfbhMn8DKOaidMlZlIWgNu7Kyr7wKW5QbyzG3nVuUxdA6csVUuS2yZdXECDkRGrbXumGme0zT36D+c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4628075)(201703131517081)(2017052603258); SRVR:VI1P121MB0062; X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0062; 3:sFkd8ui0wFzL9/EfZ+vSlQ4Xl2MSAp5wiPa2kJA9D4MvzuC8XBD5pjA3iwIyGcxhy+M0+qr5Gor+zmmnqQrDm5AD1ZsiV/BknorCLudIRsCbobTi1MSpmJeXZmWwrQrX/p5MeUB9EhukWwQo7IiWIv32dHR5LSZKsEH8N9TEh/esNS3mqxQPZdHOai4PkzrmjMXEYes8MfRIvMi/NlgwPbGRmrCvwbzV/z/wubCGAurRQIDvSrPgPuRLZrIxhRO1OWhRrJhWKIGZeRBYzLAAQBI9zxBtiA04MWvtZNwGxEp9cj7oBx4F8TwKbTjQ/UFe98lnbLmE5TtT9/ACnUmytw==; 25:kWPys+rYO8EEjIj7P3Im+ybSronhStfAuRu1KmSRtaFRSuzROdvY2paV2xvNcRAfocLxmviRqUWrABhFD3Ud1n/LAWqkOhEWBN0fnI8K3smXLN8ALvBPM6krga+copeHIohOatQW+aL9RC8oXFpKPSzBY0UCsh3tLPGtWJZwCB21r+H6jregeuu0wyzfAGsaKC4d7dfkhvVNYk38GKDCMXLJ1005R73uT+bY4A0fJg5xAEnPFklvlROSNbLgy689jxAJFaj+hyNAqUyod02KeautBKkfhG93lQGJBgFLZPNap/SIQKcyWhRYLdT0aPB0EjK6+Yq+eLtKCvdfSfu2gg==; 31:E5FERecrFx/HTEms9eCWbGu+K1LmWc/Y79+uOWcw2TrOZVYGH4nD8nI2s+M4pTC9N0FRD7wSm91fk1dZveAmU2jmu8o5DLo49UIklXC7HfNB8fgDLEIDdR4sIS97xqGUsSXrro73cT8Q9Wq295n8A00XJglGnOrYMLGPPaXEQyv2SgZH4c7a/mTzuZAdu49KvBxbu5Uv6UF8Ln9AJcBUNQ18s01Hob/dra4asMcLR5w= X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0062; 4:tTvX2HR6YfyyGr+2gWMLcTjvbOTEQZY4voDRxO98Tr5qXAK842tFSj47V9BLHEXtPt5hCou5M8eq30pRQj3amIUBZr80qo3OJl/ezh/ZnZcaIlBme3IgjihwHI+6hrcYylTuZXAVze8bXYKaZqZiqfBj7+YSixRBgog6m+pmP5cEeL6rBlxnzO773PuP3iXAE55p/d0iw8AFwVkZUhP7r+D+lsnFxfWeHTR871deTPj7YfHV0wvtzCGJ92OQmX4Fi6l4V0RXLdloA+sYRyZou6MgBXepLIAckyCaTrRRX1N0tLxsUk4YXs95f+Woj19/ X-Forefront-PRVS: 04976078F0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1P121MB0062; 23:S2ggFoa/GB2UTQ+uqT4VCRUYUMw8w+jNBchpxFBMh?= =?us-ascii?Q?sHYvytoRbWXZw4nEG25pkxHiUT6eMtZj2EbLyROscLXKeYHd9gMlUviKYHAL?= =?us-ascii?Q?eBFpFS+OLlrS9PDM08inxcYdr878+tU1oGS8yDWuI5qRM3qt/77Bkb7w6wLX?= =?us-ascii?Q?FLg3GK2f0YtHhDRjaHQ2oHzNKbwN5qT9VKpR+qAh4JEfk30sYaeWt7TEDbhv?= =?us-ascii?Q?DghEaeCRgvbwkhu1fY+0NVTfWce2UhW+DZi7+faVyT86O0V55m9h95o50Sqx?= =?us-ascii?Q?UiZQ5m9t5qilqL1mzNpOtLqwOHgeNeXcP1in+CIaYd4cg+NQYKT8B56GK3jq?= =?us-ascii?Q?jucWWFYjVtyA4k5GHK+sPl+xosDk0QYh5V+vm+j3CL2WRnZwrr0zFCUxMJpZ?= =?us-ascii?Q?ucVUtajshmyv2bfnyE3yJX0Cg8xJ9soZXeJNF57cONmWUIvnMAtjOm+d4hp7?= =?us-ascii?Q?vN1/ruDjNo4A9puaIQcdXiWkpnf+KICMR1+3aYvBh7N6yEhotSUKqfFxz5MJ?= =?us-ascii?Q?6a41oFF/HQU8lrUwSdIehLVlYayw1NouC4Ien0CDYW2+orVwdhEboOsBda+R?= =?us-ascii?Q?9TkChdPk/GtjQgR+KaQfLeA3SBqh6RabO3tzfd4ULVDVg7TeICnQrW6VgPQC?= =?us-ascii?Q?00IvuJzyRUU9QSvHAlRbmJcs+u+vCs8kqvYCpEja61hn1fhMZ1wsiv5RXe8T?= =?us-ascii?Q?jMFfL8b8KbfSA1Y4GQeHdZyJ7znhPtlrtsRezwhL6yW8du7+8Mpc7fkmzYEz?= =?us-ascii?Q?8u4zDc/7f6paejiUZBzYph8xgn7x9LtxDs1GnhjpJSS46TKKfQcVYo8UPZv8?= =?us-ascii?Q?GoefZz6Pqf1NpiKERaJHRCqjXwIaUtATM6YoAdtgvamJi9qTfnDKu0dUPPKy?= =?us-ascii?Q?QkZ8bbkYrjiFYQIr+PfJMQo3VPjxJGdMG4WxPVjD32oyTSbEbufkcO40vdzh?= =?us-ascii?Q?kdZVfjaqLWGKtt80/FOV4Yl/t3PjXEBqV/S12U1q1+b4GJSGpJ+ADD298Thk?= =?us-ascii?Q?jNcJETTADWpxBX2dQOIyqeB9xzV3D/wKHfr9o3WR31m5wmaewGokw7EPxj3s?= =?us-ascii?Q?Je8aNygamssMSPh+e6dWhn2QZUrDSrcv/G6/j7YA8djJRr/Kgb4cXMJX4jVf?= =?us-ascii?Q?X5HtRmiDUKyoZaINWvC+enuwxh3dOBKr19a8Gsh71N/DkxbHVd0V7Y1/1bky?= =?us-ascii?Q?8mVRqRZHR2e+JeR+ZVwnzXlWllc53tseDE0OXg5ulPtphyq8yYbdtmeOAysm?= =?us-ascii?Q?6OmK+MDyOWSpwKyIQ8eiXGzJANLHzwYhCa7xhGAVt9tphE25ib0kXXo+doNW?= =?us-ascii?Q?dp334hOcgevrCCuMHJPW0eMCdk41WfdDKw3OGIiCDpx1b97Y/hP8C75sjWMx?= =?us-ascii?Q?YqtOubTKWCbZk5dpdHjqfJKJLz+RS/2QUZXEfdVUrLCoznXSBIo9zV+CW/yz?= =?us-ascii?Q?E6Nk5lzB9MKQv40b/4xKVlSMs3THvl/wDddDqz6yoUN1cq9gd36rEJrTdGXa?= =?us-ascii?Q?VeyBeFp7NiMGw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0062; 6:A12xhzkuUPzUunrYLWESRXX4tjU9oLAkwXcvoWZjaUHxaRYws8XzH3HcdWCKGWRcTwMSz+tDSvZzdR1Gz6t3HNrgZnYfp6SuRQa6xOiauCOdfdjGkL8DRpYxy4A12hU0IV+tSSg4R10A1yyHJncahMwlaMpSN5gsiueYFFc6SGmvh1j4iDyOguXaEC/YlFPzy/F1WeYRHsOkjizXzGeEaqU79XrxqmHwtKdUPfskAl6TEvp6e4F/7e4rFx+YxiAtoYLMDnRWaM52lhRFQGZyMQ99T0ZMtnp+xcCbx8OLJ7LJGsnHetem02HhyFncKpXzX6SYVwI9Ram4tdpm+ljWz6gMUavzgUIKtx/caLg4Lg8=; 5:0cYnEw9/aOdZg4UyFjCRiK08PqLTcaZA8jsbiocqnYJ0NQ6tQ2/hYJM/Bbw83mWvq0dUSbkqJm9g/KB+7GMOhaDwgYQjCHlQv0W/KcxCPC2PiHcu4jGqf3nzzCMJlckS+CoCg/0LUNZw7avcOsADEadZw7NB/YBFDbjmlPNEEGY=; 24:yaq5By7PMPEcpHOfPup3HWnr1pcJsIf/hwsuqRUvZZ3fmaA5tJXZWebnjBl8GtzKE3vN6ygkZbh2sGG4SmpfHV0q/4LGh2v5MRiaj2Viwxk=; 7:VGQqNc2S8EVvYe0FBQwDG6NyecGTDcS4QyvaggziskeeyjIk36sxJvwj6V9AlP7lB7RbIjTu0keR97/nVxTUbd6iv7ewTfld+6kEMz4wj35f3rqa7FzVXZobDHu+gkijym+gFweMUg4PO6B1J5TaRdgr5Hw5/kwJ5PwrdBaIUlyG/CkBPqW0Im8hZIRAjvmpiufJYaL6NAkIIdfJJ3m9FeRPEzjQxRc9tKxesRzpmoQfa2NoqdsiwCNkncldTJNf X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2017 07:49:16.8550 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7cab3fbf-4d8f-4ce1-6e4c-08d52feb336e X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.81.48.91]; Helo=[LIGHT-EDGE-2.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0062 Archived-At: Subject: Re: [Ace] DTLS proxy in EST-coaps X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 07:49:24 -0000 Thread uses DTLS relay as a building block for bootstrapping. The DRY was s= olved with Thread specific messaging. You can find some details in their pu= blic whitepapers. -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] Sent: Friday, November 17, 2017 3:12 PM To: Sandeep Kumar ; ace@ietf.org Cc: consultancy@vanderstok.org Subject: Re: [Ace] DTLS proxy in EST-coaps Sandeep Kumar wrote: > DTLS relaying draft was in DICE wg. The WG was not chartered for the > activity. Other SDOs picked it up and filed the gaps. mcr> For DTLS, I thought we had a few IDs on how to relay DTLS in a mcr> stateless manner. I can't seem to find any (Yes, I did look throu= gh mcr> expired drafts mcr> too). I was reminded in a private email that the document I wanted was yours: https://tools.ietf.org/html/draft-kumar-dice-dtls-relay-02 but it does not detail what the DRY header would look like. I assume it has to fit into DTLS clothing so that it can be demux'ed. I was hoping that your document had already figured that part out. Perhaps you have some thinking you can share? Which SDOs picked up the gap, and where are the documents? Were there IANA allocations required? -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- ________________________________ The information contained in this email may be confidential and/or legally = protected under applicable law. The message is intended solely for the addr= essee(s). If you are not the intended recipient, you are hereby notified th= at any use, forwarding, dissemination, or reproduction of this email is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original email. From nobody Mon Nov 20 08:15:47 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF8129B74; Mon, 20 Nov 2017 08:15:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151119454541.21872.1552330728866436216@ietfa.amsl.com> Date: Mon, 20 Nov 2017 08:15:45 -0800 Archived-At: Subject: [Ace] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ace-dtls-authorize X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 16:15:45 -0000 Dear Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Göran Selander, Ludwig Seitz: An IPR disclosure that pertains to your Internet-Draft entitled "Datagram Transport Layer Security (DTLS) Profiles for Authentication and Authorization for Constrained Environments (ACE)" (draft-ietf-ace-dtls-authorize) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3112/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ace-dtls-authorize" Thank you IETF Secretariat From nobody Tue Nov 21 01:43:05 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823DE129443 for ; Tue, 21 Nov 2017 01:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 3xVAiY7dNSO8 for ; Tue, 21 Nov 2017 01:43:01 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0045.outbound.protection.outlook.com [104.47.2.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1848312943C for ; Tue, 21 Nov 2017 01:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GA/wXCG/jXrTrnaUFWS7/GiRDmzrpuJF50LIsu5ZjEU=; b=HAApaChQiexUeNqo5k1p/ZpfowUHC/6r11DBmRQp3Kgrf87HRKE41wo3kgB4X8FitUQTFPGcAXm4Fb5mZJVF4ZB/GpZMLk5/w0B9l13wub5Q05+OnU3N5+Y1p0rpbOn+4UeGjd/MKaQhUJXh95ZOl/L7WewokeQldFPFTF9FeNc= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 09:42:58 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 09:42:58 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Application Layer TLS Thread-Index: AdNirICUJkCFmJYSSCm/ASAY4sL+2Q== Date: Tue, 21 Nov 2017 09:42:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:KmuVZhpaBQHhO7Huamt+90pbgxHLOabg4/420jIpwZ0kjuIWbofKq4oQM3tu8gBxi7WJneiKwOgS/fekLEjvgekKxJJA0NT/SL+Gjqq8XhZlR4SR6mQAcVYVO4bE56jdmoLgoxkbThDJdanHgof/MljrBvRdQysrkM8XaA2ESOa71J6OMOip1wA+5b3uGnJlOkzyiIXSlYgqTsPsBdrwXzmc1Qayq9hYSmKWj4VUA4jtzvl2VwT32jwB1rbCwbE5g59QRGkU+9KAA82PA0RQgoAekKyT6vMQuPys3gsdeOGaP3NihHGHhBjozuK3papC9Mcu0LJg6ZHj2qV7frL+uI02l2cP+Jj8WoEEJ41fJfE=; 5:WA+CxZRTa+REttVplt4rIyxHS92pcBE2bLoMtiQspR9AfCNrEGUGcvZjD/RUORQVQZEX31l8GVOMyIPpwxfVSWV+nFVt8UXk3DJGCd3eIIYH43z8GiJu/OOHuicXDgUjEKaAmw76q6MZ3ICjzlPrRY/vkMZ8ErfX1hC+ph6SHE4=; 24:H4p11FiPksyrGP7J9u9oMqk49xMAB/dfGlbUk3uhRxPF5M54proHBy1iFAxFDooQKCksItSXhimmb4qCvUGoommAfpjrawX8BSbF7tFpz7g=; 7:L+Rau6dQ7yggdwoSSF6wBjpMQdoQuwF/08VJkYv5qsdYjQGZAegSzKy4AV7JBPabyMmKopu7evSKc+Y+kBf0M13xM6ujqwMgiiClCz0Fc8iYIjsAr8a9OiDTpdo/f/dOkDIf8zP5ooT74q0N2PDR3Hrm7xTCNbj4RLhwbsEGI3nkOooD/yb5OIyAWASSSGw9on4fhhQXRv2niFeTX3jflVbAQIAw5YhZ3fiiSUCm2lRYhcJSptfJeTM9D5ZRM6g0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b61d82e0-7f81-495d-ea0d-08d530c43fc0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(53754006)(40434004)(199003)(189002)(54356999)(50986999)(3280700002)(606006)(2906002)(7736002)(790700001)(3846002)(99286004)(102836003)(6116002)(2501003)(74316002)(81166006)(8676002)(81156014)(3660700001)(7116003)(5890100001)(33656002)(66066001)(1730700003)(101416001)(316002)(2351001)(106356001)(105586002)(7696004)(5660300001)(6916009)(72206003)(6506006)(5250100002)(6436002)(9686003)(54896002)(6306002)(478600001)(86362001)(14454004)(189998001)(966005)(97736004)(3480700004)(236005)(53936002)(8936002)(5640700003)(55016002)(25786009)(5630700001)(68736007)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706EA595581E0E6CAE3ED40FA230AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b61d82e0-7f81-495d-ea0d-08d530c43fc0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 09:42:58.3655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 09:43:03 -0000 --_000_AM4PR0801MB2706EA595581E0E6CAE3ED40FA230AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, based on the recent email discussion about the DTLS proxy I thought it migh= t be useful that there was some thinking about how to run TLS/DTLS at the a= pplication layer. There are essentially two drafts that have been submitted at the same time = for IETF#100, namely https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 https://tools.ietf.org/html/draft-friel-tls-over-http-00 Both teams have worked on prototypes and getting it to work was remarkably = simple. Maybe something for this group to look at. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM4PR0801MB2706EA595581E0E6CAE3ED40FA230AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

based on the recent email discussion about the DTLS = proxy I thought it might be useful that there was some thinking about how t= o run TLS/DTLS at the application layer.

There are essentially two drafts that have been subm= itted at the same time for IETF#100, namely

 

https://tools.ietf.org/html/draft-tschofenig-layered-tl= s-00

https://tools.ietf.org/html/draft-friel-tls-over-http-00

 

Both teams have worked on prototypes and getting it = to work was remarkably simple.

 

Maybe something for this group to look at.

 

Ciao
Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM4PR0801MB2706EA595581E0E6CAE3ED40FA230AM4PR0801MB2706_-- From nobody Tue Nov 21 02:07:00 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B54129443 for ; Tue, 21 Nov 2017 02:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PNaSAQAicNTx for ; Tue, 21 Nov 2017 02:06:56 -0800 (PST) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD7E129449 for ; Tue, 21 Nov 2017 02:06:56 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id CF80D22316F for ; Tue, 21 Nov 2017 10:06:52 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 21 Nov 2017 11:06:53 +0100 To: References: From: Ludwig Seitz Message-ID: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> Date: Tue, 21 Nov 2017 11:06:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=N659UExz7-8A:10 a=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=QLPfpYkryAO4RqcpiSkA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 10:06:59 -0000 On 2017-11-21 10:42, Hannes Tschofenig wrote: > Hi all, > > based on the recent email discussion about the DTLS proxy I thought it > might be useful that there was some thinking about how to run TLS/DTLS > at the application layer. > > There are essentially two drafts that have been submitted at the same > time for IETF#100, namely > > https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > Both teams have worked on prototypes and getting it to work was > remarkably simple. > > Maybe something for this group to look at. > > Ciao > Hannes I have a vague memory of a DICE draft for doing the DTLS handshake over CoAP a long time ago: https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 Can the original authors tell us why they didn't go further with that approach? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Nov 21 02:19:21 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D254129461 for ; Tue, 21 Nov 2017 02:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 RkFpRI0WBSyf for ; Tue, 21 Nov 2017 02:19:10 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D242129464 for ; Tue, 21 Nov 2017 02:19:10 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id 136so11261846qkd.4 for ; Tue, 21 Nov 2017 02:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OXfCmEvAzZDwbdAOt+QwSif1avj/YPBv3x8Zdig/fs8=; b=t3v0MYcyQlOtG9IUzcm04enb0KdtcUWbk86ZFQltp8i4V9WcrnGuLpn9103C2V+U9Y SbnfNCtKr35976wRbZs5BKboyKSga6SN71F1GoqfcZwJEKhAqlOHase0KWKkEWBVsoqD samx32oq1Df7p3VaRczdlmdQaAR5J34URYZ2DrafqRET2k+f21gMpECNaLGPHjgZzif2 ntr/n1nGinK7UvfAe9ZY8QxMVrtK6wl7FXBHQMXdaJaKmIcgFgntUHtBP+HuWyoivBsX Z87fVtPphTgkf5Mdff2Sh9QbJhXHbzS5E1ebX52bV8vjlcNbC51N38KFOGYmrKmfLtkC b5pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OXfCmEvAzZDwbdAOt+QwSif1avj/YPBv3x8Zdig/fs8=; b=oDCBv8DJDjZNU40zaD+Nd92h3udC48B4B6/cHmY4nQC2QR/QV+xZxX4GTEg8sJu/zI qnUvgac1YxBHj1ofE/rnjP48wyRR26VzPy/ZxydpUFwKhfwZ2ZZPazXcIpX6JE5Uf1gz Dd0q/bajSgEAtT7x7p97oJd+K3eN3PTn8kNmby2idJEsv9bZS8i76aDljVD+jZ+Lfct4 vFCKEfTUKlHli/VRkW3mhhcavVVUg/+inn4WkTHV/jO442QuliCc2CTO/caDK0CM3AgX BWYG/DAhsh/zYTgKJLKl48g8hf6F2M1Kxmb1EPiedTvfjOmOFQWNDp7HS4DcF90hMnjY JjjA== X-Gm-Message-State: AJaThX5gflsUZoYpxL6012tADYZrnqHCnmuPZ/o+2g0yXF1ysc2TScdr EsMTSr6juf1zqVON31O7hUZBTY4SeRrgyMVc/El63w== X-Google-Smtp-Source: AGs4zMZhPf2eUdRQ7xR7fnkrf+QPXlOC5/EvXMUSi1ta6LD5mD/VuoHS2Lo9+jvXsRnegAoyx65XhjUFVM8fF0/TNvY= X-Received: by 10.55.71.5 with SMTP id u5mr9322992qka.166.1511259549579; Tue, 21 Nov 2017 02:19:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.3.84 with HTTP; Tue, 21 Nov 2017 02:19:09 -0800 (PST) In-Reply-To: References: <151125895956.14726.11740003659885129774.idtracker@ietfa.amsl.com> From: Samuel Erdtman Date: Tue, 21 Nov 2017 11:19:09 +0100 Message-ID: To: "" , ace Cc: Ludwig Seitz , Marco Tiloca Content-Type: multipart/alternative; boundary="001a114a8d4a9dcf0e055e7b881d" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-erdtman-oauth-rpcc-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 10:19:13 -0000 --001a114a8d4a9dcf0e055e7b881d Content-Type: text/plain; charset="UTF-8" Hi, I have submitted draft-erdtman-oauth-rpcc under the OAuth WG as discussed during IETF 100. (Moved from ACE WG since the new credentials does not have any formal connection to the ACE documents, i.e. pure OAuth stuff) This document defines how to user Raw-Public-Key and Pre-Shared-Key with (D)TLS as client credentials. We think it is essential to define this for IoT devices since the classic client id and secret is not very suitable for devices with limited user interfaces. Comments, questions and reviews would be very appreciated. Cheers //Samuel ---------- Forwarded message --------- From: Date: Tue, 21 Nov 2017 at 11:09 Subject: New Version Notification for draft-erdtman-oauth-rpcc-00.txt To: Marco Tiloca , Ludwig Seitz , Samuel Erdtman A new version of I-D, draft-erdtman-oauth-rpcc-00.txt has been successfully submitted by Samuel Erdtman and posted to the IETF repository. Name: draft-erdtman-oauth-rpcc Revision: 00 Title: Raw-Public-Key and Pre-Shared-Key as OAuth client credentials Document date: 2017-11-20 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-erdtman-oauth- rpcc-00.txt Status: https://datatracker.ietf.org/doc/draft-erdtman-oauth-rpcc/ Htmlized: https://tools.ietf.org/html/draft-erdtman-oauth-rpcc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-erdtman-oauth- rpcc-00 Abstract: This document describes Transport Layer Security (TLS) authentication using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth client authentication. Although defined for TLS the mechanisms are equally applicable for DTLS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a114a8d4a9dcf0e055e7b881d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have submitted draft-erdtman-oa= uth-rpcc under the OAuth WG as discussed during IETF 100. (Moved from ACE W= G since the new credentials does not have any formal connection to the ACE = documents, i.e. pure OAuth stuff)

<= /div>
This document defines how to user Raw-Publi= c-Key and Pre-Shared-Key with (D)TLS as client credentials.

We think it is essent= ial to define this for IoT devices since the classic client id and secret i= s not very suitable for devices with limited user interfaces.

Comments, questions= and reviews would be very appreciated.
Cheers
//= Samuel



=
A new version of I-D, draft-erdtman-oauth-rpcc-00.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-erdtman-oauth-rpcc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Raw-Public-Key and Pre-Shared-Key = as OAuth client credentials
Document date:=C2=A0 2017-11-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-erdtman-oauth= -rpcc-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-erdtman-oauth-rpcc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-erdtman-oauth-rpcc-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-erdtman-oauth-rpcc-0= 0


Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) authent= ication
=C2=A0 =C2=A0using Raw-Public-Key and Pre-Shared-Key as new mechanisms for = OAuth
=C2=A0 =C2=A0client authentication.=C2=A0 Although defined for TLS the mech= anisms are
=C2=A0 =C2=A0equally applicable for DTLS.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a114a8d4a9dcf0e055e7b881d-- From nobody Tue Nov 21 02:24:34 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F051D129439 for ; Tue, 21 Nov 2017 02:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tcs.com 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 P8Ecr6BK2nzX for ; Tue, 21 Nov 2017 02:24:26 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14665129449 for ; Tue, 21 Nov 2017 02:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default; t=1511259865; x=1542795865; h=mime-version:in-reply-to:references:subject:from:to:cc: message-id:date:content-transfer-encoding; bh=u7F5R2YIuGfcC0ZoI0qvdCT7rqhB1KsFgo9ijH5xSLM=; b=dyisUQ4BjxMER8xsq8y6MPf5aGS/gHbkIm7bGLGIYpiz/2+O4SlCPQgy Y/QhIQvwCM4fyi7YkHvsQYYCPJB/km8LZB5nCoLSPAm/syriNZpGGszfA oxN/zOc5go8wKJH+vRbZPUOUvAynUNXNQZHXgsaAXf+AJnhb2a4koo6zk I=; IronPort-PHdr: =?us-ascii?q?9a23=3AQ0p3SxdkhUxef3NXMU31xmcflGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcW+ZR7h7PlgxGXEQZ/co6odzbaO6+awBCdYsd6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVr?= =?us-ascii?q?O+/7BpDdj9it1+C15pbffxhEiCCybL9uMBm6twbcu8kZjYd+Kas61wfErGZPd+?= =?us-ascii?q?lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2466svrtQLe?= =?us-ascii?q?TQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUjms86tnVBnlgz?= =?us-ascii?q?ocOjUn7G/YlNB/jKNDoBKguRN/xZLUYJqIP/Z6Z6/RYM8WSXZEUstXSidPAJ6z?= =?us-ascii?q?b5EXAuUOPulWtYvyp1UToxW+GweiB+3hxDhQiHDq0qM3yPghERjc0QA8G9ICrG?= =?us-ascii?q?nYodPoP6kSS+C1y6zIwC3fYvxN2Tf96YrIfQonofqRQL9wcdDeyVUzFwzfklqQ?= =?us-ascii?q?qZbqPymV1+UNqWeQ8u1tWvi0hG4nqgFxoCKgxsE2hobShoIa0EzE9Tljz4kpJd?= =?us-ascii?q?23UlR7YN6kEZRKrCyaK5d5Qtg4T250vyY6z6QLtJimdyYEz5QnwgTQa/2Bc4WQ?= =?us-ascii?q?4xLsSvqRITliiHJiYrK/iA6+8VS8xe3nTMW7zFFKri9dntnNqH8CyQLc5tKASv?= =?us-ascii?q?tn8Ues3yuE2QPL6uxcPEw5l7TXJ4Q8zrMzjJYfr0rOEjX5lUjwkaSYbF8r+vKy?= =?us-ascii?q?5OTierjmo5icOJJqhQzmKaQun9C/Afw/MggTQ2iX4eS826Pn/U3+WLhEjeU4nK?= =?us-ascii?q?zAvp7cOMoWuqi3DQFT3Ig57BixESur3MkAkXkGKlJKZg6HgpD0N1zMPvz0F+qz?= =?us-ascii?q?jle2nDt1yf3KJLLsDo3ILnfZkbfhebh961RbyAo21d1Q/YlbCrEAIPLxQEDxss?= =?us-ascii?q?bUAQQ5MwOu3+bnFM9y2Z8eWW2VGK+YMKPTvkWT6+IzP+aMf5UZtyr6K/gg//Lu?= =?us-ascii?q?l2M2mUcBfam12psacGq3Eeh4LEiCYHrjnMsBEWkQsgo5Vuzqh0WIUSRPaHaqQ6?= =?us-ascii?q?I8+jY7BZqiDYfeW4+sjr2B3CihEp1NeG9GC0yMEHbzeoWeWvcAcjmSLdEy2gAD?= =?us-ascii?q?AJy8R5Ag2lmVuQ7m2fIzKvfY5SwX84nu1cRnz/fS0wo/o29aFcOYhkiHT2B2l2?= =?us-ascii?q?VAbT8/wLx2qkx00EaS2OAsivZYFN5a4bVDUg4mKZfXz+VgGsH7ch7KZZGCT1Pw?= =?us-ascii?q?EYbuOi04Ut9km4xGWE16Adj3y0mbhyc=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AhAQAA/hNa/wQXEqxbGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQigRUTnzKHOY8pEIIBIguFGAKFRBYBAQEBAQEBAQEBgRKCOCQ?= =?us-ascii?q?BgkEBAQEEAQE6ATELDgIFBg0EAwECAScHGwwfCQgGCwgRCooXp1UBAQGDE4sCA?= =?us-ascii?q?QEBAQEBAQMBAQEBAQEBASAFgy+CKXWCJ4MrhGgBEgEfg0KCNgWTB483gjeFO5A?= =?us-ascii?q?SkFSMcop6JgWBMHF6XoJkCYReb4k+gjgBAQE?= X-IPAS-Result: =?us-ascii?q?A2AhAQAA/hNa/wQXEqxbGQEBAQEBAQEBAQEBAQcBAQEBAYQ?= =?us-ascii?q?igRUTnzKHOY8pEIIBIguFGAKFRBYBAQEBAQEBAQEBgRKCOCQBgkEBAQEEAQE6A?= =?us-ascii?q?TELDgIFBg0EAwECAScHGwwfCQgGCwgRCooXp1UBAQGDE4sCAQEBAQEBAQMBAQE?= =?us-ascii?q?BAQEBASAFgy+CKXWCJ4MrhGgBEgEfg0KCNgWTB483gjeFO5ASkFSMcop6JgWBM?= =?us-ascii?q?HF6XoJkCYReb4k+gjgBAQE?= X-IronPort-AV: E=Sophos;i="5.44,432,1505759400"; d="scan'208";a="270081482" MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se>, From: Abhijan Bhattacharyya To: Ludwig Seitz Cc: Message-ID: Date: Tue, 21 Nov 2017 15:53:39 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP8HF242 May 5, 2017 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/21/2017 15:53:39, Serialize complete at 11/21/2017 15:53:39, Itemize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/21/2017 15:53:39, MIME-CD by smdreal on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/21/2017 15:53:42, MIME-CD complete at 11/21/2017 15:53:42, Serialize by Router on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/21/2017 15:53:43 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 10:24:31 -0000 Just to keep it on record: We also had a draft which may find some relevance in the present context: https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00 Related publication: http://ieeexplore.ieee.org/document/7096256/ With Best Regards Abhijan Bhattacharyya Associate Consultant Scientist, TCS Research Tata Consultancy Services Building 1B,Ecospace Plot - =A0IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- 033 66884691 Cell:- +919830468972 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"Ace" wrote: ----- To: From: Ludwig Seitz Sent by: "Ace" Date: 11/21/2017 03:37PM Subject: Re: [Ace] Application Layer TLS On 2017-11-21 10:42, Hannes Tschofenig wrote: > Hi all, > > based on the recent email discussion about the DTLS proxy I thought it > might be useful that there was some thinking about how to run TLS/DTLS > at the application layer. > > There are essentially two drafts that have been submitted at the same > time for IETF#100, namely > > https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > Both teams have worked on prototypes and getting it to work was > remarkably simple. > > Maybe something for this group to look at. > > Ciao > Hannes I have a vague memory of a DICE draft for doing the DTLS handshake over CoAP a long time ago: https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 Can the original authors tell us why they didn't go further with that approach? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D 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 nobody Tue Nov 21 02:49:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C42126CB6 for ; Tue, 21 Nov 2017 02:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 NHF4Ffin9yiq for ; Tue, 21 Nov 2017 02:49:16 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0075.outbound.protection.outlook.com [104.47.0.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0814E126BF3 for ; Tue, 21 Nov 2017 02:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UdKHqQn9TUS5ghD05XKCJCSNC13ILtW08XuoA017VLM=; b=TAijtIgRxoSQWQGEKtw9zmZoYLxptHI7EkEyaPZERHu3CGfRSkcUw7e0Siz8u5j1p90rpz6ax+LAK4pYxg3PJQo9hMuMc6ofpz8ZuU3mu9WIBwtjfH6TgupqyOveJ5DVi/6dm4ovYtWTRDAszPNDq63bY3XlH5EyTGGcxDxc1bg= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2707.eurprd08.prod.outlook.com (10.167.90.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 10:49:13 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 10:49:13 +0000 From: Hannes Tschofenig To: Abhijan Bhattacharyya , Ludwig Seitz CC: "ace@ietf.org" Thread-Topic: [Ace] Application Layer TLS Thread-Index: AdNirICUJkCFmJYSSCm/ASAY4sL+2QAA/PKAAACV6IAAAOFR0A== Date: Tue, 21 Nov 2017 10:49:12 +0000 Message-ID: References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.119.33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2707; 6:DZFLA2OYuwjhN8uXJxzrU1feE9fkbjXWny6BtBoxTvdB8PVFmHtvUbqxwRcrK9UBilxQgm0zVJBHdmH4I/sR+Jqu6NS8zAafM9tZ7b3viq8Cnyd9DpXrZJhCDBGYnRVtSHWcPVGxxmF6Nq1dCVPWMfKkmm3/NaFHOenSj451piIPRTeQNDGuHSWckjxaSUDG1g6c7ge3E/PTf0LJFtDees0eY7BxUAF9DIhGe7LRLPvdCZFAPfYNwf2ykG5iKlOmLwEk/jFq345iEeE5i1SVjg4cw4DUaLw0Wg60OuWBsyDH5hvKP5nVdnX8ieRuyg8gCBouSFZV3FzQ7pfUWtYDasMg+11B5ZRql9LQG5Y55Lw=; 5:siF14UboK+KPLBcvI+LyiikzLHqTA65E4xxJFrtqaUjjMISn6ZaCSOfnLAxvtoDf34fokhENIeLweCBJduma6SJk7aDZfXuOsOySb4rplVo5bu4XyDe5fCdeU2mFBHRkIqMvBaZmQ6bw8rvn0JM8yAzkDhIbc1uo48bjE4YRcXY=; 24:4zjsfVFGeyImFG/fGmMfISSNy5rQS/3iCi2lhOz48in4DEli4U8DfZD8Uj9/HvlMbZ+YeqCnmJRLRPrjayZiiEwEENV6gle2xcKzITkSCxE=; 7:hyuhARP4YHVNANEWQtAKh6ufDBYkiz3BcuSlEeo6vK0yz3Z6ph2HnwZ20PyLTnFZtabkufJb0by3Gp9fuvvFNHyMfBP/5J4rWlrfUJl+0PumqDdQMqpoo7l4nKoUKt3wTkpsPWFCCMesG4iLg7c9i7iT7PiiCGF1R7xI0ZprVMUb7P3vfhvbKI6AhbWXJORyIRd7smLr8r359JhxyDMW0Qx4zGGuATxWP1ndyXdfFcNiAAL7FAq3sk1WA1Cr53WT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 50d75430-f8dc-4fd4-f508-08d530cd80d8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM4PR0801MB2707; x-ms-traffictypediagnostic: AM4PR0801MB2707: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(101472597685257)(80129823123378)(114017886912203); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2707; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2707; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(13464003)(377424004)(189002)(51914003)(40434004)(199003)(24454002)(53754006)(2950100002)(966005)(76176999)(50986999)(8936002)(2900100001)(53546010)(3660700001)(72206003)(33656002)(99286004)(478600001)(3846002)(5250100002)(102836003)(6506006)(6116002)(6436002)(25786009)(53936002)(8676002)(5890100001)(53386004)(74316002)(54356999)(101416001)(81156014)(5660300001)(4326008)(55016002)(7696004)(2906002)(7736002)(9686003)(110136005)(316002)(66066001)(4001150100001)(81166006)(6306002)(6246003)(97736004)(68736007)(189998001)(86362001)(229853002)(14454004)(106356001)(105586002)(3280700002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2707; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50d75430-f8dc-4fd4-f508-08d530cd80d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 10:49:13.0143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2707 Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 10:49:19 -0000 Thanks for the pointer. I wasn't aware of that work. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: 21 November 2017 11:24 To: Ludwig Seitz Cc: ace@ietf.org Subject: Re: [Ace] Application Layer TLS Just to keep it on record: We also had a draft which may find some relevance in the present context: https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00 Related publication: http://ieeexplore.ieee.org/document/7096256/ With Best Regards Abhijan Bhattacharyya Associate Consultant Scientist, TCS Research Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- 033 66884691 Cell:- +919830468972 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty.IT Services Business Solutions Consulting ____________________________________________ -----"Ace" wrote: ----- To: From: Ludwig Seitz Sent by: "Ace" Date: 11/21/2017 03:37PM Subject: Re: [Ace] Application Layer TLS On 2017-11-21 10:42, Hannes Tschofenig wrote: > Hi all, > > based on the recent email discussion about the DTLS proxy I thought it > might be useful that there was some thinking about how to run TLS/DTLS > at the application layer. > > There are essentially two drafts that have been submitted at the same > time for IETF#100, namely > > https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > Both teams have worked on prototypes and getting it to work was > remarkably simple. > > Maybe something for this group to look at. > > Ciao > Hannes I have a vague memory of a DICE draft for doing the DTLS handshake over CoA= P a long time ago: https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 Can the original authors tell us why they didn't go further with that appro= ach? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments= to it may contain confidential or privileged information. If you are not t= he intended recipient, any dissemination, use, review, distribution, printi= ng or copying of the information contained in this e-mail message and/or at= tachments to it are strictly prohibited. If you have received this communic= ation in error, please notify us by reply e-mail or telephone and immediate= ly and permanently delete the message and any attachments. Thank you _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Nov 21 02:54:58 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D71252BA for ; Tue, 21 Nov 2017 02:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 EgJi5iIXWL-y for ; Tue, 21 Nov 2017 02:54:54 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0053.outbound.protection.outlook.com [104.47.1.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6481F12426E for ; Tue, 21 Nov 2017 02:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=weNBHqwBBdUJdCO8eOdZCyA34HdByOEunayUk0hnGNk=; b=WfMVt8a8ZB2JqHoRrpXWJsyS7lsv01ZceYY8CUge6zwf/lqMu2sUyYVQ3+A7vS167u5ObTBeNnLaTuPEG+zXLemCCafZpSL8j8mv6vOILdhciOfzapZCc5WcdMTOOHeeHy2wS4LEyDrtgjsYlkwItnqBzkhMNsYPcAh8pziQ+a0= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 10:54:51 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 10:54:51 +0000 From: Hannes Tschofenig To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] Application Layer TLS Thread-Index: AdNirICUJkCFmJYSSCm/ASAY4sL+2QAA/PKAAAGQMrA= Date: Tue, 21 Nov 2017 10:54:50 +0000 Message-ID: References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> In-Reply-To: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:x9GysR11sZuE8OZsXNHAgvPWRJtBFajGYllQBcGnBupP6Yxqppr8mFNn7zxqCxMyBY2Ns/kmz62SNNOhuYV57I3KPtwtmsbZqR3LrEKnYycgdRF5TVdHUA7VFws+DnNxiD8kag0PE9MZ8M/MdU04wZBoloy5gKPEtUov2jbOe+pXBL/uqPC9dNL64/Ql8NubXlcbRpelaMGKQQjn/KBjA/qcM4QBA4j3l475/IWPx1SPMdc0VIczK69U4mxvv5PBXlkdkcAXnVLzOL5Ilp1Y+RrbG/rSLVe5Thm9NyfhzWwiuKh09dYG2gAfmNCH87DkB2XgdVnJbIX6uR46VDSxPcJ6eLcI4Ng6L5daH3Fc9Hs=; 5:DY5wBFzEoChyarVDWAPoBiZHIA5hkXEj2ksVQwXU+giuviHF2BayP7bDVjxs6Q1n5+A8bZcaMcGAuvUgZD1gJs/jx5X5SbqWfUYJ1VM6NtD0oTMzI5dFGe85TXU9ZPv0AeGlMKWDhoKJZM8tvT3pWJcXwmUrCMREzJL8b5z9NNs=; 24:ljmd5gu06JO9Po2b69G7nyay/HMi/tFPg38/h2EDKcdmBf5x/i9wNt83/JXpVNJHeh/62kkXZkYiu9eSinNOUfiv8cBvO5Y87Ta+OHSh6MA=; 7:jZKMcJXeaGc3GwIXMw5MaAElN71vtNCPnn6S+a6erzrj1HhPbI5VqHTtWzjFEUjtFP9KJ0oZYLAtKrtlUfiptRazB0UVEva/lXjjPoYJlBA3L8ZOSZQ/nP31FL1OGKM87t6pKvqlVaI6xKHXMqDMBa2YpPZnm7H8mhghtDDvQpnOmsdSOIVK51H59GDR4xXAfOwQSCTpyPouZs8UQyOJmODC7iABHyGLsxLzwSaNYZUMD6XlqPOr4iJwKvrRxYF5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cd6a50e9-e76b-4da3-f59e-08d530ce4a49 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(53754006)(40434004)(24454002)(13464003)(377424004)(50986999)(86362001)(53546010)(72206003)(81166006)(81156014)(8676002)(102836003)(3846002)(6116002)(6306002)(966005)(68736007)(53936002)(105586002)(9686003)(99286004)(6246003)(5660300001)(14454004)(110136005)(316002)(2950100002)(66066001)(478600001)(2900100001)(5890100001)(3660700001)(5250100002)(305945005)(33656002)(97736004)(7696004)(74316002)(101416001)(106356001)(3280700002)(54356999)(189998001)(2501003)(7736002)(76176999)(229853002)(2906002)(25786009)(4001150100001)(6506006)(8936002)(55016002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd6a50e9-e76b-4da3-f59e-08d530ce4a49 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 10:54:50.9300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 10:54:57 -0000 Hi Ludwig, Carsten pointed me to that document. Mark and I will do a comparison betwee= n the different solutions. In any case, it is great to see the level of int= erest in this and if you attended the TLS WG session then you can certainly= appreciate the heated discussion. One question I was asked at the IETF meeting was why the HTTP Connect funct= ionality hasn't been defined in CoAP since this would make certain use case= s with proxy use simpler. For me that's a useful addition but does not cover the entire solution spac= e since I am also consider non-IP based scenarios. Ciao Hannes -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz Sent: 21 November 2017 11:07 To: ace@ietf.org Subject: Re: [Ace] Application Layer TLS On 2017-11-21 10:42, Hannes Tschofenig wrote: > Hi all, > > based on the recent email discussion about the DTLS proxy I thought it > might be useful that there was some thinking about how to run TLS/DTLS > at the application layer. > > There are essentially two drafts that have been submitted at the same > time for IETF#100, namely > > https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > Both teams have worked on prototypes and getting it to work was > remarkably simple. > > Maybe something for this group to look at. > > Ciao > Hannes I have a vague memory of a DICE draft for doing the DTLS handshake over CoA= P a long time ago: https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 Can the original authors tell us why they didn't go further with that appro= ach? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Nov 21 03:21:48 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06C1252BA for ; Tue, 21 Nov 2017 03:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 goEgTccJmgoo for ; Tue, 21 Nov 2017 03:21:44 -0800 (PST) Received: from xenon41.um.es (xenon41.um.es [IPv6:2001:720:1710:601::41]) by ietfa.amsl.com (Postfix) with ESMTP id E9FFD120046 for ; Tue, 21 Nov 2017 03:21:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 0525C214D5; Tue, 21 Nov 2017 12:21:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6qP7AZPkWAHk; Tue, 21 Nov 2017 12:21:38 +0100 (CET) Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 0A34E203A1; Tue, 21 Nov 2017 12:21:36 +0100 (CET) From: Rafa Marin-Lopez Message-Id: <71DF1EDC-10EF-439F-8686-6FD20FDBFD62@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_7CC1C820-4259-461E-A612-9C1ABC43A9AC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 21 Nov 2017 12:21:36 +0100 In-Reply-To: Cc: Rafa Marin-Lopez , Ludwig Seitz , "ace@ietf.org" To: Hannes Tschofenig References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 11:21:47 -0000 --Apple-Mail=_7CC1C820-4259-461E-A612-9C1ABC43A9AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all: This I-D we wrote sometime ago might be also related: = https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-reco= rd-00 = Best Regards. > El 21 nov 2017, a las 11:54, Hannes Tschofenig = escribi=C3=B3: >=20 > Hi Ludwig, >=20 > Carsten pointed me to that document. Mark and I will do a comparison = between the different solutions. In any case, it is great to see the = level of interest in this and if you attended the TLS WG session then = you can certainly appreciate the heated discussion. >=20 > One question I was asked at the IETF meeting was why the HTTP Connect = functionality hasn't been defined in CoAP since this would make certain = use cases with proxy use simpler. > For me that's a useful addition but does not cover the entire solution = space since I am also consider non-IP based scenarios. >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz > Sent: 21 November 2017 11:07 > To: ace@ietf.org > Subject: Re: [Ace] Application Layer TLS >=20 > On 2017-11-21 10:42, Hannes Tschofenig wrote: >> Hi all, >>=20 >> based on the recent email discussion about the DTLS proxy I thought = it >> might be useful that there was some thinking about how to run = TLS/DTLS >> at the application layer. >>=20 >> There are essentially two drafts that have been submitted at the same >> time for IETF#100, namely >>=20 >> https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 >>=20 >> https://tools.ietf.org/html/draft-friel-tls-over-http-00 >>=20 >> Both teams have worked on prototypes and getting it to work was >> remarkably simple. >>=20 >> Maybe something for this group to look at. >>=20 >> Ciao >> Hannes >=20 >=20 > I have a vague memory of a DICE draft for doing the DTLS handshake = over CoAP a long time ago: >=20 > https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 >=20 > Can the original authors tell us why they didn't go further with that = approach? >=20 > /Ludwig >=20 >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafa 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 ------------------------------------------------------- --Apple-Mail=_7CC1C820-4259-461E-A612-9C1ABC43A9AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all:

This I-D we wrote sometime ago might be also = related:

https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-wit= h-dtls-record-00

Best Regards.

El = 21 nov 2017, a las 11:54, Hannes Tschofenig <hannes.tschofenig@arm.com> escribi=C3=B3:

Hi = Ludwig,

Carsten pointed me to that = document. Mark and I will do a comparison between the different = solutions. In any case, it is great to see the level of interest in this = and if you attended the TLS WG session then you can certainly appreciate = the heated discussion.

One question I was = asked at the IETF meeting was why the HTTP Connect functionality hasn't = been defined in CoAP since this would make certain use cases with proxy = use simpler.
For me that's a useful addition but does not = cover the entire solution space since I am also consider non-IP based = scenarios.

Ciao
Hannes

-----Original Message-----
From: = Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz
Sent: 21 November 2017 11:07
To: ace@ietf.org
Subject: Re: [Ace] Application Layer TLS

On 2017-11-21 10:42, Hannes Tschofenig wrote:
Hi all,

based on the recent email discussion about the DTLS proxy I = thought it
might be useful that there was some thinking = about how to run TLS/DTLS
at the application layer.

There are essentially two drafts that have = been submitted at the same
time for IETF#100, namely

https://tools.ietf.org/html/draft-tschofenig-layered-tls-00=

https://tools.ietf.org/html/draft-friel-tls-over-http-00

Both teams have worked on prototypes and = getting it to work was
remarkably simple.

Maybe something for this group to look at.

Ciao
Hannes


I have a vague memory of a DICE draft for = doing the DTLS handshake over CoAP a long time ago:

https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-co= dtls-00

Can the original authors tell = us why they didn't go further with that approach?

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank you.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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




= --Apple-Mail=_7CC1C820-4259-461E-A612-9C1ABC43A9AC-- From nobody Tue Nov 21 03:42:59 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8F12946E for ; Tue, 21 Nov 2017 03:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 hvaigDJFFi5u for ; Tue, 21 Nov 2017 03:42:56 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB62F127010 for ; Tue, 21 Nov 2017 03:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vALBgqpl025131; Tue, 21 Nov 2017 12:42:52 +0100 (CET) Received: from wangari.tzi.org (unknown [IPv6:2001:638:708:30da:142a:e3d3:69f6:cfd0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yh3cD0PGSzDXkR; Tue, 21 Nov 2017 12:42:52 +0100 (CET) From: Olaf Bergmann To: Ludwig Seitz Cc: References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> Date: Tue, 21 Nov 2017 12:42:52 +0100 In-Reply-To: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> (Ludwig Seitz's message of "Tue, 21 Nov 2017 11:06:53 +0100") Message-ID: <873757kgcj.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 11:42:58 -0000 Ludwig Seitz writes: > I have a vague memory of a DICE draft for doing the DTLS handshake > over CoAP a long time ago: > > https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 > > Can the original authors tell us why they didn't go further with that > approach? The main reason was that it did not fit into the official DICE work program. Meanwhile, the student who did most of the work (including a working prototype[1] which is also available as rubby gem) has graduated and left the university. But there is no technical reason for not taking this up again. [1] https://github.com/SmallLars/codtls Gr=C3=BC=C3=9Fe Olaf From nobody Tue Nov 21 04:22:37 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23255129477 for ; Tue, 21 Nov 2017 04:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 Wt4H0Syi__Kg for ; Tue, 21 Nov 2017 04:22:33 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0044.outbound.protection.outlook.com [104.47.1.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EC912946E for ; Tue, 21 Nov 2017 04:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/5B0cH8Wa+tYExNJ2xbnEzfmwuS/Ste+yucoX2ySMl8=; b=W9FiCtg+W/cnJ8mUY80BdzqZd5fZD7u2vwUjxyDryqkshMCv8GcZBEPFxD6a99QFNiMExKeAzQhyEjiRb9twRJ6p019cNMr40ZxlgUZ7M6mDHjzy3+1omcq8G47KGbZM/aUh2+31VB9VmTJ8EmTZXpHEIDIXjZsny/pa9r5D4ow= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2707.eurprd08.prod.outlook.com (10.167.90.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 12:22:30 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 12:22:30 +0000 From: Hannes Tschofenig To: Olaf Bergmann , Ludwig Seitz CC: "ace@ietf.org" Thread-Topic: [Ace] Application Layer TLS Thread-Index: AdNirICUJkCFmJYSSCm/ASAY4sL+2QAA/PKAAANcA60AAU1WEA== Date: Tue, 21 Nov 2017 12:22:30 +0000 Message-ID: References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> <873757kgcj.fsf@tzi.org> In-Reply-To: <873757kgcj.fsf@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.119.33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2707; 6:fm633kZGrrzUMM3pN9NgJAnchCExXB8mKtKvM93qjExu78NiRG3WC9c4o1vvFLzdHkRraDQmzfa/GUKe/V572olx4WJzA5mqFQSQLbMZthLTbRTnl8AUroCAC99rwU6hAeYepbjoy5IWZ4Et2gWzEeBa/y7adFP8LQx8LpLndvZkaPLmrNKoSY3sR4xxxjZfjrdu7MSLGYIJmp/aJ+967URP1X/MQ1hN/iXveL7/YXesnexF/va2wUY94zVRFoKcYYS35rZs46oTZmyf7qejRaWLY+W7XPwU8kgXtEDaGQ6Km8jCZEjDjpsuTO0PIN1An8t4/PwcD5rGpgSRWdX712mdNAfZbHmzUDumTRhWIf8=; 5:TVKoEBqBsJgILxpJsriCib15F5p9ZkA6NAumrvsQUryakGnJx6Bxm0yV+wCC5ZcRVE1xafaaW/GPkXy2QmT+dGVzJkmbVWTg8eVc4NoKTa9pU7qpNtx7/bNKI6VfYeY3s3ALG4ULtAwRHQQhZ8CUW2bm5Wy9sM6Kyd31DbLueCM=; 24:C9wqZ83dYZ+DTlP7Ld4ZLPLrZrrHnSLFXRe4WCrxU+uaI2HxMxNBnUWYA2F2yCVL9J8uw5yFrXVDQ0aseMnRpscWZP+GrgkZUyuCNmSS28o=; 7:ItxRozv2OI6iEW+8cXENZGFUXhVOAcnvAsRIyt6FdHRnZc8aWApL3DRa1j7XMYpl/FRIAqM7KJfIARWBbLl3jTHuJ5f8/u+T6gRazRg+kBrOrK6AgUhzQMWuSNdrXCTzHDvPA3p4Ehy4vUat7eYzVaeRB027bkxxUCw5SzFPlZ6NNHD6lqMRn67in+/Csxtf4HfeaBEjdlUVol1dnaslafeceFp/rHI25M18mskJJVEcGHCH063QynXm/w4pSZvZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4ee1577e-27f8-4c8c-7ca5-08d530da8950 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM4PR0801MB2707; x-ms-traffictypediagnostic: AM4PR0801MB2707: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231022)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2707; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2707; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(13464003)(40434004)(6246003)(97736004)(6306002)(68736007)(2906002)(7736002)(9686003)(66066001)(110136005)(316002)(3280700002)(105586002)(229853002)(305945005)(81166006)(189998001)(14454004)(106356001)(86362001)(478600001)(102836003)(6506006)(6116002)(3846002)(5250100002)(33656002)(99286004)(25786009)(6436002)(2900100001)(8936002)(966005)(2950100002)(50986999)(76176999)(3660700001)(72206003)(53546010)(81156014)(561944003)(5660300001)(54356999)(101416001)(55016002)(4326008)(74316002)(8676002)(53936002)(5890100001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2707; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee1577e-27f8-4c8c-7ca5-08d530da8950 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 12:22:30.6456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2707 Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 12:22:36 -0000 DQpUbyBtZSBpdCBzb3VuZHMgbGlrZSB3ZSBoYXZlIG11bHRpcGxlIGdyb3VwcyB3aG8gaGF2ZSBz ZWVuIGEgcHJvYmxlbSBhbmQgaGF2ZSBiZWVuIHdpbGxpbmcgdG8gc3BlbmQgdGhlIHRpbWUgdG8g d29yayBvbiB0aGUgc29sdXRpb25zLg0KDQpJIGJlbGlldmUgd2Ugc2hvdWxkIHB1dCBhIEJPRiBw cm9wb3NhbCBmb3IgdGhlIExvbmRvbiBJRVRGIG1lZXRpbmcgdG9nZXRoZXIuIEhvdyBkb2VzIHRo YXQgc291bmQ/DQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPbGFm IEJlcmdtYW5uDQpTZW50OiAyMSBOb3ZlbWJlciAyMDE3IDEyOjQzDQpUbzogTHVkd2lnIFNlaXR6 DQpDYzogYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FjZV0gQXBwbGljYXRpb24gTGF5ZXIg VExTDQoNCkx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNlaXR6QHJpLnNlPiB3cml0ZXM6DQoNCj4gSSBo YXZlIGEgdmFndWUgbWVtb3J5IG9mIGEgRElDRSBkcmFmdCBmb3IgZG9pbmcgdGhlIERUTFMgaGFu ZHNoYWtlDQo+IG92ZXIgQ29BUCBhIGxvbmcgdGltZSBhZ286DQo+DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc2NobWVydG1hbm4tZGljZS1jb2R0bHMtMDAN Cj4NCj4gQ2FuIHRoZSBvcmlnaW5hbCBhdXRob3JzIHRlbGwgdXMgd2h5IHRoZXkgZGlkbid0IGdv IGZ1cnRoZXIgd2l0aCB0aGF0DQo+IGFwcHJvYWNoPw0KDQpUaGUgbWFpbiByZWFzb24gd2FzIHRo YXQgaXQgZGlkIG5vdCBmaXQgaW50byB0aGUgb2ZmaWNpYWwgRElDRSB3b3JrIHByb2dyYW0uIE1l YW53aGlsZSwgdGhlIHN0dWRlbnQgd2hvIGRpZCBtb3N0IG9mIHRoZSB3b3JrIChpbmNsdWRpbmcg YSB3b3JraW5nIHByb3RvdHlwZVsxXSB3aGljaCBpcyBhbHNvIGF2YWlsYWJsZSBhcyBydWJieSBn ZW0pIGhhcyBncmFkdWF0ZWQgYW5kIGxlZnQgdGhlIHVuaXZlcnNpdHkuDQoNCkJ1dCB0aGVyZSBp cyBubyB0ZWNobmljYWwgcmVhc29uIGZvciBub3QgdGFraW5nIHRoaXMgdXAgYWdhaW4uDQoNClsx XSBodHRwczovL2dpdGh1Yi5jb20vU21hbGxMYXJzL2NvZHRscw0KDQpHcsO8w59lDQpPbGFmDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFp bGluZyBsaXN0DQpBY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYWNlDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50 cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Tue Nov 21 04:28:02 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EAB129483 for ; Tue, 21 Nov 2017 04:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 tBFdWFoM5Bni for ; Tue, 21 Nov 2017 04:27:53 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A4C129482 for ; Tue, 21 Nov 2017 04:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vALCRlxV002483; Tue, 21 Nov 2017 13:27:47 +0100 (CET) Received: from wangari.tzi.org (unknown [IPv6:2001:638:708:30da:142a:e3d3:69f6:cfd0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yh4c328VRzDXlg; Tue, 21 Nov 2017 13:27:47 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig Cc: Ludwig Seitz , "ace\@ietf.org" References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> <873757kgcj.fsf@tzi.org> Date: Tue, 21 Nov 2017 13:27:47 +0100 In-Reply-To: (Hannes Tschofenig's message of "Tue, 21 Nov 2017 12:22:30 +0000") Message-ID: <87lgizizp8.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 12:27:56 -0000 Hannes Tschofenig writes: > To me it sounds like we have multiple groups who have seen a problem > and have been willing to spend the time to work on the solutions. > > I believe we should put a BOF proposal for the London IETF meeting > together. How does that sound? +1 Gr=C3=BC=C3=9Fe Olaf From nobody Tue Nov 21 05:07:29 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72767129483 for ; Tue, 21 Nov 2017 05:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 d0eW8YhTaiMH for ; Tue, 21 Nov 2017 05:07:27 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA7A126BFD for ; Tue, 21 Nov 2017 05:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vALD7NBV006895; Tue, 21 Nov 2017 14:07:23 +0100 (CET) Received: from [IPv6:2001:638:708:30da:6d4b:1abf:c8f3:640a] (unknown [IPv6:2001:638:708:30da:6d4b:1abf:c8f3:640a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yh5Tl4t7nzDXmR; Tue, 21 Nov 2017 14:07:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <873757kgcj.fsf@tzi.org> Date: Tue, 21 Nov 2017 14:07:23 +0100 Cc: ace , Olaf Bergmann X-Mao-Original-Outgoing-Id: 532962443.447172-44077a902d59024af46410f0bba8036a Content-Transfer-Encoding: quoted-printable Message-Id: <08A9EE80-4256-4951-B975-D8367D36FACF@tzi.org> References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> <873757kgcj.fsf@tzi.org> To: Ludwig Seitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 13:07:28 -0000 On Nov 21, 2017, at 12:42, Olaf Bergmann wrote: >=20 > Ludwig Seitz writes: >=20 >> I have a vague memory of a DICE draft for doing the DTLS handshake >> over CoAP a long time ago: >>=20 >> = https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 >>=20 >> Can the original authors tell us why they didn't go further with that >> approach? >=20 > The main reason was that it did not fit into the official DICE work > program. Meanwhile, the student who did most of the work (including a > working prototype[1] which is also available as rubby gem) has = graduated > and left the university. >=20 > But there is no technical reason for not taking this up again. >=20 > [1] https://github.com/SmallLars/codtls This work was a successful early proof of concept and has thus fully = achieved its objective. One more reason that we haven=E2=80=99t picked this up again is that the = original work was for an older chip, the MC1322x, and contained code to = keep connection state in the Flash of that chip that probably would need = some porting. At the time, the TLS WG also didn=E2=80=99t seem particularly receptive = to new work: codtls is not just a compressed DTLS, as it performed the = MAC operations for the Finished messages on the actual messages = exchanged, not on the original uncompressed messages that never are = reified. Essentially, a large part of the complexity of the solution is = in trying to maintain the entire set of TLS exchanges, and then the MAC = doesn=E2=80=99t quite. (This is a fundamental problem any TLS emulation = will have, and it would be good to get the envelope of what works and = what doesn=E2=80=99t for this specified.) With much more tailored solutions around the corner (e.g., EDHOC), we = didn=E2=80=99t see a strong technical motivation to take this up again = either. But we sure can if there is a political reason instead. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 21 07:16:13 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF401243F6 for ; Tue, 21 Nov 2017 07:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 s4DOQffhI2UG for ; Tue, 21 Nov 2017 07:16:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7761294A1 for ; Tue, 21 Nov 2017 07:16:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6DEF32008C; Tue, 21 Nov 2017 10:18:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D125482639; Tue, 21 Nov 2017 10:16:07 -0500 (EST) From: Michael Richardson To: Hannes Tschofenig cc: "ace\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:16:11 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > based on the recent email discussion about the DTLS proxy I thought it > might be useful that there was some thinking about how to run TLS/DTLS > at the application layer. yes, and I'm enthusiastic to permit EST to run over whatever comes out, as I suspect it will be bytes-on-the-wire cheaper than COAPS. Yet, there are people who want EST over CoAPS to work as is... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloUQzcACgkQgItw+93Q 3WUhRAf9EEQF7JRk0MjaQY0+z/vIVAW7uvwM8DlH+kQ/fJ4uWPuzslIehnovbrMg +YG6zXQA46t8T/cYETCadHv0dwMuC/lrA6MidmEiEru6d/2YEE2gQAzBMNco5Q9s MrA4+iV6rVk/WD6kBpmddUT7EluJzu7NnGQRcGn0LUxZfkAROnBpTBAv/r+A5TOI iSNsWbVEZJldNkSeig5+xOGS0sZRHc7NCqt7PN+Sis+RprnBAx3BFVvfwI3lQ6jF a7HZeoWKNMYstTx0pOx6p2YbwQxnHOjCBbLWamBrtI0ggR8KHjB7GmXpOpHMxJ0N nCH5Kq3Yc0iE7TcojimzMTrUnNRq7w== =qAXc -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 21 07:21:28 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BB61294A1 for ; Tue, 21 Nov 2017 07:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RRNrZavoGqin for ; Tue, 21 Nov 2017 07:21:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2F31243F6 for ; Tue, 21 Nov 2017 07:21:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 771F42008C; Tue, 21 Nov 2017 10:23:26 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DBF3982639; Tue, 21 Nov 2017 10:21:23 -0500 (EST) From: Michael Richardson To: Hannes Tschofenig cc: Ludwig Seitz , "ace\@ietf.org" In-Reply-To: References: <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:21:26 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > One question I was asked at the IETF meeting was why the HTTP Connect > functionality hasn't been defined in CoAP since this would make certain > use cases with proxy use simpler. HTTPS CONNECT invokes a multistage TLS connection: client->proxy and proxy->server. That obscures the server certificate from the client and VV, and we have a well established serious security issues in the "enterprise" world with the ability of the proxy to usefully validate the server certificate. An COAP (not COAPS) CONNECT mechanism which put the security inside CoAP (as EDHOC/OSCORE and presumably draft-tschofenig-layered-tls-00 and draft-friel-tls-over-http-00 do) solves the problem of certificate validation nicely because it offers end to end security. However, it's unclear to me how it would be better than NAT66 (with all of it's expensive state), which is why I want a mechanism where the relay state is stored in the network (echoed, source routed back to the proxy). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloURHMACgkQgItw+93Q 3WXxRAgAplI3u0AnayDfB0aki3PdFOU0TcdO67Nuu6+AURT+aGjS1F5qKro0H3K1 xw0prA0Hmjs1OTD4N0NcPMfsFJDtlSVV2oIRYv1+4XCIXSV5VBsE7nMktf6pXsqw d5ZhH3vmE++L864iF3M+h91uhMCYoGLhpQJDybIWoo3F0x4vdpAUjWJjw5gUecVG 2Tb+eBOtKDCGwxbAlGCxeXwKqr+PQd52oxmh8mforfGMnEX558egNtLDcUENnH4G 6Ebrv9hLMvjLN5BqeWMjnnviafjY7TYQoXZlOAN0E7DRBsWvHHhEn9tKN3YcANUw PAcV+z/vODlt0raSA2Z0ycoDDDDhDw== =/kzM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 21 09:34:37 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60998129AC4 for ; Tue, 21 Nov 2017 09:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 sd1wBCUHEo1t for ; Tue, 21 Nov 2017 09:34:33 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A493412957A for ; Tue, 21 Nov 2017 09:34:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CFF1FE2055; Tue, 21 Nov 2017 12:34:00 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12208-04; Tue, 21 Nov 2017 12:33:57 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::530:248d:f760:bb62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5987BE2050; Tue, 21 Nov 2017 12:33:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1511285637; bh=pT0jz0Q06SVGiqQuMQZaWT3AegPdo3XKC3hC2xiXviw=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=hRz5Ol0Q81kZ773QQBzaQo7+W5aU3G3dhV8AuT71ZOnfsSGWNAwL2SqicIDko/e+S ASkZNZUZ0IZDvNALz+Jvl6lTORvsg42AyZTLb60zOmzVdJfZ3Mw3ayh7khDrO//vUQ rAGBH5b5W+j6l00RCAVAeWj+OgmhG8/fLqokaiKo= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id vALHXuqE030773; Tue, 21 Nov 2017 12:33:56 -0500 From: Derek Atkins To: Hannes Tschofenig Cc: "ace\@ietf.org" References: Date: Tue, 21 Nov 2017 12:33:56 -0500 In-Reply-To: (Hannes Tschofenig's message of "Tue, 21 Nov 2017 09:42:58 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 17:34:35 -0000 Hannes, Hannes Tschofenig writes: > Hi all, > > based on the recent email discussion about the DTLS proxy I thought it might > be useful that there was some thinking about how to run TLS/DTLS at the > application layer. I don't understand this statement. The whole point of TLS/DTLS is that it runs at the Application Layer (as opposed to at the network layer, like IPsec). Indeed, the fact that it could run at the application layer (e.g. in a web brower / web server) is exactly why SSL/TLS was created in the first place. It meant you didn't require waiting for the kernel/OS to add network security. > There are essentially two drafts that have been submitted at the same time for > IETF#100, namely > > https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 So you are moving the application layer up even higher than the historic view of an application layer? Perhaps we need a better naming scheme here. > Both teams have worked on prototypes and getting it to work was remarkably > simple. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Nov 21 10:48:10 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703AA12956B for ; Tue, 21 Nov 2017 10:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iUtKI1PxX5ZE for ; Tue, 21 Nov 2017 10:48:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73415129AA4 for ; Tue, 21 Nov 2017 10:48:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D22ED20008; Tue, 21 Nov 2017 13:50:08 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BF00882C48; Tue, 21 Nov 2017 13:48:05 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" cc: Derek Atkins In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 18:48:09 -0000 --=-=-= Content-Type: text/plain Derek Atkins wrote: >> based on the recent email discussion about the DTLS proxy I thought it might >> be useful that there was some thinking about how to run TLS/DTLS at the >> application layer. > I don't understand this statement. The whole point of TLS/DTLS is that > it runs at the Application Layer (as opposed to at the network layer, DTLS has to provide many of the services of the Transport and Network layer (various amounts of reliability, fragmentation/segmentation) and there is overhead in that. When running over things like CoAP, which *ALSO* provides those services, and in a more constrained network happy way, DTLS is way less appealing. > Perhaps we need a better naming scheme here. In my opinion, the ISO layer naming system has always been better as documentation, rather than architecture :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloUdOUACgkQgItw+93Q 3WW9FwgApWkKs7zbUaJ3ZE4VfwHAwrDXRYyXCWaVWSHgWCa9Bo+M9des9PMb5e0v OH68QzlfuAPJ36JR32ub6uaL6f3ZSiU+0Q2a+PLsrSP4bfSrRANYKUZCVdNOvKnb HlX5zpNdvBWZflOGXxQKG5hMFbbvcxWSyUJOqPzksSReKEQeO5rQtKqiBivB5zS1 ZQick8tNZhWMupomUE0pVGs23kI+PWCO+ymtxlyrOr9JGpjbu30b2y4dqpSOhTSN s/h0UC+vb50/tcQzLnEIAMJB74W7/ARgNFnzmUcgBg4NwEkJPdcm/3+R/G0+omXg 14rNIOGKxYqSmDnx1wZxnb9rte0Gng== =tM0W -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 21 11:25:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6161129BAA for ; Tue, 21 Nov 2017 11:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 kopYTXDFtSDC for ; Tue, 21 Nov 2017 11:25:16 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB6B129BA8 for ; Tue, 21 Nov 2017 11:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vALJPDw9007466; Tue, 21 Nov 2017 20:25:13 +0100 (CET) Received: from [192.168.217.119] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yhFsj4H8NzDXss; Tue, 21 Nov 2017 20:25:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <11699.1511290085@obiwan.sandelman.ca> Date: Tue, 21 Nov 2017 20:25:13 +0100 Cc: "ace@ietf.org" , Derek Atkins X-Mao-Original-Outgoing-Id: 532985113.232129-cde45ec0231c058c75736b39aef867a7 Content-Transfer-Encoding: quoted-printable Message-Id: <139F6AD3-3CC7-4040-85D6-DD5F72086BF7@tzi.org> References: <11699.1511290085@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 19:25:19 -0000 On Nov 21, 2017, at 19:48, Michael Richardson = wrote: >=20 > In my opinion, the ISO layer naming system has always been better as > documentation, rather than architecture :-) And we can celebrate its 40th birthday in a couple of months. Gr=C3=BC=C3=9Fe, Carsten (The OSI Reference Model, standardized in ISO 7498/ITU-T X.200 was = *intended* to be prescriptive, structuring the standardization work = lying ahead in 1978. It lost that function with the factual end of the OSI project a dozen = years later, and most people have forgotten what the OSI layers were = about: Layer 2, 3, 4, 7 took on a new, slightly different meaning as = layer numbers for the layers named in RFC 1122/1123, while 1 is = convenient as a layer number for the part of the RFC 1122 link layer = that is concerned with bits, symbols, clocks, and physical = interoperability. The old seven-layer OSI model is still being taught, usually mostly with = the current meaning of the layer numbers that still exist, and a lot of = misconceptions of what L5/L6 were supposed to be, in computer networking = classes by teachers that don=E2=80=99t know better. Foo.) From nobody Tue Nov 21 12:11:53 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BCB129BB5 for ; Tue, 21 Nov 2017 12:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tcs.com 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 qVk_USjNpbBp for ; Tue, 21 Nov 2017 12:11:47 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B17129BB7 for ; Tue, 21 Nov 2017 12:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default; t=1511295106; x=1542831106; h=mime-version:in-reply-to:references:subject:from:to:cc: message-id:date; bh=F2tVlO4fKmXF21+WWnnlcUSD5ggFtNdAoTPM89vUYXQ=; b=UFTC9p1H5zyJtVWRsw6AOtI+uTtDnsUI560ecgLsehlSoMm8Q53gRiUd hotDaerFsEO3a0pxesiNlq2NwK64adEUKidbqZynWW8OUakF78QVz53a9 1TyOS5NdYSvCRyhbPyE21Bquz06tdRz9f2UQTOrDTGwwOAR2/XTeOc5z8 g=; IronPort-PHdr: =?us-ascii?q?9a23=3AixmjyRb51QvKaP/K52W5sOH/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZpsy9ZB7h7PlgxGXEQZ/co6odzbaO6+awBCdZu8bJmUtBWaQEbwUCh8?= =?us-ascii?q?QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6?= =?us-ascii?q?OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MAm6oR/Su8QWjoduN7g9xxjUqXZUZu?= =?us-ascii?q?pawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnF?= =?us-ascii?q?VguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hC?= =?us-ascii?q?oBKjU063/chNBug61HoRKhvx1/zJDSYIGJL/p1Y6fRccoHSWZdQspdUipMCZ6+?= =?us-ascii?q?YYQSFeoMJelXoIrnqVQMoxuwGAmiCv3sxDFGgXH5wbY33P49HQzcxgEgG84CvG?= =?us-ascii?q?nSod7oNKkSS+e1zKzQwDjfdPxW2Tb96IrSfRAnvPqBQLJwftDNyUkzDQzKklWQ?= =?us-ascii?q?ppb/PzKV1uUCqXWQ4u16Wu20i24nqgNxrSKpxss2kYbJhpgaykzY9Spj3Ik1Jc?= =?us-ascii?q?e3SFR7YN+kCpRdrD2aOJdtQs84X25ovyM6x6QAtJWmciYKz5EnyATea/yBa4WI?= =?us-ascii?q?7RPjVPqRITdln31pYq6whxG38US4y+3zSNW00FhQoipCiNnMuWgB1wDP5cicUP?= =?us-ascii?q?dy4kCh2TOJ2gvO6e9EOVg5mbfZJpI/2LI8i5kevV7dEiL4gkn7g6mbfVg+9Oey?= =?us-ascii?q?8eToeLDmq4eZN49zlw7xLLwjmte6AeQkKggOWHWb+fik2L3j40L5RLJKg+U1nK?= =?us-ascii?q?fBtZ7UPMIVqLOlDgFT3Igt7QyxATC43tkEgHULNFNFeBSZgIj1I1zCPfL1Aeml?= =?us-ascii?q?j1ixkzpn3e7KM7P7DpjCNnTDla3ufbd5605S0gozytVf6opOBb4aIPLzW03xu8?= =?us-ascii?q?beDhMjKAO0w/zoCMlh1owERW2PArWWMLnSsF6I/O0iOPWMa5MOuDrnN/cl4Pvu?= =?us-ascii?q?gWcjmVABZampwYcXaHegE/pkOUqZZ3zsjckaEWsQoAQ+V/DliF2FUT5deXmyWa?= =?us-ascii?q?M85j4gBY28F4fDQ5qhj6CG3Ce+BpdWfHxJCkiQEXf0cIWJQ+0DZz6MLcJ6kzwL?= =?us-ascii?q?S6ShS4E72RGprg/6xKJtLvDI9S0AqZLjyN916vXXlREv6DN1AcWd026XQ2FvgG?= =?us-ascii?q?wIRiM23aFkrExny1ePy7N4jOJAH9xJ+/xJShs6NYLbz+FiEN/9RBjBftiMSFm8?= =?us-ascii?q?RNWmByo8Ts4wwt8PeUp9HM+ijh+QlxatVp8ckbqGH9QI6anc2Hb8IcdygyLm3a?= =?us-ascii?q?8ngkJgftBENWqoi6h++CDaHYuPmEKcwfWEb6MZiQfH9GaBxGzGlkFRTBJ5WqXM?= =?us-ascii?q?R2EObwOCpN7550HLSfmkCb07LgJKyceYO7pDQsHilhNNQ/K1a4eWWH64h2rlXU?= =?us-ascii?q?XA/biLdoe/PjxFhCg=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CWAABKhxRa/wQXEqxbGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQigRUTjguRKJZiEIIBIgEKhRgChUgYAQEBAQEBAQEBAYESQhC?= =?us-ascii?q?BZiQBgkEBAQEDAQEBbAIJBQcEBQYNBAMBAQEoBycfCQgGCwgRCol/GKdrAQEBg?= =?us-ascii?q?xOKdQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DNIE1dHWBK3yDK4RoAQ8DAT8MgxY?= =?us-ascii?q?EgjIFkwePN4I3hTuHUYdfIIVsiyuMdIp7H4E8cXpegmQJglMcgW9vhCSEVoI4A?= =?us-ascii?q?QEB?= X-IPAS-Result: =?us-ascii?q?A2CWAABKhxRa/wQXEqxbGQEBAQEBAQEBAQEBAQcBAQEBAYQ?= =?us-ascii?q?igRUTjguRKJZiEIIBIgEKhRgChUgYAQEBAQEBAQEBAYESQhCBZiQBgkEBAQEDA?= =?us-ascii?q?QEBbAIJBQcEBQYNBAMBAQEoBycfCQgGCwgRCol/GKdrAQEBgxOKdQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAR2DNIE1dHWBK3yDK4RoAQ8DAT8MgxYEgjIFkwePN4I3h?= =?us-ascii?q?TuHUYdfIIVsiyuMdIp7H4E8cXpegmQJglMcgW9vhCSEVoI4AQEB?= X-IronPort-AV: E=Sophos;i="5.44,432,1505759400"; d="scan'208,217";a="270262431" MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <6709ef3c-23e4-8a6f-0b37-34cb842b0f5a@ri.se> <873757kgcj.fsf@tzi.org> From: Abhijan Bhattacharyya To: Hannes Tschofenig Cc: Olaf Bergmann , Ludwig Seitz , "ace@ietf.org" Message-ID: Date: Wed, 22 Nov 2017 01:41:34 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP8HF242 May 5, 2017 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/22/2017 01:41:34, Serialize complete at 11/22/2017 01:41:34, Itemize by http on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/22/2017 01:41:34, Serialize by Router on InKolM02/TCS(Release 9.0.1FP8HF242 | May 5, 2017) at 11/22/2017 01:41:36, Serialize complete at 11/22/2017 01:41:36 Content-Type: multipart/alternative; boundary="=_alternative 006EEC3D652581DF_=" Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 20:11:52 -0000 --=_alternative 006EEC3D652581DF_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 With Best Regards Abhijan Bhattacharyya Associate Consultant Scientist, TCS Research Tata Consultancy Services Building 1B,Ecospace Plot - IIF/12 ,New Town, Rajarhat, Kolkata - 700160,West Bengal India Ph:- 033 66884691 Cell:- +919830468972 Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ = -----"Ace" wrote: ----- To: Olaf Bergmann , Ludwig Seitz From: Hannes Tschofenig = Sent by: "Ace" = Date: 11/21/2017 05:56PM Cc: "ace@ietf.org" Subject: Re: [Ace] Application Layer TLS To me it sounds like we have multiple groups who have seen a problem and ha= ve been willing to spend the time to work on the solutions. I believe we should put a BOF proposal for the London IETF meeting together= . How does that sound? Ciao Hannes -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Olaf Bergmann Sent: 21 November 2017 12:43 To: Ludwig Seitz Cc: ace@ietf.org Subject: Re: [Ace] Application Layer TLS Ludwig Seitz writes: > I have a vague memory of a DICE draft for doing the DTLS handshake > over CoAP a long time ago: > > https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00 > > Can the original authors tell us why they didn't go further with that > approach? The main reason was that it did not fit into the official DICE work program= . Meanwhile, the student who did most of the work (including a working prot= otype[1] which is also available as rubby gem) has graduated and left the u= niversity. But there is no technical reason for not taking this up again. [1] https://github.com/SmallLars/codtls Gr=FC=DFe Olaf _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D 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 --=_alternative 006EEC3D652581DF_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1

With Best Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, TCS Research
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- 033 66884691
Cell:- +919830468972
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.= tcs.com
____________________________________________
Experience certainty. IT Services
 Business Solutions
 Consulting
____________________________________________


-----"Ace" <ace-bounces@ietf.org> wr= ote: -----
<= div style=3D"padding-right:0px;padding-left:5px;border-left:solid black 2px= ;">To: Olaf Bergmann <bergmann@tzi.org>, Ludwig Seitz <ludwig.seitz@ri.se>
From: Hannes Tsch= ofenig
Sent by: "Ace" =
Date: 11/21/2017 05:56PM
Cc: "ace@ietf.org" <ace@ietf.org>
Subject: Re: [Ace] Application Layer TLS
To me it= sounds like we have multiple groups who have seen a problem and have been = willing to spend the time to work on the solutions.

I believe we sho= uld put a BOF proposal for the London IETF meeting together. How does that = sound?

Ciao
Hannes

-----Original Message-----
From: Ace= [mailto:ace-bounces@ietf.org] = On Behalf Of Olaf Bergmann
Sent: 21 November 2017 12:43
To: Ludwig Se= itz
Cc: ace@ietf.org
Subject: Re: [Ace] Application Layer TLS

Ludwig Seitz <ludwig.seitz@ri.se&= gt; writes:

> I have a vague memory of a DICE draft for doing the= DTLS handshake
> over CoAP a long time ago:
>
> https://datatracker.ietf.org/doc/html/draft-schmertmann-dice-codtls-00=
>
> Can the original authors tell us why they didn't go furthe= r with that
> approach?

The main reason was that it did not fi= t into the official DICE work program. Meanwhile, the student who did most = of the work (including a working prototype[1] which is also available as ru= bby gem) has graduated and left the university.

But there is no tech= nical reason for not taking this up again.

[1] https://github.com/SmallLars/codtls

G= r=FC=DFe
Olaf

_______________________________________________
= Ace mailing list
Ace@i= etf.org
https:= //www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents o= f this email and any attachments are confidential and may also be privilege= d. If you are not the intended recipient, please notify the sender immediat= ely and do not disclose the contents to any other person, use it for any pu= rpose, or store or copy the information in any medium. Thank you.
______= _________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinf= o/ace

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

--=_alternative 006EEC3D652581DF_=-- From nobody Tue Nov 21 14:04:13 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A84129BD7 for ; Tue, 21 Nov 2017 14:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jEwGLtXllvNc for ; Tue, 21 Nov 2017 14:04:07 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76A9128C83 for ; Tue, 21 Nov 2017 14:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1774; q=dns/txt; s=iport; t=1511301847; x=1512511447; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IpK2zcLRAMwEPqa81tIOO0MAnc8vf0K9h1gBSFxltP8=; b=NkAsQ+zr/PCGvtmNJ1JvjWY7h+oxH9fZ5twPoqOeupIdsGwyrGJFsrjd GOB+DSmRSuJEu2TSdynPktkm2eTrRvSwVrxBGC/xa1WUbbqI0looc0kZz CtEPXjsyDyT6NBJ/T39i5GdHaejxNN71IDsWaL4IMM/Idf4h9+WL+mskY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAABQohRa/5RdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOLoFUJweOF48qgX2WYhCCAQqCAYM6AoUJPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUeAQEBAwE6SwQCAQgRAQMBAQEeCQcyFAMGCAEBBAESCIoSCKscinUBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgzSCB4FVgWmDK4RoARIBhhcFoj4ClQGTVpYIAhE?= =?us-ascii?q?ZAYE5AR85gQNxehWDLYRfd4h6gSSBFAEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,432,1505779200"; d="scan'208";a="34160474" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2017 22:04:06 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vALM46In030345 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Nov 2017 22:04:06 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 21 Nov 2017 16:04:05 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Tue, 21 Nov 2017 16:04:05 -0600 From: "Panos Kampanakis (pkampana)" To: Michael Richardson , "ace@ietf.org" Thread-Topic: [Ace] Application Layer TLS Thread-Index: AdNirICUJkCFmJYSSCm/ASAY4sL+2QAQobTmAA8hyYAAB7n1QA== Date: Tue, 21 Nov 2017 22:04:05 +0000 Message-ID: <4baa66e1eece4b6e910a7bb6b8471ec4@XCH-ALN-010.cisco.com> References: <11699.1511290085@obiwan.sandelman.ca> In-Reply-To: <11699.1511290085@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 22:04:08 -0000 Someone had pointed it out on the mic in ACE @ IETF99, I think. Redefining = well established protocol functionality like (D)TLS' to secure communicatio= ns of other unencrypted application protocols comes with the risks of lack = of vetting and scrutiny, test of time and mistakes though.=20 I am not against this work, but I have seen many new secure protection chan= nel establishment protocols and I am not sure there are no issues which we= don't see now that will manifest themselves later.=20 -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Tuesday, November 21, 2017 1:48 PM To: ace@ietf.org Cc: Derek Atkins Subject: Re: [Ace] Application Layer TLS Derek Atkins wrote: >> based on the recent email discussion about the DTLS proxy I thought = it might >> be useful that there was some thinking about how to run TLS/DTLS at = the >> application layer. > I don't understand this statement. The whole point of TLS/DTLS is th= at > it runs at the Application Layer (as opposed to at the network layer, DTLS has to provide many of the services of the Transport and Network layer= (various amounts of reliability, fragmentation/segmentation) and there is = overhead in that. When running over things like CoAP, which *ALSO* provide= s those services, and in a more constrained network happy way, DTLS is way = less appealing. > Perhaps we need a better naming scheme here. In my opinion, the ISO layer naming system has always been better as docume= ntation, rather than architecture :-) -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed Nov 22 04:10:13 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9379E129427 for ; Wed, 22 Nov 2017 04:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 D5dCtEsvsCq2 for ; Wed, 22 Nov 2017 04:10:05 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0042.outbound.protection.outlook.com [104.47.1.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC2C129426 for ; Wed, 22 Nov 2017 04:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hTPqyWRCeBeoW48Bx5pymvjpXHR/d/4DFdBRrfPcXpA=; b=Abvp+zz7MzvzXeCqHIhwHBo/4Y9cOHEMRxJlqPrpC1ryn25Z+toJTlhvDPR9SaSOmKjMPM6DtrYL0fR1Z6OXoCGgNmDvcnWzltqlq2YfAxra7m1OG5D2ORFrhgy6l4MbZPAIg9bgTW2XHUhVr/PNrYTxIcu0X39nARaxLT7p2uY= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 22 Nov 2017 12:10:02 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::edae:da33:a0c9:fe3f%13]) with mapi id 15.20.0239.009; Wed, 22 Nov 2017 12:10:02 +0000 From: Hannes Tschofenig To: Derek Atkins CC: "ace@ietf.org" Thread-Topic: [Ace] Application Layer TLS Thread-Index: AdNirICUJkCFmJYSSCm/ASAY4sL+2QAQmzfLAAQblSA= Date: Wed, 22 Nov 2017 12:10:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:F224rB2CsE0lsQnza+Zoan8c6WEI7k5X1qun8oi6P/FXNk0ixKeOYOe9BPkPODMzq2pxunoNRLhh12wiw3DMegkpWaTGyb4ZrqUxAOcmlGjztJmZea91+0Q2A9Fq2XNeZnLQ7dHNnTY5Z7vEZmJDSJs7zIP2e1U00LfPLwuZ8LhBhB1qaBi6rydvVG/vyrzxHraE15WIIIoiJbTDE9/JSRuYpxBvg+26mvNDmVnkLl4Wd3XqbVKh+bqRBy+g0isbByr5KfPNkGQ9p7WztVoLOCjZOomUJrMiqekYlgvQI3Z6SgEONa7IK1aQP2IOVxC8/3kf83Er+fe3hdkmHI+U7cj5Hjr46sCWRqdvZvGkpVY=; 5:2cDyS9hQAOBQzGkjjzql6Td+hIu6LnTkhiOasfK027/BAULrWrZqUSPIGe+aMceeycen7tj2NcDWXHk8vO2GYVawEYl3HafFeV+j1MbkI5eikUd5QyAg6yzHma7ww32Bu8Hehm5Xc8wljaI8eMQJO3GCiy6H3I728rJd0Lomdtk=; 24:s95LSAS5vkds70zvxSyFdiWt6MrZlECsxcKy0UX8FevNQHNM6rzkRDIHerHZppL4z96hJOzBQov/xf9JdZFMjqHCsOcvhFa4XNIIr+lPUjk=; 7:EaBZZAjg2iVKFzbabCY0tifeIf8sSTZEb1W0twYHNJX9jPoKjlEkqKRRPW7vkYmVgs1BSc8SRPQcLPSDnSeSjMQ9A+Z6YIFVbMvrbG29LjI3qQdax0s9FDOoLVDq67qiyTeidv/Vsy20lH83WziCHPesIgJhSo5BS6GsgaNjbfoVt2+NZGL8trsS+dR2bxjRnmAQB2zEsM0iShSbEr2+eKZ8YP2VUzkv0bDz4yQU+BedZItJxpAoj9SpTULWQhTG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cfb071ea-6dbd-4256-cb6d-08d531a1f5b2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(5600022)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(180628864354917)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(199003)(53754006)(13464003)(189002)(40434004)(54356999)(6436002)(50986999)(74316002)(101416001)(76176999)(305945005)(3846002)(7736002)(102836003)(6116002)(99286004)(53546010)(5660300001)(15974865002)(2950100002)(8676002)(81166006)(81156014)(7696004)(6916009)(33656002)(189998001)(8936002)(66066001)(5250100002)(3280700002)(2906002)(68736007)(966005)(2900100001)(72206003)(14454004)(3660700001)(316002)(6246003)(478600001)(53936002)(9686003)(6306002)(25786009)(4326008)(105586002)(106356001)(5890100001)(229853002)(6506006)(97736004)(86362001)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfb071ea-6dbd-4256-cb6d-08d531a1f5b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 12:10:02.3799 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: Re: [Ace] Application Layer TLS X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 12:10:12 -0000 Hi Derek There might indeed be room for improvement on the terminology front. I was = using the "application layer TLS terminology" because it was used in discus= sions in the TLS working group and at the TLS WG session @ IETF#100. I suspect that the use cases in various documents, which differ slightly, m= ight give a better idea what we try to accomplish. Ciao Hannes -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: 21 November 2017 18:34 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] Application Layer TLS Hannes, Hannes Tschofenig writes: > Hi all, > > based on the recent email discussion about the DTLS proxy I thought it > might be useful that there was some thinking about how to run TLS/DTLS > at the application layer. I don't understand this statement. The whole point of TLS/DTLS is that it = runs at the Application Layer (as opposed to at the network layer, like IPs= ec). Indeed, the fact that it could run at the application layer (e.g. in = a web brower / web server) is exactly why SSL/TLS was created in the first = place. It meant you didn't require waiting for the kernel/OS to add networ= k security. > There are essentially two drafts that have been submitted at the same > time for IETF#100, namely > > https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 So you are moving the application layer up even higher than the historic vi= ew of an application layer? Perhaps we need a better naming scheme here. > Both teams have worked on prototypes and getting it to work was > remarkably simple. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Nov 22 11:47:00 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC4F12EB4F for ; Wed, 22 Nov 2017 11:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sei.cmu.edu 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 77VYrr7k1Kzd for ; Wed, 22 Nov 2017 11:46:53 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB23612956B for ; Wed, 22 Nov 2017 11:46:52 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAMJkohp011016; Wed, 22 Nov 2017 14:46:50 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vAMJkohp011016 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1511380011; bh=IKZGUVngQeCyUCLyp0oe1Fp8PSIHP6qHqCwIBHChvbw=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Syfo7pBS9QmOCwg5BRS0jtRYeJE4SmY99YihfLh+zuMth0lO38IPXrYM4n/Abh61Y s2K+y4iqAR2iebyMkpWBlieOAeU9KaNzuWGNwQRxxFNpmuMaiEVaEdUZyokdm+Zodd 0vZEsPlzcGT8bFfi3cB61JzriQVRFWlRjPSkFiVg= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAMJkl7p002853; Wed, 22 Nov 2017 14:46:48 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 14:46:47 -0500 From: Grace Lewis To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] Questions about draft-ietf-ace-oauth-authz Thread-Index: AQHTXS9HNSfQVd/kD0OYlzfgmKPPvqMg2uMA Date: Wed, 22 Nov 2017 19:46:47 +0000 Message-ID: References: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> In-Reply-To: <099e2b57-ca4a-6fd8-db42-a74365f90753@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-originating-ip: [10.64.104.177] Content-Type: multipart/alternative; boundary="_000_D8A13748944B4DD08A0A33063084E3F6seicmuedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Questions about draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 19:46:57 -0000 --_000_D8A13748944B4DD08A0A33063084E3F6seicmuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIGNvbWJpbmVkIHJlcGx5IGZyb20gdGhlIHRlYW0gYXQgdGhlIFNFSSB0aGF0IGlz IGxvb2tpbmcgYXQgQUNFIGZvciB0YWN0aWNhbCBlbnZpcm9ubWVudHMNCg0KMS4pIEN1cnJlbnRs eSB0aGUgZnJhbWV3b3JrIHJlcXVpcmVzIHRoZSB1c2Ugb2YgQ0JPUiBhcyBkYXRhIG9iamVjdA0K Zm9ybWF0IGFuZCBvZiBwYXJhbWV0ZXIgbmFtZSBhYmJyZXZpYXRpb25zLiBTb21lIGNvbW1lbnRz IHZvaWNlZCB0aGUNCm9waW5pb24gdGhhdCB0aGVzZSByZXF1aXJlbWVudHMgc2hvdWxkIGJlIHJl bGF4ZWQgYW5kIHRoZSBjaG9pY2UgbGVmdCB0bw0KdGhlIHByb2ZpbGVzLg0KSSBzZWUgdGhlIGZv bGxvd2luZyBvcHRpb25zOg0KDQphLikgS2VlcCBpdCBhcyBpdCBpcyAoaS5lLiBDQk9SIGFuZCBw YXJhbWV0ZXIgbmFtZSBhYmJyZXZpYXRpb25zIFJFUVVJUkVEKQ0KDQpiLikgUmVtb3ZlIGFsbCBy ZXF1aXJlbWVudHMgKGkuZS4gZGF0YSBmb3JtYXQgdG90YWxseSB1cCB0byB0aGUgcHJvZmlsZXMp DQoNCmMuKSBSRUNPTU1FTkQgdGhlIHVzZSBvZiBDQk9SIGFuZCBwYXJhbWV0ZXIgYWJicmV2aWF0 aW9ucyAoYWxsb3dpbmcNCnByb2ZpbGVzIHRvIHNwZWNpZnkgc29tZXRoaW5nIGVsc2UpDQoNCldo YXQgZG9lcyB0aGUgZ3JvdXAgdGhpbmsgd2Ugc2hvdWxkIGRvPw0KDQoNCiAgKiAgIFJlZ2FyZGlu ZyB0aGUgdXNlIG9mIENCT1IsIE9wdGlvbiBjIHNlZW1zIHRvIGJlIHRoZSBiZXN0IGNvbXByb21p c2UgYmV0d2VlbiBhIGFuZCBiLiBIb3dldmVyLCBnaXZlbiB0aGF0IHRoZSBnb2FsIG9mIEFDRSBp cyBzbWFsbCwgY29tcGFjdCBkYXRhIGZvcm1hdHMgdGhhdCBsZWFkIHRvIHNtYWxsIGJhbmR3aWR0 aCBhbmQgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMsIHdvdWxkbuKAmXQgaXQgbWFrZSBzZW5zZSB0 byByZXF1aXJlIENCT1I/IERpc2NsYWltZXIgdGhhdCB3ZSBhcmUgbm90IGZhbWlsaWFyIHdpdGgg YWxsIG90aGVyIElFVEYgb3B0aW9uczogV2hhdCB3b3VsZCBiZSBvdGhlciBhbHRlcm5hdGl2ZXMg dGhhdCBwcm92aWRlIHRoZSBzYW1lIHNtYWxsLCBjb21wYWN0IGRhdGEgZm9ybWF0Pw0KDQoyLikg U2hvdWxkIHRoZSB3b3JrIG9uIENsaWVudCBUb2tlbg0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNzZWN0aW9uLTUuNy40KQ0KYmUgaW4g dGhlIGRyYWZ0IG9yIG1vdmVkIG91dCB0byBhIHNlcGFyYXRlIGRvY3VtZW50Pw0KDQpCYWNrZ3Jv dW5kOiBXZSBkZXNpZ25lZCBDbGllbnQgVG9rZW4gdG8gYWRkcmVzcyB0aGUgdXNlIGNhc2VzIHdo ZXJlIHRoZQ0KY2xpZW50IGhhcyBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5IGFuZCBuZWVkcyB0 byByZWNlaXZlIGluZm9ybWF0aW9uDQpmcm9tIHRoZSBBUy4NCg0KDQogICogICBObyByZWFsIG9w aW5pb24gaGVyZS4gSXQgcmVhbGx5IGRlcGVuZHMgb24gd2hlcmUgdGhlIGdyb3VwIHRoaW5rcyB0 aGF0IGl0IGlzIGFwcGxpY2FibGUgdG8gdGhpbmdzIG90aGVyIHRoYW4gQUNFIGFuZC9vciBpdCBp cyByZWFsbHkgb3B0aW9uYWwgYW5kIG5vdCBhbiBpbnRlZ3JhbCBwYXJ0IG9mIEFDRS4NCg0KMy4p IFdoYXQgaXMgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgVG9rZW4gQmluZGluZyBXb3JrIGF0IE9B dXRoDQooaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC10 b2tlbi1iaW5kaW5nLykgPw0KDQozLWJpcy4pIFRvIG1lIGl0IHNlZW1zIGxpa2UgdGhpcyBjb3Vs ZCBnbyBpbnRvIGEgcHJvZmlsZSBvZiB0aGUgQUNFDQpmcmFtZXdvcmsuIFdvdWxkIHNvbWVvbmUg YmUgd2lsbGluZyB0byB3cml0ZSBzdWNoIGEgZHJhZnQ/DQoNCg0KICAqICAgTm90IHZlcnkgZmFt aWxpYXIgd2l0aCB0aGUgdG9rZW4gYmluZGluZyB3b3JrLg0KDQo0LikgV2hhdCBwYXJhbWV0ZXJz IHRvIHB1dCBpbnRvIHRoZSByZXNwb25zZSB0byBhbiB1bmF1dGhvcml6ZWQgcmVxdWVzdA0KKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNz ZWN0aW9uLTUuMS4yKT8NCg0KSmltIFNjaGFhZCBzdWdnZXN0ZWQgdG8gYWRkIGluZm9ybWF0aW9u IGFib3V0IHRoZSBhdWRpZW5jZSBhbmQgc2NvcGUgdGhlDQpSUyBleHBlY3RzIHRvIGdyYW50IGFj Y2VzcyB0byB0aGUgZ2l2ZW4gcmVzb3VyY2UNCihodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL2FjZS9pT2JmMEVDaG8tLTdGQ1lXQlJRWVVIdE9zQncpDQoNCldlIGhhdmUgaGFk IHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGFscmVhZHksIGJ1dCBJIGhhdmUgbm90IHNl ZW4gYQ0KY29uY2x1c2l2ZSAiZGVjaXNpb24iIGJ5IHRoZSBncm91cCAoaWYgc3VjaCBhIHRoaW5n IGNhbiBleGlzdCkgYXMgdG8NCndoYXQgdG8gZG8uDQoNCg0KICAqICAgRm9yIHRhY3RpY2FsIGVu dmlyb25tZW50cyAob3IgYW55IGVudmlyb25tZW50IHdpdGggaGlnaGVyIHNlY3VyaXR5IHJlcXVp cmVtZW50cyB0aGFuIHRoZSBob21lLCBmb3IgZXhhbXBsZSkgcHJvdmlkaW5nIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gdG8gYSBwb3RlbnRpYWxseSB1bmF1dGhvcml6ZWQgcmVxdWVzdCBpcyBub3Qg YSBnb29kIGlkZWEuIEhvd2V2ZXIsIHdlIGRvIHVuZGVyc3RhbmQgdGhhdCB0aGlzIG1heSBtYWtl IHNlbnNlIGluIG90aGVyIHVzZSBjYXNlcy4gVGhlIHN1Z2dlc3Rpb24gbWFkZSBiZWZvcmUgYWxv bmcgdGhlIGxpbmVzIG9mIOKAnEl0IHNob3VsZCBiZSB1cCB0byB0aGUgZGVwbG95bWVudCB3aGF0 IGl0IHdhbnRzIHRvIHJldmVhbOKAnSB3b3VsZCBtYWtlIHNlbnNlLCBhcyBsb25nIGFzIGl0IGlz IG5vdCByZXF1aXJlZC4gVGh1cywgaW4gb3VyIGNhc2UsIHdlIHdvdWxkIE5PVCBpbXBsZW1lbnQg aXQuIEJ1dCwgdGhlcmUgYXJlIGxpa2VseSBvdGhlciB1c2UgY2FzZXMgaW4gd2hpY2ggaXQgd291 bGQgYmUgdXNlZnVsIHRvIGRvIHNvLg0KDQo1LikgRnJhbmNlc2NhIHN1Z2dlc3RlZCB0byBhbGxv dyB0aGUgQVMgdG8gcmV0dXJuIGEgbGlzdCBvZiBwb3NzaWJsZQ0KcHJvZmlsZXMgdG8gdGhlIGNs aWVudCBpbiByZXNwb25zZSB0byBhbiBhY2Nlc3MgdG9rZW4gcmVxdWVzdC4gQ3VycmVudGx5DQpv bmx5IG9uZSBwcm9maWxlIGlzIHNlbGVjdGVkIGFuZCBvcHRpb25hbGx5IHJldHVybmVkIGJ5IHRo ZSBBUyAoaXQgY291bGQNCmV2ZW4gYmUgaW1wbGljaXQgYW5kIG5vdCBiZSByZXR1cm5lZCBhdCBh bGwpLg0KDQpCYWNrZ3JvdW5kOiBUaGUgd2F5IEkgd2FzIHRoaW5raW5nIHRoaXMgc2hvdWxkIHdv cmsgd2FzIHRoYXQgYm90aCB0aGUNCmNsaWVudCBhbmQgdGhlIFJTIG5lZWQgdG8gYmUgcmVnaXN0 ZXJlZCBhdCB0aGUgQVMgaW4gb3JkZXIgZm9yIHRoZQ0KZXhjaGFuZ2VzIHRvIHdvcmsuIEkgbWFk ZSB0aGUgYXNzdW1wdGlvbg0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWFjZS1vYXV0aC1hdXRoei0wOCNhcHBlbmRpeC1EKQ0KdGhhdCB0aGUgQVMgd291bGQgYWxyZWFk eSBrbm93IHdoaWNoIHByb2ZpbGVzIGJvdGggQyBhbmQgUlMgc3VwcG9ydCwgYW5kDQp0aHVzIGp1 c3Qgc2VsZWN0IHRoZSBpZGVhbCBvbmUuDQoNCldoYXQgZG9lcyB0aGUgZ3JvdXAgdGhpbmssIHNo b3VsZCB3ZSBpbnN0ZWFkIGFsbG93IGZvciBhIGxpc3Qgb2YNCnByb2ZpbGVzIGFuZCBsZXQgdGhl IGNsaWVudCBzZWxlY3Qgd2hpY2ggb25lIHRvIHVzZT8NCg0KDQogICogICBBZ2FpbiwgZnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB0YWN0aWNhbCBlbnZpcm9ubWVudHMsIGJlY2F1c2Ugd2Ug4oCc ZW5mb3JjZeKAnSBwYWlyaW5nIGJldHdlZW4gQ2xpZW50IGFuZCB0aGUgQVMsIHRoZSBBUyBzaG91 bGQgaGF2ZSBlbm91Z2gga25vd2xlZGdlIHRvIGRlY2lkZSB3aGljaCBwcm9maWxlIHRvIHVzZS4g QnV0LCB3aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgcHJvZmlsZSB0aGF0IHdvcmtzIGZv ciBib3RoLiBEb2VzIHRoZSBBUyByZWFsbHkgaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gc2Vs ZWN0IHRoZSDigJxpZGVhbOKAnT8gSW4gdGhhdCBjYXNlLCBzb21ldGhpbmcgbGlrZSB3aGF0IEZy YW5jZXNjYSBpcyBzdWdnZXN0aW5nIHdvdWxkIG1ha2Ugc2Vuc2UuIEhvd2V2ZXIsIEkgdGhpbmsg aXQgd291bGQgYmUgdXNlZnVsIGZvciB1cyB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgdXNlIGNh c2VzIGZvciBtdWx0aXBsZSBwcm9maWxlcyB0byBzZWUgaWYgaXQgcmVhbGx5IG1ha2VzIHNlbnNl LiBUaGUgcG90ZW50aWFsIG5lZWQgZm9yIHRoaXMgbmVnb3RpYXRpb24gaXMgdW5kZXJzdG9vZCwg YnV0IGl0IGFsc28gbWFrZXMgdGhlIHdob2xlIHByb2Nlc3MgbG9uZ2VyIGFuZCBtb3JlIGNvbXBs ZXguIFVubGVzcyB3ZSBoYXZlIGdvb2QgdXNlIGNhc2VzLCBhbmQgYW4gdW5kZXJzdGFuZGluZyB0 aGF0IHRoaXMgbWlnaHQgYmUgdGhlIG5vcm0gcmF0aGVyIHRoYW4gdGhlIGV4Y2VwdGlvbiwgdGhl biBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGFkZCB0byBBQ0UuIElmIG5vdCwgbWF5YmUgYW4gZXhw ZXJpbWVudGFsIFJGQz8NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkdyYWNlIEEuIExld2lzLCBQaC5ELg0KUHJpbmNpcGFsIFJlc2VhcmNoZXIN CkNhcm5lZ2llIE1lbGxvbiBTb2Z0d2FyZSBFbmdpbmVlcmluZyBJbnN0aXR1dGUNClNvZnR3YXJl IFNvbHV0aW9ucyBEaXZpc2lvbiAoU1NEKQ0KVGFjdGljYWwgVGVjaG5vbG9naWVzIEdyb3VwIChU VEcpDQoNCjQ1MDAgRmlmdGggQXZlLg0KUGl0dHNidXJnaCwgUEEgMTUyMTMNClBob25lOiAoNDEy KSAyNjgtNTg1MQ0KaHR0cDovL3d3dy5zZWkuY211LmVkdS9zdGFmZi9nbGV3aXMNCg0KRnJvbTog QWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEx1ZHdpZyBTZWl0eiA8bHVk d2lnLnNlaXR6QHJpLnNlPg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgNDo1 OSBBTQ0KVG86ICJhY2VAaWV0Zi5vcmciIDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbQWNlXSBR dWVzdGlvbnMgYWJvdXQgZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHoNCg0KSGVsbG8gQUNFLA0K DQpkdXJpbmcgdGhlIElFVEYgMTAwIHNlc3Npb24gdGhlcmUgd2VyZSBhIG51bWJlciBvZiBxdWVz dGlvbnMgb24NCmRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6IHRoYXQgSSB3b3VsZCBsaWtlIHRv IGJyaW5nIHRvIHRoZSBsaXN0IGZvcg0KZmVlZGJhY2s6DQoNCjEuKSBDdXJyZW50bHkgdGhlIGZy YW1ld29yayByZXF1aXJlcyB0aGUgdXNlIG9mIENCT1IgYXMgZGF0YSBvYmplY3QNCmZvcm1hdCBh bmQgb2YgcGFyYW1ldGVyIG5hbWUgYWJicmV2aWF0aW9ucy4gU29tZSBjb21tZW50cyB2b2ljZWQg dGhlDQpvcGluaW9uIHRoYXQgdGhlc2UgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSByZWxheGVkIGFu ZCB0aGUgY2hvaWNlIGxlZnQgdG8NCnRoZSBwcm9maWxlcy4NCkkgc2VlIHRoZSBmb2xsb3dpbmcg b3B0aW9uczoNCg0KYS4pIEtlZXAgaXQgYXMgaXQgaXMgKGkuZS4gQ0JPUiBhbmQgcGFyYW1ldGVy IG5hbWUgYWJicmV2aWF0aW9ucyBSRVFVSVJFRCkNCg0KYi4pIFJlbW92ZSBhbGwgcmVxdWlyZW1l bnRzIChpLmUuIGRhdGEgZm9ybWF0IHRvdGFsbHkgdXAgdG8gdGhlIHByb2ZpbGVzKQ0KDQpjLikg UkVDT01NRU5EIHRoZSB1c2Ugb2YgQ0JPUiBhbmQgcGFyYW1ldGVyIGFiYnJldmlhdGlvbnMgKGFs bG93aW5nDQpwcm9maWxlcyB0byBzcGVjaWZ5IHNvbWV0aGluZyBlbHNlKQ0KDQpXaGF0IGRvZXMg dGhlIGdyb3VwIHRoaW5rIHdlIHNob3VsZCBkbz8NCg0KDQoyLikgU2hvdWxkIHRoZSB3b3JrIG9u IENsaWVudCBUb2tlbg0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFj ZS1vYXV0aC1hdXRoei0wOCNzZWN0aW9uLTUuNy40KQ0KYmUgaW4gdGhlIGRyYWZ0IG9yIG1vdmVk IG91dCB0byBhIHNlcGFyYXRlIGRvY3VtZW50Pw0KDQpCYWNrZ3JvdW5kOiBXZSBkZXNpZ25lZCBD bGllbnQgVG9rZW4gdG8gYWRkcmVzcyB0aGUgdXNlIGNhc2VzIHdoZXJlIHRoZQ0KY2xpZW50IGhh cyBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5IGFuZCBuZWVkcyB0byByZWNlaXZlIGluZm9ybWF0 aW9uDQpmcm9tIHRoZSBBUy4NCg0KMy4pIFdoYXQgaXMgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUg VG9rZW4gQmluZGluZyBXb3JrIGF0IE9BdXRoDQooaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1iaW5kaW5nLykgPw0KDQozLWJpcy4pIFRvIG1l IGl0IHNlZW1zIGxpa2UgdGhpcyBjb3VsZCBnbyBpbnRvIGEgcHJvZmlsZSBvZiB0aGUgQUNFDQpm cmFtZXdvcmsuIFdvdWxkIHNvbWVvbmUgYmUgd2lsbGluZyB0byB3cml0ZSBzdWNoIGEgZHJhZnQ/ DQoNCg0KNC4pIFdoYXQgcGFyYW1ldGVycyB0byBwdXQgaW50byB0aGUgcmVzcG9uc2UgdG8gYW4g dW5hdXRob3JpemVkIHJlcXVlc3QNCihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1hY2Utb2F1dGgtYXV0aHotMDgjc2VjdGlvbi01LjEuMik/DQoNCkppbSBTY2hhYWQgc3Vn Z2VzdGVkIHRvIGFkZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXVkaWVuY2UgYW5kIHNjb3BlIHRo ZQ0KUlMgZXhwZWN0cyB0byBncmFudCBhY2Nlc3MgdG8gdGhlIGdpdmVuIHJlc291cmNlDQooaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hY2UvaU9iZjBFQ2hvLS03RkNZV0JS UVlVSHRPc0J3KQ0KDQpXZSBoYXZlIGhhZCBzb21lIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyBh bHJlYWR5LCBidXQgSSBoYXZlIG5vdCBzZWVuIGENCmNvbmNsdXNpdmUgImRlY2lzaW9uIiBieSB0 aGUgZ3JvdXAgKGlmIHN1Y2ggYSB0aGluZyBjYW4gZXhpc3QpIGFzIHRvDQp3aGF0IHRvIGRvLg0K DQo1LikgRnJhbmNlc2NhIHN1Z2dlc3RlZCB0byBhbGxvdyB0aGUgQVMgdG8gcmV0dXJuIGEgbGlz dCBvZiBwb3NzaWJsZQ0KcHJvZmlsZXMgdG8gdGhlIGNsaWVudCBpbiByZXNwb25zZSB0byBhbiBh Y2Nlc3MgdG9rZW4gcmVxdWVzdC4gQ3VycmVudGx5DQpvbmx5IG9uZSBwcm9maWxlIGlzIHNlbGVj dGVkIGFuZCBvcHRpb25hbGx5IHJldHVybmVkIGJ5IHRoZSBBUyAoaXQgY291bGQNCmV2ZW4gYmUg aW1wbGljaXQgYW5kIG5vdCBiZSByZXR1cm5lZCBhdCBhbGwpLg0KDQpCYWNrZ3JvdW5kOiBUaGUg d2F5IEkgd2FzIHRoaW5raW5nIHRoaXMgc2hvdWxkIHdvcmsgd2FzIHRoYXQgYm90aCB0aGUNCmNs aWVudCBhbmQgdGhlIFJTIG5lZWQgdG8gYmUgcmVnaXN0ZXJlZCBhdCB0aGUgQVMgaW4gb3JkZXIg Zm9yIHRoZQ0KZXhjaGFuZ2VzIHRvIHdvcmsuIEkgbWFkZSB0aGUgYXNzdW1wdGlvbg0KKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNhcHBl bmRpeC1EKQ0KdGhhdCB0aGUgQVMgd291bGQgYWxyZWFkeSBrbm93IHdoaWNoIHByb2ZpbGVzIGJv dGggQyBhbmQgUlMgc3VwcG9ydCwgYW5kDQp0aHVzIGp1c3Qgc2VsZWN0IHRoZSBpZGVhbCBvbmUu DQoNCldoYXQgZG9lcyB0aGUgZ3JvdXAgdGhpbmssIHNob3VsZCB3ZSBpbnN0ZWFkIGFsbG93IGZv ciBhIGxpc3Qgb2YNCnByb2ZpbGVzIGFuZCBsZXQgdGhlIGNsaWVudCBzZWxlY3Qgd2hpY2ggb25l IHRvIHVzZT8NCg0KDQpSZWdhcmRzLA0KDQpMdWR3aWcNCg0KLS0NCkx1ZHdpZyBTZWl0eiwgUGhE DQpTZWN1cml0eSBMYWIsIFJJU0UgU0lDUw0KUGhvbmUgKzQ2KDApNzAtMzQ5IDkyIDUxDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGlu ZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg0K --_000_D8A13748944B4DD08A0A33063084E3F6seicmuedu_ Content-Type: text/html; charset="utf-8" Content-ID: <692D1F2DA4CBB94899A7DE9C8449CCC0@sei.cmu.edu> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpPcHRpbWE7DQoJcGFub3NlLTE6MiAwIDUgMyA2IDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAw IDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIyNDg3NDMwMjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjEyMDI2NDE0Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjI2MjAyOTY3NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTk3ODY3MDE3Mjt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjc0MDUyMTMzNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTM5MDk5ODc4MDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjEzMzg1Nzky MDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI0NTAwOTk0MDt9DQpAbGlzdCBsMzpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 DQoJe21zby1saXN0LWlkOjEzNzAxMDUzNjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3ODA5 Mjc3NjY7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgY29tYmluZWQgcmVw bHkgZnJvbSB0aGUgdGVhbSBhdCB0aGUgU0VJIHRoYXQgaXMgbG9va2luZyBhdCBBQ0UgZm9yIHRh Y3RpY2FsIGVudmlyb25tZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLikgQ3VycmVudGx5 IHRoZSBmcmFtZXdvcmsgcmVxdWlyZXMgdGhlIHVzZSBvZiBDQk9SIGFzIGRhdGEgb2JqZWN0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3JtYXQgYW5kIG9mIHBhcmFtZXRl ciBuYW1lIGFiYnJldmlhdGlvbnMuIFNvbWUgY29tbWVudHMgdm9pY2VkIHRoZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3BpbmlvbiB0aGF0IHRoZXNlIHJlcXVpcmVtZW50 cyBzaG91bGQgYmUgcmVsYXhlZCBhbmQgdGhlIGNob2ljZSBsZWZ0IHRvPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgcHJvZmlsZXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHNlZSB0aGUgZm9sbG93aW5nIG9wdGlvbnM6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmEuKSBLZWVwIGl0IGFzIGl0IGlzIChpLmUuIENCT1IgYW5kIHBhcmFtZXRl ciBuYW1lIGFiYnJldmlhdGlvbnMgUkVRVUlSRUQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmIu KSBSZW1vdmUgYWxsIHJlcXVpcmVtZW50cyAoaS5lLiBkYXRhIGZvcm1hdCB0b3RhbGx5IHVwIHRv IHRoZSBwcm9maWxlcyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Yy4pIFJFQ09NTUVORCB0aGUg dXNlIG9mIENCT1IgYW5kIHBhcmFtZXRlciBhYmJyZXZpYXRpb25zIChhbGxvd2luZzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJvZmlsZXMgdG8gc3BlY2lmeSBzb21ldGhp bmcgZWxzZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkb2VzIHRoZSBncm91cCB0aGlu ayB3ZSBzaG91bGQgZG8/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzEiPlJlZ2FyZGluZyB0aGUgdXNlIG9mIENCT1IsIE9wdGlvbiBjIHNlZW1z IHRvIGJlIHRoZSBiZXN0IGNvbXByb21pc2UgYmV0d2VlbiBhIGFuZCBiLiBIb3dldmVyLCBnaXZl biB0aGF0IHRoZSBnb2FsIG9mIEFDRSBpcyBzbWFsbCwgY29tcGFjdCBkYXRhIGZvcm1hdHMgdGhh dCBsZWFkIHRvIHNtYWxsIGJhbmR3aWR0aCBhbmQgcHJvY2Vzc2luZw0KIHJlcXVpcmVtZW50cywg d291bGRu4oCZdCBpdCBtYWtlIHNlbnNlIHRvIHJlcXVpcmUgQ0JPUj8gRGlzY2xhaW1lciB0aGF0 IHdlIGFyZSBub3QgZmFtaWxpYXIgd2l0aCBhbGwgb3RoZXIgSUVURiBvcHRpb25zOiBXaGF0IHdv dWxkIGJlIG90aGVyIGFsdGVybmF0aXZlcyB0aGF0IHByb3ZpZGUgdGhlIHNhbWUgc21hbGwsIGNv bXBhY3QgZGF0YSBmb3JtYXQ/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuKSBTaG91 bGQgdGhlIHdvcmsgb24gQ2xpZW50IFRva2VuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4oPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYWNlLW9hdXRoLWF1dGh6LTA4I3NlY3Rpb24tNS43LjQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMDgj c2VjdGlvbi01LjcuNDwvYT4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5i ZSBpbiB0aGUgZHJhZnQgb3IgbW92ZWQgb3V0IHRvIGEgc2VwYXJhdGUgZG9jdW1lbnQ/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJhY2tncm91bmQ6IFdlIGRlc2lnbmVkIENsaWVudCBUb2tlbiB0 byBhZGRyZXNzIHRoZSB1c2UgY2FzZXMgd2hlcmUgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5jbGllbnQgaGFzIGludGVybWl0dGVudCBjb25uZWN0aXZpdHkgYW5kIG5l ZWRzIHRvIHJlY2VpdmUgaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmZyb20gdGhlIEFTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwzIGxldmVsMSBsZm8yIj5ObyByZWFsIG9waW5pb24gaGVyZS4gSXQgcmVhbGx5IGRlcGVu ZHMgb24gd2hlcmUgdGhlIGdyb3VwIHRoaW5rcyB0aGF0IGl0IGlzIGFwcGxpY2FibGUgdG8gdGhp bmdzIG90aGVyIHRoYW4gQUNFIGFuZC9vciBpdCBpcyByZWFsbHkgb3B0aW9uYWwgYW5kIG5vdCBh biBpbnRlZ3JhbCBwYXJ0IG9mIEFDRS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4p IFdoYXQgaXMgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgVG9rZW4gQmluZGluZyBXb3JrIGF0IE9B dXRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1iaW5kaW5n LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tYmluZGluZy88L2E+KSA/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMtYmlzLikgVG8gbWUgaXQgc2VlbXMgbGlrZSB0aGlzIGNvdWxkIGdvIGludG8gYSBwcm9maWxl IG9mIHRoZSBBQ0U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZyYW1ld29y ay4gV291bGQgc29tZW9uZSBiZSB3aWxsaW5nIHRvIHdyaXRlIHN1Y2ggYSBkcmFmdD88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMyI+Tm90IHZl cnkgZmFtaWxpYXIgd2l0aCB0aGUgdG9rZW4gYmluZGluZyB3b3JrLjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj40LikgV2hhdCBwYXJhbWV0ZXJzIHRvIHB1dCBpbnRvIHRoZSByZXNwb25z ZSB0byBhbiB1bmF1dGhvcml6ZWQgcmVxdWVzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWFjZS1vYXV0aC1hdXRoei0wOCNzZWN0aW9uLTUuMS4yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTA4I3NlY3Rp b24tNS4xLjI8L2E+KT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmltIFNjaGFhZCBzdWdnZXN0 ZWQgdG8gYWRkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhdWRpZW5jZSBhbmQgc2NvcGUgdGhlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SUyBleHBlY3RzIHRvIGdyYW50IGFj Y2VzcyB0byB0aGUgZ2l2ZW4gcmVzb3VyY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPig8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Fj ZS9pT2JmMEVDaG8tLTdGQ1lXQlJRWVVIdE9zQnciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FjZS9pT2JmMEVDaG8tLTdGQ1lXQlJRWVVIdE9z Qnc8L2E+KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGhhZCBzb21lIGRpc2N1c3Np b24gb24gdGhpcyB0b3BpYyBhbHJlYWR5LCBidXQgSSBoYXZlIG5vdCBzZWVuIGE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbmNsdXNpdmUgJnF1b3Q7ZGVjaXNpb24mcXVv dDsgYnkgdGhlIGdyb3VwIChpZiBzdWNoIGEgdGhpbmcgY2FuIGV4aXN0KSBhcyB0bzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hhdCB0byBkby48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+Rm9yIHRhY3RpY2FsIGVu dmlyb25tZW50cyAob3IgYW55IGVudmlyb25tZW50IHdpdGggaGlnaGVyIHNlY3VyaXR5IHJlcXVp cmVtZW50cyB0aGFuIHRoZSBob21lLCBmb3IgZXhhbXBsZSkgcHJvdmlkaW5nIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gdG8gYSBwb3RlbnRpYWxseSB1bmF1dGhvcml6ZWQgcmVxdWVzdCBpcyBub3Qg YQ0KIGdvb2QgaWRlYS4gSG93ZXZlciwgd2UgZG8gdW5kZXJzdGFuZCB0aGF0IHRoaXMgbWF5IG1h a2Ugc2Vuc2UgaW4gb3RoZXIgdXNlIGNhc2VzLiBUaGUgc3VnZ2VzdGlvbiBtYWRlIGJlZm9yZSBh bG9uZyB0aGUgbGluZXMgb2Yg4oCcSXQgc2hvdWxkIGJlIHVwIHRvIHRoZSBkZXBsb3ltZW50IHdo YXQgaXQgd2FudHMgdG8gcmV2ZWFs4oCdIHdvdWxkIG1ha2Ugc2Vuc2UsIGFzIGxvbmcgYXMgaXQg aXMgbm90IHJlcXVpcmVkLiBUaHVzLCBpbiBvdXIgY2FzZSwNCiB3ZSB3b3VsZCBOT1QgaW1wbGVt ZW50IGl0LiBCdXQsIHRoZXJlIGFyZSBsaWtlbHkgb3RoZXIgdXNlIGNhc2VzIGluIHdoaWNoIGl0 IHdvdWxkIGJlIHVzZWZ1bCB0byBkbyBzby48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ NS4pIEZyYW5jZXNjYSBzdWdnZXN0ZWQgdG8gYWxsb3cgdGhlIEFTIHRvIHJldHVybiBhIGxpc3Qg b2YgcG9zc2libGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByb2ZpbGVz IHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gYW4gYWNjZXNzIHRva2VuIHJlcXVlc3QuIEN1 cnJlbnRseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b25seSBvbmUgcHJv ZmlsZSBpcyBzZWxlY3RlZCBhbmQgb3B0aW9uYWxseSByZXR1cm5lZCBieSB0aGUgQVMgKGl0IGNv dWxkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ldmVuIGJlIGltcGxpY2l0 IGFuZCBub3QgYmUgcmV0dXJuZWQgYXQgYWxsKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFj a2dyb3VuZDogVGhlIHdheSBJIHdhcyB0aGlua2luZyB0aGlzIHNob3VsZCB3b3JrIHdhcyB0aGF0 IGJvdGggdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jbGllbnQgYW5k IHRoZSBSUyBuZWVkIHRvIGJlIHJlZ2lzdGVyZWQgYXQgdGhlIEFTIGluIG9yZGVyIGZvciB0aGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4Y2hhbmdlcyB0byB3b3JrLiBJ IG1hZGUgdGhlIGFzc3VtcHRpb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPig8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1h Y2Utb2F1dGgtYXV0aHotMDgjYXBwZW5kaXgtRCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNhcHBlbmRpeC1E PC9hPik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgdGhlIEFTIHdv dWxkIGFscmVhZHkga25vdyB3aGljaCBwcm9maWxlcyBib3RoIEMgYW5kIFJTIHN1cHBvcnQsIGFu ZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGh1cyBqdXN0IHNlbGVjdCB0 aGUgaWRlYWwgb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvZXMgdGhlIGdyb3Vw IHRoaW5rLCBzaG91bGQgd2UgaW5zdGVhZCBhbGxvdyBmb3IgYSBsaXN0IG9mPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9maWxlcyBhbmQgbGV0IHRoZSBjbGllbnQgc2Vs ZWN0IHdoaWNoIG9uZSB0byB1c2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzUiPkFnYWluLCBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRh Y3RpY2FsIGVudmlyb25tZW50cywgYmVjYXVzZSB3ZSDigJxlbmZvcmNl4oCdIHBhaXJpbmcgYmV0 d2VlbiBDbGllbnQgYW5kIHRoZSBBUywgdGhlIEFTIHNob3VsZCBoYXZlIGVub3VnaCBrbm93bGVk Z2UgdG8gZGVjaWRlIHdoaWNoIHByb2ZpbGUgdG8gdXNlLiBCdXQsIHdoYXQNCiBpZiB0aGVyZSBp cyBtb3JlIHRoYW4gb25lIHByb2ZpbGUgdGhhdCB3b3JrcyBmb3IgYm90aC4gRG9lcyB0aGUgQVMg cmVhbGx5IGhhdmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHNlbGVjdCB0aGUg4oCcaWRlYWzigJ0/ IEluIHRoYXQgY2FzZSwgc29tZXRoaW5nIGxpa2Ugd2hhdCBGcmFuY2VzY2EgaXMgc3VnZ2VzdGlu ZyB3b3VsZCBtYWtlIHNlbnNlLiBIb3dldmVyLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCBm b3IgdXMgdG8gYmV0dGVyIHVuZGVyc3RhbmQNCiB0aGUgdXNlIGNhc2VzIGZvciBtdWx0aXBsZSBw cm9maWxlcyB0byBzZWUgaWYgaXQgcmVhbGx5IG1ha2VzIHNlbnNlLiBUaGUgcG90ZW50aWFsIG5l ZWQgZm9yIHRoaXMgbmVnb3RpYXRpb24gaXMgdW5kZXJzdG9vZCwgYnV0IGl0IGFsc28gbWFrZXMg dGhlIHdob2xlIHByb2Nlc3MgbG9uZ2VyIGFuZCBtb3JlIGNvbXBsZXguIFVubGVzcyB3ZSBoYXZl IGdvb2QgdXNlIGNhc2VzLCBhbmQgYW4gdW5kZXJzdGFuZGluZyB0aGF0IHRoaXMgbWlnaHQgYmUN CiB0aGUgbm9ybSByYXRoZXIgdGhhbiB0aGUgZXhjZXB0aW9uLCB0aGVuIGl0IHdvdWxkIG1ha2Ug c2Vuc2UgdG8gYWRkIHRvIEFDRS4gSWYgbm90LCBtYXliZSBhbiBleHBlcmltZW50YWwgUkZDPzxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMwMDAwN0YiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtPcHRpbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw MDdGIj5HcmFjZSBBLiBMZXdpcywgUGguRC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7T3B0aW1hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA3RiI+UHJpbmNpcGFsIFJlc2Vh cmNoZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJp Zjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7T3B0aW1hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA3RiI+Q2FybmVnaWUg TWVsbG9uIFNvZnR3YXJlIEVuZ2luZWVyaW5nIEluc3RpdHV0ZTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtPcHRpbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDdGIj5Tb2Z0 d2FyZSBTb2x1dGlvbnMgRGl2aXNpb24mbmJzcDsoU1NEKSZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1 b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtPcHRpbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDdGIj5U YWN0aWNhbCBUZWNobm9sb2dpZXMgR3JvdXAgKFRURyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJp Zjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7T3B0aW1h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA3RiI+NDUwMCBGaWZ0aCBBdmUuJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJr aXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O09wdGltYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDAwN0YiPlBpdHRzYnVyZ2gsIFBBIDE1MjEzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O09wdGltYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwN0YiPlBob25lOiAoNDEy KSAyNjgtNTg1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtPcHRpbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDdGIj5odHRwOi8vd3d3LnNl aS5jbXUuZWR1L3N0YWZmL2dsZXdpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkFjZSAmbHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFs ZiBvZiBMdWR3aWcgU2VpdHogJmx0O2x1ZHdpZy5zZWl0ekByaS5zZSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgNDo1OSBBTTxicj4NCjxiPlRvOiA8 L2I+JnF1b3Q7YWNlQGlldGYub3JnJnF1b3Q7ICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPltBY2VdIFF1ZXN0aW9ucyBhYm91dCBkcmFmdC1pZXRmLWFjZS1vYXV0aC1h dXRoejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGVsbG8gQUNFLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5kdXJpbmcgdGhlIElFVEYgMTAwIHNlc3Npb24gdGhlcmUgd2VyZSBh IG51bWJlciBvZiBxdWVzdGlvbnMgb24NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHogdGhhdCBJIHdv dWxkIGxpa2UgdG8gYnJpbmcgdG8gdGhlIGxpc3QgZm9yDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZlZWRiYWNrOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLikgQ3VycmVudGx5IHRoZSBm cmFtZXdvcmsgcmVxdWlyZXMgdGhlIHVzZSBvZiBDQk9SIGFzIGRhdGEgb2JqZWN0DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvcm1hdCBhbmQg b2YgcGFyYW1ldGVyIG5hbWUgYWJicmV2aWF0aW9ucy4gU29tZSBjb21tZW50cyB2b2ljZWQgdGhl DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9w aW5pb24gdGhhdCB0aGVzZSByZXF1aXJlbWVudHMgc2hvdWxkIGJlIHJlbGF4ZWQgYW5kIHRoZSBj aG9pY2UgbGVmdCB0bw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50aGUgcHJvZmlsZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSB0aGUgZm9sbG93aW5nIG9wdGlvbnM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEuKSBLZWVwIGl0 IGFzIGl0IGlzIChpLmUuIENCT1IgYW5kIHBhcmFtZXRlciBuYW1lIGFiYnJldmlhdGlvbnMgUkVR VUlSRUQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmIuKSBSZW1vdmUgYWxsIHJlcXVpcmVtZW50cyAoaS5lLiBkYXRhIGZvcm1hdCB0b3RhbGx5 IHVwIHRvIHRoZSBwcm9maWxlcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Yy4pIFJFQ09NTUVORCB0aGUgdXNlIG9mIENCT1IgYW5kIHBhcmFt ZXRlciBhYmJyZXZpYXRpb25zIChhbGxvd2luZw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9maWxlcyB0byBzcGVjaWZ5IHNvbWV0aGluZyBl bHNlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaGF0IGRvZXMgdGhlIGdyb3VwIHRoaW5rIHdlIHNob3VsZCBkbz88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLikgU2hvdWxkIHRoZSB3 b3JrIG9uIENsaWVudCBUb2tlbiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPig8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMDgjc2VjdGlvbi01LjcuNCI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTA4I3NlY3Rpb24tNS43LjQ8 L2E+KQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5iZSBpbiB0aGUgZHJhZnQgb3IgbW92ZWQgb3V0IHRvIGEgc2VwYXJhdGUgZG9jdW1lbnQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhY2tn cm91bmQ6IFdlIGRlc2lnbmVkIENsaWVudCBUb2tlbiB0byBhZGRyZXNzIHRoZSB1c2UgY2FzZXMg d2hlcmUgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNsaWVudCBoYXMgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSBhbmQgbmVlZHMgdG8g cmVjZWl2ZSBpbmZvcm1hdGlvbg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5mcm9tIHRoZSBBUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4pIFdoYXQgaXMgdGhlIHJlbGF0aW9uc2hpcCB0 byB0aGUgVG9rZW4gQmluZGluZyBXb3JrIGF0IE9BdXRoDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPig8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWJpbmRpbmcvIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWJpbmRpbmcv PC9hPikgPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4zLWJpcy4pIFRvIG1lIGl0IHNlZW1zIGxpa2UgdGhpcyBjb3VsZCBnbyBpbnRvIGEgcHJv ZmlsZSBvZiB0aGUgQUNFDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmZyYW1ld29yay4gV291bGQgc29tZW9uZSBiZSB3aWxsaW5nIHRvIHdyaXRl IHN1Y2ggYSBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj40LikgV2hhdCBwYXJhbWV0ZXJzIHRvIHB1dCBpbnRvIHRoZSByZXNwb25z ZSB0byBhbiB1bmF1dGhvcml6ZWQgcmVxdWVzdA0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTA4I3NlY3Rpb24tNS4xLjIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0wOCNzZWN0 aW9uLTUuMS4yPC9hPik/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkppbSBTY2hhYWQgc3VnZ2VzdGVkIHRvIGFkZCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgYXVkaWVuY2UgYW5kIHNjb3BlIHRoZQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SUyBleHBlY3RzIHRvIGdyYW50IGFjY2VzcyB0byB0 aGUgZ2l2ZW4gcmVzb3VyY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPig8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2FjZS9pT2JmMEVDaG8tLTdGQ1lXQlJRWVVIdE9zQnciPmh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvYWNlL2lPYmYwRUNoby0tN0ZDWVdCUlFZVUh0T3NCdzwvYT4pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhh dmUgaGFkIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGFscmVhZHksIGJ1dCBJIGhhdmUg bm90IHNlZW4gYQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5jb25jbHVzaXZlICZxdW90O2RlY2lzaW9uJnF1b3Q7IGJ5IHRoZSBncm91cCAoaWYg c3VjaCBhIHRoaW5nIGNhbiBleGlzdCkgYXMgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hhdCB0byBkby48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NS4pIEZyYW5jZXNjYSBzdWdnZXN0 ZWQgdG8gYWxsb3cgdGhlIEFTIHRvIHJldHVybiBhIGxpc3Qgb2YgcG9zc2libGUNCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJvZmlsZXMgdG8g dGhlIGNsaWVudCBpbiByZXNwb25zZSB0byBhbiBhY2Nlc3MgdG9rZW4gcmVxdWVzdC4gQ3VycmVu dGx5DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pm9ubHkgb25lIHByb2ZpbGUgaXMgc2VsZWN0ZWQgYW5kIG9wdGlvbmFsbHkgcmV0dXJuZWQgYnkg dGhlIEFTIChpdCBjb3VsZA0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ldmVuIGJlIGltcGxpY2l0IGFuZCBub3QgYmUgcmV0dXJuZWQgYXQgYWxs KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QmFja2dyb3VuZDogVGhlIHdheSBJIHdhcyB0aGlua2luZyB0aGlzIHNob3VsZCB3b3JrIHdhcyB0 aGF0IGJvdGggdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmNsaWVudCBhbmQgdGhlIFJTIG5lZWQgdG8gYmUgcmVnaXN0ZXJlZCBhdCB0aGUg QVMgaW4gb3JkZXIgZm9yIHRoZQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5leGNoYW5nZXMgdG8gd29yay4gSSBtYWRlIHRoZSBhc3N1bXB0aW9u IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1h dXRoei0wOCNhcHBlbmRpeC1EIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1hY2Utb2F1dGgtYXV0aHotMDgjYXBwZW5kaXgtRDwvYT4pDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgdGhlIEFTIHdvdWxkIGFscmVh ZHkga25vdyB3aGljaCBwcm9maWxlcyBib3RoIEMgYW5kIFJTIHN1cHBvcnQsIGFuZA0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aHVzIGp1c3Qg c2VsZWN0IHRoZSBpZGVhbCBvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG9lcyB0aGUgZ3JvdXAgdGhpbmssIHNob3VsZCB3ZSBp bnN0ZWFkIGFsbG93IGZvciBhIGxpc3Qgb2YNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJvZmlsZXMgYW5kIGxldCB0aGUgY2xpZW50IHNlbGVj dCB3aGljaCBvbmUgdG8gdXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkx1ZHdpZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkx1ZHdpZyBTZWl0eiwgUGhEPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN1cml0eSBMYWIsIFJJ U0UgU0lDUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UGhvbmUgJiM0Mzs0NigwKTcwLTM0OSA5MiA1MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRmLm9yZyI+ QWNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D8A13748944B4DD08A0A33063084E3F6seicmuedu_-- From nobody Wed Nov 22 16:30:59 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649601241FC for ; Wed, 22 Nov 2017 16:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZAWwNahKkr8u for ; Wed, 22 Nov 2017 16:30:57 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113A81293E4 for ; Wed, 22 Nov 2017 16:30:56 -0800 (PST) X-AuditID: 1209190f-423ff7000000281b-f8-5a1616bebe79 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B9.C3.10267.EB6161A5; Wed, 22 Nov 2017 19:30:55 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id vAN0Urch000919 for ; Wed, 22 Nov 2017 19:30:54 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAN0Upd9009926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Nov 2017 19:30:53 -0500 Date: Wed, 22 Nov 2017 18:30:51 -0600 From: Benjamin Kaduk To: ace@ietf.org Message-ID: <20171123003050.GZ82825@kduck.kaduk.org> References: <20171101172455.GT26855@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101172455.GT26855@kduck.kaduk.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUixCmqrbtfTCzKoGUas8X3bz3MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuP+SreAJS8Wsm9vZGxi/MXcxcnJICJhILOt5xd7FyMUhJLCY SWLKhycsEM4RRomFH39COS+YJA5t284O0sIioCpxc95vsHY2ARWJhu7LYLaIgIDE3I+fwWxh AW+JTzOvs4HYvEArXk+/B2YLAdlzOrrZIeKCEidngmzj5GAW0JK48e8lUxcjB5AtLbH8HwdI mFPAVGJq/xlGEFtUQFlib98h9gmM/LOQdM9C0j0LoXsBI/MqRtmU3Crd3MTMnOLUZN3i5MS8 vNQiXRO93MwSvdSU0k2M4MCT5N/BOKfB+xCjAAejEg/vijmiUUKsiWXFlbmHGCU5mJREeYOX i0QJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuENXgBUzpuSWFmVWpQPk5LmYFES590WtCtSSCA9 sSQ1OzW1ILUIJivDwaEkwRsNjDAhwaLU9NSKtMycEoQ0EwcnyHAeoOFlokA1vMUFibnFmekQ +VOMxhw3Hl7/w8TxbObrBmYhlrz8vFQpcd7FIKUCIKUZpXlw00DJQyJ7f80rRnGg54R5L4BU 8QATD9y8V0CrmIBW/TwuDLKqJBEhJdXAuP3BG2nGzYL7Mntuh7+w1578hXmCme7rzMiOp7f+ KbyLvKyYdfLvq5NVcn8bZjn7mwi6txkWTXxiuqn1PfOc1zY3Hu0qEd76UmhefVLruYrnGx4J htTdDwyx4e44tDN18/r10+fK+/1W6HZvPap9LHatxM6+P4tWB1j5Tln0t/jwps1a5yq36imx FGckGmoxFxUnAgBbU5/X+QIAAA== Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 00:30:58 -0000 Reminder: there is only one week left in this WGLC. -Ben On Wed, Nov 01, 2017 at 12:24:56PM -0500, Benjamin Kaduk wrote: > This message begins a working group last call for > draft-ietf-ace-cbor-web-token for submission as a Standards-Track RFC, > ending at 23:59 PST on Wednesday 29 November, 2017. > > The current (-09) version of the document is available at: > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-09 . > > Thanks, > > Ben and Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Nov 23 01:25:29 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA72312711A; Thu, 23 Nov 2017 01:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 p-_sztMh7EH9; Thu, 23 Nov 2017 01:25:25 -0800 (PST) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773EF1242EA; Thu, 23 Nov 2017 01:25:22 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 8EC882245CB; Thu, 23 Nov 2017 09:25:18 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 23 Nov 2017 10:25:19 +0100 To: "ace@ietf.org" , References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> From: Ludwig Seitz Message-ID: Date: Thu, 23 Nov 2017 10:25:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171123003050.GZ82825@kduck.kaduk.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=IpHnQPaCosD682nvEAgA:9 a=g0G-CGi-nDCZRwHC:21 a=HkQu6zWV9uMj2sDY:21 a=QEXdDO2ut3YA:10 a=weSYshJLkwMA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 09:25:28 -0000 Hi ACE, I have only some nits on the CWT draft (see below). /Ludwig ======================================================== I'm not sure what the RFC editors prefer as affiliation (I've seen both): -- E. Wahlstroem -- OR E. Wahlstroem (no affiliation) -- === 2. Terminology In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT RECOMMENDED is used in the draft. What is the recommended procedure here? It feels like we could remove the other ones. === "CWT Claims Set The CBOR map that ..." Why is a map called a set here? I know what is meant, but it sound really weird. === Sections 3.1.* The links to sections in JWT point to sections in this draft instead (at least in the html-ised version of the draft). See: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 for hints on how to fix this. === Figure 1: Perhaps indicate the CBOR major type number together with the "Value type" text. === -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Thu Nov 23 02:55:55 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908C4127B60; Thu, 23 Nov 2017 02:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 OOycAmFxYefj; Thu, 23 Nov 2017 02:55:52 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C331F1277BB; Thu, 23 Nov 2017 02:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vANAtlqj014393; Thu, 23 Nov 2017 11:55:47 +0100 (CET) Received: from [192.168.217.124] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yjGSz0hfCzDWtT; Thu, 23 Nov 2017 11:55:47 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 23 Nov 2017 11:55:46 +0100 Cc: "ace@ietf.org" , draft-ietf-ace-cbor-web-token.authors@ietf.org X-Mao-Original-Outgoing-Id: 533127346.26809-111e485cd5973c72855e7ff9125ae692 Content-Transfer-Encoding: quoted-printable Message-Id: <94F0F425-7AF7-435C-8CC8-484B30A296D5@tzi.org> References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> To: Ludwig Seitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 10:55:53 -0000 Hi Ludwig, > I'm not sure what the RFC editors prefer as affiliation > (I've seen both): >=20 > -- > E. Wahlstroem >=20 > -- OR > E. Wahlstroem > (no affiliation) > =E2=80=94 I don=E2=80=99t know what the RFC editor prefers her, but I find =E2=80=9C= no affiliation=E2=80=9D jarring =E2=80=94 leaving the space open is much = better. > =3D=3D=3D > 2. Terminology >=20 > In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT = RECOMMENDED is used in the draft. What is the recommended procedure = here? It feels like we could remove the other ones. It is usual to include the whole boilerplate (obviously the corrected = one, with NOT RECOMMENDED included, in this case). > =3D=3D=3D >=20 > "CWT Claims Set >=20 > The CBOR map that ..." >=20 > Why is a map called a set here? I know what is meant, but it sound = really weird. Because a claim is a pair of map key and map value, so the whole thing = is indeed a set of claims (with the additional restriction that a key = can only be used once; hence we need array-valued map values). (The term =E2=80=9Cclaim" is misleading and wrong here, but that is = inherited from JWT.) > =3D=3D=3D >=20 > Sections 3.1.* >=20 > The links to sections in JWT point to sections in this draft instead > (at least in the html-ised version of the draft). >=20 > See: > https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 >=20 > for hints on how to fix this. Somewhat temporary, but a useful thing to change. >=20 > =3D=3D=3D >=20 > Figure 1: Perhaps indicate the CBOR major type number together with = the > "Value type" text. Or perhaps don=E2=80=99t? The major type number is something that is = internal to the serialization; standards using RFC 7049 should not try = to repeat internals of RFC 7049 all over the place. I=E2=80=99d prefer to use the data model level names as it is specified = now. My editorial comment on this is that this should be a table, not ASCII = art. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Nov 23 04:13:55 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30332128B4E for ; Thu, 23 Nov 2017 04:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Dwr8XUBUexy7 for ; Thu, 23 Nov 2017 04:13:52 -0800 (PST) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E08128AFE for ; Thu, 23 Nov 2017 04:13:51 -0800 (PST) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id EF6D5221F9F; Thu, 23 Nov 2017 12:13:47 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 23 Nov 2017 13:13:48 +0100 To: Carsten Bormann CC: "ace@ietf.org" References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> <94F0F425-7AF7-435C-8CC8-484B30A296D5@tzi.org> From: Ludwig Seitz Message-ID: Date: Thu, 23 Nov 2017 13:13:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <94F0F425-7AF7-435C-8CC8-484B30A296D5@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=QLPfpYkryAO4RqcpiSkA:9 a=amRETSBiBtJXTjzb:21 a=L4oD2oIIA-0SKVEq:21 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 12:13:54 -0000 On 2017-11-23 11:55, Carsten Bormann wrote: >> >> Figure 1: Perhaps indicate the CBOR major type number together >> with the "Value type" text. > > Or perhaps don’t? The major type number is something that is > internal to the serialization; standards using RFC 7049 should not > try to repeat internals of RFC 7049 all over the place. I’d prefer to > use the data model level names as it is specified now. I'll take that as an input to draft-ietf-ace-oauth-authz as well then. Btw Carsten, can you review that one at some point? I think you input would be valuable (we have reviews from a few OAuth experts, but not so many from CoRE experts). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Fri Nov 24 19:55:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22258129486; Fri, 24 Nov 2017 19:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ICn_AJF2v_ml; Fri, 24 Nov 2017 19:55:17 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89011242F7; Fri, 24 Nov 2017 19:55:16 -0800 (PST) X-AuditID: 1209190d-85dff70000005c18-97-5a18e9a35d80 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C0.81.23576.3A9E81A5; Fri, 24 Nov 2017 22:55:15 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vAP3tEgY029814; Fri, 24 Nov 2017 22:55:14 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAP3t93I009104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Nov 2017 22:55:12 -0500 Date: Fri, 24 Nov 2017 21:55:09 -0600 From: Benjamin Kaduk To: Carsten Bormann Cc: Ludwig Seitz , draft-ietf-ace-cbor-web-token.authors@ietf.org, "ace@ietf.org" Message-ID: <20171125035509.GB82825@kduck.kaduk.org> References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> <94F0F425-7AF7-435C-8CC8-484B30A296D5@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94F0F425-7AF7-435C-8CC8-484B30A296D5@tzi.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrLv4pUSUwcTtRhbfv/UwWxyZcpfV YtL2f8wWrz5PZ3Vg8Viy5CeTx9KmzUwe0xZlBjBHcdmkpOZklqUW6dslcGW87XvAVvCBrWLe 7z62BsZFrF2MnBwSAiYS/zbdALK5OIQEFjNJdG86zAThbGSUaLvZAZW5yiSx8/YkRpAWFgFV iVVPZzGD2GwCKhIN3ZfBbBEBJYkLF9ewgTQwC7QxSkyYfocFJCEs4C3xaeZ1NhCbF2jf8e/T oFbsZ5S4NXsxO0RCUOLkzCdgDcwC6hJ/5l0CmsoBZEtLLP/HARGWl2jeOhtsGaeAtcTR9avB WkUFlCX29h1in8AoOAvJpFlIJs1CmDQLyaQFjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30 cjNL9FJTSjcxgsNekncH47+7XocYBTgYlXh4X+hIRAmxJpYVV+YeYpTkYFIS5e3oF48S4kvK T6nMSCzOiC8qzUktPsQowcGsJMIr/1QsSog3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZq akFqEUxWhoNDSYI3/wXQHsGi1PTUirTMnBKENBMHJ8hwHqDhziA1vMUFibnFmekQ+VOMxhw3 Hl7/w8TxbObrBmYhlrz8vFQpcd5ykFIBkNKM0jy4aaDUJZG9v+YVozjQc8K8M0GqeIBpD27e K6BVTECrnp4UB1lVkoiQkmpg9Ppz59zU1eXXEybsj5uv+NN3uprygcmz5IXWOO1eWTJjvmpo /S8r56337z6X0HzqZ71t1qROe9Op/3ld2w32SZz29ZxRyxXQt3Vq0LO5btaGK79G57+0r5hv mj3xwavXD67Hqi37ucl8QlTLZaeJqrrbfLgucwlnTojNuFiY3xRxK/aS3F0DESWW4oxEQy3m ouJEAH4aFP84AwAA Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 03:55:18 -0000 On Thu, Nov 23, 2017 at 11:55:46AM +0100, Carsten Bormann wrote: > Hi Ludwig, > > > I'm not sure what the RFC editors prefer as affiliation > > (I've seen both): > > > > -- > > E. Wahlstroem > > > > -- OR > > E. Wahlstroem > > (no affiliation) > > — > > I don’t know what the RFC editor prefers her, but I find “no affiliation” jarring — leaving the space open is much better. I also sometimes see "Unaffliated". > > === > > 2. Terminology > > > > In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT RECOMMENDED is used in the draft. What is the recommended procedure here? It feels like we could remove the other ones. > > It is usual to include the whole boilerplate (obviously the corrected one, with NOT RECOMMENDED included, in this case). Right, at this point people should be citing BCP 14/RFC 8174. -Ben From nobody Tue Nov 28 04:25:31 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854001279E5 for ; Tue, 28 Nov 2017 04:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 8o9hbUBgm1lF for ; Tue, 28 Nov 2017 04:25:23 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAC61277BB for ; Tue, 28 Nov 2017 04:25:22 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id k24so70842pfb.1 for ; Tue, 28 Nov 2017 04:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z1hUdR8ZiCBaDsdcE35bIaP9zXKgo1r2XCCRvNADH7s=; b=tAR2SJTP5lwbfWBRi1cVX5iiaZrffmIhz07uJNh+mJuudJKgeWycca5guvk6yxZth3 tAVfOspmrjDwyrcNWuz5aNvd4z/vEZd8e02KmciMRHRyH9rRXx3O2Y2z1bOUPkzT2IFX rHYa1HxIjfT9pHYt/QipsTwp9M78SMoDI5ld0Za9dEPhpXyx+fqL+0G1CGCpZs/PBBlC F8juw/1AejkTVzcToRJoQuOeufTbFy9JW1n8UK8rsCqhINn8QqcRp03j/hbWrZh3Wdaz 0MZVzMwVCa8qv9toQqvd78aizokGWqZC+EslRAUFStllC8YupZZIzvy+x9/rxFyIfeKQ Vtvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z1hUdR8ZiCBaDsdcE35bIaP9zXKgo1r2XCCRvNADH7s=; b=RuA04QZ40xcu2SDJBm0cPbW7owbnkY4HamMgHyTj62LyoY9m0s88xlKfCEyPNEc+pJ lYE1J8TK5IXslG2qrwr1y85cJG/6P1xVrjL9tNh6EYa1Cfa5VBpqOGgG/aVb/t8AQqoo NM4EdMAg8E+ZdXVp+HMZUOXHGj6y7mhTb12Zh41fzwmcNGYbOg5ZBYYNWeL46lGmn9aj uj1VivmU0ufguseimffs9nLq+7hUhYcxfizmR7PeoC/cP7NNTFtB9Md5xLDa4VKwKWTz IfIP0iyTnLkrNOBAlK1ap9FrIThFHbMnP7QIUxPfSAwrxPh2paF5T/OTRYykKmPOoSNL /tJA== X-Gm-Message-State: AJaThX4bpFbGD6HQ/xPgoxY32RCzv8uXWzjZEu/ZDmXzSY+Ar109H5Tw z3jh7l8g0tD7an59RRIgVUrMEb3OwMDxoL0WB9Cd0A== X-Google-Smtp-Source: AGs4zMa6yAh34x5UTtK2z9+nA1PwYRaS5CIjo1+EzlcQ8i8CfQx4Kh8PP2ji/g0eXbhQI3z/J9pzfDQW6KMub1qQVJE= X-Received: by 10.99.160.96 with SMTP id u32mr40667901pgn.25.1511871922036; Tue, 28 Nov 2017 04:25:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.169.15 with HTTP; Tue, 28 Nov 2017 04:25:21 -0800 (PST) In-Reply-To: References: <20171101172455.GT26855@kduck.kaduk.org> <20171123003050.GZ82825@kduck.kaduk.org> From: Samuel Erdtman Date: Tue, 28 Nov 2017 13:25:21 +0100 Message-ID: To: Ludwig Seitz , Carsten Bormann , Benjamin Kaduk Cc: "ace@ietf.org" , draft-ietf-ace-cbor-web-token.authors@ietf.org Content-Type: multipart/alternative; boundary="f403043636eadbf7a5055f0a1ccf" Archived-At: Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 12:25:30 -0000 --f403043636eadbf7a5055f0a1ccf Content-Type: text/plain; charset="UTF-8" Thanks for the review Ludwig, it is really appreciated. see inline On Thu, Nov 23, 2017 at 10:25 AM, Ludwig Seitz wrote: > Hi ACE, > > I have only some nits on the CWT draft (see below). > > > /Ludwig > > ======================================================== > > I'm not sure what the RFC editors prefer as affiliation > (I've seen both): > > -- > E. Wahlstroem > > -- OR > E. Wahlstroem > (no affiliation) > -- > I would prefere the empty space. The xml doc does not contain any text and when submitting to http://xml2rfc.tools.ietf.org/ I get the empty line. If co-authors agree I think we need to do something when submitting the new draft. > > > === > 2. Terminology > > In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT > RECOMMENDED is used in the draft. What is the recommended procedure here? > It feels like we could remove the other ones. > > === > I agree with Carsten that the full template should be used. and I agree with Benjamin that we should use the latest version. I have created a PR that is waiting for review by co-authors. > > "CWT Claims Set > > The CBOR map that ..." > > Why is a map called a set here? I know what is meant, but it sound really > weird. > I think the is the right way to phrase it. > > === > > Sections 3.1.* > > The links to sections in JWT point to sections in this draft instead > (at least in the html-ised version of the draft). > > See: > https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 > > for hints on how to fix this. > I have created a PR that is waiting for review by co-authors. > === > > Figure 1: Perhaps indicate the CBOR major type number together with the > "Value type" text. > I agree with Carsten, we have had this discussion before. I have created a PR changing from ascii art to table (waiting for review by co-authors) > > === > > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --f403043636eadbf7a5055f0a1ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Ludwig, it is really appreciated.

see inline

On Thu, Nov 23, 2017 at 10:25 AM, Ludwig Seitz <= ;ludwig.seitz@ri.se= > wrote:
Hi ACE,

I have only some nits on the CWT draft (see below).


/Ludwig

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

I'm not sure what the RFC editors prefer as affiliation
(I've seen both):

--
E. Wahlstroem

--=C2=A0 OR
E. Wahlstroem
(no affiliation)
--

I would prefere the empty space. The= xml doc does not contain any text and when submitting to http://xml2rfc.tools.ietf.org/ I get the empt= y line.

If co-authors agree I think we need to do = something when submitting the new draft.
=C2=A0


=3D=3D=3D
2. Terminology

In the RFC 2119 boilerplate I noticed that only MUST, MUST NOT and NOT RECO= MMENDED is used in the draft. What is the recommended procedure here? It fe= els like we could remove the other ones.

=3D=3D=3D

I agree with Carsten that the= full template should be used. and I agree with Benjamin that we should use= the latest version.
I have created a PR that is waiting for revi= ew by co-authors.
=C2=A0

"CWT Claims Set

=C2=A0 The CBOR map that ..."

Why is a map called a set here? I know what is meant, but it sound really w= eird.

I think the is the right way to p= hrase it.
=C2=A0

=3D=3D=3D

Sections 3.1.*

The links to sections in JWT point to sections in this draft instead
(at least in the html-ised version of the draft).

See:
https://xml2rfc.tools.ietf.org/xml2rfcFA= Q.html#anchor18

for hints on how to fix this.

I have cr= eated a PR that is waiting for review by co-authors.


=3D=3D=3D

Figure 1:=C2=A0 Perhaps indicate the CBOR major type number together with t= he
"Value type" text.

I agree wi= th Carsten, we have had this discussion before.

I = have created a PR changing from ascii art to table (waiting for review by c= o-authors)



=3D=3D=3D



--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--f403043636eadbf7a5055f0a1ccf--